Grunderna för schemakomposition

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 Platform finns i XDM-systemöversikt.

Scheman understanding-schemas

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, vilket gör 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 schema-based-workflows

Standardisering är ett nyckelbegrepp 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 för körklara 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 planning

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-behaviors

Data som är avsedda att användas i Experience Platform är grupperade i två beteendetyper:

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 identity

Scheman används för inmatning av data i 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 plattformen:

identityMap 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.

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.

Principer för schemautveckling evolution

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 kunna 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.

I följande tabell visas vilka ändringar som stöds vid redigering av scheman, fältgrupper och datatyper:

*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.

Ange fält som obligatoriska efter intag post-ingestion-required-fields

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:

Scheman och datainmatning

För att kunna importera data till Experience Platform måste en datauppsättning först skapas. 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 schema-building-blocks

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 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 class

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 plattformsprocesser längre fram. 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 för plattformen. 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 field-group

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 standardfältgrupper i 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.

Kom 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 för plattformen. 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.

Datatyp data-type

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.

Experience 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 för plattformen. 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.

Fält field

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:

Giltiga 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:

Kompositionsexempel composition-example

Scheman byggs med en kompositionsmodell och representerar format och struktur för data som ska infogas i 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 union

Med 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 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 mapping-datafiles

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 gruppöverföring.

Scheman för externa målgrupper

Om du samlar målgrupper från externa system i Platform måste du använda följande komponenter för att fånga dem i dina scheman:

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 embedded

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 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 objects-v-freeform

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:

Kon:

Frihandsfält

Fördelarna och nackdelarna med att använda frihandsfält över objekt visas nedan.

Pros:

Kon: