Die Lücke zwischen der Google Analytics-Benutzeroberfläche und BigQuery Export schließen

Minhaz Kazi, Developer Advocate, Google Analytics – April 2023

„Aber warum stimmen die Zahlen nicht mit der Benutzeroberfläche überein?“

Wenn Sie BigQuery-Ereignisexportdaten für Ihre GA4-Property verwendet haben, Sie haben diese Frage bestimmt schon einmal gestellt. Oder schlimmer, jemand anderes hat Ihnen das gefragt. Vermutlich wurden Sie beim Beantworten dieser Frage gefragt, gefürchtete Anschlussfrage:

„Und wo sagt er das?“

In diesem Post möchten wir auf beides eingehen.

Bevor wir näher auf die Unterschiede zwischen den Zahlen eingehen, sollten Sie wissen, den vorgesehenen Zweck der BigQuery-Ereignisexportdaten. Google Analytics-Nutzer Ihre erhobenen Daten mithilfe einer der folgenden Methoden an Google Analytics senden: Google Tag, Google Tag Manager, Measurement Protocol, SDKs und Datenimport. Basierend auf den Einstellungen der Google Analytics-Property liefert Google Analytics einen signifikanten Wert, den erfassten Daten hinzuzufügen, bevor sie die standardmäßigen Berichtsoberflächen erreichen. darunter Standardberichte, das explorative Analysetool und die Data API. Diese Werte Ergänzungen können Google-Signale, Modellierung, Zugriffe Attribution, Vorhersage usw.

Über die standardmäßigen Berichtsoberflächen wird versucht, Google Analytics-Nutzern den größtmöglichen Nutzen zu bieten, Reibungspunkte haben. Uns ist jedoch bewusst, dass es aufgrund des breiten Spektrums an Nutzern Manche möchten vielleicht die Wertschöpfung durch Google Analytics ergänzen oder sogar etwas ganz Individuelles zu gestalten. Für diese Nutzer ist der BigQuery-Ereignisexport beabsichtigten Ausgangspunkt. Der BigQuery-Ereignisexport enthält erhobene Daten, der vom Client oder der App an Google Analytics gesendet wird. BigQuery-Ereignisexport enthalten keine detaillierten Daten zu den meisten oben genannten Wertzusätzen.

Daher sind für eine große Anzahl von Anwendungsfällen die standardmäßigen Berichtsoberflächen und Es wird davon ausgegangen, dass die BigQuery-Exportdaten in diesen Fällen nicht abgleichbar sind. Teile zur Wertsteigerung. Wenn es interne Konsistenz gibt und sie übereinstimmen mit den gesammelten Daten.

Sehen wir uns nun einige Gründe für die Unterschiede an. und Möglichkeiten, diese einzudämmen. In diesem Beitrag geht es um Es werden nur tägliche Ereignisse und nicht der Streaming-Export exportiert.

Probenahme

Für einen genauen Vergleich Ihrer BigQuery-Exportdaten mit Standardberichten, klicken Sie auf „Daten“ API-Berichte oder explorativen Datenanalysen bestätigen, dass sie nicht auf Stichproben basieren. Stichprobenerhebung in GA4 bietet weitere Details und Möglichkeiten für die Stichprobenerhebung.

Aktive Nutzer

Wenn Sie alle Nutzer zählen, für die in Ihrer GA4-Property mindestens ein Ereignis protokolliert wurde erhalten Sie den Messwert Nutzer insgesamt. Obwohl die Spalte Nutzer insgesamt ist im explorativen Analysetool in der GA4-Benutzeroberfläche verfügbar. Das ist der primäre Nutzermesswert Bericht in GA4 lautet Aktive Nutzer. In der GA4-Benutzeroberfläche und in Berichten, wenn nur Nutzer erwähnt wird und sich in der Regel auf Aktive Nutzer bezieht. Wenn Sie also die Anzahl der aus BigQuery-Daten ermitteln möchten, müssen Sie nur die aktiven Nutzer damit die Zahlen mit denen auf der Google Analytics-Benutzeroberfläche vergleichbar sind. Die Berechnungsmethode variieren je nach der ausgewählten Identität für die Berichterstellung.

Technische Implementierung

Wenn Sie bei BigQuery-Ereignisexportdaten die Anzahl verschiedener Nutzer-IDs zählen, erhalten Sie die Anzahl der Nutzer insgesamt. Hier sehen Sie eine Beispielabfrage, mit der sowohl Nutzer und neue Nutzer basierend auf 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;

Wenn Sie nur aktive Nutzer auswählen möchten, beschränken Sie die Abfrage auf Ereignisse, bei denen is_active_user ist 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 verwendet den Algorithmus HyperLogLog++ (HLL++), um die Kardinalität zu schätzen für gängige Messwerte wie „Aktive Nutzer“ und „Sitzungen“. Wenn Sie sich also die eindeutige Anzahl dieser Messwerte in der Benutzeroberfläche oder über die API, Approximation mit einer gewissen Genauigkeit verwenden können. Da Sie in BigQuery Zugriff auf können Sie die genaue Kardinalität dieser Messwerte berechnen. Also Messwerte können um einen kleinen Prozentsatz variieren. Bei einem Konfidenzintervall von 95 % kann die Precision bei ±1,63% für die Sitzungsanzahl liegen. Die Precision-Stufen variieren für und ändert sich je nach Konfidenzintervall. Weitere Informationen finden Sie unter HLL++ Sketches für die Genauigkeitsstufen in verschiedenen Konfidenzintervallen für mit unterschiedlichen Präzisionsparametern von HLL++.

Technische Implementierung

Weitere Informationen zur Schätzung der Anzahl eindeutiger Impressionen in Google Analytics die in Google Analytics implementiert wurden und wie Sie diese Funktionen replizieren können, mit BigQuery-Abfragen.

Verzögerung bei der Datenerhebung

Die täglichen Exporttabellen werden erstellt, nachdem alle Ereignisse des Tages in Google Analytics erfasst wurden. Die täglichen Tabellen können bis zu 72 Stunden nach dem Datum der Tabelle aktualisiert werden. mit Ereignissen, die mit dem Datum der Tabelle versehen sind. Details lesen und Beispiele. Dies ist eher problematisch, wenn Ihre Firebase SDK- oder Measurement Protocol-Implementierung sendet, Verzögerungen auftreten. Je nachdem, wann die Standard-Berichtsoberfläche und BigQuery innerhalb dieser 72 Stunden aktualisiert werden, kann es zu Abweichungen kommen, zwischen ihnen aufbauen. Für eine solche Implementierung sollten Vergleiche mit Daten durchgeführt werden, die älter sind als als 72 Stunden.

Berichte mit hoher Kardinalität

Angenommen, Sie zeigen einen Bericht über Standardberichte oder die Data API an. Der Bericht enthält eine große Datenmenge und Dimensionen mit hohem Kardinalität. Dimensionen mit hoher Kardinalität können dazu führen, dass der Bericht die Kardinalitätsgrenzwert für die zugrunde liegende Tabelle. In diesem Fall werden in Google Analytics werden weniger häufige Werte gruppiert und als (other) gekennzeichnet.

Anhand eines vereinfachten und kleinen Beispiels, wenn das Kardinalitätslimit für die zugrunde liegende Tabelle zehn Zeilen hat, sollten Sie Folgendes erwarten:

Wie Sie sehen, bleibt die Gesamtzahl der Ereignisse unverändert. Weniger werden häufige Werte gruppiert und Sie können die Tabellen nicht erneut aggregieren, für jede Dimension (z.B. können Sie nicht anhand der zusammengefassten Tabelle die Gesamtsumme Ereignisanzahl für eine bestimmte Stadt mit hoher Genauigkeit). In diesem Beispiel werden mehr wenn Sie die aggregierten Daten nach einer der Dimensionen filtern.

Diese Gruppierung der Zeile „Sonstiges“ erfolgt nur im Berichtsmodul und Data API, wenn der Bericht das Kardinalitätslimit überschreitet. Wenn Sie Ihr mit BigQuery berechnet, erhalten Sie am Ende immer die Ground-Truth-Daten – die detailliertesten Zeilen. Weitere Informationen zur Zeile „Sonstiges“ und Best Practices auf vermeiden

Google-Signale

Die Aktivierung von Google-Signalen in Ihrer GA4-Property bietet mehrere Vorteile: plattform- und geräteübergreifend dedupliziert werden. Wenn Sie keine Daten zu IDs identifiziert oder Google-Signale aktiviert und ein Nutzer ruft Ihre Website auf drei unterschiedlichen Webbrowsern verwendet werden, ordnet Google Analytics diese Aktivität drei Nutzer und BigQuery Export hat drei separate user_pseudo_ids. Wenn Google-Signale aktiviert sind und die Person sich in ihrem Google-Konto in allen drei Browsern verwenden, schreibt Google Analytics Aktivitäten auf einen Nutzer und spiegelt diese in den standardmäßigen Berichtsoberflächen wider. BigQuery zeigt jedoch weiterhin drei separate user_pseudo_ids an, Informationen zu Google-Signalen sind im BigQuery-Export nicht verfügbar. Das heißt: in Berichten mit Daten aus Google-Signalen ist die Anzahl der Nutzer höchstwahrscheinlich niedriger als in BigQuery Export.

Dieser Effekt lässt sich am besten verringern, wenn Sie in GA4 User-IDs implementieren. und Google-Signale zu aktivieren. Dadurch wird sichergestellt, Die Deduplizierung erfolgt zuerst basierend auf user_id. Für angemeldete Nutzer: user_id wird in BigQuery mit Daten gefüllt und kann für Berechnungszwecke verwendet werden. Für nicht angemeldete Nutzer, d.h. Sitzungen ohne user_id, Google-Signale werden weiterhin für die Deduplizierung verwendet.

Bestimmte Berichte in Standardberichten Schwellenwert angewendet werden, sodass bestimmte Daten nicht zurückgegeben werden. Die meisten Informationen, die einem Grenzwert unterliegen, sind im BigQuery-Export normalerweise nicht verfügbar.

Einwilligungsmodus und geschätzte Daten

Mit dem Einwilligungsmodus auf Websites und in Apps können Sie Cookie- oder App-ID-Einwilligungsstatus an Google. Wenn Besucher ihre Einwilligung verweigern, GA4 füllt die Lücken bei der Datenerhebung durch Schlüsselereignis-Modellierung und Verhaltensregeln. Modellierung. Im BigQuery-Ereignisexport sind keine der modellierten Daten verfügbar. Wenn der Einwilligungsmodus implementiert ist, enthält das BigQuery-Dataset Pings ohne Cookies und jede Sitzung hat ein anderes user_pseudo_id. Aufgrund von Modellierung, unterscheiden sich die Standardberichtsoberflächen und die detaillierten Daten in BigQuery. Durch Verhaltensmodellierung können Sie z. B. die Anzahl der aktiven Nutzer im Vergleich zum BigQuery-Export kann die Modellierung versuchen, mehrere Sitzungen von einzelnen Personen ohne Einwilligung Nutzenden.

Auch hier sollten Sie User-IDs in GA4 implementieren, um die Auswirkungen zu reduzieren. Property. user_id und benutzerdefinierte Dimensionen werden unabhängig von den Einwilligungsstatus der Nutzer.

Traffic-Attributionsdaten

In BigQuery sind Traffic-Attributionsdaten verfügbar für Nutzer (erster Besuch) und Ereignisebene fest. Dies sind die gesammelten Daten. Da Google Analytics ein eigenes Attributionsmodell auf Sitzungsebene implementiert, sind weder direkt in BigQuery Export verfügbar, noch können sie mit vollständigen Genauigkeit mit den verfügbaren Daten. Je nach Anwendungsfall können Sie Zusammenführen des BigQuery-Datasets mit relevanten selbst erhobenen Daten und Ihr eigenes Attributionsmodell erstellen. Künftig werden zusätzliche erhobene Daten Attribution ist möglicherweise über den BigQuery-Ereignisexport verfügbar.

Häufige Berechnungsfehler

• Berechnungsmethode:Bei der Berechnung verschiedener Messwerte in BigQuery sicherzustellen, dass Sie die richtige Methode verwenden. Beispiel:
  • Die Standardmethode zum Zählen von Sitzungen für Google Analytics 4 die einzelnen Kombinationen aus user_pseudo_id/user_id und ga_session_id unabhängig von Zeitraum. In Universal Analytics werden Sitzungen um Mitternacht zurückgesetzt. Wenn anhand des UA-Modells die Sitzungen für jeden Tag bis die Gesamtzahl der Sitzungen ermittelt wird, Sitzungen über mehrere Tage hinweg.
  • Abhängig von Ihrer ausgewählten Identität für die Berichterstellung wird die Nutzerzahl Berechnungsmethode aktualisieren.
• Umfang für Dimensionen und Messwerte: Für Ihre Berechnungen muss die Methode auf Nutzer-, Sitzungs-, Artikel- oder Ereignisebene.
• Zeitzone: In BigQuery Export steht event_date für die Berichtszeit. Zone und event_timestamp ein UTC-Zeitstempel in Mikrosekunden. Also Wird event_timestamp in einer Abfrage verwendet, muss dieses im Idealfall die korrekte Zeitzone für Berichte beim Vergleich mit UI-Zahlen verwenden.
• Datenfilterung und Exportbeschränkungen: Sie haben die Datenfilterung eingerichtet für Ihren BigQuery-Ereignisexport oder die Anzahl der täglichen Ereignisexporte überschritten nicht erreicht haben, stimmen die BigQuery-Ereignisexportdaten nicht mit dem Berichtsoberflächen.

In diesem Beitrag gibt es einiges zu UNNEST. Hoffentlich können Sie SELECT die richtigen Lösungen für Ihr Projekt AUS den Richtlinien hier zu unterscheiden. Wenn Sie Haben Sie noch Fragen? MITGLIED WERDEN JOIN the Discord-Server WHERE Abfragen sind willkommen!