شکاف بین رابط کاربری Google Analytics و صادرات BigQuery را پر کنید

Minhaz Kazi ، مدافع توسعه‌دهنده، Google Analytics - آوریل 2023

اما چرا اعداد با رابط کاربری مطابقت ندارند؟

اگر با داده‌های صادرات رویداد BigQuery برای ویژگی GA4 خود کار کرده‌اید، قطعاً در مقطعی این سؤال را پرسیده‌اید. یا بدتر - شخص دیگری این را از شما پرسید. و در حالی که سعی می کنید به آن پاسخ دهید، احتمالاً از شما سؤال ترسناک بعدی پرسیده شده است:

"و کجا این را می گوید؟"

با این پست سعی می کنیم هر دو را روشن کنیم.

قبل از اینکه به جزئیات نحوه تغییر اعداد بپردازیم، مهم است که هدف مورد نظر داده‌های صادرات رویداد BigQuery را درک کنیم. کاربران Google Analytics داده‌های جمع‌آوری‌شده خود را از طریق یکی از روش‌های جمع‌آوری - Google Tag ، Google Tag Manager ، Measurement Protocol ، SDKs و Data Import به GA ارسال می‌کنند. بر اساس تنظیمات ویژگی GA، Google Analytics قبل از رسیدن به سطوح گزارش استاندارد از جمله گزارش‌های استاندارد ، کاوش‌ها و Data API، ارزش قابل توجهی به داده‌های جمع‌آوری‌شده اضافه می‌کند. این ارزش افزوده می تواند شامل گنجاندن سیگنال های گوگل، مدل سازی، انتساب ترافیک، پیش بینی و غیره باشد.

سطوح گزارش استاندارد با هدف ارائه حداکثر مقدار به کاربران GA در کمترین اصطکاک می باشد. با این حال، می‌دانیم که در طیف گسترده‌ای از کاربران، برخی ممکن است بخواهند ارزش افزوده‌های Google Analytics را تکمیل کنند یا حتی کاری کاملاً سفارشی انجام دهند. برای این کاربران، صادرات رویداد BigQuery نقطه شروع مورد نظر است. صادرات رویداد BigQuery داده‌های جمع‌آوری‌شده‌ای خواهد داشت که از مشتری یا برنامه به Google Analytics ارسال می‌شود. صادرات رویداد BigQuery حاوی داده‌های ریز در مورد بیشتر ارزش افزوده‌های ذکر شده در بالا نخواهد بود.

بنابراین، برای تعداد زیادی از موارد استفاده، سطوح گزارش استاندارد و داده‌های صادراتی BigQuery در مورد این بخش‌های ارزش افزوده قابل تطبیق نیستند. اگر هماهنگی درونی در هر دو وجود دارد و با آنچه که جمع آوری می کنید مطابقت دارند، باید خوب بروید.

حال بیایید به برخی از دلایل خاص تفاوت ها بپردازیم و راه هایی را برای کاهش آنها در صورت امکان بررسی کنیم. این پست فقط بر صادرات رویداد روزانه BigQuery تمرکز دارد و نه صادرات جریانی.

نمونه برداری

برای مقایسه دقیق داده‌های صادراتی BigQuery شما با گزارش‌های استاندارد، گزارش‌های Data API یا گزارش‌های کاوش، تأیید کنید که بر اساس داده‌های نمونه‌گیری شده نیستند. نمونه‌گیری داده‌ها در GA4 جزئیات و روش‌های بیشتری برای رسیدگی به نمونه‌گیری ارائه می‌دهد.

کاربران فعال

اگر تمام کاربرانی را که حداقل یک رویداد را در دارایی GA4 شما ثبت کرده اند بشمارید، معیار مجموع کاربران را دریافت خواهید کرد. اگرچه معیار مجموع کاربران در Explorations در GA4 UI موجود است، معیار کاربر اصلی که برای گزارش در GA4 استفاده می‌شود، Active Users است. در رابط کاربری GA4 و در گزارش‌ها، اگر فقط Users ذکر شده باشد، معمولاً به Active Users اشاره می‌شود. بنابراین هنگام محاسبه تعداد کاربران از داده‌های BigQuery، باید فقط کاربران فعال را فیلتر کرده و نگه دارید تا اعداد را با رابط کاربری GA مقایسه کنید. روش محاسبه نیز بر اساس هویت گزارش انتخابی شما متفاوت خواهد بود.

پیاده سازی فنی

در داده‌های صادرات رویداد 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 Analytics از الگوریتم HyperLogLog++ (HLL++) برای تخمین اصلی بودن معیارهای رایج از جمله کاربران فعال و جلسات استفاده می‌کند. این بدان معناست که وقتی تعداد منحصربه‌فرد این معیارها را در UI یا از طریق API مشاهده می‌کنید، آنها یک تقریبی با دقت خاصی هستند. در BigQuery، از آنجایی که به داده های دانه ای دسترسی دارید، می توانید کاردینالیته دقیق این معیارها را محاسبه کنید. بنابراین معیارها می توانند با درصد کمی متفاوت باشند. در فاصله اطمینان 95 درصد، دقت ممکن است 1.63 ± درصد برای تعداد جلسات باشد. سطوح دقت برای معیارهای مختلف متفاوت است و با توجه به فواصل اطمینان تغییر خواهد کرد. برای سطوح دقت در فواصل اطمینان مختلف برای پارامترهای دقت مختلف HLL++، طرح‌های HLL++ را ببینید.

پیاده سازی فنی

برای درک نحوه پیاده‌سازی HLL++ در Google Analytics و اینکه چگونه می‌توانید عملکرد را با استفاده از جستارهای BigQuery تکرار کنید ، به تقریب تعداد منحصر به فرد در Google Analytics مراجعه کنید.

تأخیر در جمع آوری داده ها

جداول صادرات روزانه پس از جمع آوری تمام رویدادهای روز توسط GA ایجاد می شود. جداول روزانه می توانند تا 72 ساعت بعد از تاریخ جدول با رویدادهایی که با تاریخ جدول دارای مهر زمانی هستند به روز شوند. جزئیات در مورد این را بخوانید و نمونه هایی را ببینید . اگر اجرای Firebase SDK یا Measurement Protocol شما رویدادهای آفلاین یا تاخیری ارسال کند، این مشکل بیشتر است. بسته به زمانی که سطح گزارش استاندارد و BigQuery در طی این ۷۲ ساعت به‌روزرسانی می‌شوند، ممکن است تفاوت‌هایی بین آن‌ها مشاهده کنید. برای چنین پیاده سازی، مقایسه باید روی داده های قدیمی تر از 72 ساعت انجام شود.

گزارش‌های کاردینالیته بالا

فرض کنید یک گزارش را از طریق گزارش های استاندارد یا Data API مشاهده می کنید. این گزارش حجم زیادی از داده ها را نشان می دهد و دارای ابعادی با کاردینالیته بالا است. ابعاد کاردینالیته بالا ممکن است باعث شود گزارش از حد اصلی جدول زیرین بیشتر شود. هنگامی که این اتفاق می افتد، Google Analytics مقادیر کمتری را گروه بندی می کند و آنها را به عنوان (سایر) برچسب گذاری می کند.

با استفاده از یک مثال ساده و در مقیاس کوچک ، اگر حد کاردینالیته برای جدول زیر 10 ردیف باشد، می توانید انتظار داشته باشید که این اتفاق بیفتد:

همانطور که می بینید، تعداد کل رویدادها بدون تغییر باقی می ماند. با این حال، مقادیر کمتر با هم گروه‌بندی می‌شوند و شما نمی‌توانید جدول را بر اساس هر بعد دیگری جمع‌آوری کنید (مثلاً نمی‌توانید جدول کل را انتخاب کنید و تعداد کل رویدادها را برای یک شهر خاص با دقت بالا استخراج کنید). اگر داده‌های انبوه را بر اساس هر یک از ابعاد فیلتر کنید، مثال عمیق‌تر می‌شود.

این گروه بندی ردیف (سایر) فقط در ماژول گزارش و API داده زمانی اتفاق می افتد که گزارش از حد اصلی عبور کند. اگر محاسبات خود را از BigQuery انجام دهید، همیشه با داده‌های حقیقت پایه - دانه‌بندی‌ترین ردیف‌ها، به پایان می‌رسید. درباره ردیف (سایر) و بهترین روش‌ها در مورد نحوه اجتناب از آن بیشتر بخوانید.

سیگنال های گوگل

فعال کردن Google Signals در دارایی GA4 شما دارای چندین مزیت از جمله حذف مجدد کاربران در پلتفرم‌ها و دستگاه‌ها است. اگر شناسه‌های کاربری را جمع‌آوری نکنید یا Google Signals را فعال نکنید و شخصی وب‌سایت شما را در سه مرورگر وب مختلف مشاهده کند، Google Analytics آن فعالیت را به سه کاربر مختلف نسبت می‌دهد و صادرات BigQuery سه user_pseudo_id جداگانه خواهد داشت. در مقابل، با فعال شدن Google Signals و ورود شخص به حساب Google خود در هر سه مرورگر، Google Analytics آن فعالیت را به یک کاربر نسبت می دهد و آن تعداد را در سطوح گزارش استاندارد منعکس می کند. با این حال، BigQuery همچنان سه user_pseudo_id جداگانه را نشان خواهد داد زیرا اطلاعات Google Signals در صادرات BigQuery در دسترس نیست. بنابراین، گزارش‌های حاوی داده‌های Google Signals به احتمال زیاد تعداد کاربر کمتری در مقایسه با صادرات BigQuery دارند.

بهترین راه برای کاهش این اثر این است که User-ID ها را در ویژگی GA4 خود به همراه فعال کردن Google Signals پیاده سازی کنید . این اطمینان حاصل می کند که حذف مجدد ابتدا بر اساس user_id انجام می شود. برای کاربرانی که وارد سیستم شده‌اند، فیلد user_id در BigQuery پر می‌شود و می‌توان از آن برای اهداف محاسبه استفاده کرد. با این حال، برای کاربرانی که وارد سیستم نشده‌اند (یعنی جلسات بدون user_id )، از Google Signals همچنان برای حذف مجدد استفاده می‌شود.

همچنین توجه داشته باشید که برخی گزارش‌ها در سطوح گزارش‌دهی استاندارد ممکن است دارای آستانه اعمال شده باشند و داده‌های خاصی را برنگردانند. اغلب اطلاعاتی که می‌توانند در معرض آستانه قرار گیرند، معمولاً در صادرات BigQuery در دسترس نیستند.

حالت رضایت و داده های مدل شده

حالت رضایت در وب‌سایت‌ها و برنامه‌های تلفن همراه به شما امکان می‌دهد وضعیت رضایت کوکی یا شناسه برنامه کاربران خود را با Google در میان بگذارید. هنگامی که بازدیدکنندگان رضایت خود را رد می کنند، GA4 شکاف های جمع آوری داده ها را با مدل سازی رویدادهای کلیدی و مدل سازی رفتاری پر می کند. هیچ یک از داده های مدل شده در صدور رویداد BigQuery موجود نیست. هنگامی که حالت رضایت اجرا می شود، مجموعه داده BigQuery حاوی پینگ های بدون کوکی خواهد بود که توسط GA جمع آوری شده است و هر جلسه یک user_pseudo_id متفاوت خواهد داشت. به دلیل مدل سازی، تفاوت هایی بین سطوح گزارش استاندارد و داده های دانه ای در BigQuery وجود خواهد داشت. به عنوان مثال، به دلیل مدل‌سازی رفتاری، ممکن است تعداد کاربران فعال کمتری را در مقایسه با صادرات BigQuery مشاهده کنید، زیرا مدل‌سازی ممکن است سعی کند چندین جلسه را از کاربران بدون رضایت پیش‌بینی کند.

باز هم، برای کاهش اثر این، باید User-ID ها را در ویژگی GA4 خود پیاده سازی کنید . user_id و ابعاد سفارشی بدون توجه به وضعیت رضایت کاربران شما به BigQuery صادر می‌شوند.

داده های انتساب ترافیک

در BigQuery داده های انتساب ترافیک در سطح کاربر (اولین بازدید) و رویداد موجود است. اینها داده های جمع آوری شده است. با این حال، از آنجایی که Google Analytics مدل اسناد خود را در سطح جلسه پیاده‌سازی می‌کند، این اطلاعات نه مستقیماً در صادرات BigQuery در دسترس است و نه می‌توان آن را با دقت کامل با داده‌های موجود محاسبه کرد. بسته به مورد استفاده خود، می‌توانید به مجموعه داده BigQuery با هر داده شخص اول مرتبط بپیوندید و مدل انتساب خود را بسازید. در آینده، داده‌های جمع‌آوری‌شده اضافی برای انتساب ترافیک ممکن است از طریق صدور رویداد BigQuery در دسترس باشد.

اشتباهات رایج محاسباتی

• روش محاسبه: هنگام محاسبه معیارهای مختلف در BigQuery، مطمئن شوید که از روش صحیح استفاده می کنید. به عنوان مثال:
  • روش استاندارد شمارش جلسات برای ویژگی های Google Analytics 4، شمارش ترکیبات منحصر به فرد user_pseudo_id / user_id و ga_session_id بدون توجه به بازه زمانی است. در Universal Analytics، جلسات در نیمه شب بازنشانی می‌شوند. اگر از مدل UA پیروی کنید، جلسات را برای هر روز محاسبه کنید، و آنها را با هم جمع کنید تا تعداد کل جلسات را به دست آورید، جلساتی را که در چند روز طول می کشد دوبرابر شمارش خواهید کرد.
  • بسته به هویت گزارش انتخابی شما، روش محاسبه تعداد کاربر باید به روز شود.
• ابعاد و محدوده متریک : اطمینان حاصل کنید که محاسبات شما از محدوده کاربر، جلسه، آیتم یا سطح رویداد درست استفاده می کند.
• منطقه زمانی : در صادرات BigQuery، event_date برای منطقه زمانی گزارش است در حالی که event_timestamp یک مهر زمانی UTC در میکروثانیه است. بنابراین، در حالت ایده‌آل، اگر فردی از event_timestamp در یک پرس و جو استفاده می‌کند، باید برای منطقه زمانی گزارش صحیح هنگام مقایسه با اعداد UI تنظیم شود.
• فیلتر کردن داده و محدودیت‌های صادرات : اگر فیلتر داده را برای صادرات رویداد BigQuery خود تنظیم کرده‌اید یا حجم صادرات رویداد روزانه شما از حد مجاز فراتر رفته است، داده‌های صادرات رویداد BigQuery با سطوح گزارش استاندارد مطابقت نخواهد داشت.

با همه اینها، در این پست مقداری UNNEST وجود دارد. امیدواریم بتوانید راه حل های مناسب برای پروژه متمایز خود را از دستورالعمل های اینجا انتخاب کنید. اگر سؤالی دارید، به سرور GA Discord بپیوندید.