Що збирає Intercom Messenger

Скрипт Intercom Messenger (завантажений з widget.intercom.io або js.intercomcdn.com) ініціалізує глобальний об'єкт Intercom та ідентифікує відвідувачів за допомогою cookie intercom-id-* та intercom-session-*. З цього моменту він фіксує перегляди сторінок, час на сторінці, глибину прокрутки та метадані на рівні відвідувача: user agent, ОС, браузер, місцезнаходження на основі IP, реферер та будь-які користувацькі атрибути, які додаток передає через Intercom('boot', {...}) або Intercom('update', {...}). Функція присутності в реальному часі Messenger також безперервно повідомляє про активність відвідувача на сервери Intercom, поки сторінка відкрита, генеруючи один із найважчих потокових слідів даних серед інструментів обміну повідомленнями з клієнтами.

Після ідентифікації користувача — зазвичай шляхом виклику Intercom('boot', { user_id: ..., email: ... }) після автентифікації — скрипт пов'язує ідентичність відвідувача з відомим контактом Intercom. Історія розмов, атрибути та членство в сегментах — все це випливає з цієї ідентифікації, і Intercom використовує це з'єднання для запуску автоматизованих кампаній повідомлень, email життєвого циклу та продуктових турів у додатку.

Чому «Це просто віджет чату» не звільняє від згоди

Поширена захисна позиція продуктових команд полягає в тому, що Intercom — це інструмент обслуговування клієнтів, а не маркетинговий трекер, і що діяльність обслуговування клієнтів ближча до «необхідної для виконання контракту», ніж до «маркетингу, що потребує згоди». Це формулювання має вузьку правду, але загалом є хибним на практиці.

Відстеження до розмови не є виконанням контракту

Коли клієнт ініціює чат-розмову, обробку, пов'язану з цією конкретною розмовою, можна обґрунтовано охарактеризувати як виконання контракту або переддоговірне виконання за GDPR Article 6(1)(b). Все до цього моменту — відстеження переглядів сторінок, звітування про присутність, ідентифікація відвідувача, автоматичне повідомлення на основі сегментації — ні. Це аналітика та обробка з маркетинговою метою, що потребує власної правової підстави.

Messenger запускається до будь-якої розмови

Стандартна поведінка скрипта — ініціалізуватися при завантаженні сторінки та негайно починати збирати дані, задовго до того, як відвідувач натисне на бульбашку чату. Яка б правова підстава не покривала активний сеанс чату, вона не покриває дані, зібрані в період до розмови.

Автоматичні вихідні повідомлення — це маркетинг

Автоматизовані кампанії повідомлень Intercom, email життєвого циклу та поведінкові тригери є маркетинговими комунікаціями. Вони потребують власної правової підстави як за GDPR, так і в США за CAN-SPAM та TCPA, де це застосовно.

Нативні засоби конфіденційності Intercom

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

shutdown

Виклик Intercom('shutdown') завершує активний сеанс, очищує локальні cookie та припиняє подальше відстеження. Поєднуйте його з Intercom('boot'), коли користувач приймає маркетингову категорію у вашому CMP.

Опція hide_default_launcher

Встановлення hide_default_launcher: true повністю приховує бульбашку чату без вивантаження скрипта. Корисно для сторінок, де чат не повинен пропонуватися, але не є заміною фактичного запобігання завантаженню скрипта.

Контроль зберігання даних

Налаштування адміністратора Intercom включають конфігуровані вікна зберігання для даних відвідувачів, історії розмов та журналів подій. Їх скорочення є заходом глибокого захисту поверх блокування на рівні CMP.

Опція хостингу даних у EU

Intercom пропонує хостинг даних у EU для облікових записів, яким це потрібно, зберігаючи дані розмов і відвідувачів в інфраструктурі EU. Це вирішує значну частину проблеми транскордонної передачі, але не усуває вимогу згоди.

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

Надійний шаблон — відкласти ініціалізацію Messenger до моменту, коли відвідувач прийме маркетингову категорію, а потім запустити Messenger з відповідним контекстом користувача. Після ініціалізації Messenger працює нормально; якщо користувач відкликає згоду, Messenger коректно завершує роботу.

1. Видаліть стандартний фрагмент Messenger з head

Intercom надає фрагмент встановлення, який ініціалізує Messenger при завантаженні сторінки. Видаліть виклик boot з head документа. Тег script може залишитися (з type="text/plain" та data-category="marketing", якщо ваш CMP використовує цей шаблон), але виклик Intercom('boot') має бути відкладений.

2. Запустіть Messenger з колбека згоди

Коли CMP запускає подію прийняття маркетингу, перепишіть тип скрипта назад на text/javascript, дозвольте йому завантажитися, а потім викличте Intercom('boot', { app_id: ... }). Якщо користувач автентифікований, включіть ідентифікуючі параметри у виклик boot.

3. Надайте ручний тригер чату для користувачів без згоди

Клієнт, який відхилив маркетингове відстеження, все одно має право звернутися до підтримки. Запропонуйте альтернативний шлях чату — контактну форму, посилання на email або явну кнопку «Почати чат», яка завантажує Messenger лише при натисканні. Останній варіант є найчистішим шаблоном: явний клік користувача становить згоду для конкретної мети чат-розмови.

4. Обробіть відкликання

Коли користувач відкликає маркетингову згоду, викличте Intercom('shutdown'). Це очищує локальні cookie та припиняє відстеження. Збережіть оновлений стан згоди, щоб наступні завантаження сторінок його дотримувалися.

5. Використовуйте хостинг даних у EU для облікових записів EU

Для облікових записів, де має значення резидентність даних у EU, налаштуйте робочий простір Intercom на хостинг у EU. Маршрутизуйте трафік EU відповідно; якщо ви використовуєте окремі робочі простори для клієнтів EU та не-EU, інтеграція повинна вибирати правильний app ID при запуску.

Типові помилки

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

Запуск до згоди

Найпоширеніший дефект. Стандартне встановлення запускає Messenger при завантаженні сторінки, що активує ідентифікацію відвідувача та відстеження переглядів сторінок до будь-якого рішення про згоду. Виправлення просте — відкласти виклик boot до колбека згоди — але стандартна документація з інтеграції не вказує на це достатньо чітко.

Ставлення до shutdown як до необов'язкового

Якщо користувач відкликає згоду, а Messenger явно не завершений, скрипт продовжує працювати з його сеансовими cookie на місці. CMP зафіксував відкликання, але базове відстеження продовжується. Завжди пов'язуйте shutdown з відкликанням згоди.

Об'єднання підтримки та маркетингу

Деякі команди виправдовують завантаження Messenger до згоди, стверджуючи, що це «підтримка, а не маркетинг». Якщо той самий Messenger також запускає автоматичні вихідні кампанії або продуктові тури в додатку, провести межу неможливо. Консервативний підхід — повністю заблокувати Messenger під маркетингом і надати окремий, незалежний шлях контакту з підтримкою для користувачів, які відхиляють маркетинг.

Ігнорування корисних навантажень користувацьких атрибутів

Дані, передані у викликах Intercom('update') — користувацькі атрибути, рівень підписки, вік облікового запису, внутрішні ідентифікатори користувача — є персональними даними, пересланими до Intercom. Перевіряйте ці корисні навантаження на надмірне поширення; багато інтеграцій передають більше ідентифікуючих даних, ніж функціонально потребує Messenger.

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

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

• Чи чекає Messenger на згоду? Відкрийте сторінку в приватному вікні зі строгим захистом від відстеження та переконайтеся, що жодні запити до intercom.io або intercomcdn.com не виконуються до прийняття банера.
• Чи є шлях підтримки без Messenger? Для користувачів, які відхиляють маркетинг, чи можуть вони все одно зв'язатися з підтримкою через форму, email або явний тригер чату натисканням?
• Чи завершує відкликання роботу Messenger? Переконайтеся, що відкликання згоди викликає Intercom('shutdown') та очищує локальні cookie.
• Чи мінімізовані користувацькі атрибути? Перевірте корисні навантаження у викликах Intercom('update') та видаліть будь-які дані, функціонально не потрібні Messenger.
• Чи налаштований хостинг даних у EU, де це потрібно? Переконайтеся, що трафік EU маршрутизується до робочого простору, розміщеного в EU, з документацією рішення щодо маршрутизації.
• Чи заблоковані вихідні кампанії на згоду? Переконайтеся, що автоматизовані кампанії повідомлень дотримуються стану маркетингової згоди контакту та припиняють надсилання при відкликанні.

Місце Intercom у стеку з пріоритетом згоди

Платформи живого чату та обміну повідомленнями з клієнтами займають регуляторну сіру зону, яку постачальники не поспішали висвітлювати. Потік даних виглядає як аналітика та маркетингове відстеження; позиціонування наголошує на обслуговуванні клієнтів. Регулятори чітко дали зрозуміти, що аналіз визначає потік даних, а не позиціонування. Правильна архітектура ставиться до Intercom Messenger як до будь-якого іншого ідентифікуючого стороннього скрипта: блокує його за згодою, надає альтернативний шлях зв'язку з підтримкою для користувачів, які відмовляються, використовує нативний примітив shutdown платформи для дотримання відкликань та налаштовує хостинг даних у EU, де має значення резидентність. При правильному виконанні команди підтримки зберігають живий чат та автоматизацію життєвого циклу, які роблять Intercom цінним, тоді як базова позиція відповідності перестає бути тихою вразливістю, що чекає на аудит, щоб її виявити.