كل حدث GA4 يراه حاوي الخادم لديك، ومن أين يأتي كل واحد منها

في اللحظة التي يُحمَّل فيها وسم Google بمعرّف القياس الخاص بك، تتدفق أربعة أحداث دون أي إعداد وراءها. لا شيء في Analytics يوقفها، ولا يحتاج حاويك إلى طلبها.

• page_view — واحد لكل تحميل صفحة، أو لكل تغيير مسار في تطبيق الصفحة الواحدة عندما يكون خيار «تغييرات الصفحة» في التدفق مفعّلًا.
• session_start — أول نقرة في جلسة جديدة. تنتهي الجلسة بعد ثلاثين دقيقة من الخمول، فالزائر العائد بعد ساعتين يبدأ جلسة أخرى.
• first_visit — مرة واحدة لكل متصفح، في أول جلسة رآها GA4 منه على الإطلاق. مسح ملفات تعريف الارتباط ينتج واحدًا آخر.
• user_engagement — يُرسَل عندما تبقى الصفحة في المقدمة عشر ثوانٍ، أو عندما يغادر الزائر بعد التفاعل. من هنا يأتي وقت التفاعل في GA4.

إذا رأيت page_view ولا شيء غيره، فالوسم يعمل. هذا ليس عطلًا؛ إنه موقع لم يمرّر فيه أحد بعد إلى أسفل الصفحة.

يجمع القياس المحسّن في GA4 تسعة أحداث إضافية في المتصفح، دون وسم لأيٍّ منها. تُضبط على تدفق البيانات لا في Tag Manager، ولهذا يمرّرها حاوي الخادم دون أن يعرف بوجودها.

لكل منها شرط أصرم مما يوحي به اسمه.

• scroll — مرة لكل صفحة، وفقط عندما يصبح 90% من ارتفاع الصفحة مرئيًا. ليس عند أي تمرير: بل عند بلوغ الأسفل. الصفحة الأقصر من نافذة العرض لا تطلقه أبدًا.
• click — نقرة صادرة إلى نطاق غير النطاق الحالي. الروابط الداخلية لا تُحتسب. اسم الحدث هو click مع معلمة outbound؛ لا يوجد outbound_click.
• view_search_results — تحميل صفحة يحمل عنوانها معلمة استعلام بحث (q أو s أو search أو query أو keyword افتراضيًا).
• file_download — نقرة على رابط ينتهي بامتداد مستند أو أرشيف أو صوت أو فيديو أو جدول بيانات.
• form_start و form_submit — أول تفاعل مع نموذج في الصفحة، وإرساله.
• video_start و video_progress و video_complete — لمشغّلات YouTube المضمّنة فقط، وفقط عندما يكون التضمين مفعّلًا فيه دعم واجهة JS API.

وهنا الجزء الذي يكلّف الناس أسابيع. كل واحد من هذه التسعة يعتمد على المفتاح الرئيسي للقياس المحسّن في التدفق، والتدفق الذي أُنشئ عبر Analytics Admin API — لا من واجهة Analytics — يكون هذا المفتاح فيه مُطفأً. اقرأ الإعدادات عبر الواجهة البرمجية فيُرجع كل خيار فردي القيمة true؛ أما المفتاح الرئيسي فغائب ببساطة من الاستجابة، لأنه false والواجهة تحذف القيم المنطقية الخاطئة. فيبدو الإعداد مفعّلًا بالكامل ولا يوصل سوى page_view.

اكتشفنا ذلك في عقارنا نحن. تفعّل SignalHost المفتاح الرئيسي عندما تنشئ عقارًا لك؛ فإن كان عقارك قد أُنشئ بطريقة أخرى ولم يصل scroll أبدًا، افتح تدفق البيانات في Analytics وتحقق من «القياس المحسّن» نفسه، لا من الخيارات التي تحته.

الأحداث التي تجلب المال — بيع، عميل محتمل، تسجيل — هي الوحيدة في هذه الصفحة التي لا يرسلها شيء تلقائيًا. يحدد GA4 أسماءها وشكلها؛ وعلى موقعك أن يدفع كل واحد منها إلى dataLayer بهذا الاسم بالضبط، في اللحظة التي يقع فيها.

في كل حاوي SignalHost مشغّل ووسم حدث GA4 بانتظار ستة عشر منها:

• تسعة لمسار الشراء في المتجر: view_item_list و view_item و add_to_cart و remove_from_cart و view_cart و begin_checkout و add_shipping_info و add_payment_info و purchase، كلٌّ منها مع كائن ecommerce مرفق.
• خمسة للعملاء المحتملين: generate_lead و contact و schedule و submit_application و subscribe.
• اثنان للتسجيلات: sign_up و start_trial.

قالب Shopify الافتراضي لا يدفع أيًا منها، ولا نواة WooCommerce أيضًا: ما يفعل ذلك هو تطبيق أو إضافة لـ dataLayer، وفي Shopify تحتاج أحداث الدفع إلى Custom Pixel لأن حاوي القالب لا يُحمَّل أبدًا في صفحات الدفع. في اللحظة التي يدفع فيها موقعك أحدها، يكون الوسم حاضرًا ليمرّره — أما الدفع نفسه فعليك أن ترتّبه، ومقال Shopify وWooCommerce يشرح بالضبط ما الذي تثبّته.

زر «الأحداث المدعومة» في بطاقة «الأحداث» في حاويك يسردها كلها، مع معنى كل منها وما الذي تدفعه. وإن كان حاويك يرسل أحدها إلى GA4 بوسم خاص بك، تترك SignalHost ذلك الحدث لوسمك بدل أن تحتسبه مرتين.

كل طلب قياس يمر عبر حاويك يُعدّ حسب اسم الحدث، يوميًا، لمدة 400 يوم. لا يُحتفظ إلا بالاسم — لا العنوان، ولا معرّف العميل، ولا معلمة واحدة — وهذا ما يجعل الاحتفاظ به كل هذه المدة آمنًا. القائمة هي ما وصل إلى اسم مضيفك، فهي تجيب عن سؤال لا يستطيع Analytics نفسه الإجابة عنه: هل أرسله المتصفح أصلًا؟

توقّع أعدادًا متفاوتة. كل تحميل صفحة هو page_view؛ وحدها التحميلات التي تبلغ الأسفل تكون scroll؛ وحدها الجلسات التي تتجاوز عشر ثوانٍ تكون user_engagement. موقع فيه عشر مشاهدات صفحة واثنان من scroll هو موقع طبيعي.

أمران سيمنعان القائمتين من التطابق التام أبدًا. الزائر الذي لم يجب عن لافتتك يظل يرسل كل حدث، كإشارة بلا ملفات تعريف ارتباط، فيعدّه الحاوي بينما يهمله Analytics — وتعرض الصفحة الرقمين كي ترى أيهما أيّ. أما session_start و first_visit فلا يظهران في صفحة الحاوي أبدًا: لا يرسلهما المتصفح كحدثين، بل يضع علامتين على أول page_view، ويصنع Analytics الحدثين في جانبه.

فوق القائمة، تعدّ البطاقة كم حدثًا من هذه الأحداث الستة عشر وصل خلال آخر 30 يومًا، فيبرز الحدث الذي نسي موقعك إرساله.

حالتان، وصفحة الحاوي تفرّق بينهما.

إذا لم يكن الحدث في قائمة الحاوي، فموقعك لم يرسله قط. لا يستطيع الحاوي تمرير ما لم يصل. للحدث القياسي، تحقق من مفتاح القياس المحسّن في التدفق؛ ولواحد من الأحداث الستة عشر، تحقق من أن الدفع إلى dataLayer يحدث، بالاسم الصحيح، في الصفحة التي ينبغي أن يحدث فيها.

إذا كان الحدث في قائمة الحاوي لكنه ليس في Analytics، فقد وصل ومُرِّر، والمشكلة في جانب Google من الخط: معرّف قياس خاطئ، أو مرشّح بيانات، أو عقار في حساب غير الذي تنظر إليه، أو مجرد تأخير التقارير — الوقت الفعلي يعرضه خلال ثوانٍ، والتقارير القياسية قد تستغرق يومًا.

تبدأ من الصفر؟ كيف تُعدّ Google Tag Manager من جانب الخادم خطوة بخطوة.