الإجابة القصيرة: لديك سقف قدره 30 حدثاً رئيسياً لكل موقع في Google Analytics 4، وأغلب الأنشطة لا تحتاج أكثر من خمسة أو ستة منها. الباقي يُقاس بلا تدخّل منك أصلاً، أو لا يغيّر قراراً واحداً مهما راقبته.
هذا المقال لصاحب متجر أو شركة خدمات أو عيادة ركّب GA4 على موقعه، ثم فتح اللوحة فوجد عشرات التقارير ولم يعرف على أي رقم يبني قراره. السؤال العملي هنا هو ماذا تقيس في Google Analytics 4 حتى تتخذ قراراً. لن نمرّ على شاشات الواجهة واحدة واحدة؛ سنبدأ من الطرف الآخر: ما القرار الذي تنوي اتخاذه هذا الشهر، وما الحدث الذي يجعلك قادراً على اتخاذه؟ كل رقم وقاعدة في المقال مأخوذ من توثيق Google نفسه، والاطّلاع عليه تم في 20 سبتمبر 2026.
ابدأ من القرار، لا من التقرير
القياس الذي لا يغيّر سلوكك تكلفة بلا عائد. قبل أن تطلب من مطوّر إعداد أي شيء، اكتب القرارات الثلاثة أو الأربعة التي تتخذها فعلاً خلال ربع السنة، ثم اسأل: ما الرقم الذي يحسم كل واحد منها؟
| القرار | السؤال الذي يحسمه | ما يجب أن يكون مُقاساً |
|---|---|---|
| إيقاف حملة أو الاستمرار فيها | كم عميلاً محتملاً أو طلباً جاءت به هذه القناة، لا كم زيارة | حدث رئيسي يمثّل نهاية المسار (purchase أو generate_lead) مع قيمة مالية |
| تعديل صفحة أو إعادة كتابتها | أين يتوقف الزائر بالضبط داخل المسار | أحداث المراحل الوسيطة (view_item، begin_checkout) |
| زيادة ميزانية قناة | هل القناة تجلب من يصل إلى نهاية المسار أم من يغادر بسرعة | الحدث الرئيسي نفسه مقسوماً على مصدر الزيارة |
| إصلاح منتج أو خدمة | كم طلباً يُلغى أو يُرتجع بعد إتمامه | حدث refund |
لاحظ أن العمود الأخير قصير. أربعة قرارات كبرى تحتاج عملياً أربعة إلى ستة أحداث. هذه هي قائمتك، وما عداها إضافة لاحقة عندما يظهر سؤال جديد لا تستطيع الإجابة عنه.
ثلاثون: السقف الذي يحكم اختياراتك
صفحة حدود الضبط الرسمية تضع حدوداً لكل موقع (property)، وأهمها هنا:
- 30 حدثاً رئيسياً لكل موقع. يمكنك أرشفة حدث قديم لتحرير مكان، لكن العدد المتاح في أي لحظة ثلاثون.
- 50 بُعداً مخصّصاً على مستوى الحدث، و25 على مستوى المستخدم.
- 100 جمهور (audience)، و50 مقارنة محفوظة.
في المقابل، حدود جمع البيانات تقول شيئاً يخالف ما تكرره أدلة كثيرة: لا يوجد حدّ لعدد الأحداث المختلفة الأسماء في بثّ الويب. حدّ الخمسمئة الذي تقرأ عنه يخص بثّ التطبيقات، ويُحسب لكل مستخدم تطبيق. كذلك لا تُحتسب الأحداث المجمّعة تلقائياً ولا أحداث القياس المحسَّن ضمن هذه الحدود.
الخلاصة العملية: جمع الأحداث رخيص، وتعليمها كأحداث رئيسية مكلف. الثلاثون هي الميزانية الحقيقية، وكل حدث تُعلّمه بلا سبب يأخذ مقعداً من حدث ستحتاجه بعد ستة أشهر.
ما يُقاس قبل أن تطلب من أحد شيئاً
قبل أن تدفع مقابل «إعداد التتبّع»، اعرف ما يعمل بالفعل. الأحداث التالية تأتي من القياس المحسَّن وتُفعَّل من إعدادات بثّ البيانات بلا سطر كود واحد:
| الحدث | متى يُطلق تحديداً |
|---|---|
| page_view | مع كل تحميل صفحة أو تغيير في سجلّ المتصفّح. يُجمع تلقائياً ولا يمكن إيقافه |
| scroll | أول مرة يصل فيها الزائر إلى عمق 90% من الصفحة |
| click (صادرة) | عند النقر على رابط يقود خارج نطاقك إلى موقع آخر، مع تسجيل نطاق الرابط وعنوانه |
| view_search_results | عند وجود أحد خمسة معاملات في الرابط: q أو s أو search أو query أو keyword |
| file_download | عند النقر على رابط ملف بامتداد معروف مثل pdf أو docx أو xlsx أو zip أو mp4 |
| video_start وvideo_progress وvideo_complete | لفيديوهات YouTube المضمّنة التي فُعّلت فيها واجهة JS، والتقدّم يُسجَّل عند 10% و25% و50% و75% |
| form_start وform_submit | أول تفاعل مع نموذج في الجلسة، ثم إرساله |
نقطتان تستحقان الانتباه قبل أن تبني قراراً على هذه الأحداث.
الأولى أن معاملات النماذج لا تظهر في تقاريرك إلا إذا أنشأت لها أبعاداً مخصّصة. ستعرف أن ثلاثين شخصاً أرسلوا نموذجاً، لكنك لن تعرف أي نموذج أرسلوه ما لم تسجّل form_id أو form_name كبُعد.
الثانية أن معاملات form_start وform_submit مأخوذة من خصائص عنصر <form> في الصفحة نفسها: المعرّف والاسم والوجهة ونص زر الإرسال. إذا كان نموذجك مبنياً بطريقة لا تمرّ بإرسال عنصر <form> تقليدي، تحقّق في DebugView من وصول الحدث فعلاً قبل أن تعلّمه حدثاً رئيسياً. البديل الموثّق أبسط: أنشئ حدثاً جديداً من page_view مشروطاً بعنوان صفحة الشكر، وسمّه thank_you، ثم علّمه حدثاً رئيسياً. لا كود، ويقيس ما تريد قياسه فعلاً: من وصل إلى نهاية النموذج.
تحذير مرفق بالطريقة نفسها في التوثيق: لا تعدّل حدث page_view نفسه، لأنه سيتوقف عن جمع المشاهدات لبقية صفحات الموقع.
الحدث الرئيسي ليس الإحالة الناجحة
هذه أكثر نقطة تربك القارئ العربي، لأن الواجهة العربية تستخدم المصطلحين معاً وتعنيان شيئين مختلفين.
بعد توحيد التعريفات بين Google Analytics و«إعلانات Google»، صار الحدث الرئيسي هو الحدث الذي يقيس إجراءً مهماً لنجاح نشاطك، وتستخدم بياناته داخل Analytics لفهم سلوك الزوار وتحسين الموقع. أما الإحالة الناجحة فتُنشأ من حدث رئيسي لتقييم الحملات الإعلانية وضبط المزايدة عليها، ورقمها موحّد بين المنصتين. المسار كما تكتبه صفحة المقارنة الرسمية: حدث ← حدث رئيسي ← إحالة ناجحة.
ثلاث نتائج عملية لهذا التقسيم:
- لإنشاء إحالة ناجحة تحتاج حساب «إعلانات Google» مرتبطاً. إن لم تكن تعلن، تكفيك الأحداث الرئيسية.
- إحالات «إعلانات Google» الناجحة لا تظهر في تقارير Analytics العادية، بل في قسم «الإعلانات». إذا بحثت عنها في تقرير اكتساب الزيارات ولم تجدها فالسبب هذا، لا خطأ في الإعداد.
- إذا أنشأت إحالة ناجحة من حدث غير رئيسي، يصنَّف ذلك الحدث تلقائياً حدثاً رئيسياً، ويأكل مقعداً من الثلاثين دون أن تنتبه.
القائمة القصيرة بحسب نوع نشاطك
الأحداث الموصى بها من Google لا تُرسَل تلقائياً لأنها تحتاج سياقاً لا يعرفه المتصفّح: قيمة الطلب، رقمه، محتوياته. أي أنها تحتاج عملاً من مطوّر أو من منصة المتجر. هذه القوائم تكفي معظم الأنشطة.
متجر إلكتروني
| الحدث | لماذا يستحق مقعداً |
|---|---|
| purchase | الرقم الذي تُقاس به كل قناة. يُرسل مع value وcurrency ومصفوفة items |
| begin_checkout | الفارق بينه وبين purchase هو تسريب صفحة الدفع، وهو أسرع مكان للإصلاح |
| add_to_cart | يفصل «لم يعجبه المنتج» عن «تعثّر في الدفع» |
| refund | ضروري في سوق الدفع عند الاستلام: purchase يُسجَّل لحظة إتمام الطلب على الموقع، والتحصيل يأتي لاحقاً، والمرتجع حدث منفصل يجب إرساله وإلا بقيت إيراداتك مضخّمة |
| view_item | للمقارنة بين المنتجات، إن كان الكتالوج كبيراً |
مصفوفة items تقبل حتى 200 عنصر في الحدث الواحد، وcurrency تُكتب بصيغة ISO 4217 مثل EGP أو SAR أو AED.
شركة خدمات أو عيادة أو مكتب
| الحدث | لماذا يستحق مقعداً |
|---|---|
| generate_lead | إرسال نموذج أو طلب معلومات: بداية المسار |
| qualify_lead | العميل المحتمل الذي تبيّن أنه مناسب فعلاً |
| close_convert_lead | من تحوّل إلى عميل دافع |
| thank_you أو ما يعادله | إن كان نموذجك لا يُطلق form_submit بثقة |
تطبيق أو منصة اشتراك
sign_up لإنشاء الحساب، وlogin لقياس العودة، وpurchase للاشتراك المدفوع. ثلاثة أحداث تغطي أغلب القرارات في السنة الأولى.
حين يُغلق البيع على واتساب أو بالهاتف
هذه حالة أغلب الأنشطة في مصر والخليج، وهي التي تُسقطها الأدلة المكتوبة لأسواق أخرى. الموقع لا يبيع؛ الموقع يولّد محادثة، والصفقة تُغلق في محادثة واتساب أو مكالمة أو زيارة للفرع.
فريق سنابل يوفر لك دراسة فنية مخصصة لتحديد التقنيات المناسبة وتكلفة التنفيذ الدقيقة.
ابدأ بنقرة واتساب. إذا كان الزر في موقعك رابطاً عادياً يقود إلى نطاق خارجي، فحدث النقرة الصادرة يلتقطه بالفعل ويسجّل نطاق الرابط. لا تحتاج مطوّراً: أنشئ حدثاً جديداً من حدث click مشروطاً بنطاق الرابط، سمّه باسم واضح، وعلّمه حدثاً رئيسياً. تحقّق أولاً في تقرير الوقت الفعلي أن الحدث يصل بالنطاق الصحيح.
نقرة الاتصال حالة أخرى. التوثيق يعرّف النقرة الصادرة بأنها رابط «يقود خارج النطاق الحالي إلى موقع آخر»، ولا يذكر روابط tel:. لا تفترض أنها مقاسة. أرسل لها حدثاً خاصاً وتأكّد من وصوله في DebugView قبل أن تبني عليه أي قرار.
بقية المسار تحتاج إرسالاً صريحاً. تنشر Google أحداثاً موصى بها لمسار العملاء المحتملين مصمّمة تحديداً للحالات التي تتم فيها الإحالات الناجحة خارج الإنترنت: generate_lead ثم qualify_lead ثم working_lead ثم close_convert_lead، ومعها disqualify_lead وclose_unconvert_lead لمن خرج من المسار. إرسال هذه الأحداث يملأ تقرير اكتساب العملاء المحتملين، الذي يعرض العملاء المحتملين الجدد والمؤهّلين والمحوَّلين موزّعين على القنوات.
هنا تظهر القيمة الحقيقية: القناة التي تجلب أكبر عدد من النماذج ليست بالضرورة القناة التي تجلب أكبر عدد من العملاء الدافعين. بدون qualify_lead وclose_convert_lead لا يظهر هذا الفرق في تقاريرك، فتزيد ميزانية القناة الخطأ وأنت تحسبها الأفضل.
وكيف يصل خبر الإغلاق من نظامك الداخلي إلى Analytics؟ عبر استيراد البيانات، الذي يقبل صراحةً أحداثاً لم تُلتقط لحظياً، بما فيها الآتية من مصادر بلا اتصال بالإنترنت. الأداة نفسها تستورد بيانات حملات الشبكات الإعلانية غير التابعة لـ Google (النقرات والتكلفة ومرّات الظهور)، وهي الطريقة الموثّقة لإدخال إنفاق فيسبوك أو تيك توك في الصورة. حدّ الرفع 120 عملية يومياً لكل موقع، وحجم المصدر الواحد حتى غيغابايت.
انتبه إلى فرق يهمّك: بيانات المستخدمين والأحداث تُدمج وقت الجمع والمعالجة، أما بيانات الحملات والسلع فتُدمج وقت الاستعلام، ومعنى ذلك أن حذف الملف يُفقدك الدمج.
الأرقام التي لا تستحق دقيقة من وقتك
تقرير الوقت الفعلي كمؤشر أداء
معالجة البيانات قد تستغرق من 24 إلى 48 ساعة، وقد تتغيّر أرقام تقاريرك خلال هذه المدة. للمواقع القياسية تصل بيانات اليوم خلال ساعتين إلى ست ساعات، والبيانات اليومية المكتملة خلال 12 ساعة. الحكم على حملة أطلقتها صباحاً بأرقام الظهيرة حكم على بيانات ناقصة بحكم طريقة المعالجة نفسها.
معدل الارتداد كدرجة جودة للصفحة
تعريف الارتداد في GA4 ميكانيكي بحت: الجلسة المتفاعلة هي التي تتجاوز عشر ثوانٍ، أو يقع فيها حدث رئيسي، أو تتضمّن مشاهدتين فأكثر. ومعدل الارتداد هو عكس معدل التفاعل. صفحة تجيب عن سؤال الزائر في ثماني ثوانٍ ثم يغادر راضياً تُحسب ارتداداً. استخدمه للمقارنة بين قنوات الزيارة، لا كدرجة جودة لصفحاتك. ولاحظ أن first_visit وsession_start مستثناة من حساب الجلسات المتفاعلة حتى لو علّمتها أحداثاً رئيسية.
بُعد مخصّص لكل شيء
أي بُعد تتجاوز قيمه 500 قيمة يُعدّ عالي التعدّدية، ويزيد احتمال أن يجمع تقريرك القيم الأقل شيوعاً تحت صف (other). إذا أنشأت بُعداً لرقم الطلب أو لمعرّف المستخدم، فأنت تصنع المشكلة بيدك؛ التوثيق يوجّه صراحة إلى استخدام ميزة User-ID بدلاً من بُعد مخصّص يميّز كل مستخدم.
التقارير الديموغرافية على زيارات قليلة
عتبات البيانات نظامية ولا يمكن تعديلها، وتُطبَّق على البيانات الديموغرافية وعبارات البحث لمنع الاستدلال على هوية الأفراد. إن رأيت صفوفاً فارغة فالسبب غالباً قلّة المستخدمين في النطاق الزمني المختار، وتوسيع النطاق يحلّ جزءاً من المشكلة.
مقارنة رقم GA4 برقم منصة الإعلان
المنصتان تقيسان بنماذج مختلفة. GA4 يتيح ثلاثة نماذج لتحديد المصدر: المستند إلى البيانات، وآخر نقرة مدفوعة وعضوية، وآخر نقرة على قنوات Google المدفوعة. النماذج الأربعة القديمة (النقرة الأولى والخطي والتناقص الزمني والمستند إلى الموضع) أُلغيت منذ نوفمبر 2023. وكل النماذج تستبعد الزيارة المباشرة من نسبة المساهمة إلا إذا كان المسار كله مباشراً. الفارق بين الرقمين متوقّع، والقرار السليم أن تختار مصدراً واحداً للحقيقة وتقارن به عبر الزمن.
زياراتك أنت وفريقك
ثلاثة أو أربعة أشخاص يفتحون الموقع يومياً يكفون لتشويه أرقام نشاط صغير. فلاتر البيانات تستبعد زيارات المطوّرين والزيارات الداخلية بعنوان IP. أنشئها مبكراً، لأنها تعمل من لحظة الإنشاء فصاعداً ولا تمسّ البيانات السابقة، والبيانات التي تستبعدها لا تُعالَج ولا تعود متاحة إطلاقاً.
من الرقم إلى القرار: ثلاث قراءات تكفي
بعد أن تستقرّ الأحداث، لا تحتاج أكثر من ثلاث قراءات شهرية.
ابحث أولاً عن قناة تجلب زيارات ولا تجلب أحداثاً رئيسية. افتح تقرير اكتساب الزيارات وأضف عمود الأحداث الرئيسية. إن كانت قناة ترسل زيارات معقولة وحدثاً رئيسياً واحداً أو صفراً، فالمشكلة إما في الاستهداف وإما في الصفحة التي تهبط عليها الزيارة. ابدأ بالصفحة لأنها أرخص وأسرع، وراجع كيف تُبنى صفحة هبوط تحوّل الزائر قبل أن توقف الحملة.
ثم قارن كل مرحلة بالمرحلة التي تليها. مثال افتراضي لمتجر: 1,000 حدث add_to_cart في الشهر، و420 حدث begin_checkout، و96 حدث purchase. الفجوة الأولى طبيعية إلى حدّ بعيد؛ الفجوة الثانية تعني أن أكثر من ثلاثة أرباع من بدأوا الدفع لم يكملوه، وهذا سبب كافٍ لمراجعة خطوات الدفع نفسها قبل إنفاق جنيه إضافي على الإعلانات. نقاط البدء العملية في تحسين معدل التحويل في المتجر الإلكتروني.
أخيراً، ضع التكلفة أمام النتيجة لكل قناة. الأحداث الرئيسية موزّعة على القنوات تعطيك البسط، والتكلفة تأتي من ربط «إعلانات Google» أو من استيراد بيانات حملات المنصات الأخرى. القسمة هي تكلفة اكتساب العميل، وطريقة حسابها الصحيحة وما يجب إدخاله فيها من رواتب واشتراكات مشروحة في حساب تكلفة اكتساب العميل. بغير هذا الربط تبقى أرقام GA4 مؤشرات سلوك لا أداة قرار مالي.
خمس عمليات تحقق قبل أن تصدّق الرقم
- أضف قيمة مالية للأحداث الرئيسية. المعاملتان value وcurrency تجعلان الحدث قابلاً للمقارنة بالتكلفة. وإذا كانت العملة ناقصة أو بصيغة غير صالحة، يُسجَّل الحدث بعدده الصحيح لكنه لا يُرسل إلى «إعلانات Google».
- راجع طول اسم الحدث: الحد 40 حرفاً. الاسم الأطول لن يُسجَّل كحدث رئيسي، لأن اللاحقة التي تضيفها Analytics لن تجد مكاناً.
- اضبط مدة الاحتفاظ. الخياران شهران أو 14 شهراً. الإعداد يؤثر على الاستكشافات وتقارير المسار لا على التقارير المجمّعة، وزيادته تُطبَّق على بيانات جُمعت سابقاً ولم تُحذف بعد. غيّره اليوم لا بعد سنة.
- راجع طريقة احتساب الحدث الرئيسي. «مرّة في كل حدث» تحسب كل مرة يقع فيها الحدث، و«مرّة في كل جلسة» تحسبه واحداً مهما تكرّر داخل الجلسة. خمس عمليات شراء في جلسة واحدة تصير خمساً في الأولى وواحدة في الثانية. الأحداث التي وُرِّثت من أهداف Universal Analytics تأتي افتراضياً على «مرّة في كل جلسة»، وتغيير الإعداد يسري على البيانات القادمة فقط.
- افحص كل حدث في DebugView قبل الاعتماد عليه. أي حدث لم ترَه يصل بعينك في DebugView أو في تقرير الوقت الفعلي هو افتراض، لا قياس.
خلاصة تنفيذية
اختر ثلاثة إلى ستة أحداث تمثّل نهاية مسار حقيقي في نشاطك، وأضف لها قيمة مالية، وأوصِل خبر الإغلاق من نظامك الداخلي إذا كان البيع يُغلق خارج الموقع، ثم استبعد زيارات فريقك. بعد ذلك اقرأ ثلاثة أرقام شهرياً بدل ثلاثين. ما تبقّى من GA4 مفيد عندما يظهر سؤال محدّد لا تستطيع الإجابة عنه، وليس قبل ذلك.
إذا كان موقعك أو متجرك لا يرسل اليوم الأحداث التي تبني عليها قرارك، أو كان الإغلاق يحدث في نظام لا يتحدّث مع أدوات القياس، أرسل فكرتك إلى فريق سنابل. ترجع إليك خطة مبدئية ومعها تقدير للوقت والتكلفة في غضون يوم واحد، بلا مقابل وبلا التزام.
أسئلة شائعة
هل أحتاج Google Tag Manager لإعداد الأحداث الرئيسية؟
ليس دائماً. أحداث القياس المحسَّن تُفعَّل من إعدادات بثّ البيانات مباشرة، ويمكن إنشاء حدث جديد من حدث قائم داخل واجهة Analytics بشرط على عنوان الصفحة أو على معاملات الحدث، ثم تعليمه حدثاً رئيسياً. تحتاج كوداً أو أداة وسم عندما تريد إرسال بيانات لا يعرفها المتصفّح، مثل قيمة الطلب ورقمه ومحتوياته.
كم حدثاً رئيسياً يجب أن أُعدّه في البداية؟
ابدأ بحدث واحد يمثّل نهاية المسار في نشاطك (purchase أو generate_lead)، وأضف حدثاً أو اثنين للمرحلة السابقة له. الحد الأقصى ثلاثون لكل موقع، لكن العدد المفيد في السنة الأولى نادراً ما يتجاوز ستة. أضف حدثاً جديداً عندما يظهر سؤال لا تستطيع الإجابة عنه بما لديك.
لماذا تختلف أرقام GA4 عن أرقام منصة الإعلانات؟
لأن كل منصة تنسب الإحالة الناجحة بنموذج مختلف. GA4 يستبعد الزيارة المباشرة من نسبة المساهمة إلا إذا كان المسار كله مباشراً، ويتيح ثلاثة نماذج فقط بعد إلغاء النماذج الأربعة القديمة في نوفمبر 2023، ولكل نموذج نافذة زمنية بأثر رجعي قابلة للضبط. الفارق متوقّع؛ المهم أن تختار مرجعاً واحداً وتلتزم به.
لماذا تتغيّر أرقام الأمس عندما أفتح التقرير اليوم؟
لأن المعالجة قد تستغرق من 24 إلى 48 ساعة، وتتغيّر الأرقام خلالها. البيانات خلال اليوم تصل للمواقع القياسية في ساعتين إلى ست ساعات، والبيانات اليومية الكاملة خلال 12 ساعة. اقرأ أرقام أي يوم بعد مرور يومين عليه.
هل يقيس GA4 نقرات زر واتساب تلقائياً؟
إذا كان الزر رابطاً عادياً يقود إلى نطاق خارجي، فحدث النقرة الصادرة في القياس المحسَّن يلتقطه ويسجّل نطاق الرابط، ويمكنك بناء حدث رئيسي عليه بلا كود. أما روابط الاتصال tel: فالتوثيق لا يذكرها ضمن النقرات الصادرة، فلا تفترض أنها مقاسة وتحقّق بنفسك في DebugView.
المصادر
جميع المراجع من مركز مساعدة Google وموقع Google for Developers، واطُّلع عليها جميعاً في 20 سبتمبر 2026.
- حدود الضبط في Google Analytics 4
- حدود جمع البيانات
- أحداث القياس المحسَّن
- الأحداث الموصى بها
- الإحالات الناجحة مقابل الأحداث الرئيسية
- إنشاء الأحداث الرئيسية وتعديلها
- تقرير اكتساب العملاء المحتملين
- لمحة عن استيراد البيانات
- معدل التفاعل ومعدل الارتداد
- حداثة البيانات
- الاحتفاظ بالبيانات
- لمحة عن صف (other)
- لمحة عن عتبات البيانات
- فلاتر البيانات
- بدء استخدام تحديد المصدر
- تغيير طريقة احتساب الأحداث الرئيسية
- قياس التجارة الإلكترونية

