SFMC-sporingsoverflaten

For samtykkeskapformål hjelper det å behandle SFMC ikke som ett produkt, men som fire overlappende sporingsflater, hver med sitt eget integrasjonsmønster.

Web Analytics Connector og Collect-sporingskode

Collect-sporingskoden (ofte kalt collect.js eller referert via cdn.evgnet.com) er SFMC sin atferdssporer. Den setter _etmc og relaterte informasjonskapsler, identifiserer besøkende på tvers av økter, og sender sidevisnings-, klikk- og konverteringshendelser til SFMC for bruk i Journey Builder-utløsere og e-postretargeting. Fra et regulatorisk perspektiv er det klart en markedsføringssporer — selv om hendelsene ser ut som analyser, mater dataene direkte markedsføringsautomatisering.

Marketing Cloud Personalization-skriptet

Personalization-skriptet (legacy Interaction Studio) er tyngre enn Collect. Det laster en SDK som ser hele DOM-en, fanger opp clickstream- og skjemainteraksjondata, og sender det til en personaliseringsbeslutningsmotor som kan omskrive sideinnhold i sanntid. Informasjonskapsler som er satt inkluderer _ev_*-identifikatorer og en økttoken. Dette er utvetydig markedsføringsformål-prosessering og krever opt-in-samtykke i hvilken som helst EU- eller UK-jurisdiksjon.

CloudPages-skjemaer og sporede lenker

CloudPages-vertede landingssider og de sporede e-postlenkene som ruter gjennom SFMC, bærer sine egne identifiserende parametere (subscriberkey, jb, mid-parametere i URL-er). Når en besøkende kommer via en sporet lenke, kan SFMC korrelere økten med abonnementposten sin selv før noen sporing på siden fyres. Dette er en meningsfull annen juridisk holdning enn anonym sporing — abonnementidentiteten er kjent ved første kontakt — og samtykke for markedsføringskommunikasjon må allerede eksistere.

Data Cloud-koblinger

SFMC sin Data Cloud-integrasjon (kundedataplattformlaget) trekker identifikatorer fra websporing, mobile SDK-er, CRM-poster og offline-data inn i en enhetlig profil. Samtykkestatus må forplante seg til Data Cloud, ikke bare til sporingspikslene på overflaten, slik at nedstrømsaktiveringer til annonsettverk respekterer besøkendes registrerte preferanser.

Native SFMC-personvernkontroller

SFMC eksponerer flere native kontroller, men som med de fleste markedsføringsplattformer for bedrifter, antar de at en samtykkebeslutning har blitt samlet inn oppstrøms og sendes inn. De native kontrollene samler ikke selv samtykke.

Sporingsopt-out for Web Analytics Connector

Collect-skriptet leser et do_not_track-flagg og en konfigurerbar opt-out-funksjon. Hvis du setter disse, hindrer du Collect fra å sende data, men det hindrer ikke skriptet selv fra å laste. For tidligere-samtykke-jurisdiksjoner må du gate skriptlastingen, ikke bare slå flagget.

Samtykkepeferanser i abonnementposter

Abonnementprofilen i SFMC har felt for kommunikasjonssamtykke, profildata-samtykke og juridisk grunnlag. Dette er de riktige primitivene for å spore det juridiske grunnlaget som en kjent kontakt blir markedsført til under, og CMP-en bør skrive tilbake til disse feltene når en besøkende godtar eller trekker tilbake.

Marketing Cloud Personalization-samtykke

Personalization SDK-en godtar et samtykkeflagg under initialisering. Sett det til false til brukeren har godtatt markedsføringskategorien i CMP-banneret, deretter re-initialiserer du SDK-en når samtykke er gitt.

Trinn-for-trinn CMP-integrasjon

Den pålitelige arkitekturen er å gate alle fire sporingsflater bak CMP-en og bruke SFMC sin native flagg for å finne og ombestemme nedstrømsatferd når samtykke er gitt.

1. Stopp Collect-skriptet fra å laste som standard

Fjern Collect-skriptet fra dokumenthodet og erstatt det med en plassholder CMP-en kan aktivere. Når besøkende godtar markedsføringskategorien, omskriver CMP-en plassholderstakken for å laste collect.js. Alle køede hendelser vaskes på last.

2. Utsett Marketing Cloud Personalization-initialisering

Personalization-skriptet må ikke initialiseres før samtykke. De fleste CMP-er håndterer dette med et utsatt-last-mønster: skriptelementet er til stede i DOM-en, men dets type-attributt er text/plain, og CMP-en omskriver det til text/javascript ved godkjenning av samtykke.

3. Gate CloudPages-sporingsparametere

Hvis en besøkende kommer via en sporet lenke og ennå ikke har gitt samtykke, bør innbounds subscriberkey-parameteren fanges opp, men ikke brukes til å drive umiddelbar personalisering. Det riktige mønsteret er å lagre det i øktstat og bare aktivere det (korrelere med profildata, utløse Journey Builder-hendelser) når samtykke er registrert.

4. Forplant samtykkestatus til Data Cloud

Data Cloud-integrasjonen må vite hver besøkendes samtykkestatus slik nedstrømsaktiveringer respekterer det. SFMC støtter en samtykkeutvidelse som lar CMP-en skrive en samtykkepost til Data Cloud via API. Konfigurer dette slik at CMP-ens samtykkebeslutning blir kilden til sannhet på tvers av hele SFMC-laget, ikke bare for skriptene på siden.

5. Kartlegg til SFMC-abonnentsamt samtykkefelt

Når en kjent abonnent oppdaterer samtykkene sine på et CloudPages-prefefeansesenter, trenger CMP-en og SFMC-abonnentposten å holde seg synkronisert. Konfigurer en skriv-tilbake fra CMP-en til SFMC-abonnentens samtykkefelt, og konfigurer en les-tilbake slik banneret på siden respekterer hva abonnenten angav i e-postinnstillingene sine.

Vanlige fallgruver

Tre integreringsfeil står for de fleste funnene i bedriftsrevisjoner på SFMC.

Å behandle Collect som analyser

Fordi Collect-skriptet rapporterer sidevisninger og klikkhendelser som ser ut som analyser, behandler lag det noen ganger under analysesamtykkekategorien. SFMC bruker disse dataene til å drive Journey Builder-markedsføringsautomatisering, som er utvetydig markedsføringsformål-prosessering. Gate Collect under markedsføring.

La Personalization kjøre før samtykke

Personalization er den tyngste av SFMC-sporingsoverflatene og den mest synlig for regulatorer fordi den aktivt endrer siden. Å tillate det å initialisere før samtykke er, i revisjonsvillkår, det eneste mest eksponerende mønsteret i SFMC-stakken.

Ikke synkronisere samtykke på tvers av stakken

Hvis banneret på siden registrerer en samtykkebeslutning, men Data Cloud-profilen beholder en eldre tilstand, vil nedstrømsaktiveringer til annonsettverk fortsette å fyre basert på gammelt samtykke. CMP-en må eie kilden til sannhet og forplante den overalt SFMC-stakken kan nå.

Revisjonsjekkliste

Fem konkrete spørsmål å svare på for enhver SFMC-distribusjon som berører EU-, UK- eller California-trafikk.

• Venter Collect på samtykke? Bekreft ingen collect.js eller evgnet.com-forespørsel fyres før bannergodkjenning.
• Er Personalization utsatt? Bekreft Personalization SDK initialiserer ikke til markedsføringskategorien er gitt.
• Holdes innbunde sporede-lenke-parametere til samtykke? Bekreft subscriberkey-drevet personalisering venter på et eksplisitt samtykkesignal.
• Ser Data Cloud samtykkestatus? Bekreft samtykkeutvidelsen er konfigurert og CMP-en skriver beslutninger til Data Cloud i sanntid.
• Er abonnentsamt samtykkefelt synkronisert? Bekreft preferansesentre-endringer forplanter seg til banneret på siden og omvendt.

Hvor SFMC passer i en samtykke-først-stakk

SFMC er en av de mest kraftfulle — og en av de mest eksponerende — markedsføringsplattformene en bedrift kan distribuere. Standardinstallasjonsmønsteret oppfyller rett og slett ikke nåværende europeiske eller California-forventninger, og plattformens native kontroller er nyttige primitiver, men ikke en erstatning for et oppstrøms-samtykkestyreleslag. Den riktige arkitekturen behandler CMP-en som den eneste kilden til sannhet, gater hver sporingsmodul bak den, og bruker SFMC sin samtykkeutvidelse for å få Data Cloud og abonnentpostene til å forplante denne sannheten på tvers av resten av stakken. Når det gjøres riktig, holder SFMC på å gjøre det markedsførere kjøpte det for å gjøre — Journey Builder-utløsere, Personalization-beslutningstaking, Data Cloud-aktivering — mens det underliggende samsvaret med regeleverket samsvarer med det regulatorer nå forventer fra noen bedriftsmarkeder.