سدّ الفجوة بين واجهة مستخدم "إحصاءات 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 والتقارير العادية تؤكّد تقارير واجهة برمجة التطبيقات أو تقارير الاستكشاف أنّها لا تستند إلى عيّنات بيانات. يوفِّر تحليل عيّنات البيانات في "إحصاءات 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++ Sketches لمستويات الدقة في فواصل ثقة مختلفة معلمات دقة مختلفة لـ HLL++.

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

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

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

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

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

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

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

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

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

إشارات Google

يحقّق تفعيل "إشارات Google" على موقعك على "إحصاءات Google 4" عدّة مزايا، من بينها: تكرار المستخدمين عبر الأنظمة الأساسية والأجهزة. إذا لم تجمع بيانات أرقام تعريف أو تفعيل "إشارات Google"، ويشاهد أحد الأشخاص موقعك الإلكتروني من خلال ثلاثة أفراد متصفحات ويب مختلفة، ثم ينسب Google Analytics هذا النشاط إلى ثلاثة مستخدمين مختلفين، وستحتوي BigQuery Export على ثلاث user_pseudo_id منفصلة. على النقيض من ذلك، بعد تفعيل "إشارات Google" وسجِّل المستخدم الدخول حساب Google واحد في جميع المتصفحات الثلاثة، وهي سمات "إحصاءات Google" التي النشاط إلى مستخدم واحد ويعكس هذا العدد في مساحات عرض التقارير العادية. في المقابل، ستستمر BigQuery بعرض ثلاث عبارات user_pseudo_id منفصلة للأسباب التالية: لا تتوفّر معلومات "إشارات Google" في عملية تصدير BigQuery. وبالتالي، من المرجح أن تتضمّن التقارير التي تتضمّن بيانات "إشارات 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 للنمذجة التنبؤ بالجلسات المتعددة من الأفراد الذين لم يمنحوا موافقتهم المستخدمين.

للحدّ من تأثير ذلك، عليك تنفيذ 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، فستتم إعادة ضبط الجلسات في منتصف الليل. في حال حذف اتباع نموذج UA، وحساب الجلسات لكل يوم، وإضافتها للحصول على إجمالي عدد الجلسات، فستحسب الجلسات التي تمتد على مدى أيام متعددة.
  • بناءً على المعلومات التعريفية في التقارير المحدّدة، عدد المستخدمين طريقة حساب مختلفة.
• نطاق السمة والمقياس: تأكَّد من أنّ عملياتك الحسابية تستخدم الصحيح على مستوى المستخدم أو الجلسة أو العنصر أو الحدث.
• المنطقة الزمنية: في BigQuery Export، يكون event_date هو وقت إعداد التقارير. المنطقة، بينما يُعدّ event_timestamp طابعًا زمنيًا بالتوقيت العالمي المنسّق (UTC) بالميكرو ثانية. إذًا، ومن الناحية المثالية، إذا استخدم أحدهم event_timestamp في طلب بحث، يجب تعديله بما يتوافق مع المنطقة الزمنية الصحيحة لإعداد التقارير عند المقارنة بأرقام واجهة المستخدم.
• حدود فلترة البيانات وتصديرها: في حال إعداد ميزة فلترة البيانات لما يلي: تم تجاوز تصدير الأحداث في BigQuery أو حجم تصدير الأحداث اليومية الحد، لن تتطابق بيانات تصدير أحداث BigQuery مع المعيار مساحات عرض التقارير.

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