أحداث GA4: اختيار الفئة والتحقق من القياس

نُشر 07/05/2026 · حُدّث 01/11/2026 · البيانات وقياس الأداء · 4 دقيقة قراءة · بقلم Cyber Intelligence Embassy

الخلاصة

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

غرفة تحليل خيالية خالية فيها طاولتان لبطاقات فارغة ومصابيح نحاسية وملف خمري

في هذا المقال

تعريف إجراء قابل للرصد

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

فصل الجمع عن الأهمية التجارية

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

أربع فئات لأحداث GA4
الفئة	أمثلة	الشرط
تلقائية	first_visit, session_start	جمع تتيحه التهيئة الأساسية
قياس محسن	scroll, file_download	تفعيل الميزة ودعم التفاعل
موصى بها	add_to_cart, purchase	تنفيذ الأسماء والمعلمات الموثقة
مخصصة	إجراء خاص بالمنتج	تعريفه إذا لم تلائم الفئات الأخرى

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

تم التحقق في 1 نوفمبر 2026

يجب أن تصف الأحداث المخصصة حقيقة العمل.

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

إصدار المُحفز والمعلمات والأنواع والحالات المُستبعدة في قاموس الأحداث.
اختبار النجاح والخطأ والرجوع وإعادة التحميل في DebugView أو أداة مُكافئة.
مُطابقة الأحداث المُستلمة مع العمليات المعروفة وتحديد التناقضات.

المصدر الأساسي: Google Analytics — Set up events. المنهج المرتبط: اقرأ الدليل العملي.

سلامة ربط البيانات

قد يضاعف الربط الصفوف ويشوّه المجاميع.

يمثل صف الطلبات طلباً، ويمثل صف البنود منتجاً في ذلك الطلب. افحص المفاتيح المكررة والفارغة قبل دمج الجداول.
جمّع البنود حسب معرّف الطلب. يمنع الربط بهذه النتيجة تكرار مبلغ الطلب لكل منتج. قارن المجموع بجدول الطلبات الأصلي.
يحافظ LEFT JOIN على الطلبات بلا بنود، لكن شرط WHERE على الجدول الأيمن قد يحذفها. غياب المطابقة لا يعني مبلغاً صفرياً.

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

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

عرض بيانات الحالة

{
    "orders": [
        {
            "id": 1,
            "total": 100
        },
        {
            "id": 2,
            "total": 200
        }
    ],
    "line_order_ids": [
        1,
        1,
        2
    ],
    "sum_before": 300,
    "sum_after_raw_join": 400
}

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

المجموع 400 يحتسب طلباً مرتين. جمّع البنود حسب الطلب لاستعادة 300. اختبر أيضاً طلبين افتراضيين بقيمة 100 لكل منهما؛ المجموع 200. تعيد SUM(DISTINCT total) القيمة 100 فتحذف قيمة صحيحة. افحص المعرّفات وتعدد علاقات الربط بدلاً من إزالة المبالغ المتكررة.

استعلامات SQL قابلة لإعادة التنفيذ

مثال افتراضي: طلبان بمبلغي 100 و200 وثلاثة بنود للطلبات 1 و1 و2. تستخدم الاستعلامات VALUES فقط؛ نفّذها في بيئة اختبار.

WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2))
SELECT COUNT(*) AS rows, SUM(o.total) AS total
FROM orders o JOIN lines l ON l.order_id = o.id;

WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2)),
per_order AS (
  SELECT order_id, COUNT(*) AS line_count
  FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS orders, SUM(o.total) AS total
FROM orders o LEFT JOIN per_order l ON l.order_id = o.id;

ينتج الربط المباشر ثلاثة صفوف ومجموعاً 400. يعيد التجميع المسبق طلبين ومجموعاً 300.

WITH orders(id, total) AS (VALUES (1, 100), (2, 100))
SELECT SUM(total) AS correct_total,
       SUM(DISTINCT total) AS distinct_total
FROM orders;

مع مبلغي 100 و100، المجموع الصحيح 200؛ يعيد SUM(DISTINCT total) القيمة 100.

إجراء التحقق

حدد مستوى تفصيل الطلبات والبنود.
اربط طلباً له بندان.
احتفظ بالمفاتيح والأعداد والمجاميع المطابقة.

PostgreSQL — Table expressions and joins

هل يكفي SUM(DISTINCT total)؟

لا. طلبان بمبلغ 100 لكل منهما مجموعهما 200، لكن SUM(DISTINCT total) يعيد 100. أصلح علاقة المفاتيح بدلاً من حذف المبالغ المتساوية.

المصدر الأساسي: PostgreSQL — Table expressions and joins. المنهج المرتبط: اقرأ الدليل العملي.

تعدد صفوف الربط وNULL والتجميع

الملاحظات المرجعية المفصّلة متاحة باللغة الإنجليزية في هذه النسخة.

Read the cardinality behind a published number

When a result combines sources, ask what one row represents and how keys were matched. An apparently correct sum can conceal two offsetting errors. Pair counts and identifier coverage provide additional evidence.

Document population before and after joining.
Do not infer causation from the total alone.
Connect the metric definition to actual retained rows.

Inspect pairs and aggregates in the workshop →

PostgreSQL 18 · Table expressions · PostgreSQL 18 · documentation reviewed 2026-10-23

PostgreSQL 18 · Aggregate functions · PostgreSQL 18 · documentation reviewed 2026-10-23

PostgreSQL 18 · Comparison functions · PostgreSQL 18 · documentation reviewed 2026-10-23