Suprafața de urmărire SFMC

Pentru scopuri de consimțământ este util să tratați SFMC nu ca un singur produs ci ca patru suprafețe de urmărire suprapuse, fiecare cu propriul model de integrare.

Web Analytics Connector și codul de urmărire Collect

Codul de urmărire Collect (adesea numit collect.js sau referit prin cdn.evgnet.com) este urmăritorul comportamental al SFMC. Setează cookie-urile _etmc și conexe, identifică vizitatorii între sesiuni și transmite eventos de vizualizare pagină, clic și conversie către SFMC pentru utilizare în declanșatorii Journey Builder și retargeting prin email. Din perspectiva reglementară este în mod clar un tracker de marketing — deși evenimentele arată ca analitică, datele alimentează automatizarea directă a marketingului.

Scriptul Marketing Cloud Personalization

Scriptul Personalization (Interaction Studio moștenit) este mai greu decât Collect. Încarcă un SDK care monitorizează întregul DOM, capturează datele clickstream și interacțiune formular și le transmite unui motor de decizie pentru personalizare care poate rescrie conținutul paginii în timp real. Cookie-urile setate includ identificatori _ev_* și un token de sesiune. Aceasta este în mod clar procesare cu scop de marketing și necesită consimțământ opt-in în orice jurisdicție din UE sau Regatul Unit.

Formulare CloudPages și linkuri urmărite

Paginile de destinație găzduite pe CloudPages și linkurile de email urmărite care se rutează prin SFMC poartă propriii parametri de identificare (parametri subscriberkey, jb, mid în URL-uri). Când un vizitator sosește prin intermediul unui link urmărit, SFMC poate corela sesiunea cu înregistrarea abonatului lor chiar înainte ca orice urmărire în pagină să se declanșeze. Aceasta este o postură juridică semnificativ diferită de urmărirea anonimă — identitatea abonatului este cunoscută la primul contact — și consimțământul pentru comunicațiile de marketing trebuie să existe deja.

Conectorii Data Cloud

Integrarea Data Cloud a SFMC (stratul platformei de date a clienților) extrage identificatori din urmărirea web, SDK-uri mobile, înregistrări CRM și date offline într-un profil unificat. Starea consimțământului trebuie să se propagă în Data Cloud, nu doar în pixelul de urmărire la nivel de suprafață, astfel încât activările descendente către rețelele de anunțuri să respecte preferințele înregistrate ale vizitatorului.

Controale de confidentialitate native SFMC

SFMC expune mai control controale native dar, ca și în cazul majorității platformelor de marketing enterprise, acestea presupun că o decizie de consimțământ a fost colectată în amonte și este transmisă. Controalele native nu colectează consimțământul ele înșile.

Dezactivarea urmăririi pentru Web Analytics Connector

Scriptul Collect citește o steagă do_not_track și o funcție de dezactivare configurabilă. Setarea acestora împiedică Collect să trimită date dar nu împiedică scriptul în sine să se încarce. Pentru jurisdicțiile cu consimțământ anterior trebuie să porți scriptul care se încarcă, nu doar comutați steagă.

Preferințele de consimțământ în înregistrările de abonați

Profilul abonatului în SFMC are câmpuri pentru consimțământul comunicații, consimțământul datelor de profil și baza juridică. Acestea sunt primitivele corecte pentru urmărirea bazei juridice în temeiul căreia un contact cunoscut este marketing și CMP ar trebui să rescrie în aceste câmpuri când un vizitator acceptă sau revocă.

Consimțământ Marketing Cloud Personalization

SDK-ul Personalization acceptă un steagă de consimțământ în timpul inițializării. Setați-l la false până când utilizatorul a acceptat categoria de marketing în bannerul CMP, apoi reinițializați SDK-ul când consimțământul este acordat.

Integrare CMP pas cu pas

Arhitectura fiabilă este să porți toate patru suprafețe de urmărire în spatele CMP și să utilizezi steagurile native SFMC pentru a rafina comportamentul descendent odată ce consimțământul este acordat.

1. Opriți scriptul Collect să se încarce implicit

Eliminați scriptul Collect din capul documentului și înlocuiți-l cu un placeholder pe care CMP-ul îl poate activa. Când vizitatorii acceptă categoria de marketing, CMP-ul rescrie placeholder-ul pentru a încărca collect.js. Orice evenimente în coadă se videază la încărcare.

2. Amânați inițializarea Marketing Cloud Personalization

Scriptul Personalization nu trebuie să se inițializeze înainte de consimțământ. Cele mai multe CMP-uri gestionează aceasta cu un model de încărcare amânată: elementul script este prezent în DOM dar atributul type al său este text/plain, iar CMP-ul îl rescrie la text/javascript la acceptarea consimțământului.

3. Porți parametrii de urmărire CloudPages

Dacă un vizitator sosește prin intermediul unui link urmărit și nu a dat încă consimțământ, parametrul inbound subscriberkey ar trebui să fie capturat dar nu utilizat pentru a conduce personalizare imediată. Modelul corect este să-l stocați în starea sesiunii și să îl activați doar (corelând cu datele profilului, declanșând evenimente Journey Builder) odată ce consimțământul este înregistrat.

4. Propagați starea consimțământului în Data Cloud

Integrarea Data Cloud trebuie să știe starea consimțământului fiecărui vizitator, astfel încât activările descendente să o onoreze. SFMC susține o extensie de consimțământ care permite CMP-ului să scrie o înregistrare de consimțământ în Data Cloud prin API. Configurați aceasta, astfel încât decizia de consimțământ a CMP-ului să devină sursa de adevăr pe întregul strat SFMC, nu doar pentru scripturile în pagină.

5. Mapați câmpurile consimțământ abonatului SFMC

Când un abonat cunoscut și-a actualizat consimțământul pe un centru de preferințe CloudPages, înregistrarea CMP și SFMC subscriber trebuie să rămână sincronizate. Configurați o scriere înapoi din CMP în câmpurile consimțământ ale abonatului SFMC și configurați o relecție, astfel încât bannerul din pagină să respecte ceea ce abonatul a stabilit în preferințele sale de email.

Capcane comune

Trei greșeli de integrare explică majoritatea constatărilor de audit enterprise pe SFMC.

Tratarea Collect ca analitică

Deoarece scriptul Collect raportează vizualizări pagină și evenimente de clic care arată ca analitică, echipele uneori îl portă sub categoria consimțământ analitică. SFMC utilizează acele date pentru a conduce automatizarea marketing Journey Builder, care este în mod clar procesare cu scop de marketing. Porți Collect sub marketing.

Lăsând Personalization să ruleze pre-consimțământ

Personalization este cea mai grea dintre suprafețele de urmărire SFMC și cea mai vizibilă de regulatori deoarece modifica activ pagina. Permiterea inițializării sale înainte de consimțământ este, în termeni de audit, modelul cel mai expunător din stiva SFMC.

Nesinc consimțământul în stivă

Dacă bannerul din pagină înregistrează o decizie de consimțământ dar profilul Data Cloud păstrează o stare mai veche, activările descendente către rețelele de anunțuri vor continua să se declanșeze pe baza consimțământului vechi. CMP trebuie să deținea sursa de adevăr și să o propaghe peste tot unde stiva SFMC poate ajunge.

Lista de verificare audit

Cinci întrebări concrete de răspuns pentru orice implementare SFMC care atinge traficul din UE, Regatul Unit sau California.

• Collect așteaptă consimțământul? Confirmați că nicio solicitare collect.js sau evgnet.com nu se declanșează înainte de acceptarea bannerului.
• Este Personalization amânată? Confirmați că SDK-ul Personalization nu se inițializează până când categoria de marketing este acordată.
• Sunt parametrii link urmăriți inbound ținuți până la consimțământ? Confirmați că personalizarea condusă de subscriberkey așteaptă un semnal de consimțământ explicit.
• Data Cloud vede starea consimțământului? Confirmați că extensia de consimțământ este configurată și CMP-ul scrie decizii în Data Cloud în timp real.
• Sunt câmpurile consimțământ abonatului sincronizate? Confirmați că modificările centrului de preferințe se propagă la bannerul din pagină și invers.

Cum se încadrează SFMC într-o stivă orientată pe consimțământ

SFMC este una dintre cele mai puternice — și una dintre cele mai expunătoare — platforme de marketing pe care o întreprindere poate implementa. Modelul de instalare implicit pur și simplu nu satisface așteptările europene sau californiană actuale, iar controalele native ale platformei sunt primitive utile dar nu un substitut pentru un strat de gestionare a consimțământului în amonte. Arhitectura corectă tratează CMP ca unica sursă de adevăr, porți fiecare modul de urmărire în spatele acesteia și utilizează extensiile de consimțământ SFMC pentru a face ca Data Cloud și înregistrările abonatului să propaghe acel adevăr în restul stivei. Făcută corect, SFMC continuă să facă ceea ce marketerii au cumpărat-o — declanșatori Journey Builder, decizia Personalization, activare Data Cloud — în timp ce postura de conformitate din spate se potrivește cu ceea ce regulatorii așteaptă acum de la orice marketer enterprise.