تقارير الاكتساب: مقارنة النطاقات الصحيحة

الخلاصة

مصدر اكتساب المستخدم أول مرة ومصدر الجلسة ورصيد الحدث الرئيسي قراءات مختلفة. يوضح التقرير المفيد هذه النطاقات قبل مقارنة القنوات.

محطة اتصالات فضائية خالية عند الغسق
في هذا المقال

مصدر اكتساب المستخدم أول مرة ومصدر الجلسة ورصيد الحدث الرئيسي قراءات مختلفة. يوضح التقرير المفيد هذه النطاقات قبل مقارنة القنوات.

تحديد مرجع مشترك

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

قراءة أبعاد GA4 بحسب النطاق

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

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

توثيق الفروق قبل التصرف

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

المصادر والتحقق

تحتاج التقارير متعددة القنوات إلى إحصاء موثوق.

يمكن أن تُساهم عدة قنوات في رحلة واحدة. حدد توزيع النقاط في كل تقرير، ومصدر إحصاء النتائج الفريدة. افحص فترات الإسناد، وانقطاع التتبع، وعودة الزوار دون تحديد معايير الحملة؛ فالوصول المباشر لا يعني بالضرورة عدم وجود مساهمة سابقة.

  • وثّق نموذج الإسناد وفترته.
  • وازن بين النتائج الفريدة ونقاط القناة.
  • وضّح قيود الرحلات غير المُتتبّعة.

هل يجب جمع المبيعات المنسوبة إلى المنصة؟

ليس كعدد للطلبات الفريدة. يمكن لكل تقرير أن يُنسب نفس البيع. التوفيق الحالي والتداخلات.

المصدر الأساسي: Google Analytics — Campaign URL data. المنهج المرتبط: اقرأ الدليل العملي.

المناطق الزمنية والأحداث المتأخرة

تعتمد فترة التقرير على وقت الحدث وقواعد الإغلاق.

  • سجّل وقت الحدث ووقت الاستلام والمنطقة الزمنية للعمل بشكل منفصل. في مثال افتراضي، تصبح 23:30 UTC الساعة 01:30 من اليوم التالي عند إزاحة ثابتة UTC+02:00. نوع الطابع الزمني مع المنطقة في PostgreSQL لا يحتفظ باسم المنطقة الأصلي.
  • اجعل البداية مشمولة والنهاية غير مشمولة. احسب الحدود في منطقة العمل قبل تحويلها إلى UTC. اختبر تغيير التوقيت الموسمي ونهاية الشهر والتاريخ دون ساعة؛ اليوم المحلي لا يساوي دائماً 24 ساعة.
  • حدّد التأخر المسموح وموعد إغلاق التقرير. كرّر المعرّف نفسه لتمييز الحدث الجديد من النسخة المكررة. احتفظ بالنسخة المنشورة وأثر التصحيح؛ العلامة المائية تقدير للوصول وليست ضماناً لاكتمال البيانات.

حالة قبول قابلة للتكرار

مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.

عرض بيانات الحالة
{
    "event_time": "2026-10-08T23:30:00Z",
    "report_zone": "UTC+02:00",
    "local_time": "2026-10-09T01:30:00+02:00"
}

القرار المتوقع

الحدث يقع في 9 أكتوبر بالمنطقة المحددة. احتفظ أيضاً بلحظة UTC.

إجراء التحقق

  1. حدد منطقة التقرير ولحظة المرجع.
  2. أعد حدثاً قريباً من منتصف الليل.
  3. احتفظ بـ UTC والتاريخ المحلي وقاعدة الإغلاق. أضف وقتاً محلياً ملتبساً أثناء تغيير الساعة؛ واحتفظ بالإزاحة والمنطقة بدلاً من استنتاج لحظة محددة.

PostgreSQL — Date/time types

هل يمكن اعتبار يوم الاستلام يوم الحدث؟

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

المصدر الأساسي: PostgreSQL — Date/time types. المنهج المرتبط: اقرأ الدليل العملي.