Web Push の表示数を増やす方法

「プッシュは送信されたのに、表示数が想定より大幅に少ない」というのは、Web Push を導入したお客様から最も多く寄せられる質問の一つです。表示数は単独の指標ではなく、購読・送信・到達といった複数の段階で積み重なった損失の結果です。本記事では、ファネルに沿って表示数が少ない原因を段階ごとに特定する方法、原因の種類ごとの最適化手段、そして最後に継続的に実行できる総合的なアプローチを紹介します。

まず定義を揃える：表示はファネルのどの段階か

EngageLab は各プッシュを以下の段階で集計します。各段階の定義は プッシュ統計 と 統計 API を参照してください。

flowchart LR
    plan["計画ターゲット"]
    targets["有効ターゲット<br/>過去 365 日以内にアクティブだったデバイス"]
    sent["送信数<br/>サーバーが送信タスクを作成"]
    delivered["到達数<br/>Web クライアントに実際に到達"]
    impressions["表示数<br/>デバイス上で正常に表示"]
    clicks["クリック数"]

    plan --> targets --> sent --> delivered --> impressions --> clicks

「表示」については、次の 3 点を最初に明確にしておく必要があります。そうしないと、統計の定義に関する問題を配信の問題と誤認しやすくなります。

1. 表示は SDK がレポートします。 コールバック API の Impression ステータスは「Web Push 通知メッセージとアプリ内メッセージが SDK によって表示成功としてレポートされたもの」と定義されています。詳細は コールバック API を参照してください。SDK 経由でレポートされていない表示は表示数に含まれません。
2. カスタムメッセージはデフォルトでは表示数に含まれません。 プッシュ作成 API の message（カスタムメッセージ）はブラウザには表示されず、お客様の Web ページにそのまま渡されます。表示を集計するには、ページ側で customDisplayReport を呼び出して能動的にレポートする必要があります。詳細は Web SDK API を参照してください。
3. 集計期間は 5 日間です。 送信成功から 5 日を超えて発生した到達と表示は集計に含まれず、コールバックも送信されません。

したがって、表示数が少ない場合の調査では、まず「表示率が低い」（到達したが表示されていない）のか、「表示数は少ないが表示率は正常」（問題は上流の購読・送信・到達にある）のかを区別してください。両者の原因と解決策はまったく異なります。

第 1 部：表示数が少ない原因の調査方法

ファネルの上流から下流へ段階ごとに調査し、各段階でまずデータを確認してから原因を特定することを推奨します。

1.1 購読者プールは十分な規模か

表示数の上限は購読ユーザーの規模で決まります。購読ユーザーがそもそも少なければ、到達率や表示率が高くても十分な表示数にはなりません。

確認する場所：

• ユーザー概況：「購読ユーザー」と「アクティブユーザー」を比較します。購読ユーザーは、購読を完了し通知の受信に同意した一意のユーザーデバイス数です。購読ユーザーがアクティブユーザーを大きく下回る場合、多くの訪問者が権限付与を完了していないことを意味します。
• 概況：デバイスの通知権限有効化率と「通知をオフにしたユーザー」数を確認します。
• データ照会：特定の Registration ID のオンライン状態と最終オンライン時刻を抽出確認し、購読がまだ有効かどうかを確かめます。

よくある原因（FAQ と 基本設定 を参照）：

• 「直接リクエスト」方式でブラウザのネイティブ権限ダイアログを表示している。ユーザーが一度 Block / Don't Allow をクリックすると、ユーザー自身がブラウザ設定を変更しない限り再リクエストできません。
• サイトが HTTPS を使用していない、またはドメインがコンソールに設定されていないため、ネイティブ権限プロンプトを表示できず購読もできない。
• Service Worker がサイトのルートディレクトリに配置されていない、または既存の PWA の Service Worker とスコープが競合し、購読に失敗している。
• iOS ユーザーがサイトをホーム画面に追加していない、または権限リクエストがユーザー操作によってトリガーされていない。
• ユーザーがシークレットモード、プライベートブラウジング、ゲストモードを使用している。これらのモードは Web Push をサポートしません。
• 同じ user_str で複数のブラウザやデバイスから購読すると、新しい購読が古い購読を置き換え、最後に購読したデバイスだけがメッセージを受信します。

1.2 有効ターゲットから送信までに大きな損失があるか

確認する場所：

• プッシュ履歴：単一プッシュの有効ターゲット数と送信数を比較し、メッセージ詳細の失敗理由を確認します。
• 統計 API のプッシュライフサイクル照会：target_invalid、sent_failed ステータスで特定デバイスの損失段階を特定できます。

よくある原因：

• 有効ターゲットの定義は「過去 365 日以内にアクティブ」であり、長期間非アクティブな購読は有効ターゲットになりません。
• 詳細設定 でデバイスごとの 1 時間 / 1 日 / 1 週間あたりの配信上限や配信可能時間帯が設定されており、上限超過または時間帯外のメッセージは直接破棄されます。

1.3 送信から到達までに大きな損失があるか

この段階は「表示が少ない」と最も誤認されやすい層です。到達数が少なければ表示数も必然的に少なくなりますが、その場合の表示率は正常であることがあります。

確認する場所：

• プッシュ履歴における単一プッシュの到達率、プッシュ統計におけるブラウザ別（Chrome、Safari、Firefox、Edge、EngageLab チャネルなど）の到達データ。
• 統計 API が返す sub フィールドでは notification と message の 2 種類のメッセージについて到達と表示を個別に確認でき、engageLab_web、chrome、safari、firefox、edge などのフィールドでチャネル別に分解できます。

よくある原因（プッシュ作成 API と FAQ を参照）：

• time_to_live が 0 に設定されている：オフラインメッセージが保持されず、現在オンラインのユーザーだけが受信できます。デフォルトは 86400 秒（1 日）、最長 15 日です。
• チャネルの違い：EngageLab チャネルはユーザーがお客様のサイトページを開いている必要があります。システムチャネル（Chrome、Edge、Firefox など）はブラウザプロセスが OS 上に存在していれば受信できますが、ブラウザが完全に終了していると受信できません。Safari のシステムチャネルはブラウザの起動を必要としません。
• ユーザーがブラウザの Cookie / キャッシュを消去し、ベンダーチャネルの購読情報も失われた。通知権限が「許可」のままであれば、ユーザーがサイトに戻り SDK が初期化された時点で自動的に再購読され、新しい Registration ID が発行されます。権限が「確認」や「ブロック」に変更されている場合は自動再購読されません。
• third_party_channel.w3push.distribution の配信戦略がユーザー行動と合っていない。例えば、ユーザーがサイトにほとんど滞在しないのに mtpush（EngageLab チャネルのみ）を強制している。
• ブラウザベンダーのチャネルが不安定。この場合 FAQ では EngageLab チャネル優先の配信への切り替えを推奨しています。

1.4 到達から表示までに損失があるか（表示率が低い）

到達数が正常で表示数が明らかに少ない場合こそ、真の「表示率」の問題です。

確認する場所：

• プッシュ履歴の詳細でプラットフォーム別に表示される「到達数 / 表示数」とその比率。
• コールバック API の Impression と impression_failed イベント。

よくある原因：

1.5 調査チェックリスト

調査時は下表の順に各項目を確認し、定義や上流の問題を先に除外してから表示そのものを見ることを推奨します。

第 2 部：原因が判明した後の最適化

2.1 購読者プールを拡大する

• ガイド付きリクエスト（ソフトプロンプト）に切り替える。 基本設定 の通知権限で「ガイド付きリクエスト」を選択します。まずカスタムスタイルで通知の価値をユーザーに説明し、ユーザーが意思を示した後にネイティブ権限ダイアログをトリガーします。これにより、価値を理解しないまま Block をクリックして権限を永久に再リクエストできなくなる事態を防げます。ソフトプロンプトは初回表示間隔（デフォルト 3 日）と以降の表示間隔（デフォルト 7 日）を設定でき、ユーザーが購読するまで継続します。
• 前提条件を完全に満たす。 サイトで HTTPS を使用し、【統合設定】-【Web サイトドメイン】でドメインを設定します（最大 100 件）。Service Worker ファイルは最大のスコープを得るためサイトのルートに配置します。サイトに既存の PWA Service Worker がある場合は両者を統合するか、スコープが重複しないようにします。詳細は Web SDK 統合ガイド と FAQ を参照してください。
• iOS ユーザー向けのガイドを用意する。 iOS / iPadOS 16.4 以降の Safari では、ユーザーがまずサイトをホーム画面に追加してそこから開き、その後ユーザー操作（購読ボタンのタップなど）で権限をトリガーする必要があります。ページ上にバナーで案内を置くことを推奨します。
• デバイス同士の押し出しを避ける。 user_str でユーザーを識別している場合、同じ user_str が複数のブラウザ / デバイスで購読すると、最後に購読したデバイスだけがメッセージを受信する点に注意してください。ユーザーの全デバイスをカバーしたい場合は、異なるデバイスで同じ user_str を再利用しないでください。
• 移行時に購読を失わない。 他社サービスから EngageLab へ移行する際は、Web プッシュ移行時の購読ユーザー流出を防ぐ方法 に従って旧 Service Worker を処理してください。すでに権限を付与済みのユーザーには、初期化後に権限ダイアログが再表示されることはありません。

2.2 有効ターゲットから送信までの損失を減らす

• 詳細設定 で、業務上の必要に応じてデバイスごとの配信上限と配信可能時間帯を設定します。頻度制御はユーザー体験を守る手段ですが、厳しすぎる設定はメッセージを直接破棄するため、配信計画と合わせて評価してください。
• ユーザー削除 API を定期的に使い、非アクティブと確認できた購読を整理します。これにより有効ターゲット数が到達可能なユーザーをより正確に反映し、無効な購読で統計が希薄化するのを防げます。削除は取り消せないため慎重に実行してください。

2.3 到達を改善する

• time_to_live を適切に設定する。 0 は使わず、デフォルトの 1 日を維持するか、コンテンツの時効性に応じて最長 15 日まで延長します。時効性の低いコンテンツはオフライン保持期間を長めにすると、オフラインのユーザーがブラウザを再度開いたときにも受信できます。

• 状況に合った配信戦略を選ぶ。 third_party_channel.w3push.distribution では次から選択します。

  • first_ospush（デフォルト）：システムチャネル優先、無効な場合は EngageLab チャネルで配信。
  • secondary_push：EngageLab チャネル優先、ユーザーがオフラインならシステムチャネルで配信。プッシュ作成 API ではこの方式を推奨しています。
  • mtpush：EngageLab チャネルを強制。ユーザーがサイトに長く滞在するケースのみに適します。
  • ospush：システムチャネルのみを強制。

  ブラウザベンダーのチャネルが不安定な場合は、一時的に EngageLab チャネル優先に切り替えることができます。

• override_msg_id は慎重に使う。 未消去の前回通知を上書きすると、ユーザーには最新の 1 件だけが表示されます。内容更新のシナリオには適しますが、複数の通知をすべて表示したいシナリオには適しません。

• セールや大量配信ではレート制限付き配信を使う。 big_push_duration で指定した分数（最大 1440 分）にわたって配信を均等に分散し、瞬間的なピークを避けます。

2.4 表示を改善する

• 通知メッセージを優先する。 通知領域に表示して表示数を集計したいコンテンツには message ではなく notification を使用します。業務上カスタムメッセージが必要な場合は、ページに表示した後に customDisplayReport('msg_id') で表示をレポートし、クリック時に customClickReport('msg_id') を呼び出します。
• 短時間に同じユーザーへ連続して複数の通知を送らない。 Chrome、Edge、Firefox では後の通知が前の通知を置き換え、ユーザーは最後の 1 件しか見られず、表示数も 1 件しか計上されません。複数の内容を 1 件にまとめるか、送信間隔を空けてください。
• 素材と文言のブラウザ互換性に注意する。 icon は 192×192・1 MB 以下を推奨し、カスタムアイコンは Chrome と Firefox のみ対応で、Safari と Edge はシステムデフォルトのアイコンを使用します。image は 360×180・1 MB 以下を推奨し、Chrome と Edge のみ対応で、Firefox と Safari は非対応です。システムチャネルにはタイトル長の制限（中国語 20 文字未満、英語 40 文字未満）があり、長すぎると表示に影響する可能性があります。
• アプリ内メッセージに適切な表示有効期間を設定する。 表示有効期間を過ぎるとユーザーがページに戻っても表示されず、impression_failed がトリガーされます。時効性の低いコンテンツは有効期間を長めにし、画像ダウンロード失敗を避けるため画像サイズを抑えてください。
• ユーザーのアクティブな時間帯に配信する。 スケジュールタスク のインテリジェント配信、またはプッシュ統計のアクティブ時間マッチングデータを活用し、ユーザーがブラウザを開いている可能性が高い時間帯に配信して、オフラインによる期限切れを減らします。
• Safari のデータを正しく解釈する。 Safari のシステムチャネルでは表示・クリックのコールバックを取得できないため、このチャネルの表示数が低いのは統計機能の制限であり、通知が表示されていないことを意味しません。表示率を評価する際は Safari を他チャネルと分けて見ることを推奨します。

第 3 部：総合的なアプローチで表示数を体系的に増やす

単発の最適化では一つの段階の問題しか解決できません。表示数を継続的に増やすには、「購読の拡大、到達の保証、表示のモニタリング」を日常的な運用の仕組みとして回すことを推奨します。

3.1 チャネル別のモニタリングビューを構築する

• 概況 のプッシュコンバージョンファネル、到達率・表示率・クリック率の推移、通知権限を有効 / 無効にしたユーザー数を毎日確認します。
• プッシュ統計 でブラウザ別に到達と表示を確認し、Chrome と EngageLab チャネルに重点を置き、Safari は個別に評価します。
• コールバック API で delivered、Impression、impression_failed、click などのイベントを受信して保存すれば、コンソールよりも細かい粒度でユーザー別・メッセージ別の分析ができます（メッセージ単位の統計は EngageLab 側で最長 1 か月保持されます）。
• 到達率と表示率にそれぞれベースラインを設定します。到達率が異常に低下した場合は time_to_live、配信戦略、ベンダーチャネルを優先的に調査し、表示率が異常に低下した場合はメッセージ種別、複数通知の上書き、ユーザー側の権限を優先的に調査します。

3.2 フェーズ別アクションリスト

導入期（リリース前後）

• HTTPS を使用し、ドメインを設定し、Service Worker をルートに配置してスコープの競合がないことを確認する。
• 通知権限で「ガイド付きリクエスト」を選択し、ソフトプロンプトの文言と間隔を設定する。
• iOS ユーザー向けにホーム画面追加の案内を用意する。
• カスタムメッセージ（message）ではなく通知メッセージ（notification）を主要なリーチ手段とする。
• 結合テスト時に、プッシュ履歴とデータ照会で対象デバイスのオンライン状態、到達、表示が正しく計上されることを確認する。

成長期（日常運用）

• 購読ユーザーとアクティブユーザーの増加を毎週比較し、購読転換が悪い場合はソフトプロンプトの文言とトリガーのタイミングを調整する。
• time_to_live は 1 日以上を維持し、distribution は secondary_push またはデフォルト戦略を使用する。
• 同じユーザーへの配信頻度を制御し、上書きによる表示損失を避けつつ、頻度制御で体験を保護する。
• インテリジェント配信やアクティブ時間マッチングデータを活用して送信時間帯を選ぶ。
• 長期間非アクティブな購読を定期的に整理する。

セール期（ピーク配信）

• レート制限付き配信でピークを平準化する。
• 時効性の高いコンテンツは time_to_live を短くし、後から届いてもよいコンテンツはオフライン保持を延長する。
• 複数のマーケティング通知を 1 件に統合するか、ユーザーごとにバッチ分けして時間をずらして送信する。
• 配信後にチャネル別の到達率と表示率を振り返り、異常のあったチャネルの知見を次回の配信設定に反映する。

3.3 一言でまとめると

表示数 = 購読ユーザー × 有効ターゲット比率 × 到達率 × 表示率。まずファネルデータで損失がどの段階で発生しているかを判断し、その段階を最適化します。「表示」の段階そのものについては、通知メッセージを使用して SDK レポートを確実にすること、複数通知の上書きを避けること、チャネル別にデータを解釈することが核心です。

参考ドキュメント

• Web SDK 統合ガイド
• Web SDK API
• 基本設定
• 詳細設定
• プッシュ作成 API
• コールバック API
• 統計 API
• プッシュ統計
• プッシュ履歴
• FAQ
• Web プッシュ移行時の購読ユーザー流出を防ぐ方法