Çfarë Mbledh Intercom Messenger

Skripti Intercom Messenger (i ngarkuar nga widget.intercom.io ose js.intercomcdn.com) inicializon një objekt global Intercom dhe identifikon vizitorët me cookie-t intercom-id-* dhe intercom-session-*. Nga ai moment kap shikimet e faqeve, kohën në faqe, thellësinë e lëvizjes dhe metadata në nivel vizitori: user agent, OS, shfletues, vendndodhje të derivuar nga IP, referrer, dhe çdo atribut të personalizuar që aplikacioni kalon nëpërmjet Intercom('boot', {...}) ose Intercom('update', {...}). Funksioni i pranisë në kohë reale i Messenger gjithashtu raporton aktivitetin e vizitorit vazhdimisht te serverët e Intercom ndërsa faqja është e hapur, duke gjeneruar një nga gjurmët më të rënda të të dhënave në transmetim midis mjeteve të mesazheve për klientët.

Pasi një përdorues identifikohet — zakonisht duke thirrur Intercom('boot', { user_id: ..., email: ... }) pas autentifikimit — skripti lidh identitetin e vizitorit me një kontakt të njohur Intercom. Historia e bisedave, atributet dhe anëtarësia në segmente rrjedhin të gjitha nga ky identifikim, dhe Intercom e përdor lidhjen për të drejtuar fushata mesazhesh të automatizuara, email të ciklit jetësor dhe turne produkti brenda aplikacionit.

Pse "Është Thjesht një Widget Chat" Nuk Ju Shpëton nga Pëlqimi

Një arsyetim i zakonshëm mbrojtës nga ekipet e produktit është se Intercom është një mjet shërbimi ndaj klientit, jo një gjurmues marketingu, dhe se aktiviteti i shërbimit ndaj klientit qëndron më afër "të nevojshëm për ekzekutimin e kontratës" sesa "marketing që kërkon pëlqim". Arsyetimi ka të vërtetë të ngushtë por është gjerësisht i gabuar në praktikë.

Gjurmimi para bisedës nuk është ekzekutim kontrate

Pasi një klient fillon një bisedë chat, përpunimi i lidhur me atë bisedë specifike mund të karakterizohet arsyeshëm si ekzekutim kontrate ose para-kontrate sipas GDPR Article 6(1)(b). Gjithçka para atij pikë — gjurmimi i shikimeve të faqeve, raportimi i pranisë, identifikimi i vizitorit, mesazhi i automatizuar i drejtuar nga segmentimi — nuk është. Është përpunim për qëllime analitike dhe marketingu që kërkon bazën e vet ligjore.

Messenger ekzekutohet para çdo bisede

Sjellja e paracaktuar e skriptit është të inicializohet në ngarkimin e faqes dhe të fillojë mbledhjen e të dhënave menjëherë, shumë para se vizitori të ketë klikuar fluskën e chat-it. Çfarëdo baze ligjore që mbulon një sesion aktiv chat nuk mbulon të dhënat e mbledhura në periudhën para bisedës.

Mesazhet dalëse të automatizuara janë marketing

Fushatat e mesazheve të automatizuara të Intercom, email-i i ciklit jetësor dhe nxitësit e sjelljes janë komunikime marketingu. Ato kërkojnë bazën e tyre ligjore si sipas GDPR ashtu edhe, në SHBA, CAN-SPAM dhe TCPA ku zbatohen.

Kontrollet Vendase të Privatësisë së Intercom

Intercom ekspozon një grup të dobishëm primitivash vendase të privatësisë. Si me platformat e tjera kryesore të marketingut, ato supozojnë se një vendim pëlqimi ekziston në rrjedhën e sipërme; ato nuk e mbledhin vetë.

shutdown

Thirrja Intercom('shutdown') përfundon sesionin aktiv, pastron cookie-t lokale dhe ndalon gjurmimin e mëtejshëm. Çiftojeni me Intercom('boot') kur përdoruesi pranon kategorinë e marketingut në CMP-në tuaj.

Opsioni hide_default_launcher

Vendosja e hide_default_launcher: true fsheh fluskën e chat-it plotësisht pa shkarkuar skriptin. E dobishme për faqet ku chat-i nuk duhet ofruar, por jo zëvendësim për parandalimin aktual të ngarkimit të skriptit.

Kontrollet e ruajtjes së të dhënave

Cilësimet e administratorit të Intercom përfshijnë dritare të konfigurueshme ruajtjeje për të dhënat e vizitorëve, historinë e bisedave dhe regjistrat e ngjarjeve. Shtrëngimi i tyre është një masë mbrojtëse në thellësi mbi bllokimin në nivel CMP.

Opsioni i Hostimit të të Dhënave në EU

Intercom ofron hostim të dhënash në EU për llogaritë që e kërkojnë, duke mbajtur të dhënat e bisedave dhe vizitorëve brenda infrastrukturës së EU. Kjo adreson një pjesë kuptimplotë të shqetësimit për transfertën ndërkufitare por nuk eliminon kërkesën për pëlqim.

Integrimi Hap pas Hapi me CMP

Modeli i besueshëm është të shtyhet inicializimi i Messenger derisa vizitori të pranojë kategorinë e marketingut, pastaj të boot-ohet Messenger me kontekstin e duhur të përdoruesit. Pasi inicializohet, Messenger funksionon normalisht; nëse përdoruesi revokon pëlqimin, Messenger mbyllet pastër.

1. Hiqni snippet-in e paracaktuar të Messenger nga head

Intercom ofron një snippet instalimi që inicializon Messenger në ngarkimin e faqes. Hiqni thirrjen boot nga head i dokumentit. Tag-u i skriptit mund të mbetet (me type="text/plain" dhe data-category="marketing" nëse CMP-ja juaj përdor atë model), por thirrja Intercom('boot') duhet të shtyhet.

2. Boot-oni Messenger nga callback-u i pëlqimit

Kur CMP-ja ekzekuton ngjarjen e pranimit të marketingut, rishkruani tipin e skriptit përsëri në text/javascript, lëreni të ngarkohet, dhe pastaj thirrni Intercom('boot', { app_id: ... }). Nëse përdoruesi është i autentifikuar, përfshini parametrat identifikues në thirrjen boot.

3. Ofroni një nxitës manual chat për përdoruesit pa pëlqim

Një klient që ka refuzuar gjurmimin e marketingut ka ende të drejtë të kontaktojë mbështetjen. Ofroni një rrugë alternative chat — një formular kontakti, një lidhje email, ose një buton eksplicit "Fillo chat-in" që ngarkon Messenger vetëm kur klikohet. Ky i fundit është modeli më i pastër: klikimi eksplicit i përdoruesit përbën pëlqim për qëllimin specifik të bisedës së chat-it.

4. Trajtoni revokimin

Kur përdoruesi revokon pëlqimin e marketingut, thirrni Intercom('shutdown'). Kjo pastron cookie-t lokale dhe ndalon gjurmimin. Ruani gjendjen e përditësuar të pëlqimit në mënyrë që ngarkimet pasuese të faqes ta respektojnë.

5. Përdorni hostimin e të dhënave në EU për llogaritë e EU

Për llogaritë ku rezidenca e të dhënave në EU ka rëndësi, konfiguroni hapësirën e punës Intercom për hostim në EU. Drejtoni trafikun e EU sipas përshtatjes; nëse operoni hapësira pune të ndara për klientët e EU dhe jo-EU, integrimi duhet të zgjedhë app ID-në e saktë në momentin e boot-imit.

Grackat e Zakonshme

Katër gabime integrimi shfaqen vazhdimisht në auditimet e vendosjeve të Intercom.

Boot-imi para pëlqimit

Defekti më i zakonshëm. Instalimi i paracaktuar boot-on Messenger në ngarkimin e faqes, gjë që ekzekuton identifikimin e vizitorit dhe gjurmimin e shikimeve para çdo vendimi pëlqimi. Korrigjimi është i drejtpërdrejtë — shtyjeni thirrjen boot te callback-u i pëlqimit — por dokumentacioni i paracaktuar i integrimit nuk e sinjalizon këtë mjaftueshëm qartë.

Trajtimi i shutdown si opsionale

Nëse një përdorues revokon pëlqimin dhe Messenger nuk mbyllet eksplicit, skripti vazhdon të funksionojë me cookie-t e sesionit në vend. CMP-ja ka regjistruar revokimin por gjurmimi themelor vazhdon. Gjithmonë lidhni shutdown me revokimin e pëlqimit.

Bashkimi i mbështetjes dhe marketingut

Disa ekipe justifikojnë ngarkimin e Messenger para pëlqimit duke argumentuar se është "mbështetje, jo marketing". Nëse i njëjti Messenger gjithashtu ekzekuton fushata dalëse të automatizuara ose turne produkti brenda aplikacionit, vija nuk mund të vihet. Qasja konservatore është të bllokohet Messenger plotësisht nën marketing dhe të ofrohet një rrugë e veçantë, e pabashkuar kontakti mbështetjeje për përdoruesit që refuzojnë marketingun.

Injorimi i payload-eve të atributeve të personalizuara

Të dhënat e kaluara në thirrjet Intercom('update') — atribute të personalizuara përdoruesi, niveli i abonimit, mosha e llogarisë, identifikues të brendshëm përdoruesi — janë të dhëna personale të përcjella te Intercom. Rishikoni këto payload-e për ndarje të tepërt; shumë integrime kalojnë më shumë të dhëna identifikuese sesa Messenger ka nevojë funksionalisht.

Lista e Kontrollit të Auditimit

Gjashtë pyetje konkrete për t'iu përgjigjur për çdo vendosje Intercom që prek trafikun e EU, UK ose Kalifornisë.

• A pret Messenger për pëlqimin? Hapni faqen në një dritare private me mbrojtje strikte gjurmimi dhe konfirmoni se asnjë kërkesë intercom.io ose intercomcdn.com nuk ekzekutohet para pranimit të banerit.
• A ekziston një rrugë mbështetjeje pa Messenger? Për përdoruesit që refuzojnë marketingun, a mund të kontaktojnë ende mbështetjen nëpërmjet një formulari, email-i ose nxitësi chat me klikim eksplicit?
• A e mbyll revokimi Messenger? Konfirmoni se revokimi i pëlqimit thërret Intercom('shutdown') dhe pastron cookie-t lokale.
• A janë atributet e personalizuara të minimizuara? Rishikoni payload-et në thirrjet Intercom('update') dhe hiqni çdo të dhënë që nuk kërkohet funksionalisht nga Messenger.
• A është konfiguruar hostimi në EU ku kërkohet? Konfirmoni se trafiku i EU drejtohet te një hapësirë pune e hostuar në EU, me dokumentacion të vendimit të drejtimit.
• A janë fushatat dalëse të bllokuara nga pëlqimi? Konfirmoni se fushatat e mesazheve të automatizuara respektojnë gjendjen e pëlqimit të marketingut të kontaktit dhe ndalojnë dërgimin pas revokimit.

Ku Përshtatet Intercom në një Stack me Pëlqimin në Radhë të Parë

Platformat e live chat-it dhe mesazheve për klientët zënë një zonë gri rregullatore që ofruesit nuk kanë qenë të etur ta theksojnë. Rrjedha e të dhënave duket si analitikë dhe gjurmim marketingu; arsyetimi thekson shërbimin ndaj klientit. Rregullatorët kanë bërë të qartë se rrjedha e të dhënave kontrollon analizën, jo arsyetimi. Arkitektura e duhur e trajton Intercom Messenger si çdo skript tjetër identifikues të palës së tretë: bllokojeni pas pëlqimit, ofroni një rrugë alternative kontakti mbështetjeje për përdoruesit që refuzojnë, përdorni primitivën vendase shutdown të platformës për të nderuar revokimet, dhe konfiguroni hostimin në EU ku rezidenca ka rëndësi. E bërë saktë, ekipet e mbështetjes ruajnë live chat-in dhe automatizimin e ciklit jetësor që e bëjnë Intercom të vlefshëm, ndërsa qëndrimi themelor i përputhshmërisë ndalon së qeni një ekspozim i heshtur në pritje që një auditim ta nxjerrë në pah.