Die Modellschicht unter dem Knoten „Entscheiden“ besteht aus einem markenspezifischen Verhaltensmodell (einem Ereignissequenzmodell des Verhaltens jedes Mitglieds) und einer Digitalen-Zwilling-Schicht, die dieses Modell weiterführt (kontrafaktische Simulation und das synthetische Forschungspanel). Diese Seite beschreibt die Aspekte, die ein Integrator tatsächlich bearbeiten kann: die zugrunde liegenden Ereignisse, die Entscheidungskriterien, die Ausgabeflächen und die MCP-Tools, die das Panel steuern.
Nutzen Sie die unten aufgeführten, schreibgeschützten Endpunkte REST oder die Tools MCP für die Vorhersage eines einzelnen Mitglieds. Ergebnisse zum nächsten Verhalten und persönliche Kauffenster teilen sich eine Antwort mit expliziten Verfügbarkeits- und Berechtigungsprüfungen. Ereignisse werden weiterhin über die normalen Integrationsschnittstellen erfasst; zusätzliche Ausgaben erscheinen in Segmenten, Mitgliedsprofilen, Lookalike-Profilen, Sendezeitoptimierung und dem synthetischen Panel.
Nächste Verhaltensweisen, Kauffenster und Nachfragekontext
Die Vorhersage eines einzelnen Mitglieds gibt das nächste Verhalten und persönliche Kauffenster zurück und kombiniert Verbrauchersignale mit dem Kontext der Markennachfrage, wenn der Mieterfusionsleiter bereit ist.
Interaktives Beispiel
Ein Kunde. Eine Prognoseantwort.
Alle Zustände und Zahlen sind synthetische Beispiele, keine Live-Vorhersagen oder Angaben zur Einsatzbereitschaft im Arbeitsbereich. Es werden keine Kundendaten übermittelt.
Teilergebnis
Verhaltensprognosen bleiben verfügbar. Kauffenster sind erst verfügbar, nachdem der Fusion Head der Marke trainiert und validiert wurde.
Was könnte als Nächstes passieren?
Eine abschließende Verteilung über die vier unterstützten Ereignisse dieses Beispiels. Die Wahrscheinlichkeiten für das nächste Ereignis sind nicht kalibriert.
Nächstes Ereignis
Wahrscheinlichkeit
Kaufen
37%
Portalbesuch
28%
E-Mail-Klick
21%
Couponeinlösung
14%
Warum fehlt eine Veranstaltung?
Bei der gesendeten E-Mail handelt es sich um ein Eingabekontextereignis und nicht um ein Vorhersageziel. Seine Wahrscheinlichkeit ist null. Andere nicht unterstützte oder nicht abgedeckte Ereignisse bleiben ebenfalls nicht verfügbar.
Ersetzen Sie den API-Host, die Mitglieds-UUID und den API-Schlüssel durch Ihre Arbeitsbereichswerte.
Erforderlicher Zugriff · predictions:read Rückgabeverhalten. Gewähren Sie auch metrics:read (oder *) um Kauffenster zu aktivieren, wenn das Modell fertig ist.
Auszug aus der Antwort anzeigen
Nur synthetischer Auszug. Antworten des Markenmodells enthalten zusätzlich den vollständigen Veranstaltungskatalog und die Metadaten zur Abdeckung; öffentliche Referenzen verwenden ein separates Vokabular mit sechs Klassen.
Beispielprognose basierend auf 128 Tagen synthetischer Historie. Vergleichen Sie das aktuelle Muster mit der zukünftigen Tagesnachfrage und ihren Quantilen.
Synthetisches Beispiel, generiert mit TimesFM 2,5 Gewichtungen. Die Prognose beginnt am 05.10.2026 (UTC); die Daten sind für die Demo festgelegt. Die Quantilabdeckung ist nicht kalibriert. Die Werte stellen weder die Kundennachfrage noch individuelle Kaufwahrscheinlichkeiten dar.
Eine vollständige Verteilung des nächsten Verhaltens
Sie erhalten eine abschließende Wahrscheinlichkeitsverteilung und ein Ranking. Das bewertete Markenmodell hat Priorität und umfasst bis zu 23 Ziele. Ist es nicht verfügbar, bilden interne, öffentlich priorisierte Modelle eine einzige Referenz mit sechs Klassen. Nicht unterstützte und kontextbezogene Ereignisse bleiben weiterhin nicht verfügbar.
7-/30-/90-Tage-Kauffenster
Automatisch in der Mitgliederantwort enthalten: Ein mieterfreundlicher Leichtbaukopf kombiniert CWM-Signale mit TimesFM-Markentrends. Sofort einsatzbereite Köpfe sind sofort einsatzbereit; fehlende Schulungen oder Evaluierungen verhindern lediglich den Kauf.
Tägliche Marken- und Kategorieprognosen
Wenn der TimesFM 2.5-Service konfiguriert ist und die tägliche Historie vollständig ist, können Sie Umsatz, Aufträge oder verkaufte Einheiten für bis zu 90 Tage mit Punktprognosen und neun Quantilen prognostizieren.
So interpretieren Sie diese Ergebnisse
Die Wahrscheinlichkeiten für das nächste Ereignis summieren sich über alle unterstützten Kandidaten zu 100 % und sind nicht kalibriert. Kauffenster schätzen separat mindestens einen Kauf innerhalb von 7/30/90 Tagen und sind kumulativ, niemals mit Ereignisklassen normalisiert. Verstrichene Stille wird im Ereignisvektor nicht berücksichtigt. Die öffentliche Prior-Referenz hat keine Workspace-Validierung erhalten.
Nachfragequantile beschreiben die aggregierte Unsicherheit; sie stellen keine individuellen Kaufintervalle dar und wurden nicht kalibriert. Fehlende Daten sind weiterhin nicht verfügbar. Eine Genauigkeitssteigerung wird erst nach Ihrer eigenen Bewertung zugesichert.
Integrationsdetails und Verfügbarkeit
# Bearer API key; predictions:read
GET /api/v2/cwm/capabilities
GET /api/v2/cwm/members/{id}/next-behaviors
# metrics:read additionally enables purchaseWindows in next-behaviors
# predictions:read AND metrics:read for standalone trend/windows
GET /api/v2/cwm/trends?metric=gmv&horizon_days=30
GET /api/v2/cwm/members/{id}/purchase-windows
# Read-only MCP equivalents
cwm_get_forecast_capabilities
cwm_predict_next_behaviors
cwm_forecast_aggregate_trend
cwm_predict_purchase_windows
Kaufwahrscheinlichkeiten verwenden Einheiten von 0 bis 1 und kumulative, monotone Fenster. Bis zum Training und der Validierung enthält die Antwort Wahrscheinlichkeiten: {"7":null,"30":null,"90":null} und kalibriert: falseVorhanden CWM Die Massenwerte von 0 bis 100 behalten ihre Bedeutung. Aggregierte Prognosen liefern einen Punkt und das 10. bis 90. Quartil pro vollständigem UTC-Tag; fehlende Tagesintervalle werden nicht mit Null aufgefüllt. Kategorienamen erfordern catalog_gmv oder units_soldDie Entwurfs-Eingabemetriken werden offengelegt. Die Autorisierung von Mandanten und Mitgliedern erfolgt weiterhin serverseitig. Die Bereitschaft zeichnet sich aus durch service_unavailable, awaiting_training, awaiting_validation und bereit. TimesFM 2.5 Gewichte verwenden Apache 2.0.
Nächste-Verhaltens-Reaktionen verwenden predictionKind: next_event und Einheit: probability_0_1Eine Antwortmöglichkeit umfasst die Verteilung und purchaseWindowsDie Ergebnisse einzelner Experten sind intern. Die Kauffusion wird automatisch ausgelöst, sobald der Zugriff auf die Metriken dies zulässt. Ein validierter Mandantenkopf liefert kumulative 7/30/90-Tage-Wahrscheinlichkeiten; fehlende Berechtigungen, Schulungen, Validierungen oder Eingaben lassen alle Fenster leer. null mit expliziter Begründung. Verfügbare Verhaltensvorhersagen bleiben lesbar. Diese Fenster werden nicht mit der Verteilung des nächsten Ereignisses summiert. Die Zeilen des Markenmodells enthalten alle 48 Standardereignisse: 26 sind Konsumentenverhalten, 39 werden in das Sequenzvokabular aufgenommen und 23 ist die Obergrenze des Vorhersageziels. Nur abgedeckte Kandidaten, die von der aktiven, bewerteten Generation unterstützt werden, erhalten Wahrscheinlichkeiten; alle anderen Zeilen haben eine Wahrscheinlichkeit: null und eine explizite Verfügbarkeit. Die Abdeckung der Eingabefrequenzen älterer Systeme liefert schwächere Belege für die Korpuspräsenz und kann Herkunftsmaskierungs-Tag-Ziele nicht zertifizieren. Neue Snapshots verwenden positive Ziele aus den Trainingsfenstern des Optimierers, wobei Validierungsmitglieder und maskierte Zeilen ausgeschlossen werden. Die endgültige Verteilung umfasst den Rang, entropyBits, retainedModelMass, coverageBasis, modelVersion und kalibriert: falseEin verfügbares, evaluiertes Markenmodell wird direkt verwendet, ohne alternative Expertenergebnisse anzufordern. Andernfalls werden gültige öffentliche Priorverteilungen intern gleichmäßig zu einer reduzierten pv/fav/cart/buy/rmcart/-Verteilung gemittelt. buy_disc Referenz. Aggregation unterscheidet single_tenant_model von uniform_valid_expertsDas Vokabular identifiziert den Kandidatenschlüsselraum. Die beiden Vokabulare werden niemals vermischt. Die einheitliche Referenz ist kein gelerntes Multiklassen-Gateway und wird nicht mandantenvalidiert; die Abdeckung des öffentlichen Klassentrainings ist nicht verifiziert. Eine gerundete Masse von Null beweist kein fehlendes Klassentraining. Dieser Endpunkt benötigt predictions:read; purchaseWindows zusätzlich benötigt metrics:read oder *. Ohne Metrikberechtigung meldet die Kaufkomponente metrics_scope_required und führt keine Metrik- oder Fusionsabfrage durch. Der Status ist nur dann in Ordnung, wenn beide Komponenten verfügbar sind, eingeschränkt bei Teil-/Referenzergebnissen und nicht verfügbar, wenn keine der Komponenten verfügbar ist. Speicherzugriff und Berechtigung zur Live-Verarbeitung werden vor der externen Verarbeitung erneut geprüft; unzureichende Nachweise bleiben verfügbar. Eine Anfrage teilt ihren Live-Status. CWM Fingerabdruck intern über die Verhaltens- und Kaufköpfe hinweg.
1 · Was speist es?
Das Modell wird anhand des Mitgliederereignisstroms trainiert, den Ihre Integrationen bereits erzeugen – REST API v2 (Bestellungen, Mitglieder), Web- & Portal-Tracking, POS-/Belegerfassung, Treue- und Coupon-Aktivitäten. Ereignisse durchlaufen einen gesteuerten Katalog mit einer Richtlinien-Firewall, bevor sie in das Training aufgenommen werden können; Die Firewall wird in der Pipeline durchgesetzt, nicht durch Konvention.
Zugelassen: Verhaltensereignisse
Käufe, Belege, gesammelte/eingelöste Punkte, Statusänderungen, Coupon-Einlösungen, E-Mail-Öffnungen/Klicks, Push-Benachrichtigungen, Portalbesuche/Klicks, Filialbesuche. Jeder Ereignistyp wird explizit im Katalog erfasst – neue Ereignistypen werden nicht automatisch hinzugefügt.
Ausgeschlossen: Feedback und Inhalte
Alles, was das Modell selbst zurückschreibt (seine eigenen Tags und Bewertungen), ist ausgeschlossen – ein Modell darf nicht aus seiner eigenen Ausgabe lernen. Nachrichteninhalte und Freitext gehen nie in das Training ein: Das Modell lernt, dass ein Mitglied geklickt hat, aber nie, was in der Nachricht stand.
Gesperrt: eingeschränkte Mitglieder
Mitglieder, die einer Verarbeitungseinschränkung unterliegen (GDPR Art. 18), sind vom End-to-End-Training ausgeschlossen. Die Daten eines gelöschten Mitglieds – einschließlich der Einbettung – werden im Rahmen des Löschvorgangs entfernt.
Praktische Konsequenz für Integratoren: Je umfangreicher und sauberer Ihr Event-Feed (richtige Mitgliederidentitätsauflösung, ehrliche Zeitstempel), desto besser ist das Modell – es gibt keinen separaten „Trainings-Upload“. Siehe REST API und Web-Tracking.
2 · Die Vertrauensbasis und das Prinzip der Kundenbetreuung
Das Markenmodell wird pro Mandant deterministisch trainiert (gleiche Daten ⇒ gleiches Modell, versioniert) und wird erst dann für verwendet, wenn es eine transparente Baseline auf Basis der eigenen, zurückgehaltenen Daten dieser Marke übertroffen hat. Nachgelagerte Nutzer lesen das Modell nie direkt – sie durchlaufen ein einziges Bereitstellungsprädikat:
serve = verified_win ∧ not_paused ∧ not_stale
Falls ein Schritt fehlschlägt – das Modell hat sich noch nicht bewährt, die Marke hat die Bewertung pausiert oder das Modell ist veraltet –, greift jeder Nutzer auf die Glass-Box-Vorhersagemodelle zurück (oder auf einen ehrlichen leeren Zustand im Fall von Lookalike-Zielgruppen). Nichts wird jemals mit Nullen aufgefüllt und nichts wird vorgetäuscht: Ein Mitglied ohne Einbettung wird über den Ausweichpfad bedient und niemals in das Modell integriert.
Der Lebenszyklus einer Marke.
Anhäufende Daten
Nicht genügend Erfahrungswerte für ein ehrliches Training – nichts hilft.
Wöchentlicher Vergleich
Geschult, getestet anhand der Baseline in einer realen Umgebung
Die Bewertung stoppt oder das Modell läuft ab – automatischer Fallback
3 · Ausgaben und deren Darstellung
Drei Ausgabefamilien stehen in den unten stehenden Mitglieder- und Segmentoberflächen zur Verfügung. Verwenden Sie die oben stehende gesteuerte Vorhersageschnittstelle REST oder MCP für die einheitliche Verteilung und die Kauffenster für das nächste Ereignis.
Mitgliedereinbettungen
Ein Verhaltens-Fingerabdruck pro Mitglied, abgeleitet aus der gesamten Ereignissequenz. Ermöglicht die Ähnlichkeitsanalyse nächster Nachbarn: Jedes Mitglied mit einem bestimmten Verhalten hat einen solchen Fingerabdruck – keine Tags erforderlich.
Die Kauf- und Kündigungswahrscheinlichkeit (0–100) pro Mitglied wird aktualisiert, sobald neue Aktivitäten erfolgen. Sie wird als Segmentbedingung angezeigt – z. B. „Kaufwahrscheinlichkeit (voraussichtliches nächstes Ereignis, 0–100)“ – und im Mitgliedsprofil.
Ihre KI-Agenten können das Forschungspanel des digitalen Zwillings über den verwalteten Server MCP betreiben. Vier Panel-Tools, wörtlich aus dem Live-Manifest übernommen, neben den oben genannten, schreibgeschützten Prognose-Tools:
list_synthetic_scenarios
((keine))
Listen Sie die Simulationsszenarien für synthetische Paneele mit ihren jeweiligen Anwendungsgrenzen, Konfidenzintervallen und Eingabefeldern auf. Rufen Sie zuerst an, um einen Typ auszuwählen. Erforderlich metrics:read.
run_synthetic_panel
(segment_id, kind, fields)
Führt ein synthetisches Panel durch: Anonymisierte digitale Zwillinge eines Segments reagieren auf einen Reiz und liefern einen aussagekräftigen Richtungsbericht (niemals absolute Zahlen). Gibt eine `run_id` zum Abfragen zurück. Begrenzt durch ein tägliches Durchlauflimit + ≤ 50 Zwillinge. Erfordert `synthetic:write`.
get_synthetic_report
(run_id)
Lesen Sie den eingefrorenen, ehrlichen Bericht für einen synthetischen Panellauf – Richtungsanalyse, Konfidenzniveau, Unterdrückungssignale, Themen – oder einen blockReason Falls nicht bereit. Erfordert metrics:read.
get_synthetic_calibration
((keine))
Kalibrierung des synthetischen Testpanels der Marke (Trefferquote vergangener synthetischer Vorhersagen im Vergleich zur Realität); null (bis Backtests vorliegen). Erfordert metrics:read.
Typischer Ablauf
1.list_synthetic_scenarios → Wähle eine Art aus und lies ihre Nutzungsgrenze.
4.get_synthetic_calibration() → Trefferquote Ihrer Marke im Vergleich zur Realität (null bis Backtests vorliegen)
Vertragliche Vorgaben: Die Anzahl der Durchläufe ist begrenzt (tägliche Obergrenze, ≤ 50 Zwillinge pro Durchlauf); Berichte sind Richtungszahlen, niemals absolute ZahlenEin Wahlgang, der die Integritätsprüfungen nicht besteht (Zusammenbruch des Panels, Speichelleckerei, zu kleine Stichprobe), kommt mit einem blockReason Oder wenn Unterdrückungsflags anstelle eines positiven Ergebnisses ausgegeben werden – diese sind als endgültig und nicht wiederholbar zu behandeln. Dieselben Beschränkungen und Regeln gelten unabhängig davon, ob ein Mensch oder Ihr Agent den Lauf startet. Einrichtung, Authentifizierung und Bereiche: MCP Integrationsleitfaden.
5 · Gewährleistet die Weiterentwicklung
Markenspezifische Isolation
Ein Modell pro Mandant, ausschließlich mit den Mitgliedern dieses Mandanten trainiert. Keine Datenzusammenführung zwischen Marken – weder in eine Richtung noch in eine andere.
Deterministisch und versioniert
Dieselbe Datenbasis erzeugt dasselbe Modell, Bit für Bit; jeder Wert ist auf die Modellversion zurückführbar, die ihn generiert hat.
Löschung abgeschlossen
Durch die Löschung der Mitglieder werden ihre Trainingsdaten und Einbettungen als Teil der Löschtransaktion gelöscht – nicht nach einem Bereinigungsplan.
Veraltete Daten entfernt
Eingebettete Artikel, deren Gültigkeitsdauer abgelaufen ist, werden planmäßig gelöscht, und veraltete Modelle werden automatisch nicht mehr angezeigt.
