Identiteitsverwerking in de workflow voor doelactivering

Op deze pagina worden de bijzonderheden beschreven van de manier waarop identiteiten naar verschillende doeltypen worden geëxporteerd. U ziet dan hoe u kunt zoeken welke identiteiten afhankelijk van de bestemming beschikbaar zijn voor export.

Elke bestemming in de catalogus is lichtjes verschillend, zodat is er geen één-grootte-pasvorm-al opstelling over alle bestemmingen. Nochtans, zijn er een paar patronen die de opstelling van bestemmingen en hun identiteitsvereisten begeleiden, zoals die in de hieronder secties worden beschreven.

Bestandsgebaseerde doelen file-based

Voor bestandsgebaseerde doelen (bijvoorbeeld Amazon S3, SFTP, de meeste e-mailmarketing bestemmingen zoals Adobe Campaign, Oracle Eloqua, Salesforce Marketing Cloud), is de identiteitsopstelling in de meeste van deze bestemmingen open, betekenend dat u om het even welke identiteit in niet moet selecteren Kenmerken selecteren stap van de batchactiveringsworkflow.

Als u ervoor kiest id's toe te voegen aan uw geëxporteerde bestanden, moet u niet vergeten dat er slechts één identiteit uit het menu naamruimte identity kan worden geselecteerd in een exportbewerking. Wanneer u een identiteit selecteert om te exporteren, wordt deze automatisch geselecteerd als een mandatory, kenmerk en deduplicatie-sleutel.

Als tijdelijke oplossing kunt u meer identiteiten aan het exporteren toevoegen als deze als kenmerken in het Experience Platform zijn opgenomen. Zie onder een voorbeeld waarin het e-mailadres van het XDM-kenmerk is geselecteerd voor export, in aanvulling op de naamruimte identity Phone_E.164.

Een identiteit exporteren vanuit een identiteitskaart in plaats van een identiteit te exporteren als een XDM-kenmerk - de verschillen identity-map-or-attribute

Het aantal geëxporteerde records kan verschillen, afhankelijk van de vraag of u voor exportidentiteiten in het identiteitsoverzicht of identiteiten selecteert die als kenmerken in het Experience Platform zijn opgenomen. Beleid samenvoegen speelt ook een belangrijke rol in het aantal verslagen die worden uitgevoerd wanneer u identiteiten van de identiteitskaart selecteert.

Stel dat u uit twee verschillende datasets de volgende profielfragmenten hebt die worden samengevoegd in één klantprofiel:

Profielfragment één

Profielfragment twee

Het samengevoegde profiel ziet er als volgt uit:

Het exportgedrag is afhankelijk van de vraag of u IdentityMap: Email of xdm: personalEmail.address voor uitvoer.

Als een klant activeert IdentityMap: EmailEr staan twee records in het geëxporteerde bestand: een voor e-mail1 en een voor e-mail2.

Als een klant echter xdm: personalEmail.address, bevat de record alleen e-mail2, omdat het veld E-mailkenmerk alleen e-mail2 bevat. In deze situaties kunnen verschillende gebruiksgevallen worden opgelost waarbij u mogelijk alle e-mailadressen wilt activeren die in het bestand staan voor een klant, of alleen het meest recente e-mailadres dat in het bestand staat voor de klant.

Het wegnemen is dat het aantal records dat u exporteert, afhankelijk is van het gekozen samenvoegbeleid en of u identiteiten of kenmerken selecteert in het exporteren.

Op API gebaseerde streamingdoelen streaming-destinations

Op API gebaseerde streamingdoelen gebouwd met Destination SDK (bijvoorbeeld Facebook, Google Customer Match, Pinterest, Brazeen andere) ondersteunen alleen specifieke id's voor exporteren. Voor gedetailleerde informatie over de specifieke identiteiten die naar elke bestemming kunnen worden uitgevoerd, lees ondersteunde identiteiten in elke pagina van de bestemmingsdocumentatie (bijvoorbeeld, zie sectie met ondersteunde identiteiten in de Pinterest doelpagina).

Houd er echter rekening mee dat u over de flexibiliteit beschikt om gegevens uit een van beide privégrafieken of van kenmerken als identiteiten. Dit betekent dat u attributen XDM aan het identiteitsgebied kunt in kaart brengen dat door de bestemming wordt vereist. Zie hieronder een voorbeeld voor de Pinterest doel, waarbij het XDM-kenmerk personalEmail.address is toegewezen aan de vereiste Pinterest identiteit pinterest_audience.

Reclamebestemmingen die afhankelijk zijn van cookie-integratie van derden third-party-cookie-destinations

Reclamebestemmingen die afhankelijk zijn van cookies van derden (bijvoorbeeld: Google Ads, Google Ad Manager, Google DV360, Bing, The Trade Desk) vereist niet dat klanten id's selecteren in de activeringsworkflow. Voor deze bestemmingen, wanneer vestiging een activeringswerkschema, kijkt het Experience Platform automatisch omhoog de lijst van de identiteitsgelijke die door wordt geconstrueerd Experience Cloud ID service en exporteert u alle identiteiten die beschikbaar zijn voor een profiel en die door de bestemming worden ondersteund.

Voor deze doelen is een id-sync vereist via een van de Experience Cloud ID service of via Experience Platform Web SDK.

Als u Experience Platform Web SDK en de erfenis Experience Cloud ID service niet op de pagina wordt geïmplementeerd, dan moet u ervoor zorgen dat de gegevensstroom voor de website in kwestie is ingeschakeld zodat ID-synchronisatie van derden mogelijk is, zoals beschreven in het configureren, gegevensstroomdocumentatie.

Wanneer u een gegevensstroom configureert zoals wordt beschreven in de bovenstaande documentatie, moet u ervoor zorgen dat de Third Party ID Sync is ingeschakeld. De meeste klanten zouden de container_id veld leeg (standaard 0). U hoeft deze waarde alleen te wijzigen als uw implementatie van een oudere Audience Manager een specifieke container-id gebruikt (dit zou echter de grote minderheid van klanten zijn).

Enterprise-bestemmingen enterprise-destinations

Enterprise-bestemmingen (Amazon Kinesis, Azure Event Hubs, (HTTP API) vereisen geen specifieke id's in de gegevensexport, aangezien deze ontworpen zijn voor gebruik bij de integratie van bedrijven. Nochtans, kunt u identiteiten als attributen XDM of van de identiteitskaart uitvoeren, als u wenst. Een voorbeeld van geëxporteerde gegevens naar de HTTP-bestemming, waarin zowel de personalEmail.address XDM-kenmerk en de identiteiten ECID en email_lc_sha256 (gehasht e-mailadres) van het identiteitsoverzicht.

Aanpassingsdoelen personalization-destinations

Aanpassingsdoelen (of randdoelen) (bijvoorbeeld Adobe Target, Custom Personalization) hoeft u geen identiteit te selecteren in de activeringsworkflow, omdat de integratie een opgezocht profiel is. De client (Target, Web SDK, of anderen) vraagt de Edge en haalt de profielinformatie die het voor onsite verpersoonlijking nodig heeft.

Volgende stappen next-steps

Nadat u dit document hebt gelezen, weet u nu hoe u kunt achterhalen welke identiteiten worden ondersteund of vereist voor afzonderlijke doelen. U weet nu ook hoe identiteitsselectie voor elk bestemmingstype werkt.

Vervolgens kunt u lezen over welke exportinstellingen voor bestemmingen zijn gemeenschappelijk over bestemmingstypes, die op een individueel bestemmingsniveau door ontwikkelaars kunnen worden gevormd, en welke montages door gebruikers in het activeringswerkschema kunnen worden uitgegeven.

U kunt ook alle beschikbare doelen uitchecken in de catalogus.