أحداث التجارة الإلكترونية في GA4: الإعداد وكيف تتحقق منها
GA4 مثبّت، وعدد المشتريات يظهر في التقارير، ولست متأكدًا أنه يمكنك الوثوق به. التقارير تبدو معقولة، وهنا الخطر: الرقم الخاطئ الذي يبدو معقولًا نادرًا ما يُسأل عنه.
يعطيك هذا المقال الأحداث المطلوب إعدادها، وما يجب أن يحتويه حدث الشراء، وروتين اختبار ينتهي بمقارنة مع طلباتك الحقيقية.
لماذا لا يكفي أن "البيانات تظهر"
سيسجل GA4 عملية شراء بلا رقم طلب، أو بإيراد صفر، أو الطلب نفسه ثلاث مرات. لا شيء يتحول إلى الأحمر. والمعتاد أن يُثبَّت الوسم وتُرى الأحداث تصل ثم ينتقل صاحبه إلى غيره.
ما يحدث بعد ذلك صامت: الإيراد يختلف عن المتجر، والطلب نفسه يضخّم إجمالي يوم كامل، وتقارير المنتجات فارغة لأن المنتجات لم تُرسل أصلًا. تكتشف ذلك حين يقارن أحدهم GA4 بقائمة الطلبات، وغالبًا بعد أن اتُّخذت قرارات ميزانية بناءً عليه.
النموذج: أحداث ومعاملات وإثبات
فكّر في ثلاث طبقات.
الأحداث
الإجراءات التي تقيسها بالأسماء التي يتوقعها GA4
الطبقة 1المعاملات
البيانات التي يحملها كل حدث: العملة والقيمة والمنتجات
الطبقة 2الإثبات
طلب تجريبي يُقارن بالمتجر
الطبقة 3
الأحداث. توثّق Google مجموعة أحداث موصى بها للتجارة الإلكترونية. يحتاج المتجر عادة تلك التي تتبع مسار المشتري:
view_item
عُرضت صفحة منتج.
add_to_cart
أُضيف منتج إلى السلة.
begin_checkout
بدأ المشتري إتمام الطلب.
purchase
اكتمل الطلب.
- view_item
- add_to_cart
- begin_checkout
- purchase
أضف أحداثًا أخرى مثل refund أو view_item_list فقط حين ستستخدمها في تقرير.
المعاملات. اسم الحدث وحده لا يقول الكثير. يصف دليل Google لحدث الشراء ما ينبغي أن يحمله: معرّف المعاملة وقيمة وعملة وقائمة منتجات، مع الضريبة والشحن والقسيمة تفاصيل إضافية اختيارية. اعتمد تلك الصفحة مرجعًا لأن متطلبات الحقول قد تتغير.
يستحق `transaction_id` انتباهًا خاصًا فهو هوية الطلب. يذكر دليل Google أن الشراء المتكرر يحتاج معرّفًا مختلفًا، وإلا أزال Analytics التكرار. استخدم رقم طلبك الحقيقي، لا قيمة عشوائية تتغير مع كل تحميل للصفحة.
الإثبات. كل حدث يحتاج طلبًا تجريبيًا لا افتراضًا.
الإعداد عمليًا
طريقة وصول الأحداث إلى GA4 تعتمد على منظومتك. قد توفر منصة المتجر تكاملًا أصليًا. وإلا فتُدفع الأحداث إلى طبقة بيانات ويرسلها وسم GA4 في Google Tag Manager كما يشرح Google Tag Manager للمتاجر: أساسيات طبقة البيانات. أيًّا كان اختيارك التزم بطريقة واحدة، فتشغيل تكامل أصلي ووسم GTM لعملية الشراء نفسها سبب كلاسيكي لتضاعف الإيراد.
وحدد أيضًا ماذا يعني الشراء لنشاطك. في متجر بالدفع عند الاستلام الطلب المُنشأ ليس طلبًا مُسلَّمًا، فيقيس حدث الشراء النية لا الإيراد. اذكر ذلك في تقاريرك.
كيف تتحقق خطوة بخطوة
- فعّل التصحيح. تعرض DebugView في GA4 أحداث الجهاز المفعّل عليه وضع التصحيح خلال ثوانٍ. تذكر وثائق Google أنها لا تعرض الأحداث إذا كان وضع التصحيح مغلقًا، وأن ضوابط الخصوصية أو حالة موافقة غير ممنوحة قد توقف ظهور الأحداث.
- امشِ المسار. على جهاز اختبار اعرض منتجًا وأضفه إلى السلة وابدأ الدفع وأنشئ طلبًا تجريبيًا. راقب وصول كل حدث مرة واحدة.
- افتح حدث الشراء. تأكد من وجود `transaction_id` و`value` و`currency` و`items`. تأكد أن العملة رمز صحيح، والقيمة رقم، وأن قائمة المنتجات غير فارغة.
- العدّ مرة واحدة. حدّث صفحة الشكر. إن ظهر شراء ثانٍ فالدفعة تعمل عند إعادة التحميل وتحتاج حارسًا.
- راجع التقارير لاحقًا. قد تتأخر التقارير القياسية عن DebugView، فأكّد مرة أخرى بعد معالجة البيانات لا في الدقيقة نفسها.
188 من 200 طلب تساوي 94%. و27,900 من 30,000 ريال تساوي 93%.
مثال محسوب
افترض أن متجرك سجل في أسبوع 200 طلب بقيمة 30,000 ريال، بمتوسط طلب 150 ريالًا. ويعرض GA4 عدد 188 عملية شراء وإيرادًا 27,900 ريال. هذا 94% من الطلبات و93% من الإيراد.
فجوة بهذا الحجم ليست خطأ تلقائيًا، فاختيارات الموافقة والمانعات والطلبات المُدخلة يدويًا قد تفسر الأحداث الناقصة. الأسئلة المفيدة تخص النمط: هل الفجوة مستقرة من أسبوع إلى آخر؟ وهل يعرض GA4 طلبات أكثر من المتجر؟ الثاني هو علامة الخطر، لأن المتصفحات لا تخترع طلبات بل تكررها فقط. ومتوسط الإيراد لكل شراء في GA4 هنا 27,900 / 188 أي نحو 148.4 ريال، قريب من 150 في المتجر، وهذا يوحي أن القيم تُرسل صحيحة وإن نقصت بعض الطلبات.
المقايضات ومتى تتغير التوصية
- حجم منخفض. مع طلبات قليلة جدًا أسبوعيًا تتأرجح النسب كثيرًا. قارن الإجماليات على نافذة أطول.
- طرق دفع متعددة. إن وصل الطلب المدفوع مسبقًا والطلب بالدفع عند الاستلام إلى صفحة الشكر بطريقتين مختلفتين، فافحص كل مسار على حدة.
- بيانات الخادم أو التطبيق. إن أرسلت أحداثًا من خادمك أيضًا فتحتاج معرّفًا متفقًا عليه كي لا يُحتسب الطلب مرتين.
- الموافقة. ما يحق لك جمعه يتوقف على جمهورك والقواعد المنطبقة. تأكد لدى الجهة المختصة أو مستشارك بدل الافتراض.
ما لا يخبرك به GA4
حتى الإعداد المثالي يقيس ما تسمح به المتصفحات والموافقة. لن يطابق متجرك تمامًا، ولن يخبرك أي إعلان تسبب بالطلب. وإسناد القنوات يعتمد على وسوم حملات متسقة، انظر معاملات UTM: نظام تسمية يحافظ على نظافة الإسناد. ولمعرفة لماذا نادرًا ما تتفق أرقام المنصات مع المتجر اقرأ لماذا تختلف مبيعات متجرك عن نتائج Meta وGoogle Ads؟.
الخطوة التالية
أنشئ اليوم طلبًا تجريبيًا واحدًا وافتح حدث الشراء في DebugView. إن غاب أي حقل من الأربعة أو ظهر الطلب مرتين فأصلح ذلك قبل قرار الميزانية التالي. وإن فضّلت أن تُبنى مجموعة الأحداث كاملة وتُختبر مقابل طلباتك الحقيقية فخدمة إعداد التتبع تغطي ذلك.