Пуши и retention: сколько заказов на самом деле добавляют уведомления

В конце октября, когда сентябрьской когорте исполнилось 30 дней, продакт-менеджер приложения доставки продуктов приносит на планёрку цифры. Из 1 170 человек, сделавших первый заказ, снова заказали 50% тех, у кого включены уведомления, и 19% остальных. Он уже сделал вывод: просить разрешение на уведомления при первом запуске, а маркетологу слать акции два раза в неделю. Когорта та же, что в уроке про in-app события, цифры условные.

Кто вообще может получить пуш

Пуш доходит только до тех, кто разрешил уведомления, а правила разрешения у Android и iPhone разные.

Android. С Android 13 уведомления у только что установленного приложения выключены, пока человек не выдаст разрешение POST_NOTIFICATIONS. Если приложение собрано под Android 13 и новее, момент запроса выбирает команда; под 12L и ниже система спросит сама при первом запуске; а если приложение стояло на телефоне до обновления до Android 13 и уведомления в нём не выключали, разрешение переносится само. На телефонах с Android 12 и ниже такого разрешения нет: уведомления включены, пока человек их не выключит.

iPhone. Системное окно iOS показывает один раз: при первом запросе спрашивает и запоминает ответ, а следующие запросы окна уже не открывают. Передумать человек может только в настройках телефона. Apple советует спрашивать в момент, когда человеку понятно, зачем приложению уведомления. Есть и временное разрешение (provisional): уведомления приходят тихо, без звука и баннера, только в историю Центра уведомлений, и на них есть кнопки Keep и Turn Off. Для «курьер у двери» тихое уведомление бесполезно, для подборок может подойти.

Справка для Android-разработчиков приводит как удачный момент для запроса ровно наш случай: человек только что оформил заказ доставки еды. Для продуктов это экран после первого заказа с текстом «Сообщим, когда курьер будет у двери». При первом запуске человек ещё ничего не заказал и не понимает, зачем ему уведомления, а на iPhone второго окна уже не будет.

Разрешение системы - ещё не согласие на рекламу. По правилу 4.5.4 App Review пуши с акциями можно слать только тем, кто явно согласился на них в интерфейсе приложения, и выключить их человек должен иметь возможность в самом приложении. Поэтому в настройках нужен отдельный пункт «Акции и подборки». На Android под него заводят отдельный канал уведомлений: с Android 8.0 каждое уведомление принадлежит каналу, Google советует заводить канал на каждый тип уведомлений, и человек может приглушить акции, оставив статусы заказа.

Долю разрешивших считают по статусу разрешения. Приложение при каждом запуске читает, включены ли уведомления (на Android areNotificationsEnabled(), на iOS getNotificationSettings), и передаёт статус в аналитику свойством пользователя. Как его назвать, решает план событий из урока про in-app события. Токенов в базе бывает больше, чем людей, которые увидят пуш: у покупателя может быть два телефона, а Firebase советует считать токен устаревшим, если устройство месяц не выходило на связь, и сам удаляет Android-токены, неактивные 270 дней (управление токенами FCM). И смотрят долю отдельно по iOS и по версиям Android: телефоны с Android 12 и ниже дают включённые уведомления без всякого запроса и поднимают общую цифру.

При выходе из аккаунта токен отвязывают от клиента, иначе пуш одного человека придёт на телефон, которым уже пользуется другой. А в самом тексте пуша не должно быть ничего личного: он виден на заблокированном экране, и то же правило 4.5.4 запрещает слать в пушах конфиденциальные данные.

Уведомления и повторные заказы по источникам

В уроке про in-app события сентябрьская когорта к D30 дала 1 170 первых покупателей, и 440 из них (38%) заказали снова. Там же объяснено, почему удержание приложения доставки меряют повторным заказом. Статус уведомлений AppsFlyer не знает, поэтому его добавляют к той же когорте в продуктовой аналитике, куда передана атрибуция, как в уроке про аналитику мобильного приложения.

Уведомления включили 702 первых покупателя из 1 170, то есть 60%: из Google 65%, из Meta и Apple Ads по 60-61%, из TikTok 50%. Как и в когортном анализе, проценты считают от первых покупателей когорты. Тянет связать это с возвратами: повторных заказов у TikTok тоже меньше всех, 32% против 37-41% у других сетей. Но на 190 покупателях эта разница от случайной не отличается, это разобрано в том же уроке про in-app события. Причину такое совпадение тоже не назовёт: и уведомления, и возвраты могут зависеть от того, каких людей приводит сеть.

Продакт-менеджер разрезал всех 1 170 покупателей по статусу уведомлений. Из 702 с включёнными уведомлениями повторно заказали 351 (50%), из 468 без них 89 (19%). Разница большая, и на таких выборках она не случайна. Но разрешение приложение просит после первого заказа, и соглашаться охотнее могут те, кто и так собирается заказывать снова. Поэтому 50% против 19% смешивают две вещи, эффект пушей и то, что уведомления включают другие люди, и по этим цифрам их не разделить. Запрос при первом запуске поменяет, кто разрешает уведомления, но сколько заказов приносят пуши, всё равно останется неизвестно. Ответ даёт только сравнение со случайной группой, которой пуш не отправляли.

Holdout: сколько заказов добавляет пуш

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

Команда берёт 6 000 покупателей, у которых включены уведомления и акции и которые не заказывали 7 дней и больше. Половину, выбранную случайно по номеру клиента, оставляют без рассылки. Второй половине в четверг в 18:00 уходит пуш «Повторите прошлую корзину», который открывает корзину с прошлым заказом (такие переходы настраивают диплинками). Через 7 дней смотрят, какая доля каждой группы сделала заказ. Считают всю группу целиком: открывшие пуш отобрали себя сами, и сравнивать их не с кем. Почему знаменатель решает исход, показывает A/B-тест фичи.

В отчёте рассылки будет 210 заказов: столько человек открыли пуш и заказали в течение суток. Но в группе без пуша за ту же неделю заказали 240 человек из 3 000, а пуша они не видели. Пуш добавил 2 процентных пункта, около 60 дополнительных покупателей на 3 000, а заказов у них не меньше, чем покупателей. Калькулятор хи-квадрат из урока про A/B-тесты покажет p около 0,007, так что разница вряд ли случайна. Интервал для неё (разница ± 1,96 стандартной ошибки) - примерно от 0,6 до 3,4 пункта, то есть от 17 до 103 дополнительных покупателей. Точнее на такой выборке не скажешь.

С заказа сервису остаётся 1 000 ₸ (эту маржу посчитали в уроке про mobile-first), значит, рассылка по 3 000 человек принесла около 60 000 ₸. Отправка почти ничего не стоит: Firebase Cloud Messaging бесплатен. Платят за пуш аудиторией. В группе с рассылкой уведомления выключили 30 человек, без неё 9. Разница в 21 человека, или 0,7% группы, и есть цена одной рассылки. Если статусы заказа и акции идут одним каналом, эти люди перестанут получать и «курьер у двери».

В Firebase базовую группу эксперимента с уведомлениями можно оставить без сообщения, но делит он установки (об этом в уроке про A/B-тесты фич), поэтому рассылку из CRM надёжнее делить по номеру клиента.

Один тест говорит только об одной рассылке. Чтобы видеть вклад всех рекламных пушей вместе, часть покупателей, например 10%, оставляют без них на квартал и сравнивают их заказы с остальными. Планировщик на странице калькуляторов считает равные группы. Его число на вариант можно взять как размер группы без пушей: при делении 10 на 90 этого хватит с запасом.

Частота и актуальность

Маркетолог хочет слать пуш два раза в неделю. Тест выше проверил одну рассылку в неделю. Что даст вторая, он не говорит: она может добавить ещё столько же покупателей, а может сдвинуть те же заказы на пару дней раньше. Вторую рассылку проверяют третьей группой против той же группы без пушей и смотрят на две строки: дополнительные покупатели и выключившие уведомления. 0,7% за рассылку кажутся мелочью, но если темп сохранится, десять еженедельных рассылок выключат уведомления примерно у 7% аудитории, и каждая следующая акция дойдёт до меньшего числа людей.

Лимит частоты держат на стороне сервиса:

• Лимит считают на человека по всем рекламным рассылкам вместе. Если акции, брошенную корзину и подборки запускают разные люди, каждый уложится в свой лимит, а покупатель получит три пуша за вечер. Поэтому все рекламные пуши идут через одну очередь, которая знает, сколько человеку уже отправили за неделю.
• Сервисные уведомления (оплата прошла, курьер у двери) в лимит не входят, но и рекламу в них не добавляют.
• Перед отправкой очередь смотрит, жив ли повод. Пуш «Вы оставили товары в корзине» запланирован на 19:05, а в 19:00 человек оформил заказ: напоминать уже не о чем.

Повод проверяет ваша очередь, до передачи в Firebase: Firebase не знает, оформил ли человек заказ, и ответ с ID сообщения значит только, что он принял сообщение к доставке. Если телефон выключен, сообщение, которому не задали срок жизни, ждёт его до четырёх недель. Поэтому срок задают явно: android.ttl для Android, заголовок TTL в webpush.headers для веба, заголовок apns-expiration для iPhone. Напоминание о корзине, пришедшее через три дня, только раздражает. Статусам курьера дают общий ключ свёртки (collapse key): из нескольких ожидающих сообщений с одним ключом Firebase хранит только последнее, и после включения телефона человек увидит только актуальный статус.

Задание: план holdout для своего приложения

Возьмите приложение, с которым работаете, или сервис доставки из урока.

Выполнено 0 из 6

• Посчитайте долю разрешивших уведомления отдельно по iOS, Android 13 и новее и Android 12 и ниже.
• Запишите, в какой момент приложение просит разрешение и что обещает текст запроса.
• Добавьте к когорте по источникам статус уведомлений: сколько первых покупателей из каждой сети их включили и сколько из них заказали снова.
• Для одной рассылки опишите тест: кто в аудитории, по какому номеру делите, какая доля остаётся без пуша, метрика со знаменателем, защитная метрика, срок.
• Посчитайте в планировщике, сколько людей нужно в каждой группе.
• Запишите недельный лимит рекламных пушей на человека и кто за ним следит.

Теперь ситуация после теста. Маркетолог пишет владельцу: «Пуш принёс 210 заказов, это 210 000 ₸ маржи. Отправляем два раза в неделю на всю базу». Что вы ответите?

210 - это люди, которые открыли пуш и заказали в течение суток, и как минимум половина из них заказала бы и так: в группе без пуша за неделю заказали 8%. Дополнительных покупателей около 60, с интервалом от 17 до 103, то есть около 60 000 ₸ на рассылку по 3 000 человек, а не 210 000 ₸. Рассылка на всех 6 000 даст примерно вдвое больше: обе половины выбраны случайно из одной аудитории. Зато каждая рассылка выключает уведомления у 0,7% получателей. Вторую рассылку в неделю сначала запустите третьей группой: если она почти не добавляет покупателей, а уведомления выключают так же, она только сокращает аудиторию для следующих акций.

Видео: идеи push-сценариев

Идеи от AppsFlyer на английском. Каждую из них стоит сначала прогнать через holdout.