Snapshots versus Event-Streams

Daten lassen sich in eine von zwei grundlegenden Kategorien einteilen: Snapshots (Zustand) und Event-Streams (was passiert ist). Diesen Unterschied zu verstehen und korrekt anzuwenden, ist einer der wichtigsten Schritte, um sicherzustellen, dass Ihr Decisioning Studio Pro-Agent effektiv lernt.

Snapshot-Daten (Zustand)

Ein Snapshot bildet den Zustand von Kund:innen zu einem bestimmten Zeitpunkt ab. Er beantwortet die Frage: „Wie sieht diese:r Kund:in gerade aus?“

Ein Snapshot ist statisch und aggregiert. Er spiegelt das kumulierte Ergebnis aller Änderungen bis zu diesem Zeitpunkt wider. Das eignet sich am besten für Kundenprofile und berechnete Features (zum Beispiel „Tage seit dem letzten Kauf“, „Kundenbindungsstufe“, „Churn-Score“).

Erforderliche Felder

So sollten Snapshots aktualisiert werden

• Trigger: Zeitgesteuert. Erstellen Sie Snapshots nach einem festen Zeitplan (zum Beispiel täglich) und beziehen Sie auch Kund:innen ohne Aktivität an diesem Tag ein.
• Umfang: Jedes Update muss alle relevanten Kund:innen enthalten, auch diejenigen ohne Event.
• Methode: Hängen Sie neue Snapshot-Datensätze an den Datensatz an, anstatt vorherige Werte zu überschreiben. So bleibt der historische Zustand für das Trainieren von Modellen erhalten.

Snapshot-Daten für die tägliche Zustellung abfragen

Decisioning Studio Pro führt seine Empfehlungspipeline einmal pro Tag aus. Exportieren Sie bei der Zustellung von Snapshot-Daten bei jedem Pipeline-Lauf den Snapshot des Vortags:

1
2
3

SELECT *
FROM snapshot_data
WHERE snapshot_date = {t-1} -- on pipeline run date t, export the snapshot from t-1

Event-Stream-Daten (Flow)

Ein Event-Stream zeichnet einzelne Aktionen in dem Moment auf, in dem sie stattfinden. Er beantwortet die Frage: „Was hat diese:r Kund:in getan, und wann?“ Ein Event-Stream eignet sich ideal für rohe, unveränderliche, inkrementelle und chronologische Daten. Jeder Datensatz steht für ein Ereignis, das zu einem bestimmten Zeitpunkt stattgefunden hat. Verwenden Sie diesen Datenstream zum Beispiel für Aktivierungsdatensätze, Engagement-Protokolle (Öffnungen, Klicks), Konversions-Events oder Gutscheineinlösungen.

Pflichtfelder

Wichtig

Der Event-Zeitstempel und der Erstellungszeitstempel sind unterschiedliche Felder, und beide sind erforderlich. Der Event-Zeitstempel hält fest, wann die Aktion tatsächlich stattgefunden hat. Der Erstellungszeitstempel hält fest, wann der Dateneintrag in Ihr System geschrieben wurde. Das kann aufgrund von Verarbeitungsverzögerungen später sein. Verwechseln Sie die beiden nicht.

So sollten Event-Streams aktualisiert werden

• Trigger: Event-gesteuert. Neue Datensätze werden hinzugefügt, wenn neue Events eintreten.
• Umfang: Nur Kund:innen, bei denen ein Event eingetreten ist, erhalten neue Datensätze.
• Methode: Bestehende Datensätze sind unveränderlich. Updates erfolgen immer als Einfügen neuer Datensätze.

Event-Daten für die tägliche Zustellung abfragen

Unterteilen Sie tägliche Exporte nach create_timestamp. Events werden manchmal erst nach ihrem Eintreten in Ihr System geschrieben (verspätete Eingänge). Wenn Sie nach event_timestamp unterteilen, gehen diese verspätet eingehenden Datensätze dauerhaft verloren.

1
2
3
4

-- Correct: use create_timestamp to ensure late-arriving events are captured
SELECT *
FROM events_data
WHERE DATE(create_timestamp) = {t-1} -- on run date t, export all records created yesterday

1
2
3
4

-- Incorrect: slicing on event_timestamp will permanently lose late-arriving events
SELECT *
FROM events_data
WHERE DATE(event_timestamp) = {t-1}

Ein Beispiel: Wenn ein Event am 1. Januar stattgefunden hat, aber erst am 2. Januar in Ihr System geschrieben wurde, würde eine Unterteilung nach event_timestamp am 2. Januar dieses Event vollständig übersehen. Eine Unterteilung nach create_timestamp erfasst es korrekt.

Für native Braze-Integrationen

Braze bietet zwei integrierte Mechanismen, die diesen beiden Datentypen direkt entsprechen.

Angepasste Attribute: Snapshot-Daten

Angepasste Attribute speichern den Status auf Nutzerebene zu einem bestimmten Zeitpunkt. Verwenden Sie sie für Kundenprofile und berechnete Features (zum Beispiel churn_score, total_purchases_last_30d). Jedes Update überschreibt den vorherigen Wert. Das Attribut enthält also den neuesten Status, und frühere Events gehen verloren.

Braze-Currents: Event-Stream-Daten

Braze-Currents liefert rohe, unveränderliche Event-Daten. Die Tabelle USER_BEHAVIOR_CUSTOM_EVENTS erfasst jede Instanz eines angepassten Events, sobald es eintritt. Damit ist sie die richtige Quelle für Aktivierungs-, Engagement- und Konversions-Events.

Tipp

Behandeln Sie angepasste Attribute als Quelle für den Kundenstatus und Braze-Currents als Quelle für Kundenverhalten-Events. Verwenden Sie keine angepassten Attribute, um rohe Event-Daten an Decisioning Studio Pro zu übergeben.

Häufige Probleme

Event-Daten als Snapshot übergeben

Wenn Sie Event-Daten zu Snapshot-Feldern aggregieren, bevor Sie sie an Decisioning Studio Pro senden, entstehen mehrere Probleme:

• Verlust der Granularität: Nachdem die Daten zu einer täglichen Zusammenfassung auf Kundenebene aggregiert wurden, sind die einzelnen Event-Datensätze verloren. Decisioning Studio Pro kann sie nicht rekonstruieren.
• Ungenaue Zeitstempel: Ein Feld wie „last_email_sent“ zeigt Ihnen zwar das letzte Vorkommen, verliert aber den vollständigen Verlauf der Events und macht eine präzise Attribution unmöglich.
• Phantom-Updates: Selbst an Tagen, an denen keine Events aufgetreten sind, wird der Snapshot-Datensatz aktualisiert. Dadurch entstehen doppelte Einträge, die sich nur schwer deduplizieren lassen.

Wenn Sie Braze verwenden, liefern Sie Event-Rohdaten mit Currents-Exporten an Decisioning Studio Pro.

Snapshot-Daten bei einem Event-Trigger aktualisieren

Einige Implementierungen aktualisieren Snapshot-Daten nur, wenn ein Event eintritt, beispielsweise indem ein Feature nur dann neu berechnet wird, wenn Kund:innen einen Kauf tätigen. Dadurch veralten Features, die vom Zeitablauf abhängen, für Kund:innen, die in letzter Zeit kein Event hatten.

Ein Feature wie days_since_last_purchase hat beispielsweise jeden Tag einen anderen korrekten Wert. Wenn es nur bei einem Kauf neu berechnet wird, bleibt es für alle Kund:innen, die in letzter Zeit nichts gekauft haben, auf einem falschen Wert stehen. Aktualisieren Sie Snapshot-Daten daher immer nach einem zeitgesteuerten Zeitplan, der alle Kund:innen abdeckt – und zwar jeden Tag.