Hoe zijn AEP-naamruimten gerelateerd aan AAM gegevensbronnen
Dit artikel bespreekt de correlatie tussen AEP Identiteitsnaamruimten, AAM Gegevensbronnen, en de gegevensbronnen van de Attributen van de Klant die via de Dienst van de Kern van Mensen worden gecreeerd (die zelf speciale AAM gegevensbronnen beschikbaar aan alle klanten ongeacht de status van AAM Vergunning zijn). Om het delen van gegevens tussen AEP en het publiek van het Experience Cloud toe te laten gebruikend een SHA256 gehakt e-mailadres en een manier te verstrekken om identiteiten tot de gegevensbronnen van de Attributen van de AAM en van de Klant via de Groep van het Gebied van het Schema van de Kaart van de Identiteit over te gaan, moest een type van verbinding tussen AAM gegevensbronnen en de naamruimten van AEP worden gemaakt. Precies hoe die verbinding wordt gemaakt en of een AEP identiteitsnamespace voor de overeenkomstige AAM in kwestie werd gecreeerd hangt van af wanneer de AAM of de attributengegevensbron van de Klant werd gecreeerd.
Beschrijving
Milieu
- Adobe Experience Platform (AEP)
- Adobe Audience Manager (AAM)
- People Core Service (klantkenmerken)
Kwesties/Symptomen
Is er een verband tussen AAM (en Attribuut van de Klant) Gegevensbronnen en de Namespaces van de Identiteit AEP?
Resolutie
Ja. Deze zijn op de volgende manieren verwant.:
- Alle AAM gegevensbronnen voor andere apparaten die tussen april 2019 en februari 2024 in de gebruikersinterface van de People Core Service zijn gemaakt, hebben een overeenkomstige AEP-naamruimte die in de productiesandbox met dezelfde naam in hetzelfde Experience Cloud Org is gemaakt, zelfs als de Experience Cloud Org geen licentie voor AEP had.
- Voor alle AAM gegevensbronnen voor apparaatoverschrijdingen en klantkenmerken die vóór april 2019 zijn gemaakt, is in april 2019 de bijbehorende naamruimte voor AEP-identiteit gemaakt.
- Alle AAM dwars-apparaat en de gegevensbronnen van Attributen van de Klant die na Ffeb 2024 worden gecreeerd hebben geen corollary AEP Namespace van de Identiteit die voor hen wordt gecreeerd, maar hun herkenningstekens kunnen nog worden overgegaan tot AAM en de attributen van de Klant via de Groep van het Gebied van het Schema van de Kaart van de Identiteit. Hieronder vindt u aanvullende informatie.
- Om het even welke automatisch-geproduceerde identiteitsnamespaces hebben een wijzer aan maar zijn niet de zelfde entiteit zoals hun AAM dwars-apparaat of de gegevensbrontegenhangers van Attributen van de Klant. Het zijn afzonderlijke identiteiten waarnaar in dezelfde rij van een opzoektabel op de Experience Edge wordt verwezen.
- Alleen AAM gegevensbronnen van andere apparaten en klantkenmerken kunnen een naamruimte-tegenhanger hebben. Op cookie gebaseerde AAM gegevensbronnen doen dit niet.
Op grond van deze informatie zijn er enkele belangrijke punten waarop u zich bewust moet zijn:
- Het schrappen van een AAM cross-device of Customer Attribute gegevensbron met een corollary identities namespace zal in de schrapping van die overeenkomstige identiteitsnaamruimte resulteren.
- Om het even welke updates aan AAM dwars-apparaat of de gegevensbron van het Attribuut van de Klant naam of integratiecode zal NIET in een gecorollineerde AEP identiteit namespace UI worden weerspiegeld.
- Het naamruimtesymbool komt al dan niet overeen met de alias van de oudere klant of AAM integratiecode. Het symbool is te vinden op een van de manieren die in de volgende sectie worden vermeld.
hoe toepast men praktisch deze informatie?
Als een bestaande AAM of implementatie van de Attributen van de Klant tijdens een migratie aan het Web van AEP of Mobiele SDKs moet worden gehandhaafd, dan is de manier om de gebruiker of CRM IDs tot AAM en Attributen van de Klant over te gaan (wat historisch via de functie setCustomerIDs/methode van de ECID Identiteitsdienst werd gedaan) door de Identiteitskaart van SDK Kaartmet het met het symbool te plaatsen met het symbool van de 2} identiteitsnaamruimte die het symbool van 2} identificeert dat of identificeert dat of AAM of identificeert dat of Klantkenmerken gegevensbron. Het naamruimtesymbool voor identiteit kan op verschillende manieren worden gevonden:
- Gebruik AEP of de UI van de Inzameling van Gegevens om de identiteitsnaamruimte te vinden die met de AAM dwars-apparaat of gegevensbron van Attributen van de Klant in kwestie beantwoordt. Als dit niet onmiddellijk duidelijk is of de vereiste AEP identiteitsnaamruimte niet in identiteiten UI is, dan probeer een andere één van de hieronder opties.
- Voor degenen met een AAM vergunning, navigeer aan de Gegevensbronnen van de Gegevens van het Publiek
>binnen AAM UI. Klik in de desbetreffende gegevensbron en de waarde in het veld Namespace met grijswaarden is het te gebruiken identiteitssymbool. Alle gegevensbronnen van de attributengegevens van de Klant zullen ook in AAM UI zijn, zodat werkt deze methode ook voor degenen die zowel de Attributen van de Klant als AAM gebruiken. - Gebruik AAM API voor één van de potentiële AAM gegevensbronnen gebruikend deze API vraagom een nuttige lading terug te keren JSON die het
customNamespaceCodegebied bevat. De waarde van dat veld is het identiteitssymbool dat moet worden gebruikt. De zelfde API vraag kan worden gebruikt om het symbool te bepalen voor een gegevensbron van Attributen van de Klant te gebruiken. - Als geen van de bovenstaande opties werkt, omdat de naamruimte van de AEP-identiteit zich niet in de interface voor identiteiten bevindt of de organisatie geen licentie voor AAM heeft, neemt u contact op met AAM ondersteuning en vraagt u om het identiteitssymbool dat verwijst naar de gegevensbron van Kenmerken van de klant in kwestie.
Wanneer het juiste identiteitssymbool in de identiteitskaart is, zal de Ervaring Edge de slaan van gegevens aan Audience Manager (veronderstellend de Dienst van de Audience Manager op de gegevensstroom wordt toegelaten) doorsturen waar AAM het identiteitssymbool zal zien, omhoog de corollary AAM integratiecode of de alias van het Attribuut van de Klant zal kijken, dan de slag met de juiste AAM integratiecode of alias van het Attribuut van de Klant bijwerken, daardoor de AAM dwars-gegevensbron of van Kenmerk van de Klant om gebruikersidentiteitskaart voor de AAM en verder te verzamelen Gebruiksgevallen voor kenmerken.
Zorgen de juiste identiteiten gaan naar de juiste oplossing
Er zijn gevallen waarin de identiteiten die bedoeld zijn voor AAM en Customer Attributes wel en niet gebruikt zouden moeten worden voor AEP-gebruiksgevallen. Houd de volgende informatie en tips in gedachten wanneer u bepaalt welke identiteiten naar welke oplossingen moeten worden verzonden:
- AEP behandelt alle identiteiten die via het identiteitsoverzicht zijn doorgegeven en die ook een overeenkomstige AEP-identiteit hebben in de interface AEP-identiteiten, als stitchable-identiteiten, zelfs als de naamruimten in kwestie niet zijn gekoppeld aan een XDM-veld dat geschikt is voor profielen. Dit kan problematisch zijn als de id's die moeten worden doorgegeven aan AAM of klantkenmerken geen individuele id's/profielniveau zijn. Dit kan ertoe leiden dat meerdere AEP-profielen worden samengevoegd/samengevouwen als de id in kwestie bijvoorbeeld een huishoudelijke id is in plaats van een individuele id. Het gebruiken van de Grafiek van de Identiteit die Regelsverbindt kan ook met deze situatie helpen.
- Als de identiteit via de Identiteitskaart wordt overgegaan, maar die zelfde entiteit bestaat niet in AEP identiteiten UI, dan zal de ingang AEP een fout werpen tenzij er een andere identiteit duidelijk als Primair is.
- Als de gewenste functionaliteit AEP en AAM/klantenattributen moet hebben gebruiken de zelfde identiteit, maar geen identiteit AEP namespace is gecreeerd, dan kan men worden gecreeerd gebruikend het zelfde symbool van identiteitskaart namespace dat in AAM UI wordt gevonden (zie vorige sectie). Hierdoor kan één ID-vermelding het verzenden van de id naar AEP, AAM en Customer Attributes afhandelen. Houd er echter rekening mee dat deze wordt gebruikt als een naastID, zoals vermeld in het eerste opsommingsteken.
- Als de naamruimte AEP-identiteit zich in de gebruikersinterface van AEP-identiteiten bevindt en hetzelfde identiteitssymbool heeft als de gegevensset AAM en kenmerk van klant, is er geen ondersteunde manier om te voorkomen dat die identiteit naar AEP gaat.
Verwante Lezen:
Van het Web SDK van AEP Voor authentiek verklaarde Staten in AAM: Dit artikel bespreekt de kwestie waar dwars-apparaat IDs/gegevensbronnen niet synchroniseren of zich gedragen op de zelfde manier zoals alvorens u migreerde.