Basisbeginselen van de schemacompositie

Leer over de schema's van de Gegevens van de Ervaring van het Model (XDM) en de bouwstenen, principes, en beste praktijken voor het samenstellen van schema's in Adobe Experience Platform. Voor algemene informatie over XDM en hoe het binnen wordt gebruikt Platform, zie de XDM System, overzicht.

Schema's begrijpen understanding-schemas

Een schema is een set regels die de structuur en indeling van gegevens vertegenwoordigen en valideren. Op een hoog niveau, verstrekken de schema's een abstracte definitie van een real-world voorwerp (zoals een persoon) en schetsen welke gegevens in elke instantie van dat voorwerp (zoals voornaam, achternaam, verjaardag, etc.) zouden moeten worden omvat.

Naast het beschrijven van de structuur van gegevens, passen de schema's beperkingen en verwachtingen op gegevens toe zodat het kan worden bevestigd aangezien het zich tussen systemen beweegt. Deze standaarddefinities maken het mogelijk dat gegevens consistent worden geïnterpreteerd, ongeacht de oorsprong, en verwijderen de noodzaak van vertaling in verschillende toepassingen.

Experience Platform handhaaft deze semantische normalisatie door schema's te gebruiken. De schema's zijn de standaardmanier om gegevens in Experience Platform te beschrijven, toestaand alle gegevens die aan schema's in overeenstemming zijn om over een organisatie zonder conflicten worden opnieuw gebruikt, of zelfs tussen veelvoudige organisaties worden gedeeld.

XDM-schema's zijn ideaal voor het opslaan van grote hoeveelheden complexe gegevens in een op zichzelf staand formaat. Zie de secties op ingesloten objecten en big data in de bijlage bij dit document voor meer informatie over hoe XDM dit doet.

Workflows op basis van schema's in Experience Platform schema-based-workflows

Standaardisering is een sleutelbegrip van het Experience Platform. XDM, die door Adobe wordt gedreven, is een inspanning om de gegevens van de klantenervaring te standaardiseren en standaardschema's voor het beheer van de klantenervaring te bepalen.

De infrastructuur waarop het Experience Platform is gebouwd, bekend als XDM System, vergemakkelijkt workflows op basis van schema's en omvat de Schema Registry, Schema Editor, schema-metagegevens en servicepatronen. Zie de XDM System, overzicht voor meer informatie .

Er zijn verscheidene zeer belangrijke voordelen aan het gebruiken van schema's in Experience Platform. In de eerste plaats zorgen schema's voor een beter gegevensbeheer en gegevensminimalisering, wat vooral belangrijk is bij privacyregels. Ten tweede, staan de bouwschema's met de standaardcomponenten van de Adobe voor uit-van-de-doosinzichten en gebruik van de diensten van AI/ML met minimale aanpassingen toe. Ten slotte bieden schema's infrastructuren voor het uitwisselen van inzichten in gegevens en een efficiënte orchestratie.

Uw schema plannen planning

De eerste stap in het bouwen van een schema is het concept, of real-world voorwerp, te bepalen dat u binnen het schema probeert te vangen. Zodra u het concept identificeert dat u probeert te beschrijven, begin plannend uw schema door over dingen zoals het type van gegevens, potentiële identiteitsgebieden te denken, en hoe het schema in de toekomst kan evolueren.

Gedrag van gegevens in Experience Platform data-behaviors

Gegevens die bestemd zijn voor gebruik in Experience Platform worden gegroepeerd in twee gedragstypen:

Alle XDM schema's beschrijven gegevens die als verslag of tijdreeks kunnen worden gecategoriseerd. Het gegevensgedrag van een schema wordt bepaald door de klasse van het schema, die aan een schema wordt toegewezen wanneer het eerst wordt gecreeerd. XDM-klassen worden later in dit document nader beschreven.

Zowel de verslagen als de tijdreeksschema's bevatten een kaart van identiteiten (xdm:identityMap). Dit veld bevat de identiteitsrepresentatie van een onderwerp, getekend vanuit velden die zijn gemarkeerd als Identiteit zoals beschreven in de volgende sectie.

Identity identity

Schema's worden gebruikt voor het opnemen van gegevens in het Experience Platform. Deze gegevens kunnen over de veelvoudige diensten worden gebruikt om één enkele, verenigde mening van een individuele entiteit tot stand te brengen. Daarom is het belangrijk om bij het ontwerpen van schema's voor klantenidentiteiten te overwegen welke gebieden kunnen worden gebruikt om een onderwerp te identificeren, ongeacht waar de gegevens uit kunnen komen.

Om dit proces te helpen, kunnen de belangrijkste gebieden binnen uw schema's als identiteiten worden gemerkt. Bij gegevensinvoer worden de gegevens in die velden ingevoegd in "Identity Graph" voor die persoon. De grafiekgegevens zijn vervolgens toegankelijk via Real-Time Customer Profile en andere diensten van het Experience Platform om een geneutraliseerde mening van elke individuele klant te verstrekken.

Velden die doorgaans zijn gemarkeerd als "Identity" include: email address, phone number, Experience Cloud ID (ECID), CRM-id of andere unieke id-velden. Houd rekening met alle unieke id's die specifiek zijn voor uw organisatie, omdat deze goed kunnen zijn. "Identity" ook velden.

Het is belangrijk om over klantenidentiteiten tijdens de schema planningsfase te denken helpen ervoor zorgen dat de gegevens worden samengebracht om het robuustst mogelijke profiel te bouwen. Als u meer wilt weten over de manier waarop identiteitsgegevens u kunnen helpen uw klanten digitale ervaringen te bieden, raadpleegt u de Overzicht van identiteitsservice. Zie het document met aanbevolen werkwijzen voor gegevensmodellen voor tips over het gebruik van identiteiten bij het maken van een schema.

Er zijn twee manieren om identiteitsgegevens naar Platform te verzenden:

identityMap identityMap

identityMap is een map-type gebied dat de diverse identiteitswaarden voor een individu, samen met hun bijbehorende namespaces beschrijft. Dit gebied kan worden gebruikt om identiteitsinformatie voor uw schema's te verstrekken, in plaats van het bepalen van identiteitswaarden binnen de structuur van het schema zelf.

Het belangrijkste nadeel van het gebruik identityMap is dat identiteiten in de gegevens worden ingesloten en daardoor minder zichtbaar worden. Als u onbewerkte gegevens opgeeft, moet u in plaats daarvan afzonderlijke identiteitsvelden definiëren binnen de daadwerkelijke schemastructuur.

Identiteitskaarten kunnen echter nuttig zijn als er een variabel aantal identiteiten voor een schema is of als u gegevens opneemt uit bronnen die identiteiten bij elkaar opslaan (zoals Airship of Adobe Audience Manager). Daarnaast zijn identiteitskaarten vereist als u de Adobe Experience Platform Mobile SDK.

Een voorbeeld van een eenvoudige identiteitskaart zou als het volgende kijken:

"identityMap": {
  "email": [
    {
      "id": "jsmith@example.com",
      "primary": true
    }
  ],
  "ECID": [
    {
      "id": "87098882279810196101440938110216748923",
      "primary": false
    },
    {
      "id": "55019962992006103186215643814973128178",
      "primary": false
    }
  ],
  "CRMID": [
    {
      "id": "2e33192000007456-0365c00000000000",
      "primary": false
    }
  ]
}

Zoals in het bovenstaande voorbeeld wordt getoond, wordt elke toets in het dialoogvenster identityMap object staat voor een naamruimte van de identiteit. De waarde voor elke sleutel is een array van objecten die de identiteitswaarden (id) voor de desbetreffende naamruimte. Zie de Identity Service documentatie voor een lijst met standaardnaamruimten wordt herkend door Adobe-toepassingen.

Beginselen voor de ontwikkeling van schema's evolution

Naarmate de aard van de digitale ervaringen zich blijft ontwikkelen, moeten de schema's die gebruikt worden om ze te vertegenwoordigen ook worden gebruikt. Een goed ontworpen schema kan daarom aanpassen en evolueren zoals nodig, zonder destructieve veranderingen in vorige versies van het schema te veroorzaken.

Aangezien het handhaven van achterwaartse verenigbaarheid essentieel voor schemaevolutie is, handhaaft het Experience Platform een zuiver additief versieringsbeginsel. Dit beginsel zorgt ervoor dat om het even welke revisies aan het schema slechts in niet-destructieve updates en veranderingen resulteren. Met andere woorden: afbrekende wijzigingen worden niet ondersteund.

In de volgende tabel wordt aangegeven welke wijzigingen worden ondersteund bij het bewerken van schema's, veldgroepen en gegevenstypen:

*Raadpleeg de onderstaande sectie voor belangrijke overwegingen met betrekking tot nieuwe vereiste velden instellen.

Vereiste velden

Afzonderlijke schemavelden kunnen gemarkeerd als vereist, wat betekent dat alle opgenomen records gegevens in die velden moeten bevatten om de validatie te kunnen doorstaan. Bijvoorbeeld, kan het plaatsen van het primaire identiteitsgebied van een schema zoals vereist helpen ervoor zorgen dat alle ingebedde verslagen aan het Profiel van de Klant in real time zullen deelnemen. Als u een tijdstempelveld instelt als vereist, blijven alle gebeurtenissen in de tijdreeks chronologisch behouden.

Velden instellen zoals vereist na invoegen post-ingestion-required-fields

Als een veld is gebruikt om gegevens in te voeren en oorspronkelijk niet is ingesteld als vereist, heeft dat veld mogelijk een null-waarde voor sommige records. Als u dit veld na invoer als vereist instelt, moeten alle toekomstige records een waarde voor dit veld bevatten, ook al kunnen historische records null zijn.

Houd rekening met het volgende wanneer u een eerder optioneel veld naar wens instelt:

Schema's en gegevensinvoer

Om gegevens in Experience Platform in te voeren, moet een dataset eerst worden gecreeerd. Datasets zijn de bouwstenen voor gegevenstransformatie en -tracking voor Catalog Serviceen vertegenwoordigen over het algemeen tabellen of bestanden die ingesloten gegevens bevatten. Alle datasets zijn gebaseerd op bestaande schema's XDM, die beperkingen voor wat verstrekken de ingebedde gegevens zouden moeten bevatten en hoe het zou moeten worden gestructureerd. Zie het overzicht op Adobe Experience Platform-gegevensinscriptie voor meer informatie .

Bouwstenen van een schema schema-building-blocks

Experience Platform gebruikt een compositiebenadering waarin de standaard bouwstenen worden gecombineerd om schema's tot stand te brengen. Deze benadering bevordert de herbruikbaarheid van bestaande componenten en drijft standaardisatie over de industrie om verkopersschema's en componenten in Platform.

De schema's worden samengesteld gebruikend de volgende formule:

Klasse + Schema&veldgroep; = XDM-schema

*Een schema bestaat uit een klasse en nul of meer groepen schemavelden. Dit betekent dat u een datasetschema kon samenstellen zonder gebiedsgroepen bij allen te gebruiken.

Klasse class

Het samenstellen van een schema begint door een klasse toe te wijzen. De klassen bepalen de gedragsaspecten van de gegevens die het schema (verslag of tijdreeks) zal bevatten. Bovendien beschrijven de klassen het kleinste aantal gemeenschappelijke eigenschappen die alle die schema's op die klasse worden gebaseerd zouden moeten omvatten en een manier verstrekken om veelvoudige compatibele datasets worden samengevoegd.

De klasse van een schema bepaalt welke gebiedsgroepen voor gebruik in dat schema in aanmerking komen. Dit wordt meer in detail besproken in de volgende sectie.

Adobe biedt verschillende standaard XDM-klassen (core). Twee van deze klassen, XDM Individual Profile en XDM ExperienceEvent, zijn vereist voor bijna alle downstreamprocessen van het Platform. Naast deze kernklassen kunt u ook uw eigen aangepaste klassen maken om specifieke gebruiksgevallen voor uw organisatie te beschrijven. Aangepaste klassen worden gedefinieerd door een organisatie wanneer er geen Adobe-gedefinieerde kernklassen beschikbaar zijn om een uniek gebruiksgeval te beschrijven.

De volgende schermafbeelding toont hoe klassen worden vertegenwoordigd in de gebruikersinterface van het platform. Aangezien het getoonde voorbeeldschema geen gebiedsgroepen bevat, worden alle getoonde gebieden verstrekt door de klasse van het schema (XDM Individual Profile).

Raadpleeg voor de meest recente lijst met beschikbare standaard XDM-klassen de officiële XDM-opslagplaats. U kunt ook naar de handleiding verwijzen op XDM-componenten verkennen als u liever bronnen in de gebruikersinterface weergeeft.

Veldgroep field-group

Een veldgroep is een herbruikbare component die een of meer velden definieert die bepaalde functies implementeren, zoals persoonlijke gegevens, hotelvoorkeuren of adres. Veldgroepen moeten worden opgenomen als onderdeel van een schema dat een compatibele klasse implementeert.

Veldgroepen definiëren met welke klasse of klassen ze compatibel zijn, op basis van het gedrag van de gegevens die ze vertegenwoordigen (record- of tijdreeks). Dit betekent dat niet alle veldgroepen beschikbaar zijn voor gebruik met alle klassen.

Experience Platform omvat vele standaardgroepen van het gebied van de Adobe terwijl ook verkopers toestaan om gebiedsgroepen voor hun gebruikers te bepalen, en individuele gebruikers om gebiedsgroepen voor hun eigen specifieke concepten te bepalen.

Als u bijvoorbeeld details wilt vastleggen, zoals "First Name" en "Home Address" voor je "Loyalty Members" schema, zou u standaardgebiedsgroepen kunnen gebruiken die die gemeenschappelijke concepten bepalen. Nochtans, concepten die specifieker voor uw organisatie (zoals de details van het douaneloyaliteitsprogramma of productattributen) zijn die niet door standaardgebiedsgroepen kunnen worden behandeld. In dit geval moet u uw eigen veldgroep definiëren om deze gegevens vast te leggen.

Herinner dat de schema's uit "nul of meer"gebiedsgroepen worden samengesteld, zodat betekent dit dat u een geldig schema kon samenstellen zonder enige gebiedsgroepen bij allen te gebruiken.

De volgende schermafbeelding laat zien hoe veldgroepen worden vertegenwoordigd in de gebruikersinterface van het platform. Eén veldgroep (Demographic Details) wordt in dit voorbeeld toegevoegd aan een schema, dat een groepering van gebieden aan de structuur van het schema verstrekt.

Raadpleeg voor de meest recente lijst met beschikbare standaard XDM-veldgroepen de officiële XDM-opslagplaats. U kunt ook naar de handleiding verwijzen op XDM-componenten verkennen als u liever bronnen in de gebruikersinterface weergeeft.

Gegevenstype data-type

Gegevenstypen worden op dezelfde manier als letterlijke basisvelden gebruikt als referentieveldtypen in klassen of schema's. Het belangrijkste verschil is dat gegevenstypen meerdere subvelden op dezelfde manier kunnen definiëren als veldgroepen. Het belangrijkste verschil tussen hen, is dat de gegevenstypes overal in een schema kunnen worden omvat door het als "gegevenstype"van een gebied toe te voegen. Veldgroepen zijn alleen compatibel met bepaalde klassen, maar gegevenstypen kunnen in elke bovenliggende klasse of veldgroep worden opgenomen.

Experience Platform biedt een aantal gangbare gegevenstypen als onderdeel van de Schema Registry ondersteuning van het gebruik van standaardpatronen voor het beschrijven van gemeenschappelijke gegevensstructuren. Dit wordt nader toegelicht in de Zelfstudies voor schema-registratie en wordt duidelijker wanneer u door de stappen loopt om gegevenstypen te definiëren.

De volgende schermafbeelding toont hoe gegevenstypen worden weergegeven in de interface van het platform. Een van de velden die door de Demographic Details veldgroep gebruikt "Object" gegevenstype, zoals aangegeven door de tekst na het verticale streepje (|) naast de veldnaam. Dit specifieke gegevenstype biedt verschillende subvelden die betrekking hebben op de naam van een individuele persoon, een constructie die opnieuw kan worden gebruikt voor andere velden waarin de naam van een persoon moet worden vastgelegd.

Voor de meest bijgewerkte lijst van beschikbare standaard XDM gegevenstypes, verwijs naar officiële XDM-opslagplaats. U kunt ook naar de handleiding verwijzen op XDM-componenten verkennen als u liever bronnen in de gebruikersinterface weergeeft.

Veld field

Een veld is de eenvoudigste bouwsteen van een schema. Velden bieden beperkingen met betrekking tot het type gegevens dat ze kunnen bevatten door een specifiek gegevenstype te definiëren. Deze basistypen definiëren één veld, terwijl de gegevenstypen Met de instelling die u eerder hebt genoemd, kunt u meerdere subvelden definiëren en dezelfde structuur voor meerdere velden opnieuw gebruiken in verschillende schema's. Zo, naast het bepalen van het "gegevenstype"van een gebied als één van de gegevenstypes die in de registratie worden bepaald, steunt het Experience Platform fundamentele scalaire types zoals:

De geldige waaiers van deze scalaire types kunnen verder tot bepaalde patronen, formaten, minimum/maximum, of vooraf bepaalde waarden worden beperkt. Gebruikend deze beperkingen, kan een brede waaier van specifiekere gebiedstypes worden vertegenwoordigd, die omvatten:

Compositievoorbeeld composition-example

De schema's worden gebouwd gebruikend een samenstellingsmodel en vertegenwoordigen het formaat en de structuur van gegevens die in moeten worden opgenomen Platform. Zoals eerder vermeld, zijn deze schema's samengesteld uit een klasse en nul of meer gebiedsgroepen die met die klasse compatibel zijn.

Bijvoorbeeld, zou een schema beschrijvend aankopen die bij een detailhandel worden gemaakt kunnen worden genoemd "Store Transactions". Het schema implementeert het XDM ExperienceEvent klasse gecombineerd met de norm Commerce veldgroep en een door de gebruiker gedefinieerde Product Info veldgroep.

Een ander schema dat websiteverkeer volgt zou " kunnen worden genoemdWeb Visits". Het implementeert ook de XDM ExperienceEvent , maar deze keer wordt de standaard Web veldgroep.

In het onderstaande diagram worden deze schema's en de velden weergegeven die door elke veldgroep worden bijgedragen. Het bevat ook twee schema's die op XDM Individual Profile klasse, inclusief "Loyalty Members" schema genoemd eerder in deze gids.

Samenvoegen union

Terwijl het Experience Platform u toestaat om schema's voor bepaalde gebruiksgevallen samen te stellen, staat het u ook toe om een "unie"van schema's voor een specifiek klassentype te zien. Het vorige diagram toont twee schema's die op de klasse XDM ExperienceEvent en twee schema's worden gebaseerd op XDM Individual Profile klasse. De samenvoeging, die hieronder wordt weergegeven, aggregeert de velden van alle schema's die dezelfde klasse delen (XDM ExperienceEvent en XDM Individual Profile, respectievelijk).

Door een schema in te schakelen voor gebruik met Real-Time Customer Profile, wordt het opgenomen in de unie voor dat klassentype. Profile levert robuuste, gecentraliseerde profielen van klantenattributen en een timestamped rekening van elke gebeurtenis die de klant over om het even welk systeem heeft geïntegreerd met Platform. Profile gebruikt de verenigingsmening om deze gegevens te vertegenwoordigen en een holistische mening van elke individuele klant te verstrekken.

Meer informatie over het werken met Profile, zie de Overzicht van het realtime klantprofiel.

Gegevensbestanden toewijzen aan XDM-schema's mapping-datafiles

Alle gegevensbestanden die in Experience Platform worden opgenomen moeten de structuur van een XDM-schema in acht nemen. Zie het document over het opmaken van gegevensbestanden om te voldoen aan XDM-hiërarchieën (inclusief voorbeeldbestanden) voor meer informatie over het opmaken van gegevensbestanden ETL-testtransformaties. Voor algemene informatie over het opnemen van gegevensbestanden in het Experience Platform raadpleegt u de overzicht van batch-opname.

Schema's voor extern publiek

Als u publiek van externe systemen in Platform brengt, moet u de volgende componenten gebruiken om hen in uw schema's te vangen:

Volgende stappen

Nu u de grondbeginselen van schemacompositie begrijpt, bent u bereid beginnen het onderzoeken en bouwend schema's gebruikend Schema Registry.

Raadpleeg de volgende documentatie voor informatie over de structuur van de twee belangrijkste XDM-klassen en hun veelgebruikte compatibele veldgroepen:

De Schema Registry wordt gebruikt om toegang te krijgen tot Schema Library in Adobe Experience Platform en biedt een gebruikersinterface en RESTful-API die toegang bieden tot alle beschikbare bibliotheekbronnen. De Schema Library Bevat de middelen van de Industrie die door Adobe, de middelen van de Leverancier door de partners van het Experience Platform worden bepaald, en klassen, gebiedsgroepen, gegevenstypes, en schema's worden bepaald die door leden van uw organisatie zijn samengesteld.

Als u wilt beginnen met het samenstellen van het schema met de gebruikersinterface, volgt u de Zelfstudie Schema-editor om het schema voor "Loyalty-leden" op te bouwen dat in dit document wordt vermeld.

Als u wilt beginnen met het Schema Registry API, begin door te lezen Handleiding voor ontwikkelaars van de API voor schemaregister. Nadat u de handleiding voor ontwikkelaars hebt gelezen, volgt u de stappen die in de zelfstudie worden beschreven op een schema maken met de API voor het schemaregister.

Bijlage

De volgende secties bevatten extra informatie betreffende de beginselen van schemacompositie.

Relatieve tabellen versus ingesloten objecten embedded

Wanneer het werken met relationele gegevensbestanden, impliceren de beste praktijken het normaliseren van gegevens, of het nemen van een entiteit en het verdelen van het in discrete stukken die dan over veelvoudige lijsten worden getoond. Om de gegevens als geheel te lezen of de entiteit bij te werken, lees en schrijf verrichtingen over vele individuele lijsten moeten worden gemaakt gebruikend JOIN.

Door ingebedde voorwerpen te gebruiken, kunnen de schema's XDM complexe gegevens direct vertegenwoordigen en het opslaan in op zichzelf staande documenten met een hiërarchische structuur. Één van de belangrijkste voordelen aan deze structuur is dat het u toestaat om de gegevens te vragen zonder het moeten de entiteit door dure verbindingen aan veelvoudige gedenormaliseerde lijsten reconstrueren. Er zijn geen harde beperkingen aan hoeveel niveaus uw schemahiërarchie kan zijn.

Schema's en grote gegevens big-data

Moderne digitale systemen genereren enorme hoeveelheden gedragssignalen (transactiegegevens, weblogbestanden, internet van dingen, weergave, enzovoort). Deze grote gegevens bieden buitengewone mogelijkheden om ervaringen te optimaliseren, maar zijn lastig te gebruiken vanwege de schaal en de verscheidenheid van de gegevens. Om waarde te kunnen halen uit de gegevens, moeten de structuur, indeling en definities ervan worden gestandaardiseerd, zodat deze consistent en efficiënt kunnen worden verwerkt.

De schema's lossen dit probleem op door gegevens toe te laten om uit veelvoudige bronnen worden geïntegreerd, door gemeenschappelijke structuren en definities worden gestandaardiseerd, en over oplossingen worden gedeeld. Dit staat verdere processen en de diensten toe om het even welk type van vraag te beantwoorden die van de gegevens wordt gesteld. Het verschuift van de traditionele benadering naar gegevensmodellering, waarbij alle vragen die over de gegevens moeten worden gesteld van tevoren bekend zijn, en de gegevens worden gemodelleerd om aan die verwachtingen te voldoen.

Objecten versus vrije-formuliervelden objects-v-freeform

Bij het ontwerpen van uw schema's moet u rekening houden met een aantal belangrijke factoren wanneer u objecten kiest op vrije-formuliervelden:

Objecten

Hieronder ziet u de voor- en nadelen van het gebruik van objecten op vrije-formuliervelden.

Pros:

Cons:

Velden met vrije vorm

De voor- en nadelen van het gebruik van vrije-formuliervelden op objecten worden hieronder weergegeven.

Pros:

Cons: