アプリが 1 分以内に 3 つの通知を送信すると、プレイヤーの電話には 1 つのバナーが表示されます。それはプッシュプロバイダーのバグではありません。これは Android 16 でデフォルトで有効になった Android 通知クールダウンであり、大量の送信者向けのルールを静かに書き換えます。ベッティングアプリやゲームアプリのプッシュを実行している場合、最も価値のある瞬間はまさにそれがターゲットとする瞬間です。ゴール、オッズの変動、キャッシュアウトのプロンプトが同じ 60 秒以内に発生します。この記事では、クールダウンが何をするのか、その下にすでにあった FCM レート制限、そしてアプリが認識され続けるための送信設計パターンについて説明します。
Android 通知クールダウンがバーストに与える影響
Android 16 は 2025 年 6 月 10 日に安定版に到達し、通知クールダウンがデフォルトで有効になって出荷されました。この動作は、2024 年後半の Android 16 開発者プレビューで最初に文書化されましたが、当時はまだオプトインのトグルでした。安定版リリースでは、Google はすべての人にそれをオンにしました。
仕組みは単純です。アプリが通知のバーストを送信すると、最初の通知は通常の音量と完全なバナーで通常どおりアラートされます。バースト内の後続の各通知は、最大 1 分間、音量が徐々に低下し、視覚的に最小化され、バーストは単一のバナーの下にグループ化されます。何も削除されません。通知は引き続き到着し、トレイに残り、配信レポートにカウントされます。単に注意を引くことをやめるだけです。
最後の点は、ダッシュボードの読み方に影響します。配信率は変わりません。変化するのは、注意のその下流にあるすべて、つまりビュー、クリック、そして 2 番目と 3 番目の送信が推進するはずだったコンバージョンです。
Android 16 通知:アラートされるもの、静かになるもの
クールダウンは、すべての Android 16 通知を同じように扱いません。通話、アラーム、優先度の高い会話は免除されており、どれだけ速くスタックしても通常どおりアラートされます。それ以外はすべて静音化曲線に従い、ベッティングアプリの通知、マーケティングおよびトランザクションの両方が対象となります。
1 つの適用可能性に関する注意点ですが、これは文書化されたプラットフォームの声明というよりは推測です。クールダウンは通知レイヤーで動作するため、仕組み上、FCM から配信されるアプリプッシュと、Chrome が Android 上でレンダリングするウェブプッシュ通知の両方に適用されるはずです。ブランドがアプリとモバイルサイトの両方を運営している場合は、同じデバイス上の 1 つの注意予算を共有する両方のチャネルからの Android 16 通知として扱ってください。
FCM レート制限はすでにあなたを制限していました
クールダウンは可視レイヤーです。その下では、Firebase Cloud Messaging は長年、デバイスごとのスロットリングを強制してきました。FCM ドキュメントでは、単一デバイスへのメッセージ数を 1 分あたり 240 件、1 時間あたり 5,000 件に制限しており、制限に近い送信者はアプリが悪用されているとフラグ付けされるリスクがあると警告しています。
まともなキャンペーンで1人のユーザーに1分あたり240件のメッセージが送信されることはありません。しかし、これらのFCMレート制限はキャンペーンごとではなくデバイスごとであるため、実行するすべてのシステムが同じ共有予算(CRM、取引エンジンのオッズアラート、プロモスケジューラ、トランザクションレイヤー)に対して送信されます。4つのシステムがそれぞれ合理的に動作するアーキテクチャでも、FCMには不正行為、クールダウンにはバーストとして認識されるデバイスレベルのパターンが生成される可能性があります。
2つのメカニズムが組み合わさります。FCMレート制限は物理的に到達できるものを制限し、Android通知クールダウンは到達したもののうちどれだけが認識されるかを決定します。大量の送信者は現在、両方に対して同時に設計しています。
そもそもベッティングアプリの通知がバーストする理由
ベッティングアプリがバーストするのは、CRMチームが不注意だからではありません。製品の最高の瞬間が本質的に同時であるためバーストします。フォローしている試合でのゴールは、瞬時にスコアアラート、オッズの変動、キャッシュアウトの機会となります。3つの異なるシステムがそれぞれそれらのメッセージの1つを所有しており、どれも他の2つが送信したものをチェックしません。
クールダウン下でプレイヤーの電話が体験するバーストは次のとおりです。
| 時間 | システム | 通知 | プレイヤーが体験すること |
|---|---|---|---|
| 0:00 | CRM / イベントフィード | 「ゴール。フォロー中の試合で1-0」 | フルアラート:サウンド、バイブレーション、バナー |
| 0:15 | 取引エンジン | 「次のゴールマーケットでオッズが変動しました」 | 静音化:音量を下げ、最小化し、グループ化 |
| 0:40 | プロモエンジン | 「オープンベットで今すぐキャッシュアウト可能」 | さらに静音化:ほぼ無音、グループに折りたたまれる |
痛いのは順序です。キャッシュアウトプロンプトは、そのバーストの中で直接収益が付随する唯一の通知ですが、3番目に到着したためクールダウンによって埋もれてしまいました。最初に送信した人がその分を制します。現在、ほとんどのベッティングアプリの通知スタックでは、勝者はレイテンシが最も低いシステムであり、最も重要なメッセージではありません。
試合日のプッシュシーケンスは、常に意図的なシーケンスを必要としてきました。クールダウンはそれを技術から要件に変えます。
プッシュ通知のバーストを乗り切るデザインパターン
ユーザーのためにクールダウンをオフにすることはできませんし、そうすべきではありません。それはプレイヤーがすでに不満に思っていたパターンを罰することになります。修正はアーキテクチャです。4つのパターンにより、プッシュ通知のバーストがリーチを食い尽くすのを防ぎます。
秒ではなく分単位で送信を間隔を空ける
クールダウンウィンドウは最大1分間実行されます。制御する2つの通知がそのウィンドウ内に着信すると、1つのアラートを競合します。したがって、個別のメッセージ間で分単位で測定されるサブスクライバーごとの間隔を強制し、ほとんどのチームがカウントし忘れるトランザクションパスを含むすべての場所でそれを強制します。0:00のゴールアラートと2:30のキャッシュアウトプロンプトは、どちらも通常どおりアラートされます。30秒間隔の同じペアは、1つのアラートと1つのゴーストです。
バーストに単一の所有者を割り当てる
予測可能なすべての瞬間に、どの通知がそれを所有するかを事前に決定します。目標が達成されたとき、スコアアラート、オッズの変動、またはキャッシュアウトプロンプトのいずれがトリガーされますか? 1つを選択します。通常は収益に最も近いもの、またはプレイヤーが明示的に購読したものを選び、残りは抑制または遅延させます。優先度レベルはレーシングシステムよりも優れています。
更新を1つの通知に折りたたむ
オッズ追跡は古典的な原因です。5回のオッズ変動が5回の通知になるべきではありません。メッセージ置換を使用します。これにより、新しいペイロードがトレイ内の既存の通知を更新し、新しい通知を積み重ねるのではなく、FCMは長年折りたたみ動作をサポートしてきました。1つのライブで継続的に更新されるオッズ通知は、クールダウンをトリガーすることはなく、ノイズではなく機能として読み取られます。
セグメントごとにファンアウトをずらす
1回の波で送信される500,000人の購読者への一斉送信は、人口レベルでもバーストを生成し、そのウィンドウでシステムが送信する他のものと衝突します。ファンアウトをセグメントの波に分割します。まず、フォローしている試合のライブベッター、次に最近の入金者、数分後に、またはまったく送信しないクールなセグメント。あなたのプレイヤーセグメンテーションモデルはすでに波を定義しています。ファンアウトはそれらを尊重するだけで済みます。
通知頻度の上限設定とサイレントアワーが仕事を完了します
上記の4つのパターンは分単位の問題を解決します。通知頻度の上限設定は、日単位および週単位の問題を解決します。クールダウンは、OSレベルで、最高の送信者がすでに自身に課している規律をGoogleが強制するものであり、最後の強制メカニズムにはなりません。加入者あたり1日あたりおよび1週間あたりのハウスの上限を設定し、セグメントの熱によってそれらをスケーリングします。
| セグメント | 1日あたりの最大数 | 1週間あたりの最大数 |
|---|---|---|
| 過去7日間アクティブ、ライブイベントをフォロー | 試合日は3〜4件 | 10〜12件 |
| 過去7日間アクティブ、カジノのリズム | 2 | 8〜10件 |
| 休止中、8〜20日間サイレント | 1 | 3〜4件 |
| 休止中、21日以上 | — | 1件、その後再エンゲージまたは抑制 |
サイレントアワーは上限の下のハードフロアです。おやすみモードのウィンドウを定義し、マーケティング的なものは何も通過させないでください。この垂直方向では、通知頻度の上限設定は、配信衛生のためだけでなく、プレイヤー保護でもあります。上限、サイレントアワー、および入金プロンプトに対する厳格な緊急性なしルールは、2つの角度から見た同じプラクティスであり、そのラインを維持するオペレーターは、プレイヤーに通知をオンにしておく理由を与えます。ベッティングサイトの保持プレイブックは、完全な衛生スタックをカバーしています。
PushEngageに間隔規律を構築する
上記のすべてのパターンは、カスタム送信インフラストラクチャなしで、今日のPushEngageワークフローで構築可能です。PushEngageのベッティングおよびゲーミングサイトは35億件以上の通知を送信しており、送信シェーピングコントロールは、そのボリュームの送信者が必要とするため存在します。
待機ノードは、ビジネスプラン以上で利用可能であり、スペーシングの基本となります。ワークフロー内の任意の2つの送信の間に数分、数時間、または数日間の待機を挿入できるため、設計したシーケンスが購読者をバーストすることはありません。同じプランの決定ノードと終了基準は、ワークフローが状態をチェックしてからトリガーする方法であり、実際には「バーストした1つの所有者に割り当てる」とは、高優先度のメッセージが既に出力された場合は、積み重ねるのではなく終了することです。
サイレントアワーは、ワークフローごとにフォールバックを選択して設定できます。送信を完全にスキップするか、ウィンドウ終了の1分後に再スケジュールするか、各購読者のタイムゾーンで解決されます。オファーの有効期限がある場合は再スケジュールを使用し、瞬間的なアラートの場合はスキップを使用します。午前9時1分に配信されたキックオフ通知はノイズです。タイムゾーン対応のスケジュール設定により、スクリプトなしでセグメントごとにファンアウトを段階的に実行することもできます。波は、グローバルな一括送信としてではなく、ローカル時間に開始できるためです。
さらに上位のプランには2つの機能があります。ワークフロー内のA/Bスプリットパスはプレミアムから開始され、カスタムイベントトリガーとWebhook(取引エンジンまたはウォレットイベントがワークフローを直接開始できるコンポーネント)はグロースから開始されます。アプリ側の設定全体をマッピングする場合は、このシリーズの主要ガイドであるベッティングアプリのプッシュ通知から始めてください。
Chromeはウェブでも同じプレイを実行しています
ウェブプッシュも実行している場合、同じエンゲージメントロジックが現在そのチャネルを管理しています。2026年1月以降、Chromeは毎日、ユーザーが実際にサイトに滞在している時間に基づいてプッシュを送信しているすべての送信元をスコアリングし、破壊的と分類した送信者をスロットリングします。メカニズムは異なりますが、メッセージは同じです。プラットフォームは現在注意力を測定しており、エンゲージされたユーザーをターゲットにする送信者はリーチを維持しますが、バスターはそれを失います。このストーリーのウェブ側のバージョンと、それに対応するセグメントアーキテクチャについては、セグメンテーションがデリバリー要件になった理由で説明しています。
次の試合日の前に変更すべきこと
3つの手順を順番に実行します。まず、先月の送信で、同じデバイスでのプッシュ通知のバーストを監査します。1分以内に2つ以上の通知を受信した購読者をプルし、どのシステムが衝突したかを特定し、埋め込まれた通知が収益に関連する通知であった頻度を記録します。次に、予測可能な各モーメントに単一の所有通知を割り当て、残りは折りたたまれた更新または遅延フォローアップに降格します。3番目に、すべての繰り返しシーケンスを、待機ノード、頻度キャップ、およびサイレントアワーを備えたワークフローに移動し、スペーシングがチームの記憶ではなくプラットフォームによって強制されるようにします。
Androidの通知クールダウンは、あなたのリーチを奪ったわけではありません。それは、1分間に3回の通知が、見てもらえるチャンスが3回あるという幻想を奪ったのです。間隔を空け、優先順位を付け、まとめる送信者は、競合他社のバーストがサイレントグループに折りたたまれる一方で、フルボリュームでアラートを発します。それらを作成せずに送信シェーピングコントロールが必要な場合は、PushEngageのアプリプッシュ通知には、すべての有料プランで、待機ノード、サイレントアワー、タイムゾーンスケジューリングが付属しており、14日間の返金保証が付いています。