Allgemeine Grundsätze
Gut strukturierte Daten sind die Grundlage eines effektiven Decisioning Studio Pro Agents. Bevor Sie sich mit den spezifischen Anforderungen an einzelne Datenbestände befassen, ist es hilfreich, die vier Kernprinzipien zu verstehen, die für alle Daten gelten, die Sie an Decisioning Studio Pro senden. Verstöße gegen eines dieser Prinzipien gehören zu den häufigsten Ursachen für eine verschlechterte Modell-Performance.
Ein einheitlicher Kundenbezeichner für alle Assets
Jedes Daten-Asset (Kundenprofile, Aktivierungen, Engagements, Konversionen) muss auf denselben Kundenbezeichner verweisen. Es sollte genau einen primären Bezeichner geben, der jede:n Kund:in über alle Assets hinweg eindeutig und einheitlich identifiziert.
| Anforderung | Folgen bei Nichteinhaltung |
|---|---|
| In jedem Asset muss ein einziger, eindeutiger Kundenbezeichner vorhanden sein | Wenn verschiedene Assets unterschiedliche ID-Systeme verwenden (zum Beispiel eine Warehouse-ID für Features, aber eine Plattform-ID für Aktivierungen), kann die Decisioning Studio Pro Engine die Assets nicht zuverlässig miteinander verknüpfen. Dadurch wird die Feedbackschleife unterbrochen, und sowohl das Modelltraining als auch die Genauigkeit des Reportings verschlechtern sich. Stellt sich heraus, dass die Abbildung zwischen den beiden ID-Systemen nicht One-to-Many, sondern Many-to-Many ist, können die daraus resultierenden Probleme mit der Datenintegrität gravierend sein. |
Unter Externe Braze-ID verwenden erfahren Sie, welchen Bezeichner Sie verwenden sollten.
Event-Daten müssen als inkrementeller Stream übergeben werden
Events wie Conversions, Engagements und Aktivierungen stellen diskrete Ereignisse dar, die zu einem bestimmten Zeitpunkt stattgefunden haben. Übermitteln Sie jedes Event als eigenen Datensatz in einem inkrementellen (Append-only) Stream an Decisioning Studio Pro.
| Anforderung | Auswirkung bei Verstoß |
|---|---|
| Event-Daten müssen als einzelne, mit Zeitstempel versehene Datensätze strukturiert und inkrementell übermittelt werden | Wenn Event-Daten in einem Snapshot aggregiert werden (zum Beispiel durch Speicherung eines Attributs „Letzter Sendezeitpunkt“ anstelle einzelner Sendedatensätze), geht die genaue zeitliche Zuordnung jedes Events verloren. Dadurch wird es unmöglich, Ergebnisse präzise bestimmten Entscheidungen zuzuordnen, was die Feedback-Schleife unterbricht, die das Modell zum Lernen benötigt. Ohne präzise Event-Zeitstempel können Sie nicht genau wissen, wann eine Conversion stattgefunden hat oder welche Empfehlung sie ausgelöst hat. |
Unter Snapshots versus Event-Streams finden Sie eine vollständige Erklärung der Unterscheidung sowie Beispiele für korrekte und inkorrekte Muster.
Snapshot-Daten müssen regelmäßig nach einem zeitgesteuerten Zeitplan aktualisiert werden
Snapshot-Daten (wie Kundenprofile und Features) bilden den aktuellen Zustand von Kund:innen zu einem bestimmten Zeitpunkt ab. Aktualisieren Sie Snapshot-Daten regelmäßig nach einem festen Zeitplan (zum Beispiel täglich) für alle Kund:innen, auch für Kund:innen ohne neue Events.
| Anforderung | Auswirkung bei Nichteinhaltung |
|---|---|
| Snapshots müssen für alle Kund:innen regelmäßig nach einem festen Zeitplan aktualisiert werden, unabhängig davon, ob für Kund:innen an diesem Tag ein Event aufgetreten ist | Wenn Snapshot-Updates nur bei einem Event getriggert werden, veralten Features, die vom Verstreichen der Zeit abhängen (wie „Tage seit dem letzten Kauf“ oder „Tage seit der Anmeldung“), für Kund:innen ohne aktuelles Event. Das Modell wird dann mit veralteten Feature-Werten trainiert, was seine Fähigkeit verringert, präzise und zeitnahe Empfehlungen zu geben. |
Alle Assets müssen Mindestanforderungen an Datenqualität und Datenintegrität erfüllen
Neben der Struktur müssen die Daten selbst in sich konsistent und vollständig genug sein, um nützlich zu sein.
| Anforderung | Folgen bei Nichteinhaltung |
|---|---|
| Jedes Asset muss die Felder enthalten, die zum Festlegen eines Primärschlüssels und gegebenenfalls von Join-Schlüsseln zu anderen Assets erforderlich sind. Doppelte Datensätze müssen vor der Aufnahme entfernt oder dedupliziert werden. | Doppelte oder nicht zuordenbare Datensätze verursachen Rauschen beim Modelltraining und können zu fehlerhafter Attribution führen. Fehlende Schlüssel verhindern, dass die Engine Events entlang der Customer Journey von der Empfehlung bis zur Konversion verknüpft. |
Speziell für Event-Stream-Daten muss jeder Datensatz mindestens Folgendes enthalten:
Pflichtfelder:
- Bezeichner der Kund:innen
- Zeitstempel des Zeitpunkts, zu dem das Event eingetreten ist (der Zeitpunkt der Aktion selbst; unter Snapshots im Vergleich zu Event-Streams erfahren Sie, wie sich dieser vom Zeitstempel der Datensatzerstellung unterscheidet)
- Zeitstempel des Zeitpunkts, zu dem der Datensatz in Ihrem System erstellt wurde (wird für das zuverlässige Aufteilen inkrementeller Exporte verwendet)
- Event-Typ
- Felder, die ausreichen, um auf die spezifischen Events zu filtern, die für Sie relevant sind
Empfohlene Felder:
- Zusätzliche Event-Metadaten, die eine zuverlässige Zuordnung zwischen Event-Typen ermöglichen (zum Beispiel das Verknüpfen eines Konversions-Events mit der spezifischen Aktivierung, die ihm vorausging)