حل تكرار عمليات الشراء في GA4 عند تحديث صفحة الشكر

الإجابة العملية

إعادة فتح صفحة تأكيد الطلب قد تعيد إرسال حدث الشراء إذا كان التنفيذ يعتمد على تحميل الصفحة فقط. الحل يبدأ بتعريف معرّف ثابت وفريد لكل طلب، ثم تمريره في transaction_id من مصدر الطلب الحقيقي. في تدفقات الويب يستخدم Analytics هذا المعرف للمساعدة في إزالة تكرار الشراء؛ لذلك لا يصلح رقم عشوائي يتغير مع كل زيارة، ولا قيمة موحدة لجميع العملاء. توجد أيضًا حالات يكون فيها الحدث نفسه صادرًا من إضافة المنصة ومن حاوية Tag Manager معًا. هنا لا يكفي الاعتماد على إزالة التكرار؛ الأفضل تعيين تنفيذ واحد مسؤول عن الإرسال. افصل بين رقم الطلب ومعرّف العميل، ولا تضمّن الاسم أو البريد في المعاملة. توثيق مصدر المعرف يساعد عند معالجة الاسترداد لاحقًا ويمنع مشكلة معاكسة، وهي اختفاء مشتريات صحيحة لأن الطلبات المختلفة حصلت على القيمة نفسها.

خطوات التطبيق

1. افحص صفحة الشكر مع طلبين مختلفين، وحدد جميع إضافات التتبع والحاويات التي ترسل purchase بدل الاكتفاء بالنظر إلى عدد الوسوم.
2. استخرج معرّفًا ثابتًا من سجل الطلب ومرره في transaction_id، وأوقف المسار الزائد بعد التأكد من أن المسار المعتمد يرسل المنتجات والقيمة.
3. أعد تحميل تأكيد الطلب الأول ثم افتح الطلب الثاني، واختبر أن إعادة الزيارة لا تغير المعرف بينما المعاملة الجديدة تحمل معرفًا آخر.

مثال تطبيقي افتراضي

في مثال افتراضي، يحمل طلب عطور رقم TEST-204، لكن الإضافة ترسل توقيت الصفحة بدل الرقم. كل تحديث يبدو كمعاملة جديدة. يُستبدل التوقيت برقم الطلب المستقر، ويُراجع وسم ثانٍ في GTM كان يرسل الحدث ذاته. يظل الاختبار داخل سجلات تجريبية، ولا يُنسب نجاح أو مقدار نمو إلى متجر حقيقي.

أخطاء تستحق الانتباه

• إرسال transaction_id فارغ أو إعادة استخدام القيمة نفسها لطلبات مختلفة قد يؤدي إلى تقليل عدد المشتريات المسجلة بدل إصلاح التكرار.
• إيقاف أي وسم بشكل عشوائي قد يحذف البيانات الصحيحة؛ حدّد التنفيذ المعتمد ومعلمات التجارة الإلكترونية قبل إزالة التنفيذ الآخر.

كيف تتحقق من التنفيذ؟

• تحقق في طلبات الشبكة من ثبات transaction_id عند إعادة زيارة الطلب ومن اختلافه بين طلبين فعليين مختلفين.
• طابق معرّف المعاملة مع سجل الطلب، وتأكد من خلوه من معلومات تعريف العميل الشخصية ومن جاهزيته لربط الاسترداد بالشراء.