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 Platform wordt gebruikt, zie het XDM overzicht van het Systeem.

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 ingebedde voorwerpenen grote gegevensin het bijlage aan dit document voor meer informatie over hoe XDM dit verwezenlijkt.

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, ook wel XDM System genoemd, vergemakkelijkt workflows op basis van schema's en omvat de Schema Registry , Schema Editor , schema-metagegevens en het serviceconsumptiepatroon. Zie het XDM overzicht van het Systeemvoor 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 bevatten de verslag als de tijdreeksenschema's 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. Op gegevensopname, worden de gegevens in die gebieden opgenomen in "Identity Graph"voor dat individu. De grafiekgegevens kunnen dan door Real-Time Customer Profile en andere diensten van het Experience Platform worden betreden om een geneutraliseerde mening van elke individuele klant te verstrekken.

Velden die algemeen als "Identity"worden gemerkt omvatten: e-mailadres, telefoonaantal, Experience Cloud ID (ECID), identiteitskaart van CRM, of andere unieke gebieden van identiteitskaart Overweeg om het even welke unieke herkenningstekens specifiek voor uw organisatie, aangezien zij ook goede "Identity"gebieden kunnen zijn.

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. Meer over leren hoe de identiteitsinformatie u kan helpen digitale ervaringen aan uw klanten leveren, zie het overzicht van de Dienst van de Identiteit. Zie het gegevens modellerend beste praktijkdocument voor uiteinden op het gebruik van identiteiten wanneer het creëren 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 van 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 samen opslaan (zoals Airship of Adobe Audience Manager). Bovendien worden de identiteitskaarten vereist als u Adobe Experience Platform Mobile SDKgebruikt.

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, vertegenwoordigt elke sleutel in het identityMap -object een naamruimte voor de identiteit. De waarde voor elke sleutel is een serie van voorwerpen, die de identiteitswaarden (id) voor respectieve namespace vertegenwoordigen. Verwijs naar de Identity Service documentatie voor a lijst van standaardidentiteitsnamespaceserkend door de toepassingen van de Adobe.

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, wordt het breken veranderingen niet gesteund.

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

* verwijs naar de sectie hieronder voor belangrijke overwegingen betreffende het plaatsen van nieuwe vereiste gebieden.

Vereiste velden

De individuele schemagebieden kunnen zoals vereistworden gemerkt, zo betekent het dat om het even welke ingebedde verslagen gegevens op die gebieden moeten bevatten om bevestiging over te gaan. 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 Service en 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 Ingestie van Gegevens van Adobe Experience Platformvoor 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 te steunen.

De schema's worden samengesteld gebruikend de volgende formule:

Klasse + de Groef&amp van het Gebied van het Schema;ast; = 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 besproken meer in detail 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 downstream-platformprocessen. 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).

Voor de meest bijgewerkte lijst van beschikbare standaardXDM klassen, verwijs naar de officiële bewaarplaats XDM. Alternatief, kunt u naar de gids verwijzen bij het onderzoeken van componenten XDMals u verkiest om middelen in UI te bekijken.

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.

Bijvoorbeeld, om details zoals "First Name"en "Home Address"voor uw "Loyalty Members"schema te vangen, 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. Één enkele gebiedsgroep (Demographic Details) wordt toegevoegd aan een schema in dit voorbeeld, dat een groepering van gebieden aan de structuur van het schema verstrekt.

Voor de meest bijgewerkte lijst van beschikbare standaard XDM gebiedsgroepen, verwijs naar de officiële XDM bewaarplaats. Alternatief, kunt u naar de gids verwijzen bij het onderzoeken van componenten XDMals u verkiest om middelen in UI te bekijken.

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 voor ondersteuning van het gebruik van standaardpatronen voor het beschrijven van algemene gegevensstructuren. Dit wordt verklaard meer in detail in de leerprogramma's van de Registratie van het Schemaen zal duidelijker worden aangezien u door de stappen loopt om gegevenstypes te bepalen.

De volgende schermafbeelding toont hoe gegevenstypen worden weergegeven in de interface van het platform. Een van de velden in de veldgroep Demographic Details gebruikt het gegevenstype Object , zoals wordt aangegeven door de tekst na het verticale streepje (| ) naast de naam van het veld. 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 de officiële XDM bewaarplaats. Alternatief, kunt u naar de gids verwijzen bij het onderzoeken van componenten XDMals u verkiest om middelen in UI te bekijken.

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 basisgegevenstypes bepalen één enkel gebied, terwijl de eerder genoemde gegevenstypesu toestaan om veelvoudige subfields te bepalen en de zelfde multi-gebiedstructuur door diverse schema's opnieuw te gebruiken. 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

Schema's zijn gemaakt met behulp van een compositiemodel en vertegenwoordigen de indeling en structuur van gegevens die in Platform moeten worden opgenomen. 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 "Store Transactions"kunnen worden genoemd. Het schema implementeert de klasse XDM ExperienceEvent in combinatie met de standaard Commerce veldgroep en een door de gebruiker gedefinieerde Product Info veldgroep.

Een ander schema dat websiteverkeer volgt zou "Web Visits"kunnen worden genoemd. De klasse XDM ExperienceEvent wordt ook geïmplementeerd, maar deze keer wordt de standaardveldgroep van Web gecombineerd.

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 de XDM Individual Profile klasse worden gebaseerd, met inbegrip van het "Loyalty Members"schema dat eerder in deze gids wordt vermeld.

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. In het vorige diagram worden twee schema's weergegeven op basis van de klasse XDM ExperienceEvent en twee schema's op basis van de klasse XDM Individual Profile . De samenvoeging, die hieronder wordt weergegeven, aggregeert de velden van alle schema's die dezelfde klasse delen (XDM ExperienceEvent respectievelijk XDM Individual Profile ).

Wanneer u een schema inschakelt voor gebruik met Real-Time Customer Profile , wordt dit opgenomen in de union voor dat klassetype. Profile biedt robuuste, gecentraliseerde profielen van klantkenmerken en een tijdstempelaccount voor elke gebeurtenis die de klant heeft gehad in een systeem dat is geïntegreerd met Platform . Profile gebruikt de verenigingsmening om deze gegevens te vertegenwoordigen en een holistische mening van elke individuele klant te verstrekken.

Voor meer informatie bij het werken met Profile, zie het Real-Time overzicht van het Profiel van de Klant.

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. Voor meer informatie over hoe te om gegevensbestanden te formatteren om aan hiërarchieën XDM (met inbegrip van steekproefdossiers) te voldoen, zie het document op transformaties van steekproefETL. Voor algemene informatie over het opnemen van gegevensbestanden in Experience Platform, zie het overzicht van de partijopname.

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 van en het bouwen van 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:

Schema Registry wordt gebruikt om Schema Library binnen Adobe Experience Platform te openen, en verstrekt een gebruikersinterface en RESTful API waarvan alle beschikbare bibliotheekmiddelen toegankelijk zijn. Schema Library bevat de middelen van de Industrie die door Adobe, de middelen van de Leverancier door partners van het Experience Platform worden bepaald, en klassen, gebiedsgroepen, gegevenstypes, en schema's worden bepaald die door leden van uw organisatie zijn samengesteld die.

Beginnen samenstellend schema gebruikend UI, volg samen met het leerprogramma van de Redacteur van het Schemaom het schema van de "Leden van de Loyaliteit"te bouwen dat door dit document wordt vermeld.

Beginnen gebruikend Schema Registry API, begin door de gids van de ontwikkelaar van de Registratie API van het Schema te lezen. Na het lezen van de ontwikkelaarsgids, volg de stappen die in het leerprogramma worden geschetst op creërend een schema gebruikend de Registratie API van het Schema.

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:

Kons:

Velden met vrije vorm

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

Pros:

Kons: