Bästa tillvägagångssätt för datamodellering

Experience Data Model (XDM) är grundramverket som standardiserar kundupplevelsedata genom att tillhandahålla gemensamma strukturer och definitioner för användning i Adobe Experience Platform-tjänster längre fram i kedjan. Genom att följa XDM-standarder kan alla kundupplevelsedata införlivas i en gemensam representation och användas för att få värdefulla insikter från kundåtgärder, definiera kundmålgrupper och uttrycka kundattribut i personaliseringssyfte.

Eftersom XDM är extremt mångsidigt och anpassningsbart efter design är det viktigt att följa bästa praxis för datamodellering när du utformar dina scheman. Det här dokumentet innehåller de viktigaste beslut och överväganden som du måste ta när du mappar kundupplevelsedata till XDM.

Komma igång

Innan du läser den här handboken bör du gå igenom XDM-systemöversikten för att få en introduktion på hög nivå till XDM och dess roll i Experience Platform.

Eftersom den här guiden enbart fokuserar på viktiga överväganden när det gäller schemadesign, rekommenderar vi att du läser grunderna i schemakomposition för detaljerade förklaringar av de enskilda schemaelementen som nämns i den här guiden.

Sammanfattning av bästa praxis summary

Den rekommenderade metoden för att utforma din datamodell för användning i Experience Platform kan sammanfattas på följande sätt:

Stegen för att identifiera de datakällor som krävs för att du ska kunna använda ditt företag varierar från organisation till organisation. Medan resten av avsnitten i det här dokumentet fokuserar på de senare stegen för att organisera och konstruera en ERD efter att datakällorna har identifierats, kan förklaringarna för diagrammets olika komponenter ge dig underlag för dina beslut om vilken av datakällorna som ska migreras till Platform.

Skapa en högnivå av ERD create-an-erd

När du har bestämt vilka datakällor du vill hämta till Platform kan du skapa en högnivå av ERD som hjälper dig att mappa dina data till XDM-scheman.

Exemplet nedan representerar en förenklad ERD för ett företag som vill hämta data till Platform. Bilden visar de viktigaste enheterna som bör sorteras i XDM-klasser, inklusive kundkonton, hotell, adresser och flera vanliga e-handelshändelser.

Sortera entiteter i profil-, uppslags- och händelsekategorier sort-entities

När du har skapat en ERD för att identifiera de nödvändiga entiteter som du vill hämta till Platform måste dessa entiteter sorteras i profil-, uppslags- och händelsekategorier:

Överväganden för entitetssortering considerations

Avsnitten nedan ger ytterligare vägledning om hur du sorterar dina enheter i ovanstående kategorier.

Muterbara och oföränderliga data mutable-and-immutable-data

Ett primärt sätt att sortera mellan enhetskategorier är om de data som hämtas är ändringsbara eller inte.

Attribut som tillhör profiler eller uppslagsenheter kan normalt ändras. En kunds preferenser kan till exempel förändras över tid och parametrarna för en prenumerationsplan kan uppdateras beroende på marknadstrender.

Händelsedata kan däremot normalt inte ändras. Eftersom händelser kopplas till en viss tidsstämpel ändras inte den "systemögonblicksbild" som en händelse ger. En händelse kan t.ex. fånga upp en kunds preferenser när han/hon checkar ut en kundvagn, och den ändras inte även om kundens preferenser ändras senare. Händelsedata kan inte ändras efter att de har spelats in.

Sammanfattningsvis innehåller profiler och sökentiteter ändringsbara attribut och representerar den senaste informationen om de ämnen de hämtar, medan händelser är oföränderliga poster i systemet vid en viss tidpunkt.

Kundattribut customer-attributes

Om ett företag innehåller attribut som är kopplade till en enskild kund är det troligast en profilenhet. Exempel på kundattribut är:

Spåra data över tid track-data

Om du vill analysera hur vissa attribut inom en enhet ändras över tid är det troligast en händelsenhet. Om du till exempel lägger till produktartiklar i en kundvagn kan du spåra dem som tilläggshändelser i kundvagnen i Platform:

Användningsexempel för segmentering segmentation-use-cases

När ni kategoriserar era enheter är det viktigt att tänka på vilka målgrupper ni kanske vill bygga för att hantera era specifika affärsanvändningsfall.

Ett företag vill t.ex. känna till alla "Guld" eller "Platinum"-medlemmar i deras lojalitetsprogram som har gjort fler än fem inköp det senaste året. På grundval av denna segmenteringslogik kan följande slutsatser dras om hur relevanta enheter bör representeras:

Användningsexempel vid aktivering activation-use-cases

Förutom att ta hänsyn till användningsfall för segmentering bör ni också granska användningsexemplen för aktivering för dessa målgrupper för att identifiera ytterligare relevanta attribut.

Ett företag har till exempel byggt upp en målgrupp baserat på regeln country = US. När målgruppen sedan aktiveras för vissa nedladdningsmål vill företaget filtrera alla exporterade profiler baserat på hemstatus. Därför bör ett state-attribut också hämtas i den tillämpliga profilentiteten.

Sammanställda värden aggregated-values

Baserat på användningsfallet och detaljrikedomen i era data bör ni bestämma om vissa värden behöver föraggregeras innan de inkluderas i en profil eller en händelseenhet.

Ett företag vill till exempel skapa en målgrupp baserat på antalet kundvagnsköp. Du kan välja att inkludera dessa data med lägsta granularitet genom att ta med varje tidsstämplad inköpshändelse som sin egen enhet. Detta kan ibland öka antalet registrerade händelser exponentiellt. Om du vill minska antalet inkapslade händelser kan du välja att skapa ett aggregerat värde numberOfPurchases över en vecka som är lång eller månadslängd. Andra sammanställningsfunktioner som MIN och MAX kan också användas i dessa situationer.

Kardinalitet cardinality

Kardinalerna i ERD kan även ge vissa ledtrådar om hur ni kategoriserar era era enheter. Om det finns en en-till-många-relation mellan två enheter är det troligtvis enheten som representerar"många" som är en händelseenhet. Det finns dock även fall där"många" är en uppsättning uppslagsenheter som anges som en array i en profilentitet.

I följande tabell visas några vanliga entitetsrelationer och de kategorier som kan härledas från dem:

Fördelar och nackdelar med olika enhetsklasser pros-and-cons

I föregående avsnitt fanns allmänna riktlinjer för hur du ska kategorisera dina enheter, men det är viktigt att du förstår att det ofta kan finnas fördelar och nackdelar för att välja en enhetskategori framför en annan. Följande fallstudie är avsedd att illustrera hur du kan överväga dina alternativ i dessa situationer.

Ett företag håller reda på aktiva prenumerationer för sina kunder, där en kund kan ha många prenumerationer. Företaget vill också inkludera prenumerationer för segmenteringsanvändning, som att hitta alla användare med aktiva prenumerationer.

I det här scenariot har företaget två möjliga alternativ för att representera en kunds prenumerationer i sin datamodell:

Metod 1: Använd profilattribut profile-approach

Det första sättet är att inkludera en array med prenumerationer som attribut i profilentiteten för kunder. Objekt i den här arrayen skulle innehålla fält för category, status, planName, startDate och endDate.

Pros

Kon

Metod 2: Använd händelseentiteter event-approach

Det andra sättet är att använda händelsescheman för att representera prenumerationer. Detta innebär att man måste importera samma prenumerationsfält som det första tillvägagångssättet, med tillägg av ett prenumerations-ID, ett kund-ID och en tidsstämpel för när prenumerationshändelsen inträffade.

Pros

Kon

Skapa scheman baserat på dina kategoriserade entiteter schemas-for-categorized-entities

När du har sorterat dina enheter i profil-, uppslags- och händelsekategorier kan du börja konvertera din datamodell till XDM-scheman. I demonstrationssyfte har exempeldatamodellen som visades tidigare sorterats i lämpliga kategorier i följande diagram:

Kategorin som en entitet har sorterats under bör avgöra vilken XDM-klass du baserar dess schema på. Så här upprepar du:

Avsnitten nedan innehåller allmän vägledning om hur du konstruerar scheman baserade på din ERD.

Anta en iterativ modelleringsmetod iterative-modeling

reglerna för schemautveckling anger att endast icke-förstörande ändringar kan göras i scheman när de har implementerats. När du har lagt till ett fält i ett schema och data har importerats till det fältet kan fältet alltså inte längre tas bort. Därför är det viktigt att du använder en iterativ modelleringsmetod när du först skapar dina scheman, och börjar med en förenklad implementering som successivt blir mer komplicerad över tiden.

Om du är osäker på om ett visst fält är nödvändigt för att inkluderas i ett schema är det bästa sättet att utelämna det. Om det senare fastställs att fältet är nödvändigt kan det alltid läggas till i nästa iteration i schemat.

Identitetsfält identity-fields

I Experience Platform används XDM-fält som markerats som identiteter för att sammanfoga information om enskilda kunder som kommer från flera datakällor. Även om ett schema kan ha flera fält markerade som identiteter måste en enda primär identitet definieras för att schemat ska kunna aktiveras för användning i Real-Time Customer Profile. Mer information om hur de här fälten används finns i avsnittet Identitetsfält i grunderna för schemakomposition.

När du utformar dina scheman är det troligt att eventuella primärnycklar i relationsdatabastabeller passar för primära identiteter. Andra exempel på tillämpliga identitetsfält är kundens e-postadresser, telefonnummer, konto-ID:n och ECID.

Schemafältgrupper för Adobe adobe-application-schema-field-groups

Experience Platform tillhandahåller flera färdiga XDM-schemafältgrupper för datainhämtning som är relaterade till följande Adobe-program:

Du kan till exempel använda fältgruppen Adobe Analytics ExperienceEvent Templateför att mappa Analytics-specifika fält till dina XDM-scheman. Beroende på vilka Adobe-program du arbetar med bör du använda dessa fältgrupper som tillhandahålls av Adobe i dina scheman.

Programfältgrupper i Adobe tilldelar automatiskt en primär standardidentitet genom att använda fältet identityMap, som är ett systemgenererat, skrivskyddat objekt som mappar standardvärden för identiteter för en enskild kund.

För Adobe Analytics är ECID standardidentitet. Om ett ECID-värde inte anges av en kund blir den primära identiteten i stället AAID.

Datavalideringsfält data-validation-fields

När du importerar data till datavjön framtvingas datavalidering endast för begränsade fält. Om du vill validera ett visst fält under en gruppinmatning måste du markera fältet som begränsat i XDM-schemat. För att förhindra att felaktiga data importeras till Platform rekommenderar vi att du definierar villkoren för fältnivåvalidering när du skapar dina scheman.

Om du vill ange begränsningar för ett visst fält väljer du fältet i Schemaredigeraren för att öppna sidofältet Field properties. I dokumentationen om typspecifika fältegenskaper finns exakta beskrivningar av de tillgängliga fälten.

Tips för att bevara dataintegriteten data-integrity-tips

Följande är en samling förslag som bevarar dataintegriteten när du skapar ett schema.

Nästa steg

Det här dokumentet innehåller allmänna riktlinjer och bästa praxis för utformning av din datamodell för Experience Platform. Sammanfattning:

När du är klar kan du gå till självstudiekursen Skapa ett schema i användargränssnittet för steg-instruktioner om hur du skapar ett schema, tilldelar lämplig klass för entiteten och lägger till fält som data ska mappas till.