Tutorial: Echtzeit-Anomalieerkennung im E-Commerce für add_to_cart und begin_checkout

Ein täglicher statistischer Audit erkennt ein kaputtes Kauf-Event innerhalb eines Tages; während eines Flash-Sale oder direkt nach einem Deployment ist ein Tag zu langsam. Einen Rückgang bei add_to_cart- oder begin_checkout-Events zu erkennen, während er gerade passiert, braucht eine Datenquelle mit nur wenigen Minuten Verzögerung – der BigQuery-Export von GA4 läuft als täglicher Batch-Job und ist nicht für ein Dashboard gebaut, das sich alle paar Minuten aktualisiert. Die Realtime-Reporting-API von GA4 dagegen schon: Sie liefert Event-Zahlen aus ungefähr den letzten 30 Minuten und steht auf jeder GA4-Property zur Verfügung, auch in der kostenlosen Stufe.

Die folgende Anleitung baut ein schlankes operatives Dashboard rund um diese API. Es besteht aus einem Google Sheet, das alle paar Minuten per Apps Script aktualisiert wird. Darin stehen die aktuellen add_to_cart- und begin_checkout-Zahlen neben denen derselben Tageszeit eine Woche zuvor. Conditional Formatting färbt die betroffene Zelle rot, sobald der Rückgang eine Schwelle überschreitet.

Schritt 1: Live-Zahlen mit der Realtime-Reporting-API abrufen

Die Methode runRealtimeReport der GA4-Data-API akzeptiert eventName als Dimension und eventCount als Metrik, gefiltert auf die Echtzeitdaten der Property – kein BigQuery-Export ist dabei beteiligt. Der eingebaute Advanced Service „Analytics Data API“ von Apps Script kann sie direkt aus einem an das Dashboard-Sheet gebundenen Skript aufrufen:

function pullRealtimeCounts() {
  const propertyId = 'properties/XXXXXXXXX';
  const request = {
    dimensions: [{ name: 'eventName' }],
    metrics: [{ name: 'eventCount' }],
    dimensionFilter: {
      filter: {
        fieldName: 'eventName',
        inListFilter: { values: ['add_to_cart', 'begin_checkout'] }
      }
    }
  };
  const response = AnalyticsData.Properties.runRealtimeReport(request, propertyId);
  return response.rows || [];
}

Ein zeitgesteuerter Trigger führt diese Funktion alle fünf Minuten aus und hängt die beiden Zahlen mit Zeitstempel an ein Protokoll-Tabellenblatt an – das Rohmaterial, aus dem sowohl der Live-Status als auch der Baseline-Vergleich gebaut werden.

Schritt 2: Eine Baseline, leicht genug für eine Aktualisierung alle paar Minuten

Eine 14-Tage-Rolling-Z-Score-Baseline ist das richtige Werkzeug für einen täglichen statistischen Audit, für ein Live-Dashboard, das nur eine Frage schnell beantworten soll – liegt das aktuelle Volumen ungefähr dort, wo es gerade sein sollte –, ist sie überdimensioniert. Ein Vergleich mit demselben Wochentag zur selben Tageszeit genau sieben Tage zuvor lässt sich einfacher berechnen und ist für jemanden, der kurz auf einen Bildschirm schaut, leichter nachzuvollziehen. Möglich macht ihn ein zweiter Trigger, der einmal täglich läuft und die Tageszahlen stundenweise ablegt. So findet der aktuelle Abruf immer die passende Vorwochenstunde vor.

Schritt 3: Abweichung und Status berechnen

Eine Formelspalte verwandelt die beiden Zahlen in eine prozentuale Abweichung und ein Statuslabel:

=IF(baseline_count=0, "n/a",
   ROUND((current_count - baseline_count) / baseline_count * 100, 1))

Unterhalb von etwa zehn Baseline-Events verliert ein Prozentwert seine Aussagekraft – ein einzelnes fehlendes Event liest sich über Nacht wie ein 50-prozentiger Einbruch. Eine Mindest-Baseline-Schwelle (zum Beispiel den Status erst ab einer Baseline-Zahl über 20 auszuwerten) verhindert, dass das Dashboard in den ruhigsten Stunden unnötig Alarm schlägt.

Schritt 4: Rückgänge mit Conditional Formatting sichtbar machen

Die eigentliche Hervorhebung übernimmt eine Conditional-Formatting-Regel mit eigener Formel auf der Statusspalte: rot unterhalb von -30, gelb-orange zwischen -30 und -15, keine Füllung darüber. Das ist dasselbe visuelle Muster wie im Dashboard eines statistischen Audits, hier aber direkt in Sheets angewendet. Die operative Ansicht aktualisiert sich damit in dem Moment, in dem Apps Script eine neue Zeile anhängt – ohne zusätzliche Datenquelle und ohne Connector dazwischen.

Schritt 5: Dort platzieren, wo das Team tatsächlich hinschaut

Das Sheet funktioniert für sich allein für jeden mit Bearbeitungs- oder Ansichtsrecht, aber es während eines Launch-Fensters auf einen gemeinsam genutzten Bildschirm zu pinnen oder es als eine von mehreren Kacheln in Looker Studio einzubinden, hält es sichtbar, ohne dass jemand das Sheet geöffnet haben muss. Beim Einbinden in Looker Studio muss die Aktualisierungshäufigkeit des Sheets-Connectors gegenüber der Voreinstellung heruntergesetzt werden – sonst steckt eine Fünf-Minuten-Aktualisierung durch Apps Script hinter einem deutlich langsameren Cache, und der eigentliche Zweck des Aufbaus geht verloren.

Innerhalb der Leitplanken bleiben

Dieses Dashboard ist eine Live-Symptomprüfung, kein Ersatz für den statistischen Audit, der gegen die abgeschlossenen Tagesdaten läuft – es übersieht einen langsamen, allmählichen Rückgang, der in keinem einzelnen Fünf-Minuten-Fenster die Schwelle überschreitet, und genau dafür ist eine rollende Baseline da. Eine rote Zelle hier ist der Anlass, nachzusehen, nicht für sich genommen ein bestätigter Vorfall: Ein Flash-Sale, der das add_to_cart-Volumen legitim verdreifacht, oder eine wirklich ruhige Stunde können beide einen Ausschlag außerhalb der Schwelle erzeugen, ohne dass etwas kaputt ist.