Beslissing voorstel
Deze handleiding bevat een uitgebreide implementatiereferentie voor het bepalen van aanbiedingen met behulp van Adobe Journey Optimizer (AJO) Decisioning and Adobe Real-Time Customer Data Platform (RT-CDP). Het wordt ontworpen voor oplossingsarchitecten, marketing technologen, en implementatietechnici die de gecentraliseerde logica van de aanbiedingsselectie moeten uitvoeren die de volgende-beste aanbieding voor elk klantenprofiel over kanalen bepaalt.
Gebruik deze gids om te begrijpen wat moet worden gevormd, waar keuzen bestaan, en welke compromissen op elk besluit van toepassing zijn.
Het patroon ontkoppelt de "wat te tonen"beslissing van de "waar te om het"kanaallogica te tonen, toelatend verenigbare, geoptimaliseerde aanbiedingsselectie over e-mail, Web, mobiele app, en om het even welk ander aanraakpunt. AJO Decisioning beheert de volledige levenscyclus van de aanbieding: het creëren en catalogusbeheer, de toelatingsregels (die elke aanbieding kunnen zien), rangschikkingsstrategieën (hoe te om onder in aanmerking komende aanbiedingen te selecteren), plaatsingen (waar aanbiedingen verschijnen), en besluitvormingsbeleid (die alles samen binden).
Hoofdlettergebruik
Organisaties moeten op het moment van de interactie vaak het meest relevante aanbod, de meest relevante promotie of de meest relevante prikkel aan elke klant presenteren. Of de interactie nu plaatsvindt in een e-mailcampagne, op de homepage van een website, in een mobiele app of op een beslissingspunt binnen een meerstapsreis, de uitdaging is hetzelfde: Selecteer het optimale aanbod in een catalogus met beschikbare opties op basis van wie de klant is, waarvoor hij/zij in aanmerking komt en welke aanbieding het meest geschikt is om het gewenste resultaat te bereiken.
De besluitvorming van de aanbieding richt dit door alle aanbiedingsselectielogica in AJO te centraliseren Beslissingsbeheersmotor. In plaats van hardcodering biedt toewijzingen aan in afzonderlijke campagnes of kanalen, evalueert de besluitvormingsmotor de attributen van elk profiel, het publiekslidmaatschap, en contextafhankelijke signalen om de beste aanbieding in echt te bepalen - tijd. Deze centralisatie zorgt ervoor dat de zelfde klant verenigbare, geoptimaliseerde aanbiedingen ontvangt ongeacht welk kanaal zij door.
Dit patroon verschilt qua bereik van bekende gebruikers van websites/apps. Beslissing is kanaalagnostisch en gecentraliseerd, terwijl bekende bezoekers zich richten op de personalisatie van digitale oppervlakken. Het verschilt van gedragsaanbevelingen in het catalogusmodel — gebruik de aanbodbeslissing wanneer het in aanmerking komende item wordt bepaald door bedrijfsregels, toelatingsbeperkingen of wettelijke vereisten (promoties, financiële producten, stimulansen). Gebruik gedragsaanbevelingen als de itemset groot, voortdurend verandert en de selectie wordt gestuurd door gedragsmatige gelijkenis of affiniteitssignalen (productcatalogi, inhoudsbibliotheken).
Belangrijkste bedrijfsdoelstellingen
De volgende bedrijfsdoelstellingen worden gesteund door dit gebruiks gevalpatroon.
Lever gepersonaliseerde klantenervaringen
Inhoud, aanbiedingen en berichten voor individuele voorkeuren, gedrag en levenscyclusfase aanpassen.
KPIs: Betrokkenheid, de Tarieven van de Omzetting, Tevredenheid van de Klant (CSAT)
Overbodige verkoop- en upselopbrengst van de aandrijving
Aanvullende en hoogwaardige producten of services aan bestaande klanten promoten op basis van gedrag en aankoopgeschiedenis.
KPIs: Upsell/Cross-Sell %, Incrementele Inkomsten, de Waarde van het Leven van de Klant
de klantenloyaliteit en levenwaarde van de verhoging
Verbeter klantenverhoudingen en maximaliseer waarde op lange termijn door loyaliteitsprogramma’s, beloningen, en gepersonaliseerde betrokkenheid.
KPIs: de Waarde van het Leven van de Klant, Behoud, Upsell/Crosssell %
Voorbeelden van tactische gebruiksgevallen
De volgende scenario’s illustreren hoe de aanbodbeslissing in de praktijk kan worden toegepast.
- Volgende beste aanbieding in e-mailcampagnes — selecteer de meest relevante aanbieding per ontvanger op verzendtijd
- Promotiebanner in realtime op de website: door te beslissen wordt de aanbieding tijdens het laden van de pagina geselecteerd op basis van het profiel van de bezoeker
- Aangepaste interne kaart met de beste prikkel voor de levenscyclusfase van de gebruiker
- Interchannel bieden consistentie — dezelfde beslissingslogica dient voor e-mail, web en push, zodat de klant een uniforme aanbiedingservaring ziet
- Dynamische coupon- of kortingsselectie op basis van het waardeniveau van de klant (klanten met een hoge waarde ontvangen bijvoorbeeld een premium-aanbieding)
- Selectie voor productupgrade of upselvoorstel op basis van huidig abonnementsniveau
- Loyalty biedt verpersoonlijking op basis van tier en activiteitengeschiedenis
Kernprestatie-indicatoren
De volgende PKIs helpen de doeltreffendheid van een implementatie van het aanbiedingsbesluit meten.
Hoofdletterpatroon gebruiken
In deze sectie worden het uitvoeringsplan en de patroondefinitie voor het bepalen van de aanbieding beschreven.
het besluit van de Aanbieding
Gebruik de gecentraliseerde besluitvormingslogica om de op één na beste aanbieding of inhoud voor een profiel over kanalen te selecteren.
Plan van de Uitvoering: de Evaluatie van het Publiek > de Ontvankelijkheid van de Aanbieding > Rangschikkende Strategie > de Uitvoering van het Besluit > Levering > het Melden
Zie de sectie van de Opties van de Implementatie voor hoe elke samenstelling zich manifesteert.
Applicaties
In dit gebruikspatroon worden de volgende Adobe-toepassingen gebruikt.
- Adobe Journey Optimizer (AJO) — De motor van het Beheer van het Besluit voor de schepping van aanbiedingen, toelatingsregels, rangschikkingsstrategieën, plaatsingen, en besluitvormingsbeleid; kanaalconfiguratie en berichtontwerp voor levering van de aanbieding; campagne en uitvoering van reizen
- Adobe Real-Time Customer Data Platform (rt-CDP) — de evaluatie van het publiek voor de segmenten van de aanbiedingsbeleenbaarheid; profielgegevens en berekende kenmerken die worden gebruikt voor geschiktheid en classificatie
- Adobe Experience Platform (AEP) — Verenigde profielopslag, identiteitsresolutie, en gegevensstichting die zowel AJO als rt-CDP steunen
Basismogelijkheden
Voor dit gebruikspatroon moeten de volgende basisfuncties aanwezig zijn. Voor elk vermogen, wijst de status erop of het typisch wordt vereist, verondersteld om vooraf te worden gevormd, of niet van toepassing.
Ondersteunende mogelijkheden
De volgende mogelijkheden vergroten dit gebruikspatroon, maar zijn niet vereist voor kernuitvoering.
Toepassingsmogelijkheden
Dit plan oefent de volgende mogelijkheden van de Catalogus van de Mogelijkheid van de Toepassing uit. Capaciteiten worden toegewezen aan implementatiefasen in plaats van aan genummerde stappen.
Journey Optimizer (AJO)
De volgende lijst maakt een lijst van de mogelijkheden van AJO en de implementatiefasen waar zij worden gevormd.
Real-Time CDP (RT-CDP)
De volgende lijst maakt een lijst van mogelijkheden RT-CDP en de implementatiefasen waar zij worden gevormd.
Vereisten
Voltooi de volgende voorwaarden voordat u begint met de implementatie.
- [ ] AJO-sandbox met mogelijkheden voor Beslissingsbeheer ingeschakeld
- [ ] Gebruikersrollen met beslissingsbeheermachtigingen (aanbiedingen, plaatsingen, beslissingen maken/bewerken)
- [ ] Profielschema bevat kenmerken die vereist zijn om in aanmerking te komen voor een aanbieding (bijvoorbeeld een loyaliteitsniveau, klantensegment, abonnementsniveau)
- [ ] Profielgegevens zijn actueel en worden actief ingevoerd voor kenmerk-versheid voor geschiktheid
- [ ] Voor optie A (e-mail): E-mailkanaaloppervlak geconfigureerd met geverifieerd subdomein en geïntegreerde pool
- [ ] Voor optie B (Web/App): Web SDK geïmplementeerd met AJO-service ingeschakeld op de datastream; edge-active samenvoegingsbeleid geconfigureerd
- [ ] Voor optie C (reis): Reiscanvasmachtigingen en ten minste één gebeurtenis of publiek voor het betreden van de reis geconfigureerd
- [ ] Creatieve elementen aanbieden (afbeeldingen, kopiëren, CTA’s) voorbereid voor elke aanbieding en plaatsingscombinatie
- [ ] Inhoud van de terugvalaanbieding die voor elke plaatsing wordt voorbereid
- [ ] Soorten publiek voor aanbiedingstoelatingsregels gedefinieerd en geëvalueerd in RT-CDP
Implementatieopties
In deze sectie worden de beschikbare implementatieopties voor het bepalen van aanbiedingen beschreven. Elke optie dient een ander leveringskanaal en een ander gebruiksscenario.
Optie A: Beslissing van e-mailaanbiedingen
Deze optie is het meest geschikt voor het selecteren van de beste aanbieding om in uitgaande e-mailcampagnes op te nemen — promotionele e-mails, personalisatie voor nieuwsbrieven, levenscycluse-mails met dynamische aanbiedingsinhoud. Het besluit wordt genomen bij de tijd van de berichtteruggave voor elke ontvanger.
Hoe werkt het
Beslissingsbeleid wordt aangeroepen tijdens het genereren van e-mailberichten om de beste aanbieding voor elke ontvanger te selecteren. De e-mailsjabloon bevat een zone voor plaatsing van aanbiedingen waar de beslissingsengine de inhoudsweergave van de geselecteerde aanbieding (afbeelding, HTML of tekst) invoegt. Tijdens het verzenden evalueert de engine het profiel van elke ontvanger aan de hand van de regels voor het in aanmerking nemen van aanbiedingen, past de classificatiestrategie toe en sluit de inhoud van de winnende aanbieding in de e-mail in.
Deze benadering werkt met zowel geplande campagnes (die in de tijd van de campagneuitvoering worden geëvalueerd) als reis-ingebedde e-mail (die wordt geëvalueerd wanneer het profiel de knoop van de berichtactie bereikt). De inhoud van het aanbod — image, kop, kopie van het lichaam en CTA — wordt gepersonaliseerd per ontvanger op basis van de uitkomst van het besluit.
Belangrijkste overwegingen
- Aanbiedingsgeschiktheid wordt tijdens het verzenden geëvalueerd op basis van de huidige status van het profiel
- De evaluatie van het publiek in de batch is voldoende omdat beslissingen tijdens het weergeven van berichten plaatsvinden
- Voor elk aanbod is een HTML of afbeelding-inhoud nodig voor plaatsing van de e-mail
- Voor elke gebruikte e-mailplaatsing moet het terugvalvoorstel inhoud bevatten
Voordelen
- Eenvoudigste implementatiepad: maakt gebruik van standaard e-maillevering voor campagne of reizen
- Geen SDK-vereisten voor clients
- Werkt met bestaande e-mailinfrastructuur en kanaaloppervlakken
- Steunt grote publieksvolumes door de uitvoering van de partijcampagne
Beperkingen
- Het besluit wordt op het tijdstip van verzending genomen; kan zich niet aanpassen aan gedrag na verzending
- De inhoud van de aanbieding is statisch zodra e-mail wordt geleverd (geen updates in real time)
- Beperkt tot profielkenmerken die beschikbaar zijn in de opslagruimte van het hubprofiel (niet voor Edge)
Experience League-bronnen
Optie B: In real-time beslissingen over aanbiedingen via internet/app
Deze optie is het meest geschikt voor selectie in real-time op webpagina’s of mobiele apps — promotionele homepagebanners, widgets voor accountdashboardaanbiedingen, kaarten voor in-app-aanbiedingen of een digitaal oppervlak waarop de aanbieding moet worden geselecteerd op het moment dat de pagina wordt geladen of het scherm wordt weergegeven.
Hoe werkt het
Beslissingsbeleid wordt aangeroepen bij het laden van een pagina of het weergeven van een toepassingsscherm via het Edge-beslissingsnetwerk of op code gebaseerde ervaringen. Wanneer een bezoeker een pagina laadt, stuurt de Web SDK een aanvraag naar de Edge Network, die het randprofiel van de bezoeker evalueert aan de hand van de toelatingsregels voor aanbiedingen en rangschikkingsstrategieën. De geselecteerde aanbieding is teruggekeerd in de reactie en in de gevormde plaatsing op het digitale oppervlak teruggegeven.
Voor code-gebaseerde ervaringen, wint de toepassing de besluitreactie terug en geeft de aanbiedingsinhoud gebruikend douane front-end logica terug. Voor webkanaalervaringen kan het AJO-webkanaal de inhoud van de aanbieding rechtstreeks in de pagina injecteren door middel van visuele of op code gebaseerde authoring.
Belangrijkste overwegingen
- Vereist SDK- of Mobile SDK-implementatie van het web met AJO-service ingeschakeld op de gegevensstroom
- Edge-actief samenvoegbeleid is vereist voor realtime profielopzoekingen
- Voor subsidiabiliteit gebruikte doelgroepen moeten randevaluatie (eenvoudige kenmerkcontroles en segmentlidmaatschap) ondersteunen.
- De inhoud van de aanbieding vertegenwoordigingen zouden JSON of beeldURL formaten voor cliënt-zijrendering moeten gebruiken
- Het volgen van de druk moet worden uitgevoerd om aanbiedingsmeningen en klikken te vangen
Voordelen
- Selectie in realtime, tijdens de sessie, gebaseerd op de huidige profielstatus van de bezoeker
- Latentie in tweede beslissingsfase via Edge Network
- Aanbiedingen worden aangepast aan de meest recente profielgegevens die beschikbaar zijn aan de rand
- Ondersteunt A/B-tests van aanbiedingsstrategieën via contentexperimenten
Beperkingen
- SDK-implementatie op de client vereist (Web SDK of Mobile SDK)
- Edge-profiel heeft een subset van volledige hubprofielkenmerken — complexe toelatingsregels worden mogelijk niet correct geëvalueerd
- Edge-segmenten hebben beperkingen voor de complexiteit van segmentregels (geen query’s voor tijdreeksen)
- Vereist front-end ontwikkeling voor aangepaste rendering in op code gebaseerde ervaringen
Experience League-bronnen
hoe dit van Bekende-bezoeker Web/app verpersoonlijkingsOptie B verschilt:
De infrastructuur is identiek - zowel AJO die bij de rand met het Web SDK beslist als rand-actief fusiebeleid. Het verschil is het bestuursmodel van de catalogus. Deze optie is van toepassing op een catalogus met een beperkt aanbod met toelatingsregels, maximumaantal tellers en geldigheidsdatums. Gebruik deze optie wanneer bedrijfs- of regelgevingsbeperkingen bepalen welke aanbiedingen kunnen worden weergegeven en hoe vaak. 🔗 Optie B van 0} bekende bezoeker Web/app verpersoonlijking selecteert van inhoudspunten gebruikend segmentlidmaatschap of het rangschikken strategieën zonder het beheer van de levenscyclus aan te bieden. Als je objectset groot is, voortdurend verandert en geen aftopping of afhandeling van geschiktheid vereist, gebruikt je Bekende bezoeker Option B.
Optie C: Beslissingsknooppunt voor reis
Deze optie is het beste voor de selectie van aanbiedingen binnen een multi-step reis — het selecteren van de beste aanbieding op een besluitvormingspunt in een klantenreis, dan het leveren van het door de volgende actieknooppunt. Gebruik dit wanneer het biedingsbesluit deel van een bredere orchestratiestroom met wacht, voorwaarden, en veelvoudige berichtacties uitmaakt.
Hoe werkt het
Het beleid van het besluit wordt aangehaald van een besluitvormingsknoop binnen een de reiscanvas van AJO. Wanneer een profiel het beslissingsknooppunt bereikt, evalueert de engine de geschiktheid en rangschikking van de aanbieding om de optimale aanbieding te selecteren. De geselecteerde aanbieding informeert de volgende berichtactie — die inhoud aanbieden om te omvatten, welk kanaal te gebruiken, of welke reistak te nemen op basis van het aanbiedingsresultaat.
Deze aanpak maakt adaptieve reizen mogelijk wanneer het besluit tot het aanbieden van het aanbod van invloed is op latere stappen van de reis. Een reis kan bijvoorbeeld de beste aanbieding selecteren, deze via e-mail verzenden, wachten op betrokkenheid en vervolgens een pushmelding uitvoeren als het aanbod niet is geopend.
Belangrijkste overwegingen
- De reis moet met een beslissingsknoop worden ontworpen die door één of meerdere knopen van de berichtactie wordt gevolgd
- Aanbiedingsgeschiktheid wordt beoordeeld aan de hand van de status van het profiel op het moment dat het profiel het beslissingsknooppunt bereikt
- De reis wacht stappen tussen de beslissing en levering kan de staat van het profiel veroorzaken om te veranderen
- Kan combineren met vertakking van de reis om verschillende wegen te nemen gebaseerd op welke aanbieding werd geselecteerd
Voordelen
- Hiermee wordt selectie in meerdere stappen geïntegreerd
- Maakt adaptieve reizen mogelijk wanneer de keuzemogelijkheid van invloed is op de volgende stappen
- Biedt ondersteuning voor levering via meerdere kanalen binnen dezelfde reis (e-mail, push, SMS)
- Kan combineren met reisvoorwaarden voor service na aanbieding
Beperkingen
- Complexere organisatie dan standalone campagnebeslissingen
- Er gelden beperkingen voor de doorvoer van reizen (5.000 profielen per seconde)
- Beslissing is gekoppeld aan de context van de reis — veranderingen vereisen een ombuiging van de reis
- Reis moet opnieuw worden gepubliceerd om de catalogus met aanbiedingen of de actualiseringen van het besluitvormingsbeleid van kracht te laten worden
Experience League-bronnen
Optievergelijking
In de volgende tabel worden de drie implementatieopties vergeleken met de belangrijkste criteria.
Kies de juiste optie
Gebruik de volgende richtlijnen om de beste implementatieoptie voor uw gebruiksgeval te selecteren.
- kies Optie A als het primaire gebruiksgeval de beste aanbieding per ontvanger in uitgaande e-mailcampagnes selecteert en geen cliënt-kant SDK beschikbaar is. Dit is het eenvoudigste implementatiepad en werkt goed voor promotiemateriaal, nieuwsbrieven en levenscycluscampagnes.
- kies Optie B als de aanbiedingen in echt - tijd moeten worden geselecteerd op het ogenblik een bezoeker een Web-pagina laadt of een mobiele app opent. Hiervoor is Web SDK of Mobile SDK vereist en een ‘edge-active’ samenvoegbeleid, maar dit biedt de snelste, meest contextuele aanbiedingsselectie.
- kies Optie C als het aanbiedingsbesluit deel van een bredere klantenreis met veelvoudige stappen, wacht, en voorwaardelijk het vertakken uitmaakt. Dit is de juiste keuze wanneer het geselecteerde aanbod invloed moet hebben op de afhandelingsacties of wanneer meerkanaalsfollow-up op basis van de betrokkenheid van het aanbod nodig is.
- combineer opties wanneer de aanbiedingen over kanalen constant moeten worden geleverd. Gebruik hetzelfde beslissingsbeleid voor alle drie de opties om ervoor te zorgen dat een klant hetzelfde aanbod ziet in e-mail (Option A), op de website (Option B) en in een follow-up van de reis (Option C).
Uitvoeringsfasen
De volgende fasen schetsen de implementatiereeks van begin tot eind voor aanbiedingsbesluit.
Fase 1: Voorwaarden voor fundamentalisatie valideren
vermogen van de Toepassing: AEP: Data Modeling & Preparation, AEP: Identiteit en profielconfiguratie
Deze fase bevestigt dat de fundamentele gegevenslaag besluiten aanbiedt. Profielschema’s moeten de kenmerken bevatten die worden gebruikt in de toelatingsregels voor aanbiedingen en identiteitsconfiguratie moet het oplossen van profielen voor meerdere kanalen mogelijk maken.
Besluit: Profielkenmerken voor geschiktheid
Bepaal welke profielkenmerken worden gebruikt in de toelatingsregels voor aanbiedingen.
Belangrijkste configuratiedetails
- Controleer of het profielschema velden bevat waarnaar wordt verwezen in geschiktheidsregels (bijvoorbeeld
_tenantId.loyaltyTier,_tenantId.subscriptionType) - Er bestaat al een schema voor het bijhouden van de aanbiedingsinteractie voor indruk-, klik- en conversiegebeurtenissen
- Voor optie B: Verifieer het rand-actieve samenvoegbeleid wordt gevormd en Web SDK datastream heeft de dienst van AJO toegelaten
Experience League-documentatie
Fase 2: Evaluatie van publiek configureren
vermogen van de Toepassing: rt-CDP: Evaluatie publiek
Deze fase definieert en evalueert de soorten publiek die worden gebruikt als criteria om in aanmerking te komen voor de aanbieding. Deze doelgroepen bepalen welke klantsegmenten in aanmerking komen voor specifieke aanbiedingen (bv. “klanten met een hoge waarde” komen in aanmerking voor premiumaanbiedingen, “proefgebruikers” komen in aanmerking voor conversieaanbiedingen).
Besluit: Methode voor de evaluatie van het publiek
Bepaal hoe snel het lidmaatschap van de doelgroep moet worden bijgewerkt om in aanmerking te komen voor een aanbieding.
navigatie UI: Klant > Soorten publiek > leidt tot publiek > bouwt regel
Belangrijkste configuratiedetails
- Doelgroepen definiëren voor geschiktheid voor aanbiedingen (bijvoorbeeld “Loyalty Gold Tier”, “High Value Customers”, “Trial Users”)
- Definieer zo nodig het publiek voor onderdrukking (bijv. “Onlangs ontvangen aanbod X”)
- Voor optie B: Controleren of het publiek in aanmerking komt voor randevaluatie — vragen uit tijdreeksen en complexe aggregaties in segmentregelexpressies vermijden
Waar opties afwijken
voor Optie A (E-mailbesluit):
Evaluatie via batch of streaming is voldoende. Het publiek wordt geëvalueerd vóór of tijdens de uitvoering van de campagne. Complexe segmentregelexpressies inclusief op tijd gebaseerde voorwaarden en gebeurtenisaggregaties worden volledig ondersteund.
voor Optie B (Echte Web/App):
Edge-evaluatie is vereist. Het publiek moet eenvoudige attributencontroles of de voorwaarden van het segmentlidmaatschap gebruiken. De subsidiabiliteit van de rand van de test door de uitdrukking van de segmentregel te verifiëren kwalificeert voor randsegmentatie.
voor Optie C (de Node van het Beslissingsbesluit van de Reis):
Elke evaluatiemethode werkt afhankelijk van de toegangscriteria voor de reis. Als de reis op publiek-gebaseerd ingang gebruikt, past de methode van de publieksevaluatie de behoeften van de reis aan.
Experience League-documentatie
Fase 3: Beslissing instellen
vermogen van de Toepassing: AJO: Beslissing
Dit is de kernfase waarin de catalogus van aanbiedingen, de toelatingsregels, de rangschikkingsstrategieën en het besluitvormingsbeleid worden opgebouwd. Deze fase leidt tot de configuratie van de besluitvormingsmotor die alle leveringsopties (A, B, C) deelt.
Besluit: Het kanaal en de inhoudsindeling van de plaatsing
Bepaal waar aanbiedingen worden weergegeven en in welke indeling.
Besluit: Beoordelingsstrategie
Bepaal hoe de beste aanbieding uit in aanmerking komende aanbiedingen moet worden geselecteerd.
Besluit: Aanbiedingslimiet
Bepaal of er limieten moeten zijn voor het aantal keren dat een aanbieding wordt getoond.
navigatie UI: Componenten > Beslissingsbeheer > Plaatsingen/Regels/Aanbiedingen/Besluiten
Belangrijkste configuratiedetails
-
creeer plaatsingen - bepaal waar de aanbiedingen verschijnen door het kanaaltype en inhoudsformaat voor elke plaatsing te specificeren.
- UI: Componenten > Besluitbeheer > Plaatsingen
- Eén plaatsing per kanaal/indeling maken (bijvoorbeeld “Email Hero Banner - HTML”, “Web Homepage - JSON”, “Mobile App Card - JSON”)
-
bepaalt toelatingsregels - creeer regels gebruikend de uitdrukkingen van de segmentregel die profielattributen of publiekslidmaatschap van verwijzingen voorzien.
- UI: Componenten > Beslissingsbeheer > Regels
- Regels kunnen verwijzen naar het lidmaatschap van het publiek, profielkenmerken (loyaliteitslaag, abonnementstype), datumbeperkingen of contextafhankelijke gegevens
-
creeer gepersonaliseerde aanbiedingen — Bouw elke aanbieding met inhoudsvertegenwoordiging voor elke plaatsing, wijs geschiktheidsregels toe, plaats prioriteit, en vorm facultatieve aftappen.
- UI: Componenten > Beslissingsbeheer > Aanbiedingen > Aanbieding maken
- Elke aanbieding heeft een inhoudsweergave per plaatsing nodig (bijvoorbeeld HTML voor e-mail, JSON voor web)
- Wijs toelatingsregels toe om te controleren welke profielen elke aanbieding kunnen zien
- Geldigheidsdatums voor aanbieding instellen (begin/einde) en optionele frequentietoewijzing instellen
- Elke aanbieding goedkeuren om ervoor te zorgen dat deze in aanmerking komt voor een beslissing
-
creeer fallback aanbiedingen — Bouw een standaardaanbieding voor elke plaatsing die wordt getoond wanneer geen gepersonaliseerde aanbieding kwalificeert.
- UI: Componenten > Beslissingsbeheer > Aanbiedingen > Fallback-aanbieding maken
- Voor elke plaatsing die in de beslissing wordt gebruikt, moet een reservekopie zijn aangebracht
-
creeer inzamelingsbepalende eigenschappen en inzamelingen - organiseer aanbiedingen in inzamelingen gebruikend bepalingsmarkeringen.
- UI: Componenten > Beslissingsbeheer > Verzamelingsaanduidingen
- Groepsgerelateerde aanbiedingen (bv. “Summer Promotions”, “Loyalty Rewards”) voor gebruik in besluitvormingsgebieden
-
creeer besluitvormingsbeleid — Bind plaatsingen, inzamelingen, het rangschikken strategieën, en reserveaanbiedingen in uitvoerbare besluiten.
- UI: Componenten > Beslissingsbeheer > Besluiten > Beslissingen maken
- Elk beslissingsbereik koppelt een plaatsing aan een verzameling en geeft de waarderingsmethode op
Experience League-documentatie
Fase 4: Kanaal en oppervlak configureren
vermogen van de Toepassing: AJO: Kanaalconfiguratie
Deze fase vormt de kanaaloppervlakten waardoor de aanbiedingen zullen worden geleverd. De configuratie is afhankelijk van de implementatieoptie(s).
Besluit: Het type Channel
Bepaal welk overseinenkanaal het gebruiksgeval vereist.
Waar opties afwijken
voor Optie A (E-mailbesluit):
- UI: Beheer > Kanalen > Kanaaloppervlakken > oppervlak maken (e-mail)
- Subdomein, IP-pool, naam/e-mail van afzender, antwoordinstellingen, abonnementsinstellingen configureren
- Verifieer SPF, DKIM, en DMARC verslagen voor het verzendende subdomain
voor Optie B (Echte Web/App):
- UI: Beheer > Kanalen > Kanaaloppervlakken > Oppervlak maken (Web of In-app)
- Voor het web: Het URL-patroon van het weboppervlak configureren
- Voor code-gebaseerde ervaringen: De oppervlakte-URI voor de toepassing definiëren
- Controleren of de gegevensstroom AJO-service heeft ingeschakeld
voor Optie C (de Knoop van het Besluit van de Reis):
- Kanaaloppervlakken configureren voor elk kanaal dat wordt gebruikt tijdens de rit (e-mail, push, SMS of web)
- Elke actie van het reisbericht vereist een overeenkomstige actieve kanaaloppervlakte
Experience League-documentatie
Fase 5: Inhoud en levering configureren
vermogen van de Toepassing: AJO: Berichtgeving, AJO: Campagne uitvoeren
Deze fase ontwerpt de berichtmalplaatjes of ervaringsoppervlakken die de geselecteerde aanbieding tonen, dan vormt het leveringsmechanisme (campagne, reis, of code-gebaseerde ervaring).
Besluit: Inhoudsaanpak voor rendering van aanbiedingen
Bepaal hoe de aanbiedingsinhoud in het bericht of de ervaring moet worden geïntegreerd.
Besluit: Campagnertype (alleen Option A)
Bepaal of dit een geplande marketing campagne of een API-getriggerde campagne is.
Waar opties afwijken
voor Optie A (E-mailbesluit):
-
Het e-mailbericht schrijven met de e-mailtoepassing Designer
- UI: Campagnes > Campagne maken > E-mail selecteren > Inhoud bewerken
- Voeg een component voor de aanbiedingsbeslissing in de e-maillay-out in om de plaatsingszone te definiëren
- Voeg personalisatietokens voor profiel-vlakke inhoud (naam, loyaliteitsrij) toe
- De onderwerpregel en de voorheader configureren met optionele personalisatie
-
De campagne maken en configureren
- UI: Campagnes > Campagne maken > Gepland of API-geactiveerd
- Het doelpubliek binden en het kanaaloppervlak selecteren
- Het uitvoeringsschema of de configuratie van de API-trigger instellen
- De campagne evalueren en activeren
voor Optie B (Echte Web/App):
-
De op code gebaseerde ervaring of het webkanaal configureren
- UI: Campagnes > Campagne maken > Ervaring op basis van code (of Web)
- Het beslissingsbeleid koppelen aan het ervaringsoppervlak
- Definieer de renderindeling (JSON-reactie voor op code gebaseerde code; visuele editor voor webkanaal)
-
Rendering op de client implementeren
- Gebruik de Web SDK
sendEvent-reactie om de geselecteerde aanbieding op te halen - De aanbiedingsinhoud renderen in de opgegeven plaatsing op de pagina
- Afbeelding importeren en klikken op bijhouden
- Gebruik de Web SDK
voor Optie C (de Knoop van het Besluit van de Reis):
-
De reis ontwerpen met een beslissingsknooppunt
- UI: Reizen > Reis maken > Beslissingsknooppunt toevoegen
- Vorm de besluitknoop om het besluitvormingsbeleid van Fase 3 aan te halen
-
Knoppen voor berichtactie toevoegen na de beslissing
- E-mail-, push- of SMS-acties configureren die verwijzen naar de geselecteerde aanbieding
- Wachtstappen, voorwaarden of vertakking toevoegen op basis van de service van de aanbieding
-
De reis publiceren
Experience League-documentatie
Fase 6: Testen en valideren
vermogen van de Toepassing: AJO: Beslissing, AJO: Berichtontwerp
In deze fase wordt gecontroleerd of de beslissingsengine de juiste aanbiedingen voor testprofielen retourneert en of de inhoud van de aanbieding op de juiste wijze wordt weergegeven in elk leveringskanaal.
Bepalingslogica testen
Gebruik testprofielen met bekende kenmerken om te controleren of de juiste aanbiedingen zijn geselecteerd op basis van geschiktheid en rangschikking.
- Testprofielen maken die voldoen aan verschillende geschiktheidscriteria (bijvoorbeeld Gold-laag, Silver-laag, proefgebruiker)
- Controleer of elk testprofiel het verwachte aanbod ontvangt
- Controleren of profielen die voldoen aan geen subsidiabiliteitsregels, een fallback-aanbieding ontvangen
Rendering van inhoud testen
Bekijk de inhoud van de aanbieding in elk leveringskanaal.
- Voor optie A: Gebruik e-mailvoorvertoning met testprofielen om te controleren of de inhoud van de aanbieding correct wordt weergegeven
- Voor optie B: De Edge-beslissingsrespons testen in een testomgeving
- Voor optie C: Gebruik de testmodus voor reizen om te controleren of het beslissingsknooppunt correct is geselecteerd
Tekstspatiëring valideren
Bevestig dat er afbeeldingen worden bijgehouden die afbeeldingen kunnen weergeven, klikken en conversies.
- Controleren of er interactiegebeurtenissen voor aanbiedingen worden weergegeven in de volgende gegevenssets
- Toewijzing bevestigen tussen aanbiedingsindrukken en downstreamomzettingen
Experience League-documentatie
Fase 7: Rapportage en prestatiebewaking configureren
vermogen van de Toepassing: AJO: Rapportage en prestatieanalyse
In deze fase worden de rapportage zodanig ingesteld dat de distributie van aanbiedingen, acceptatiecijfers, conversie-effecten en terugvalpercentages worden bijgehouden. In deze fase worden zowel de eigen AJO-rapporten als de op CJA gebaseerde analyse van meerdere kanalen behandeld.
Besluit: Rapportagemethode
Bepaal welke rapporteringshulpmiddelen nodig zijn voor de analyse van de aanbiedingsprestaties.
Belangrijkste configuratiedetails
-
inheemse rapportering van AJO — de campagne of de reisprestaties van de monitor gebruikend ingebouwde rapporten.
- UI: Campagnes > Campagne selecteren > Alle tijdrapport (of Live-rapport)
- Specifieke maatstaven voor aanbiedingen bekijken: impressies per aanbieding, doorkliktarief per aanbieding, terugvalpercentage
- Levering funnel controleren: Gericht > Verzonden > Geleverd > Openen > Klikken
-
de analyse van CJA (geadviseerd) — Bouw dwars-kanaal prestaties dashboards aan.
- Een CJA-verbinding configureren, inclusief AJO-gegevens voor interactie
- Een gegevensweergave maken met de aanbiedingsspecifieke afmetingen (naam van aanbieding, plaatsing, beslissing) en metriek (afbeeldingen, klikken, conversies)
- Workspace-analyse maken voor: de selectiedistributie van aanbiedingen, het aanvaardingspercentage per segment, opbrengsteffect, dwars-kanaalaanbiedingen consistentie
Experience League-documentatie
Implementatieoverwegingen
In deze sectie worden onder meer de begeleiding, gemeenschappelijke valkuilen, beste praktijken en afwegingsbesluiten voor het uitvoeren van beslissingen over aanbiedingen besproken.
Guardrails en limieten
Houd rekening met de volgende platformhulplijnen en -beperkingen wanneer u de implementatie plant.
- Maximum van 10.000 goedgekeurde gepersonaliseerde aanbiedingen per zandbak - de gidsen van het Beheer van het Besluit
- Maximaal 30 stages per besluit
- Maximaal 30 verzamelingsbereiken per beslissingsverzoek
- Voor AI-classificatiemodellen is een minimum van 1.000 conversieevenementen vereist voor training
- Aanbiedings het begrenzen tellers kunnen een vertraging van tot een paar seconden in hoge productiescenario’s hebben
- Edge-beslissingen zijn beperkt tot profielkenmerken die beschikbaar zijn in de winkel met randprofielen
- Maximum van 4.000 segmentdefinities per zandbak - de gidsen van het Platform
- Er kan slechts één samenvoegbeleid actief zijn op Edge per sandbox
- Maximaal 500 actieve live campagnes per sandbox
- Grenswaarde voor het aantal reizen: 5.000 profielen per seconde
- Maximaal 10 kanaaloppervlakken per kanaaltype per sandbox
Veelvoorkomende valkuilen
Vermijd deze vaak voorkomende problemen tijdens de implementatie.
- het Besluit keert altijd terugvalaanbieding terug: dit typisch betekent gepersonaliseerde aanbiedingen niet worden goedgekeurd, buiten hun waaier van de geldigheidsdatum zijn, of de toelatingsregels passen niet de attributen van het testprofiel aan. Controleer elke voorwaarde: goedkeuringsstatus, datumbereik en nauwkeurigheid van de segmentregelexpressie. Controleer ook of de plafondlimiet niet is bereikt.
- Aanbieding die niet in inzameling verschijnt: verzeker de aanbieding met het correcte inzamelingsbepaler is geëtiketteerd en dat de gelijken van de inzamelingsfilter. Aanbiedingen moeten gelabeld en goedgekeurd zijn om in een op verzameling gebaseerd beslissingsbereik te worden weergegeven.
- het Rangschikken formule niet toegepast: verifieer dat de formule syntactisch geldig is en verwijzingen toegankelijke profielattributen. Formulatiefouten worden zonder meer teruggezet naar op prioriteit gebaseerde rangschikking zonder zichtbare fout.
- de levering van Edge keert lege verpersoonlijking terug: zorg de datastream wordt gevormd met de Adobe Journey Optimizer toegelaten dienst en dat het besluitvormingswerkingsgebied correct geformatteerd is. Controleer of het arceringsactieve samenvoegbeleid bestaat.
- Inconsistente aanbiedingen over kanalen: als het afzonderlijke besluitvormingsbeleid per kanaal wordt gebruikt, kan het zelfde profiel verschillende aanbiedingen ontvangen. Gebruik één enkel besluitvormingsbeleid over kanalen voor consistentie, of keur opzettelijke divergentie op kanaal-specifieke plaatsingen toe.
- inhoud van de aanbieding die niet in e-mail teruggeeft: verifieer de aanbieding een inhoudsvertegenwoordiging heeft die het formaat van de e-mailplaatsing (HTML of beeld URL) aanpast. Ontbrekende weergaven resulteren in lege plaatsingszones.
Aanbevolen procedures
Volg deze aanbevelingen voor een succesvolle implementatie van het Aanbiedingsbesluit.
- Begin met een kleine aanbiedingscatalogus en herhaling - begin met 5-10 aanbiedingen en breid uit aangezien het beslissingskader wordt bevestigd. Dit vereenvoudigt het oplossen van problemen en verzekert geschiktheidsregels correct werken alvorens te schrapen.
- de inzamelingsbepalers van het Gebruik strategisch - de aanbiedingen van de markering door categorie (b.v., "Aankoop,"Behoud,“Upsell”) om flexibele op inzameling-gebaseerde besluitvormingswerkingsgebieden toe te laten die over campagnes en reizen kunnen worden opnieuw gebruikt.
- creeer altijd betekenisvolle reserveaanbiedingen — De aanbiedingen van de reserve zijn niet enkel een veiligheidsnet; dit zijn de standaardervaring voor profielen die niet overeenkomen met een toelatingsregel. Investeer in fallback-inhoud die zelfs zonder personalisatie waarde biedt.
- de toelatingsregels van het Ontwerp om waar mogelijk elkaar uit te sluiten - wanneer de veelvoudige aanbiedingen overlappende geschiktheid hebben, wordt de rangschikkende strategie kritiek. Indien de zakelijke vereisten een specifieke aanbieding voor een bepaald segment voorschrijven, sluit de toelatingsregels dan wederzijds uit in plaats van alleen op rangschikking te vertrouwen.
- Test met rand-representatieve profielen voor Optie B - de profielen van Edge bevatten een ondergroep van de attributen van het hubprofiel. Testen met profielen met randkenmerken om te controleren of geschiktheid correct wordt beoordeeld in de productie.
- de fallbacktarieven van de Monitor als gezondheid metrisch - een hoog fallback tarief (boven 20-30%) wijst erop dat de aanbiedingscatalogus genoeg klantensegmenten niet behandelt. Breid de aanbiedingencatalogus uit of verruim de subsidiabiliteitsregels.
- het besluitvormingsbeleid van de Versie eerder dan het uitgeven levende degenen - creeer een nieuwe versie van het besluitvormingsbeleid eerder dan het wijzigen van actieve. Dit voorkomt verstoring van live campagnes en maakt een A/B-vergelijking van besluitvormingsstrategieën mogelijk.
Handelsbesluiten
Houd rekening met de volgende compromissen wanneer u beslissingen neemt op het gebied van architectuur en configuratie.
Geschiktheidsbepaling versus dekking van aanbieding
De strenge toelatingsregels zorgen ervoor dat elke aanbieding alleen de meest relevante profielen bereikt, maar kunnen resulteren in hoge terugvalpercentages wanneer de profielen niet overeenkomen met een aanbod. De brede toelatingsregels maximaliseren aanbiedingsdekking maar verminderen personaliseringsprecisie.
- de dichte toelatingsgunsten: Hogere goedkeuringspercentages, betere verpersoonlijking, lagere aanbiedingsvermoeidheid
- brede geschiktheidsgunsten: Lagere fallback tarieven, ontvangen meer profielen gepersonaliseerde aanbiedingen, eenvoudiger regelbeheer
- Aanbeveling: begin met bredere geschiktheidsregels en draai hen die op prestatiesgegevens worden gebaseerd aan. Houd de terugvalpercentages en acceptatiecijfers in de gaten om de juiste balans te vinden. Gebruik waarderingsstrategieën om onderscheid te maken tussen breed in aanmerking komende aanbiedingen.
Op basis van prioriteit versus op AI gerangschikte rangschikking
Rangschikking op basis van prioriteit geeft de onderneming volledige controle over welke aanbiedingen worden getoond, terwijl de op AI-rangschikking optimaliseert voor omzetting maar menselijke controle over aanbiedingsselectie vermindert.
- op prioriteit-gebaseerde voorkeur: Bedrijfs controle, voorspelbaarheid, geen vereiste van opleidingsgegevens, directe plaatsing
- AI-gerangschikte voorkeur: de optimalisering van de Omzetting, ontdekking van onverwachte patronen, automatische aanpassing aan veranderend klantengedrag
- Aanbeveling: Op prioriteit-gebaseerde rangschikking van het gebruik voor aanvankelijke lanceringen en regelgevende-gevoelige aanbiedingen waar de bedrijfscontrole van het grootste belang is. De overgang naar AI-gerangschikt voor gebruik met hoge volumes en optimale prestaties zodra er voldoende conversiegegevens (1.000+ gebeurtenissen) beschikbaar zijn.
Beleid met één keuze tegenover beleid met één kanaal
Eén enkel beslissingsbeleid zorgt voor consistentie op alle kanalen, maar beperkt optimalisatie per kanaal. Het beleid per kanaal staat kanaal-specifieke rangschikking en geschiktheid toe maar risico inconsistente klantenervaringen.
- Enig beleid begunstigt: de consistentie van het Kanaal, eenvoudiger beheer, verenigde rapportering
- per-kanaalbeleid gunt: kanaal-geoptimaliseerde rangschikking, kanaal-specifieke geschiktheid (b.v., Web-slechts aanbiedingen), onafhankelijke herhaling
- Aanbeveling: begin met één enkel besluitvormingsbeleid voor dwars-kanaalconsistentie. Creeer per-kanaalbeleid slechts wanneer de bedrijfsvereisten kanaalspecifieke aanbiedingsstrategieën (b.v., Web-exclusieve flitsverkoop) vragen.
De beslissing van de hub (Optie A/C) vs. randbesluit (Optie B)
Het besluit van de hub heeft toegang tot het volledige profiel maar werkt bij verzendtijd. Edge-beslissingen worden in real-time uitgevoerd met een latentie van subseconden, maar zijn beperkt tot kenmerken van randbeschikbare profielen.
- de beslissingsvoorkeur van de Hub: Toegang tot volledige profielgegevens, complexe toelatingsregels, de volumes van de partijcampagne
- de besluiten van Edge begunstigen: context In real time, in-session verpersoonlijking, sub-tweede reactie
- Aanbeveling: hubbesluit van het gebruik voor uitgaande kanalen (e-mail, duw) waar de volledige profielgegevens relevantie verbeteren. Gebruik randbeslissingen voor binnenkomende kanalen (web, app) waar real-time respons van essentieel belang is. Ervoor zorgen dat randgebruiksregels alleen randkenmerken bevatten.
Gerelateerde documentatie
De volgende bronnen bieden aanvullende informatie over de componenten die in dit gebruikspatroon worden gebruikt.