Ваше приложение отправляет три уведомления в течение минуты, и телефон игрока отображает одно баннерное уведомление. Это не ошибка вашего поставщика push-уведомлений. Это механизм подавления уведомлений Android, включенный по умолчанию в Android 16, который незаметно переписывает правила для каждого отправителя с большим объемом сообщений. Если вы отправляете push-уведомления для приложения для ставок или игр, ваши самые ценные моменты — это именно те, на которые он нацелен: гол, изменение коэффициентов и предложение вывода средств поступают в течение одной и той же минуты. В этой статье рассказывается о том, что делает механизм подавления, о лимитах скорости FCM, которые уже существовали под ним, и о шаблонах проектирования отправки, которые гарантируют, что ваше приложение будет услышано.
Что механизм подавления уведомлений Android делает с серией уведомлений
Android 16 достиг стабильной версии 10 июня 2025 года, и вместе с ним был выпущен механизм подавления уведомлений, включенный по умолчанию. Это поведение было впервые задокументировано в предварительных версиях для разработчиков Android 16 в конце 2024 года, когда оно еще было опциональным переключателем. В стабильной версии Google включил его для всех.
Механизм прост. Когда приложение отправляет серию уведомлений, первое уведомление оповещает нормально, на полной громкости, с полным баннером. Каждое последующее уведомление в серии постепенно уменьшается по громкости и визуально минимизируется в течение одной минуты, а серия группируется под одним баннером. Ничего не удаляется. Уведомления по-прежнему поступают, по-прежнему находятся в трее, по-прежнему учитываются в ваших отчетах о доставке. Они просто перестают требовать внимания.
Последний пункт важен для того, как вы читаете свои панели мониторинга. Коэффициент доставки не изменится. Изменится все, что следует за вниманием: просмотры, клики и конверсии, которые должны были обеспечить ваши второе и третье уведомления.
Уведомления Android 16: что по-прежнему оповещает, а что приглушается
Механизм подавления не обрабатывает все уведомления Android 16 одинаково. Звонки, будильники и приоритетные разговоры освобождаются; они оповещают нормально, независимо от того, как быстро они накапливаются. Все остальное подвержено кривой приглушения, и это охватывает все уведомления приложений для ставок, как маркетинговые, так и транзакционные.
Одно примечание о применимости, и это скорее вывод, чем задокументированное заявление платформы: механизм подавления работает на уровне уведомлений, поэтому по механизму он должен применяться как к push-уведомлениям приложений, доставляемым через FCM, так и к веб-push-уведомлениям, которые Chrome отображает на Android. Если ваш бренд управляет как приложением, так и мобильным сайтом, рассматривайте уведомления Android 16 из обоих каналов как разделяющие один бюджет внимания на одном и том же устройстве.
Лимиты скорости FCM уже ограничивали вас
Период ожидания — это видимый слой. Под ним Firebase Cloud Messaging годами применяет ограничение частоты отправки сообщений для каждого устройства. В документации FCM установлены лимиты: 240 сообщений в минуту и 5000 в час для одного устройства, и предупреждает, что отправители, работающие вблизи этих пределов, рискуют тем, что приложение будет помечено как злоупотребляющее.
Ни одна разумная кампания не отправляет 240 сообщений в минуту одному пользователю. Но эти ограничения частоты FCM действуют на каждое устройство, а не на кампанию, что означает, что каждая система, которую вы запускаете, использует один и тот же общий бюджет: ваша CRM, оповещения о коэффициентах вашего торгового движка, ваш планировщик промоакций, ваш транзакционный слой. Архитектура, в которой четыре системы ведут себя разумно, все равно может создать шаблон на уровне устройства, который воспринимается FCM как злоупотребление, а как всплеск — для периода ожидания.
Два механизма усугубляют друг друга. Ограничения частоты FCM ограничивают то, что физически может быть доставлено; период ожидания уведомлений Android решает, сколько из доставленного будет замечено. Отправители с большим объемом сообщений теперь проектируют с учетом обоих ограничений одновременно.
Почему уведомления букмекерских приложений вообще вызывают всплески
Букмекерские приложения вызывают всплески не потому, что команды CRM невнимательны. Они вызывают всплески, потому что лучшие моменты продукта по своей сути одновременны. Гол в отслеживаемом матче — это в тот же момент оповещение о счете, изменение коэффициентов и возможность вывода средств. Три разные системы отвечают за одно из этих сообщений, и ни одна из них не проверяет, что отправили другие две.
Вот всплеск, как его воспринимает телефон игрока в период ожидания:
| Время | Система | Уведомление | Что переживает игрок |
|---|---|---|---|
| 0:00 | CRM / лента событий | «ГОЛ. 1–0 в матче, который вы отслеживаете» | Полное оповещение: звук, вибрация, баннер |
| 0:15 | Торговый движок | «Коэффициенты изменились на рынке следующего гола» | Приглушенное: уменьшенный объем, свернуто, сгруппировано |
| 0:40 | Движок промоакций | «Кэшаут теперь доступен для вашей открытой ставки» | Еще более приглушенное: почти беззвучное, свернуто в группу |
Болезненная часть — это порядок. Запрос на кэшаут, единственное уведомление в этом всплеске, связанное с прямой прибылью, — это то, которое период ожидания похоронил, потому что оно прибыло третьим. Кто отправляет первым, тот владеет минутой. Прямо сейчас в большинстве стеков уведомлений букмекерских приложений побеждает та система, у которой наименьшая задержка, а не то сообщение, которое имеет наибольшее значение.
Последовательность уведомлений в день матча всегда требовала продуманной организации. Период ожидания превращает это из искусства в необходимость.
Шаблоны проектирования, которые выживают при всплесках push-уведомлений
Вы не можете отключить период ожидания для своих пользователей, и вам не следует этого делать; он наказывает именно тот шаблон, который ваши игроки уже презирали. Решение архитектурное. Четыре шаблона не позволяют всплескам push-уведомлений съесть ваш охват.
Разделяйте отправку по минутам, а не по секундам
Окно периода ожидания длится до минуты. Любые два уведомления, которые вы контролируете и которые попадают в это окно, конкурируют за одно оповещение. Поэтому установите разрыв между отдельными сообщениями для каждого подписчика, измеряемый минутами, и применяйте его везде, включая транзакционный путь, который большинство команд забывают учитывать. Оповещение о голе в 0:00 и запрос на кэшаут в 2:30 — оба оповещают нормально. Та же пара с интервалом в тридцать секунд — это одно оповещение и один призрак.
Назначьте всплеску одного владельца
Для каждого предсказуемого момента заранее решите, какое одно уведомление им владеет. Когда происходит событие, оповещение о счете, изменение коэффициентов или всплывающее окно для вывода средств? Выберите одно, обычно то, которое ближе всего к доходу, или то, на которое игрок явно подписался, и подавите или задержите остальные. Уровни приоритета лучше систем гонок.
Сверните обновления в одно уведомление
Отслеживание коэффициентов — классический виновник: пять изменений коэффициентов не должны быть пятью уведомлениями. Используйте замену сообщений, где новый полезный груз обновляет существующее уведомление в трее вместо добавления нового. FCM поддерживает поведение свертывания годами. Одно живое, постоянно обновляемое уведомление о коэффициентах никогда не запускает ограничение, и оно воспринимается как функция, а не как шум.
Разделите рассылку по сегментам
Рассылка на 500 000 подписчиков, которая уходит одной волной, также создает всплески на уровне населения, сталкиваясь со всем, что ваши системы отправляют в это окно. Разбейте рассылку на волны сегментов: сначала игроки, делающие ставки вживую на отслеживаемый матч, затем недавние депозиторы, а через несколько минут — более холодные сегменты или вообще ничего. Ваша модель сегментации игроков уже определяет волны; рассылка просто должна их учитывать.
Ограничение частоты уведомлений и тихие часы завершают работу
Четыре приведенных выше шаблона исправляют минуту. Ограничение частоты уведомлений исправляет день и неделю. Ограничение — это принуждение Google на уровне ОС к дисциплине, которую лучшие отправители уже навязали себе, и это будет не последний механизм принуждения. Установите внутренние пределы на подписчика в день и в неделю и масштабируйте их в зависимости от активности сегмента:
| Сегмент | Макс./день | Макс./неделя |
|---|---|---|
| Активен последние 7 дней, отслеживает события в реальном времени | 3–4 в дни матчей | 10–12 |
| Активен последние 7 дней, в ритме казино | 2 | 8–10 |
| Уходящие, 8–20 дней тишины | 1 | 3–4 |
| Спящие, 21+ дней | — | 1, затем повторно вовлечь или подавить |
Тихие часы — это жесткий пол под ограничениями: определите окно «не беспокоить» и не позволяйте ничему маркетинговому пересекать его. В этой вертикали ограничение частоты уведомлений — это также защита игрока, а не просто гигиена доставки. Ограничения, тихие часы и строгое правило отсутствия срочности для предложений о депозите — это одна и та же практика, рассматриваемая с двух точек зрения, и операторы, которые придерживаются этой линии, дают игрокам причину оставлять уведомления включенными. Руководство по удержанию клиентов для сайтов ставок охватывает полный стек гигиены.
Создание дисциплины интервалов в PushEngage
Каждый из приведенных выше шаблонов может быть создан в PushEngage Workflows сегодня, без пользовательской инфраструктуры отправки. Сайты ставок и игр на PushEngage отправили более 3,5 миллиардов уведомлений, и элементы управления формированием отправки существуют, потому что отправителям такого объема они нужны.
Узлы ожидания, доступные в планах Business и выше, являются примитивом интервалов: вставляйте ожидание на минуты, часы или дни между любыми двумя отправками в рабочем процессе, чтобы ни одна разработанная вами последовательность не могла вызвать перегрузку подписчика. Узлы принятия решений и критерии выхода, в тех же планах, — это то, как рабочий процесс проверяет состояние перед запуском, что на практике выглядит как «назначить владельца для перегрузки»: если сообщение с более высоким приоритетом уже отправлено, выйдите вместо того, чтобы добавлять еще одно.
Тихие часы настраиваются для каждого рабочего процесса с выбираемым вами резервным вариантом: пропустить отправку полностью или перенести ее на одну минуту после окончания окна, разрешенное в собственном часовом поясе каждого подписчика. Используйте перенос для предложений с ограниченным сроком действия и пропуск для оповещений, привязанных к моменту; стартовое уведомление, доставленное в 09:01, — это шум. Планирование с учетом часового пояса также позволяет вам распределять сегменты без скриптов, поскольку волны могут отправляться по местному времени, а не как один глобальный всплеск.
Две возможности находятся выше в иерархии планов: A/B-разделение путей внутри рабочего процесса начинается с Premium, а триггеры пользовательских событий и веб-хуки, компоненты, которые позволяют вашему торговому движку или событиям кошелька напрямую запускать рабочий процесс, начинаются с Growth. Если вы настраиваете полную настройку на стороне приложения, начните с push-уведомлений для приложений ставок, основного руководства для этой серии.
Chrome использует ту же тактику в Интернете.
Если вы также используете веб-push, та же логика взаимодействия теперь контролирует этот канал. С января 2026 года Chrome ежедневно оценивает каждый отправляющий источник по push-уведомлениям относительно времени, которое пользователи фактически проводят на сайте, и ограничивает отправителей, которых он классифицирует как деструктивных. Разный механизм, идентичное сообщение: платформы теперь измеряют внимание, и отправители, нацеленные на вовлеченных пользователей, сохраняют свой охват, в то время как спамеры теряют его. Веб-версия этой истории и архитектура сегментации, которая ей соответствует, рассматриваются в почему сегментация теперь является требованием к доставляемости.
Что изменить перед следующим игровым днем
Три шага, по порядку. Во-первых, проверьте отправки за прошлый месяц на предмет всплесков push-уведомлений на одном устройстве: выберите любого подписчика, получившего две или более уведомлений в течение минуты, определите, какие системы столкнулись, и отметьте, как часто скрытое уведомление было тем, к которому прилагался доход. Во-вторых, назначьте каждому предсказуемому моменту одно собственное уведомление и понизьте остальные до свернутых обновлений или отложенных последующих уведомлений. В-третьих, перенесите каждую повторяющуюся последовательность в рабочие процессы с узлами ожидания, ограничениями частоты и тихими часами, чтобы интервалы обеспечивались платформой, а не памятью команды.
Задержка уведомлений Android не снизила ваш охват. Она устранила иллюзию того, что три уведомления в минуту были тремя шансами быть замеченным. Отправители, которые распределяют, приоритизируют и группируют, будут оповещать на полную громкость, в то время как всплески их конкурентов будут сгруппированы в беззвучную группу. Если вы хотите получить элементы управления отправкой без их создания, push-уведомления приложений в PushEngage поставляются с узлами ожидания, тихими часами и планированием по часовым поясам на каждом платном уровне, с гарантией возврата денег в течение 14 дней.
