GA4 للمتاجر: كيف تتحقق من دقة بيانات التحويل؟

قبل أن أستخدم تقارير GA4 لاتخاذ قرار عن تحسين التحويل، أختار طلبًا تجريبيًا أعرف تفاصيله وأطابق معرّفه وقيمته وعملته ووقت تسجيله مع نظام الطلبات. رقم إجمالي قريب من إجمالي المتجر لا يكفي؛ فقد يعوّض حدث مكرر طلبًا آخر لم يُسجّل.

اكتب خطة أحداث مرتبطة بالفعل

حدّد ما الذي ينبغي أن يطلق كل حدث. يُستخدم view_item عندما تظهر تفاصيل المنتج، وadd_to_cart بعد نجاح الإضافة، وbegin_checkout عند بدء مسار الدفع، وpurchase عند تحقق تعريف الشراء المعتمد في المتجر. الضغط على زر لا يعني بالضرورة أن الإضافة أو الدفع نجح.

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

راجع معرّفات المنتجات والطلبات

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

استخدم transaction_id خاصًا بالطلب ويظل ثابتًا عند إعادة تحميل صفحة النجاح. يكفي المعرّف التشغيلي للتسوية. لا ترسل الاسم أو البريد أو رقم الهاتف ضمن معاملات GA4. افحص كذلك قيمة العناصر وكمياتها والعملة التي حُسب بها المبلغ.

اختبر حالات تتجاوز الطلب الناجح

أنشئ طلب اختبار واحفظ تفاصيله، ثم افتح صفحة النجاح مرة ثانية. هل أُرسل purchase مجددًا؟ جرّب دفعًا مرفوضًا وراجع ما سُجّل في المتجر. ظهور صفحة تأكيد لا يحسم أن البوابة حصّلت المبلغ.

order = T-017نظام المتجر يحتفظ بطلب مدفوع واحد.

purchase / T-017الحدث الأول بعد نجاح الدفع.

reload / T-017تحقّق مما إذا أُرسل purchase مرة أخرى للطلب نفسه.

المعرّف في المثال افتراضي. طابق حدث الشراء في المتجر مع الحدث الذي استلمه GA4 ثم مع سجل التقرير بعد المعالجة لتحدد أين نشأ الاختلاف.

فتح الصورة بالحجم الكامل ↗

أضف سيناريو العودة المتأخرة من بوابة الدفع. وإذا كان القياس يشمل الاسترجاع، فاختبر refund مرتبطًا بالطلب الأصلي. اكتب النتيجة المتوقعة والفعلية، وميّز طلب الاختبار بوضوح في سجل التشغيل.

افهم الفرق بين نظام الطلبات والتحليلات

يسجّل المتجر الطلبات لأغراض التشغيل، بينما يقيس GA4 الأحداث التي وصلت إليه. قد تؤثر الموافقة أو ظروف الجهاز أو إغلاق المتصفح أو تأخر العودة من البوابة في وصول الحدث. راجع أيضًا المنطقة الزمنية وحالة الطلبات والفترة المستخدمة في التقرير.

ابدأ بمعرّفات يمكن تتبعها بدل مقارنة رقمين إجماليين. افصل الفرق المعروف بسبب التعريف عن خطأ الإرسال الذي يستطيع المطور إعادة إنتاجه. إذا بقيت نسبة غير قابلة للتفسير، فأظهرها كحدّ للتقرير.

ابنِ مسارًا بتعريف واحد

اختر جلسة أو مستخدمًا كوحدة للتحليل، وحدّد ترتيب الخطوات والمهلة بين البداية والنهاية. يجب أن يكون المقام واضحًا عند حساب الانتقال من خطوة إلى التي تليها.

إذا جمعت مشاهدات المنتجات والإضافات للسلة والمشتريات كأحداث مستقلة، فأنت تعرض إجماليات مفيدة للتشغيل لكنها لا تثبت أن المسار نفسه اكتمل بالترتيب. افصل الجهاز أو السوق عندما يكشف التقسيم اختلافًا مهمًا، واستخدم التعريف ذاته في المقارنتين.

طابق طلبًا واحدًا سطرًا بسطر

اكتب معرّف الطلب ووقته وحالته وقيمة العناصر، ثم افصل الشحن والضريبة والخصم. افحص ما يدخل في value وفق تعريف GA4 وقارن الحدث المقابل بسجل المتجر.

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

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

اجعل التحقق من القياس جزءًا من التسليم

احتفظ بخريطة الأحداث وطلب ناجح وآخر مرفوض، مع تفسير الفروق التي أمكن تتبعها. أعد الفحص بعد تغيير بوابة الدفع أو القالب؛ فقد يتغير التسجيل حتى إن لم يتغيّر التصميم الظاهر.

عند ظهور فرق جديد، ابدأ بالمعرّف والقيمة والعملة قبل تحليل تسرب Checkout أو ترتيب فرضيات CRO. هذه المطابقة تساعد على معرفة هل تغيّر سلوك العميل بالفعل أم تغيّرت طريقة تسجيله.