Avtalsbeslut
Den här guiden innehåller en omfattande implementeringsreferens för offertbeslut med hjälp av Adobe Journey Optimizer (AJO) Decisioning och Adobe Real-Time Customer Data Platform (RT-CDP). Det är utformat för lösningsarkitekter, marknadsföringsteknologer och implementeringstekniker som behöver implementera en centraliserad logik för val av erbjudanden som bestämmer nästa bästa erbjudande för varje kundprofil i olika kanaler.
Använd den här guiden för att förstå vad som behöver konfigureras, var det finns val och vilka kompromisser som gäller för varje beslut.
Mönstret skiljer"vad som ska visas" från kanallogiken"var det ska visas", vilket möjliggör ett enhetligt och optimerat urval av erbjudanden för e-post, webben, mobilappar och andra kontaktytor. AJO Decisioning hanterar hela erbjudandets livscykel: skapande och kataloghantering av erbjudanden, regler för behörighet (vem som kan se varje erbjudande), rangordningsstrategier (hur man väljer bland giltiga erbjudanden), placeringar (där erbjudanden visas) och beslutsstrategier (som knyter ihop allt).
Använd ärendeöversikt
Organisationer måste ofta presentera det mest relevanta erbjudandet, erbjudandet eller incitamentet för varje kund vid interaktionen. Oavsett om interaktionen sker i en e-postkampanj, på en webbplatshem, i en mobilapp eller vid en beslutspunkt under en flerstegsresa är utmaningen densamma: välj det optimala erbjudandet från en katalog med tillgängliga alternativ baserat på vem kunden är, vad de är kvalificerade för och vilket erbjudande som mest troligt leder till önskat resultat.
Detta hanteras genom att all logik för val av erbjudanden centraliseras i AJO beslutsmotor. I stället för att hårdkoda tilldelningar av erbjudanden i enskilda kampanjer eller kanaler utvärderar beslutsmotorn varje profils attribut, målgruppsmedlemskap och sammanhangsberoende signaler för att avgöra vilket som är det bästa erbjudandet i realtid. Denna centralisering säkerställer att samma kund får enhetliga, optimerade erbjudanden oavsett vilken kanal de använder.
Det här mönstret skiljer sig från kända webb-/apppersonaliseringar i omfånget - offertbeslut är kanalbaserat och centraliserat, medan personalisering för kända besökare fokuserar på digital ytanpassning. Det skiljer sig från beteenderekommendationer i katalogmodell - beslut om erbjudanden när den stödberättigande artikeluppsättningen styrs av affärsregler, behörighetskrav eller lagstadgade krav (kampanjer, finansiella produkter, incitament). Använd beteenderekommendation när objektuppsättningen är stor, ändras kontinuerligt och markeringen styrs av beteendemässiga likhets- eller tillhörighetssignaler (produktkataloger, innehållsbibliotek).
Viktiga verksamhetsmål
Följande affärsmål stöds av det här användningsmönstret.
Leverera personaliserade kundupplevelser
Skräddarsy innehåll, erbjudanden och budskap efter enskilda preferenser, beteenden och livscykelsteg.
KPI engagemang, konverteringsgrader, kundnöjdhet (CSAT)
Öka korsförsäljning och merförsäljning
Marknadsför kompletterande och premiumbaserade produkter eller tjänster till befintliga kunder baserat på beteenden och inköpshistorik.
KPI, merförsäljning/korsförsäljning %, inkrementell intäkt, kundens livstidsvärde
Öka kundlojalitet och livstidsvärde
Fördjupa kundrelationerna och maximera det långsiktiga värdet genom lojalitetsprogram, belöningar och personaliserat engagemang.
KPI Kundens livstidsvärde, kvarhållning, merförsäljning/korsförsäljning %
Exempel på taktiska användningsfall
Följande scenarier visar hur offertbeslut kan tillämpas i praktiken.
- Nästa bästa erbjudande i e-postkampanjer - välj den mest relevanta kampanjen per mottagare vid sändning
- Realtidskampanjbanderoll på webbplats - beslut väljer erbjudandet vid sidladdning baserat på besökarens profil
- Personligt anpassat appkort med de bästa incitamenten för användarens livscykelstadium
- Enhetliga erbjudanden i flera kanaler - samma beslutslogik används för e-post, webben och push så att kunderna får en enhetlig upplevelse
- Dynamiskt kupong- eller rabattval baserat på kundvärdesnivå (t.ex. värdefulla kunder får ett premiumerbjudande)
- Produktuppgradering eller merförsäljning baserat på den aktuella prenumerationsnivån
- Personalisering av lojalitetserbjudanden baserat på nivå- och aktivitetshistorik
Nyckeltal för prestanda
Följande nyckeltal hjälper till att mäta effektiviteten i en implementering av offertbeslut.
Använd skiftlägesmönster
I det här avsnittet beskrivs funktionskedjan och mönsterdefinitionen för offertbeslut.
Erbjudandebeslut
Använd centraliserad beslutslogik för att välja nästa bästa erbjudande eller innehåll för en profil över alla kanaler.
Funktionskedja: Målgruppsutvärdering > Erbjudandebehörighet > Rankningsstrategi > Beslutskörning > Leverans > Rapportering
Se avsnittet Implementeringsalternativ för hur varje disposition visas.
Tillämpningar
Följande Adobe-program används i det här fallmönstret.
- Adobe Journey Optimizer (AJO) - Beslutshanteringsmotor för att skapa erbjudanden, regler för kvalificering, rangordningsstrategier, praktik och beslutspolicyer; kanalkonfiguration och meddelandeskapande för erbjudanden; kampanj- och resekörning
- Adobe Real-Time Customer Data Platform (RT-CDP) - Målgruppsutvärdering för erbjudandeberättigandesegment, profildata och beräknade attribut som används för kvalificering och rankning
- Adobe Experience Platform (AEP) - Enhetligt profilarkiv, identitetsupplösning och datamängd som stöder både AJO och RT-CDP
Foundationsfunktioner
Följande grundläggande funktioner måste finnas för det här användningsmönstret. För varje funktion anger statusen om den vanligtvis är obligatorisk, antas vara förkonfigurerad eller inte tillämplig.
Stödfunktioner
Följande funktioner förstärker det här användningsmönstret, men behövs inte för att köra kärnan.
Programfunktioner
I den här planen används följande funktioner från programfunktionskatalogen. Funktioner mappas till implementeringsfaser i stället för till numrerade steg.
Journey Optimizer (AJO)
I följande tabell visas AJO-funktioner och de implementeringsfaser där de är konfigurerade.
Real-Time CDP (RT-CDP)
I följande tabell visas RT-CDP-funktioner och de implementeringsfaser där de är konfigurerade.
Förutsättningar
Slutför följande krav innan du börjar implementera.
- [ ] AJO-sandlåda med funktioner för beslutshantering aktiverat
- [ ] användarroller med beslutsbehörigheter (skapa/redigera erbjudanden, ersättningar, beslut)
- [ ] Profilschemat innehåller attribut som krävs för att erbjuda behörighet (t.ex. lojalitetsnivå, kundsegment, prenumerationsnivå)
- [ ] Profildata är aktuella och har aktivt importerats för aktualitet av berättigandeattribut
- [ ] för alternativ A (e-post): Ytan på e-postkanalen har konfigurerats med verifierad underdomän och en värmad IP-pool
- [ ] för alternativ B (Web/App): Web SDK som implementerats med AJO-tjänsten aktiverad på datastream; edge-active merge policy konfigurerad
- [ ] för alternativ C (Resa): Researbetsytebehörigheter och minst en resestarthändelse eller konfigurerad målgrupp
- [ ] Erbjud kreativa resurser (bilder, kopia, CTA:er) som förberetts för varje erbjudande och monteringskombination
- [ ] Reserverbjudandeinnehåll har förberetts för varje placering
- [ ] målgrupper för regler för anbudsbehörighet som definieras och utvärderas i RT-CDP
Implementeringsalternativ
I det här avsnittet beskrivs de tillgängliga implementeringsalternativen för offertbeslut. Varje alternativ har olika leveranskanaler och har olika skiftlägeskontext.
Alternativ A: Beslut om e-posterbjudande
Det här alternativet är bäst om du väljer det bästa erbjudandet som ska ingå i utgående e-postkampanjer - kampanjmeddelanden, personalisering av nyhetsbrev, e-postmeddelanden i livscykeln med dynamiskt erbjudandeinnehåll. Beslutet fattas vid meddelanderenderingstid för varje mottagare.
Så här fungerar det
Beslutsprinciper anropas vid återgivning av e-postmeddelanden för att välja det bästa erbjudandet för varje mottagare. E-postmallen innehåller en offertplaceringszon där beslutsmotorn infogar det valda erbjudandets innehållsbeteckning (bild, HTML eller text). Vid sändning utvärderar motorn varje mottagares profil mot reglerna för anbudsbehörighet, tillämpar rangordningsstrategin och bäddar in innehållet i det vinnande erbjudandet i e-postmeddelandet.
Den här metoden fungerar med både schemalagda kampanjer (utvärderade vid körning av kampanjer) och reseinbäddade e-postmeddelanden (utvärderade när profilen når noden för meddelandeåtgärder). Innehållet i erbjudandet - bild, rubrik, brödtext och CTA - personaliseras per mottagare baserat på beslutsresultatet.
Viktiga överväganden
- Erbjudandets berättigande utvärderas vid sändning med hjälp av profilens aktuella tillstånd
- Det räcker med att utvärdera grupper eftersom beslut fattas vid meddelandeåtergivning
- Varje erbjudande behöver en HTML- eller bildåtergivning för e-postplacering
- Reserverbjudandet måste ha innehåll för varje e-postplacering som används
Fördelar
- Enklare implementeringsväg - använder standardkampanjer eller e-postleverans via resan
- Inga krav från SDK på klientsidan
- Fungerar med befintlig e-postinfrastruktur och kanalytor
- Stöd för stora målgruppsvolymer genom batchkampanjkörning
Begränsningar
- Beslut fattas vid sändning; det går inte att anpassa sig till beteendet efter sändning
- Erbjudandet är statiskt när e-postmeddelandet har skickats (inga uppdateringar i realtid)
- Begränsad till profilattribut som är tillgängliga i navprofilarkivet (inte kant)
Experience League-resurser
Alternativ B: Beslut om erbjudande i realtid för webb/app
Det här alternativet passar bäst för val av erbjudanden i realtid på webbsidor eller mobilappar - kampanjbanners för hemsidor, widgetar för kontoinstrumentpanel, erbjudandekort i appen eller någon annan digital yta där erbjudandet ska väljas när sidan läses in eller skärmåtergivningen.
Så här fungerar det
Beslutsprinciper anropas vid sidinläsning eller appskärmsåtergivning via Edge Decisioning-nätverket eller kodbaserade upplevelser. När en besökare läser in en sida skickar Web SDK en förfrågan till Edge Network, som utvärderar besökarens edge-profil mot reglerna för erbjudandebehörighet och rankningsstrategier. Det valda erbjudandet returneras som svar och återges i den konfigurerade placeringen på den digitala ytan.
För kodbaserade upplevelser hämtar programmet beslutssvaret och återger erbjudandeinnehållet med hjälp av anpassad logik. För webbkanalsupplevelser kan AJO webbkanal mata in erbjudandeinnehållet direkt på sidan med visuell eller kodbaserad redigering.
Viktiga överväganden
- Kräver att SDK eller SDK för mobiler implementeras med AJO-tjänsten aktiverad på datastream
- Edge-aktiv kopplingsregel krävs för profilsökningar i realtid
- Målgrupper som används för kvalificering måste stödja edge-utvärdering (enkla attributkontroller och segmentmedlemskap)
- Erbjudanderepresentationer bör använda JSON- eller bild-URL-format för återgivning på klientsidan
- Tryckspårning måste implementeras för att hämta in offertvisningar och klickningar
Fördelar
- Val av sessionsrelaterade erbjudanden i realtid baserat på besökarens aktuella profiltillstånd
- Beslutsfördröjning under andra fasen via Edge Network
- Erbjudandena anpassar sig till de mest aktuella profildata som finns i kanten
- Stöd för A/B-testning av erbjudandestrategier via innehållsexperiment
Begränsningar
- Kräver implementering av SDK på klientsidan (Web SDK eller Mobile SDK)
- Edge-profilen har en delmängd av fullständiga attribut för hubbprofiler - komplexa regler för behörighet kanske inte utvärderas korrekt
- Edge-segment har begränsningar för segmentregelkomplexitet (inga tidsseriefrågor)
- Kräver frontendutveckling för anpassad återgivning i kodbaserade upplevelser
Experience League-resurser
Hur detta skiljer sig från anpassningsalternativ B för webbbesökare/appar:
Infrastrukturen är identisk - båda använder AJO Decisioning i toppklass med Web SDK och en fullödig kopplingsstrategi. Skillnaden är katalogstyrningsmodellen. Det här alternativet styr en avgränsad erbjudandekatalog med regler för behörighet, spärrräknare och giltighetsdatum - använd den när affärsbegränsningar eller lagstadgade begränsningar avgör vilka erbjudanden som kan visas och hur ofta. Känd besökares anpassning av webb/app Alternativ B väljer bland innehållsobjekt med hjälp av segmentmedlemskap eller rankningsstrategier utan livscykelhantering. Om objektuppsättningen är stor, ändras kontinuerligt och inte kräver begränsning eller behörighetskontroll ska du använda alternativet Känd besökare B i stället.
Alternativ C: Vägbeslutsnod
Det här alternativet är bäst för att välja ett erbjudande inom en resa i flera steg - välj det bästa erbjudandet vid en beslutspunkt i en kundresa och leverera det sedan via nästa åtgärdsnod. Använd detta när erbjudandebeslutet ingår i ett större orkestreringsflöde med väntetider, villkor och flera meddelandeåtgärder.
Så här fungerar det
Beslutspolicyer anropas från en beslutsnod inom en arbetsyta i AJO. När en profil når beslutsnoden utvärderar motorn om erbjudandet är giltigt och rangordnas för att välja det optimala erbjudandet. Det valda erbjudandet informerar nästa meddelandeåtgärd - som erbjuder innehåll som ska inkluderas, vilken kanal som ska användas eller vilken kundgren som ska vidtas baserat på erbjudandets resultat.
Detta tillvägagångssätt möjliggör anpassningsbara resor där offertbeslutet påverkar efterföljande kundsteg. En resa kan till exempel välja det bästa erbjudandet, leverera det via e-post, vänta på engagemang och sedan följa upp med ett push-meddelande om erbjudandet inte öppnats.
Viktiga överväganden
- Resan måste utformas med en beslutsnod följt av en eller flera meddelandeåtgärdsnoder
- Erbjudandets berättigande utvärderas med hjälp av profilens tillstånd när profilen når beslutsnoden
- Väntestegen mellan beslut och leverans kan göra att profilens tillstånd ändras
- Kan kombineras med förgreningar av resan för att ta olika vägar baserat på vilket erbjudande som valts
Fördelar
- Integrerar urval av erbjudanden i flerstegsflöden
- Möjliggör anpassningsbara resor där erbjudandet påverkar efterföljande steg
- Stöd för flerkanalsleverans inom samma resa (e-post, push, SMS)
- Kan kombineras med resevillkor för uppföljning av anställningar efter erbjudande
Begränsningar
- Mer komplex att konfigurera än fristående kampanjbeslut
- Gränser för genomströmning på resa gäller (5 000 profiler per sekund för inträde)
- Beslutet är knutet till resesammanhanget - ändringar kräver att en ny version av resan görs
- Resan måste publiceras på nytt för att uppdateringar av erbjudandekatalogen eller beslutspolicyn ska börja gälla
Experience League-resurser
Jämförelse av alternativ
I följande tabell jämförs de tre implementeringsalternativen över de viktigaste kriterierna.
Välj rätt alternativ
Använd följande vägledning för att välja det bästa implementeringsalternativet för ditt användningsfall.
- Välj alternativ A om det primära användningsexemplet är att välja det bästa erbjudandet per mottagare i utgående e-postkampanjer och ingen SDK på klientsidan är tillgänglig. Detta är den enklaste implementeringsvägen och fungerar bra för e-postreklam, nyhetsbrev och livscykelkampanjer.
- Välj alternativ B om erbjudanden måste väljas i realtid när en besökare läser in en webbsida eller öppnar en mobilapp. För detta krävs Web SDK eller Mobile SDK och en effektiv kopplingsregel, men det snabbaste och mest kontextuella valet av erbjudande.
- Välj alternativ C om erbjudandebeslutet är en del av en större kundresa med flera steg, väntan och villkorlig förgrening. Det här är det rätta valet när det valda erbjudandet ska påverka åtgärder för efterföljande kundresor eller när uppföljning i flera kanaler baserat på anställningserbjudandet behövs.
- Kombinera alternativ när erbjudanden måste levereras på ett enhetligt sätt i alla kanaler. Använd samma policy för alla tre alternativen för att se till att kunden ser samma erbjudande via e-post (alternativ A), på webbplatsen (alternativ B) och inom en uppföljning av resan (alternativ C).
Implementeringsfaser
I följande faser beskrivs den kompletta implementeringssekvensen för anbudsbeslut.
Fas 1: Validera grundläggande krav
Programfunktion: AEP: Datamodellering och förberedelser, AEP: Identitet- och profilkonfiguration
Den här fasen kontrollerar att det grundläggande datalagret stöder offertbeslut. Profilscheman måste innehålla de attribut som används i reglerna för behörighet, och identitetskonfigurationen måste aktivera matchning av flerkanalsprofiler.
Beslut: Profilattribut för behörighet
Bestäm vilka profilattribut som ska användas i reglerna för erbjudande.
Information om nyckelkonfiguration
- Verifiera att profilschemat innehåller fält som det refereras till i regler för behörighet (t.ex.
_tenantId.loyaltyTier,_tenantId.subscriptionType) - Bekräfta att det finns ett schema för uppföljning av interaktion för att upptäcka, klicka och konvertera erbjudanden
- För alternativ B: Verifiera att en edge-active-sammanslagningsprincip är konfigurerad och att tjänsten AJO är aktiverad för Web SDK-datastream
Experience League-dokumentation
Fas 2: Konfigurera målgruppsutvärdering
Programfunktion: RT-CDP: Målgruppsutvärdering
I den här fasen definieras och utvärderas de målgrupper som används som kriterier för att erbjuda rätt till uppgradering. Dessa målgrupper avgör vilka kundsegment som kvalificerar sig för specifika erbjudanden (t.ex."värdefulla kunder" kvalificerar sig för premiumerbjudanden,"testanvändare" kvalificerar sig för konverteringserbjudanden).
Beslut: Metod för utvärdering av målgrupper
Bestäm hur snabbt målgruppsmedlemskapet måste uppdateras för att vara kvalificerat för erbjudanden.
Gränssnittsnavigering: Kund > Målgrupper > Skapa målgrupp > Skapa regel
Information om nyckelkonfiguration
- Definiera målgrupper för rätt att köpa (t.ex."Loyalty Gold Tier","High-Value Customers","Trial Users")
- Definiera undertryckande målgrupper om det behövs (t.ex."Nyligen mottaget erbjudande X")
- För alternativ B: Verifiera att berättigade målgrupper är kvalificerade för edge-utvärdering - undvik tidsseriefrågor och komplexa aggregeringar i segmentregeluttryck
Var alternativen skiljer sig
För alternativ A (E-postbeslut):
Utvärderingen av batchströmning eller strömning räcker. Publiken utvärderas före eller under kampanjkörningen. Komplexa segmentregeluttryck, inklusive tidsbaserade villkor och händelseaggregeringar, stöds fullt ut.
För alternativ B (realtid för webb/app):
Edge måste utvärderas. Publiken måste använda enkla attributkontroller eller villkor för segmentmedlemskap. Testa om kanten är berättigad genom att verifiera att segmentregeluttrycket är kvalificerat för kantsegmentering.
För alternativ C (resebeslutsnod):
Alla bedömningsmetoder fungerar beroende på vilka kriterier för reseanmälan som gäller. Om resan använder målgruppsbaserad anmälan matchar metoden för målgruppsbedömning kundens krav.
Experience League-dokumentation
Fas 3: Ange beslutsinställningar
Programfunktion: AJO: Bestämning
Detta är den centrala fasen där erbjudandekatalogen, reglerna för behörighet, rankningsstrategier och beslutspolicyer byggs. I den här fasen skapas den beslutsmotorkonfiguration som alla leveransalternativ (A, B, C) delar.
Beslut: Placeringskanal och innehållsformat
Bestäm var erbjudandena ska visas och i vilket format.
Beslut: Rankningsstrategi
Bestäm hur det bästa erbjudandet ska väljas bland giltiga erbjudanden.
Beslut: Erbjudandebegränsning
Bestäm om det ska finnas gränser för hur många gånger ett erbjudande visas.
Gränssnittsnavigering: Komponenter > Beslutshantering > Placeringar/Regler/Erbjudanden/Beslut
Information om nyckelkonfiguration
-
Skapa placeringar - Definiera var erbjudandena visas genom att ange kanaltyp och innehållsformat för varje placering.
- Gränssnitt: Komponenter > Beslutshantering > Placeringar
- Skapa en placering per kanal/formatkombination (t.ex. "Email Hero Banner - HTML", "Web Homepage - JSON", "Mobile App Card - JSON")
-
Definiera regler för behörighet - Skapa regler med hjälp av segmentregeluttryck som refererar till profilattribut eller målgruppsmedlemskap.
- Gränssnitt: Komponenter > Beslutshantering > Regler
- Regler kan referera till målgruppsmedlemskap, profilattribut (lojalitetsnivå, prenumerationstyp), datumbegränsningar eller sammanhangsberoende data
-
Skapa personaliserade erbjudanden - Bygg varje erbjudande med innehållsrepresentationer för varje placering, tilldela regler för behörighet, ange prioritet och konfigurera valfri begränsning.
- Gränssnitt: Komponenter > Beslutshantering > Erbjudanden > Skapa erbjudande
- Varje erbjudande måste innehålla en representation per placering (t.ex. HTML för e-post, JSON för webben)
- Tilldela regler för behörighet för att styra vilka profiler som kan se varje erbjudande
- Ange giltighetsdatum för erbjudandet (start/slut) och valfri frekvensbegränsning
- Godkänn varje erbjudande för att få delta i beslut
-
Skapa reserverbjudanden - Skapa ett standarderbjudande för varje placering som visas när inget anpassat erbjudande kvalificerar sig.
- Gränssnitt: Komponenter > Beslutshantering > Erbjudanden > Skapa reserverbjudande
- Reservationen måste ha representationer för varje placering som används i beslutet
-
Skapa samlingskvalificerare och samlingar - Ordna erbjudanden i samlingar med kvalificeringstaggar.
- UI: Komponenter > Beslutshantering > Samlingskvalificerare
- Grupprelaterade erbjudanden (t.ex. "Sommarkampanjer", "Loyalty Rewards") för användning i beslutsomfattningar
-
Skapa beslutsprinciper - Bind placeringar, samlingar, rankningsstrategier och reserverbjudanden till körbara beslut.
- Gränssnitt: Komponenter > Beslutshantering > Beslut > Skapa beslut
- Varje beslutsomfattning länkar en placering till en samling och anger rangordningsmetoden
Experience League-dokumentation
Fas 4: Konfigurera kanal och yta
Programfunktion: AJO: Kanalkonfiguration
Den här fasen konfigurerar kanalytorna som erbjudandena kommer att levereras via. Konfigurationen beror på vilka implementeringsalternativ som används.
Beslut: Kanaltyp
Avgör vilken meddelandekanal som användningsfallet kräver.
Var alternativen skiljer sig
För alternativ A (E-postbeslut):
- Gränssnitt: Administration > Kanaler > Kanalytor > Skapa yta (e-post)
- Konfigurera underdomän, IP-pool, avsändarens namn/e-postadress, svar, inställningar för att avbryta prenumeration
- Verifiera SPF-, DKIM- och DMARC-poster för den sändande underdomänen
För alternativ B (realtid för webb/app):
- Gränssnitt: Administration > Kanaler > Kanalytor > Skapa yta (webb eller app)
- För webben: Konfigurera webbytans URL-mönster
- För kodbaserade upplevelser: Definiera yta-URI för programmet
- Kontrollera att AJO-tjänsten är aktiverad för datastream
För alternativ C (resebeslutsnod):
- Konfigurera kanalytor för varje kanal som används i resan (e-post, push, SMS eller webb)
- Varje åtgärd för att skicka ett meddelande kräver en motsvarande aktiv kanalyta
Experience League-dokumentation
Fas 5: Konfigurera innehåll och leverans
Programfunktion: AJO: Meddelanderedigering, AJO: Kampanjkörning
Den här fasen utformar meddelandemallar eller upplevelseytor som visar det valda erbjudandet och konfigurerar sedan leveransmekanismen (kampanj, resa eller kodbaserad upplevelse).
Beslut: Innehållsstrategi för anbudsåtergivning
Bestäm hur erbjudandeinnehållet ska integreras i meddelandet eller upplevelsen.
Beslut: Kampanjtyp (endast alternativ A)
Bestäm om detta är en schemalagd marknadsföringskampanj eller en API-utlöst kampanj.
Var alternativen skiljer sig
För alternativ A (E-postbeslut):
-
Skriv e-postmeddelandet med e-post-Designer
- Gränssnitt: Kampanjer > Skapa kampanj > Välj e-post > Redigera innehåll
- Infoga en komponent för anbudsbeslut i e-postlayouten för att definiera placeringszonen
- Lägg till personaliseringstoken för innehåll på profilnivå (namn, lojalitetsnivå)
- Konfigurera ämnesrad och preheader med personlig anpassning (tillval)
-
Skapa och konfigurera kampanjen
- Gränssnitt: Kampanjer > Skapa kampanj > Schemalagd eller API-utlöst
- Bind målgruppen och välj kanalyta
- Ange körningsschema eller API-utlösarkonfiguration
- Granska och aktivera kampanjen
För alternativ B (realtid för webb/app):
-
Konfigurera kodbaserad upplevelse eller webbkanal
- Gränssnitt: Kampanjer > Skapa kampanj > Kodbaserad upplevelse (eller webben)
- Länka beslutspolicyn till upplevelsen
- Definiera återgivningsformatet (JSON-svar för kodbaserad, visuell redigerare för webbkanal)
-
Implementera rendering på klientsidan
- Använd Web SDK
sendEvent-svaret för att hämta det valda erbjudandet - Rendera erbjudandeinnehållet på den avsedda placeringen på sidan
- Implementera intryck och klickspårning
- Använd Web SDK
För alternativ C (resebeslutsnod):
-
Designa resan med en beslutsnod
- Användargränssnitt: Resor > Skapa resa > Lägg till beslutsnod
- Konfigurera beslutsnoden för att anropa beslutsprincipen från fas 3
-
Lägg till meddelandeåtgärdsnoder efter beslutet
- Konfigurera e-post-, push- eller SMS-åtgärder som refererar till det valda erbjudandet
- Lägg till väntesteg, villkor eller förgreningar baserat på offertengagemang
-
Publicera resan
Experience League-dokumentation
Fas 6: Testa och validera
Programfunktion: AJO: Beslutsfattare, AJO: Meddelanderedigering
Denna fas kontrollerar att beslutsmotorn returnerar rätt erbjudanden för testprofiler och att erbjudandeinnehållet återges korrekt i varje leveranskanal.
Testa beslutslogik
Använd testprofiler med kända attribut för att verifiera att rätt erbjudanden har valts ut baserat på behörighet och rankning.
- Skapa testprofiler som matchar olika behörighetskriterier (t.ex. Gold-nivå, Silver-nivå, Trial-användare)
- Verifiera att varje testprofil tar emot det förväntade erbjudandet
- Verifiera att profiler som inte matchar några regler för behörighet får reserverbjudandet
Testa innehållsåtergivning
Förhandsgranska innehållet i varje leveranskanal.
- För alternativ A: Använd e-postförhandsgranskning med testprofiler för att verifiera att erbjudandeinnehållet återges korrekt
- Alternativ B: Testa Edge Decisionings-svaret i en testmiljö
- Alternativ C: Använd testläge för resan för att verifiera att beslutsnoden väljs korrekt
Validera visningsspårning
Bekräfta att visningar, klickningar och konverteringar spåras.
- Verifiera att interaktionshändelser för erbjudanden visas i spårningsdatauppsättningarna
- Bekräfta attribuering mellan offertvisningar och konverteringar i efterföljande led
Experience League-dokumentation
Fas 7: Konfigurera rapportering och prestandaövervakning
Programfunktion: AJO: Rapporterings- och prestandaanalys
I den här fasen skapas rapporter för att spåra fördelningen av erbjudanden, acceptansgrader, konverteringseffekt och reservfrekvenser. Denna fas omfattar både AJO-rapporter och CJA-baserad flerkanalsanalys.
Beslut: Rapporteringsmetod
Fastställ vilka rapporteringsverktyg som behövs för att analysera resultatet.
Information om nyckelkonfiguration
-
Inbyggd AJO-rapportering - Övervaka kampanjer eller resan med hjälp av inbyggda rapporter.
- Gränssnitt: Campaigns > Select campaign > All time report (eller Live report)
- Granska de erbjudandespecifika mätvärdena: antal visningar per erbjudande, klickfrekvens per erbjudande, reservfrekvens
- Monitor delivery funnel: Targeted > Skickat > Delired > Open > Click
-
CJA-analys (rekommenderas) - Skapa instrumentpaneler för kanalövergripande erbjudanden.
- Konfigurera en CJA-anslutning med AJO-datauppsättningar för interaktion
- Skapa en datavy med erbjudandespecifika dimensioner (erbjudandenamn, placering, beslut) och mätvärden (visningar, klick, konverteringar)
- Bygg en analys av arbetsytan för: distribution av erbjudanden, acceptansgrad per segment, intäktspåverkan, enhetlighet i flerkanalserbjudanden
Experience League-dokumentation
Implementeringsöverväganden
Det här avsnittet handlar om säkerhetsutkast, vanliga fallgropar, bästa praxis och avräkningsbeslut för implementering av offertbeslut.
Gardrutor och begränsningar
Tänk på följande plattformsskydd och -begränsningar när du planerar implementeringen.
- Högst 10 000 godkända anpassade erbjudanden per sandlåda - Beslutshanteringssystem
- Högst 30 praktik per beslut
- Maximalt 30 samlingsomfång per beslutsbegäran
- AI-rankningsmodeller kräver minst 1 000 konverteringshändelser för utbildning
- Räknare för buffertbegränsning kan ha en fördröjning på upp till några sekunder i högflödesscenarier
- Edge beslut är begränsade till profilattribut som är tillgängliga i edge-profilarkivet
- Maximalt 4 000 segmentdefinitioner per sandlåda - Plattformsskydd
- Endast en sammanfogningsprincip kan vara aktiv i Edge per sandlåda
- Max 500 aktiva livekampanjer per sandlåda
- Gräns för antal resenärer: 5 000 profiler per sekund
- Högst 10 kanalytor per kanaltyp per sandlåda
Vanliga fallgropar
Undvik problem som ofta uppstår under implementeringen.
- Beslut returnerar alltid reserverbjudande: Detta innebär vanligtvis att personaliserade erbjudanden inte godkänns, ligger utanför giltighetsdatumintervallet eller att reglerna för behörighet inte matchar testprofilens attribut. Verifiera varje villkor: godkännandestatus, datumintervall och exakthet för segmentregeluttryck. Kontrollera också att begränsningen inte har nåtts.
- Erbjudandet visas inte i samlingen: Kontrollera att erbjudandet har taggats med rätt samlingskvalificerare och att samlingsfiltret matchar. Erbjudandena måste vara både taggade och godkända för att kunna förekomma i de samlingsbaserade beslutsomfången.
- Rankningsformeln används inte: Kontrollera att formeln är syntaktiskt giltig och refererar till tillgängliga profilattribut. Formelfel återgår i tysthet till prioritetsbaserad rankning utan synligt fel.
- Edge-leverans returnerar tom personalisering: Kontrollera att datastream har konfigurerats med tjänsten Adobe Journey Optimizer aktiverad och att beslutsomfånget är korrekt formaterat. Kontrollera att den edge-active-sammanslagningsprincipen finns.
- Inkonsekventa erbjudanden över olika kanaler: Om olika beslutsprinciper används per kanal kan samma profil ta emot olika erbjudanden. Använd en enda beslutspolicy i alla kanaler för enhetlighet, eller acceptera avsiktliga skillnader baserat på kanalspecifika placeringar.
- Erbjud innehåll som inte återges i e-post: Kontrollera att erbjudandet har en innehållsrepresentation som matchar e-postplaceringsformatet (HTML eller bild-URL). Saknade representationer resulterar i tomma placeringszoner.
God praxis
Följ de här rekommendationerna för en lyckad implementering av offertbeslut.
- Börja med en liten erbjudandekatalog och iterera - Börja med 5-10 erbjudanden och utöka allt eftersom beslutsramverket valideras. Detta förenklar felsökning och säkerställer att reglerna för behörighet fungerar korrekt före skalning.
- Använd samlingskvalificerare strategiskt - Tagga erbjudanden per kategori (t.ex. "Anskaffning", "Kvarhållning", "merförsäljning") för att möjliggöra flexibla samlingsbaserade beslutsomfattningar som kan återanvändas mellan kampanjer och resor.
- Skapa alltid meningsfulla reserverbjudanden - Reserverbjudanden är inte bara ett säkerhetsnät. De är standardupplevelsen för profiler som inte matchar någon behörighetsregel. Investera i reservinnehåll som ger värde även utan personalisering.
- Behörighetsreglerna för design utesluter varandra där det är möjligt - När flera erbjudanden överlappar varandra blir rankningsstrategin avgörande. Om det i affärskraven fastställs ett specifikt erbjudande för ett visst segment, kan du göra reglerna för behörighet ömsesidigt uteslutande i stället för att enbart förlita dig på rangordningen.
- Testa med kantrepresentativa profiler för alternativ B - Edge-profiler innehåller en delmängd av hubbprofilattribut. Testa med profiler som har edge-available-attribut för att säkerställa att kvalificeringen utvärderas korrekt i produktionen.
- Övervaka reservfrekvenser som ett hälsomått - en hög reservfrekvens (över 20-30 %) anger att erbjudandekatalogen inte täcker tillräckligt många kundsegment. Utöka erbjudandekatalogen eller bredda reglerna för behörighet.
- Versionsbeslutsprinciper i stället för att redigera live-principer - Skapa en ny version av beslutspolicyn i stället för att ändra en aktiv. Detta förhindrar avbrott i livekampanjer och möjliggör A/B-jämförelse av beslutsstrategier.
Avvecklingsbeslut
Tänk på följande när du ska fatta beslut om arkitektur och konfiguration.
Kvalificeringsprecision jämfört med täckning
Nära regler för behörighet säkerställer att varje erbjudande endast når de mest relevanta profilerna, men kan resultera i höga reservpriser när profilerna inte matchar något erbjudande. Många regler för berättigande maximerar täckningen för erbjudandet men minskar precisionen för personalisering.
- Nära berättigandeförmåner: Högre acceptansgrad, bättre personalisering, lägre utmattning
- Höga berättigandeförmåner: Lägre reservfrekvenser, fler profiler tar emot personaliserade erbjudanden, enklare regelhantering
- Rekommendation: Börja med bredare regler för behörighet och tätare dem baserat på prestandadata. Övervaka reservfrekvenser och acceptansfrekvenser för att hitta rätt balans. Använd rankningsstrategier för att skilja mellan allmänt berättigade erbjudanden.
Prioritetsbaserad eller AI-rankad rankning
Prioritetsbaserad rankning ger företaget full kontroll över vilka erbjudanden som visas, medan AI-rankad optimerar konverteringen men minskar den mänskliga kontrollen över valet av erbjudanden.
- Prioritetsbaserade fördelar: Affärskontroll, förutsägbarhet, inga krav på utbildningsdata, omedelbar driftsättning
- AI-rankade tjänster: Konverteringsoptimering, upptäckt av oväntade mönster, automatisk anpassning till förändrade kundbeteenden
- Rekommendation: Använd prioritetsbaserad rankning för inledande lanseringar och myndighetskänsliga erbjudanden där affärskontroll är av största vikt. Övergång till AI-rankad för högvolymsoptimerade användningsfall när det finns tillräckligt med konverteringsdata (1 000+ händelser).
Policyer för ett enda beslut jämfört med riktlinjer för beslut per kanal
En enda beslutspolicy säkerställer enhetlighet i alla kanaler, men begränsar optimeringen per kanal. Policyer per kanal möjliggör kanalspecifik rankning och kvalificering, men riskerar inkonsekventa kundupplevelser.
- Enkel princip prioriterar: Konsekvens över flera kanaler, enklare hantering, enhetlig rapportering
- Policyer per kanal ger följande fördelar: Kanaloptimerad rankning, kanalspecifik behörighet (t.ex. webbaserade erbjudanden), oberoende iteration
- Rekommendation: Börja med en enda beslutsprincip för enhetlighet mellan kanaler. Skapa profiler per kanal endast när affärsbehoven kräver kanalspecifika strategier (t.ex. webbexklusiv Flash-försäljning).
Hubbbeslut (alternativ A/C) jämfört med kantbeslut (alternativ B)
Hubbbeslut har åtkomst till den fullständiga profilen men fungerar vid sändning. Edge-beslut körs i realtid med delsekundsfördröjning, men är begränsat till profilattribut som är tillgängliga på kanten.
- Navet för beslut: Åtkomst till fullständiga profildata, komplexa regler för behörighet, gruppkampanjvolymer
- Edge-beslutsstöd prioriterar: Realtidskontext, sessionsanpassning, subsekundssvar
- Rekommendation: Använd navbeslut för utgående kanaler (e-post, push) där fullständiga profildata förbättrar erbjudanderelevansen. Använd edge-decimering för inkommande kanaler (webb, app) där realtidsrespons är avgörande. Se till att reglerna för behörighet endast används för Edge-attribut.
Relaterad dokumentation
Följande resurser innehåller ytterligare information om komponenterna som används i det här användningsmönstret.