Aanbevolen procedures voor gegevensmodellering
Experience Data Model (XDM) is het kernkader dat de gegevens van de klantenervaring door gemeenschappelijke structuren en definities voor gebruik in de stroomafwaartse diensten van Adobe Experience Platform te verstrekken gestandaardiseerd. Door zich aan de normen van XDM te houden, kunnen alle gegevens van de klantenervaring in een gemeenschappelijke vertegenwoordiging worden opgenomen en gebruikt om waardevolle inzichten van klantenacties te bereiken, klantenpubliek te bepalen, en klantenattributen voor verpersoonlijkingsdoeleinden uit te drukken.
Aangezien XDM uiterst veelzijdig en aanpasbaar door ontwerp is, is het belangrijk om beste praktijken voor gegevensmodellering te volgen wanneer het ontwerpen van uw schema's. Dit document behandelt de belangrijkste besluiten en overwegingen die u moet maken wanneer het in kaart brengen van uw gegevens van de klantenervaring aan XDM.
Aan de slag
Lees deze handleiding voordat u deze leest. XDM System, overzicht voor een inleiding op hoog niveau aan XDM en zijn rol binnen Experience Platform.
Aangezien deze gids zich uitsluitend op zeer belangrijke overwegingen betreffende schemaontwerp concentreert, wordt u sterk geadviseerd om te lezen grondbeginselen van de schemacompositie voor gedetailleerde uitleg van de afzonderlijke schema - elementen die in deze handleiding worden genoemd.
Overzicht van best practices summary
De aanbevolen aanpak voor het ontwerpen van uw gegevensmodel voor gebruik in Experience Platform kan als volgt worden samengevat:
- Begrijp de zaken van het bedrijfsgebruik voor uw gegevens.
- Identificeer de primaire gegevensbronnen die in moeten worden gebracht Platform om die gebruiksgevallen aan te pakken.
- Identificeer om het even welke secundaire gegevensbronnen die ook van belang kunnen zijn. Bijvoorbeeld, als momenteel slechts één bedrijfseenheid in uw organisatie in het uitvoeren van hun gegevens geinteresseerd is PlatformEen vergelijkbare bedrijfseenheid zou ook geïnteresseerd kunnen zijn in het verstrekken van vergelijkbare gegevens in de toekomst. Het overwegen van deze secundaire bronnen helpt het gegevensmodel over uw volledige organisatie te standaardiseren.
- Creeer een diagram van de entiteitverhouding op hoog niveau (ERD) voor de gegevensbronnen die zijn geïdentificeerd.
- Zet het ERD op hoog niveau om in een Platform-centric ERD (inclusief profielen, Experience Events en lookup entities).
De stappen met betrekking tot het identificeren van de toepasselijke gegevensbronnen die worden vereist om uw zaken van het bedrijfsgebruik uit te voeren variëren van organisatie tot organisatie. Hoewel de overige secties in dit document zich richten op de laatste stappen voor het organiseren en samenstellen van een ERD nadat de gegevensbronnen zijn geïdentificeerd, kunnen de toelichtingen in de verschillende componenten van het diagram uw beslissingen over welke van uw gegevensbronnen moeten worden gemigreerd naar Platform.
Een ERD op hoog niveau maken create-an-erd
Zodra u de gegevensbronnen hebt bepaald die u in wilt brengen Platform, maakt u een ERD op hoog niveau om het proces te begeleiden waarbij uw gegevens worden toegewezen aan XDM-schema's.
In het onderstaande voorbeeld wordt een vereenvoudigde ERD voorgesteld voor een bedrijf dat gegevens in Platform. Het diagram benadrukt de essentiële entiteiten die in klassen XDM, met inbegrip van klantenrekeningen, hotels, adressen, en verscheidene gemeenschappelijke e-commercegebeurtenissen zouden moeten worden gesorteerd.
Entiteiten sorteren in profiel-, zoekopdracht- en gebeurteniscategorieën sort-entities
Als u eenmaal een Europese beoordelingsruimte hebt gecreëerd om de essentiële entiteiten te identificeren die u in Platform, moeten deze entiteiten worden gesorteerd in profiel-, zoekopdracht- en gebeurteniscategorieën:
Overwegingen bij het sorteren van entiteiten considerations
In de volgende secties vindt u meer informatie over het sorteren van uw entiteiten in de bovenstaande categorieën.
Meerdere en onveranderlijke gegevens mutable-and-immutable-data
Een primaire manier om te sorteren tussen entiteitscategorieën is of de gegevens die worden vastgelegd, veranderbaar zijn of niet.
Kenmerken die bij profielen of opzoekentiteiten horen, zijn doorgaans veranderbaar. De voorkeuren van een klant kunnen bijvoorbeeld in de loop der tijd veranderen en de parameters van een abonnementsplan kunnen afhankelijk van de markttendensen worden bijgewerkt.
Gebeurtenisgegevens zijn daarentegen doorgaans onveranderlijk. Aangezien gebeurtenissen aan een specifieke tijdstempel zijn gekoppeld, verandert de "systeemmomentopname" die een gebeurtenis biedt, niet. Een gebeurtenis kan bijvoorbeeld de voorkeuren van een klant vastleggen wanneer een klant een winkelwagentje uitcheckt en wordt niet gewijzigd, zelfs niet als de voorkeuren van de klant later veranderen. Gebeurtenisgegevens kunnen niet worden gewijzigd nadat deze zijn opgenomen.
Om samen te vatten, bevatten de profielen en de raadplegingsentiteiten veranderlijke attributen en vertegenwoordigen de recentste informatie over de onderwerpen zij vangen, terwijl de gebeurtenissen onveranderlijke verslagen van het systeem op een specifiek tijdstip zijn.
Klantkenmerken customer-attributes
Als een entiteit kenmerken bevat die betrekking hebben op een individuele klant, is het zeer waarschijnlijk een profielentiteit. Voorbeelden van klantkenmerken zijn:
- Persoonlijke gegevens zoals naam, geboortedatum, geslacht en account-id(s).
- Locatiegegevens zoals adressen en GPS-gegevens.
- Contactgegevens zoals telefoonnummers en e-mailadressen.
Gegevens bijhouden over een bepaalde tijd track-data
Als u wilt analyseren hoe bepaalde kenmerken binnen een entiteit in de loop der tijd veranderen, is het waarschijnlijk een gebeurtenisentiteit. Bijvoorbeeld, kan het toevoegen van productpunten aan een karretje als toe:voegen-aan-kartgebeurtenissen in worden gevolgd Platform:
Gebruiksgevallen voor segmentatie segmentation-use-cases
Wanneer het categoriseren van uw entiteiten, is het belangrijk om over het publiek te denken u kunt willen bouwen om uw bijzondere zaken van het bedrijfsgebruik te richten.
Een bedrijf wil bijvoorbeeld alle "Gold" of "Platinum" leden van zijn loyaliteitsprogramma kennen die het afgelopen jaar meer dan vijf aankopen hebben gedaan. Op basis van deze segmentatielogica kunnen de volgende conclusies worden getrokken met betrekking tot de wijze waarop relevante entiteiten moeten worden vertegenwoordigd:
- "Goud" en "Platinum" staan voor de status van loyaliteit die van toepassing is op een individuele klant. Aangezien de segmentatielogica slechts met de huidige loyaliteitsstatus van klanten betrekking heeft, kunnen deze gegevens als deel van een profielschema worden gemodelleerd. Als u veranderingen in loyaliteitsstatus in tijd wilt volgen, kon u een extra gebeurtenisschema voor de veranderingen van de loyaliteitsstatus ook tot stand brengen.
- Aankopen zijn gebeurtenissen die zich op een bepaald moment voordoen en de segmentatielogica heeft betrekking op aankoopgebeurtenissen binnen een opgegeven tijdvenster. Deze gegevens moeten daarom als een gebeurtenisschema worden gemodelleerd.
Gebruiksgevallen activeren activation-use-cases
Naast overwegingen met betrekking tot gevallen van segmentatiegebruik, zou u ook de activeringsgebruiksgevallen voor die doelgroepen moeten herzien om extra relevante attributen te identificeren.
Een bedrijf heeft bijvoorbeeld een publiek gemaakt op basis van de regel dat country = US. Wanneer het bedrijf dat publiek vervolgens activeert naar bepaalde downstreamdoelen, wil het alle geëxporteerde profielen filteren op basis van de thuisstaat. Daarom state moet ook worden vastgelegd in de toepasselijke profielentiteit.
Geaggregeerde waarden aggregated-values
Op basis van het gebruiksgeval en de granulariteit van uw gegevens moet u bepalen of bepaalde waarden vooraf moeten worden geaggregeerd voordat ze in een profiel of gebeurtenisentiteit worden opgenomen.
Een bedrijf wil bijvoorbeeld een publiek maken op basis van het aantal winkels. U kunt ervoor kiezen deze gegevens op te nemen met de laagste granulariteit door elke aanschafgebeurtenis met een tijdstempel op te nemen als een eigen entiteit. Hierdoor kan het aantal opgenomen gebeurtenissen echter soms exponentieel toenemen. Als u het aantal opgenomen gebeurtenissen wilt verminderen, kunt u desgewenst een samengevoegde waarde maken numberOfPurchases gedurende een lange periode van een week of maand. Andere statistische functies zoals MIN en MAX kunnen ook op deze situaties van toepassing zijn.
Kardinaal cardinality
De in uw ERD vastgestelde randvoorwaarden kunnen ook aanwijzingen geven over de manier waarop u uw entiteiten kunt indelen. Als er een een-op-veel relatie is tussen twee entiteiten, zal de entiteit die de "velen"vertegenwoordigt waarschijnlijk een gebeurtenisentiteit zijn. Er zijn echter ook gevallen waarin "veel" een set opzoekentiteiten is die als een array binnen een profielentiteit worden opgegeven.
In de volgende tabel worden enkele gemeenschappelijke entiteitsrelaties en de categorieën beschreven die daaruit kunnen worden afgeleid:
Pros en cons van verschillende entiteitsklassen pros-and-cons
Hoewel het vorige gedeelte enkele algemene richtlijnen bevatte om te bepalen hoe u uw entiteiten kunt indelen, is het belangrijk te begrijpen dat er vaak voor- en nadelen zijn bij het kiezen van een categorie entiteiten in plaats van een andere categorie. In het volgende casestudy ziet u hoe u in deze situaties rekening kunt houden met uw opties.
Een bedrijf volgt actieve abonnementen voor hun klanten, waar één klant vele abonnementen kan hebben. Het bedrijf wil ook abonnementen voor segmentgebruiksgevallen, zoals het vinden van alle gebruikers met actieve abonnementen omvatten.
In dit scenario, heeft het bedrijf twee potentiële opties om de abonnementen van een klant in hun gegevensmodel te vertegenwoordigen:
Aanpak 1: Profielkenmerken gebruiken profile-approach
De eerste benadering zou zijn om een array van abonnementen als attributen binnen de profielentiteit voor Klanten te omvatten. Objecten in deze array bevatten velden voor category, status, planName, startDate, en endDate.
Pros
- Segmentering is haalbaar voor het beoogde gebruik.
- In het schema blijven alleen de meest recente abonnementsrecords voor een klant behouden.
Cons
- De volledige array moet worden aangepast telkens wanneer er wijzigingen optreden in een veld in de array.
- Als verschillende gegevensbronnen of bedrijfseenheden gegevens in de array invoeren, wordt het lastig om de meest recente bijgewerkte array te synchroniseren over alle kanalen.
Aanpak 2: Gebeurtenisentiteiten gebruiken event-approach
De tweede benadering zou gebeurtenisschema's moeten gebruiken om abonnementen te vertegenwoordigen. Dit betekent dat u dezelfde abonnementsvelden als de eerste aanpak moet invoeren, plus een abonnement-id, een klant-id en een tijdstempel van wanneer de abonnementsgebeurtenis heeft plaatsgevonden.
Pros
- De segmentatieregels kunnen flexibeler zijn (zoals het vinden van alle klanten die hun abonnementen in de laatste 30 dagen veranderden).
- Wanneer de abonnementsstatus van een klant verandert, hoeft u niet langer een lange, mogelijk complexe array bij te werken binnen de profielkenmerken van de klant. Dit is vooral nuttig als de gelijktijdige veranderingen in de abonnementenlijst van de klant van veelvoudige bronnen voorkomen.
Cons
- De segmentatie wordt complexer voor het originele voorgenomen gebruiksgeval (identificerend de status van de recentste abonnementen van klanten). Het publiek heeft nu extra logica nodig om de laatste abonnementsgebeurtenis voor een klant te markeren om zijn status te controleren.
- Gebeurtenissen hebben een hoger risico om automatisch te vervallen en te worden gewist uit de profielopslag. Zie de handleiding op Verlopen van gebeurtenissen beleven voor meer informatie .
Schema's maken op basis van uw gecategoriseerde entiteiten schemas-for-categorized-entities
Nadat u de entiteiten hebt gesorteerd in profiel-, opzoekfunctie- en gebeurteniscategorieën, kunt u beginnen met het omzetten van uw gegevensmodel in XDM-schema's. Voor demonstratiedoeleinden is het eerder getoonde model van voorbeeldgegevens in aangewezen categorieën in het volgende diagram gesorteerd:
De categorie waarop een entiteit is gesorteerd, moet de XDM-klasse bepalen waarop u het schema baseert. Herhaal dit:
- Profielentiteiten moeten de opdracht XDM Individual Profile klasse.
- Gebeurtenisentiteiten moeten de XDM ExperienceEvent klasse.
- Bij opzoeken moeten entiteiten aangepaste XDM-klassen gebruiken die door uw organisatie zijn gedefinieerd. Profiel- en gebeurtenisentiteiten kunnen dan via schemarelaties verwijzen naar deze opzoekentiteiten.
LoyaltyAccount voorwerp om de aangewezen loyaliteitsgebieden voor elke klant te bevatten. Als de relatie echter één op vele is, kan de entiteit die de "vele"vertegenwoordigt door een afzonderlijk schema of een serie van profielattributen, afhankelijk van zijn ingewikkeldheid worden vertegenwoordigd.De onderstaande secties bieden algemene richtlijnen voor het samenstellen van schema's op basis van uw ERD.
Een iteratieve modelleringsaanpak hanteren iterative-modeling
De regels voor schemaontwikkeling bepalen dat alleen niet-destructieve wijzigingen in schema's kunnen worden aangebracht nadat ze zijn geïmplementeerd. Met andere woorden, wanneer u een veld aan een schema toevoegt en er gegevens tegen dat veld zijn ingevoerd, kan het veld niet meer worden verwijderd. Daarom is het van essentieel belang om bij de eerste opzet van uw schema's een herhalende modelleringsaanpak te volgen, te beginnen met een vereenvoudigde implementatie die in de loop der tijd steeds complexer wordt.
Als u niet zeker bent of een bepaald gebied noodzakelijk is om in een schema te omvatten, is de beste praktijken het uit te sluiten. Als later wordt bepaald dat het veld nodig is, kan dit altijd worden toegevoegd in de volgende versie van het schema.
Identiteitsvelden identity-fields
In Experience Platform, worden de gebieden XDM duidelijk als identiteiten gebruikt om informatie over individuele klanten te verbinden die uit veelvoudige gegevensbronnen komen. Hoewel een schema meerdere velden kan hebben die zijn gemarkeerd als identiteiten, moet één primaire identiteit worden gedefinieerd om het schema in te schakelen Real-Time Customer Profile. Zie de sectie over identiteitsvelden in de grondbeginselen van schemacompositie voor meer gedetailleerde informatie over het gebruiksgeval van deze gebieden.
Wanneer het ontwerpen van uw schema's, zijn om het even welke primaire sleutels in uw relationele gegevensbestandlijsten waarschijnlijk kandidaten voor primaire identiteiten. Andere voorbeelden van toepasselijke identiteitsvelden zijn e-mailadressen van klanten, telefoonnummers, account-id's en ECID.
Toepassingsschema-veldgroepen Adoben adobe-application-schema-field-groups
Experience Platform verstrekt verscheidene uit-van-de-doos groepen van het XDM- schemagebied voor het vangen van gegevens met betrekking tot de volgende toepassingen van de Adobe:
- Adobe Analytics
- Adobe Audience Manager
- Adobe Campaign
- Adobe Target
U kunt bijvoorbeeld de opdracht Adobe Analytics ExperienceEvent Template veldgroep naar kaart Analytics-specific fields to your XDM schema's. Afhankelijk van de toepassingen van de Adobe u met werkt, zou u deze Adobe-Geleide gebiedsgroepen in uw schema's moeten gebruiken.
Toepassingsveldgroepen van de Adobe wijzen automatisch een primaire standaardidentiteit toe door het gebruik van identityMap veld, dat een door het systeem gegenereerd, alleen-lezen object is dat standaardidentiteitswaarden voor een individuele klant toewijst.
Voor Adobe Analytics is ECID de primaire standaardidentiteit. Als een klant geen ECID-waarde opgeeft, wordt de primaire identiteit standaard ingesteld op AID.
Velden voor gegevensvalidatie data-validation-fields
Wanneer u gegevens in het gegevenspeer opneemt, wordt de gegevensbevestiging slechts afgedwongen voor beperkte gebieden. Als u een bepaald veld tijdens een batch-opname wilt valideren, moet u het veld markeren als beperkt in het XDM-schema. Om te voorkomen dat slechte gegevens in Platform worden opgenomen, wordt u aangeraden de criteria voor validatie op veldniveau te definiëren wanneer u uw schema's maakt.
Als u beperkingen voor een bepaald veld wilt instellen, selecteert u het veld in de Schema-editor om het dialoogvenster Field properties zijbalk. Zie de documentatie op type-specifieke veldeigenschappen voor een exacte beschrijving van de beschikbare velden.
Tips om de gegevensintegriteit te behouden data-integrity-tips
Hieronder volgt een verzameling suggesties voor het behoud van gegevensintegriteit wanneer u een schema maakt.
- Denk aan primaire identiteiten: Voor Adobe-producten zoals web SDK, mobiele SDK, Adobe Analytics en Adobe Journey Optimizer wordt de opdracht
identityMapVeld fungeert vaak als primaire identiteit. Wijs geen extra velden aan als primaire identiteiten voor dat schema. - Vermijd gebruik
_idals identiteit: gebruik de_idveld in Experience Event schema's als een identiteit. Het is bedoeld voor een unieke registratie, niet voor gebruik als identiteit. - Lengtebeperkingen instellen: Het wordt aanbevolen minimale en maximale lengte in te stellen voor velden die zijn gemarkeerd als identiteiten. Er wordt een waarschuwing weergegeven als u een aangepaste naamruimte wilt toewijzen aan een identiteitsveld zonder te voldoen aan de minimale en maximale lengte. Deze beperkingen helpen consistentie en gegevenskwaliteit te behouden.
- Patronen toepassen op consistente waarden: Als uw identiteitswaarden een specifiek patroon volgen, zou u moeten gebruiken Pattern instellen om deze beperking af te dwingen. Deze instelling kan regels bevatten zoals alleen cijfers, hoofdletters of kleine letters of specifieke tekencombinaties. Gebruik reguliere expressies die overeenkomen met patronen in de tekenreeksen.
- Limiet voor eVars in analyseschema's: Een analyseschema moet normaal gesproken slechts één eVar hebben die als een identiteit is opgegeven. Als u meer dan één eVar als identiteit wilt gebruiken, moet u controleren of de gegevensstructuur kan worden geoptimaliseerd.
- De unieke kenmerken van een geselecteerd veld garanderen: Het gekozen veld moet uniek zijn in vergelijking met de primaire identiteit in het schema. Als dit niet het geval is, merk het dan niet als een identiteit. Als bijvoorbeeld meerdere klanten hetzelfde e-mailadres kunnen opgeven, is die naamruimte geen geschikte identiteit. Dit beginsel is ook van toepassing op andere naamruimten zoals telefoonnummers.
- Beperkt triggerwaarschuwingen voor aangepaste naamruimtevelden: Stel beperkingen in om een waarschuwing te activeren wanneer een schemaveld wordt gemarkeerd met een aangepaste naamruimte zonder de minimale en maximale lengte op te geven. De waarschuwing dient als een belangrijke waarschuwing voor het handhaven van gegevensintegriteit. Zie de type-specifieke veldeigenschappen documentatie voor informatie over hoe te om beperkingen op een bepaald gebied te plaatsen.
Volgende stappen
In dit document worden de algemene richtlijnen en aanbevolen procedures voor het ontwerpen van uw gegevensmodel voor Experience Platform besproken. Samenvatten:
- Gebruik een top-down benadering door uw gegevenslijsten in profiel, raadpleging, en gebeurteniscategorieën te sorteren alvorens uw schema's te construeren.
- Er zijn vaak meerdere benaderingen en opties als het gaat om het ontwerpen van schema's voor verschillende doeleinden.
- Uw gegevensmodel zou uw zaken van het bedrijfsgebruik zoals segmentatie of de analyse van de klantenreis moeten steunen.
- Maak uw schema's zo eenvoudig mogelijk, en voeg slechts nieuwe gebieden toe wanneer absoluut noodzakelijk.
Als u klaar bent, raadpleegt u de zelfstudie het creëren van een schema in UI voor geleidelijke instructies op hoe te om een schema tot stand te brengen, wijs de aangewezen klasse voor de entiteit toe, en voeg gebieden toe om uw gegevens aan in kaart te brengen.