Grunderna för schemakomposition

Det här dokumentet innehåller en introduktion till Experience Data Model (XDM) scheman och de byggstenar, principer och bästa metoder för att sammanställa scheman som ska användas i Adobe Experience Platform. Allmän information om XDM och hur det används i Platform, se 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 standardsättet 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

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.

Den infrastruktur som Experience Platform är byggd, kallas XDM System, underlättar schemabaserade arbetsflöden och innehåller Schema Registry, Schema Editor, schemadata och tjänstekonsumtionsmönster. Se XDM - systemöversikt för mer information.

Det finns flera fördelar med att utnyttja 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

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 det koncept du försöker beskriva kan du börja planera ditt schema genom att tänka på saker som datatyp, potentiella identitetsfält och hur schemat kan utvecklas i framtiden.

Databeteenden i Experience Platform

Uppgifter avsedda att användas i Experience Platform är grupperad i två beteendetyper:

• Registrera data: Innehå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.

Scheman för både post- och tidsserier 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 markerade som "Identitet" enligt beskrivningen i nästa avsnitt.

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å scheman när det gäller kundidentiteter och vilka fält som kan användas för att identifiera ett ämne oavsett varifrån data kommer.

Nyckelfält i dina scheman kan markeras som identiteter för att underlätta med den här processen. När data har matats in infogas uppgifterna i dessa fält iIdentity Graph" för den där individen. Diagramdata kan sedan nås av Real-Time Customer Profile och andra Experience Platform för att ge en sammanslagen bild av varje enskild kund.

Fält som vanligen markeras som "Identity" inkluderar: e-postadress, telefonnummer, Experience Cloud ID (ECID), CRM-ID eller andra unika ID-fält. Du bör också ta hänsyn till unika identifierare som är specifika för din organisation, eftersom de kan vara bra "Identityäven fält.

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 en så robust profil som möjligt. Se översikten på Adobe Experience Platform Identity Service om du vill veta mer om hur identitetsinformation kan hjälpa er att leverera digitala upplevelser till era kunder.

Det finns två sätt att skicka identitetsdata till plattformen:

1. Lägga till identitetsbeskrivningar till enskilda fält, antingen via Gränssnittet för schemaredigeraren eller med API för schemaregister
2. Använda en 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 blir inbäddade i data och därmed blir mindre synliga. Om du importerar rådata bör du definiera enskilda identitetsfält i den faktiska schemastrukturen i stället.

Men identitetskartor kan vara särskilt användbara om du samlar in data från källor som lagrar identiteter tillsammans (till exempel Airship eller Adobe Audience Manager) eller när det finns ett varierande antal identiteter för ett schema. 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 visas i exemplet ovan finns varje tangent i identityMap -objektet representerar ett identitetsnamnutrymme. Värdet för varje nyckel är en array med objekt som representerar identitetsvärdena (id) för respektive namnutrymme. Se Identity Service dokumentation för lista med vanliga ID-namnutrymmen känns igen av Adobe.

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 bakåtkompatibilitet är avgörande för schemautvecklingen, Experience Platform har en rent additiv versionsprincip. Denna princip säkerställer att alla ändringar av schemat endast resulterar i icke-förstörande uppdateringar och ändringar. Med andra ord: brytningsändringar stöds inte.

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

*Se avsnittet nedan för viktig information ställa in nya obligatoriska fält.

Obligatoriska fält

Enskilda schemafält kan vara markerat som obligatoriskt, vilket innebär att alla kapslade 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, samtidigt som du anger ett tidsstämpelfält som det behövs, säkerställer att alla tidsseriehändelser bevaras kronologiskt.

Ange obligatoriska fält 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:

1. 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.
2. Om fältet deltar i Kundprofil i realtid och du exporterar data innan du ställer in dem efter behov, kan det vara null för vissa profiler.
3. Du kan använda API:t för schemaregister för att visa en tidsstämplad ändringslogg för alla XDM-resurser i plattformen, inklusive nya obligatoriska fält. Se guiden på slutpunkt för granskningslogg för mer information.

Scheman och datainhämtning

För att kunna importera data till Experience Platformmåste en datauppsättning först skapas. Datauppsättningar är byggstenarna för dataomvandling och -spårning för Catalog Serviceoch 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. Se översikten på Adobe Experience Platform datainmatning för mer information.

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 av befintliga komponenter och driver standardisering i hela branschen för att stödja leverantörsscheman och komponenter i Platform.

Scheman består av följande formel:

Klass + schemafältgrupp* = 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 ska 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 kan användas i schemat. Detta diskuteras 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 ExperienceEventkrävs för nästan alla plattformsprocesser 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 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 officiell XDM-databas. Du kan även läsa guiden på utforska XDM-komponenter om du föredrar att 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 vilka klasser de är kompatibla med baserat på beteendet hos 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 för 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 dina "Loyalty Members"schema, du skulle kunna använda standardfältgrupper som definierar dessa vanliga begrepp. Koncept som är mer specifika för din organisation (t.ex. kundens lojalitetsprogram 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) läggs till i ett schema i det här exemplet, som innehåller en gruppering av fält till schemats struktur.

Den senaste listan över tillgängliga standardfältgrupper i XDM finns i officiell XDM-databas. Du kan även läsa guiden på utforska XDM-komponenter om du föredrar att visa resurser i användargränssnittet.

Datatyp

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 underfält. De kan definiera flera underfält på samma sätt som fältgrupper, men den största skillnaden är att datatyper kan inkluderas var som helst i ett schema genom att lägga till dem 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 innehå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 Schema Registry självstudiekurser där det 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 i Demographic Details fältgruppen använder "Object", datatyp, enligt texten efter lodstreck (|) 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 officiell XDM-databas. Du kan även läsa guiden på utforska XDM-komponenter om du föredrar att visa resurser i användargränssnittet.

Fä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 enda fält, medan datatyper kan du definiera flera delfält och återanvända samma struktur med flera fält i olika scheman. Förutom att definiera ett fälts"datatyp" som en av de datatyper som definieras i registret, Experience Platform har stöd för grundläggande skalära typer som:

• Sträng
• Heltal
• Dubbel
• Boolean
• Array
• Objekt

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:

• Enum
• Lång
• Kort
• Byte
• Datum
• Datum-tid
• Mappa

Kompositionsexempel

Scheman representerar format och struktur för data som ska hämtas in i Platformoch byggs med en kompositionsmodell. 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 kallasStore Transactions". Schemat implementerar XDM ExperienceEvent klass kombinerad med standard Commerce fältgrupp och användardefinierad Product Info fältgrupp.

Ett annat schema som spårar webbplatstrafiken kan kallasWeb Visits". Den implementerar även XDM ExperienceEvent -klassen, men den här tiden kombinerar standarden Web fältgrupp.

Diagrammet nedan visar dessa scheman och fälten från varje fältgrupp. Den innehåller även två scheman baserade på XDM Individual Profile -klass, inklusiveLoyalty Membersschemat som nämndes tidigare i den här guiden.

Sammanslutning

while Experience Platform gör att du kan skapa scheman för särskilda användningsfall, så att du också kan 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å XDM Individual Profile klassen. Unionen, som visas nedan, samlar fälten för alla scheman som delar samma klass (XDM ExperienceEvent och XDM Individual Profile).

Genom att aktivera ett schema för användning med Real-Time Customer Profile, kommer den att inkluderas i unionen för den typen av klass. Profile ger robusta, centraliserade profiler av kundattribut samt 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, se Översikt över kundprofiler i realtid.

Mappa datafiler till XDM-scheman

Alla datafiler som är inkapslade i Experience Platform måste överensstämma med strukturen i ett XDM-schema. Mer information om hur du formaterar datafiler enligt XDM-hierarkier (inklusive exempelfiler) finns i dokumentet om exempel på ETL-omformningar. Allmän information om inmatning av datafiler i Experience Platform, se batchvis hantering - översikt.

Scheman för externa segment

Om du överför segment från externa system till plattformen måste du använda följande komponenter för att hämta dem i dina scheman:

• Segment definition class: 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 din XDM Individual Profile för att koppla kundprofiler till specifika segment.

Nästa steg

Nu när du förstår grunderna i 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:

• XDM Individual Profile
• XDM ExperienceEvent

The 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. The Schema Library innehåller branschresurser som definieras av Adobe, leverantörsresurser som definieras av Experience Platform partners och klasser, fältgrupper, datatyper och scheman som har komponerats av medlemmar i organisationen.

För att börja komponera schemat med användargränssnittet följer du med Schemaredigeraren, genomgång att skapa schemat "Lojalitetsmedlemmar" som omnämns i hela det här dokumentet.

Börja använda Schema Registry API, börja med att läsa Utvecklarhandbok för API för schematabell. När du har läst utvecklarhandboken följer du de steg som beskrivs i självstudiekursen om skapa ett schema med API:t för schemaregister.

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 bästa metoderna att normalisera data eller att ta en enhet och dela upp den i separata delar som sedan visas i flera tabeller. För att kunna läsa data som helhet eller uppdatera enheten måste läs- och skrivåtgärder utföras i 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 uppgifterna måste datastrukturen, formatet och definitionerna standardiseras så att de kan behandlas enhetligt och effektivt.

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, vilket innebär att man kan gå ifrån den traditionella metoden med datamodellering där alla frågor som ställs 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.

Proffs:

• 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 Servicemå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.

Proffs:

• Frihandsfält skapas direkt under schemats rotobjekt (_tenantId), öka 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.

Resurser för Business.Adobe.com

Mobile Forms Theme Editor Audience Segmentation Mobile Marketing Audience Insights Tv Advertising