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

Minhaz Kazi, Developer Advocate, Google Analytics – April 2023

„Warum stimmen die Zahlen aber nicht mit der Benutzeroberfläche überein?“

Wenn Sie mit den BigQuery-Ereignisexportdaten für Ihre GA4-Property gearbeitet haben, wurde diese Frage definitiv schon einmal gestellt. Oder noch schlimmer: Sie wurden von jemand anderem gefragt. Und während Sie versucht haben, sie zu beantworten, wurde Ihnen wahrscheinlich die gefürchtete Folgefrage gestellt:

„Und wo steht das?“

In diesem Artikel werden wir versuchen, beide Aspekte zu beleuchten.

Bevor wir genauer darauf eingehen, wie sich die Zahlen unterscheiden, müssen wir uns mit dem Zweck der Exportdaten von BigQuery-Ereignissen vertraut machen. Google Analytics-Nutzer senden ihre erhobenen Daten über eine der Erfassungsmethoden an Google Analytics: Google Tag, Google Tag Manager, Measurement Protocol, SDKs oder Datenimport. Basierend auf den Einstellungen der Google Analytics-Property werden die erhobenen Daten in Google Analytics erheblich ergänzt, bevor sie in die Standardberichtsoberflächen wie Standardberichte, explorative Datenanalysen und die Data API aufgenommen werden. Diese Ergänzungen können beispielsweise Google-Signale, Modellierung, Traffic-Attribution, Prognosen usw. umfassen.

Über die Standard-Berichtsoberflächen soll Nutzern möglichst wenig Beeinträchtigungen geboten werden. Uns ist jedoch bewusst, dass Nutzer aufgrund des breiten Spektrums an Nutzern eventuell den Mehrwert durch Google Analytics ergänzen oder sogar komplett auf sie zugeschnittene Lösungen anbieten möchten. Für diese Nutzer ist der BigQuery-Ereignisexport der vorgesehene Ausgangspunkt. Der Export von BigQuery-Ereignissen enthält erfasste Daten, die vom Client oder der App an Google Analytics gesendet werden. Der BigQuery-Ereignisexport enthält keine detaillierten Daten zu den meisten oben genannten Wertzusätzen.

Daher wird davon ausgegangen, dass sich die standardmäßigen Berichtsoberflächen und BigQuery-Exportdaten für eine Vielzahl von Anwendungsfällen nicht abgleichen lassen, wenn es um diese zusätzlichen Komponenten geht. Wenn beide Elemente eine interne Einheitlichkeit haben und sie mit dem übereinstimmen, was Sie erfassen, ist alles in Ordnung.

Beschäftigen wir uns nun mit den spezifischen Gründen für diese Unterschiede und sehen wir uns Möglichkeiten an, diese nach Möglichkeit zu minimieren. In diesem Artikel geht es nur um den täglichen BigQuery-Ereignisexport, nicht um den Streaming-Export.

Probenahme

Damit Sie Ihre BigQuery-Exportdaten genau mit Standardberichten, Data API-Berichten oder explorativen Datenanalysen vergleichen können, achten Sie darauf, dass sie nicht auf Stichproben basieren. Weitere Informationen und Möglichkeiten zur Stichprobenerhebung finden Sie unter Stichprobenerhebung in GA4.

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 der Messwert Nutzer insgesamt im explorativen Analysetool in der GA4-Benutzeroberfläche verfügbar ist, wird für Berichte in GA4 der primäre Nutzermesswert Aktive Nutzer verwendet. Wenn in der GA4-Benutzeroberfläche und in Berichten nur Nutzer erwähnt wird, bezieht sich dies in der Regel auf Aktive Nutzer. Wenn Sie also die Nutzerzahl aus BigQuery-Daten berechnen, müssen Sie nur die aktiven Nutzer filtern und beibehalten, damit die Zahlen mit der Google Analytics-Benutzeroberfläche vergleichbar sind. Die Berechnungsmethode richtet sich außerdem nach der ausgewählten Identität für die Berichterstellung.

Technische Implementierung

Wenn Sie in BigQuery-Ereignisexportdaten die einzelnen User-IDs zählen, erhalten Sie die Anzahl der Nutzer insgesamt. Hier ist eine Beispielabfrage, die sowohl „Nutzer insgesamt“ als auch „Neue Nutzer“ basierend auf user_pseudo_id anzeigt:

-- 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, begrenzen Sie die Abfrage auf Ereignisse, bei denen is_active_user den Wert true hat:

-- 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++

In Google Analytics wird der Algorithmus HyperLogLog++ (HLL++) verwendet, um die Kardinalität für gängige Messwerte wie „Aktive Nutzer“ und „Sitzungen“ zu schätzen. Wenn Sie sich also die eindeutige Anzahl dieser Messwerte in der Benutzeroberfläche oder über die API ansehen, handelt es sich um einen Näherungswert mit einer bestimmten Genauigkeit. Da Sie in BigQuery Zugriff auf die detaillierten Daten haben, können Sie die genaue Kardinalität dieser Messwerte berechnen. Daher können Messwerte nur um einen kleinen Prozentsatz variieren. Bei einem Konfidenzintervall von 95% kann die Genauigkeit für die Sitzungsanzahl ±1, 63% betragen. Die Genauigkeitsstufen variieren für verschiedene Messwerte und ändern sich je nach Konfidenzintervall. Unter HLL++-Skizzen finden Sie die Genauigkeitsstufen bei verschiedenen Konfidenzintervallen für verschiedene Precision-Parameter von HLL++.

Technische Implementierung

Unter Schätzung der eindeutigen Anzahl in Google Analytics erfahren Sie, wie HLL++ in Google Analytics implementiert wurde und wie Sie die Funktionalität mithilfe von BigQuery-Abfragen replizieren können.

Verzögerung bei der Datenerhebung

Die täglichen Exporttabellen werden erstellt, nachdem in GA alle Ereignisse für den Tag erfasst wurden. Die täglichen Tabellen können bis zu 72 Stunden nach dem Datum der Tabelle mit Ereignissen aktualisiert werden, deren Zeitstempel das Datum der Tabelle hat. Weitere Informationen und Beispiele Dies ist eher problematisch, wenn Ihre Firebase SDK- oder Measurement Protocol-Implementierung Offline- oder verzögerte Ereignisse sendet. Je nachdem, wann die Standardberichtsoberfläche und BigQuery innerhalb dieser 72 Stunden aktualisiert werden, können Unterschiede zwischen ihnen auftreten. Für eine solche Implementierung sollten Vergleiche mit Daten durchgeführt werden, die älter als 72 Stunden sind.

Berichte mit hoher Kardinalität

Angenommen, Sie rufen einen Bericht über Standardberichte oder die Data API auf. Der Bericht enthält große Datenmengen und Dimensionen mit hoher Kardinalität. Dimensionen mit hoher Kardinalität können dazu führen, dass der Bericht das Kardinalitätslimit der zugrunde liegenden Tabelle überschreitet. In diesem Fall werden weniger häufige Werte in Google Analytics gruppiert und mit Sonstiges gekennzeichnet.

Wenn das Kardinalitätslimit für die zugrunde liegende Tabelle anhand eines vereinfachten und kleinen Beispiels 10 Zeilen beträgt, ist Folgendes zu erwarten:

Wie Sie sehen, bleibt die Gesamtzahl der Ereignisse unverändert. Weniger häufige Werte werden jedoch gruppiert und Sie können die Tabelle nicht anhand einer Dimension noch einmal aggregieren. So lässt sich z. B. nicht aus der aggregierten Tabelle die Gesamtzahl der Ereignisse für eine bestimmte Stadt mit hoher Genauigkeit ableiten. Das Beispiel wird noch tiefgreifender, wenn Sie die aggregierten Daten nach einer beliebigen Dimension filtern.

Diese Gruppierung der Zeile „Sonstiges“ erfolgt nur im Berichtsmodul und in der Data API, wenn der Bericht das Kardinalitätslimit überschreitet. Wenn Sie Ihre Berechnungen in BigQuery durchführen, erhalten Sie immer die Ground-Truth-Daten – die detailliertesten Zeilen. Weitere Informationen zur Zeile „Sonstiges“ und Best Practices

Google-Signale

Das Aktivieren von Google-Signalen für Ihre GA4-Property bietet mehrere Vorteile, unter anderem die plattform- und geräteübergreifende Duplizierung von Nutzern. Wenn User-ID und Google-Signale nicht implementiert sind: Wenn ein Nutzer Ihre Website in drei verschiedenen Webbrowsern aufruft, wird dies in Google Analytics als drei verschiedene Nutzer gezählt und der BigQuery-Export hat drei separate user_pseudo_ids. Wenn Google-Signale aktiviert und die Person in allen drei Browsern in ihrem einzelnen Google-Konto angemeldet ist, wird ein Nutzer in Google Analytics dupliziert und seine Anzahl wird in den standardmäßigen Berichtsoberflächen angezeigt. BigQuery zeigt jedoch weiterhin drei separate user_pseudo_ids an. Im BigQuery-Export sind keine Google-Signale-Informationen verfügbar. Berichte mit Google-Signale-Daten weisen daher im Vergleich zum BigQuery-Export höchstwahrscheinlich eine geringere Nutzerzahl auf.

Dieser Effekt lässt sich am besten reduzieren, wenn Sie User-IDs in Ihrer GA4-Property implementieren und Google-Signale aktivieren. Dadurch wird die Deduplizierung zuerst basierend auf user_id durchgeführt. Bei angemeldeten Nutzern wird das Feld user_id in BigQuery ausgefüllt und kann für Berechnungszwecke verwendet werden. Nicht angemeldete Nutzer (d.h. Sitzungen ohne user_id) werden jedoch trotzdem zur Deduplizierung verwendet.

Für bestimmte Berichte in standardmäßigen Berichtsoberflächen gilt möglicherweise ein Grenzwert, sodass bestimmte Daten nicht zurückgegeben werden. Die meisten Informationen, für die Grenzwerte gelten können, sind normalerweise nicht im BigQuery-Export verfügbar.

Einwilligungsmodus und geschätzte Daten

Mit dem Einwilligungsmodus auf Websites und in mobilen Apps können Sie Google über den Cookie- oder App-ID-Einwilligungsstatus Ihrer Nutzer informieren. Wenn Besucher die Einwilligung verweigern, werden in GA4 die Lücken bei der Datenerhebung durch Conversion-Modellierung und Verhaltensmodellierung geschlossen. Keine der modellierten Daten sind im BigQuery-Ereignisexport verfügbar. Wenn der Einwilligungsmodus implementiert ist, enthält das BigQuery-Dataset Pings ohne Cookies, die von GA erfasst wurden. Jede Sitzung hat eine andere user_pseudo_id. Aufgrund der Modellierung gibt es Unterschiede zwischen den Standardberichtsoberflächen und den detaillierten Daten in BigQuery. Aufgrund der Verhaltensmodellierung sehen Sie beispielsweise im Vergleich zum BigQuery-Export möglicherweise weniger aktive Nutzer, da bei der Modellierung möglicherweise versucht wird, mehrere Sitzungen von einzelnen Nutzern vorherzusagen, die keine Einwilligung erteilt haben.

Um dies zu verhindern, sollten Sie User-IDs in Ihrer GA4-Property implementieren. user_id und benutzerdefinierte Dimensionen werden unabhängig vom Einwilligungsstatus der Nutzer nach BigQuery exportiert.

Traffic-Attributionsdaten

In BigQuery sind Traffic-Attributionsdaten auf Nutzer- (erster Besuch) und auf Ereignisebene verfügbar. Dies sind die gesammelten Daten. Da Google Analytics jedoch ein eigenes Attributionsmodell auf Sitzungsebene implementiert, sind diese Informationen weder direkt im BigQuery-Export verfügbar noch können sie mit den verfügbaren Daten vollständig genau berechnet werden. Je nach Anwendungsfall können Sie das BigQuery-Dataset mit allen relevanten selbst erhobenen Daten verknüpfen und ein eigenes Attributionsmodell erstellen. In Zukunft können zusätzliche erfasste Daten für die Traffic-Attribution über den BigQuery-Ereignisexport verfügbar sein.

Häufige Berechnungsfehler

• Berechnungsmethode:Achten Sie bei der Berechnung verschiedener Messwerte in BigQuery darauf, die richtige Methode zu verwenden. Beispiel:
  • Die Standardmethode zum Zählen von Sitzungen für Google Analytics 4-Properties besteht darin, die einzelnen Kombinationen aus user_pseudo_id/user_id und ga_session_id unabhängig vom Zeitraum zu zählen. In Universal Analytics werden Sitzungen um Mitternacht zurückgesetzt. Wenn Sie das UA-Modell verwenden, die Sitzungen für jeden Tag berechnen und die Gesamtzahl der Sitzungen addieren, werden die Sitzungen, die sich über mehrere Tage erstrecken, doppelt gezählt.
  • Abhängig von der ausgewählten Identität für die Berichterstellung muss die Berechnungsmethode der Nutzerzahl aktualisiert werden.
• Dimensions- und Messwertumfang: Für Ihre Berechnungen muss der richtige Umfang auf Nutzer-, Sitzungs-, Artikel- oder Ereignisebene verwendet werden.
• Zeitzone: Im BigQuery-Export gilt event_date für die Zeitzone der Berichterstellung und event_timestamp für einen UTC-Zeitstempel in Mikrosekunden. Wenn also event_timestamp in einer Abfrage verwendet wird, muss der Wert beim Vergleich mit Werten auf der Benutzeroberfläche an die richtige Zeitzone für die Berichterstellung angepasst werden.
• Datenfilterung und Exportlimits: Wenn Sie für den Export von BigQuery-Ereignissen die Datenfilterung eingerichtet haben oder das tägliche Exportvolumen das Limit überschritten hat, stimmen die Exportdaten der BigQuery-Ereignisse nicht mit den standardmäßigen Berichtsoberflächen überein.

Trotzdem gibt es in diesem Beitrag etwas UNNEST. Hoffentlich können Sie die richtigen Lösungen für Ihr Projekt AUS DEN Richtlinien hier AUSWÄHLEN. Wenn ihr Fragen habt, JOIN den GA Discord-Server WHERE-Abfragen sind sehr willkommen.