Intercom Messenger가 수집하는 내용

Intercom Messenger 스크립트(widget.intercom.io 또는 js.intercomcdn.com에서 로드됨)는 전역 Intercom 객체를 초기화하고 intercom-id-* 및 intercom-session-* 쿠키로 방문자를 식별합니다. 그 순간부터 페이지뷰, 페이지 체류 시간, 스크롤 깊이 및 방문자 수준 메타데이터(사용자 에이전트, OS, 브라우저, IP 파생 위치, 리퍼러 및 애플리케이션이 Intercom('boot', {...}) 또는 Intercom('update', {...})를 통해 전달하는 모든 사용자 정의 속성)를 캡처합니다. Messenger의 실시간 존재 기능은 또한 페이지가 열려 있는 동안 방문자 활동을 Intercom 서버로 지속적으로 보고하여 고객 메시징 도구 중 더 무거운 스트리밍 데이터 풋프린트 중 하나를 생성합니다.

사용자가 식별되면(일반적으로 인증 후 Intercom('boot', { user_id: ..., email: ... })를 호출하여) 스크립트는 방문자 신원을 알려진 Intercom 연락처에 연결합니다. 대화 기록, 속성, 세분화 멤버십은 모두 이 식별에서 흘러나오며, Intercom은 이 링크를 사용하여 자동화된 메시지 캠페인, 라이프사이클 이메일, 인앱 제품 투어를 주도합니다.

왜 "단순히 채팅 위젯"이 동의를 피하게 해주지 않는가

제품 팀의 일반적인 방어적 프레이밍은 Intercom이 마케팅 추적기가 아닌 고객 서비스 도구이며, 고객 서비스 활동이 "마케팅 동의 필요"보다는 "계약 이행에 필요"에 더 가깝다는 것입니다. 이 프레이밍은 좁은 범위의 사실이지만 실제로는 광범위하게 잘못되었습니다.

대화 전 추적은 계약 이행이 아닙니다

고객이 채팅 대화를 시작하면 해당 특정 대화와 관련된 처리는 GDPR Article 6(1)(b) 하에서 합리적으로 계약 또는 전계약 이행으로 특징지을 수 있습니다. 그 전의 모든 것(페이지뷰 추적, 존재 보고, 방문자 식별, 세분화 기반 자동 메시지)은 그렇지 않습니다. 자신의 합법적 근거가 필요한 분석 및 마케팅 목적의 처리입니다.

Messenger는 모든 대화 전에 시작됩니다

스크립트의 기본 동작은 페이지 로드 시 초기화되고 즉시 데이터 수집을 시작하는 것이며, 방문자가 채팅 버블을 클릭한 지 오래 전입니다. 활성 채팅 세션을 포함하는 모든 합법적 근거는 대화 전 기간에 수집된 데이터를 포함하지 않습니다.

자동화된 아웃바운드 메시지는 마케팅입니다

Intercom의 자동화된 메시지 캠페인, 라이프사이클 이메일, 행동 기반 트리거는 마케팅 커뮤니케이션입니다. GDPR과 미국에서 CAN-SPAM 및 해당하는 TCPA에 따라 자신의 합법적 근거가 필요합니다.

기본 Intercom 개인정보 보호 제어

Intercom은 유용한 기본 개인정보 보호 기본 요소 집합을 노출합니다. 다른 주요 마케팅 플랫폼과 마찬가지로 동의 결정이 업스트림에 존재한다고 가정합니다. 자체적으로 수집하지 않습니다.

shutdown

Intercom('shutdown') 호출은 활성 세션을 종료하고, 로컬 쿠키를 지우며, 추가 추적을 중단합니다. 사용자가 CMP에서 마케팅 카테고리를 수락할 때 Intercom('boot')와 쌍을 이룹니다.

hide_default_launcher 옵션

hide_default_launcher: true로 설정하면 스크립트를 언로드하지 않고도 채팅 버블을 완전히 숨깁니다. 채팅을 제공하면 안 되는 페이지에 유용하지만 실제로 스크립트 로드를 방지하는 것을 대체하지 않습니다.

데이터 보존 제어

Intercom의 관리 설정에는 방문자 데이터, 대화 기록, 이벤트 로그에 대한 구성 가능한 보존 창이 포함됩니다. 이를 강화하는 것은 CMP 수준 게이팅 위에 심층 방어 측정입니다.

EU 데이터 호스팅 옵션

Intercom은 이를 요구하는 계정을 위해 EU 데이터 호스팅을 제공하여 대화 및 방문자 데이터를 EU 인프라 내에 유지합니다. 이는 국경 간 전송 우려의 의미 있는 부분을 해결하지만 동의 요구 사항을 제거하지는 않습니다.

단계별 CMP 통합

신뢰할 수 있는 패턴은 Messenger 초기화를 방문자가 마케팅 카테고리를 수락할 때까지 연기한 다음, 적절한 사용자 컨텍스트로 Messenger를 부팅하는 것입니다. 초기화되면 Messenger는 정상적으로 실행됩니다. 사용자가 동의를 취소하면 Messenger는 깔끔하게 종료됩니다.

1. head에서 기본 Messenger 스니펫 제거

Intercom은 페이지 로드에서 Messenger를 초기화하는 설치 스니펫을 제공합니다. 문서 head에서 부팅 호출을 제거합니다. 스크립트 태그는 유지될 수 있습니다(type="text/plain" 및 data-category="marketing"(CMP가 해당 패턴을 사용하는 경우)), 하지만 Intercom('boot') 호출은 연기되어야 합니다.

2. 동의 콜백에서 Messenger 부팅

CMP가 마케팅 수락 이벤트를 실행할 때 스크립트 타입을 text/javascript로 다시 작성하고, 로드되도록 허용한 다음 Intercom('boot', { app_id: ... })를 호출합니다. 사용자가 인증되면 부팅 호출에 식별 파라미터를 포함합니다.

3. 미동의 사용자를 위한 수동 채팅 트리거 제공

마케팅 추적을 거부한 고객도 지원에 연락할 권리가 있습니다. 대체 채팅 경로를 제공합니다(연락 양식, 이메일 링크 또는 클릭할 때만 Messenger를 로드하는 명시적 "채팅 시작" 버튼). 후자가 가장 깔끔한 패턴입니다: 사용자의 명시적 클릭은 채팅 대화의 특정 목적에 대한 동의를 구성합니다.

4. 취소 처리

사용자가 마케팅 동의를 취소할 때 Intercom('shutdown')를 호출합니다. 이는 로컬 쿠키를 지우고 추적을 중단합니다. 업데이트된 동의 상태를 유지하여 후속 페이지 로드가 이를 준수하도록 합니다.

5. EU 계정에 대해 EU 데이터 호스팅 사용

EU 데이터 위치가 중요한 계정의 경우 EU 호스팅을 위해 Intercom 워크스페이스를 구성합니다. EU 트래픽을 적절히 라우팅합니다. EU 및 비EU 고객을 위해 별도의 워크스페이스를 운영하는 경우 통합이 부팅 시 올바른 app_id를 선택해야 합니다.

일반적인 함정

Intercom 배포의 감사에서 4가지 통합 오류가 반복적으로 나타납니다.

동의 전에 부팅

가장 흔한 결함입니다. 기본 설치는 페이지 로드에서 Messenger를 부팅하여 방문자 식별 및 페이지뷰 추적이 동의 결정 전에 실행됩니다. 수정은 간단합니다(부팅 호출을 동의 콜백으로 연기) 하지만 기본 통합 문서는 이를 충분히 명확하게 플래깅하지 않습니다.

shutdown을 선택 사항으로 취급

사용자가 동의를 취소하고 Messenger를 명시적으로 종료하지 않으면 스크립트는 세션 쿠키가 제자리에 있는 상태로 계속 실행됩니다. CMP는 취소를 기록했지만 기본 추적이 계속됩니다. 항상 shutdown을 동의 취소에 연결합니다.

지원과 마케팅 번들링

일부 팀은 "지원, 마케팅이 아님"이라는 주장으로 동의 전 Messenger 로드를 정당화합니다. 동일한 Messenger가 또한 자동화된 아웃바운드 캠페인 또는 인앱 제품 투어를 실행하면 라인을 그을 수 없습니다. 보수적인 접근 방식은 마케팅에서 Messenger를 완전히 게이트하고 마케팅을 거부하는 사용자를 위한 별도의 번들되지 않은 지원 연락처 경로를 제공하는 것입니다.

사용자 정의 속성 페이로드 무시

Intercom('update') 호출에 전달된 데이터(사용자 정의 사용자 속성, 구독 층, 계정 나이, 내부 사용자 식별자)는 Intercom으로 전달되는 개인 데이터입니다. 이 페이로드를 과도한 공유 검토합니다. 많은 통합이 Messenger가 기능적으로 필요한 것보다 더 많은 식별 데이터를 전달합니다.

감사 체크리스트

EU, UK 또는 California 트래픽에 접근하는 모든 Intercom 배포에 대해 답변해야 할 6가지 구체적인 질문입니다.

• Messenger가 동의를 기다리나요? 엄격한 추적 보호로 개인 창에서 페이지를 열고 배너 수락 전에 intercom.io 또는 intercomcdn.com 요청이 실행되지 않음을 확인합니다.
• 비 Messenger 지원 경로가 있나요? 마케팅을 거부하는 사용자의 경우 양식, 이메일 또는 명시적 클릭 채팅 트리거를 통해 지원에 여전히 연락할 수 있습니까?
• 취소가 Messenger를 종료하나요? 동의 취소가 Intercom('shutdown')을 호출하고 로컬 쿠키를 지우는지 확인합니다.
• 사용자 정의 속성이 최소화되나요? Intercom('update') 호출의 페이로드를 검토하고 Messenger가 기능적으로 필요로 하지 않는 모든 데이터를 제거합니다.
• EU 데이터 호스팅이 구성되어 있나요? EU 트래픽이 EU 호스팅 워크스페이스로 라우팅되는지 확인하고 라우팅 결정을 문서화합니다.
• 아웃바운드 캠페인이 동의에 게이트되어 있나요? 자동화된 메시지 캠페인이 연락처의 마케팅 동의 상태를 준수하고 취소 시 전송을 중단하는지 확인합니다.

Intercom이 동의 우선 스택에 맞는 위치

라이브 채팅 및 고객 메시징 플랫폼은 공급업체가 강조하기를 원하지 않는 규제 회색 영역을 차지합니다. 데이터 흐름은 분석 및 마케팅 추적처럼 보입니다. 프레이밍은 고객 서비스를 강조합니다. 규제 기관은 데이터 흐름이 프레이밍이 아닌 분석을 제어한다는 것을 명확히 했습니다. 올바른 아키텍처는 Intercom Messenger를 다른 식별 제3자 스크립트처럼 취급합니다: 동의 뒤에 게이트, 거부하는 사용자를 위한 대체 지원 연락처 경로 제공, 플랫폼의 기본 shutdown 기본 요소를 사용하여 취소 준수, 위치가 중요한 경우 EU 데이터 호스팅 구성. 올바르게 수행되면 지원 팀은 Intercom을 가치 있게 만드는 라이브 채팅 및 라이프사이클 자동화를 유지하면서 기본 규정 준수 상태가 감사에서 표면화될 때까지 기다리고 있는 조용한 노출이 되는 것을 중단합니다.