メッセージを受け取るはずのユーザーが受け取っていない場合、いくつかの理由が考えられます。このトラブルシューティングガイドは問題の核心に迫るのに役立ちます。
注意：Intercom JavaScript API メソッド（例：Intercom('shutdown')）の呼び出しに関わる配信問題の解決には、アプリのコードベースへのアクセスが必要です。必要に応じて開発チームに相談してください。
まず、各メッセージがどのように配信されるかを理解しましょう
ワンオフメッセージは即時に送信されます（スケジュール設定していない限り）。これは、フィルターに合致するすべてのusersを探し、見つけ次第送信することを意味します。
継続的なメッセージの場合、1時間に1回、メッセージ受信資格があるusersを確認します。
シリーズでは、customerがアプリにログインするかウェブサイトを訪問しIntercomにトラッキングされると、エントリールールに合致するパスのシリーズに入ります。
ログインしていない場合、エントリールールは1時間に1回、入るべきusersをチェックします。パスの途中のルールブロック（すでにシリーズに入っている場合）は約15分ごとにチェックされます。
アプリ内メッセージ（チャット、投稿など）は、ユーザーがオンラインのときのみ配信されます。usersが「ping」するとき、つまりオンラインでアプリがusersの情報を送信しているときにのみマッチして送信されます。'最終確認'の値は、ユーザーが最後にメッセージを受け取るためにサイトにいた時間を示します。モバイルアプリがネイティブのiOSやAndroid SDKではなくウェブベースのMessengerを使う場合、ウェブのpingのみ生成され、iOSやAndroidのpingは生成されません。つまり、「Show first on」をiOSのみに設定するとマッチせず、アプリ内メッセージは表示されません。モバイルアプリ内で動作するウェブベースのMessengerにメッセージがマッチするよう、「Show first on」にWebを含めてください。
プッシュ通知が付いたメッセージは即時に送信されます。
ユーザーのMessengerセッションはまだ有効ですか？
アプリ内メッセージの配信は、host appのログイン状態ではなくMessengerセッションによって制御されます。ユーザーが有効なJWTでIntercom('boot')を通じて識別されると、デフォルト7日間のセッションCookieが作成されます。このセッションはユーザーがアプリからログアウトしても持続し、明示的にIntercom('shutdown')を呼び出すまで続きます。
つまり、アプリからログアウトしたユーザーでも、セッションCookieが有効であれば次回Messengerが読み込まれたときにアプリ内メッセージを受け取ることができます。
重要：Audience条件はログアウト時ではなくMessengerが読み込まれるたびにチェックされます。したがって、除外フィルターは機能しますが、Messengerがセッション中に実際に起動した場合に限ります。
ログアウトまたは除外されたusersへの配信を防ぐには：
ログアウトイベントハンドラー内で
Intercom('shutdown')を呼び出してください。これによりセッションCookieが即座にクリアされ、そのデバイスの次の訪問者のために新しい匿名セッションが開始されます。メッセージのaudienceフィルターに除外ステータスを含めてください（例：
excluded_user is not true）。条件はMessengerの読み込みごとに再評価されるため、セッションが技術的に有効でも配信を防げます。オプションで、設定 > チャンネル > Messenger > Messengerを安全に保つで最大セッション期間をアプリのセッション長に合わせて短縮してください。
注意：この動作は識別されたusersのみに適用されます。匿名訪問者はJWTベースのセッション持続に影響されない別のCookieベースのセッションを使用します。
Messengerセキュリティはサインイン済みusersへの配信をブロックしていますか？
ワークスペースでMessengerセキュリティが有効な場合、サインイン済みusersへのチャットメッセージはMessenger起動時に有効なセキュリティトークンが提供された場合のみ配信されます。トークンがないか無効だと、Messengerはそのページで安全な起動を完了せず、pingは送信されず、ユーザーの最近のページビューは空のままで、アプリ内チャットメッセージは配信されません。
確認方法： 設定 > チャンネル > Messenger > セキュリティで、本番ドメインのどれがセキュリティチェックを通過しているかを確認してください。「準備できていません」と表示されるドメインは、有効なトークンを含むpingを送信しておらず、そのドメインのサインイン済みMessengerは安全な起動を完了しません。開発者に確認し、そのドメイン用にサーバー側で新しいJWT（または旧方式のIdentity Verificationハッシュ）が生成され、Messenger起動呼び出しに渡されていることを確認してください。設定手順はこちらを参照してください。
このセキュリティチェックは、ユーザーIDやメールアドレスが既知のサインイン済みインストールにのみ適用されます。匿名のマーケティングサイト経由のLeadsはこのチェック対象外で、Messengerがページに読み込まれていればアプリ内チャットメッセージを受け取れます。これは上記のセッションベースの配信ルールと同じで、トークンは不要です。
次に、これらの質問に答えてください
まだメッセージが送信されない理由がわからない場合は、以下の質問に答える必要があります。
メッセージを大規模なaudienceに送信していますか？
大規模audience向けのメッセージは処理に時間がかかることがあります。メッセージを公開すると、すべてのフィルターをチェックし、どのusersが合致するかを確認します。メッセージが大きいほど処理完了までに時間がかかります。
設定したフィルターにusersは合致していますか？
Intercomでは、すべてのメッセージはトリガーベースです。つまり、受信者はメッセージに設定したフィルターに合致して初めて受信資格を得ます。フィルターの例は「30日以内に登録」「プランはlite」です。
メッセージにフィルターを追加すると、それがusersのメッセージ受信資格をチェックする基準になります。例えば、上記のフィルターを設定したメッセージは次のようになります。
現在、これらのフィルターに合致するusersはいないため、誰もメッセージを受け取りません。ただし、これは継続的なメッセージなので、Intercomは毎時間これらのフィルターに合致するusersをチェックし、合致したusersにメッセージを送信します。
このメッセージのフィルターにusersが合致すると、ウィンドウの右側に表示されます。フィルターに合致した場合のメッセージの表示例は以下の通りです。
そのユーザーは配信停止していますか？
ユーザーがあなたのアプリからのメール配信を配信停止している場合、一斉メールは受け取れません。ただし、アプリ内メッセージや個別送信されたメールは受け取れますが、手動および自動のメールは受け取れません。
メッセージはバウンスしていますか？
Intercomがメッセージを送信しようとして恒久的な失敗（ハードバウンス）が発生した場合、その受信者へのメール配信は再試行しません。これはハードバウンス先への継続的な配信試行が送信者の評価やメール受信率に悪影響を及ぼすためです。
そのユーザーはメッセージをスパムとしてマークしていますか？
同様に、受信者があなたのメールをスパムとしてマークした場合、そのユーザーにはこれ以上Intercomアプリからメールを送信できません。
配信停止、バウンス、スパムマークされたusersは一斉メッセージのaudienceから自動的に除外されます。過去にバウンスや苦情があった相手には配信されません。
マーケティングメールを受け取るべきでない特定のアドレスは自動的にメール受信資格がありません。例として abuse@ や postmaster@ アドレスがあります。
メッセージ送信時にすべての受信者が受信資格なしの場合、「このメールを準備中でまもなく送信開始します」というメッセージが表示されることがあります。
注意：ユーザーまたはLeadの「スパムマーク」属性が'true'であっても、再度メール受信の書面または口頭の同意を得ている場合は、サポートチームに連絡してください。ユーザー/Leadの同意を得ることが重要です。スパムマークを続ける人にメールを送ると送信者評価が下がり、メールがスパムフィルターに振り分けられる可能性が高まります。
メッセージを配信ウィンドウ内で送信するようスケジュールしていますか？
メッセージを特定の時間や配信ウィンドウ内で送信するようスケジュールしている場合、配信が遅れることがあります。例えば、別のタイムゾーンの午前9時にメッセージを公開したい場合、スケジュール設定が可能です。
配信ウィンドウを設定することもでき、これがメッセージの配信時間に影響する場合があります。配信ウィンドウが午前9時から午後5時の場合、受信者のタイムゾーン内でその時間帯に配信されます。受信者のタイムゾーンが不明な場合はアプリのタイムゾーンが使われます。
注意：配信ウィンドウ付きメッセージは送信者のタイムゾーンではなく受信者のタイムゾーンに従って送信されます。受信者の位置情報がない場合はアプリのタイムゾーンが使われます。