سدّ الفجوة بين واجهة مستخدم "إحصاءات Google" وBigQuery Export

مينهاز كازي، مسؤول علاقات المطوّرين، "إحصاءات Google" – نيسان (أبريل) 2023

"ولكن لماذا لا تتطابق الأرقام مع واجهة المستخدم؟"

إذا كنت قد تعاملت مع بيانات تصدير أحداث BigQuery لموقعك على "إحصاءات Google 4"، لقد طرحت هذا السؤال بالتأكيد في مرحلة معيّنة. أو الأسوأ من ذلك - سألك شخص آخر هذا. وأثناء محاولة الإجابة عليه، ربما طُرح عليك سؤال المتابعة المخيف:

"أين المكتوب عليها؟"

سنحاول من خلال هذه المشاركة تسليط الضوء على كليهما.

قبل أن ندخل في تفاصيل كيفية اختلاف الأرقام، من المهم فهم الغرض المقصود من بيانات تصدير حدث BigQuery. ويرسل مستخدمو "إحصاءات Google" بياناتهم التي يتم جمعها إلى "إحصاءات Google" من خلال إحدى طرق جمع البيانات، وهي علامة Google وإدارة العلامات من Google وMeasurement Protocol وحِزم تطوير البرامج (SDK) واستيراد البيانات. استنادًا إلى إعدادات موقع "إحصاءات Google"، تُضيف "إحصاءات Google" قيمة كبيرة إلى البيانات التي تم جمعها قبل أن تصل إلى مساحات عرض التقارير العادية، بما في ذلك التقارير العادية والاستكشافات وData API. ويمكن أن تشمل إضافات القيم هذه تضمين "إشارات Google"، ووضع النماذج، وإحالة الزيارات، والتوقّع، وما إلى ذلك.

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

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

الآن دعونا ندخل في بعض الأسباب المحددة للاختلافات ونستكشف طرق التخفيف من حدتها عندما يكون ذلك ممكنًا. تركِّز هذه المشاركة على تصدير الأحداث اليومية في BigQuery فقط وليس على تصدير بيانات البث.

أخذ العينات

لإجراء مقارنة دقيقة لبيانات BigQuery Export بالتقارير العادية أو تقارير Data API أو تقارير الاستكشاف، تأكَّد من أنّها لا تستند إلى عيّنات بيانات. يوفِّر تحليل عيّنات البيانات في "إحصاءات Google 4" تفاصيل إضافية وطرقًا إضافية لمعالجة تحليل عينات البيانات.

المستخدِمون النشطون

إذا سجّلت جميع المستخدِمين الذين سجّلوا حدثًا واحدًا على الأقل في موقعك على "إحصاءات Google 4"، سيظهر لك مقياس إجمالي المستخدِمين. على الرغم من أنّ مقياس إجمالي المستخدمين متاح في أداة "الاستكشافات" ضمن واجهة مستخدم "إحصاءات Google 4"، إنّ مقياس المستخدِم الأساسي المستخدَم لإعداد التقارير في "إحصاءات Google 4" هو المستخدمون النشطون. في واجهة مستخدم "إحصاءات Google 4" وفي التقارير، في حال ذكر المستخدِمون فقط، يشير ذلك عادةً إلى المستخدِمون النشطون. لذا عند حساب عدد المستخدمين من بيانات BigQuery، ستحتاج إلى فلترة المستخدمين النشطين فقط والاحتفاظ بالمستخدمين النشطين فقط لجعل الأرقام قابلة للمقارنة مع واجهة مستخدم "إحصاءات Google". ستختلف طريقة الحساب أيضًا استنادًا إلى المعلومات التعريفية في التقارير التي اخترتها.

التنفيذ الفني

في بيانات تصدير أحداث BigQuery، عند احتساب عدد أرقام تعريف المستخدمين المختلفة، ستحصل على عدد إجمالي المستخدمين. إليك نموذج طلب بحث يعرض كلاً من "إجمالي المستخدمين" و"المستخدمون الجدد" استنادًا إلى user_pseudo_id:

-- Example: Get 'Total User' count and 'New User' count.

WITH
  UserInfo AS (
    SELECT
      user_pseudo_id,
      MAX(IF(event_name IN ('first_visit', 'first_open'), 1, 0)) AS is_new_user
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
    GROUP BY 1
  )
SELECT
  COUNT(*) AS user_count,
  SUM(is_new_user) AS new_user_count
FROM UserInfo;

لاختيار المستخدمين النشطين فقط، احصر طلب البحث على الأحداث التي تكون فيها قيمة is_active_user هي true:

-- Example: Get exact and approximate Active User count.

WITH
  ActiveUsers AS (
    SELECT
      user_pseudo_id
    -- Replace table name.
    FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
    -- Replace date range.
    WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
      AND is_active_user
    GROUP BY 1
  )
SELECT
  COUNT(DISTINCT user_pseudo_id) AS exact_active_user_count,
  APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_active_user_count
FROM ActiveUsers;

HyperLogLog++

تستخدم "إحصاءات Google" خوارزمية HyperLogLog++ (HLL++ ) لتقدير عدد القيم الفريدة للسمة في المقاييس الشائعة، بما في ذلك "المستخدمون النشطون" و"الجلسات". وهذا يعني أنّه عند عرض العدد الفريد لهذه المقاييس في واجهة المستخدم أو عبر واجهة برمجة التطبيقات، تكون هذه المقاييس تقريبية بدقة معيّنة. في BigQuery، نظرًا لأن لديك إمكانية الوصول إلى البيانات الدقيقة، يمكنك حساب عدد العناصر في الحقل الدقيق لهذه المقاييس. لذلك قد تختلف المقاييس بنسبة صغيرة. عند فاصل ثقة بنسبة% 95، قد تكون الدقة ±1.63% لعدد الجلسات. ستختلف مستويات الدقة وفقًا لمقاييس مختلفة وستتغير وفقًا لفواصل الثقة. راجِع رسومات HLL++ للتعرّف على مستويات الدقة على فواصل ثقة مختلفة لمعلَمات دقة مختلفة في HLL++.

التنفيذ الفني

اطّلِع على تقريب عدد القيم الفريدة في "إحصاءات Google" لفهم كيفية تنفيذ HLL++ في "إحصاءات Google" وكيفية تكرار الوظائف باستخدام طلبات بحث BigQuery.

التأخير في جمع البيانات

يتم إنشاء جداول التصدير اليومية بعد أن تجمع "إحصاءات Google" جميع أحداث اليوم. يمكن تحديث الجداول اليومية لمدة تصل إلى 72 ساعة بعد تاريخ الجدول من خلال الأحداث ذات الطابع الزمني بتاريخ الجدول. اقرأ التفاصيل حول هذا الموضوع واطّلِع على أمثلة. وتزداد هذه المشكلة إذا تم إرسال حزمة تطوير البرامج (SDK) لمنصة Firebase أو Measurement Protocol في إطار أحداث متأخرة أو بلا اتصال بالإنترنت. اعتمادًا على وقت تحديث مساحة عرض التقارير العادية وBigQuery في غضون 72 ساعة، قد تلاحظ اختلافات بينهما. لمثل هذا التنفيذ، يجب إجراء مقارنات مع البيانات الأقدم من 72 ساعة.

التقارير التي تتضمّن عددًا كبيرًا من القيم

لنفترض أنّك تطّلِع على تقرير من خلال التقارير العادية أو Data API. يعرض التقرير كمية كبيرة من البيانات ويحتوي على سمات ذات عدد كبير من العناصر في الحقل. إنّ السمات التي تتضمّن عددًا كبيرًا من القيم قد تؤدي إلى تجاوز التقرير الحدّ الأقصى لعدد القيم الفريدة للسمة في الجدول الأساسي. عند حدوث ذلك، ستجمع "إحصاءات Google" القيم الأقل تكرارًا وتصنِّفها باعتبارها (غير ذلك).

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

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

لا يتمّ تجميع الصفّ (other) إلا في وحدة إعداد التقارير وData API عندما يتجاوز التقرير الحدّ الأقصى لعدد القيم الفريدة للسمة. إذا أجريت العمليات الحسابية من BigQuery، فدائمًا ما ينتهي بك الأمر بالبيانات الواقعية - الصفوف الأكثر دقة. يمكنك الاطّلاع على مزيد من المعلومات عن الصفّ (other) وأفضل الممارسات المتعلّقة بكيفية تجنُّبه.

إشارات Google

يؤدي تفعيل "إشارات Google" على موقعك على "إحصاءات Google 4" (GA4) إلى عدة مزايا، من بينها تكرار المستخدمين على مختلف المنصّات والأجهزة. في حال عدم جمع أرقام تعريف المستخدمين أو تفعيل "إشارات Google" وكان أحد المستخدمين يشاهد موقعك الإلكتروني على ثلاثة متصفّحات ويب مختلفة، ستُنسب "إحصاءات Google" هذا النشاط إلى ثلاثة مستخدمين مختلفين، وسيحتوي BigQuery Export على ثلاث user_pseudo_id منفصلة. في المقابل، عند تفعيل "إشارات Google" وتسجيل الشخص الدخول إلى حساب Google واحد في جميع المتصفّحات الثلاثة، تنسب "إحصاءات Google" هذا النشاط إلى مستخدِم واحد وتعكس هذا العدد في مساحات عرض التقارير العادية. ومع ذلك، ستستمر خدمة BigQuery في عرض ثلاث سمات user_pseudo_id منفصلة لأنّ معلومات "إشارات Google" غير متوفّرة في ميزة BigQuery Export. وبالتالي، من المرجح أن يكون عدد المستخدمين أقل في التقارير التي تحتوي على بيانات "إشارات Google" مقارنةً بتقارير BigQuery Export.

وأفضل طريقة للحدّ من هذا التأثير هي تنفيذ User-ID في موقعك على "إحصاءات Google 4" مع تفعيل "إشارات Google". سيضمن ذلك تنفيذ إزالة التكرار أولاً استنادًا إلى user_id بالنسبة إلى المستخدمين الذين سجّلوا الدخول، ستتم تعبئة الحقل user_id في BigQuery ويمكن استخدامه لأغراض الحساب. أمّا بالنسبة إلى المستخدِمين الذين لم يسجّلوا الدخول (أي الجلسات بدون user_id)، سيستمر استخدام "إشارات Google" لإزالة التكرار.

يُرجى العِلم أيضًا أنّ بعض التقارير في مساحات عرض التقارير العادية قد يتم تطبيق حدود عليها ولا تعرض بيانات معيّنة. عادةً ما لا تتوفّر معظم المعلومات التي يمكن أن تخضع للحد الأدنى في BigQuery Export.

"وضع الموافقة" والبيانات المستندة إلى نموذج

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

وللحدّ من تأثير ذلك، عليك تنفيذ User-ID في موقعك على "إحصاءات Google 4". يتم تصدير user_id والسمات المخصّصة إلى BigQuery بغض النظر عن حالة الموافقة للمستخدمين.

بيانات إحالة الزيارات

تتوفّر بيانات إحالة الزيارات في BigQuery على مستوى المستخدِم (الزيارة الأولى) والحدث. وهي البيانات التي يتم جمعها. ومع ذلك، بما أنّ "إحصاءات Google" تنفِّذ نموذج تحديد المصدر الخاص بها على مستوى الجلسة، فإنّ هذه المعلومات لا تتوفّر مباشرةً في BigQuery Export ولا يمكن احتسابها بدقة كاملة باستخدام البيانات المتاحة. استنادًا إلى حالة استخدامك، يمكنك التفكير في ضم مجموعة بيانات BigQuery مع أي بيانات طرف أول ذات صلة وإنشاء نموذج تحديد مصدر خاص بك. في المستقبل، قد تتوفّر بيانات إضافية مجمّعة لإحالة الزيارات من خلال تصدير أحداث BigQuery.

الأخطاء الحسابية الشائعة

• طريقة الاحتساب: عند احتساب مقاييس مختلفة في BigQuery، احرص على استخدام المنهجية الصحيحة. على سبيل المثال:
  • الطريقة العادية لاحتساب الجلسات لمواقع "إحصاءات Google 4" تحتسب المجموعات الفريدة من user_pseudo_id/user_id وga_session_id بغض النظر عن الإطار الزمني. في Universal Analytics، ستتم إعادة ضبط الجلسات في منتصف الليل. إذا اتّبعت نموذج Universal Analytics، وحسابت الجلسات لكل يوم، وأضفتها للحصول على إجمالي عدد الجلسات، ستحتسب مرتين الجلسات التي تمتدّ على مدار عدّة أيام.
  • اعتمادًا على المعلومات التعريفية في التقارير التي اختَرتها، يجب تعديل طريقة احتساب عدد المستخدمين.
• نطاق السمة والمقياس: تأكَّد من أنّ عملياتك الحسابية تستخدم النطاق الصحيح للمستخدم أو الجلسة أو العنصر أو الحدث.
• المنطقة الزمنية: في BigQuery Export، يُستخدم الحقل event_date للمنطقة الزمنية لإعداد التقارير في حين أنّ event_timestamp هو طابع زمني للتوقيت العالمي المتفق عليه بالميكرو ثانية. لذلك، إذا كان أحدهم يستخدم event_timestamp في طلب بحث، يجب تعديله ليتناسب مع المنطقة الزمنية الصحيحة لإعداد التقارير عند مقارنته بأرقام واجهة المستخدم.
• حدود فلترة البيانات وتصديرها: في حال إعداد فلترة البيانات لتصدير أحداث BigQuery أو تجاوز حجم تصدير الأحداث اليومي الحدّ الأقصى المسموح به، لن تتطابق بيانات تصدير أحداث BigQuery مع مساحات عرض إعداد التقارير العادية.

مع كل ذلك، نجد بعض الأمور التي تهمُّنا في هذه المشاركة. نأمل أن تتمكن من تحديد الحلول الصحيحة لمشروع DISTINCT الخاص بك من الإرشادات هنا. إذا كانت لديك أي أسئلة، يمكنك الانضمام إلى خادم GA Discord