Що збирає відстеження Klaviyo Onsite

Сніпет Klaviyo Onsite (завантажений з static.klaviyo.com/onsite/js/klaviyo.js) ініціалізує глобальну чергу _learnq та ідентифікує відвідувачів за допомогою кукі __kla_id, що належить Klaviyo. Після встановлення він автоматично звітує про перегляди сторінок, фіксує взаємодії з формами, генерує подію Active On Site, яка керує потоком Browse Abandonment у Klaviyo, та прив'язує анонімну поведінку перегляду до відомого профілю підписника в момент, коли відвідувач входить в систему або надсилає форму з електронною адресою. Подальші події — Viewed Product, Added to Cart, Started Checkout, Placed Order — проходять через ту саму інфраструктуру ідентифікації та успадковують ту саму атрибуцію на основі кукі.

Для аналізу за GDPR кукі є несуттєвим, дані, що залишають сторінку, є персональними даними, оскільки прив'язані до постійного ідентифікатора, а Klaviyo зареєстрований у Сполучених Штатах, що робить передачу даних предметом регулювання EU-US Data Privacy Framework. Усі три умови однозначно відносять відстеження Klaviyo Onsite до категорії «вимагає попередньої згоди» в EU, UK, EEA та Бразилії згідно з LGPD. У Каліфорнії та сама обробка підпадає під право відмови від передачі даних для крос-контекстної поведінкової реклами згідно з CPRA, яке активується через передачу даних Klaviyo до платформ платної реклами.

Три поверхні відстеження, які потрібно контролювати

Встановлення Klaviyo — це не одна поверхня відстеження, а три, і їх потрібно обробляти окремо при інтеграції з CMP.

Скрипт відстеження Onsite

Це основний поведінковий трекер — скрипт, який встановлює __kla_id та керує потоком подій active-on-site. Це поверхня, яку більшість команд пам'ятає контролювати, і вона найпомітніша для регуляторів під час аудиту. Блокуйте його за замовчуванням і завантажуйте лише тоді, коли відвідувач приймає категорію маркетингу.

Klaviyo Forms та спливаючі вікна підписки

Klaviyo Forms — це окрема бібліотека, яка забезпечує роботу спливаючих вікон підписки на email та SMS, вбудованих форм та розблокування контенту. Вона розміщена на тому ж домені, але завантажується як окремий скрипт. Форми можуть генерувати події показу та відправлення незалежно від основного трекера Onsite, тому контроль лише Onsite при завантаженому Forms — це поширений шаблон часткової відповідності, який все одно витікає ідентифікуючі дані.

Збір підписок на SMS

Підписки на SMS мають власні вимоги щодо згоди згідно з TCPA у США та згідно з галузевими правилами в EU, а форми SMS від Klaviyo збирають номери телефонів разом із підтвердженою прапорцем згодою. Зібрана тут згода стосується самих SMS-повідомлень, окремо від згоди на кукі. Правильно налаштований стек записує обидва: згоду на кукі в CMP, згоду на SMS у профілі підписника Klaviyo.

Вбудовані засоби конфіденційності Klaviyo

Klaviyo надає кілька вбудованих механізмів конфіденційності. Як і в більшості маркетингових платформ, вони припускають, що рішення про згоду вже існує і передається ззовні. Вони не збирають згоду самостійно.

Властивість consent у викликах identify

Коли ви викликаєте klaviyo.identify() або klaviyo.track(), ви можете додати дані про згоду, які фіксують правову підставу для маркетингових комунікацій. Це правильний механізм для передачі рішення CMP у профіль підписника Klaviyo.

Поля згоди на рівні профілю

Профіль підписника має виділені поля для згоди на email, згоди на SMS та джерела згоди. Оновлення цих полів поширюються на механізм сегментації Klaviyo, щоб потоки враховували зафіксований стан.

Панель налаштувань Privacy & Consent

Адмін-панель Klaviyo має розділ Privacy & Consent, який контролює деякі поведінки за замовчуванням — наприклад, чи генерується подія Active On Site для відвідувачів без зафіксованої згоди. За замовчуванням налаштування дозвільне; посилення цих параметрів є корисним додатковим рівнем захисту поверх контролю на рівні CMP.

Покрокова інтеграція з CMP

Надійна архітектура полягає в тому, щоб контролювати всі три поверхні відстеження Klaviyo через CMP та використовувати властивості згоди у викликах Klaviyo identify і track для синхронізації записів підписників платформи із зафіксованим станом згоди.

1. Видаліть стандартний сніпет Onsite з head

Klaviyo надає однорядковий сніпет, який інсталятори зазвичай вставляють у head документа. Видаліть його. Замініть його на елемент-заповнювач script, атрибут type якого встановлений як text/plain, а атрибут data-category ідентифікує його як маркетинговий. Ваша CMP перепише type назад на text/javascript, коли відвідувач прийме категорію маркетингу.

2. Відкладіть завантаження Klaviyo Forms

Бібліотека Forms завантажується незалежно від Onsite. Застосуйте той самий шаблон заповнювача до її елемента script, щоб вона не ініціалізувалася до отримання згоди. Після надання згоди і Onsite, і Forms можуть ініціалізуватися разом; події з черги автоматично відправляються.

3. Відокремте згоду на SMS від згоди на кукі

Збір підписок на SMS працює через Klaviyo Forms, але зібрана згода (явний прапорець для SMS-маркетингу) є окремим юридичним артефактом від згоди на кукі. Банер CMP фіксує рішення щодо кукі; прапорець форми фіксує рішення щодо SMS. Не об'єднуйте їх — об'єднана згода недійсна як за GDPR, так і за TCPA.

4. Передайте згоду в профіль Klaviyo

Коли відомий підписник приймає або відкликає згоду на вашому сайті, CMP повинна викликати API Klaviyo для оновлення полів згоди профілю. API профілів Klaviyo підтримує виклик часткового оновлення, який записує згоду на email, згоду на SMS та мітку часу згоди без перезапису решти профілю. Більшість сучасних CMP мають конектор Klaviyo, який забезпечує це наскрізно.

5. Підключіть Consent Mode v2, якщо ви використовуєте теги Google паралельно

Більшість магазинів, що використовують Klaviyo, також запускають Google Ads та GA4. Ваша CMP повинна публікувати сигнали v2 згоди — ad_storage, analytics_storage, ad_user_data, ad_personalization — у dataLayer до того, як спрацює будь-який тег Google. Klaviyo не споживає ці сигнали нативно, але Google це робить, і невідповідність між Klaviyo та Google проявиться як вимірюваний розрив доходу в звітності атрибуції.

Поширені помилки

Чотири помилки інтеграції регулярно з'являються під час аудитів розгортань Klaviyo.

Ставлення до Forms як до «просто спливаючого вікна»

Деякі команди контролюють Onsite у категорії маркетингу, але залишають Forms завантаженим при першому рендері, аргументуючи тим, що «спливаюче вікно — це просто елемент інтерфейсу». Бібліотека Forms генерує події показу в Klaviyo для кожного відображеного спливаючого вікна, що є ідентифікуючими поведінковими даними, переданими до американського ad-tech постачальника — саме той шаблон, який CMP повинна запобігати.

Об'єднання згоди на кукі та SMS

Єдиний прапорець із текстом «Я погоджуюсь на кукі та на отримання маркетингових SMS» недійсний для обох. Згода на кукі повинна бути специфічною для кукі; згода на SMS повинна бути специфічною для SMS. Використовуйте окремі елементи керування.

Дозвіл конекторам платної реклами працювати з відкликаними профілями

Klaviyo може передавати аудиторії в Google Ads, Meta, TikTok та інші рекламні мережі через свої інтеграції. Якщо підписник відкликає згоду, передача аудиторій повинна виключити його — а не просто припинити додавання. Налаштуйте параметри синхронізації аудиторій Klaviyo для врахування змін стану згоди в реальному часі, а не лише при початковій синхронізації.

Забування питання історичних даних

Коли відвідувач вперше надає згоду, ваш стек не повинен ретроактивно прив'язувати його анонімну поведінку до згоди до нового профілю. CMP та Klaviyo повинні погодитися, що дані перегляду до згоди не є персональними даними, прив'язаними до щойно ідентифікованого профілю. Деякі потоки Klaviyo припускають цю асоціацію за замовчуванням — перегляньте відповідні тригери потоків.

Контрольний список аудиту

Шість конкретних питань, на які потрібно відповісти для будь-якого розгортання Klaviyo, що обслуговує трафік з EU, UK, Бразилії чи Каліфорнії.

• Чи чекає Onsite на згоду? Відкрийте вітрину магазину у приватному вікні з суворим захистом від відстеження та підтвердіть, що жодні запити до static.klaviyo.com не відправляються до прийняття банера.
• Чи чекає Forms на згоду? Підтвердіть, що події показу спливаючих вікон не генеруються до прийняття категорії маркетингу.
• Чи розділені згода на кукі та SMS? Підтвердіть, що банер кукі не збирає також згоду на SMS, і що форми підписки на SMS мають власний явний прапорець.
• Чи відображає профіль Klaviyo стан CMP? Підтвердіть, що CMP записує рішення про згоду в поля згоди профілю через API Klaviyo.
• Чи враховують синхронізації аудиторій відкликання? Підтвердіть, що відкликання згоди видаляє підписника з аудиторій платної реклами, а не лише з майбутніх синхронізацій.
• Чи зберігається анонімність перегляду до згоди? Підтвердіть, що тригери потоків не прив'язують ретроактивно поведінку до згоди до щойно ідентифікованих профілів.

Місце Klaviyo у стеку, орієнтованому на згоду

Klaviyo знаходиться на перетині атрибуції електронної комерції та прямих маркетингових комунікацій, що означає, що він торкається як режиму згоди на кукі (GDPR/ePrivacy, CCPA/CPRA), так і режиму маркетингових комунікацій (CAN-SPAM, TCPA, стаття 6/7 GDPR для повідомлень). Правильна архітектура розглядає їх як дві окремі поверхні згоди — обидві маршрутизовані через єдину CMP, яка є джерелом істини, з нативними полями згоди Klaviyo, синхронізованими через API. Магазини, які роблять це правильно, зберігають поведінку покинутих кошиків, покинутого перегляду та сегментації, яка робить Klaviyo комерційно цінним, водночас зменшуючи ризик аудиту до малої частки того, що несе стандартне встановлення. Інженерна робота проста; дисципліна полягає в тому, щоб не дозволяти маркетинговій команді розглядати Forms як виняток із тих самих правил, що й трекер Onsite.