SFMC izsekošanas virsma

Piekrišanas nolūkos ir lietderīgi uzskatīt SFMC nevis par vienu produktu, bet par četrām pārklātu izsekošanas virsmām, katrai ar savu integrācijas modeli.

Web Analytics Connector un Collect izsekošanas kods

Collect izsekošanas kods (bieži sauc par collect.js vai atsaucas caur cdn.evgnet.com) ir SFMC behaviorāls sekotājs. Tas iestata _etmc un saistītos sīkfailus, identificē apmeklētājus pāri sesijai un nosūta lapas skatījumus, klikšķus un konversijas notikumus uz SFMC lietošanai Journey Builder triggerus un e-pasta retargetēšanai. No normatīvās perspektīvas tas ir skaidri mārketinga sekotājs — lai arī notikumi izskatās analitiskaski, dati tiek padoti tiešajā mārketinga automatizācijā.

Marketing Cloud Personalization skripts

Personalization skripts (mantojums Interaction Studio) ir smagāks par Collect. Tas ielādē SDK, kas pauž visu DOM, uztver klikšķu straumi un veidlapas mijiedarbības datus un nosūta tos personalizācijas lēmumu dzinējam, kas var atkārtoti rakstīt lapas saturu reālā laikā. Iestatītie sīkfaili ietver _ev_* identifikatorus un sesijas žetonu. Tas nepārprotami ir mārketinga nolūka apstrāde un prasa pēc izvēles piekrišanu jebkurā ES vai UK jurisdikcijā.

CloudPages veidlapas un izsekotās saites

CloudPages-mitinātās piezemēšanas lapas un izsekotās e-pasta saites, kas maršrutējās caur SFMC, nēsā savus identifikācijas parametrus (subscriberkey, jb, mid parametri URL). Kad apmeklētājs ierodas caur izsekotu saiti, SFMC var korelēt sesiju ar viņu abonenta ierakstu pat pirms jebkāda lapas izsekošanas ugunsceļa. Tas ir nozīmīgi atšķirīgs juridiskais stāvoklis no anonīmās izsekošanas — abonentu identitāte ir zināma no pirmā kontakta — un mārketinga komunikācijas piekrišana jau ir jābūt.

Data Cloud savienotāji

SFMC Data Cloud integrācija (klientu datu platformas slānis) vieno identifikatorus no tīmekļa izsekošanas, mobilo SDK, CRM ierakstiem un bezsaistības datiem vienotā profilā. Piekrišanas stāvoklis jāpropagandē Data Cloud, nevis tikai uz virsmas līmeņa izsekošanas pikseļa, lai varētu lejupstraumi aktivizēt ad tīklus, kas respektē apmeklētāja ierakstītās preferencias.

Vietējie SFMC privātuma kontroles

SFMC izklāsti vairākas vietējās kontroles, bet, tāpat kā lielākajā daļā uzņēmuma mārketinga platformu, tie pieņem, ka piekrišanas lēmums ir savākts augšupstraumi un tiek nodots. Vietējās kontroles pašas neapkopo piekrišanu.

Izsekošanas iespēja Web Analytics Connector

Collect skripts nolasa do_not_track karogu un konfigurējamu iespēju neatteikti. Šo iestatīšana novērš Collect no datu sūtīšanas, bet neprevencē paša skripta ielādi. Iepriekšējas piekrišanas jurisdikcijām ir jāizvērš skripta ielāde, nevis tikai pārslēgt karogu.

Piekrišanas preferencias abonenta ierakstā

Abonenta profils SFMC ir lauki komunikācijas piekrišanai, profila datu piekrišanai un likumīgam pamatam. Tie ir pareizi primitīvi juridiskā pamata izsekošanai, pēc kura zināms kontakts tiek tirgots, un CMP būtu jāraksta atpakaļ šos laukus, kad apmeklētājs pieņem vai atsauc.

Marketing Cloud Personalization piekrišana

Personalization SDK pieņem piekrišanas karogu iniciālizācijas laikā. Iestatiet uz false, līdz lietotājs ir pieņēmis mārketinga kategoriju CMP baneris, tad atkārtoti inicializējiet SDK, kad piekrišana ir sniegta.

Posms pa posmam CMP integrācija

Uzticamā arhitektūra ir visas četras izsekošanas virsmas ieslēgt aiz CMP un izmantot SFMC vietējās karogas, lai rafinētu lejupstraumi darbību pēc piekrišanas piešķiršanas.

1. Apstādiniet Collect skriptu ielādi pēc noklusējuma

Noņemiet Collect skriptu no dokumenta galvas un aizstājiet to ar vietturi, kuru var aktivizēt CMP. Kad apmeklētājs pieņem mārketinga kategoriju, CMP pārraksta vietturu, lai ielādētu collect.js. Jebkuri rindā stāvošie notikumi iztukšo ielādei.

2. Atlieciet Marketing Cloud Personalization inicializāciju

Personalization skripts nedrīkst inicializēt pirms piekrišanas. Lielākā daļa CMP apstrādā to ar atliktās ielādes modeli: skripta elements ir DOM, bet tā type atribūts ir text/plain, un CMP to pārraksta uz text/javascript piekrišanas pieņemšanas gadījumā.

3. Ieslēgt CloudPages izsekošanas parametrus

Ja apmeklētājs ierodas caur izsekotu saiti un vēl nav devis piekrišanu, inbound subscriberkey parametrs būtu jāiekļauj, bet ne izmantot, lai virzītu uzreiz personalizāciju. Pareizais modeli ir saglabāt to sesijas stāvoklī un aktivizēt to tikai (korelējot ar profila datiem, triggerot Journey Builder notikumus) pēc piekrišanas ierakstīšanas.

4. Izplatiet piekrišanas stāvokli uz Data Cloud

Data Cloud integrācijai ir jāzina katra apmeklētāja piekrišanas stāvoklis, lai lejupstraumi aktivizācijas to godā. SFMC atbalsta piekrišanas paplašinājumu, kas ļauj CMP rakstīt piekrišanas ierakstu Data Cloud API caur. Konfigurējiet to tā, lai CMP piekrišanas lēmums kļūtu par patiesības avotu visā SFMC slānī, nevis tikai uz lapas skriptiem.

5. Kartējiet uz SFMC abonenta piekrišanas laukiem

Kad zināms abonentu atjaunina viņu piekrišanu CloudPages preferenču centrā, CMP un SFMC abonenta ieraksts ir jāparalelē. Konfigurējiet rakstīšanu atpakaļ no CMP uz SFMC abonenta piekrišanas laukiem, un konfigurējiet lasīšanu atpakaļ, lai uz lapas baners godā to, ko abonentu iestatīja savos e-pasta preferencēs.

Parastās kļūdas

Trīs integrācijas kļūdas uzskaita lielāko daļu uzņēmuma revīzijas atklājumi par SFMC.

Collect uzskatīšana par analitiku

Tā kā Collect skripts ziņo par lapas skatījumiem un klikšķa notikumiem, kas izskatās analitiskaski, komandas dažreiz ieslēdz to zem analitikes piekrišanas kategorijas. SFMC izmanto šos datus, lai virzītu Journey Builder mārketinga automatizāciju, kas ir nepārprotami mārketinga nolūka apstrāde. Ieslēgtā Collect zem mārketinga.

Personalization palaišana pirms piekrišanas

Personalization ir smagākais SFMC izsekošanas virsmas un visvairāk regulators redzams, jo tas aktīvi modificē lapu. Pieļaujot tā inicializēšanu pirms piekrišanas ir revīzijas izteiksmē, viens visvairāk eksponējošais modeli SFMC stekā.

Piekrišanas nesinhronizēšana visā stekā

Ja uz lapas baners ieraksta piekrišanas lēmumu, bet Data Cloud profils saglabā vecāku stāvokli, lejupstraumi aktivizācijas uz ad tīkliem turpinās ugunsceļa, pamatojoties uz novecojušu piekrišanu. CMP ir jākļūst par patiesības avotu un jāpropagandē tas visur, kur SFMC steks var sasniegt.

Revīzijas kontrolsaraksts

Pieci konkrēti jautājumi, uz kuriem jāatbild jebkuram SFMC izvietojumam, kas skar ES, UK vai Kalifornijas satiksmi.

• Vai Collect gaida piekrišanu? Apstipriniet, ka ne collect.js, ne evgnet.com pieprasījums neizpildās pirms bannera pieņemšanas.
• Vai Personalization ir atliekta? Apstipriniet, ka Personalization SDK neinicializējas, līdz ir sniegta mārketinga kategorija.
• Vai inbound izsekotu saišu parametri tiek turēti, līdz piekrišana? Apstipriniet, ka subscriberkey-virzīta personalizācija gaida skaidru piekrišanas signālu.
• Vai Data Cloud redz piekrišanas stāvokli? Apstipriniet, ka piekrišanas paplašinājums ir konfigurēts un CMP raksta lēmumus Data Cloud reālā laikā.
• Vai abonenta piekrišanas lauki tiek sinhronizēti? Apstipriniet, ka preferenču centra izmaiņas izplatās uz uz lapas banneri un otrādi.

Vieta, kur SFMC atbilst piekrišanas pirmajam stekam

SFMC ir viens no spēcīgākajiem — un viens no visvairāk eksponējošākajiem — mārketinga platformām, ko uzņēmums var izvietot. Noklusējuma instalācijas modeli vienkārši neatbilst pašreizējām Eiropas vai Kalifornijas gaidām, un platformas vietējās kontroles ir noderīgi primitīvi, bet ne aizstājējs augšupstraumes piekrišanas pārvaldības slānim. Pareizā arhitektūra uzskata CMP par vienīgo patiesības avotu, ieslēdz katru izsekošanas moduli aiz tā un izmanto SFMC piekrišanas paplašinājumus, lai padarītu Data Cloud un abonenta ierakstus, lai šis patiesums izplatītos visā steka. Ja to izdarīs pareizi, SFMC turpina darīt to, ko tirgotāji to nopirka — Journey Builder triggerus, Personalization lēmumu pieņemšanu, Data Cloud aktivizāciju — kamēr pamatā esošais atbilstības stāvoklis atbilst tam, ko regulatori nu sagaida no jebkura uzņēmuma tirgotāja.