مثال توضيحي
حدد الفجوة بين الطلب والحدث
في المثال سُجل الطلب ويظهر GA4 على صفحة عامة، لكن حدث الشراء لم يُفحص بعد.
المتجر
الطلب التجريبي محفوظ.
الصفحة العامة
يظهر وسم GA4.
الوجهة
استلام حدث purchase نفسه غير مؤكد.
أُعد لشرح الخطوات، وليس نتيجة من متجر أو حساب Google حقيقي.
الخطوة التالية: حدد طريقة الربط التي ترسل purchase، ثم تابع الإجراء التجريبي إلى موقع GA4 المقصود. الملاحظتان الأوليان لا تؤكدان وصول الشراء.
١. حدد السجل الناقص
اختر بيئة وطريقة اختبار مصرحًا بهما. سجل الصفحة والوقت ومعرّف القياس المتوقع الذي يبدأ بـ G- واختيار ملفات ارتباط Analytics. استخدم مرجع طلب تجريبي بلا بيانات عميل. قد تختلف جلسة مدير المتجر عن جلسة المشتري.
- الطلب موجود ولا يظهر إرسال purchase: راجع الإضافة أو الكود المسؤول عن إرسال الحدث وموعده.
- يوجد طلب إرسال ولا يظهر الحدث في الموقع الصحيح داخل GA4: قارن الوجهة وافحص جهازك في DebugView.
- الحدث موجود لكن قيمة الإيراد مختلفة: افحص بياناته قبل تكرار الطلب.
٢. اعرف أي ربط يرسل حدث الشراء
حدد طريقة إضافة GA4: إضافة Google Analytics for WooCommerce المجانية، أو إضافة أخرى، أو GTM، أو كود خاص. ارجع إلى وثائق الطريقة المستخدمة فعلًا. وجود معرّف القياس في الصفحة الرئيسية لا يحدد من يرسل purchase.
في إضافة Google Analytics for WooCommerce المجانية، يعتمد تتبع الشراء على عودة المشتري إلى صفحة الشكر أو تأكيد الطلب. هذا شرط لهذه الإضافة، ولا يصح تعميمه على كل الإضافات أو طرق الإرسال من الخادم.
٣. راجع العودة من بوابة الدفع
في مسار الاختبار المتفق عليه، سجل الصفحة التي يصل إليها المشتري بعد مغادرة بوابة الدفع. لا تكمل تجربة ستخصم مبلغًا حقيقيًا أو ترسل رسالة طلب أو تبدأ تجهيز الشحنة قبل ترتيب التعامل مع هذه الآثار.
قارن صفحة العودة بالموضع الذي يفترض أن يرسل فيه الربط حدث purchase. فتح صفحة الدفع ليس عملية شراء. كما أن فحص الصفحة الرئيسية من الخارج لا يستطيع مشاهدة تأكيد طلب خاص بعميل.
٤. تتبع الحدث إلى الوجهة المقصودة
افتح Tag Assistant على الصفحة نفسها وافحص الإجراء المتوقع. ظهور طلب في Network يدل على محاولة إرسال من المتصفح، ولا يؤكد وحده استلام الحدث. قارن الوجهة بمصدر بيانات الويب المقصود.
فعّل وضع تصحيح الأخطاء لجهاز الاختبار وابحث عن purchase في DebugView داخل موقع GA4 الصحيح. احتفظ باختيار ملفات الارتباط مع النتيجة. قد تمنع إعدادات الخصوصية أو رفض موافقة Analytics ظهور أحداث التصحيح، وقد يكون الجهاز غير مفعّل للتصحيح أصلًا. لا تلغِ شرط الموافقة كي ينجح الاختبار.
٥. قارن قيمة الشراء ومرجع الطلب
افحص transaction_id وvalue وcurrency وitems في الحدث نفسه. إذا كانت أسعار المتجر بالريال السعودي، تحقق من إرسال العملة الصحيحة بدل قيمة منسوخة من مثال إعداد. قارن البيانات بالسجل المتوقع للطلب التجريبي.
إذا ظهر الشراء مرتين، افحص طرق الربط التي أرسلته. تأكد من أن معرّف العملية يخص الطلب نفسه، وراجع طريقة معالجة التكرار في الربط المستخدم. إضافة وسم جديد قد تجعل تحديد السبب أصعب.
٦. جهز ملاحظة واضحة للمطور
اجمع وقت الاختبار والصفحة وطريقة الربط واختيار ملفات الارتباط والوجهة المتوقعة وأول موضع انقطعت فيه الأدلة. لا ترسل بيانات العميل أو رموز الدفع. قد تحتاج تقارير GA4 المعتادة إلى 24–48 ساعة للمعالجة؛ غياب صف من التقرير يختلف عن غياب الحدث من جلسة تصحيح معدة بطريقة صحيحة.
يفحص TrackCanary رموز التتبع وإشارات WooCommerce الظاهرة في الصفحات العامة. لا يدخل إلى الدفع ولا يقرأ الطلبات الخاصة ولا يؤكد استلام GA4 لحدث purchase. استخدم الفحص العام لأدلة الصفحة، وخطوات الحساب لمراجعة وصول الحدث.
المصادر
آخر تحديث: