Intercom Messengerが収集するもの

Intercom Messengerスクリプト（widget.intercom.ioまたはjs.intercomcdn.comからロード）は、グローバルIntercomオブジェクトを初期化し、intercom-id-*およびintercom-session-* Cookieで訪問者を識別します。その瞬間から、ページビュー、ページ上の時間、スクロール深度、および訪問者レベルのメタデータ（ユーザーエージェント、OS、ブラウザ、IP導出位置、リファラー、およびアプリケーション経由で渡されるカスタム属性（Intercom('boot', {...})またはIntercom('update', {...})）をキャプチャします。Messengerのリアルタイムプレゼンス機能は、ページが開いている間、訪問者アクティビティをIntercomのサーバーに継続的に報告し、カスタマーメッセージングツール間でより重いストリーミングデータフットプリントの1つを生成します。

ユーザーが識別されると（通常、認証後にIntercom('boot', { user_id: ..., email: ... })を呼び出すことで）、スクリプトは訪問者のアイデンティティを既知のIntercomコンタクトにリンクします。会話履歴、属性、およびセグメンテーションメンバーシップはすべてこの識別から流れ、Intercomはリンクを使用して自動メッセージキャンペーン、ライフサイクルメール、およびアプリ内プロダクトツアーを実行します。

「それは単なるチャットウィジェット」がコンセントの要件から逃れない理由

プロダクトチームからの一般的な防御的な枠組みは、Intercomはマーケティングトラッカーではなく顧客サービスツールであり、顧客サービスアクティビティは「契約パフォーマンスに必要」に「マーケティング同意が必要」よりも近いということです。この枠組みは狭い真実を持っていますが、実際には広く間違っています。

会話前の追跡は契約パフォーマンスではない

顧客がチャット会話を開始すると、その特定の会話に関連する処理はGDPR Article 6(1)(b)に基づく契約またはプリコントラクトパフォーマンスとして合理的に特性化できます。その前のすべてのもの（ページビュー追跡、プレゼンス報告、訪問者識別、セグメンテーション駆動型自動メッセージ）はそうではありません。それは自身の法的根拠を必要とする分析およびマーケティング目的の処理です。

Messengerは会話前に起動する

スクリプトのデフォルト動作は、ページロード時に初期化され、訪問者がチャットバブルをクリックする前に即座にデータ収集を開始することです。アクティブなチャットセッションをカバーする法的根拠は何であれ、会話前の期間に収集されたデータをカバーしません。

自動送信メッセージはマーケティング

Intercomの自動メッセージキャンペーン、ライフサイクルメール、および動作トリガーはマーケティング通信です。これらはGDPRの下でおよび米国ではCAN-SPAMおよび該当する場合はTCPAの下で自身の法的根拠を必要とします。

ネイティブIntercomプライバシーコントロール

Intercomは有用なネイティブプライバシープリミティブのセットを公開しています。他の主要なマーケティングプラットフォームと同様に、それらは同意決定が上流に存在することを前提としています。それらはそれ自体で収集しません。

shutdown

Intercom('shutdown')呼び出しはアクティブなセッションを終了し、ローカルCookieをクリアし、さらなる追跡を停止します。ユーザーがCMPのマーケティングカテゴリを受け入れるときにIntercom('boot')とペアにします。

hide_default_launcherオプション

hide_default_launcher: trueを設定すると、スクリプトをアンロードせずにチャットバブルを完全に隠します。チャットを提供すべきではないページに役立ちますが、実際にスクリプトがロードされるのを防ぐ代替ではありません。

データ保持コントロール

Intercomの管理設定には、訪問者データ、会話履歴、およびイベントログの設定可能な保持ウィンドウが含まれています。これらを厳しくすることは、CMPレベルのゲートの上に深い防御対策です。

EU Data Hostingオプション

Intercomはそれを必要とするアカウント向けにEUデータホスティングを提供し、会話および訪問者データをEUインフラストラクチャ内に保ちます。これはクロスボーダー転送懸念の重大な部分に対処しますが、同意要件を排除しません。

ステップバイステップCMP統合

信頼できるパターンは、訪問者がマーケティングカテゴリを受け入れるまでMessenger初期化を延期し、その後適切なユーザーコンテキストでMessengerをブートすることです。初期化されると、Messengerは正常に実行されます。ユーザーが同意を取り消すと、Messengerはきれいにシャットダウンします。

1. ヘッドからデフォルトのMessengerスニペットを削除する

Intercomはページロード時にMessengerを初期化するインストールスニペットを提供します。ドキュメントヘッドからブート呼び出しを削除します。スクリプトタグは残すことができます（CMPがそのパターンを使用する場合はtype="text/plain"およびdata-category="marketing"を使用）が、Intercom('boot')呼び出しは延期される必要があります。

2. コンセントコールバックからMessengerをブートする

CMPがマーケティング受け入れイベントを起動したら、スクリプトタイプをtext/javascriptに書き直し、ロードさせて、Intercom('boot', { app_id: ... })を呼び出します。ユーザーが認証された場合、ブート呼び出しで識別パラメータを含めます。

3. 未同意ユーザーに対して手動チャットトリガーを提供する

マーケティング追跡を拒否した顧客でも、サポートに連絡する権利があります。別のチャットパス（連絡フォーム、メールリンク、またはクリック時にのみMessengerをロードする明示的な「チャット開始」ボタン）を提供します。後者は最もきれいなパターンです。ユーザーの明示的なクリックは、チャット会話の特定の目的に対する同意を構成します。

4. 取り消しを処理する

ユーザーがマーケティング同意を取り消すと、Intercom('shutdown')を呼び出します。これはローカルCookieをクリアし、追跡を停止します。更新された同意状態を保持して、その後のページロードがそれを尊重するようにします。

5. EUアカウント向けにEUデータホスティングを使用する

EUデータレジデンシーが重要なアカウントの場合、IntercomワークスペースをEUホスティング用に構成します。それに応じてEUトラフィックをルーティングします。EUと非EUの顧客に対して個別のワークスペースを運用する場合、統合はブート時に正しいアプリIDを選択する必要があります。

一般的な落とし穴

4つの統合エラーがIntercom展開の監査で繰り返し表示されます。

同意前のブート

最も一般的な欠陥。デフォルトのインストールはページロード時にMessengerをブートし、これはあらゆる同意決定前に訪問者識別とページビュー追跡を起動します。修復は簡単です（ブート呼び出しをコンセントコールバックに延期する）が、デフォルトの統合ドキュメントはこれを十分に明確にフラグを立てていません。

shutdownをオプションとして扱う

ユーザーが同意を取り消し、Messengerが明示的にシャットダウンされない場合、スクリプトはセッションCookieとともに実行を続けます。CMPは取り消しを記録しましたが、基礎となる追跡は続きます。常にshutdownを同意取り消しに配線します。

サポートとマーケティングをバンドルする

一部のチームは、「マーケティングではなくサポート」であると主張することで、同意前のMessengerロードを正当化します。同じMessengerが自動送信キャンペーンまたはアプリ内プロダクトツアーも実行する場合、ラインは引けません。保守的なアプローチは、Messengerを完全にマーケティングの下にゲートし、マーケティングを拒否するユーザーに対して別の、バンドルされていないサポート連絡先パスを提供することです。

カスタム属性ペイロードを無視する

Intercom('update')呼び出しで渡されるデータ（カスタムユーザー属性、サブスクリプション層、アカウント年齢、内部ユーザー識別子）はIntercomに転送される個人データです。これらのペイロードを過度な共有について確認します。多くの統合はMessengerが機能的に必要とするよりも多くの識別データを渡します。

監査チェックリスト

EU、UK、またはカリフォルニアのトラフィックに接するIntercom展開に対して答えるべき6つの具体的な質問。

• Messengerは同意を待っていますか？厳密な追跡保護を備えたプライベートウィンドウでページを開き、バナー受け入れ前にintercom.ioまたはintercomcdn.comリクエストが起動しないことを確認します。
• メッセンジャー以外のサポートパスはありますか？マーケティングを拒否するユーザーの場合、フォーム、メール、または明示的なクリックチャットトリガーを介してサポートに連絡できますか？
• 取り消しはMessengerをシャットダウンしますか？同意取り消しがIntercom('shutdown')を呼び出し、ローカルCookieをクリアすることを確認します。
• カスタム属性は最小化されていますか？Intercom('update')呼び出しのペイロードを確認し、Messengerが機能的に必要としないデータを削除します。
• EUデータホスティングは必要に応じて構成されていますか？EUトラフィックがEUホストワークスペースにルーティングされることを確認し、ルーティング決定のドキュメントを作成します。
• 送信キャンペーンは同意にゲートされていますか？自動メッセージキャンペーンがコンタクトのマーケティング同意状態を尊重し、取り消し時に送信を停止することを確認します。

Intercomがコンセンストファースト・スタックに適合する場所

ライブチャットおよびカスタマーメッセージングプラットフォームは、ベンダーが強調することに熱心ではなかった規制上のグレーゾーンを占めています。データフローは分析およびマーケティング追跡のように見えます。フレーミングは顧客サービスを強調しています。規制当局はデータフローが分析をコントロールすることを明確にしており、フレーミングではありません。正しいアーキテクチャはIntercom Messengerを他の識別サードパーティスクリプトのように扱います：同意の背後にそれをゲートし、マーケティングを拒否するユーザーに対して別のサポート連絡先パスを提供し、プラットフォームのネイティブshutdownプリミティブを使用して取り消しを尊重し、残留性が重要な場合はEUデータホスティングを構成します。正しく行うと、サポートチームはIntercomを有価にするライブチャットとライフサイクル自動化を保持し、一方で基礎となるコンプライアンスの姿勢は監査が表面化するのを待っている静かな露出であることを停止します。