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 catalogusis lichtjes verschillend, zodat is er geen one-size-past-alle 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 op dossier-gebaseerde bestemmingen(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 niet wordt vereist om enige identiteit in de Uitgezochte attributenstap van het werkschema van de partijactivering te selecteren.

Als u verkiest om identiteiten aan uw dossieruitvoer toe te voegen, merk op dat slechts één enkele identiteit van identiteit namespacein de uitvoer kan worden geselecteerd. Wanneer u een identiteit voor de uitvoer selecteert, wordt het automatisch geselecteerd als a verplichte attributenen deduplicatietoets.

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, naast de naamruimte voor identiteiten 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 van de Fusiespeelt 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:

fragment van het Profiel één

fragment van het Profiel twee

Het samengevoegde profiel ziet er als volgt uit:

Het exportgedrag is anders, afhankelijk van de vraag of u IdentityMap: Email of xdm: personalEmail.address selecteert voor exporteren.

Als een klant IdentityMap: Email activeert, bevat het geëxporteerde bestand twee records: een voor e-mail1 en een voor e-mail2.

Als een klant echter xdm: personalEmail.address activeert, is alleen email2 aanwezig in de record, aangezien het veld E-mailkenmerk alleen email2 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 die bestemmingenmet Destination SDK(bijvoorbeeld Facebook, Google Customer Match, Pinterest, Braze, en anderen) wordt gebouwd steunen slechts specifieke IDs voor de uitvoer. Voor gedetailleerde informatie over de specifieke identiteiten die naar elke bestemming kunnen worden uitgevoerd, lees de gesteunde identiteiten sectie in elke pagina van de bestemmingsdocumentatie (bijvoorbeeld, zie de gesteunde identiteitssectiein de Pinterest bestemmingspagina).

Nota, echter, dat u de flexibiliteit hebt om gegevens van of privé grafiekenof van attributen als identiteiten te gebruiken. Dit betekent dat u attributen XDM aan het identiteitsgebied kunt in kaart brengen dat door de bestemming wordt vereist. Zie onder een voorbeeld voor het doel Pinterest , waarbij het XDM-kenmerk personalEmail.address wordt toegewezen aan de vereiste Pinterest identity pinterest_audience .

Advertising-bestemmingen die afhankelijk zijn van integratie met cookies van derden third-party-cookie-destinations

Advertising-doelen die afhankelijk zijn van cookies van derden (bijvoorbeeld: Google Ads, Google Ad Manager, Google DV360, Bing, The Trade Desk), vereisen niet dat klanten id's selecteren in de activeringsworkflow. Voor deze bestemmingen, wanneer vestiging een activeringswerkschema, zoekt het Experience Platform automatisch de lijst van de identiteitsgelijke die door Experience Cloud ID service wordt geconstrueerden voert alle identiteiten uit die voor een profiel beschikbaar zijn en door de bestemming worden gesteund.

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

Als u Experience Platform Web SDK gebruikt en erfenis Experience Cloud ID service niet op de pagina wordt uitgevoerd, dan moet u ervoor zorgen dat de gegevensstroom voor de website in kwestie wordt toegelaten om voor de synchronisatie van identiteitskaart van de Derde toe te staan, zoals die in wordt geschetst vormt datastream documentatie.

Wanneer u een gegevensstroom configureert zoals wordt beschreven in de bovenstaande documentatie, moet u ervoor zorgen dat de schuifregelaar Third Party ID Sync is ingeschakeld. De meeste klanten zouden het veld container_id leeg laten (standaard ingesteld op 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

de bestemmingen van de Onderneming(Amazon Kinesis, Azure Event Hubs, HTTP API) vereisen geen specifieke IDs in de gegevensuitvoer, aangezien deze voor de gebruiksgevallen van de ondernemingsintegratie worden ontworpen. Nochtans, kunt u identiteiten als attributen XDM of van de identiteitskaart uitvoeren, als u wenst. Bekijk een voorbeeld van uitgevoerde gegevens aan de bestemming van HTTP, die zowel het personalEmail.address attribuut XDM, als de identiteiten ECID en email_lc_sha256 (gehakt e-mailadres) van de identiteitskaart omvat.

Personalization-bestemmingen personalization-destinations

Personalization (of rand) bestemmingen(bijvoorbeeld: Adobe Target, Custom Personalization) vereisen geen identiteitsselectie in het activeringswerkschema, aangezien de integratie een profielraadpleging is. De client (Target, Web SDK of anderen) vraagt naar de Edge en haalt de profielgegevens op die de client nodig heeft voor on-site personalisatie.

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.

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

U kunt alle beschikbare bestemmingen in de catalogusook controleren.