Adobe Experience Cloud izsekošanas virsmas

“Vienots” Adobe uzstādījums no privātuma viedokļa ir piecas atšķirīgas izsekošanas virsmas. Katrai ir savs piekrišanas jautājums.

Adobe Experience Cloud ID pakalpojums

ECID pakalpojums (ielādēts no cdn.cookielaw.org vai pašmitināts, izmantojot Adobe Launch) piešķir pastāvīgu apmeklētāja identifikatoru un saglabā to AMCV_* sīkfailos. ECID ir pamats, kas savieno visus pārējos Adobe pakalpojumus — Analytics, Target un Audience Manager visi izmanto to pašu ECID, lai saistītu notikumus ar profilu. ECID bloķēšana ir galvenais piekrišanas lēmums; bez tā neviens no pakārtotajiem pakalpojumiem nevar konsekventi identificēt apmeklētāju.

Adobe Analytics (Site Catalyst)

Adobe Analytics bāksignāls (ielādēts, izmantojot s_code.js vai AppMeasurement) ziņo par lapas skatījumu un klikšķu notikumiem Adobe analītikas infrastruktūrā. Skripts iestata s_cc, s_sq un s_pers sīkfailus, kā arī citus. Tāpat kā ECID, tā ir uzvedības analītikas virsma, kurai ES saskaņā ar ePrivacy Article 5(3) nepieciešama aktīvā piekrišana.

Adobe Target

Target skripts (ielādēts, izmantojot at.js) apstrādā reāllaika personalizācijas lēmumus. Tas tiek ielādēts servera pusē, vēro apmeklētāja uzvedību un modificē lapas saturu, pamatojoties uz segmentācijas noteikumiem. Target sīkfaili ietver mbox un mboxEdgeCluster. Target ir nepārprotami mārketinga nolūkiem paredzēta izsekošanas virsma.

Adobe Audience Manager

Audience Manager (DMP slānis, ielādēts, izmantojot dpm.demdex.net) ir segmentācijas dzinējs, kas veido auditorijas aktivizācijai apmaksātajos plašsaziņas līdzekļos. Tas iestata demdex sīkfailu un pārsūta apmeklētāja datus uz Adobe identitātes grafiku. AAM ir visvairāk pakļautā virsma no regulatora viedokļa, jo tā ir nepārprotami starpkontekstu uzvedības reklāma saskaņā ar CPRA un tiešs mārketings saskaņā ar GDPR.

Adobe Real-Time CDP

Real-Time CDP apvieno identitāti tīmeklī, mobilajās ierīcēs un bezsaistes avotos, veidojot vienotu klientu profilu. No piekrišanas viedokļa tas pēc noklusējuma pārmanto atļautāko piekrišanas stāvokli no saviem ievadiem; CMP integrācijai tā vietā jāpieprasa visierobežojošākais stāvoklis.

Adobe vietējie piekrišanas primitīvi

Adobe ir ievērojami investējis piekrišanas pārvaldības primitīvos, īpaši kopš 2023. gada. Platforma tagad pakļauj piekrišanas virsmas katrā steka slānī.

Adobe Privacy & Consent service

Adobe Privacy & Consent service, kas tika palaists 2025. gadā, ir Adobe vienotais piekrišanas slānis. Tas pieņem piekrišanas lēmumus no CMP, izmantojot API vai standarta IAB GPP signālu, un izplata tos Analytics, Target, Audience Manager un Real-Time CDP ietvaros. Šis ir ieteicamais integrācijas punkts 2026. gadā.

Adobe Launch piekrišanas paplašinājums

Izvietojumiem, kas izmanto Adobe Launch kā tagu pārvaldnieku, piekrišanas paplašinājuma ietvars (līdzīgi Google Tag Manager piekrišanas režīmam) ļauj katram Adobe tagam konfigurēt gaidīšanu uz konkrētām piekrišanas kategorijām. OneTrust, TrustArc, Cookiebot un citu integrācijas tiek pieslēgtas šim ietvaram.

Privacy JS API

Adobe Analytics, Target un ECID pakļauj optIn API lapas līmeņa Adobe objektā. Izsaucot visitor.optIn.approve(["aam", "ecid", "target", "analytics"]), tiek piešķirta piekrišana nosauktajiem pakalpojumiem; visitor.optIn.deny(...) to atsauc. Tas ir pareizais primitīvs smalkai, pakalpojumu līmeņa piekrišanas izpildei.

CMP integrācija soli pa solim

Uzticamā arhitektūra ir atlikt katru Adobe tagu, līdz tiek reģistrēts piekrišanas lēmums, pēc tam izplatīt lēmumu, izmantojot Privacy & Consent service vai Launch piekrišanas paplašinājumu.

1. Atlikt Adobe Launch inicializāciju

Pati Launch bibliotēka inicializē tagu pārvaldnieku, kas ielādē visu pārējo. Atlieciet Launch skriptu, līdz CMP ir uztvēris apmeklētāja lēmumu. Šis ir vienīgais vissvarīgākais vārti — to pareizi nokārtojot, tiek novērsti gandrīz visi pakārtotie defekti.

2. Konfigurēt piekrišanas kategorijas katram pakalpojumam

Kartējiet katru Adobe pakalpojumu uz CMP kategoriju. ECID un Analytics parasti tiek bloķēti analītikā; Target un Audience Manager — mārketingā; Real-Time CDP — jebkurā kategorijā, kas aptver atļautāko pakārtoto izmantošanu. Dokumentējiet kartējumu; revīzijas aizstāvība balstās uz to.

3. Izmantot optIn API

Kad CMP aktivizē savu kategorijas piekrišanas atzvanu, izsauciet visitor.optIn.approve([...]) ar pakalpojumiem, kas atbilst piešķirtajām kategorijām. ECID pakalpojums un pakārtotie Adobe skripti sāks sūtīt notikumus. Atsaukšanas gadījumā izsauciet visitor.optIn.deny(...), lai tos apturētu.

4. Savienot ar Privacy & Consent service

Piekrišanas stāvoklim, kam jāizplatās ārpus lapas līmeņa izpildes — Real-Time CDP ietvaros, servera puses uzņemšanā, pakešu importā no citām sistēmām — CMP jāraksta Adobe Privacy & Consent service, izmantojot API. Pakalpojums pēc tam izpilda lēmumu katrā Adobe slānī, kas to atbalsta.

5. Ievērot atsaukšanu visā identitātes grafikā

Kad lietotājs atsauc piekrišanu, Real-Time CDP un Audience Manager ir jānoņem lietotājs no aktīvajām auditorijām, ne tikai jāpārtrauc pievienot notikumus viņa profilam. Konfigurējiet Privacy & Consent service dzēšanas darbplūsmu, lai tā aktivizētos atsaukšanas gadījumā, un pārbaudiet, ka pakārtotās auditorijas aktivizācijas virsmas (Google Ads, Meta, LiveRamp) ievēro nomākšanu.

Biežāk pieļautās kļūdas

Četras integrācijas kļūdas veido lielāko daļu revīzijas atklājumu uzņēmumu Adobe izvietojumos.

Launch inicializācija pirms piekrišanas

Noklusējuma Launch integrācija ielādē tagu pārvaldnieku lapas renderēšanas laikā, kas inicializē ECID un jebkurus citus tagus, ko Launch ir konfigurēts aktivizēt automātiski. Šis ir visizplatītākais defekts un visvieglāk novēršamais — atlieci Launch skriptu.

ECID uzskatīšana par atbrīvotu

Dažas komandas apgalvo, ka ECID ir “identitātes infrastruktūra”, nevis izsekošana, un bloķē pakārtotus pakalpojumus, vienlaikus ļaujot ECID aktivizēties. ECID sīkfails ir nebūtisks identifikators saskaņā ar ePrivacy Article 5(3) neatkarīgi no tā, kā tā dati tiek izmantoti pakārtoti. Bloķējiet to.

Neatbilstoša piekrišana visā stekā

Ja CMP reģistrē piekrišanu analītikai, bet optIn API apstiprina tikai ecid un analytics, atstājot aam un target nenorādītus, pakārtotā uzvedība ir atkarīga no platformas un reti atbilst CMP reģistrētajam. Apstipriniet pilnu lietotāja piešķirto kopu, skaidri atsakot pārējo.

Servera puses uzņemšanas aizmirstana

Adobe Real-Time CDP atbalsta servera puses datu uzņemšanu no CRM, noliktavām un bezsaistes sistēmām. Šīs plūsmas automātiski neievēro pārlūkprogrammas puses piekrišanu. Privacy & Consent service ir jāizsauc no servera puses uzņemšanas cauruļvada, lai izpildītu piekrišanas apvalku.

Revīzijas kontrolsaraksts

Seši konkrēti jautājumi, uz kuriem jāatbild jebkuram Adobe Experience Cloud izvietojumam, kas skar ES, UK vai Kalifornijas datplūsmu.

• Vai Launch gaida piekrišanu? Atveriet lapu privātajā logā un apstipriniet, ka pirms banera pieņemšanas netiek aktivizēts neviens Adobe domēna pieprasījums.
• Vai pakalpojuma un kategorijas kartējums ir dokumentēts? Katram Adobe pakalpojumam (ECID, Analytics, Target, AAM, Real-Time CDP) — vai pastāv rakstisks ieraksts par to, kura CMP kategorija to bloķē?
• Vai optIn API atbilst CMP stāvoklim? Apstipriniet, ka apstiprinājuma/atteikuma izsaukumi skaidri uzrāda katru Adobe pakalpojumu, ar piešķirto kopu, kas atbilst CMP reģistrētajam lēmumam.
• Vai Privacy & Consent service ir konfigurēts? Apstipriniet, ka CMP raksta lēmumus Privacy & Consent service API, lai ne-pārlūka virsmas (Real-Time CDP, servera puses uzņemšana) tos ievērotu.
• Vai pakārtotās aktivizācijas ievēro atsaukšanu? Apstipriniet, ka piekrišanas atsaukšana noņem lietotāju no aktīvajām auditorijām Google Ads, Meta un LiveRamp, ne tikai no turpmākajām sinhronizācijām.
• Vai servera puses uzņemšanas ceļi ir bloķēti? Apstipriniet, ka CRM un noliktavas importi Real-Time CDP ietvaros izpilda to pašu piekrišanas apvalku kā pārlūkprogrammas notikumi.

Kur Adobe iederas piekrišanas prioritātes stekā

Uzņēmumu mārketinga steki, kas veidoti ap Adobe Experience Cloud, vienlaikus ir gan jaudīgākie, gan visvairāk pakļautie no jebkuras izplatītas konfigurācijas. Labā ziņa ir tā, ka Adobe pēdējos divos gados ir nopietni investējis piekrišanas primitīvos, un 2026. gada izvietojums, kas pareizi izmanto Privacy & Consent service, ir ievērojami vairāk aizstāvams nekā tāds, kas veidots tikai uz vecāka Visitor ID Service. Darbs slēpjas disciplīnā: pakalpojuma un kategorijas kartējuma dokumentēšanā, optIn API skaidrā izmantošanā, nevis paļaujoties uz platformas noklusējumiem, piekrišanas izplatīšanā uz servera puses virsmas un pakārtoto aktivizāciju pārbaudē, lai tās tiešām ievērotu atsaukumus. Pareizi izdarīts, tas pats Adobe steks, kas nodrošina personalizāciju un segmentāciju, ko mārketinga speciālisti to iegādājās, pārstāj būt klusa atbilstības iedarbība, kas gaida, kad regulators to atklās.