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

Experience Data Model (XDM) är det centrala ramverket 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 guiden ska du granska XDM - systemöversikt för en introduktion på hög nivå av XDM och dess roll i Experience Platform.

Eftersom den här handboken enbart fokuserar på viktiga aspekter av schemadesign rekommenderar vi att du läser grunderna för schemakomposition om du vill ha detaljerade förklaringar av de enskilda schemaelement som nämns i den här handboken.

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 detta dokument fokuserar på de senare stegen för att organisera och konstruera en ERD efter det att datakällorna har identifierats, kan förklaringarna till diagrammets olika komponenter ge 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 Platformskapar du en högnivåteknisk 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 föra in data i 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 enheter du vill ta med Platformmåste de här entiteterna sorteras i kategorierna profil, sökning och händelse:

Ö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 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 att 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 är state attribut ska 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 sammanställningsvärde numberOfPurchases under en vecka, 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, startDateoch endDate.

Proffs

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.

Proffs

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

The regler för schemautveckling diktera 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. Se avsnittet om identitetsfält i grunderna för schemakomposition för mer detaljerad information om hur dessa fält används.

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 Adobe Analytics ExperienceEvent Template fältgrupp 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.

Adobe-programfältgrupper tilldelar automatiskt en primär standardidentitet genom att använda identityMap -fält, som är ett systemgenererat, skrivskyddat objekt som mappar vanliga identitetsvärden 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 Schemaläggaren för att öppna Field properties sidofält. Läs dokumentationen om typspecifika fältegenskaper för exakta beskrivningar av tillgängliga fält.

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 se självstudiekursen på skapa ett schema i användargränssnittet om du vill ha stegvisa 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.