RESOURCES/Architettura
Architettura di riferimento per un livello di decisioning
Un livello decisioning si trova tra il data plane e l'activation plane. Legge il contesto del cliente dal warehouse o dal CDP, produce una decisione classificata e dimensionata per cliente, e scrive quella decisione nei sistemi che eseguono. Possiede il registro delle decisioni e lo stato dell'esperimento, e non possiede nient'altro.
Román Via-Dufresne, Co-fondatore, Markin
Aggiornato 4 August 2026 · 9 min di lettura
Richiedi una demo
Definizione
Livello decisionale
Il componente di uno stack cliente che trasforma il contesto unificato del cliente in un'unica azione commessa per cliente, classificata in base al valore atteso e registrata con lo stato dell'esperimento necessario per valutarla in seguito.
La maggior parte degli stack ha un buco nel mezzo
Lo stack B2C moderno è ben fornito a entrambe le estremità. C'è un data warehouse, solitamente un CDP, e un set maturo di canali. Tra di essi c'è un divario dove viene fatta la scelta commerciale effettiva, e nella maggior parte delle aziende questo divario è colmato da regole di eleggibilità, limiti di frequenza e una riunione di pianificazione. Niente nello stack è proprietario della frase 'questo cliente dovrebbe ricevere questo, e vale tanto'.
- Il magazzino sa tutto e non decide nulla.
- La piattaforma di engagement decide come, mai se.
- Le regole codificano le decisioni dell'anno scorso e non vengono mai ritirate.
- Nessun sistema detiene il controfattuale, quindi nulla può essere giudicato.
Quattro piani
Mantenere questi elementi separati è ciò che rende lo stack sostituibile. Unire due di essi è il modo in cui le organizzazioni finiscono per non essere in grado di cambiare fornitore.
01
Leggi, non migrare
Il livello di decisioning si abbona al contesto dove questo già risiede. Qualsiasi architettura che richieda una migrazione di dati prima della prima decisione ha interposto un anno tra te e il caso di ricavo.
02
Decidi su una finestra, non su ogni singolo evento
La maggior parte delle decisioni B2C sono quotidiane o orarie, non per evento. La decisioning in tempo reale è realmente necessaria per le superfici in-sessione e raramente per quelle del ciclo di vita, e pagarne l'utilizzo ovunque è un errore comune e costoso.
03
Prendere una decisione per cliente
L'Arbitrato ha un significato solo se l'output è singolare. Emettere una lista classificata e lasciare che ogni canale scelga da essa ricrea il problema originale in un nuovo contesto.
04
Registra il controfattuale con la decisione
L'assegnazione al holdout fa parte del record decisionale, non un ripensamento per la reportistica. Se l'assegnazione viene ricostruita in seguito, il piano di misurazione non è affidabile.
05
Esegui attraverso i sistemi già in uso.
Il livello di decisioning dovrebbe raggiungere il cliente attraverso i canali che l'azienda già gestisce, piuttosto che diventare un nuovo canale con la propria governance, i propri template e la propria superficie di compliance.
Responsabilità e cosa si rompe quando vengono unite
| Aereo | Possiede | Non deve possedere |
|---|---|---|
| Data plane | Identità, profili unificati, cronologia eventi, risultati. Data warehouse, CDP, analisi del prodotto. | Priorità commerciale. Un "profile store" che classifica le azioni diventa impossibile da comprendere. |
| Decision plane | Generazione Candidate, classificazione per valore atteso, arbitraggio, guardrail, assegnazione holdout, il log delle decisioni. | Risoluzione dell'identità o produzione creativa. Possedere l'una o l'altra la trasforma in una migrazione di piattaforma. |
| Piano di attivazione | Consegna, governance del canale, creatività, orario di invio e deliverability. Piattaforma di engagement, superfici di prodotto, strumenti di assistenza. | Priorità cross-channel. Ogni canale si ottimizza da solo e niente arbitra tra di loro. |
| Piano di misurazione | Integrità del holdout, finestre, letture, il registro di ciò che era vero. | L'incentivo a riportare favorevolmente. Dovrebbe essere leggibile indipendentemente dal decision plane. |
Domande di revisione dell'architettura
Eseguili sul tuo stack attuale, chiunque lo fornisca.
- Quale singolo sistema può rispondere a 'perché questo cliente ha ricevuto questo, martedì scorso'?
- Dove si risolve oggi la priorità cross-channel, ed è risolta per valore o per tetto massimo?
- Lo stack può emettere 'nessuna azione' come decisione di prima classe?
- L'assegnazione del holdout viene registrata al momento della decisione o ricostruita al momento del reporting?
- Se sostituissi la tua piattaforma di engagement l'anno prossimo, quale percentuale della logica decisionale dovrebbe essere ricostruita?
- C'è qualcosa nello stack che registra ciò che è realmente accaduto, in modo che la decisione successiva sia migliore della precedente?
Due cose che un livello di decisioning non deve mai diventare
- Una seconda fonte di verità. Se inizia a risolvere l'identità o a memorizzare profili canonici, ora hai due sistemi in disaccordo e una migrazione che non avevi pianificato.
- Un canale. Una volta che possiede template, reputazione di invio e revisione di conformità, compete con la piattaforma di engagement invece di dirigerla.
- Un sostituto per il magazzino dati. I carichi di lavoro analitici e i carichi di lavoro decisionali hanno forme diverse; unirli rende entrambi più lenti.
- Un motore di regole con un modello aggiunto. Se il set di candidati è autoprodotto dall'uomo, l'architettura va bene e il limite è ancora umano.
Markin è un team autonomo di growth-science per le grandi aziende B2C. Indaga perché i ricavi per cliente sono bloccati, formula le proprie ipotesi in marketing, prodotto, prezzi e stato di salute tecnico, sceglie la Next Best Action per ogni cliente, la lancia attraverso i sistemi che l'azienda già utilizza e ne dimostra ogni singola contro un holdout randomizzato.
Gli strumenti di Decisioning scelgono tra le azioni che il tuo team ha già creato. Markin decide cosa costruire.
Domande che le persone si pongono
- Un livello decisionale sostituisce un CDP?
- No. Un CDP risolve l'identità e unifica i profili; un livello di decisioning consuma quei profili e sceglie le azioni. Risolvono problemi diversi e il confine è netto: se un componente sta decidendo cosa dovrebbe accadere a un cliente, appartiene al piano di decisioning, e se sta decidendo chi è il cliente, appartiene al piano dati.
- Abbiamo bisogno di decisioning in tempo reale?
- Per superfici in-session come un paywall, un checkout o un posizionamento in-app, sì. Per le decisioni sul ciclo di vita, una finestra decisionale giornaliera o oraria è solitamente indistinguibile nel risultato e considerevolmente più economica da gestire. Acquistare in tempo reale per tutto è uno degli sprechi più comuni in questa categoria.
- Dove dovrebbe risiedere il log delle decisioni?
- Nel piano decisionale, e leggibile dal warehouse. Ogni decisione dovrebbe includere il cliente, l'azione scelta, le alternative considerate, il valore atteso, i guardrail applicati e l'assegnazione holdout. Senza tale registrazione, nulla a valle può essere verificato o migliorato.
- Come il livello decisionale evita di entrare in conflitto con la logica del percorso già presente nella piattaforma di engagement?
- Diventando il segnale d'ingresso anziché un mittente parallelo. Il livello di decisioning scrive un attributo o attiva un evento, e il percorso esistente lo riprende. La governance del canale, le regole di frequenza e la creatività rimangono dove sono già, il che rende anche l'integrazione reversibile.
Compara
Come questo si traduce nelle categorie che già acquisti.
Neutral, side by side reads on where the decision layer sits next to the tools in your stack.
Tutti i confronti- Markin vs Optimizely: eseguire test vs decidere cosa testareOptimizely esegue gli esperimenti che progetti. Markin decide quali esperimenti vale la pena eseguire, li dimensiona in revenue e li valuta tutti rispetto a un holdout.
- Markin vs la creazione interna: cosa un team può realisticamente realizzareCostruire un livello di decisioning interno è possibile e a volte corretto. Un confronto onesto di throughput, costo, proprietà e tempo per ottenere un numero verificato.
- Next-Best Action vs. next-best opportunityNext-best opportunity dimensiona ciò che è in gioco per un cliente. Next-Best Action sceglie il trattamento. Perché l'ordine è importante e come i due si connettono.