Push-платформа сообщает о 1 200 доставках, а в сегменте всего тысяча клиентов. Кажется, что охват превысил 100%. Обычно причина проще: один человек пользуется несколькими устройствами, а система считает технические адреса доставки.

Для push нужны как минимум две единицы учёта: клиент и зарегистрированная установка приложения или браузера. Адрес доставки связан с технической регистрацией; он не является паспортом человека. Один клиент может иметь несколько адресов, а связь устройства с аккаунтом может измениться.

Firebase отдельно описывает поддержку актуальности регистраций, хранение времени обновления и работу с неактивными адресами. Конкретный механизм адресации зависит от сервиса и версии SDK: это может быть регистрационный токен или идентификатор установки. Для бизнес-отчёта важнее сохранить правильную связь между адресом, установкой и клиентом.

Не смешивайте уровни в одной доле

Условный пример. В сегменте тысяча известных клиентов и 1 400 зарегистрированных адресов. Сервис зафиксировал успешную техническую доставку на 1 200 адресов; они принадлежат 900 уникальным клиентам.

Доля доставок по адресам — около 85,7%. Охват известных клиентов хотя бы одной такой доставкой — 90%. Деление 1 200 на тысячу даёт 120%, но эта величина не является долей охваченных людей.

Даже 90% не означает, что столько клиентов увидели сообщение. Приём сервисом, доставка на устройство, показ и нажатие — разные события. Доступность каждого подтверждения зависит от платформы и настройки сбора. Если показ не измеряется, его нельзя подменять доставкой без оговорки.

Постройте два связанных отчёта

УровеньПоказателиНа какой вопрос отвечает
Регистрация и отправкаДействующие адреса, попытки, ошибки, подтверждённые статусыРаботает ли техническая доставка
КлиентУникальные назначенные, охваченные и нажавшие клиентыДо скольких известных клиентов удалось дойти
ЭкспериментПокупки и вклад на назначенного клиентаИзменило ли воздействие бизнес-результат

Для каждого показателя сохраните определение знаменателя. «CTR push» может означать клики по доставкам на устройства или долю нажавших клиентов. Название без единицы учёта оставляет слишком много вариантов интерпретации.

События без надёжной связи с клиентом показывайте отдельно как анонимные установки. Они могут быть полезной аудиторией, но не должны автоматически увеличивать счётчик уникальных людей.

Храните историю связи с аккаунтом

В таблице соответствия нужны клиентский ID, ID установки, адрес доставки, время начала и окончания связи, источник обновления и последнее подтверждённое состояние регистрации. Набор полей адаптируют к платформе; лишние персональные данные для этой задачи не нужны.

При выходе из аккаунта прежняя привязка не должна продолжать отправлять персональные сообщения предыдущему пользователю. При новом входе связь обновляется по установленным правилам. Историческое событие связывают с аккаунтом на момент события, а не обязательно с сегодняшним владельцем установки.

Переустановка приложения или изменение регистрации не должны создавать «нового покупателя», если клиентский ID известен. И наоборот, общий планшет магазина нельзя считать одним человеком только потому, что у него одна установка.

Отдельно учитывайте разрешение и доступность

Наличие адреса не гарантирует актуальное разрешение на уведомления или право отправить конкретное маркетинговое сообщение. Техническую регистрацию, настройки ОС, предпочтения клиента и необходимые согласия проверяют по своим источникам.

Отсутствие подтверждения доставки не всегда равно запрету уведомлений. Устройство могло быть недоступно, сообщение — просрочено, а нужное событие — не поддерживаться. В отчёте полезна категория «статус неизвестен» вместо ложной точности.

Как измерить эффект канала

Если задача относится к клиенту, назначайте экспериментальный вариант по устойчивому клиентскому ID и применяйте его ко всем известным установкам этого клиента. Иначе телефон попадёт в тест, планшет — в контроль, а покупку будет трудно интерпретировать.

Сохраняйте всех назначенных участников в основной оценке, включая тех, кому сообщение не дошло. Отдельная диагностика доставки помогает понять исполнение, но сравнение только получивших сообщение теряет защиту случайного назначения.

Для анонимной аудитории можно строить эксперимент по установкам, явно ограничив вывод этой единицей. Смешивать такой результат с эффектом на известных клиентов без дополнительного метода нельзя. Корректный отчёт показывает техническое качество, реальный доступный охват и инкрементальный эффект push как три связанные, но разные задачи.

Источники

Google Firebase. Best Practices for FCM Registration Management. Firebase Cloud Messaging Documentation. Проверено 23.09.2026.