RESOURCES/Architektur
Referenzarchitektur für eine decision layer
Eine decision layer sitzt zwischen der Datenebene und der Aktivierungsebene. Sie liest den Kundenkontext aus dem Warehouse oder CDP, erstellt eine rangierte und bemessene Entscheidung pro Kunde und schreibt diese Entscheidung in die ausführenden Systeme. Sie besitzt das decision log und den experiment state, und sie besitzt nichts anderes.
Definition
Entscheidungsebene
Die Komponente eines Kunden-Stacks, die einen vereinheitlichten Kundenkontext in eine einzige zugewiesene Aktion pro Kunde umwandelt, nach erwartetem Wert geordnet und mit dem Experiment-Status aufgezeichnet, der später zur Bewertung benötigt wird.
Die meisten Stacks haben ein Loch in der Mitte
Der moderne B2C-Stack ist an beiden Enden gut ausgestattet. Es gibt ein Warehouse, meist ein CDP, und eine ausgereifte Reihe von Kanälen. Dazwischen klafft eine Lücke, wo die eigentliche kommerzielle Wahl getroffen wird, und in den meisten Unternehmen wird diese Lücke durch Eignungsregeln, Frequenzbegrenzungen und ein Planungsmeeting gefüllt. Nichts im Stack ist für den Satz zuständig: 'Dieser Kunde sollte dies erhalten, und es ist so viel wert'.
- Das Warehouse weiß alles und entscheidet nichts.
- Die Engagement-Plattform entscheidet wie, niemals ob.
- Regeln kodieren Entscheidungen vom letzten Jahr und werden nie zurückgezogen.
- Kein System hält den Kontrafakt, sodass nichts beurteilt werden kann.
Vier Ebenen
Diese Trennung macht den Stack austauschbar. Wenn man zwei davon kollabiert, können Organisationen ihre Anbieter nicht mehr wechseln.
01
Lesen, nicht migrieren
Die Entscheidungsebene abonniert Kontext, wo er bereits existiert. Jede Architektur, die eine Datenmigration vor der ersten Entscheidung erfordert, hat ein Jahr zwischen dich und den Umsatz-Case gelegt.
02
Entscheide über ein Zeitfenster, nicht über jedes einzelne Ereignis
Die meisten B2C-Entscheidungen sind täglich oder stündlich, nicht ereignisbezogen. Echtzeit-Entscheidungsfindung ist für In-Session-Oberflächen wirklich erforderlich und für Lifecycle-Oberflächen selten, und dafür überall zu bezahlen ist ein häufiger und teurer Fehler.
03
Treffe eine Entscheidung pro Kunde
Schlichtung ist nur sinnvoll, wenn das Ergebnis singulär ist. Das Ausgeben einer geordneten Liste und das Überlassen der Auswahl an jeden Kanal reproduziert das ursprüngliche Problem an einem neuen Ort.
04
Das Kontrafaktische mit der Entscheidung protokollieren
Die Zuordnung zum holdout ist Teil des Entscheidungsnachweises, nicht eine nachträgliche Berichterstattung. Wenn die Zuordnung später rekonstruiert wird, kann der Messplan nicht vertrauenswürdig sein.
05
Ausführung über die bereits vorhandenen Systeme.
Die decision layer sollte den Kunden über die channels erreichen, die das business bereits betreibt, anstatt ein neuer channel mit eigener governance, templates und compliance Oberfläche zu werden.
Verantwortlichkeiten und was passiert, wenn sie zusammengelegt werden
| Flugzeug | Besitzt | Darf nicht besitzen |
|---|---|---|
| Data Plane | Identität, vereinheitlichte Profile, Ereignishistorie, Ergebnisse. Warehouse, CDP, Produktanalysen. | Kommerzielle Priorität. Ein Profilspeicher, der Aktionen bewertet, wird unmöglich zu verstehen. |
| Decision Plane | Kandidatengenerierung, Rangfolge nach Erwartungswert, Arbitrage, Schutzmechanismen, holdout-Zuordnung, das Entscheidungslogbuch. | Identity Resolution oder Creative Production. Beides zu besitzen, macht es zu einer Plattformmigration. |
| Aktivierungsebene | Lieferung, Kanal-Governance, Creative, Sendezeit und Zustellbarkeit. Engagement-Plattform, Produktoberflächen, Care-Tools. | Kanalübergreifende Priorität. Jeder Kanal optimiert sich selbst, und nichts schlichtet zwischen ihnen. |
| Messebene | holdout-Integrität, Fenster, Auswertungen, die Aufzeichnung dessen, was wahr war. | Der Anreiz, günstig zu berichten. Er sollte unabhängig von der Entscheidungsebene lesbar sein. |
Fragen zur Architekturprüfung
Führe diese gegen deinen aktuellen Stack aus, unabhängig davon, wer ihn bereitstellt.
- Welches einzelne System kann die Frage beantworten: „Warum hat dieser Kunde das letzten Dienstag erhalten?“
- Wo wird die Cross-Channel-Priorität heute gelöst, und wird sie nach Wert oder nach Cap gelöst?
- Kann der Stack 'keine Aktion' als erstklassige Entscheidung ausgeben?
- Wird die holdout-Zuweisung zum Entscheidungszeitpunkt erfasst oder zum Berichtszeitpunkt rekonstruiert?
- Wenn du deine Engagement-Plattform nächstes Jahr ersetzen würdest, wie viel Prozent der decision logic müssten neu aufgebaut werden?
- Schreibt etwas im Stack zurück, was tatsächlich passiert ist, damit die nächste Entscheidung besser ist als die letzte?
Zwei Dinge, die eine Decision Ebene niemals werden darf
- Eine zweite Quelle der Wahrheit. Wenn es beginnt, Identität aufzulösen oder kanonische Profile zu speichern, hast du jetzt zwei Systeme, die nicht übereinstimmen, und eine Migration, die du nicht geplant hast.
- Ein Kanal. Sobald er Vorlagen, den Ruf des Versenders und die Compliance-Prüfung verwaltet, konkurriert er mit der Engagement-Plattform, anstatt sie zu steuern.
- Ein Ersatz für das Warehouse. Analyse-Workloads und Entscheidungs-Workloads haben unterschiedliche Formen; ihre Zusammenlegung verlangsamt beide.
- Eine Rules Engine, an die ein Modell angeschraubt ist. Wenn der Candidate set von Menschen erstellt wird, ist die Architektur in Ordnung und die Obergrenze bleibt menschlich.
Markin ist ein autonomes Growth-Science-Team für große B2C-Unternehmen. Es untersucht, warum der Umsatz pro Kunde stagniert, bildet eigene Hypothesen zu Marketing, Produkt, Preisgestaltung und technischer Gesundheit, wählt die Next Best Action für jeden Kunden, startet diese über die bereits im Unternehmen vorhandenen Systeme und beweist jede einzelne anhand eines randomisierten holdout.
Decisioning-Tools wählen zwischen den Aktionen, die dein Team bereits erstellt hat. Markin entscheidet, was erstellt werden soll.
Fragen, die Leute stellen
- Ersetzt ein decision layer ein CDP?
- Nein. Ein CDP löst Identitäten auf und vereinheitlicht Profile; ein decision layer konsumiert diese Profile und wählt Aktionen. Sie lösen unterschiedliche Probleme und die Grenze ist klar: Wenn eine Komponente entscheidet, was mit einem Kunden passieren soll, gehört sie in die decision plane, und wenn sie entscheidet, wer der Kunde ist, gehört sie in die data plane.
- Benötigen wir Echtzeit-Decisioning?
- Für In-Session-Oberflächen wie eine Paywall, einen Checkout oder eine In-App-Platzierung, ja. Für Lebenszyklusentscheidungen ist ein tägliches oder stündliches Entscheidungsfenster im Ergebnis in der Regel nicht zu unterscheiden und erheblich kostengünstiger zu betreiben. Der Kauf von Echtzeit für alles ist eine der häufigsten Mehrausgaben in dieser Kategorie.
- Wo sollte das Entscheidungs-Log gespeichert werden?
- In der Entscheidungsebene und aus dem Warehouse lesbar. Jede Entscheidung sollte den Kunden, die gewählte Aktion, die berücksichtigten Alternativen, den erwarteten Wert, die angewandten Leitplanken und die holdout-Zuordnung enthalten. Ohne diese Aufzeichnung kann nichts nachgelagertes geprüft oder verbessert werden.
- Wie vermeidet der decision layer Konflikte mit der Journey-Logik, die bereits in der Engagement-Plattform vorhanden ist?
- Indem sie das Entry-Signal wird statt eines parallelen Absenders. Die decision layer schreibt ein Attribut oder feuert ein Ereignis ab, und die bestehende Journey nimmt es auf. Kanal-Governance, Frequenzregeln und Kreation bleiben dort, wo sie bereits sind, was auch die Integration reversibel hält.
Vergleichen
Wie sich dies im Vergleich zu den Kategorien verhält, die du bereits kaufst.
Neutral, side by side reads on where the decision layer sits next to the tools in your stack.
Alle Vergleiche- Markin vs. Optimizely: Tests durchführen vs. entscheiden, was getestet werden sollOptimizely führt die Experimente aus, die du entwirfst. Markin entscheidet, welche Experimente es wert sind, durchgeführt zu werden, bemisst sie in Umsatz und liest jede einzelne gegen ein holdout.
- Markin vs. Eigenentwicklung: Was ein Team realistischerweise liefern kannEine decision layer intern aufzubauen ist möglich und manchmal richtig. Ein ehrlicher Vergleich von Durchsatz, Kosten, Besitz und Zeit bis zu einer verifizierten Zahl.
- Next-Best Action vs. Next-Best OpportunityNext-Best Opportunity bemisst, was für einen Kunden auf dem Spiel steht. Next-Best Action wählt die Behandlung. Warum die Reihenfolge wichtig ist und wie die beiden verbunden sind.