Grunderna för schemakomposition
Skapat för:
- Utvecklare
Lär dig mer om XDM-scheman (Experience Data Model) och byggstenarna, principerna och de bästa sätten att komponera scheman i Adobe Experience Platform. Allmän information om XDM och hur det används i Experience Platform finns i XDM-systemöversikt.
Scheman
Ett schema är en uppsättning regler som representerar och validerar datastrukturen och dataformatet. På en hög nivå ger scheman en abstrakt definition av ett objekt i verkligheten (till exempel en person) och ger en översikt över vilka data som ska inkluderas i varje instans av objektet (till exempel förnamn, efternamn, födelsedag o.s.v.).
Förutom att beskriva datastrukturen, tillämpar scheman begränsningar och förväntningar på data så att de kan valideras när de flyttas mellan olika system. Med dessa standarddefinitioner kan data tolkas på ett enhetligt sätt, oavsett ursprung, och behovet av översättning mellan olika program försvinner.
Experience Platform underhåller denna semantiska normalisering med hjälp av scheman. Scheman är standardmetoden för att beskriva data i Experience Platform, så att alla data som överensstämmer med scheman kan återanvändas i en organisation utan konflikter, eller till och med delas mellan flera organisationer.
XDM-scheman är idealiska för att lagra enorma mängder komplexa data i ett självständigt format. Se avsnitten om inbäddade objekt och big data i bilagan till det här dokumentet om du vill ha mer information om hur XDM gör detta.
Schemabaserade arbetsflöden i Experience Platform
Standardisering är ett nyckelkoncept bakom Experience Platform. XDM, som drivs av Adobe, är ett försök att standardisera kundupplevelsedata och definiera standardscheman för kundupplevelsehantering.
Infrastrukturen som Experience Platform bygger på, kallas XDM System, underlättar schemabaserade arbetsflöden och innehåller Schema Registry, Schema Editor, schemadata och tjänstkonsumtionsmönster. Mer information finns i XDM-systemöversikt.
Det finns flera fördelar med att använda scheman i Experience Platform. För det första möjliggör scheman bättre datastyrning och minimering av data, vilket är särskilt viktigt med sekretessbestämmelser. För det andra gör det möjligt att bygga scheman med Adobe standardkomponenter att få användningsklara insikter och använda AI/ML-tjänster med minimala anpassningar. Slutligen tillhandahåller scheman infrastruktur för datautbytesinsikter och effektiv samordning.
Planera ditt schema
Det första steget i att skapa ett schema är att fastställa konceptet, eller det verkliga objektet, som du försöker fånga inom schemat. När du har identifierat konceptet som du försöker beskriva börjar du planera ditt schema genom att tänka på saker som datatypen, potentiella identitetsfält och hur schemat kan utvecklas i framtiden.
Databeteenden i Experience Platform
Data som är avsedda att användas i Experience Platform är grupperade i två beteendetyper:
- Registrera data: Tillhandahåller information om attributen för ett ämne. Ett ämne kan vara en organisation eller individ.
- Tidsseriedata: Ger en ögonblicksbild av systemet när en åtgärd vidtas, antingen direkt eller indirekt, av ett postämne.
Alla XDM-scheman beskriver data som kan kategoriseras som post- eller tidsserier. Databeteendet för ett schema definieras av schemats klass, som tilldelas till ett schema när det skapas första gången. XDM-klasser beskrivs mer ingående senare i det här dokumentet.
Både post- och tidsseriescheman innehåller en karta över identiteter (xdm:identityMap). Det här fältet innehåller identitetsbeteckningen för ett ämne, som har ritats från fält som markerats som "Identitet" enligt beskrivningen i nästa avsnitt.
Identity
Scheman används för att importera data till Experience Platform. Dessa data kan användas för flera tjänster för att skapa en enda, enhetlig vy av en enskild enhet. Därför är det viktigt att tänka på vilka fält som kan användas för att identifiera ett ämne när du utformar scheman för kundidentiteter, oavsett varifrån uppgifterna kommer.
Nyckelfält i dina scheman kan markeras som identiteter för att underlätta med den här processen. Vid datainförsel infogas data i dessa fält i Identity Graph för den aktuella personen. Diagramdata kan sedan nås av Real-Time Customer Profile och andra Experience Platform-tjänster för att ge en sammanslagen vy över varje enskild kund.
Fält som oftast markeras som Identity är: e-postadress, telefonnummer, Experience Cloud ID (ECID), CRM-ID eller andra unika ID-fält. Överväg alla unika identifierare som är specifika för din organisation, eftersom de kan vara bra fält av typen Identity.
Det är viktigt att tänka på kundens identiteter under schemaplaneringsfasen för att säkerställa att data samlas ihop för att skapa den mest robusta profilen som är möjlig. Mer information om hur identitetsinformation kan hjälpa dig att leverera digitala upplevelser till dina kunder finns i Översikt över identitetstjänsten. I dokumentet om god praxis för datamodellering finns tips om hur du använder identiteter när du skapar ett schema.
Det finns två sätt att skicka identitetsdata till Experience Platform:
- Lägga till identitetsbeskrivningar i enskilda fält, antingen via Schemaredigerarens användargränssnitt eller med API:t för schemaregister
- Använda ett
identityMap-fält
identityMap
identityMap är ett mappningsfält som beskriver de olika identitetsvärdena för en individ, tillsammans med deras associerade namnutrymmen. Det här fältet kan användas för att ange identitetsinformation för dina scheman, i stället för att definiera identitetsvärden inom strukturen för själva schemat.
Den största nackdelen med att använda identityMap är att identiteter bäddas in i data och blir mindre synliga som ett resultat av detta. Om du importerar rådata bör du definiera enskilda identitetsfält i den faktiska schemastrukturen i stället.
NOTEidentityMap kan användas som ett källschema i en relation, men kan inte användas som ett referensschema. Detta beror på att alla referensscheman måste ha en synlig identitet som kan mappas i ett referensfält i källschemat. Mer information om kraven för käll- och referensscheman finns i användargränssnittsguiden för relationer.Identitetskartor kan dock vara användbara om det finns ett varierande antal identiteter för ett schema, eller om du samlar in data från källor som lagrar identiteter tillsammans (till exempel Airship eller Adobe Audience Manager). Dessutom krävs identitetskartor om du använder Adobe Experience Platform Mobile SDK.
Ett exempel på en enkel identitetskarta skulle se ut så här:
"identityMap": {
"email": [
{
"id": "jsmith@example.com",
"primary": true
}
],
"ECID": [
{
"id": "87098882279810196101440938110216748923",
"primary": false
},
{
"id": "55019962992006103186215643814973128178",
"primary": false
}
],
"CRMID": [
{
"id": "2e33192000007456-0365c00000000000",
"primary": false
}
]
}
Som exemplet ovan visar representerar varje nyckel i objektet identityMap ett identitetsnamnutrymme. Värdet för varje nyckel är en array med objekt som representerar identitetsvärdena (id) för respektive namnutrymme. I Identity Service-dokumentationen finns en lista över standardnamnutrymmen för identiteter som känns igen av Adobe-program.
NOTEprimary) kan också anges för varje identitetsvärde. Du behöver bara ange primära identiteter för scheman som ska användas i Real-Time Customer Profile. Mer information finns i avsnittet fackliga scheman.Principer för schemautveckling
I takt med att de digitala upplevelserna utvecklas måste även de scheman som används för att representera dem finnas kvar. Ett väldesignat schema kan därför anpassas och utvecklas efter behov, utan att det medför destruktiva ändringar i tidigare versioner av schemat.
Eftersom det är viktigt att bibehålla bakåtkompatibiliteten för att utveckla scheman tillämpar Experience Platform en rent additiv versionsprincip. Denna princip säkerställer att alla ändringar av schemat endast resulterar i icke-förstörande uppdateringar och ändringar. brytningsändringar stöds alltså inte.
NOTEI följande tabell visas vilka ändringar som stöds vid redigering av scheman, fältgrupper och datatyper:
- Lägga till nya fält i resursen
- Göra ett obligatoriskt fält valfritt
- Nya obligatoriska fält*
- Ändra resursens visningsnamn och beskrivning
- Aktiverar schemats deltagande i profilen
- Tar bort tidigare definierade fält
- Byta namn på eller definiera om befintliga fält
- Ta bort eller begränsa fältvärden som tidigare stöds
- Flytta befintliga fält till en annan plats i trädet
- Tar bort schemat
- Inaktivera schemat från att delta i profilen
*Läs avsnittet nedan om du vill veta mer om hur du ställer in nya obligatoriska fält.
Obligatoriska fält
Enskilda schemafält kan markeras som obligatoriska, vilket innebär att alla inkapslade poster måste innehålla data i dessa fält för att validera. Om du till exempel anger ett schemats primära identitetsfält som obligatoriskt kan du se till att alla inkapslade poster deltar i kundprofilen i realtid. Om du anger ett tidsstämpelfält som obligatoriskt ser du dessutom till att alla händelser i tidsserien bevaras kronologiskt.
IMPORTANTnull eller tomma värden för inkapslade fält. Om det inte finns något värde för ett visst fält i en post eller händelse, ska nyckeln för det fältet uteslutas från inmatningsnyttolasten.Ange fält som obligatoriska efter intag
Om ett fält har använts för att importera data och inte ursprungligen ställdes in som nödvändigt, kan det fältet ha ett null-värde för vissa poster. Om du anger det här fältet som obligatoriskt för postinmatning måste alla framtida poster innehålla ett värde för det här fältet, även om historiska poster kan vara null.
Tänk på följande när du ställer in ett tidigare valfritt fält efter behov:
- Om du frågar efter historiska data och skriver resultaten i en ny datamängd, kommer vissa rader att misslyckas eftersom de innehåller null-värden för det obligatoriska fältet.
- Om fältet deltar i Kundprofil för realtid och du exporterar data innan du anger det som nödvändigt, kan det vara null för vissa profiler.
- Du kan använda API:t för schemaregister för att visa en tidsstämplad ändringslogg för alla XDM-resurser i Experience Platform, inklusive nya obligatoriska fält. Mer information finns i guiden för slutpunkten för granskningsloggen.
Scheman och datainmatning
Om du vill importera data till Experience Platform måste du först skapa en datauppsättning. Datauppsättningar är byggstenarna för dataomvandling och spårning för Catalog Service, och representerar vanligtvis tabeller eller filer som innehåller inkapslade data. Alla datauppsättningar baseras på befintliga XDM-scheman, som innehåller begränsningar för vad de inmatade data ska innehålla och hur de ska struktureras. Mer information finns i översikten om Adobe Experience Platform datainmatning.
Bygga block i ett schema
Experience Platform använder en dispositionsmetod där standardbyggstenar kombineras för att skapa scheman. Den här metoden främjar återanvändbarheten för befintliga komponenter och driver standardiseringen i hela branschen för att stödja leverantörsscheman och komponenter i Experience Platform.
Scheman består av följande formel:
Klass + schemafältgrupp&stämpel;ast; = XDM-schema
*Ett schema består av en klass och noll eller flera schemafältgrupper. Det innebär att du kan skapa ett datauppsättningsschema utan att använda fältgrupper alls.
Klass
Dispositionen av ett schema börjar med att tilldela en klass. Klasser definierar de beteendeaspekter av data som schemat kommer att innehålla (post- eller tidsserie). Förutom detta beskriver klasser det minsta antalet gemensamma egenskaper som alla scheman baserade på den klassen behöver innehålla och tillhandahåller ett sätt för att sammanfoga flera kompatibla datamängder.
En schemaklass avgör vilka fältgrupper som är berättigade att användas i schemat. Detta beskrivs mer ingående i nästa avsnitt.
Adobe tillhandahåller flera standardklasser ("core") för XDM. Två av dessa klasser, XDM Individual Profile och XDM ExperienceEvent, krävs för nästan alla Experience Platform-processer längre fram i kedjan. Dessutom kan du skapa egna klasser som beskriver mer specifika användningsfall för organisationen. Anpassade klasser definieras av en organisation när det inte finns några Adobe-definierade huvudklasser tillgängliga som beskriver ett unikt användningsfall.
I följande skärmbild visas hur klasser visas i användargränssnittet i Experience Platform. Eftersom exempelschemat som visas inte innehåller några fältgrupper, kommer alla fält som visas att tillhandahållas av schemaklassen (XDM Individual Profile).
Den senaste listan över tillgängliga standard-XDM-klasser finns i den officiella XDM-databasen. Du kan också läsa guiden utforska XDM-komponenter om du hellre vill visa resurser i användargränssnittet.
Fältgrupp
En fältgrupp är en återanvändbar komponent som definierar ett eller flera fält som implementerar vissa funktioner, som personlig information, hotellinställningar eller adress. Fältgrupper är avsedda att ingå i ett schema som implementerar en kompatibel klass.
Fältgrupper definierar vilken eller vilka klasser de är kompatibla med, baserat på beteendet för de data de representerar (post- eller tidsserie). Det innebär att inte alla fältgrupper är tillgängliga för användning med alla klasser.
Experience Platform innehåller många vanliga fältgrupper från Adobe, samtidigt som leverantörer kan definiera fältgrupper för sina användare, och enskilda användare kan definiera fältgrupper för sina egna specifika koncept.
Om du till exempel vill hämta information som First Name och Home Address för ditt Loyalty Members-schema, kan du använda standardfältgrupper som definierar de vanliga begreppen. Begrepp som är mer specifika för din organisation (t.ex. kundens kundlojalitetsprogram eller produktattribut) som kanske inte omfattas av standardfältgrupper. I det här fallet måste du definiera en egen fältgrupp för att kunna hämta informationen.
NOTEKom ihåg att scheman består av fältgrupper som är "noll eller fler", vilket innebär att du kan skapa ett giltigt schema utan att använda några fältgrupper alls.
I följande skärmbild visas hur fältgrupper representeras i användargränssnittet i Experience Platform. En enda fältgrupp (Demographic Details) har lagts till i ett schema i det här exemplet, som tillhandahåller en gruppering av fält till schemats struktur.
Den senaste listan över tillgängliga standardfältgrupper i XDM finns i den officiella XDM-databasen. Du kan också läsa guiden utforska XDM-komponenter om du hellre vill visa resurser i användargränssnittet.
NOTEDatatyp
Datatyper används som referensfälttyper i klasser eller scheman på samma sätt som grundläggande litteralfält. Den största skillnaden är att datatyper kan definiera flera delfält på samma sätt som fältgrupper. Den största skillnaden mellan dem är att datatyper kan inkluderas var som helst i ett schema genom att lägga till den som"datatyp" för ett fält. Fältgrupper är bara kompatibla med vissa klasser, men datatyper kan inkluderas i alla överordnade klasser eller fältgrupper.
NOTEExperience Platform tillhandahåller ett antal vanliga datatyper som en del av Schema Registry som stöder användning av standardmönster för att beskriva vanliga datastrukturer. Detta förklaras mer ingående i självstudiekurserna Schemaregister och blir tydligare när du går igenom stegen för att definiera datatyper.
I följande skärmbild visas hur datatyperna visas i användargränssnittet i Experience Platform. Ett av fälten som tillhandahålls av fältgruppen Demographic Details använder datatypen Object, vilket anges av texten efter lodtecknet (|) bredvid fältets namn. Den här särskilda datatypen innehåller flera delfält som relaterar till namnet på en enskild person, en konstruktion som kan återanvändas för andra fält där en persons namn måste hämtas.
Den senaste listan över tillgängliga XDM-standarddatatyper finns i den officiella XDM-databasen. Du kan också läsa guiden utforska XDM-komponenter om du hellre vill visa resurser i användargränssnittet.
NOTEFält
Ett fält är den mest grundläggande byggstenen i ett schema. Fält innehåller begränsningar för vilken typ av data de kan innehålla genom att definiera en viss datatyp. Dessa grundläggande datatyper definierar ett enskilt fält, medan de datatyper som tidigare nämnts gör att du kan definiera flera delfält och återanvända samma flerfältstruktur i olika scheman. Förutom att definiera ett fälts"datatyp" som en av de datatyper som definieras i registret, stöder Experience Platform grundläggande skalära typer som:
- Sträng
- Heltal
- Dubbel
- Boolean
- Array
- Objekt
TIPGiltiga intervall för dessa skalära typer kan begränsas ytterligare till vissa mönster, format, minimum/maximum eller fördefinierade värden. Med dessa begränsningar kan en mängd mer specifika fälttyper visas, bland annat:
- Enum
- Lång
- Kort
- Byte
- Datum
- Datum-tid
- Karta
NOTEKompositionsexempel
Scheman byggs med en kompositionsmodell och representerar format och struktur för data som ska infogas i Experience Platform. Som tidigare nämnts består dessa scheman av en klass och noll eller flera fältgrupper som är kompatibla med den klassen.
Ett schema som beskriver inköp som görs i en butik kan till exempel kallas Store Transactions. Schemat implementerar klassen XDM ExperienceEvent kombinerat med standardfältgruppen Commerce och en användardefinierad fältgrupp Product Info.
Ett annat schema som spårar webbplatstrafiken kan kallas Web Visits. Den implementerar även klassen XDM ExperienceEvent, men den här gången kombineras standardfältgruppen Web.
Diagrammet nedan visar dessa scheman och fälten från varje fältgrupp. Den innehåller också två scheman baserade på klassen XDM Individual Profile, inklusive schemat Loyalty Members som nämndes tidigare i den här guiden.
Sammanslutning
I Experience Platform kan du skapa scheman för olika användningsområden, men du kan även se en "union" av scheman för en viss klasstyp. I föregående diagram visas två scheman baserade på klassen XDM ExperienceEvent och två scheman baserade på klassen XDM Individual Profile. Unionen, som visas nedan, samlar fälten i alla scheman som delar samma klass (XDM ExperienceEvent respektive XDM Individual Profile).
Genom att aktivera ett schema för användning med Real-Time Customer Profile inkluderas det i unionen för den klasstypen. Profile levererar robusta, centraliserade profiler med kundattribut och ett tidsstämplat konto för varje händelse som kunden har haft i alla system som är integrerade med Experience Platform. Profile använder unionsvyn för att representera dessa data och ge en helhetsbild av varje enskild kund.
Mer information om hur du arbetar med Profile finns i Översikt över kundprofiler i realtid.
Mappa datafiler till XDM-scheman
Alla datafiler som importeras till Experience Platform måste överensstämma med strukturen i ett XDM-schema. Mer information om hur du formaterar datafiler så att de överensstämmer med XDM-hierarkier (inklusive exempelfiler) finns i dokumentet om ETL-omformningar. Allmän information om hur du importerar datafiler till Experience Platform finns i översikten över gruppinhämtning.
Scheman för externa målgrupper
Om du överför målgrupper från externa system till Experience Platform måste du använda följande komponenter för att hämta dem i dina scheman:
- Segment definition klass: Använd den här standardklassen för att hämta nyckelattribut för en extern segmentdefinition.
- Segment Membership Details fältgrupp: Lägg till den här fältgruppen i ditt XDM Individual Profile-schema för att associera kundprofiler med specifika målgrupper.
Nästa steg
Nu när du förstår grunderna för schemakomposition kan du börja utforska och skapa scheman med Schema Registry.
Om du vill granska strukturen för de två grundläggande XDM-klasserna och deras vanliga kompatibla fältgrupper, se följande referensdokumentation:
Schema Registry används för att komma åt Schema Library i Adobe Experience Platform och tillhandahåller ett användargränssnitt och RESTful API från vilket alla tillgängliga biblioteksresurser är tillgängliga. Schema Library innehåller branschresurser som definierats av Adobe, leverantörsresurser som definierats av Experience Platform partners och klasser, fältgrupper, datatyper och scheman som har disponerats av medlemmar i din organisation.
Om du vill börja komponera schemat med hjälp av användargränssnittet följer du med schemaredigerarsjälvstudiekursen för att skapa det schema för lojalitetsmedlemmar som omnämns i det här dokumentet.
Börja med att läsa API-utvecklarhandbokenför schemat när du vill börja använda Schema Registry-API:t. När du har läst utvecklarhandboken följer du de steg som beskrivs i självstudiekursen Skapa ett schema med API:t för schemaregistret.
Bilaga
Följande avsnitt innehåller ytterligare information om principerna för schemakomposition.
Relationstabeller jämfört med inbäddade objekt
När du arbetar med relationsdatabaser omfattar de effektivaste strategierna att normalisera data eller att ta en enhet och dela upp den i separata delar som sedan visas i flera tabeller. Om du vill läsa data som helhet eller uppdatera entiteten måste läs- och skrivåtgärder utföras för många enskilda tabeller med JOIN.
Genom att använda inbäddade objekt kan XDM-scheman representera komplexa data direkt och lagra dem i självständiga dokument med en hierarkisk struktur. En av de största fördelarna med den här strukturen är att den gör det möjligt att fråga efter data utan att behöva rekonstruera enheten med dyrbara kopplingar till flera deformerade tabeller. Det finns inga hårda begränsningar för hur många nivåer din schemahierarki kan vara.
Scheman och big data
Moderna digitala system genererar enorma mängder beteendesignaler (transaktionsdata, webbloggar, internet med mera). Dessa stora data ger fantastiska möjligheter att optimera upplevelser, men är svåra att använda på grund av datans storlek och variation. För att få ut mer av informationen måste dess struktur, format och definitioner standardiseras så att de kan behandlas på ett konsekvent och effektivt sätt.
Scheman löser detta problem genom att data kan integreras från flera källor, standardiseras med gemensamma strukturer och definitioner och delas mellan olika lösningar. Detta gör att efterföljande processer och tjänster kan besvara alla typer av frågor som ställs om data. Det går längre än till traditionell datamodellering där alla frågor som ska ställas om data är kända i förväg och data är modellerade för att uppfylla dessa förväntningar.
Objekt jämfört med frihandsfält
Det finns några viktiga faktorer att tänka på när du väljer objekt framför frihandsfält när du utformar scheman:
Objekt
Fördelarna och nackdelarna med att använda objekt över frihandsfält visas nedan.
Pros:
- Objekt används bäst när du vill skapa en logisk gruppering av vissa fält.
- Objekten organiserar schemat på ett mer strukturerat sätt.
- Objekt kan indirekt bidra till att skapa en bra menystruktur i segmentbyggargränssnittet. De grupperade fälten i schemat återspeglas direkt i mappstrukturen som finns i gränssnittet i Segment Builder.
Kon:
- Fält blir mer kapslade.
- När du använder Adobe Experience Platform Query Service måste längre referenssträngar anges för frågefält som är kapslade i objekt.
Frihandsfält
Fördelarna och nackdelarna med att använda frihandsfält över objekt visas nedan.
Pros:
- Frihandsfält skapas direkt under rotobjektet för schemat (
_tenantId), vilket ökar synligheten. - Referenssträngar för frihandsfält brukar vara kortare när frågetjänsten används.
Kon:
- Platsen för friformsfält i schemat är ad för sig, vilket innebär att de visas i alfabetisk ordning i schemaredigeraren. Detta kan göra att scheman blir mindre strukturerade och liknande friformsfält kan hamna långt åtskilda beroende på deras namn.