Skip to main content

概要

MoEngage の Push Debug は、キャンペーン分析内の診断機能で、プッシュ通知の配信状況を透明性の高い形で確認できます。User ID などの識別子で検索することで、One-Time および Periodic (child) プッシュキャンペーンにおける特定ユーザーのジャーニーを調査できます。この機能は、ユーザーのデバイスに通知が配信されたかどうか、いつ配信されたか、また配信された、または配信されなかった理由を正確に示す、詳細なステップごとのタイムラインを返します。 このガイドでは、Push Debug を使用してキャンペーン配信の問題をトラブルシューティングし、オーディエンスターゲティングを検証し、キャンペーンが意図したとおりに動作することを確認する方法を説明します。

ユースケース

Push Debug を使用すると、特定の配信シナリオを診断して解決でき、キャンペーンの実行に完全な確信を持つことができます。
  • 未配信のトラブルシューティング: 個々のユーザーが想定した通知を受信しなかった理由を正確に調査できます。これにより、重要なメッセージが主要なユーザーに確実に届くようにし、良好で信頼性の高い顧客体験を維持できます。
  • オーディエンスターゲティングの検証: 特定のユーザーがキャンペーンのオーディエンスに含まれた理由を検証できます。これにより、セグメンテーションロジックが正確であることを確認し、予算が適切なオーディエンスに使われ、ユーザーが関連性の高いコンテンツのみを受け取るようにできます。

デバッグワークフロー

このセクションでは、特定のプッシュキャンペーン内の個人のジャーニーを分析する方法を詳しく説明します。
  • Push Debug 機能は、キャンペーンの送信完了から約 1 時間後に利用可能になります。
  • 30 日以上前に作成されたキャンペーンでは、Push Debug を利用できません。
  • 調査対象のユーザーの識別子(User ID、MoEngage ID)が必要です。

ステップ 1: 検索を開始する

  1. One-Time または Periodic (child) プッシュキャンペーンの Campaign analytics and info ページで、Debug タブを選択します。 Debugnavigation.png
  2. Debug タブで、検索バーにユーザー識別子を入力します。ワークスペースごとに最大 100 ユーザーまでクエリできます。 Debugtab.png
  3. Find User をクリックします。
    システムが指定したユーザーのインタラクションデータを取得します。

ステップ 2: デバッグ結果を分析する

システムがインタラクションデータを取得し、各行がキャンペーンの特定のユーザーデバイスを表します。このサマリービューには次の列が含まれます。
  • ID: ビジネスで設定したユーザーの一意の識別子(例: Auto_test_user_01)。
  • MoEngage ID: 各ユーザープロファイルに対して MoEngage が生成する一意の ID。特にアカウント統合のシナリオで、ユーザーを正しく識別するのに役立ちます。
  • Platform: ユーザーのデバイスのプラットフォーム(例: Android、iOS、Web)。
  • Start Time: このキャンペーンでユーザーについて最初に記録されたイベントのタイムスタンプ。
  • Last Updated: このキャンペーンでユーザーについて最後に記録されたイベントのタイムスタンプ。
  • Latest Step: ユーザーのジャーニーにおける最後のイベントの名前(例: Eligibility check、Delivery controls、Sent)。
Download CSV file を選択して、インタラクションデータの結果をエクスポートすることもできます。 debug1.png
  • 検索履歴は現在のセッションでのみ保持され、ページを更新すると利用できなくなります。
  • アカウントには検索の上限が適用されます。UI には残りの検索回数が表示されます。たとえば、20 回検索を実行した場合、UI には 80/100 と表示されます。

ステップ 3: 詳細な配信タイムラインを分析する

任意の行の横にある展開アイコンをクリックすると、その特定のデバイスの詳細なステップごとの配信タイムラインが表示されます。これにより、ユーザーの完全なジャーニーを把握し、配信ステータスの正確な理由を特定できます。 完全に成功したキャンペーンジャーニーには、次の主要なイベントが含まれます。
  • Eligibility check: “ユーザーはターゲットセグメントに含まれており、デバイスに到達可能でした。”
  • Delivery controls: “ユーザーは、フリークエンシーコントロールやキャンペーンコントロールグループなどを含む、すべての配信コントロールチェックを通過しました。”
  • Sent: “通知はプッシュプロバイダー(例: APNS/FCM)に送信されました。”
  • Notification Received: “ユーザーのデバイスが通知を受信しました。”
  • Clicked: “ユーザーが通知をクリックしました。”
以下のシナリオでは、タイムラインが特定のイベントで止まっている場合の意味を説明します。

シナリオ 1: エンゲージメントを伴う配信成功

ユーザーがすべてのチェックを通過した場合、タイムラインには配信成功のシーケンスが表示されます。複数のプラットフォームを使用するユーザーの場合、プラットフォームごとに個別のタイムラインを確認できます。
  • Latest Step: Clicked
  • Message: “ユーザーが通知をクリックしました。”
  • Outcome: このユーザーに対するキャンペーンは完全に成功しました。タイムラインにはすべてのイベントが表示され、通知が送信、受信され、エンゲージメントがあったことが確認できます。
debug1.png

シナリオ 2: エンゲージメントを伴わない配信成功

このシナリオは、通知を受信したものの、まだ操作していない(または操作しないことを選んだ)ユーザーを表します。タイムラインにより、通知がデバイスに正常に配信されたことが確認できます。
  • Latest Step: Notification Received
  • Message: “ユーザーのデバイスが通知を受信しました。”
  • Outcome: “Clicked” イベントがないことは、ユーザーがメッセージを受信したものの、エンゲージメントがないことを示します。
withoutengagementdebug2.png

シナリオ 3: 送信されたが受信されていない

この場合、MoEngage のシステムはメッセージを正常に送出しましたが、外部サービス(Apple や Google のプッシュ通知サービスなど)がユーザーのデバイスへの配信に失敗しました。
  • Latest Step: Sent
  • Message : “通知はプッシュプロバイダー(例: APNS/FCM)に送信されました。”
  • Outcome: メッセージは MoEngage から送信されましたが、外部のプッシュサービス(例: APNS または FCM)によって配信が確認されませんでした。“Notification Received” イベントがないことは、ユーザーが通知を受信しなかったことを示します。
sentbutnotreceived.png

シナリオ 4: 送信の失敗

APNS/FCM が MoEngage に失敗レスポンスを返した場合、通知が失敗することがあります。
  • Latest Step: Sent
  • Message: タイムラインには、通知の送信に失敗した理由が示されます。一般的な理由は次のとおりです。
    • Failure: Requested entity was not found
    • Failure: SenderId mismatch
  • Result: 送信サービスからのエラーにより、通知は送信されませんでした。一般的なプッシュエラーと対処方法の詳細については、こちらを参照してください。

シナリオ 5: 配信コントロールでドロップされた

ユーザーがセグメンテーションを通過した後でも、配信コントロールルールのいずれかを満たさない場合はドロップされることがあります。
  • Latest Step: Delivery controls
  • Message: タイムラインには、ユーザーがドロップされた理由が示されます。一般的な理由は次のとおりです。
    • キャンペーンコントロールグループによりユーザーがドロップされました。
    • Frequency Capping によりユーザーがドロップされました。
    • Do Not Disturb (DND) 設定によりユーザーがドロップされました。
  • Outcome: 送信プロセスが停止され、通知は送出されません。
Deliverycontrolsfailuredebug3.png

シナリオ 6: ユーザーがセグメントに含まれていない

ユーザーがキャンペーンのターゲットオーディエンスに含まれていなかった場合、タイムラインは最初のチェックで止まります。
  • Latest Step: Eligibility check
  • Message: “ユーザーはセグメント外であるか、デバイスに到達できなかったため、対象外でした。”
  • Outcome: それ以降の配信チェックは実行されません。ユーザーの属性がセグメンテーション条件に一致しなかったか、デバイスに到達できなかったため、ユーザーはキャンペーンから除外されました。
notpartofthesegmentdebug4.png

単一プラットフォーム上の複数デバイスの扱い

ユーザーが同じプラットフォーム上に複数のデバイス(例: 2 台の Android スマートフォン)を持っている場合、システムはエンゲージメントデータを次のように処理します。
  • 個々のデバイスの配信タイムラインには、Sent ステータスまでのイベントが表示されます。
  • Received や Clicked などのその後のエンゲージメントイベントは、特定の 1 台のデバイスにアトリビュートできないため、まとめてプラットフォームレベルで表示されます。たとえば、2 台の Android スマートフォンを持つユーザーが通知をクリックした場合、MoEngage はそのユーザーについて Android プラットフォームでクリックが発生したことを記録しますが、それがスマートフォン A とスマートフォン B のどちらで発生したかは判断できません。

FAQ

Push Debug 機能は、One-Time および Periodic (child) プッシュキャンペーンをサポートしています。
ワークスペースには、ワークスペースごとに月あたり合計 100 回の Debug 検索が割り当てられています。UI には残りの検索回数が表示されます(例: 80/100)。
ワークスペースでより高い上限が必要な場合は、MoEngage のカスタマーサクセスマネージャー(CSM)またはサポートチームにお問い合わせください。
この機能は、過去のユーザー ID を自動的に解決します。ユーザーのジャーニーに複数の ID が関係する場合(例: 匿名プロファイルからログイン済みプロファイルへ)、結果テーブルには、該当する ID に関連付けられたすべての過去のユーザープロファイルのインタラクションデータが含まれます。
はい。Download CSV file を選択すると、Debug の結果をエクスポートできます。EXPORTTTTTTdebug.png

次のステップ