قم بمطابقة مشتريات GA4 مع جدول الطلبات الخاص بك قبل أن تثق بنتيجة الاختبار.

يُظهر تقرير عقارك في GA4 عدد 4,180 عملية شراء الشهر الماضي، بينما يُشير جدول الطلبات إلى 4,690 عملية شراء. عند سؤالك عن الرقم الصحيح، ستكون الإجابة الصادقة هي لا هذا ولا ذاك، إلى أن تُحدد مصير الطلبات المفقودة البالغ عددها 510. هذه ليست مشكلة تنظيم. فكل نتيجة تجربة وكل درجة أولوية تُنتجها تُحسب بناءً على رقم خاطئ بمقدار غير معروف وفي اتجاه غير معروف.

تتعامل جوجل مع شريحة كبيرة غير مقاسة على أنها طبيعية: لا يتم تشغيل نمذجة السلوك لوضع الموافقة إلا بعد تسجيل العقار ما لا يقل عن 1,000 فعالية يوميًا مع analytics_storage='denied' لمدة 7 أيام على الأقلأما البيانات المفقودة فتبقى مفقودة.

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

ما الذي تقيسه عملية مطابقة المشتريات فعليًا؟

لا يقتصر التوفيق بين البيانات على مجرد "مطابقة الأرقام". فهي لن تتطابق أبدًا، والفريق الذي يُجبرها على ذلك غالبًا ما يكون قد ارتكب خطأً أسوأ من ترك الفجوة دون تغيير. يجيب التوفيق بين البيانات على ثلاثة أسئلة: ما حجم الفجوة؟ ما هي الآليات المُسببة لها؟ وما مقدار ما يمكن استعادته وما هي تكلفته؟ نجري هذا التوفيق قبل أي تجربة، لأن الاختبار الذي يُقاس على حدث تحويل يُسقط نسبة غير معروفة من الطلبات دون علم المستخدم ليس تجربة حقيقية.

الخطوة 1: استخرج جدولين يمكن ربطهما باستخدام رقم الطلب

أنت بحاجة إلى صف واحد لكل طلب، من كلا النظامين، لنفس النطاق الزمني، مع مفتاح موجود على كلا الجانبين.

• الخلفية: معرف الطلب، والطابع الزمني للإنشاء في المنطقة الزمنية لإعداد التقارير الخاصة بالعقار، وقيمة الطلب على نفس أساس الضريبة والشحن الذي قمت بتكوينه في GA4، وطريقة الدفع، والجهاز، والبلد، والحالة.
• GA4: تصدير BigQuery، وليس واجهة المستخدم. استعلام purchase الأحداث مع ecommerce.transaction_id, event_timestamp, ecommerce.purchase_revenue، فئة الجهاز، ومصدر حركة البيانات.

استخدم BigQuery بوعي. تظهر البيانات المُنمذجة من وضع الموافقة في التقارير القياسية لـ GA4 وبعض الاستكشافات، لكن جوجل تُصرّح بأنها لست في عملية تصدير البيانات من BigQuery، يمكنك استخدام شرائح الجمهور، أو مستكشف المستخدمين، أو مجموعات العملاء، أو استكشافات الاحتفاظ بالعملاء، أو المقاييس التنبؤية. قارن واجهة المستخدم بجدول الطلبات لديك، وستجد أنك تقارن تقديرًا بحقيقة.

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

الخطوة الثانية: عبّر عن الفجوة بثلاث طرق، وليس بطريقة واحدة.

نسبة مئوية شهرية واحدة تخفي كل شيء. احسب النسب الثلاث جميعها:

1. الفجوة بين عدد الطلبات وعددها: (طلبات النظام الخلفي مطروحًا منها مشتريات GA4 المطابقة) / طلبات النظام الخلفي. هذا يعزل فقدان التتبع.
2. فجوة الإيرادات: ينطبق الحساب نفسه على القيمة. إذا كانت فجوة العدد 3% وفجوة الإيرادات 11%، فلا توجد لديك مشكلة في التتبع، بل لديك مشكلة في تعريف القيمة (الضرائب، الشحن، الخصومات، العملة، بطاقات الهدايا).
3. التباين اليومي للفجوة: ارسم بيانيًا الفجوة اليومية بين عدد الطلبات وعددها. يشير الخط المستقيم إلى سبب هيكلي مثل نقص الموافقة أو وجود عوائق. أما الارتفاعات المفاجئة فتشير إلى عمليات نشر أو حملات مكثفة أو مشكلة في مزود خدمة الدفع.

الخطوة 3: تقسيم الفجوة إلى أسباب محددة

اتبع هذا الجدول. لكل سبب اختبار يمكنه تأكيده أو استبعاده في أقل من ساعة.

اثنان يستحقان عناية خاصة. transaction_id تعمل خاصية إزالة البيانات المكررة على تدفقات الويب فقط، وليس على تدفقات التطبيقات، وتحذر جوجل من أن إرسال سلسلة نصية فارغة يجعل خدمة إزالة البيانات المكررة في تحليلات جوجل تعمل. كل حدث شراء يتم تنفيذه transaction_id=''قد يتسبب هذا الخطأ البرمجي في إضاعة معظم اليوم. إضافةً إلى ذلك، فإن قائمة الإحالات غير المرغوب فيها محدودة بـ 50 نطاقًا لكل تدفق بيانات، وهو ما يمثل مشكلة إذا كنت تستخدم العديد من جهات الاستحواذ والمحافظ وصفحات البنوك.

[البيانات الداخلية المطلوبة: التوزيع الملحوظ لهذه الأسباب التسعة عبر مشاركات المصالحة في سويتاس، حتى يتمكن القراء من معرفة أيها يهيمن عادةً.]

الخطوة الرابعة: حدد مستوى تسامح يمكنك الدفاع عنه

لا تنشر جوجل أي نسبة مقبولة للاختلاف، كما أن نسبة "5% مقبولة" الشائعة لا تظهر في أي من وثائق جوجل التي عثرنا عليها. حدد نسبتك الخاصة، مع مراعاة التجزئة بدلاً من الاعتماد على النسبة وحدها.

هذه هي حدود التشغيل الخاصة بنا، وليست معيارًا صناعيًا. والنقطة الأساسية هي: أن نسبة 3% غير المفسرة أسوأ من نسبة 8% المفسرة.

الخطوة 5: قم بالإصلاح بالترتيب الذي يحقق أكبر عدد من الطلبات في الساعة الواحدة من العمل

1. تعريف القيمة والمنطقة الزمنية. التكوين، وليس الهندسة، وعادةً ما يستغرق الأمر فترة ما بعد الظهر.
2. معرفات المعاملات المكررة والفارغة. إصلاح طبقة البيانات.
3. الإحالات غير المرغوب فيها عبر النطاقات المختلفة. قم بتكوين كليهما، ثم أعد اختبار مسار إرجاع الدفع الفعلي، وليس مسار الاختبار التجريبي.
4. حدث شراء من جانب الخادم. أرسل عملية الشراء من نظام الطلبات الخاص بك باستخدام بروتوكول القياس، وذلك باستخدام client_id تم إنشاء علامة الويب الخاصة بك. تشترط جوجل إرسال هذه البيانات خلال 48 ساعة من تاريخ حدث العميل الأصلي، وإلا فقد لا تتم معالجة الإسناد كما هو متوقع. هذا ما يُعيد الطلبات المفقودة بسبب برامج الحجب وصفحات التأكيد التي لم يتم عرضها.
5. بنية الموافقة. الأبطأ والأكثر تسييساً. تعامل مع الباقي على أنه فجوة معروفة الحجم وموثقة.

ما الذي يتغير إذا كنت تبيع في تركيا أو الاتحاد الأوروبي؟

هناك عاملان إقليميان يؤثران على الأرقام.

الموافقة اختيارية في تركيا أيضاً، ولكن بدون شبكة الأمان الخاصة بجوجل. فرضت هيئة حماية البيانات التركية غرامة قدرها 300,000 ألف ليرة تركية على أحد مشغلي المواقع الإلكترونية بموجب القرار رقم 2022/1358 (الصادر بتاريخ 23 ديسمبر 2022) لاستخدامه ملفات تعريف الارتباط الإعلانية والتسويقية دون أساس قانوني، واشترطت الهيئة الحصول على موافقة صريحة على ملفات تعريف الارتباط غير الضرورية. وقد ردّت العديد من المواقع التركية باستخدام لافتة تحظر علامة جوجل تمامًا بدلًا من لافتة تُرسل إشارات الموافقة. هذا التمييز مكلف: إذ يتطلب نمذجة البيانات analytics_storage='denied' يجب أن تكون الأحداث موجودة. الإعلان الذي لا يُفعّل أي شيء لا يُعطي جوجل أي بيانات للنمذجة، لذا فإن البيانات تختفي بدلاً من أن تُقدّر.

تقوم عمليات الإرجاع التركية لأجهزة 3DS بإعادة المشتري عبر البريد. باستخدام iyzico، يقوم التاجر بعرض صفحة 3DS مُفكّكة التشفير، وبعد تأكيد رمز التحقق لمرة واحدة (OTP)، يقوم iyzico بإعادة التوجيه إلى صفحة التاجر. callbackUrl مع status, paymentId و mdStatusإن الاستجابة المدفوعة بواسطة طلب POST هي بالضبط ما تسميه جوجل بكسر قياس النطاقات المتعددة، حيث يمكن لعمليات إعادة التوجيه أن تزيل _gl قبل تحميل الوجهة. إذا كان الفرق في مدفوعات البطاقات يكاد يكون معدومًا عند الدفع نقدًا عند الاستلام، فهذا هو السبب.

ادعاءان شائعان لم نتمكن من التحقق منهما

"يحدد متصفح سفاري مدة صلاحية ملفات تعريف الارتباط الخاصة بالطرف الأول بسبعة أيام." غير دقيق. تشير وثائق WebKit إلى أن ITP يحذف ملفات تعريف الارتباط الخاصة بـ JavaScript وغيرها من مساحات التخزين القابلة للكتابة بواسطة البرامج النصية بعد 7 أيام من لا يوجد تفاعل للمستخدمويحدد بشكل منفصل مدة صلاحية ملفات تعريف الارتباط الخاصة بجافا سكريبت بـ 24 ساعة عند الوصول إلى الصفحة المقصودة عبر رابط من نطاق إعلاني. وقد أظهرت اختبارات سيمو أهافا أن هذه المدة تُحسب بناءً على أيام استخدام المتصفح، وليس أيام التقويم، مما يعني أن العميل العائد قد يحتفظ بمعرفه لأكثر من أسبوع.

"يُعتبر التفاوت بنسبة 5% مقبولاً." لم نجد أي مصدر من جوجل لهذه المعلومة. تنتشر هذه المعلومة عبر مدونات البائعين وإجابات المنتديات. استخدمها كمعلومات متداولة، لا كمعيار.

أين تفشل هذه الطريقة؟

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

الأسئلة المتكررة

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

لماذا لا تستخدم واجهة GA4 بدلاً من BigQuery؟ قد تتضمن واجهة المستخدم مستخدمين وجلسات مُنمذجة لا يتضمنها التصدير، لذا فإنّ رقمي جوجل يختلفان. ويجعل التوفيق بينهما وبين التقدير من المستحيل تحليل هذا الاختلاف.

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

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

هل يُعالج وضع الموافقة ثغرة الموافقة في تركيا؟ جزئياً. إن حجب الإشارات يُتيح إمكانية وضع نماذج، وذلك وفقاً لحدود حجم البيانات التي تحددها جوجل. ولا يُعدّ ذلك بديلاً عن اللافتة القانونية بموجب القوانين التركية.

ما الذي يُعتبر فجوة جيدة؟ نظامٌ لكل نقطة مئوية فيه اسم. نسبة 8% موثقة أفضل من نسبة 3% غير مفسرة.

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

هل يمكننا إجراء اختبارات A/B بينما تكون الفجوة أعلى من 10%؟ قم بتشغيلها على المقاييس النسبية المقاسة داخل أداة الاختبار، ولكن لا تقم بالإبلاغ عن التأثير المطلق للإيرادات من GA4 حتى يتم تحليل الفجوة.

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

مصادر

• [GA4] نمذجة السلوك لوضع الموافقة، مساعدة Google Analytics
• [GA4] تقليل أحداث المفاتيح المكررة باستخدام معرّفات المعاملات، مساعدة Google Analytics
• [GA4] الإحالات غير المرغوب فيها، مساعدة Google Analytics
• [GA4] قياس النطاقات المتعددة، مساعدة Google Analytics
• إرسال أحداث بروتوكول القياس إلى Google Analytics وGoogle for Developers
• معلمات وضع الموافقة، وثائق منصة علامات جوجل
• منع التتبع في WebKit
• إزالة حدّ انتهاء صلاحية ملفات تعريف الارتباط الخاصة بجافا سكريبت في متصفحات WebKit، سيمو أهافا
• KVKK كورول كراري 2022/1358، 23 ديسمبر 2022
• تطبيق 3DS، وثائق مطوري iyzico