Offer Decisioning
Questa guida fornisce un riferimento completo all'implementazione per offer decisioning utilizzando Adobe Journey Optimizer (AJO) Decisioning e Adobe Real-Time Customer Data Platform (RT-CDP). È progettato per architetti di soluzioni, tecnici di marketing e tecnici di implementazione che devono implementare una logica di selezione dell’offerta centralizzata che determini l’offerta migliore per ogni profilo cliente su tutti i canali.
Utilizza questa guida per capire cosa deve essere configurato, dove esistono opzioni e quali compromessi si applicano a ciascuna decisione.
Il modello separa la decisione "cosa mostrare" dalla logica del canale "dove mostrarlo", consentendo una selezione dell’offerta coerente e ottimizzata su e-mail, web, app mobile e qualsiasi altro punto di contatto. AJO Decisioning gestisce l’intero ciclo di vita delle offerte: creazione di offerte e gestione del catalogo, regole di idoneità (chi può vedere ogni offerta), strategie di classificazione (come selezionare tra le offerte idonee), posizionamenti (dove vengono visualizzate le offerte) e criteri decisionali (che associano tutto).
Panoramica del caso d’uso
Le organizzazioni devono spesso presentare a ciascun cliente l’offerta, la promozione o l’incentivo più pertinente al momento dell’interazione. Che l’interazione si verifichi in una campagna e-mail, su una home page del sito web, all’interno di un’app mobile o in un punto decisionale all’interno di un percorso in più passaggi, la sfida è la stessa: seleziona l’offerta ottimale da un catalogo di opzioni disponibili in base a chi sia il cliente, a cosa si qualifica e a quale offerta è più probabile che generi il risultato desiderato.
Offer Decisioning affronta questo problema centralizzando tutta la logica di selezione delle offerte nel motore di gestione delle decisioni di AJO. Invece di suddividere le assegnazioni delle offerte in singole campagne o canali, il motore decisionale valuta gli attributi di ciascun profilo, l’appartenenza al pubblico e i segnali contestuali per determinare l’offerta migliore in tempo reale. Questa centralizzazione assicura che lo stesso cliente riceva offerte coerenti e ottimizzate indipendentemente dal canale attraverso cui interagisce.
Questo modello si differenzia dalla personalizzazione web/app per visitatore noto per quanto riguarda l’ambito: le decisioni sull’offerta sono indipendenti dal canale e centralizzate, mentre la personalizzazione dei visitatori noti si concentra sulla personalizzazione della superficie digitale. Differisce dalle raccomandazioni comportamentali nel modello di catalogo: utilizza Offer Decisioning quando l’insieme di articoli idonei è disciplinato da regole aziendali, vincoli di idoneità o requisiti normativi (promozioni, prodotti finanziari, incentivi). Utilizza i consigli comportamentali quando il set di elementi è grande, in continua modifica e la selezione è guidata da segnali di affinità o similarità comportamentali (cataloghi di prodotti, librerie di contenuti).
Obiettivi aziendali chiave
I seguenti obiettivi di business sono supportati da questo modello di casi d’uso.
Distribuisci esperienze cliente personalizzate
Personalizza contenuti, offerte e messaggi in base a preferenze, comportamenti e fasi del ciclo di vita individuali.
KPI: coinvolgimento, tassi di conversione, soddisfazione cliente (CSAT)
Incrementa le vendite incrociate e incrementa i ricavi
Promuovere prodotti o servizi complementari e di alta qualità ai clienti esistenti in base al comportamento e alla cronologia degli acquisti.
KPI: % vendite incrociate/upselling, ricavi incrementali, valore ciclo di vita cliente
Aumenta la fedeltà dei clienti e il valore del ciclo di vita
Approfondisci le relazioni con i clienti e massimizza il valore a lungo termine tramite programmi di fidelizzazione, premi e coinvolgimento personalizzato.
KPI: valore ciclo di vita cliente, conservazione, upselling/cross-selling %
Esempi di casi d’uso tattici
Gli scenari seguenti illustrano come è possibile applicare in pratica Offer Decisioning.
- Proposta di acquisto successiva nelle campagne e-mail: seleziona la promozione più pertinente per destinatario al momento dell’invio
- Banner promozionale in tempo reale sul sito web: il processo decisionale seleziona l’offerta al caricamento della pagina in base al profilo del visitatore
- Scheda in-app personalizzata con il miglior incentivo per la fase del ciclo di vita dell’utente
- Coerenza delle offerte cross-channel: la stessa logica decisionale viene utilizzata per e-mail, web e push, in modo che il cliente possa vedere un’esperienza di offerta unificata
- Selezione dinamica di coupon o sconti in base al livello di valore del cliente (ad esempio, i clienti di valore elevato ricevono un’offerta premium)
- Aggiornamento del prodotto o selezione di offerte di upselling in base al livello di abbonamento corrente
- Personalizzazione delle offerte di fidelizzazione e premio in base alla cronologia dei livelli e delle attività
Indicatori chiave di prestazioni
I KPI seguenti aiutano a misurare l’efficacia di un’implementazione di Offer Decisioning.
Schema del caso d’uso
Questa sezione descrive la catena di funzioni e la definizione del modello per offer decisioning.
Offer Decisioning
Utilizza la logica decisionale centralizzata per selezionare l’offerta o il contenuto migliore per un profilo tra canali diversi.
Catena di funzioni: Valutazione del pubblico > Idoneità offerta > Strategia di classificazione > Esecuzione delle decisioni > Consegna > Generazione rapporti
Consulta la sezione Opzioni di implementazione per informazioni sulla modalità di visualizzazione di ciascuna composizione.
Applicazioni
In questo modello di caso d’uso vengono utilizzate le seguenti applicazioni Adobe.
- Adobe Journey Optimizer (AJO) — Motore di gestione delle decisioni per la creazione di offerte, regole di idoneità, strategie di classificazione, posizionamenti e criteri di decisione; configurazione dei canali e authoring dei messaggi per la consegna delle offerte; esecuzione di campagne e percorsi
- Adobe Real-Time Customer Data Platform (RT-CDP) — Valutazione del pubblico per i segmenti di idoneità delle offerte; dati di profilo e attributi calcolati utilizzati nell'idoneità e nella classificazione
- Adobe Experience Platform (AEP): archivio profili unificato, risoluzione identità e base dati che supportano sia AJO che RT-CDP
Funzioni fondamentali
Per questo modello di caso d’uso devono essere disponibili le seguenti funzionalità fondamentali. Per ogni funzione, lo stato indica se in genere è obbligatorio, se si presume che sia preconfigurato o meno applicabile.
Funzioni di supporto
Le seguenti funzionalità incrementano questo modello di caso d’uso, ma non sono necessarie per l’esecuzione di base.
Funzioni dell’applicazione
Questo piano esegue le seguenti funzioni dal catalogo delle funzioni dell'applicazione. Le funzioni sono mappate su fasi di implementazione anziché su passaggi numerati.
Journey Optimizer (AJO)
Nella tabella seguente sono elencate le funzioni di AJO e le fasi di implementazione in cui sono configurate.
Real-Time CDP (RT-CDP)
Nella tabella seguente sono elencate le funzioni RT-CDP e le fasi di implementazione in cui sono configurate.
Prerequisiti
Completa i seguenti prerequisiti prima di iniziare l’implementazione.
- [ Sandbox AJO ] con funzionalità di gestione delle decisioni abilitate
- [ ] Ruoli utente con autorizzazioni di Gestione delle decisioni (crea/modifica offerte, posizionamenti, decisioni)
- [ Lo schema del profilo ] include gli attributi necessari per l'idoneità dell'offerta (ad esempio, livello fedeltà, segmento cliente, livello di abbonamento)
- [ I dati del profilo ] sono correnti e vengono acquisiti attivamente per l'aggiornamento degli attributi di idoneità
- [ ] per l'opzione A (e-mail): superficie del canale e-mail configurata con sottodominio verificato e pool IP riscaldato
- [ ] Per l'opzione B (Web/App): Web SDK implementato con il servizio AJO abilitato nello stream di dati; criterio di unione edge-active configurato
- [ ] per l'opzione C (Percorso): autorizzazioni dell'area di lavoro del Percorso e configurazione di almeno un evento di ingresso del percorso o pubblico
- [ ] Risorse creative per offerte (immagini, copie, CTA) preparate per ogni combinazione di offerta e posizionamento
- [ ] contenuto offerta di fallback preparato per ogni posizionamento
- [ ] tipi di pubblico per le regole di idoneità delle offerte definiti e valutati in RT-CDP
Opzioni di implementazione
Questa sezione descrive le opzioni di implementazione disponibili per offer decisioning. Ogni opzione offre un canale di consegna e un contesto del caso d’uso diversi.
Opzione A: Decisioning delle offerte e-mail
Questa opzione è ideale per selezionare l’offerta migliore da includere nelle campagne e-mail in uscita: e-mail promozionali, personalizzazione newsletter, e-mail sul ciclo di vita con contenuto di offerta dinamico. La decisione viene presa al momento del rendering del messaggio per ogni destinatario.
Come funziona
I criteri di decisione vengono richiamati durante il rendering dei messaggi e-mail per selezionare l’offerta migliore per ogni destinatario. Il modello e-mail include un’area di posizionamento dell’offerta in cui il motore decisionale inserisce la rappresentazione del contenuto dell’offerta selezionata (immagine, HTML o testo). Al momento dell’invio, il motore di valuta il profilo di ciascun destinatario in base alle regole di idoneità per le offerte, applica la strategia di classificazione e incorpora il contenuto dell’offerta vincente nell’e-mail.
Questo approccio funziona sia con le campagne pianificate (valutate al momento dell’esecuzione della campagna) che con le e-mail incorporate nel percorso (valutate quando il profilo raggiunge il nodo dell’azione del messaggio). Il contenuto dell’offerta (immagine, titolo, copia del corpo e CTA) è personalizzato per destinatario in base al risultato della decisione.
Considerazioni chiave
- L’idoneità dell’offerta viene valutata al momento dell’invio utilizzando lo stato corrente del profilo
- La valutazione del pubblico in batch è sufficiente poiché le decisioni si verificano durante il rendering dei messaggi
- Ogni offerta richiede una rappresentazione del contenuto di HTML o immagini per il posizionamento dell’e-mail
- L’offerta di fallback deve contenere contenuti per ogni posizionamento e-mail utilizzato
Vantaggi
- Percorso di implementazione più semplice: utilizza la consegna e-mail standard per campagne o percorsi
- Nessun requisito SDK lato client
- Compatibile con l'infrastruttura e-mail e le superfici di canale esistenti
- Supporta volumi di pubblico di grandi dimensioni tramite l’esecuzione di campagne in batch
Limitazioni
- La decisione viene presa al momento dell’invio; non può adattarsi al comportamento successivo all’invio
- Il contenuto dell’offerta è statico una volta consegnata l’e-mail (nessun aggiornamento in tempo reale)
- Limitato agli attributi di profilo disponibili nell’archivio profili hub (non edge)
Risorse di Experience League
Opzione B: Decisioning delle offerte in tempo reale per web/app
Questa opzione è ideale per la selezione delle offerte in tempo reale su pagine web o app mobili: banner promozionali per home page, widget di offerte sulla dashboard dell’account, schede di offerta in-app o qualsiasi superficie digitale in cui l’offerta deve essere selezionata al momento del caricamento della pagina o del rendering dello schermo.
Come funziona
I criteri di decisione vengono richiamati al caricamento della pagina o al rendering della schermata dell’app tramite la rete Edge Decisioning o esperienze basate su codice. Quando un visitatore carica una pagina, il Web SDK invia una richiesta ad Edge Network, che valuta il profilo Edge del visitatore in base alle regole di idoneità delle offerte e alle strategie di classificazione. L’offerta selezionata viene restituita nella risposta ed è sottoposta a rendering nel posizionamento configurato sulla superficie digitale.
Per esperienze basate su codice, l’applicazione recupera la risposta di decisione ed esegue il rendering del contenuto dell’offerta utilizzando una logica front-end personalizzata. Per le esperienze dei canali web, il canale web AJO può inserire il contenuto dell’offerta direttamente nella pagina utilizzando l’authoring visivo o basato su codice.
Considerazioni chiave
- Richiede l’implementazione di Web SDK o Mobile SDK con il servizio AJO abilitato per lo stream di dati
- Il criterio di unione attivo per Edge è richiesto per le ricerche di profilo in tempo reale
- I tipi di pubblico utilizzati per l’idoneità devono supportare la valutazione Edge (controlli degli attributi semplici e appartenenza ai segmenti)
- Le rappresentazioni di contenuto dell’offerta devono utilizzare formati JSON o URL immagine per il rendering lato client
- Per acquisire visualizzazioni e clic delle offerte, è necessario implementare il tracciamento delle impression
Vantaggi
- Selezione di offerte in tempo reale durante la sessione in base allo stato attuale del profilo del visitatore
- Latenza delle decisioni al secondo secondario tramite Edge Network
- Le offerte si adattano ai dati di profilo più recenti disponibili al perimetro
- Supporta il test A/B delle strategie di offerta tramite la sperimentazione dei contenuti
Limitazioni
- Richiede l’implementazione lato client di SDK (Web SDK o Mobile SDK)
- Il profilo Edge dispone di un sottoinsieme di attributi completi del profilo hub; regole di idoneità complesse potrebbero non essere valutate correttamente
- I segmenti di Edge hanno restrizioni di complessità delle regole di segmento (nessuna query di serie temporali)
- Richiede lo sviluppo front-end per il rendering personalizzato nelle esperienze basate su codice
Risorse di Experience League
Differenze rispetto all'opzione di personalizzazione Web/app visitatore noto B:
L’infrastruttura è identica: entrambi utilizzano AJO Decisioning alla periferia con Web SDK e un criterio di unione attivo per la rete Edge. La differenza sta nel modello di governance del catalogo. Questa opzione gestisce un catalogo di offerte limitate con regole di idoneità, contatori dei limiti e date di validità; utilizzalo quando vincoli aziendali o normativi determinano quali offerte possono essere visualizzate e con quale frequenza. Personalizzazione Web/app visitatore noto L'opzione B seleziona gli elementi di contenuto utilizzando l'appartenenza ai segmenti o strategie di classificazione senza gestione del ciclo di vita delle offerte. Se il set di elementi è grande, in continua modifica e non richiede la governance dei limiti o dell’idoneità, utilizza l’opzione B Visitatore noto.
Opzione C: nodo di decisione del Percorso
Questa opzione è ideale per la selezione di offerte all’interno di un percorso con più passaggi: selezionare l’offerta migliore in un punto decisionale di un percorso di clienti, quindi distribuirla attraverso il nodo di azione successivo. Utilizzalo quando la decisione sull’offerta fa parte di un flusso di orchestrazione più ampio con attese, condizioni e più azioni messaggio.
Come funziona
I criteri di decisione vengono richiamati da un nodo di decisione all’interno di un’area di lavoro del percorso AJO. Quando un profilo raggiunge il nodo della decisione, il motore valuta l’idoneità e la classificazione delle offerte per selezionare l’offerta ottimale. L’offerta selezionata informa l’azione del messaggio successiva, che indica il contenuto dell’offerta da includere, il canale da utilizzare o il ramo di percorso da intraprendere in base al risultato dell’offerta.
Questo approccio consente percorsi adattivi in cui la decisione di offerta influenza le fasi successive del percorso. Ad esempio, un percorso potrebbe selezionare l’offerta migliore, consegnarla tramite e-mail, attendere il coinvolgimento e quindi inviare una notifica push se l’offerta non è stata aperta.
Considerazioni chiave
- Il percorso deve essere progettato con un nodo decisione seguito da uno o più nodi azione messaggio
- L’idoneità dell’offerta viene valutata utilizzando lo stato del profilo nel momento in cui questo raggiunge il nodo della decisione
- Passaggi di attesa percorsi tra la decisione e la consegna possono causare la modifica dello stato del profilo
- Può combinarsi con la diramazione del percorso per seguire percorsi diversi in base all’offerta selezionata
Vantaggi
- Integra la selezione delle offerte nei flussi di orchestrazione in più passaggi
- Abilita percorsi adattivi in cui la scelta dell’offerta influenza i passaggi successivi
- Supporta la consegna cross-channel all’interno dello stesso percorso (e-mail, push, SMS)
- Può combinarsi con condizioni di percorso per il tracciamento del coinvolgimento post-offerta
Limitazioni
- Configurazione più complessa rispetto alle decisioni sulle campagne autonome
- Si applicano limiti di velocità effettiva percorsi (velocità di ingresso di 5,000 profili al secondo)
- La decisione è associata al contesto del percorso. Le modifiche richiedono il controllo delle versioni del percorso
- È necessario ripubblicare il percorso per rendere effettivi gli aggiornamenti del catalogo delle offerte o dei criteri di decisione
Risorse di Experience League
Confronto delle opzioni
La tabella seguente confronta le tre opzioni di implementazione tra i diversi criteri chiave.
Scegli l’opzione giusta
Use the following guidance to select the best implementation option for your use case.
- Choose Option A if the primary use case is selecting the best offer per recipient in outbound email campaigns and no client-side SDK is available. This is the simplest implementation path and works well for promotional emails, newsletters, and lifecycle campaigns.
- Choose Option B if offers must be selected in real time at the moment a visitor loads a web page or opens a mobile app. This requires Web SDK or Mobile SDK and an edge-active merge policy but delivers the fastest, most contextual offer selection.
- Choose Option C if the offer decision is part of a broader customer journey with multiple steps, waits, and conditional branching. This is the right choice when the selected offer should influence downstream journey actions or when multi-channel follow-up based on offer engagement is needed.
- Combine options when offers must be delivered consistently across channels. Use the same decision policy across all three options to ensure a customer sees the same offer in email (Option A), on the website (Option B), and within a journey follow-up (Option C).
Fasi di implementazione
The following phases outline the end-to-end implementation sequence for offer decisioning.
Phase 1: Validate foundational prerequisites
Application function: AEP: Data Modeling & Preparation, AEP: Identity & Profile Configuration
This phase validates that the foundational data layer supports offer decisioning. Profile schemas must include the attributes used in offer eligibility rules, and identity configuration must enable cross-channel profile resolution.
Decision: Profile attributes for eligibility
Determine which profile attributes will be used in offer eligibility rules.
Dettagli chiave della configurazione
- Verificare che lo schema del profilo includa i campi a cui si fa riferimento nelle regole di idoneità (ad esempio,
_tenantId.loyaltyTier,_tenantId.subscriptionType) - Conferma l’esistenza di uno schema di tracciamento dell’interazione dell’offerta per gli eventi di impression, clic e conversione
- Per l’opzione B: verifica che il criterio di unione edge-active sia configurato e che lo stream di dati Web SDK abbia il servizio AJO abilitato
Documentazione di Experience League
Fase 2: configurare la valutazione del pubblico
Funzione applicazione: RT-CDP: Audience Evaluation
Questa fase definisce e valuta i tipi di pubblico utilizzati come criteri di idoneità per le offerte. Questi tipi di pubblico determinano quali segmenti di clienti sono idonei per offerte specifiche (ad esempio, i "clienti di alto valore" si qualificano per le offerte premium, gli "utenti di prova" si qualificano per le offerte di conversione).
Decisione: metodo di valutazione del pubblico
Determina la rapidità con cui l’iscrizione al pubblico deve essere aggiornata per l’idoneità alle offerte.
Navigazione interfaccia utente: Cliente > Tipi di pubblico > Crea pubblico > Genera regola
Dettagli chiave della configurazione
- Definisci i tipi di pubblico di targeting per l’idoneità delle offerte (ad esempio, "Livello Gold fedeltà", "Clienti di alto valore", "Utenti di prova")
- Definisci i tipi di pubblico di eliminazione se necessario (ad esempio, "Offerta X ricevuta di recente")
- Per l’opzione B: verificare che i tipi di pubblico di idoneità siano idonei per la valutazione Edge — evitare query di serie temporali e aggregazioni complesse nelle espressioni delle regole di segmento
Dove le opzioni divergono
Per L'Opzione A (Email Decisioning):
È sufficiente la valutazione in batch o in streaming. I tipi di pubblico vengono valutati prima o durante l’esecuzione della campagna. Sono completamente supportate le espressioni di regole di segmento complesse, comprese le condizioni basate sul tempo e le aggregazioni di eventi.
Per L'Opzione B (Web/App In Tempo Reale):
È necessaria la valutazione di Edge. I tipi di pubblico devono utilizzare semplici controlli degli attributi o condizioni di appartenenza ai segmenti. Verifica l’idoneità degli edge verificando che l’espressione della regola del segmento sia idonea alla segmentazione degli edge.
Per L'Opzione C (Nodo Di Decisione Percorso):
Qualsiasi metodo di valutazione funziona in base ai criteri percorsi di immissione. Se il percorso utilizza una voce basata sul pubblico, il metodo di valutazione del pubblico corrisponde ai requisiti del percorso.
Documentazione di Experience League
Fase 3: Impostare il decisioning
Funzione applicazione: AJO: Decisioning
Questa è la fase principale in cui vengono generati il catalogo delle offerte, le regole di idoneità, le strategie di classificazione e i criteri decisionali. Questa fase crea la configurazione del motore decisionale che tutte le opzioni di consegna (A, B, C) condividono.
Decisione: canale di posizionamento e formato dei contenuti
Determina dove verranno visualizzate le offerte e in quale formato.
Decisione: strategia di classificazione
Determina come deve essere selezionata l’offerta migliore dalle offerte idonee.
Decisione: limite dell’offerta
Determine whether there should be limits on how many times an offer is shown.
UI navigation: Components > Decision Management > Placements / Rules / Offers / Decisions
Dettagli chiave della configurazione
-
Crea posizionamenti — consente di definire la posizione in cui vengono visualizzate le offerte specificando il tipo di canale e il formato di contenuto per ciascun posizionamento.
- Interfaccia utente: Componenti > Gestione delle decisioni > Posizionamenti
- Crea un posizionamento per ogni combinazione canale/formato (ad esempio, "Email Hero Banner - HTML", "Web Homepage - JSON", "Mobile App Card - JSON")
-
Definire le regole di idoneità — Creare regole utilizzando espressioni della regola di segmento che fanno riferimento ad attributi di profilo o appartenenza a un pubblico.
- Interfaccia utente: Componenti > Gestione delle decisioni > Regole
- Le regole possono fare riferimento all’iscrizione al pubblico, agli attributi del profilo (livello di fedeltà, tipo di abbonamento), ai vincoli di data o ai dati contestuali
-
Crea offerte personalizzate: crea ogni offerta con rappresentazioni di contenuto per ogni posizionamento, assegna le regole di idoneità, imposta la priorità e configura il limite facoltativo.
- Interfaccia utente: Componenti > Gestione delle decisioni > Offerte > Crea offerta
- Ogni offerta richiede una rappresentazione del contenuto per posizionamento (ad esempio, HTML per e-mail, JSON per web)
- Assegna regole di idoneità per controllare quali profili possono visualizzare ogni offerta
- Impostare le date di validità dell’offerta (inizio/fine) e il limite di frequenza opzionale
- Approva ogni offerta per renderla idonea alle decisioni
-
Crea offerte di fallback: crea un'offerta predefinita per ogni posizionamento visualizzato quando non è idonea alcuna offerta personalizzata.
- Interfaccia utente: Componenti > Gestione delle decisioni > Offerte > Crea offerta di fallback
- Il fallback deve avere rappresentazioni per ogni posizionamento utilizzato nella decisione
-
Creare qualificatori e raccolte della raccolta — Organizzare le offerte in raccolte utilizzando tag qualificatori.
- Interfaccia utente: Componenti > Gestione delle decisioni > Qualificatori di raccolta
- Offerte relative al gruppo (ad esempio, "Promozioni estive", "Premi fedeltà") da utilizzare negli ambiti decisionali
-
Creare criteri di decisione: associa posizionamenti, raccolte, strategie di classificazione e offerte di fallback a decisioni eseguibili.
- Interfaccia utente: Componenti > Gestione delle decisioni > Decisioni > Crea decisione
- Ogni ambito decisionale collega un posizionamento a una raccolta e specifica il metodo di classificazione
Documentazione di Experience League
Phase 4: Configure channel and surface
Funzione applicazione: AJO: Configurazione canale
This phase configures the channel surfaces through which offers will be delivered. The configuration depends on which implementation option(s) are being used.
Decision: Channel type
Determine which messaging channel the use case requires.
Dove le opzioni divergono
Per L'Opzione A (Email Decisioning):
- Interfaccia utente: Amministrazione > Canali > Superfici di canale > Crea superficie (e-mail)
- Configurare le impostazioni relative a sottodominio, pool IP, nome/e-mail del mittente, risposta e annullamento dell’abbonamento
- Verifica i record SPF, DKIM e DMARC per il sottodominio di invio
Per L'Opzione B (Web/App In Tempo Reale):
- Interfaccia utente: Amministrazione > Canali > Superfici di canale > Crea superficie (web o in-app)
- Per il web: configura il pattern URL della superficie web
- Per esperienze basate su codice: definisci l’URI di superficie per l’applicazione
- Verifica che il servizio AJO sia abilitato per lo stream di dati
Per L'Opzione C (Nodo Di Decisione Percorso):
- Configurare le superfici di canale per ciascun canale utilizzato nel percorso (e-mail, push, SMS o web)
- Ogni azione del messaggio di percorso richiede una superficie di canale attiva corrispondente
Documentazione di Experience League
Phase 5: Configure content and delivery
Application function: AJO: Message Authoring, AJO: Campaign Execution
This phase designs the message templates or experience surfaces that display the selected offer, then configures the delivery mechanism (campaign, journey, or code-based experience).
Decision: Content approach for offer rendering
Determine how the offer content should be integrated into the message or experience.
Decision: Campaign type (Option A only)
Determine whether this is a scheduled marketing campaign or an API-triggered campaign.
Dove le opzioni divergono
Per L'Opzione A (Email Decisioning):
-
Creare il messaggio e-mail tramite E-mail Designer
- Interfaccia utente: Campagne > Crea campagna > Seleziona e-mail > Modifica contenuto
- Inserisci un componente decisione di offerta nel layout dell’e-mail per definire l’area di posizionamento
- Aggiungere token di personalizzazione per il contenuto a livello di profilo (nome, livello fedeltà)
- Configurare l’oggetto e il preintestazione con la personalizzazione facoltativa
-
Creare e configurare la campagna
- Interfaccia utente: Campagne > Crea campagna > Pianificato o attivato da API
- Associa il pubblico di destinazione e seleziona la superficie di canale
- Impostare la pianificazione di esecuzione o la configurazione del trigger API
- Rivedere e attivare la campagna
Per L'Opzione B (Web/App In Tempo Reale):
-
Configurare l’esperienza basata su codice o il canale web
- Interfaccia utente: Campagne > Crea campagna > Esperienza basata su codice (o Web)
- Collegare il criterio di decisione alla superficie dell’esperienza
- Definire il formato di rendering (risposta JSON per basato su codice; editor visivo per canale web)
-
Implementare il rendering lato client
- Utilizza la risposta di Web SDK
sendEventper recuperare l'offerta selezionata - Eseguire il rendering del contenuto dell’offerta nel posizionamento designato nella pagina
- Implementare il tracciamento delle impression e dei clic
- Utilizza la risposta di Web SDK
Per L'Opzione C (Nodo Di Decisione Percorso):
-
Progettare il percorso con un nodo di decisione
- Interfaccia utente: Percorsi > Crea Percorso > Aggiungi nodo di decisione
- Configurare il nodo della decisione per richiamare il criterio di decisione dalla fase 3
-
Aggiungi nodi di azione del messaggio dopo la decisione
- Configurare le azioni e-mail, push o SMS che fanno riferimento all’offerta selezionata
- Aggiungi passaggi di attesa, condizioni o diramazioni in base al coinvolgimento dell’offerta
-
Pubblicare il percorso
Documentazione di Experience League
Fase 6: Test e convalida
Funzione dell'applicazione: AJO: Decisioning, AJO: Message Authoring
Questa fase verifica che il motore decisionale restituisca le offerte corrette per i profili di test e che il contenuto dell’offerta venga riprodotto correttamente in ogni canale di consegna.
Logica di test decisioning
Utilizza profili di test con attributi noti per verificare che le offerte corrette siano selezionate in base all’idoneità e alla classificazione.
- Crea profili di test che corrispondono a diversi criteri di idoneità (ad esempio, livello Gold, livello Silver, utente di prova)
- Verifica che ogni profilo di test riceva l’offerta prevista
- Verifica che i profili che non corrispondono a nessuna regola di idoneità ricevano l’offerta di fallback
Test del rendering del contenuto
Visualizza l’anteprima del contenuto dell’offerta in ogni canale di consegna.
- Per l’opzione A: utilizza l’anteprima e-mail con profili di test per verificare che il contenuto dell’offerta venga riprodotto correttamente
- Per l’opzione B: testare la risposta di Edge Decisioning in un ambiente di staging
- Per l’opzione C: utilizza la modalità di test percorso per verificare che il nodo decisionale selezioni correttamente
Convalidare il tracciamento delle impression
Verifica che vengano tracciate le impression, i clic e le conversioni delle offerte.
- Verificare che gli eventi di interazione dell’offerta vengano visualizzati nei set di dati di tracciamento
- Conferma l’attribuzione tra le impression dell’offerta e le conversioni a valle
Documentazione di Experience League
Fase 7: configurare la generazione di rapporti e il monitoraggio delle prestazioni
Funzione applicazione: AJO: Reporting e analisi delle prestazioni
Questa fase imposta la generazione di rapporti per tenere traccia della distribuzione della selezione delle offerte, dei tassi di accettazione, dell’impatto sulla conversione e dei tassi di fallback. Questa fase tratta sia i rapporti nativi di AJO che l’analisi cross-channel basata su CJA.
Decisione: metodo di comunicazione
Determina quali strumenti di reporting sono necessari per l’analisi delle prestazioni delle offerte.
Dettagli chiave della configurazione
-
Rapporti nativi di AJO: monitora le prestazioni della campagna o del percorso utilizzando i rapporti incorporati.
- Interfaccia utente: Campagne > Seleziona campagna > Rapporto Tutti i tempi (o Rapporto live)
- Rivedi metriche specifiche per l’offerta: impression per offerta, tasso di click-through per offerta, tasso di fallback
- Monitora la consegna funnel: Target > Inviato > Consegnato > Aperture > Clic
-
Analisi CJA (consigliata): creazione di dashboard delle prestazioni delle offerte cross-channel.
- Configurare una connessione CJA con i set di dati di interazione dell’offerta AJO
- Creare una visualizzazione dati con dimensioni specifiche per l’offerta (nome dell’offerta, posizionamento, decisione) e metriche (impression, clic, conversioni)
- Crea un’analisi dell’area di lavoro per: distribuzione della selezione delle offerte, tasso di accettazione per segmento, impatto sui ricavi, coerenza delle offerte cross-channel
Documentazione di Experience League
Considerazioni sull’implementazione
This section covers guardrails, common pitfalls, best practices, and trade-off decisions for offer decisioning implementations.
Guardrail e limiti
Be aware of the following platform guardrails and limits when planning your implementation.
- Maximum of 10,000 approved personalized offers per sandbox – Decision Management guardrails
- Massimo 30 posizionamenti per decisione
- Maximum of 30 collection scopes per decision request
- I modelli di classificazione IA richiedono almeno 1.000 eventi di conversione per la formazione
- Offer capping counters may have a lag of up to a few seconds in high-throughput scenarios
- Edge decisions are limited to profile attributes available in the edge profile store
- Maximum of 4,000 segment definitions per sandbox – Platform guardrails
- Only one merge policy can be active on Edge per sandbox
- Maximum of 500 active live campaigns per sandbox
- Journey entry rate limit: 5,000 profiles per second
- Massimo 10 superfici di canale per tipo di canale per sandbox
Insidie comuni
Avoid these frequently encountered issues during implementation.
- Decision always returns fallback offer: This typically means personalized offers are not approved, are outside their validity date range, or eligibility rules do not match the test profile's attributes. Verify each condition: approval status, date range, and segment rule expression accuracy. Also check that capping limits have not been reached.
- Offer not appearing in collection: Ensure the offer has been tagged with the correct collection qualifier and that the collection filter matches. Offers must be both tagged and approved to appear in collection-based decision scopes.
- Ranking formula not applied: Verify that the formula is syntactically valid and references accessible profile attributes. Formula errors silently fall back to priority-based ranking with no visible error.
- Edge delivery returns empty personalization: Ensure the datastream is configured with the Adobe Journey Optimizer service enabled and that the decision scope is correctly formatted. Verify the edge-active merge policy exists.
- Inconsistent offers across channels: If separate decision policies are used per channel, the same profile may receive different offers. Use a single decision policy across channels for consistency, or accept intentional divergence based on channel-specific placements.
- Offer content not rendering in email: Verify the offer has a content representation that matches the email placement format (HTML or image URL). Missing representations result in blank placement zones.
Best practice
Follow these recommendations for a successful offer decisioning implementation.
- Start with a small offer catalog and iterate – Begin with 5-10 offers and expand as the decisioning framework is validated. This simplifies troubleshooting and ensures eligibility rules work correctly before scaling.
- Use collection qualifiers strategically – Tag offers by category (e.g., "Acquisition," "Retention," "Upsell") to enable flexible collection-based decision scopes that can be reused across campaigns and journeys.
- Always create meaningful fallback offers – Fallback offers are not just a safety net; they are the default experience for profiles that do not match any eligibility rule. Invest in fallback content that provides value even without personalization.
- Design eligibility rules to be mutually exclusive where possible – When multiple offers have overlapping eligibility, the ranking strategy becomes critical. If business requirements dictate a specific offer for a specific segment, make eligibility rules mutually exclusive rather than relying solely on ranking.
- Test with edge-representative profiles for Option B – Edge profiles contain a subset of hub profile attributes. Test with profiles that have edge-available attributes to ensure eligibility evaluates correctly in production.
- Monitor fallback rates as a health metric – A high fallback rate (above 20-30%) indicates that the offer catalog does not cover enough customer segments. Expand the offer catalog or broaden eligibility rules.
- Version decision policies rather than editing live ones – Create a new decision policy version rather than modifying an active one. This prevents disruption to live campaigns and enables A/B comparison of decision strategies.
Decisioni di compromesso
Consider the following trade-offs when making architectural and configuration decisions.
Eligibility precision vs. offer coverage
Tight eligibility rules ensure each offer reaches only the most relevant profiles, but may result in high fallback rates when profiles do not match any offer. Broad eligibility rules maximize offer coverage but reduce personalization precision.
- Privilegi limitati per l'idoneità: Tassi di accettazione più elevati, migliore personalizzazione, minore affaticamento delle offerte
- Ampi favori di idoneità: tassi di fallback inferiori, più profili ricevono offerte personalizzate, gestione più semplice delle regole
- Consiglio: inizia con regole di idoneità più ampie e le inasprisce in base ai dati sulle prestazioni. Monitora i tassi di fallback e i tassi di accettazione per trovare il giusto equilibrio. Utilizza le strategie di classificazione per differenziare le offerte ampiamente idonee.
Classificazione basata su priorità e classificazione basata su IA
La classificazione basata su priorità offre all’azienda il pieno controllo su quali offerte vengono visualizzate, mentre la classificazione basata su IA ottimizza la conversione ma riduce il controllo umano sulla selezione delle offerte.
- Preferenze basate su priorità: Controllo aziendale, prevedibilità, nessun requisito di dati di formazione, distribuzione immediata
- Preferenze basate sull'intelligenza artificiale: Ottimizzazione della conversione, individuazione di pattern imprevisti, adattamento automatico al comportamento del cliente in continua evoluzione
- Consiglio: utilizza la classificazione basata sulla priorità per i lanci iniziali e le offerte soggette a normative in cui il controllo aziendale è fondamentale. Transizione verso una classificazione basata sull’intelligenza artificiale per casi d’uso di volume elevato e ottimizzati per le prestazioni, una volta disponibili dati di conversione sufficienti (oltre 1.000 eventi).
Criteri decisionali singoli e criteri decisionali per singolo canale
Un unico criterio decisionale garantisce la coerenza dell’offerta su tutti i canali, ma limita l’ottimizzazione per canale. I criteri per canale consentono la classificazione specifica per il canale e l’idoneità, ma rischiano di causare esperienze cliente incoerenti.
- Un singolo criterio favorisce: coerenza cross-channel, gestione semplificata, reporting unificato
- I criteri per canale favoriscono: classificazione ottimizzata per il canale, idoneità specifica per il canale (ad esempio, offerte solo web), iterazione indipendente
- Consiglio: inizia con un singolo criterio di decisione per coerenza tra canali diversi. Crea criteri per canale solo quando i requisiti aziendali richiedono strategie di offerta specifiche per canale (ad esempio, vendite flash esclusive per il web).
Decisioning hub (opzione A/C) e Edge Decisioning (opzione B)
Le decisioni dell’hub hanno accesso al profilo completo, ma funzionano al momento dell’invio. Edge Decisioning funziona in tempo reale con latenza al secondo secondario, ma è limitato agli attributi di profilo disponibili all’edge.
- Il decisioning dell'hub favorisce: accesso ai dati del profilo completo, regole di idoneità complesse, volumi di campagne batch
- Il decisioning di Edge favorisce: Contesto in tempo reale, personalizzazione nella sessione, risposta al secondo secondario
- Consiglio: utilizza le decisioni hub per i canali in uscita (e-mail, push) in cui i dati di profilo completi migliorano la rilevanza dell'offerta. Utilizza le decisioni edge per i canali in entrata (web, app) in cui la risposta in tempo reale è fondamentale. Assicurati che le regole di idoneità per Edge utilizzino solo attributi disponibili Edge.
Documentazione correlata
Le risorse seguenti forniscono ulteriori dettagli sui componenti utilizzati in questo modello di caso d’uso.