Wat de Intercom Messenger Verzamelt

Het Intercom Messenger-script (geladen van widget.intercom.io of js.intercomcdn.com) initialiseert een globaal Intercom-object en identificeert bezoekers met de cookies intercom-id-* en intercom-session-*. Vanaf dat moment legt het paginaweergaven, tijd op de pagina, scrolldiepte en bezoekersmetadata vast: user agent, OS, browser, IP-afgeleid locatie, referrer en eventuele aangepaste attributen die de applicatie doorgeeft via Intercom('boot', {...}) of Intercom('update', {...}). De realtime aanwezigheidsfunctie van Messenger rapporteert ook continu bezoekersactiviteit terug naar de servers van Intercom terwijl de pagina open is, waardoor een van de zwaardere streaming-datavoetafdrukken onder klantenberichtentools ontstaat.

Zodra een gebruiker is geïdentificeerd — meestal door Intercom('boot', { user_id: ..., email: ... }) aan te roepen na authenticatie — koppelt het script de bezoekersidentiteit aan een bekende Intercom-contact. Gespreksgeschiedenis, attributen en segmentatiememberschap vloeien allemaal voort uit deze identificatie, en Intercom gebruikt de koppeling om geautomatiseerde berichtcampagnes, levenscyclus-e-mails en in-app producttours aan te sturen.

Waarom "Het is Maar een Chatwidget" Je Niet Vrijstelt van Toestemming

Een veelgehoord defensief argument van productteams is dat Intercom een klantenservicetool is, geen marketingtracker, en dat klantenserviceactiviteit dichter bij "noodzakelijk voor contractuitvoering" staat dan bij "marketing waarvoor toestemming nodig is". Het argument heeft een smalle kern van waarheid maar is in de praktijk grotendeels onjuist.

Pre-gesprekstracking is geen contractuitvoering

Zodra een klant een chatgesprek initieert, kan de verwerking die betrekking heeft op dat specifieke gesprek redelijkerwijs worden gekarakteriseerd als contract- of pre-contractuitvoering onder GDPR Article 6(1)(b). Alles daarvoor — de paginaweergavetracking, de aanwezigheidsrapportage, de bezoekersidentificatie, het segmentatie-gedreven geautomatiseerde bericht — is dat niet. Het is analytische en marketinggerichte verwerking die een eigen rechtsgrondslag vereist.

De Messenger activeert vóór elk gesprek

Het standaardgedrag van het script is om bij het laden van de pagina te initialiseren en onmiddellijk data te verzamelen, lang voordat de bezoeker op de chatbubbel heeft geklikt. Welke rechtsgrondslag een actieve chatsessie ook dekt, het dekt niet de data die in de pre-gespreksperiode is verzameld.

Geautomatiseerde uitgaande berichten zijn marketing

De geautomatiseerde berichtcampagnes van Intercom, levenscyclus-e-mails en gedragstriggers zijn marketingcommunicaties. Ze vereisen hun eigen rechtsgrondslag onder zowel de GDPR als, in de VS, CAN-SPAM en TCPA waar van toepassing.

Eigen Privacycontroles van Intercom

Intercom biedt een nuttige set eigen privacyprimitieven. Net als andere grote marketingplatforms gaan ze ervan uit dat een toestemmingsbeslissing stroomopwaarts bestaat; ze verzamelen het zelf niet.

shutdown

De aanroep Intercom('shutdown') beëindigt de actieve sessie, wist de lokale cookies en stopt verdere tracking. Koppel het aan Intercom('boot') wanneer de gebruiker de marketingcategorie in je CMP accepteert.

De optie hide_default_launcher

Het instellen van hide_default_launcher: true verbergt de chatbubbel volledig zonder het script te verwijderen. Handig voor pagina's waar chat niet aangeboden moet worden, maar geen vervanging voor daadwerkelijk voorkomen dat het script laadt.

Dataretentiecontroles

De beheerdersinstellingen van Intercom bevatten configureerbare retentievensters voor bezoekersdata, gespreksgeschiedenis en event-logs. Deze aanscherpen is een verdedigings-in-de-diepte maatregel bovenop de CMP-niveau gating.

De EU Data Hosting-optie

Intercom biedt EU-datahosting voor accounts die dat vereisen, waarbij gespreks- en bezoekersdata binnen de EU-infrastructuur wordt gehouden. Dit pakt een betekenisvol deel van de grensoverschrijdende overdrachtscontext aan, maar elimineert de toestemmingsvereiste niet.

Stapsgewijze CMP-integratie

Het betrouwbare patroon is om de Messenger-initialisatie uit te stellen totdat de bezoeker de marketingcategorie accepteert, daarna de Messenger op te starten met de juiste gebruikerscontext. Eenmaal geïnitialiseerd werkt de Messenger normaal; als de gebruiker de toestemming intrekt, wordt de Messenger netjes afgesloten.

1. Verwijder het standaard Messenger-fragment uit de head

Intercom biedt een installatiefragment dat de Messenger bij het laden van de pagina initialiseert. Verwijder de boot-aanroep uit de documenthead. De scripttag kan blijven (met type="text/plain" en data-category="marketing" als je CMP dat patroon gebruikt), maar de aanroep van Intercom('boot') moet worden uitgesteld.

2. Start Messenger op vanuit de toestemmings-callback

Wanneer de CMP zijn marketing-geaccepteerd event activeert, herschrijf het scripttype terug naar text/javascript, laat het laden en roep vervolgens Intercom('boot', { app_id: ... }) aan. Als de gebruiker is geauthenticeerd, neem de identificerende parameters op in de boot-aanroep.

3. Bied een handmatige chattrigger voor niet-toestemmende gebruikers

Een klant die marketingtracking heeft geweigerd heeft nog steeds recht op contact met de ondersteuning. Bied een alternatief chatpad aan — een contactformulier, een e-maillink of een expliciete "Start chat"-knop die de Messenger alleen laadt wanneer erop geklikt wordt. Het laatste is het schoonste patroon: de expliciete klik van de gebruiker vormt toestemming voor het specifieke doel van het chatgesprek.

4. Verwerk intrekking

Wanneer de gebruiker de marketingtoestemming intrekt, roep Intercom('shutdown') aan. Dit wist de lokale cookies en stopt de tracking. Bewaar de bijgewerkte toestemmingsstatus zodat volgende paginalaadacties dit respecteren.

5. Gebruik EU-datahosting voor EU-accounts

Voor accounts waarbij EU-dataresidentie van belang is, configureer de Intercom-workspace voor EU-hosting. Routeer EU-verkeer dienovereenkomstig; als je aparte workspaces beheert voor EU- en niet-EU-klanten, moet de integratie het juiste app ID kiezen bij het opstarten.

Veelvoorkomende Valkuilen

Vier integratiefouten duiken herhaaldelijk op in audits van Intercom-implementaties.

Opstarten vóór toestemming

Het meest voorkomende gebrek. De standaardinstallatie start de Messenger bij het laden van de pagina, wat de bezoekersidentificatie en paginaweergavetracking activeert vóór enige toestemmingsbeslissing. De remedie is eenvoudig — stel de boot-aanroep uit naar de toestemmings-callback — maar de standaard integratiedocumentatie markeert dit niet duidelijk genoeg.

Shutdown behandelen als optioneel

Als een gebruiker de toestemming intrekt en de Messenger niet expliciet wordt afgesloten, blijft het script draaien met zijn sessiecookies. De CMP heeft de intrekking geregistreerd maar de onderliggende tracking gaat door. Koppel shutdown altijd aan de intrekking van toestemming.

Ondersteuning en marketing bundelen

Sommige teams rechtvaardigen het laden van de Messenger vóór toestemming door te argumenteren dat het "ondersteuning is, geen marketing". Als dezelfde Messenger ook geautomatiseerde uitgaande campagnes of in-app producttours uitvoert, kan de grens niet worden getrokken. De conservatieve aanpak is de Messenger volledig onder marketing te plaatsen en een apart, niet-gebundeld ondersteuningscontactpad te bieden voor gebruikers die marketing weigeren.

Aangepaste attributie-payloads negeren

De data die wordt doorgegeven in Intercom('update')-aanroepen — aangepaste gebruikersattributen, abonnementsniveau, accountleeftijd, interne gebruikersidentificatoren — zijn persoonsgegevens die naar Intercom worden doorgezonden. Controleer deze payloads op te veel delen; veel integraties geven meer identificerende data door dan de Messenger functioneel nodig heeft.

Auditchecklist

Zes concrete vragen om te beantwoorden voor elke Intercom-implementatie die EU-, UK- of Californisch verkeer raakt.

• Wacht de Messenger op toestemming? Open de pagina in een privévenster met strikte trackingbescherming en bevestig dat er geen intercom.io- of intercomcdn.com-verzoeken worden geactiveerd vóór banneracceptatie.
• Is er een niet-Messenger-ondersteuningspad? Voor gebruikers die marketing weigeren, kunnen ze nog steeds contact opnemen met ondersteuning via een formulier, e-mail of een expliciete-klik chattrigger?
• Sluit intrekking de Messenger af? Bevestig dat het intrekken van toestemming Intercom('shutdown') aanroept en lokale cookies wist.
• Zijn aangepaste attributen geminimaliseerd? Bekijk de payloads in Intercom('update')-aanroepen en verwijder alle data die functioneel niet vereist is door de Messenger.
• Is EU-datahosting geconfigureerd waar vereist? Bevestig dat EU-verkeer wordt gerouteerd naar een EU-gehoste workspace, met documentatie van de routeringsbeslissing.
• Zijn uitgaande campagnes geblokkeerd op toestemming? Bevestig dat geautomatiseerde berichtcampagnes de marketingtoestemmingsstatus van het contact respecteren en stoppen met verzenden bij intrekking.

Waar Intercom Past in een Toestemming-Eerst Stack

Live-chat- en klantenberichtenplatforms bevinden zich in een regulatoire grijze zone die leveranciers niet gretig hebben belicht. De datastroom ziet eruit als analytische en marketingtracking; het kader benadrukt klantenservice. Toezichthouders hebben duidelijk gemaakt dat de datastroom de analyse bepaalt, niet het kader. De juiste architectuur behandelt de Intercom Messenger als elk ander identificerend third-party script: plaats het achter toestemming, bied een alternatief ondersteuningscontactpad voor gebruikers die weigeren, gebruik het eigen shutdown-primitief van het platform om intrekkingen te respecteren en configureer EU-datahosting waar residentie van belang is. Correct uitgevoerd behouden ondersteuningsteams de live chat en levenscyclusautomatisering die Intercom waardevol maakt, terwijl de onderliggende nalevingspositie ophoudt een stille blootstelling te zijn die wacht op een audit om aan het licht te komen.