Какво събира Intercom Messenger

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

След като потребителят бъде идентифициран — обикновено чрез извикване на Intercom('boot', { user_id: ..., email: ... }) след удостоверяване — скриптът свързва идентичността на посетителя с известен Intercom контакт. История на разговори, атрибути и членство в сегментация — всичко това произтича от тази идентификация и Intercom използва връзката, за да задвижва автоматизирани кампании за съобщения, имейл за жизнен цикъл и продуктови обиколки в приложението.

Защо "Това е само чат widget" не ви освобождава от съгласие

Обичайно защитно рамкиране от продуктови екипи е, че Intercom е инструмент за обслужване на клиенти, а не маркетингов тракер, и че дейността по обслужване на клиенти е по-близо до "необходима за изпълнение на договор", отколкото до "маркетинг, изискващ съгласие". Рамкирането има тясна истина, но е широко погрешно на практика.

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

След като клиентът инициира чат разговор, обработката, свързана с този конкретен разговор, може разумно да бъде характеризирана като изпълнение на договор или преддоговорно изпълнение по GDPR Article 6(1)(b). Всичко преди тази точка — проследяването на прегледи на страници, докладването на присъствие, идентификацията на посетителя, автоматизираното съобщение, задвижвано от сегментация — не е. Това е аналитика и обработка с маркетингова цел, изискваща своя собствена законна основа.

Messenger се активира преди всякакъв разговор

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

Автоматизираните изходящи съобщения са маркетинг

Автоматизираните кампании за съобщения на Intercom, имейл за жизнен цикъл и поведенчески тригери са маркетингови комуникации. Те изискват своя собствена законна основа както по GDPR, така и, в САЩ, по CAN-SPAM и TCPA, където е приложимо.

Собствени контроли за поверителност на Intercom

Intercom предоставя полезен набор от собствени примитиви за поверителност. Както при други основни маркетингови платформи, те предполагат, че решение за съгласие съществува нагоре по веригата; те не го събират сами.

shutdown

Извикването Intercom('shutdown') прекратява активната сесия, изчиства локалните бисквитки и спира по-нататъшно проследяване. Съчетайте го с Intercom('boot'), когато потребителят приеме маркетинговата категория във вашия CMP.

Опцията hide_default_launcher

Задаването на hide_default_launcher: true скрива напълно чат балона без да разтоварва скрипта. Полезно за страници, където чатът не трябва да се предлага, но не е заместител на действителното предотвратяване на зареждането на скрипта.

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

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

Опцията за хостване на данни в EU

Intercom предлага хостване на данни в EU за акаунти, които го изискват, запазвайки данните за разговори и посетители в рамките на EU инфраструктурата. Това адресира значителна част от проблема с трансграничния трансфер, но не елиминира изискването за съгласие.

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

Надеждният модел е да се отложи инициализацията на Messenger, докато посетителят приеме маркетинговата категория, след това да се стартира Messenger с подходящия потребителски контекст. След като се инициализира, Messenger работи нормално; ако потребителят оттегли съгласието, Messenger се изключва чисто.

1. Премахнете стандартния Messenger snippet от head

Intercom предоставя инсталационен snippet, който инициализира Messenger при зареждане на страницата. Премахнете boot извикването от document head. Скрипт тагът може да остане (с type="text/plain" и data-category="marketing", ако вашият CMP използва този модел), но извикването Intercom('boot') трябва да се отложи.

2. Стартирайте Messenger от callback за съгласие

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

3. Осигурете ръчен чат тригер за потребители без съгласие

Клиент, който е отхвърлил маркетинговото проследяване, все още има право да се свърже с поддръжката. Предложете алтернативен път за чат — формуляр за контакт, имейл връзка или изричен бутон "Започни чат", който зарежда Messenger само когато бъде кликнат. Последният е най-чистият модел: изричното кликване на потребителя представлява съгласие за конкретната цел на чат разговора.

4. Обработете оттегляне

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

5. Използвайте хостване на данни в EU за EU акаунти

За акаунти, където резидентността на данните в EU има значение, конфигурирайте работното пространство на Intercom за EU хостване. Насочете EU трафика съответно; ако управлявате отделни работни пространства за EU и не-EU клиенти, интеграцията трябва да избере правилния app ID при стартиране.

Често срещани грешки

Четири интеграционни грешки се появяват многократно в одити на Intercom внедрявания.

Стартиране преди съгласие

Най-често срещаният дефект. Стандартната инсталация стартира Messenger при зареждане на страницата, което активира идентификацията на посетителя и проследяването на прегледи на страници преди всяко решение за съгласие. Поправката е ясна — отложете boot извикването към callback за съгласие — но стандартната документация за интеграция не обозначава това достатъчно ясно.

Третиране на shutdown като опционално

Ако потребител оттегли съгласие и Messenger не бъде изрично изключен, скриптът продължава да работи със своите сесийни бисквитки на място. CMP е записал оттеглянето, но основното проследяване продължава. Винаги свързвайте shutdown с оттегляне на съгласие.

Обединяване на поддръжка и маркетинг

Някои екипи оправдават зареждането на Messenger преди съгласие, като твърдят, че е "поддръжка, не маркетинг". Ако същият Messenger също изпълнява автоматизирани изходящи кампании или продуктови обиколки в приложението, линията не може да бъде начертана. Консервативният подход е да поставите Messenger изцяло под маркетинг и да осигурите отделен, необединен път за контакт с поддръжката за потребители, които отхвърлят маркетинга.

Игнориране на товари с персонализирани атрибути

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

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

Шест конкретни въпроса, на които да отговорите за всяко Intercom внедряване, докосващо EU, UK или трафик от Калифорния.

• Чака ли Messenger за съгласие? Отворете страницата в частен прозорец със строга защита от проследяване и потвърдете, че никакви intercom.io или intercomcdn.com заявки не се активират преди приемане на банера.
• Има ли път за поддръжка без Messenger? За потребители, които отхвърлят маркетинга, могат ли все още да се свържат с поддръжката чрез формуляр, имейл или изричен тригер за чат с кликване?
• Изключва ли оттеглянето Messenger? Потвърдете, че оттеглянето на съгласие извиква Intercom('shutdown') и изчиства локалните бисквитки.
• Минимизирани ли са персонализираните атрибути? Прегледайте товарите в Intercom('update') извиквания и премахнете всички данни, които не са функционално необходими на Messenger.
• Конфигурирано ли е хостването на данни в EU, където е необходимо? Потвърдете, че EU трафикът се насочва към работно пространство, хоствано в EU, с документация на решението за маршрутизация.
• Контролирани ли са изходящите кампании по съгласие? Потвърдете, че автоматизираните кампании за съобщения зачитат състоянието на маркетинговото съгласие на контакта и спират изпращането при оттегляне.

Къде се вписва Intercom в стек, първи по съгласие

Платформите за чат на живо и съобщения с клиенти заемат регулаторна сива зона, която доставчиците не са били желаели да подчертаят. Потокът от данни изглежда като аналитика и маркетингово проследяване; рамкирането подчертава обслужването на клиенти. Регулаторите са дали ясно да се разбере, че потокът от данни контролира анализа, а не рамкирането. Правилната архитектура третира Intercom Messenger като всеки друг идентифициращ скрипт на трета страна: поставете го зад съгласие, осигурете алтернативен път за контакт с поддръжката за потребители, които отхвърлят, използвайте собствения примитив shutdown на платформата, за да уважите оттеглянията, и конфигурирайте хостване на данни в EU, където резидентността има значение. Направено правилно, екипите за поддръжка запазват чата на живо и автоматизацията на жизнения цикъл, които правят Intercom ценен, докато основната позиция по съответствие спира да бъде тиха експозиция, чакаща одит да я изтъкне.