Hur är AEP-identitetsnamnutrymmen relaterade AAM datakällor?
I den här artikeln beskrivs korrelationen mellan AEP Identity Namespaces och AAM Data Sources. Alla AAM datakällor som skapas i AAM har ett passande AEP-identitetsnamnutrymme och om datakällan tas bort tas identitetsnamnutrymmet bort.
Beskrivning description
Miljö
- Adobe Experience Platform (AEP)
- Adobe Audience Manager (AAM)
Problem/symtom
Finns det någon relation mellan AAM datakällor och AEP-identitetsnamnutrymmen?
Upplösning resolution
Ja. De är relaterade på följande sätt.:
- Alla AAM datakällor för olika enheter som skapats i AAM sedan april 2019 har ett passande AEP-ID-namnutrymme som skapats med samma namn i samma Experience Cloud-organisation, även om Experience Cloud-organisationen inte licensierats för AEP.
- Alla AAM datakällor för olika enheter som skapades före april 2019 hade ett passande AEP-ID som skapades i april 2019.
- Alla AAM identitetsnamnutrymmen har en pekare till, men är inte, samma enhet som AAM motsvarigheter till datakällor för olika enheter. De är separata identiteter som refereras i samma rad i en uppslagstabell på Experience Edge.
- Endast AAM datakällor för olika enheter har en motsvarande ID-namnutrymme. Kakformsbaserade AAM datakällor gör det inte.
Här är några viktiga frågor att tänka på:
- Borttagningen av en AAM datakälla för olika enheter resulterar i att det tillhörande identitetsnamnutrymmet tas bort.
- Eventuella uppdateringar av AAM datakälla för olika enheter name eller integrationskod återspeglas INTE i AEP-namnutrymmets användargränssnitt.
- All integrationskod AAM olika enheter för datakällor som skapats efter april 2019 med specialtecken (till exempel ett bindestreck eller understreck) resulterar i en ny ID-namnutrymmessymbol som består av 3 versaler
- Identitetsnamnutrymmessymbolen ska matcha integreringskoden för AAM datakälla mellan enheter (även om den har specialtecken) OM AAM datakälla skapades föregående till april 2019 OCH integreringskoden har inte uppdaterats sedan dess.
Hur tillämpar man praktiskt taget denna information?
Om en befintlig AAM-implementering måste upprätthållas under en migrering till AEP-webben eller mobila SDK:er är det sätt på vilket användar- eller CRM-ID:n skickas till AAM (det som historiskt har gjorts via funktionen/metoden Ange användar-ID för ECID-identitetstjänsten) genom att ställa in SDK-identitetskarta med ID-namnutrymmessymbol som finns i AEP eller användargränssnittet för datainsamling och som motsvarar den aktuella AAM datakällan för olika enheter. Experience edge kommer att se identitetssymbolen, slå upp den medföljande AAM integreringskoden och sedan vidarebefordra datainsamlingen med rätt AAM integreringskod, vilket gör att den AAM datakällan för olika enheter kan fortsätta att samla in användar-ID:n för AAM användning med dessa ID:n.
Viktigt: AEP hanterar alla identiteter som skickas via identitetskartan i AEP Web SDK (eller på annat sätt) som identifierbara identiteter, även om de aktuella identitetsnamnutrymmena inte är kopplade till ett profilaktiverat XDM-fält. Detta kan vara problematiskt om ID:n som måste skickas till AAM inte är ID:n på individ- eller profilnivå. Detta kan leda till att flera AEP-profiler slås samman/komprimeras till en om ID:t i fråga till exempel är ett hushåll-ID i stället för ett enskilt ID.
Användbart tips: Om det inte är klart vilken AAM datakälla mellan olika enheter som kan vara relaterad till ett givet AEP-identitetsnamnområde, anropar du AAM-API:t för en av de möjliga AAM datakällorna med detta API-anrop returnerar en JSON-nyttolast som innehåller customNamespaceCode fält. Värdet för det fältet ska matcha det som av AEP Identity Namespace pekar på den AAM datakällan.
Relaterad läsning:
Autentiserade tillstånd för AEP Web SDK i AAM: I den här artikeln behandlas problemet där enhets-ID:n/datakällor inte synkroniseras eller beter sig på samma sätt som innan du migrerade.