أربع دقائق لإنشاء حساب الخدمة. ستة عشر شهرًا من سجل Search Console تُملأ بأثر رجعي عند أول مزامنة. ثانيتان لنطاق تم التحقق منه ومنح الصلاحيات له مسبقًا. وشهران — الرقم الذي يتسبب في تذاكر دعم أكثر من الأرقام الثلاثة الأخرى مجتمعة، لأنه نافذة الاحتفاظ الافتراضية بالبيانات في GA4، وتقريبًا لا أحد يعرف أن عليه التحقق منها قبل الاتصال.
الإعداد نفسه قصير: بيانات اعتماد واحدة في الإعدادات ← حسابات Google، وزرا اتصال في إدارة النطاقات، وبعد ذلك تنسى غالبًا وجود هذه الصفحة. لكن رقم الشهرين يستحق شرحًا كاملًا، لأنه يفسر سبب ظهور سجل Analytics غني ومفيد لبعض النطاقات من اليوم الأول بينما لا يظهر لنطاقات أخرى شيء يُذكر لأسابيع — وهذا ليس خللًا في المنصة عندما يحدث.
بيانات اعتماد واحدة، تُمنح مرة واحدة
تقوم برفع مفتاح حساب خدمة من Google — ملف JSON، وليس تسجيل دخول شخصي. هوية آلية، وليست رمز OAuth بشري ينتهي صلاحيته أو يتعطل عند تغيير شخص لكلمة مروره. تصدره Google Cloud مرة واحدة ويستمر بالعمل حتى تحذفه، وهذا أيضًا ما يتيح للمنصة المزامنة في الساعة الثالثة صباحًا دون أن يكون أحد مسجلاً دخوله.
إنشاء واحد يستغرق نحو تلك الدقائق الأربع إن لم تفعل ذلك من قبل: مشروع جديد أو حالي، ثم IAM وAdmin ← حسابات الخدمة ← إنشاء، ثم تنزيل المفتاح. الصلاحية أهم مما يوحي به القائمة المنسدلة — امنح صلاحية مشاهد (Viewer) على خاصية Search Console وخاصية Analytics، ولا شيء أعلى من ذلك. رأيت فرقًا يمنحون صلاحية محرر (Editor) لأنها الخيار الأول في القائمة، وبعد ستة أشهر لا أحد يستطيع تفسير سبب امتلاك حساب آلي صلاحية كتابة في إعدادات GA4. القراءة فقط هي الصحيحة؛ المنصة لا تلمس إعداداتك أبدًا.
مفتاح واحد يغطي كل نطاق ضمن مشروع Google Cloud ذاك. إذا كنت وكالة تدير عشرات مواقع العملاء، فهذا يدعم فكرة حساب خدمة واحد لكل عميل بدلًا من حساب واحد للجميع — فإنهاء التعامل مع عميل يصبح حذف مفتاح، وليس تدقيقًا لمعرفة أي النطاقات شاركت بيانات اعتماد بصمت مع شخص غادر للتو.
Search Console: سريع حين يكون سريعًا، ومزعج حين لا يكون كذلك
- افتح اتصال على أحد النطاقات. يحصل كل من Search Console وAnalytics على بطاقة خاصة به، ويحتوي Analytics على اختصار "نفس Search Console"، لأن مفتاحًا واحدًا يغطي عادةً كليهما.
- تم التحقق منه مسبقًا ومُنح حساب الخدمة صلاحية الوصول؟ فوري — فحص صلاحية، يتم خلال نحو ثانيتين.
- لم يتم التحقق منه بعد: تحقق تلقائي عبر DNS إذا سلّمت مفتاح API الخاص بمسجل نطاقك (Cloudflare، Route 53، وبضعة آخرين)، أو سجل TXT يدوي تضيفه بنفسك.
الطريقة اليدوية هي حيث يفقد الناس صبرهم. الانتشار (propagation) يختلف حقًا — تسعون ثانية مرة، وأربع ساعات مرة أخرى، حسب TTL وتخزين المحلل المؤقت. المنصة تستطلع الحالة دوريًا، لذا أضف السجل وامضِ في عملك. إذا مرّ يوم كامل دون تحقق، فنادرًا ما يكون السبب الانتشار؛ غالبًا خطأ إملائي في القيمة أو أن السجل وُضع في المنطقة الخاطئة (النطاق الجذري بدلًا من نطاق فرعي، أو العكس). شغّل أمر `dig TXT` على ما هو منشور فعليًا قبل لوم Google.
طريقة مفتاح API تتخطى كل ذلك بكتابة السجل نيابة عنك، لكنها تعني منح أداة طرف ثالث صلاحية كتابة على DNS الخاص بك — وإذا كان هذا الـ DNS يقف أمام حركة الإنتاج، فلا أعتقد أن التردد أمر غير منطقي. الطريقة اليدوية تكلفك بضع دقائق في البداية وتوفر عليك التفكير فيها مجددًا إلى الأبد.
Analytics، وفجوة الاحتفاظ بالبيانات التي لا يحذرك منها أحد
يتصل Analytics عن طريق الاكتشاف وليس التحقق — تبحث المنصة عن خاصية GA4 موجودة على النطاق وتتصل بها إذا كان لحساب الخدمة الخاص بك صلاحية الوصول، لأن صلاحيات GA4 مضبوطة أصلًا من جانب Google. يمكنها إنشاء خاصية إذا لم توجد أي خاصية، لكن اترك ذلك فقط للمواقع الجديدة فعليًا. إذا انتقلت من Universal Analytics أو لديك خاصية بسجل يمتد لسنوات، فاتصل بتلك الخاصية صراحةً. خاصية جديدة بثلاثة أيام من البيانات نقطة بداية أسوأ بكثير من خاصية عمرها تسع سنوات وتحمل أنماطًا موسمية متراكمة، وحلقة التحسين تعتمد على ذلك السجل أكثر مما يوحي به تدفق الاتصال.
هنا الفجوة التي تُربك الناس: يملأ Search Console بأثر رجعي حتى ستة عشر شهرًا من بيانات الاستعلامات عند أول مزامنة، لأن Google تحتفظ بهذا القدر من السجل على خوادمها بغض النظر عن وقت الاتصال. لا يملك GA4 ضمانًا مماثلًا — فتعبئته بأثر رجعي محدودة بإعداد الاحتفاظ بالبيانات الخاص بالخاصية نفسها، وهذا الإعداد افتراضيًا شهران ما لم يغيّره أحد في مؤسستك. لذا يمكن لنطاق أن يُظهر ستة عشر شهرًا من مرات الظهور والنقرات لحظة الاتصال، وشهرين من الجلسات، في نفس اليوم بالضبط، من نفس تدفق الإعداد بالضبط. هذا ليس فشل مزامنة. إنه إعداد Google الافتراضي للاحتفاظ يعمل تمامًا كما هو مضبوط، والحل — إن أردت أكثر من شهرين مستقبلًا — هو تغيير نافذة الاحتفاظ في إعدادات خاصية GA4 مباشرة، وليس شيئًا من جانب هذه المنصة. يستحق التحقق منه قبل الاتصال، لا بعد أن يربكك التباين.
الخصائص المشتركة وما يعمل بعد ذلك
نقطة أخرى في Analytics: إذا كانت مؤسستك تشغّل خاصية GA4 واحدة تجمع بيانات خمسة مواقع — أمر شائع عندما يُعِد شخص التتبع منذ سنوات ولم يقسّمه أحد منذ ذلك الحين — يعمل الاتصال بشكل جيد، لكن كل استعلام يُصفّى حسب اسم المضيف خلف الكواليس. ليس مربع اختيار، وليس شيئًا يمكن تعطيله عن طريق الخطأ. لهذا السبب تُظهر لوحة التحكم دائمًا أرقام هذا النطاق فقط وليس إجمالي الخاصية المشترك.
بمجرد إتمام كلا الاتصالين، تعمل المزامنة يوميًا وفق جدول تتحكم فيه أنت (راجع فصل الجداول الزمنية)، وتنضم تحليلات المتجر تلقائيًا لأي شيء مبني على المنصة. يُظهر صف النطاق الحالة: معلّق، جزئي، أو نشط — "جزئي" تعني أن أحد الاتصالين نشط والآخر ليس كذلك، وهذه إشارة لك للتحقق من البطاقة الحمراء بدلًا من الاعتماد على الحالة الإجمالية.
أين يتعطل الأمر فعليًا
تقريبًا كل تذكرة دعم رأيتها تندرج ضمن ثلاث فئات، لا شيء غريب فيها. الأولى: مفتاح حساب الخدمة صالح لكنه محدد لمشروع Google Cloud الخاطئ، فيرجع فحص الصلاحية فارغًا رغم أن المفتاح نفسه يُرفع بنجاح. الثانية: لم يُضف أحد فعليًا بريد حساب الخدمة الإلكتروني — شيء مثل [email protected] — كمشاهد (Viewer) داخل إعدادات الوصول الخاصة بـ Search Console أو GA4 نفسها؛ رفع المفتاح إلى المنصة لا يمنحه أي صلاحية من جانب Google. الثالثة، وهي الأخفى: يُعاد ربط نطاق بحساب خدمة جديد بعد حذف القديم، لكن الجدول يستمر بالفشل بصمت مقابل بيانات اعتماد قديمة لأسبوع كامل قبل أن يلاحظ أحد توقف تحديث الأرقام.
لا شيء من هذا خلل في المنصة — إنها التكلفة الاعتيادية لاحتياج حساب آلي لصلاحيات على منتجين منفصلين من Google، ونموذج Google نفسه لا يجعل ذلك واضحًا. خصص خمس عشرة دقيقة لأول نطاق لك، وليس الدقيقتين اللتين يوحي بهما التدفق. كل نطاق بعد ذلك سريع، لأن بيانات الاعتماد والخبرة العملية تنتقلان معك.
