Повърхността за проследяване на SFMC

За целите на съгласието е полезно да третирате SFMC не като един продукт, а като четири припокриващи се повърхности за проследяване, всяка със свой собствен модел на интеграция.

Web Analytics Connector и Collect Tracking Code

Кодът за проследяване Collect (често наричан collect.js или референцииран чрез cdn.evgnet.com) е поведенческата проследяваща система на SFMC. Той задава бисквитките _etmc и свързани, идентифицира посетителите в сесии и предава събитията за преглед на страница, кликване и преобразуване към SFMC за използване в Journey Builder тригери и преориентиране на имейл. От регулаторна гледна точка това е ясно маркетинг проследявател — макар че събитията изглеждат като аналитика, данните захранват директна маркетинг автоматизация.

Скрипт на Marketing Cloud Personalization

Скриптът Personalization (наследство Interaction Studio) е по-тежък от Collect. Той зарежда SDK, който наблюдава целия DOM, събира данни за потока от кликвания и взаимодействие с формуляра и ги предава на двигател за персонализиране на решения, който може да пренаписва съдържанието на страницата в реално време. Бисквитките, които се задават, включват идентификатори _ev_* и маркер на сесия. Това е недвусмислено маркетинг обработка на цели и изисква предварително съгласие във всяка юрисдикция на ЕС или Великобритания.

CloudPages формуляри и проследени връзки

CloudPages хостваните целеви страници и проследените имейл връзки, които се маршрутват чрез SFMC, носят своите собствени идентифициращи параметри (параметри subscriberkey, jb, mid в URL-и). Когато посетител пристигне чрез проследена връзка, SFMC може да корелира сесията с неговия запис на абонат, дори преди да се активира какво-либо проследяване на страницата. Това е значително по-различна правна позиция от анонимното проследяване — идентичността на абоната е известна при първи контакт — и съгласието за маркетинг комуникации трябва вече да съществува.

Data Cloud конектори

Интеграцията на SFMC's Data Cloud (слой платформа за данни на клиента) дърпа идентификаторите от проследяване в интернет, мобилни SDK-и, CRM записи и офлайн данни в един единствен профил. Състоянието на съгласието трябва да се разпространи в Data Cloud, не само в пикселът за проследяване на повърхностното ниво, така че последващите активизации към рекламни мрежи да уважават предпочитанията на посетителя.

Родни контроли за неприкосновеност на SFMC

SFMC експонира няколко родни контроли, но както при повечето маркетинг платформи на предприятия, те предполагат, че решение за съгласие е събрано в горния поток и се прехвърля. Родните контроли не събират съгласие сами.

Отказ от проследяване за Web Analytics Connector

Скриптът Collect чете флаг do_not_track и конфигурируема функция за отказ. Задаването на тези предотвратява Collect от изпращане на данни, но не предотвратява самия скрипт от зареждане. За юрисдикции със предварително съгласие трябва да ограничите зареждането на скрипта, не просто да превключите флага.

Предпочитания за съгласие в записи на абонати

Профилът на абоната в SFMC има полета за съгласие за комуникация, съгласие за данни на профила и законния основание. Това са правилните примитиви за проследяване на правния основание, под който известен контакт се маркетира и CMP трябва да напише обратно в тези полета, когато посетител приема или отозова.

Съгласие на Marketing Cloud Personalization

SDK Personalization приема флаг за съгласие по време на инициализиране. Задайте го на false, докато потребителят е приел маркетинг категорията в CMP банера, след това преинициализирайте SDK при предоставянето на съгласието.

Интеграция на CMP стъпка по стъпка

Надежната архитектура е да ограничите всички четири повърхности за проследяване зад CMP и да използвате родните флагове на SFMC за уточняване на поведението по-долу по течението, както только съгласието е предоставено.

1. Спрете скрипта на Collect от зареждане по подразбиране

Премахнете скрипта Collect от главата на документа и го замените със заместител, който CMP може да активира. Когато посетителят приеме маркетинг категорията, CMP пренаписва заместителя, за да зареди collect.js. Всички събрани събития се изплащат при зареждане.

2. Отложете инициализирането на Marketing Cloud Personalization

Скриптът Personalization не трябва да инициализира преди съгласие. Повечето CMP-и го обработват с отложен модел на товар: елементът на скрипта присъства в DOM, но неговия атрибут type е text/plain и CMP го пренаписва на text/javascript при приемането на съгласието.

3. Ограничете параметрите за проследяване на CloudPages

Ако посетител пристигне чрез проследена връзка и все още не е дал съгласие, входящия параметър subscriberkey трябва да бъде прихванат, но не използван, за да движи незабавна персонализиране. Правилният модел е да го запазите в състояние на сесия и да го активирате (корелирайте с данни на профила, активизирайте Journey Builder събитията) едва след като съгласието е записано.

4. Разпространете състоянието на съгласието към Data Cloud

Интеграцията на Data Cloud трябва да знае състоянието на съгласието на всеки посетител, така че последващите активизации да го уважават. SFMC поддържа разширение на съгласие, което позволява на CMP да напише запис за съгласие в Data Cloud чрез API. Конфигурирайте това, така че решението за съгласие на CMP да стане източник на истина за целия слой SFMC, не само за скриптите на страницата.

5. Картографирайте на полета за съгласие на абонат SFMC

Когато известен абонат актуализира своето съгласие на предпочитания център CloudPages, CMP и записът на абонат SFMC трябва да останат синхронизирани. Конфигурирайте обратно писане от CMP към полетата за съгласие на абонат SFMC и конфигурирайте четене обратно, така че баннерът на страницата да уважава това, което абонатът е задал в своите предпочитания за имейл.

Често срещани пропуски

Три грешки при интеграция са отговорни за повечето предприятия пронаход на SFMC.

Третиране на Collect като аналитика

Тъй като скриптът Collect докладва преглади на страница и събитията на кликване, които изглеждат като аналитика, екипите понякога го ограничават под категорията съгласие за аналитика. SFMC използва тези данни, за да движи маркетинг автоматизиране на Journey Builder, което е недвусмислено маркетинг обработка на цели. Ограничете Collect под маркетинг.

Позволяване на Personalization да работи преди съгласие

Personalization е най-тежката от повърхностите за проследяване на SFMC и най-видима за регулатор, защото активно модифицира страницата. Позволяването му да инициализира преди съгласие е, в условията на одит, най-експозиционния модел в стека SFMC.

Неизвършване на синхронизация на съгласието в целия стек

Ако баннерът на страницата записа решение за съгласие, но профилът на Data Cloud запазва по-старо състояние, последващите активизации към рекламни мрежи ще продължат да се активизират въз основа на остарелото съгласие. CMP трябва да притежава източника на истина и да го разпространи навсякъде, където стекът SFMC може да стигне.

Контролен списък за одит

Пет конкретни въпроса за отговор за всяко внедряване на SFMC, докосващо трафик на ЕС, Великобритания или Калифорния.

• Collect чака ли съгласие? Потвърдете, че не се активизира никакъв collect.js или evgnet.com заявка преди приемането на банера.
• Е ли Personalization отложена? Потвърдете, че SDK на Personalization не инициализира, докато маркетинг категорията не бъде предоставена.
• Параметрите входящи проследени връзки се задържат ли до съгласие? Потвърдете, че персонализирането, движимо от subscriberkey, чака изричен сигнал за съгласие.
• Data Cloud вижда ли състояние на съгласието? Потвърдете, че разширението на съгласие е конфигурирано и CMP пише решения в Data Cloud в реално време.
• Полетата за съгласие на абонат синхронизирани ли са? Потвърдете, че промените на центъра за предпочитания се разпространяват към баннера на страницата и обратно.

Място на SFMC в стек, приоритизиран на съгласие

SFMC е един от най-мощните — и един от най-експозиционните — маркетинг платформи, които предприятие може да внедри. Модела на инсталиране по подразбиране просто не удовлетворява текущите очаквания на европейския или kalifornийския пазар и родните контроли на платформата са полезни примитиви, но не замяна на слой за управление на съгласие в горния поток. Правилната архитектура третира CMP като един единствен източник на истина, ограничава всеки модул за проследяване зад него и използва разширенията на съгласие на SFMC, за да направи Data Cloud и записите на абонати да разпространят тази истина в целия остатък на стека. Направено правилно, SFMC продължава да прави това, което маркетологите го купиха да прави — Journey Builder тригери, решение на Personalization, активизиране на Data Cloud — докато основната позиция за съответствие отговаря на това, което регулаторите сега очакват от всеки маркетолог на предприятие.