Beteenderekommendation
Den här guiden beskriver hur du implementerar beteenderekommendationer för produkter och innehåll med hjälp av Adobe Journey Optimizer (AJO) Decisioning, Real-Time Customer Data Platform (RT-CDP) och Adobe Experience Platform (AEP). Det är utformat för lösningsarkitekter, marknadsföringsteknologer och implementeringstekniker som behöver kunna leverera personaliserade rekommendationsupplevelser via webben, mobilappar och e-postkanaler.
Den innehåller alla genomförbara implementeringsalternativ, beslutsöverväganden vid varje fas och länkar till Adobe Experience League-dokumentation. Beteenderekommendation genererar rekommendationer på objektnivå eller på innehållsnivå med hjälp av beteendesignaler - produktvyer, inköp, innehållsinteraktioner, sökfrågor - i kombination med urvalsstrategier och rangordningsmodeller för AJO Decisioning. Till skillnad från beslut om erbjudanden - som styr en avgränsad uppsättning erbjudanden, kampanjer eller incitament med hjälp av regler för behörighet och affärsbegränsningar - fungerar det här mönstret på stora, ständigt föränderliga artikelkataloger (produkter, artiklar, videor) där urvalet styrs av beteendesignaler snarare än styrd behörighet.
Använd ärendeöversikt
Organisationer med produktkataloger, innehållsbibliotek eller mediebibliotek måste visa de mest relevanta objekten för varje besökare utifrån deras beteendehistorik och sessionsaktivitet. Oavsett om det är en karusell som"rekommenderas för dig" på en hemsida, en korsförsäljningswidget på en produktinformationssida eller produktrekommendationer som är inbäddade i en e-postkampanj är den underliggande utmaningen densamma: matcha varje besökares beteendeprofil mot de mest relevanta objekten från en katalog och leverera sedan dessa rekommendationer i rätt kanal vid rätt tillfälle.
Det här mönstret åtgärdar den utmaningen genom att inhämta beteendesignaler i realtid via Web SDK eller Mobile SDK, bearbeta dem via AJO Decisioning-markeringsstrategier som kombinerar objektattribut med beteendekontext och levererar de rekommenderade objekten via webben, i appen eller via e-postkanaler. Rankningsmodeller kan vara formelbaserade (t.ex. sortera efter kategoritillhörighetspoäng) eller AI-rankade (t.ex. personaliserad rekommendationsmodell). Mönstret hanterar också kallstartsscenarier för nya besökare utan beteendehistorik genom att konfigurera reservrekommendationer.
Målgruppen för det här mönstret är bland annat e-handelsteamen, team för innehållspersonalisering och team för digitala upplevelser som vill förbättra engagemanget, konverteringen och det genomsnittliga ordervärdet genom personaliserade rekommendationer som bygger på verkliga användarbeteenden.
Viktiga verksamhetsmål
Följande affärsmål stöds av det här användningsmönstret.
Ö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 konverteringsgraden
Förbättra andelen besökare och presumtiva som utför önskade åtgärder, t.ex. inköp, registreringar eller inskickade formulär.
KPI Konverteringshastigheter, Leadkonvertering, kostnad per lead
Leverera personaliserade kundupplevelser
Skräddarsy innehåll, erbjudanden och budskap efter enskilda preferenser, beteenden och livscykelsteg.
KPI engagemang, konverteringsgrader, kundnöjdhet (CSAT)
Exempel på taktiska användningsfall
Nedan följer några vanliga taktiska implementeringar av det här mönstret:
- Produktens korsförsäljningswidget på produktinformationssidan ("kunder som också köpt")
- "Recommended for you"-karusell på hemsidan baserat på webbläsarhistorik
- Innehållsrekommendationer för mediewebbplats baserat på läsbeteende
- "Nyligen visade" i kombination med liknande objektwidget
- Kompletterande produktrekommendationer efter köp
- E-postproduktrekommendationer baserade på beteendetillhörighet
- Kategorispecifika rekommendationer baserade på webbläsarbeteende under session
- Sökresultat omrangordnas baserat på beteendesignaler
Nyckeltal för prestanda
Följande nyckeltal hjälper till att mäta effekten av implementeringar av beteenderekommendationer.
Använd skiftlägesmönster
Beteenderekommendation
Generera rekommendationer på objektnivå eller innehållsnivå baserade på beteendesignaler, med AJO Decisioning-markeringsstrategier och rankningsmodeller för att leverera kontextuellt innehåll.
Funktionskedja: Behavioral signalintag > Decisioning Strategy Evaluation > recommendation Delivery > Reporting
I avsnittet Mönsterkomposition under Implementeringsfrågor finns vägledning om hur du kombinerar mönster.
Tillämpningar
Följande program används i det här fallmönstret.
- Adobe Journey Optimizer (AJO) Beslut - Urvalsstrategier, rangordningsmodeller, objektkataloger och beslutsprofiler som utvärderar beteendesignaler och returnerar de mest relevanta objekten för varje besökare
- Adobe Real-Time Customer Data Platform (RT-CDP) - ackumulering av beteendeprofildata, målgruppsutvärdering för rekommendationsomfattning och beräknade attribut för beteendeaffinitetsklassificering
- Adobe Experience Platform (AEP) - Inmatning av beteendehändelser via Web SDK och Mobile SDK, Edge Network bearbetning, XDM-schemahantering för händelse- och katalogdata
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)
Real-Time CDP (RT-CDP)
Förutsättningar
Slutför följande innan du börjar implementera:
- [ ] AJO Decisioning har etablerats och aktiverats i målsandlådan
- [ ] Web SDK eller Mobile SDK distribueras och samlar in beteendehändelser med produkt-/innehållsidentifierare
- [ ] Produkt- eller innehållskatalogdata är tillgängliga för konsumtion (produktnamn, kategori, pris, bild-URL, tillgänglighet)
- [ ] Beteendehändelsescheman innehåller objekt-/produktidentifierare som länkar till katalogobjekt
- [ ] Datastream har konfigurerats med tjänsten Adobe Journey Optimizer aktiverad (krävs för Edge-beslut)
- [ ]-sammanslagningsprincipen med
isActiveOnEdge: truehar konfigurerats (krävs för webb-/apprekommendationer i realtid) - [ ] För e-postrekommendationer (alternativ C): e-postkanalens yta har konfigurerats och validerats
- [ ] För e-postrekommendationer (alternativ C): målgruppen definieras och utvärderas
Implementeringsalternativ
Följande alternativ beskriver olika strategier för att implementera beteenderekommendationer. Välj det alternativ som bäst passar dina kanalbehov och tekniska begränsningar.
Alternativ A: Realtidsrekommendationer för webben
Passar bäst för: Rekommendationer för produkter eller innehåll på webbsidor - korsförsäljningswidgetar för produktinformation, rekommenderad hemsida, personaliserade listor för kategorisidor och personalisering av sökresultat.
Så här fungerar det:
Beteendesignaler samlas in i realtid via Web SDK när besökare surfar på webbplatsen. Varje sidvy, produktinteraktion eller sökfråga direktuppspelas till AEP och kopplas till besökarens profil (via ECID för anonyma besökare eller autentiserad identitet för kända besökare). När en sida som innehåller en rekommendationsyta läses in, begär Web SDK en beslutsutvärdering från AJO via Edge Network. Beslutsmotorn utvärderar besökarens beteendeprofil mot urvalsstrategin, tillämpar rangordningslogik, filtrerar bort icke-berättigade objekt (som redan har köpts, ej i lager) och returnerar de rekommenderade objekten.
Rekommendationer återges på sidan med kodbaserade upplevelser eller webbkanalsytor. Återgivningen kan vara en karusell, ett rutnät, widget för ett objekt eller en anpassad layout som definieras i rekommendationsmallen. Impression- och klickningshändelser spåras automatiskt tillbaka till AEP för prestandarapportering.
Viktiga överväganden:
- Edge-beslut kräver att kopplingsregeln är aktiv i Edge
- Rekommendationsfördröjning beror på svarstiden Edge Network (under 500 ms SLA för begäranden med en omfattning)
- Anonyma besökare får rekommendationer baserade på sessionsbeteenden; kända besökare drar nytta av beteendemönster mellan sessioner
- Rivstarta besökare utan beteendehistorik som får tillbaka sina rekommendationer
Fördelar:
- Realtidspersonalisering baserad på sessionsbeteende
- Leverans av undersekundära rekommendationer via Edge Network
- Fungerar för både anonyma och kända besökare
- Automatiskt intryck och klickning
- Ingen sidomladdning krävs för nya rekommendationer
Begränsningar:
- Edge profilarkiv innehåller en delmängd av fullständiga profilattribut
- Komplexa rangordningsmodeller med många profilattribut kan kräva utvärdering på navsidan
- Kräver Web SDK-distribution med beteendehändelsespårning
Experience League:
Alternativ B: Rekommendationer för mobilappar
Passar bäst för: Produktrekommendationer i appen, personliga innehållsflöden, aviseringsdrivna rekommendationer och mobilhandelsupplevelser.
Så här fungerar det:
Beteendesignaler samlas in via Mobile SDK när användarna interagerar med appen. Produktvyer, innehållsinteraktioner, sökningar och inköp strömmas till AEP. När en skärm som innehåller en rekommendationsyta läses in, begär Mobile SDK en beslutsutvärdering. Rekommendationer levereras via meddelanden i appen, innehållskort eller kodbaserade upplevelser i mobilappen.
Innehållskort är särskilt väl lämpade att användas som rekommendationer i mobilappar eftersom de finns kvar i en upplevelse som ser ut ungefär som när användaren vill. Meddelanden i appen kan användas för sammanhangsbaserade rekommendationer som utlöses av specifika beteenden (t.ex. för att visa kompletterande produkter efter att en artikel har lagts till i kundvagnen).
Viktiga överväganden:
- Mobile SDK måste konfigureras med beteendehändelsespårning för relevanta interaktioner
- Innehållskort ger en beständig rekommendationsyta, meddelanden i appen är tillfälliga
- Spårning av offlinebeteende kräver SDK-köhantering för överföring av fördröjda händelser
- Uppdateringscyklerna i App Store påverkar hur snabbt ändringar av rekommendationsrendering kan distribueras
Fördelar:
- Inbyggd mobilupplevelse med smidig, appintegrerad rekommendationsrendering
- Innehållskort är en beständig, läsbar rekommendationsfeed
- Meddelanden i appen aktiverar sammanhangsberoende, beteendestyrda rekommendationer
- Utnyttjar signaler på enhetsnivå (plats, appanvändningsmönster) för ökad relevans
Begränsningar:
- Kräver integrerings- och apputvecklingsresurser för Mobile SDK
- Återgivningsändringar kräver appuppdateringar (såvida inte kodbaserade upplevelser med serverdrivna layouter används)
- Offlineperioder skapar luckor i beteendesignalinsamling
Experience League:
Alternativ C: Rekommendationer för e-postbeteende
Passar bäst för: Produktrekommendationer i e-postkampanjer - övergivna bläddringsmeddelanden med visade produktrekommendationer, korsförsäljningsmeddelanden efter köp, periodiska"val för dig"-sammanfattningar och e-postmeddelanden med anpassade produktförslag.
Så här fungerar det:
Behaviorala profildata som samlats in från tidigare sessioner informerar rekommendationsvalet vid e-postsändningstid eller återgivningstid. En målgrupp definieras för att rikta sig till rätt mottagare (t.ex. besökare som surfar men inte köpte, kunder som nyligen köpt något). En kampanj eller resa är konfigurerad att skicka ett e-postmeddelande som innehåller rekommendationer. Vid sändning utvärderar AJO Decisioning varje mottagares beteendeprofil mot urvalsstrategin och injicerar de rekommenderade objekten i e-postinnehållet.
Det här alternativet bygger på ackumulerad beteendehistorik i stället för sessionssignaler. Beräknade attribut (kategoritillhörighetsgrad, senaste produktvisningar, inköpsfrekvens) förbättrar rekommendationskvaliteten avsevärt för e-post eftersom de bearbetar beteendehistorik till profilnivåsignaler som urvalsstrategin kan utvärdera effektivt.
Viktiga överväganden:
- E-postrekommendationer utvärderas vid sändning, inte vid öppning - beteendeprofilläget vid tidpunkten för sändning avgör rekommendationerna
- Beräknade attribut rekommenderas starkt för att förbättra rangordningskvaliteten
- Begränsningar för e-poståtergivning (ingen JavaScript, begränsad CSS) begränsar visningsformat för rekommendationer
- Kräver en konfigurerad och validerad e-postkanal
Fördelar:
- Utnyttjar fullständig beteendehistorik för sessioner för djupare personalisering
- Integreras med befintliga arbetsflöden för kampanjer och resor
- Gäller för återanvändning och återvinningsscenarier där webb-/appkontaktytor inte är tillgängliga
- Kan innehålla flera rekommendationsplaceringar i ett enda e-postmeddelande
Begränsningar:
- Rekommendationer är statiska vid sändning - de uppdateras inte när e-postmeddelandet öppnas
- Begränsningar för e-poståtergivning begränsar visningsformat för rekommendationer
- Kräver utvärdering av målgruppen och infrastruktur för samordning av kampanjer och resor
- Komplexa implementeringar på grund av ytterligare beroenden (kanalkonfiguration, målgruppsdefinition, kampanjkörning)
Experience League:
Jämförelse av alternativ
I följande tabell sammanfattas de viktigaste skillnaderna mellan implementeringsalternativen.
Välj rätt alternativ
Använd följande vägledning för att välja det bästa alternativet för din situation:
- Börja med alternativ A om ditt primära mål är produktrekommendationer i realtid på din webbplats. Detta är den vanligaste utgångspunkten och ger omedelbart värde med den lägsta komplexiteten i implementeringen.
- Välj alternativ B om din mobilapp är en primär engagemangskanal och rekommendationer i appen skulle leda till meningsfull konverteringshöjning. Alternativ B kan köras parallellt med alternativ A med samma urvalsstrategier och artikelkataloger.
- Lägg till alternativ C när du vill utöka beteenderekommendationer till e-postkampanjer. Detta ligger vanligen i lager ovanpå alternativ A eller B, med samma objektkataloger och urvalsstrategier, men med e-postspecifika återgivningsmallar och målgruppsbaserad målinriktning.
- Kombinera alternativ A + C för ett gemensamt mönster: webrekommendationer i realtid för aktiva besökare, plus övergivna e-postrekommendationer för bläddring eller efter köp för besökare som inte konverterar.
Implementeringsfaser
I följande faser får du hjälp med att implementera beteenderekommendationer från början till slut.
Fas 1: Konfigurera beteendehändelseschema och datainsamling
Programfunktion: AEP: Datamodellering och förberedelse (F2), AEP: Datakällor och samling (F3)
I den här fasen fastställs XDM-scheman, datamängder och datainsamlingsmekanismer som samlar in beteendesignaler och artikelkatalogdata. Den här datamängden är vad all rekommendationslogik bygger på.
Beslut: Design av beteendestyrt händelseschema
Vilka beteendesignaler ska leda till rekommendationer?
Beslut: Inmatningsmetod för artikelkatalog
Hur kommer produkten eller innehållskatalogen att importeras till AEP?
Gränssnittsnavigering: Datahantering > Scheman > Skapa schema; Datasamling > Datastreams > Ny datastream
Information om nyckelkonfiguration:
- Experience Event-schemat måste innehålla produkt-/artikelidentifierare (SKU, produkt-ID, innehålls-ID) i händelsens nyttolast
- Artikelkatalogschemat ska innehålla attribut för filtrering och rankning: kategori, pris, bild-URL, tillgänglighetsstatus, taggar
- Tjänsten Adobe Journey Optimizer måste vara aktiverad för Edge-beslut
- Web SDK
sendEventanrop måste innehålla produktinteraktionsdata mappade till XDM-e-handelsfält
Experience League-dokumentation:
Fas 2: Konfigurera identitet och profil
Programfunktion: AEP: Identity & Profile Configuration (F4)
I den här fasen anges identitetsnamnutrymmen, primära identitetsbeteckningar och sammanfogningsprinciper som säkerställer att beteendesignaler kopplas korrekt till besökarprofiler och är tillgängliga för rekommendationsleverans i realtid.
Beslut: Sammanslagningspolicy för Edge-beslut
Kräver rekommendationens exempel Edge utvärdering i realtid?
Beslut: Anonym kontra känd besöksidentitet
Hur ska beteendesignaler från anonyma besökare hanteras?
Gränssnittsnavigering: Identiteter > Identitetsnamnutrymmen; Profiler > Sammanfoga profiler
Information om nyckelkonfiguration:
- ECID-namnområdet är förkonfigurerat och används automatiskt av Web SDK och Mobile SDK
- Anpassade identitetsnamnutrymmen (CRM-ID, lojalitets-ID) måste skapas för autentiserad identitet
- Primär identitet i Experience Event-schemat ska vara ECID för webb-/mobilbeteendehändelser
- Sammanslagningsprincipen måste använda privat enhetsdiagram för identitetssammanfogning mellan enheter
Experience League-dokumentation:
Fas 3: Ställ in artikelkatalog och urvalsstrategi
Programfunktion: AJO: Bestämning
I den här fasen konfigureras objektkatalogen (beslutsobjekt), urvalsstrategier som kombinerar beteendesignaler med objektattribut för rankning, filtreringsregler för att exkludera icke-berättigade objekt och reservrekommendationer för kallstartsprofiler.
Beslut: Artikelkatalogområde
Vilka artiklar finns tillgängliga för rekommendation?
Beslut: rangordningsmetod
Hur ska kvalificerade artiklar rangordnas för att fastställa de bästa rekommendationerna?
Beslut: Filtreringsregler
Vilka objekt ska uteslutas från rekommendationerna?
Beslut: Strategi för kallstart
Vad ska visas för nya besökare utan beteendebakgrund?
Gränssnittsnavigering: Journey Optimizer > Komponenter > Beslutshantering > Beslut; Journey Optimizer > Komponenter > Beslutshantering > Erbjudanden; Journey Optimizer > Komponenter > Beslutshantering > Placeringar
Information om nyckelkonfiguration:
- Skapa beslutsobjekt som representerar varje produkt eller innehållsobjekt i katalogen, med attribut (kategori, pris, bild-URL, taggar)
- Definiera urvalsstrategier som kombinerar objektkatalogfiltrering med beteendelogik
- Konfigurera rangordningsmodeller - formelbaserade uttryck kan referera till profilattribut (t.ex. kategoritillhörighetspoäng från beräknade attribut)
- Skapa reserverbjudanden/artiklar som fungerar som standardrekommendationer för kallstartsprofiler
- Ordna objekten i samlingar med hjälp av samlingskvalificerare (taggar) för logisk gruppering
- Ställ in filtreringsregler i urvalsstrategier för att tillämpa affärsregler (exkludera inköpt, endast inköpt)
Experience League-dokumentation:
Fas 4: Konfigurera kanal och yta
Programfunktion: AJO: Kanalkonfiguration
Den här fasen konfigurerar de leveransytor där rekommendationer ska återges. Konfigurationen varierar avsevärt beroende på implementeringsalternativ.
Beslut: Typ av leveransyta
Var kommer rekommendationer att visas?
Var alternativen skiljer sig:
För alternativ A (Web Real-Time Recommendations):
Konfigurera en kodbaserad upplevelseyta eller webbkanalsyta. Kodbaserade upplevelser ger den flexibilitet som krävs för anpassad rekommendationsåtergivning (karuseller, rutnät, artikelkort). Yt-URI:n identifierar var på sidan rekommendationerna visas.
För alternativ B (mobilappsrekommendationer):
Konfigurera ytor för meddelanden eller innehållskort i appen. Innehållskort rekommenderas för beständiga rekommendationsflöden. Meddelanden i appen fungerar bra för sammanhangsbaserade, beteendestyrda rekommendationer.
För alternativ C (E-postbeteenderekommendationer):
Konfigurera en e-postkanal med underdomänsdelegering, IP-pooltilldelning och avsändarinställningar. Kontrollera att ytan är godkänd för leverans.
Gränssnittsnavigering: Administration > Kanaler > Kanalytor > Skapa yta
Experience League-dokumentation:
Fas 5: Konfigurera innehåll och leverans
Programfunktion: AJO: Meddelanderedigering
Den här fasen definierar rekommendationsåtergivningsmallarna som styr hur rekommenderade objekt visas för besökaren. Detta inkluderar layoutdesign av objekt, anpassningsuttryck som drar in objektattribut (namn, bild, pris, länk) och den övergripande utformningen av rekommendationsupplevelsen.
Beslut: Rekommendationens visningsformat
Hur ska rekommenderade objekt återges?
Beslut: Antal rekommendationer som ska visas
Hur många artiklar ska beslutet returnera per placering?
Var alternativen skiljer sig:
För alternativ A (Web Real-Time Recommendations):
Designa rekommendationsrenderingen med kodbaserade upplevelsemallar. Använd HTML/CSS/JavaScript för att skapa karusellen, rutnätet eller widgetlayouten. Personalization-uttryck refererar till beslutssvarsattributen (objektnamn, bild-URL, pris, produkt-URL). Impression och klickspårning hanteras automatiskt av Web SDK.
För alternativ B (mobilappsrekommendationer):
Konfigurera innehållskortsmallar eller meddelandemallar i appen med artikelvisningslogik. Använd JSON-baserade innehållsstrukturer som mobilappen återger internt. Inkludera djuplänkar för varje rekommenderat objekt.
För alternativ C (E-postbeteenderekommendationer):
Designa e-postinnehåll med e-post-Designer. Infoga rekommendationsplaceringar med beslutsstyrda innehållsblock. Konfigurera anpassningsuttryck för objektattribut i e-postmallen. Personalisering av ämnesrader kan referera till de vanligaste rekommenderade objekten.
Gränssnittsnavigering: Innehållshantering > Innehållsmallar; Campaign/Journey > Redigera innehåll > E-posta Designer
Information om nyckelkonfiguration:
- Varje rekommendationsplacering måste hänvisa till det beslut som skapats i fas 3
- Personalization-uttryck använder Handlebars-syntax för att återge objektattribut
- För webben: konfigurera den kodbaserade upplevelsen så att den anropar beslutet och återger svaret
- För e-post: bädda in beslutet i e-poståtgärden i kampanjen eller resan
- Förhandsgranska rekommendationer med testprofiler med känd beteendehistorik
Experience League-dokumentation:
Fas 6: Ställa in målgruppsomfattning och kampanj/resa (endast alternativ C)
Programfunktion: RT-CDP: Målgruppsutvärdering, AJO: Kampanjkörning eller Journey Orchestration
För e-postbaserade rekommendationer (alternativ C) definierar den här fasen målgruppen och konfigurerar den kampanj eller resa som levererar rekommendationsmeddelandet. Alternativen A och B hoppar över den här fasen eftersom rekommendationer levereras i realtid vid sidinläsning/skärminläsning.
Beslut: Metod för utvärdering av målgrupper
Hur ska målgruppen för rekommendationsmeddelanden utvärderas?
Beslut: Leveransmekanism
Ska e-postmeddelandet levereras via en kampanj eller en resa?
Gränssnittsnavigering: Kund > Publiker > Skapa målgrupp > Skapa regel; Kampanjer > Skapa kampanj; Resor > Skapa resa
Information om nyckelkonfiguration:
- Definiera målgruppen med segmentregeluttryck som refererar till beteendehistorik (t.ex."visade produkter under de senaste 7 dagarna men inte köpt")
- Konfigurera kampanjen eller resan med e-poståtgärden som refererar till kanalytan från fas 4
- Bädda in beslutet från fas 3 i e-postinnehållet
- Ange schemaläggnings- och frekvensregler för att undvika övermeddelanden
Experience League-dokumentation:
Fas 7: Konfigurera rapportering och optimering
Programfunktion: AJO: Rapportering och prestandaanalys, CS5: Rapportering och analys
I den här fasen fastställs prestandaövervakning för rekommendationer klickfrekvens, konvertering och intäktsmått. Den skapar en rapportinfrastruktur för att mäta rekommendationseffektivitet och identifiera optimeringsmöjligheter.
Beslut: Rapporteringsdjup
Vilken nivå av rapportanalys krävs?
Gränssnittsnavigering: Kampanjer > Välj kampanj > Alla tidsrapporter; Resurser > Välj resa > Alla tidsrapporter; Customer Journey Analytics > Projekt > Skapa nytt projekt
Information om nyckelkonfiguration:
- Granska AJO kampanjrapporter och reserapporter för leverans- och engagemangsmått
- För integrering med Customer Journey Analytics skapar du en anslutning med händelsedatamängder för AJO-upplevelser (meddelandefeedback, e-postspårning, beslutsfattande)
- Skapa en Customer Journey Analytics-datavy med rekommendationsspecifika dimensioner (artikelnamn, artikelkategori, rekommendationsyta) och mått (visningar, klick, konverteringar, intäkter)
- Skapa beräknade värden för rekommendation CTR, konverteringsgrad och intäkt per intryck
- Skapa Customer Journey Analytics arbetsytepaneler som jämför rekommendationsprestanda för ytor, segment och tidsperioder
Experience League-dokumentation:
Implementeringsöverväganden
Granska följande utkast, fallgropar, bästa praxis och kompromisser före och under implementeringen.
Gardrutor och begränsningar
- Högst 10 000 godkända anpassade erbjudanden (beslutsobjekt) per sandlåda - Beslutsfattare
- Högst 30 praktik per beslut
- Maximalt 30 samlingsomfång per beslutsbegäran
- Erbjud leveranssvarstid SLA: mindre än 500 ms vid P95 för Edge-förfrågningar med en enda omfattning
- 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
- Endast en sammanslagningsprincip kan vara aktiv på Edge per sandlåda: Profilskyddsutkast
- Högst 25 aktiva beräknade attribut per sandlåda - Beräknade attributskyddsräcken
- Maximalt 4 000 segmentdefinitioner per sandlåda - Segmenteringsskyddsräcken
- Direktuppspelningsinmatning: högst 20 000 poster per sekund per HTTP-anslutning — Inmatningsskydd
Vanliga fallgropar
- Beslutet returnerar endast reservobjekt: Kontrollera att anpassade beslutsobjekt har godkänts, inom giltighetsdatumintervallet och att berättigandereglerna matchar besökarens profilattribut. Kontrollera att begränsningen inte har nåtts.
- Edge-leverans returnerar tom personalisering: Kontrollera att datastream har konfigurerats med tjänsten Adobe Journey Optimizer aktiverad och att beslutsomfånget är korrekt formaterat i Web SDK-begäran.
- Rankningsformeln används inte: Kontrollera att formeln är syntaktiskt giltig och refererar till tillgängliga profilattribut. Formelfel återgår i tysthet till prioritetsbaserad rankning.
- Gamla rekommendationer: Om beteendehändelsedata inte flödar i realtid kommer rekommendationerna att baseras på föråldrade beteendeprofiler. Verifiera att Web SDK eller Mobile SDK aktivt direktuppspelar händelser.
- Återgångsfrekvensen för kallstart är för hög: Om en stor andel av besökarna får återgångsrekommendationer bör du överväga att initiera kallstartsstrategin med sammanhangsberoende signaler (aktuell sidkategori, hänvisningskälla) i stället för att enbart förlita dig på beteendehistorik.
- Rekommendationer som inte återges på sidan: Kontrollera att den kodbaserade URI:n för upplevelseyta matchar sidans URL-mönster och att Web SDK begär och återger beslutssvaret korrekt.
- Katalogobjekt saknas i rekommendationer: Kontrollera att alla katalogobjekt har importerats som beslutsobjekt, taggats med rätt samlingskvalificerare och inkluderats i rätt samlingar som markeringsstrategin refererar till.
God praxis
- Börja med en formelbaserad rankningsmodell som använder beräknade attribut (kategoritillhörighet, interaktionsnyhet) innan du investerar i AI-rankade modeller. Formbaserade modeller är genomskinliga, ändringsbara och ger en solid baslinje för jämförelse.
- Gör intryck och klicka på spärra/knip från dag ett. Utan interaktionsdata kan AI-rankningsmodeller inte träna och du kan inte mäta rekommendationens effektivitet.
- Skapa separata urvalsstrategier för olika rekommendationsytor (hemsida, PDP, e-post) i stället för att återanvända en enda strategi överallt. Olika ytor har olika användaravsikter.
- Använd beräknade attribut för att bearbeta beteendehistorik till rankningssignaler. Raw-händelsedata är för detaljerade för effektiv formelbaserad rankning; aggregerade signaler som"kategoritillhörighetspoäng" och"dagar sedan senaste köp" är mer effektiva.
- Testa reservrekommendationer separat från personaliserade rekommendationer. Se till att reservdelar är varumärkesanpassade standardinställningar av hög kvalitet som ger en bra upplevelse för nya besökare.
- Övervaka återfallsfrekvensen vid kallstart som ett viktigt hälsomått. En minskande fallfrekvens över tiden tyder på ökad beteendetäckning.
- För e-postrekommendationer skickas schemat när beteendeprofilen är mest komplett (t.ex. efter de bästa surftimmarna, inte under dem).
Avvecklingsbeslut
Följande kompromisser bör utvärderas utifrån dina specifika behov.
Realtidssignaler jämfört med ackumulerad historik
Beteendesignaler under session ger omedelbar relevans men begränsat djup. Ackumulerad beteendehistorik ger djup men kan vara inaktuell. Balansen mellan dessa källor påverkar rekommendationskvaliteten.
- Alternativ A prioriterar: Realtidssignaler för omedelbar relevans, kompletterat med historik för kända besökare
- Alternativ C prioriterar: Endast ackumulerad historik, eftersom e-postmeddelanden skickas asynkront
- Rekommendation: För webb och mobiler (Alternativ A, B) kombinerar sessionssignaler med beräknade attribut som härletts från historiskt beteende. För e-post (alternativ C) investerar du mycket i beräknade attribut som sammanfattar beteendehistorik i användbara profilnivåsignaler.
Formelbaserade eller AI-rankade modeller
Formelbaserad rankning är transparent och omedelbar. AI-rankade modeller anpassar sig automatiskt men kräver utbildningsdata och ger mindre insyn i rangordningsbesluten.
- Formelbaserade fördelar: Genomskinlighet, hörbarhet, omedelbar driftsättning och detaljerad affärskontroll över rankningslogik
- AI-rankade favoriter: Automatiserad optimering, identifiering av icke-uppenbara mönster och reducerad manuell justeringsinsats
- Rekommendation: Börja med formelbaserad rankning för att etablera en resultatbaslinje och samla in konverteringsdata. Gå över till AI-rankade modeller när du har tillräckligt med utbildningsdata (över 1 000 konverteringshändelser) och vill optimera bortom vad manuell formeljustering kan göra.
Rekommendationstäckning kontra relevans
Om du breddar artikelkatalogen och avspänningsfilterreglerna ökar procentandelen förfrågningar som får personaliserade rekommendationer, men det kan minska relevansen per rekommendation.
- Hög täckning prioriterar: Maximera antalet besökare som ser personaliserade rekommendationer, användbart när det primära målet är engagemang
- Hög relevans: Visar endast mycket relevanta objekt, även om det innebär att fler besökare ser reservrekommendationer. Användbart när det primära målet är konvertering
- Rekommendation: Starta med måttlig filtrering (exkludera köpta artiklar, ej lagerförda artiklar) och övervaka både reservfrekvensen och konverteringsgraden. Förbättra filtreringsreglerna endast om konverteringsdata har stöd för det.
Personalization djupdesign jämfört med implementeringskomplexitet
Mer omfattande beteendesignaler och mer sofistikerade rankningsmodeller förbättrar rekommendationskvaliteten men ökar komplexiteten i implementeringen och belastningen på underhållet.
- Förenklad implementering prioriterar: Snabbare värdeskapande, lägre underhållsbehov, enklare felsökning och upprepning
- Djupare personalisering prioriterar: Högre konverteringshöjning, bättre kundupplevelse, konkurrensdifferentiering
- Rekommendation: Implementera i faser. Börja med produktvysignaler och receptbaserad rankning (fas 1). Lägg till beräknade attribut för beteendeberikning (fas 2). Utvärdera AI-rankade modeller när grunden är mogen och det finns tillräckligt med utbildningsdata (fas 3).
Relaterad dokumentation
Följande resurser innehåller ytterligare information om de tekniker och funktioner som används i det här mönstret.