Google Analytics 4

في تكامل Ga4 لا يكفي إرسال كل ما يتاح من بيانات. نحدد أولًا النتائج التجارية المطلوبة، ثم نختار الأحداث الملائمة، مثل: generate_lead, sign_up, begin_checkout, purchase, and refund. هذه أمثلة للمتطلبات التي ينبغي مراجعتها وليست وعدًا بأن كل حدث مدعوم تلقائيًا. نحدد مع العميل مصدر الحدث وصلاحيات استخدامه ونقطة تسجيله الصحيحة قبل بناء أي خريطة إرسال.

الحقول التي نراجع ملاءمتها بحسب طبيعة الحالة تشمل: client or permitted user identifiers, event name, items array, transaction_id, revenue and currency. لا نجمع هذه الحقول كلها بالضرورة؛ نستخدم الحد الأدنى المسموح به فقط، ونمنع انتقال المعلومات الحساسة إلى منصات غير مناسبة. الأهم هو ثبات المعرّفات وتطابق القيمة والزمن مع السجل الأصلي حتى تكون المقارنة عادلة.

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

نضع قائمة مراجعة للحقول الخاصة بالمصدر: client or permitted user identifiers, event name, items array, transaction_id, revenue and currency. لكل حقل نحدد النوع المتوقع والقيمة الافتراضية ومصدر الحقيقة وطريقة التأكد من سلامته. إذا تغيّر الاسم أو صيغة القيمة في النظام المصدر، ينبغي أن يظهر فشل واضح في الاختبار بدل إرسال نتائج لا يمكن الوثوق بها.

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

بعد التشغيل، نحدد مسؤولًا عن مراقبة الأرقام وأسباب الأخطاء. تشمل قائمة المراجعة: incorrect recommended-event parameters, duplicate transaction IDs, session discrepancies and consent filtering. عند ظهور اختلاف، نبدأ برقم الحدث أو السجل الأصلي، ثم نفحص توقيت الإرسال وحالة الاستجابة، ونوثق أي تغيير في خرائط البيانات قبل إعادة الاختبار.