Spårningsytorna i Adobe Experience Cloud

En „enskild" Adobe-installation utgör, ur ett integritetsperspektiv, fem distinkta spårningsytor. Var och en har sin egen samtyckesfråga.

Adobe Experience Cloud ID Service

ECID-tjänsten (laddad från cdn.cookielaw.org eller självhostad via Adobe Launch) tilldelar en beständig besöksidentifierare och lagrar den i AMCV_*-kakorna. ECID är substratet som binder samman alla andra Adobe-tjänster — Analytics, Target och Audience Manager använder alla samma ECID för att koppla händelser till en profil. Att grinda ECID är det grundläggande samtyckesbeslutet; utan det kan ingen av de nedströms tjänsterna identifiera besökaren konsekvent.

Adobe Analytics (Site Catalyst)

Adobe Analytics-beaconet (laddat via s_code.js eller AppMeasurement) rapporterar sidvisningar och klickhändelser till Adobes analysinfrastruktur. Skriptet sätter bland annat kakorna s_cc, s_sq och s_pers. Liksom ECID är det en beteendeanalysyta som kräver opt-in-samtycke i EU enligt ePrivacy Article 5(3).

Adobe Target

Target-skriptet (laddat via at.js) hanterar personaliseringsbeslut i realtid. Det laddar på serversidan, observerar besökarbeteende och modifierar sidinnehåll baserat på segmenteringsregler. Target-kakorna inkluderar mbox och mboxEdgeCluster. Target är entydigt en spårningsyta för marknadsföringsändamål.

Adobe Audience Manager

Audience Manager (DMP-skiktet, laddat via dpm.demdex.net) är segmenteringsmotorn som bygger målgrupper för aktivering i betald media. Den sätter demdex-kakan och vidarebefordrar besökardata till Adobes identitetsgraf. AAM är den mest exponerade ytan ur ett tillsynsperspektiv eftersom den entydigt utgör kontextöverskridande beteendebaserad annonsering enligt CPRA och uttrycklig marknadsföring enligt GDPR.

Adobe Real-Time CDP

Real-Time CDP förenar identitet över webb, mobil och offlinekällor och bygger en enhetlig kundprofil. Ur ett samtykesperspektiv ärver den som standard det mest tillåtande samtyckesläget från sina indata; en CMP-integration måste i stället genomdriva det mest restriktiva läget.

Adobes inbyggda samtyckesmekansimer

Adobe har investerat betydande resurser i samtyckesprimitiver, särskilt sedan 2023. Plattformen exponerar nu samtyckesytor på varje lager i stacken.

Adobe Privacy & Consent service

Privacy & Consent service lanserades 2025 och är Adobes enhetliga samtyckesskikt. Den tar emot samtyckesbeslut från en CMP via API eller standard-signalen IAB GPP och propagerar dem genom Analytics, Target, Audience Manager och Real-Time CDP. Detta är den rekommenderade integrationspunkten 2026.

Samtyckestillägget i Adobe Launch

För installationer som använder Adobe Launch som tagghanterare låter ramverket för samtyckestillägg (liknande Google Tag Managers samtyckesläge) varje Adobe-tagg konfigureras att vänta på specifika samtykeskategorier. Integrationer från OneTrust, TrustArc, Cookiebot och andra kopplar in i detta ramverk.

Privacy JS API

Adobe Analytics, Target och ECID exponerar ett optIn-API på sidnivåns Adobe-objekt. Att anropa visitor.optIn.approve(["aam", "ecid", "target", "analytics"]) beviljar samtycke för de namngivna tjänsterna; visitor.optIn.deny(...) återkallar det. Detta är rätt primitiv för finkornig samtyckesstyrning per tjänst.

Steg-för-steg CMP-integration

Den tillförlitliga arkitekturen är att skjuta upp varje Adobe-tagg tills ett samtyckesbeslut har registrerats, och sedan propagera beslutet genom Privacy & Consent service eller samtyckestillägget i Launch.

1. Skjut upp initieringen av Adobe Launch

Launch-biblioteket initierar själva tagghanteraren som laddar allt annat. Skjut upp Launch-skriptet tills CMP:n har fångat besökarens beslut. Detta är den enskilt mest avgörande grindningen — att göra rätt här förebygger nästan alla nedströms defekter.

2. Konfigurera samtykeskategorier per tjänst

Mappa varje Adobe-tjänst till en CMP-kategori. ECID och Analytics grindas normalt under analys; Target och Audience Manager under marknadsföring; Real-Time CDP under den kategori som täcker den mest tillåtande nedströmsanvändningen. Dokumentera mappningen; revisionsförsvaret vilar på den.

3. Använd optIn-API:et

När CMP:n avfyrar sin „kategori accepterad"-callback, anropa visitor.optIn.approve([...]) med de tjänster som matchar de beviljade kategorierna. ECID-tjänsten och nedströms Adobe-skript börjar då skicka händelser. Vid återkallelse, anropa visitor.optIn.deny(...) för att stoppa dem.

4. Koppla till Privacy & Consent service

För samtyckeslägen som måste propageras bortom styrning på sidnivå — in i Real-Time CDP, in i serversideinsamling, in i batchimporter från andra system — måste CMP:n skriva till Adobes Privacy & Consent service via API. Tjänsten genomdriver sedan beslutet på varje Adobe-lager som stöder det.

5. Respektera återkallelse genom hela identitetsgrafen

När en användare återkallar samtycke måste Real-Time CDP och Audience Manager ta bort användaren från aktiva målgrupper, inte bara sluta lägga till händelser i deras profil. Konfigurera Privacy & Consent service:s raderingsarbetsflöde att aktiveras vid återkallelse, och granska att nedströms målgruppsaktiveringssystem (Google Ads, Meta, LiveRamp) respekterar undertryckningen.

Vanliga fallgropar

Fyra integrationsmisstag står för merparten av granskningsanmärkningarna på företags Adobe-installationer.

Att låta Launch initieras före samtycke

Standardintegrationen av Launch laddar tagghanteraren vid sidrendering, vilket initierar ECID och alla andra taggar som Launch är konfigurerat att avfyra automatiskt. Detta är den enskilt vanligaste defekten och den enklaste att åtgärda — skjut upp Launch-skriptet.

Att behandla ECID som undantaget

Vissa team hävdar att ECID är „identitetsinfrastruktur" snarare än spårning, och grindar nedströms tjänster men låter ECID avfyras. ECID-kakan är en icke-nödvändig identifierare enligt ePrivacy Article 5(3) oavsett hur dess data används nedströms. Grinda den.

Felaktigt matchat samtycke genom stacken

Om CMP:n registrerar samtycke för analys men optIn-API:et bara godkänner ecid och analytics medan aam och target lämnas ospecificerade, blir nedströmsbeteendet plattformsberoende och matchar sällan det CMP:n registrerade. Godkänn hela den uppsättning användaren beviljade, neka resten uttryckligen.

Att glömma serversideinsamling

Adobe Real-Time CDP stöder serversideinsamling av data från CRM:er, datalager och offlinesystem. Dessa flöden respekterar inte samtycke på webbläsarsidan automatiskt. Privacy & Consent service måste anropas från serversidans insamlingspipeline för att genomdriva samtyckesomfattningen.

Granskningschecklista

Sex konkreta frågor att besvara för varje Adobe Experience Cloud-installation som berör EU-, UK- eller Kalifornien-trafik.

• Väntar Launch på samtycke? Öppna sidan i ett privat fönster och bekräfta att inga förfrågningar till Adobe-domäner avfyras före banneracceptans.
• Är mappningen tjänst-till-kategori dokumenterad? Finns det för varje Adobe-tjänst (ECID, Analytics, Target, AAM, Real-Time CDP) en skriftlig post om vilken CMP-kategori som grindar den?
• Matchar optIn-API:et CMP:ns tillstånd? Bekräfta att approve/deny-anropen listar varje Adobe-tjänst explicit, med den beviljade uppsättningen matchande CMP:ns registrerade beslut.
• Är Privacy & Consent service konfigurerad? Bekräfta att CMP:n skriver beslut till Privacy & Consent service-API:et så att icke-webbläsarytor (Real-Time CDP, serversideinsamling) respekterar dem.
• Respekterar nedströmsaktiveringarna återkallelse? Bekräfta att återkallelse av samtycke tar bort användaren från aktiva målgrupper i Google Ads, Meta och LiveRamp, inte bara från framtida synkroniseringar.
• Är serversidans insamlingsvägar grindade? Bekräfta att CRM- och datalagerimporter till Real-Time CDP genomdriver samma samtyckesomfattning som webbläsarhändelser.

Var Adobe passar i en samtyckesfokuserad stack

Företagsmarknadsföringsstackar byggda kring Adobe Experience Cloud är samtidigt de mest kraftfulla och de mest exponerande av alla vanliga konfigurationer. Den goda nyheten är att Adobe har investerat tungt i samtyckesmekansimer de senaste två åren, och en installation från 2026 som använder Privacy & Consent service korrekt är väsentligt mer försvarbar än en byggd enbart på den äldre Visitor ID Service. Arbetet ligger i disciplinen: att dokumentera mappningen tjänst-till-kategori, att använda optIn-API:et explicit istället för att förlita sig på plattformens standardvärden, att propagera samtycke till serversidesytor och att granska att nedströms aktiveringar faktiskt respekterar återkallelser. Korrekt utfört slutar samma Adobe-stack som driver den personalisering och segmentering marknadsförarna köpte den för att vara en tyst regelefterlevnadsexponering som väntar på att en tillsynsmyndighet ska uppdaga den.