Push Notifications: What to Push, What Not to Push, and How Often

eugeneyan

Начать здесь Статьи Выступления Прототипирование Обо мне

Пуш-уведомления: что пушить, чего не пушить и как часто

[ teardown recsys machinelearning production ] · 18 мин чтения

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

Чем пуши отличаются от recsys или поиска?

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

Намерение пользователя становится менее ясным по мере перехода от поиска к рекомендациям и далее к пушам/почте

Ещё одно отличие в том, что форма уведомления может иметь большее значение, чем сам рекомендованный товар. Alibaba обнаружила, что персонализированные пуши, которые объясняют, почему товар важен именно для клиента, повышают open rate. Например, привязка пуша к действиям клиента — скажем, предложение дополняющих товаров на основе недавней покупки. DPG Media предлагает объяснять пользователям, почему они получают новые уведомления — например, что они ранее подписались на обновления, — или включать информацию о теме или местоположении. Такая прозрачность помогает пушу выглядеть менее случайным и может располагать к снисхождению, когда он промахивается по релевантности.

Ещё одна сложность в том, что нерелевантные или нежелательные пуши рискуют привести к тому, что пользователь отключит уведомления, удалит приложение или начнёт их игнорировать из-за низкой пользы. Это оборачивается безвозвратной потерей канала для передачи своевременной и полезной информации и ведёт к снижению использования приложения. К сожалению, как обнаружила Twitter, большинство рекомендательных движков смотрят близоруко, чрезмерно оптимизируя сиюминутный отклик пользователя в ущерб долгосрочной удовлетворённости.

Несколько других отличий между пуш-уведомлениями и обычными рекомендациями:

Своевременность критична, поскольку пуши, связанные со срочными новостями, акциями или выходом новых продуктов, через некоторое время могут утратить актуальность. Если они не своевременны, релевантность теряется быстро. Рекомендации же, напротив, обычно более «вечнозелёные». Жёсткие ограничения по месту часто означают, что в одном пуше есть место лишь для одного рекомендованного товара. Лимиты на сообщения ограничивают число пушей, которое каждый клиент может получить за день или неделю, чтобы не перегружать пользователей и не рисковать отписками. Пуши чаще привязаны к внешним событиям, таким как ограниченные по времени скидки или новости, тогда как обновления рекомендаций обычно основаны на активности на сайте. Пуши, как правило, делают упор на точность и своевременность, тогда как для рекомендаций ценны разнообразие, свежесть и другие цели.

Далее мы обсудим, что пушить в противовес тому, что не пушить. В целом «что пушить» — это про то, чтобы быть полезным, а «чего не пушить» — про то, чтобы не навредить. Первое более актуально для сценариев в e-commerce или образовании, где мы хотим генерировать проактивные предложения вроде рекомендаций к чтению или напоминаний об учёбе. Второе более актуально в таких сценариях, как соцсети или новости, где объём органических событий и так высок, и мы хотим отфильтровать пуши, которые скорее всего сработают плохо или будут раздражать пользователей.

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

Что пушить: быть полезным и вовлекающим

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

Интуитивно понятно, что рекомендовать в пуш-уведомлениях дополняющие товары (а не товары-заменители) выгодно. Дополняющие товары покупают в дополнение к предыдущему товару, тогда как заменители покупают вместо другого товара. Таким образом, дополняющие товары усиливают ценность друг друга, а заменители являются альтернативами. Например, аксессуары для телефона дополняют iPhone, а Google Pixel — это заменитель iPhone. Есть опасение, что рекомендация заменителей через пуши может раздражать клиентов своей избыточностью, ведь у них уже есть товар-заменитель.

Чтобы выявить сильно дополняющие товары, они сначала вычисляли оценку дополнения \(p_{ij}\) и оценку замены \(q_{ij}\) между всеми товарами \(i\) и \(j\). Оценка дополнения измеряет вероятность покупки \(j\) после покупки \(i\):

\(A_{ui}\) обозначает покупку пользователем \(u\) товара \(i\), а \(t(A_{ui})\) — момент времени этой покупки. По сути, \(j\) является дополнением к \(i\), если \(j\) покупается после покупки \(i\).

Оценка замены определяется аналогично, но на основе просмотра \(i\) и покупок \(j\):

\(B_{ui}\) обозначает просмотр пользователем \(u\) товара \(i\), а \(t(B_{ui})\) — момент времени события просмотра. С риском упрощения: \(j\) является заменителем \(i\), если \(j\) покупается после просмотра \(i\).

Затем, вычитая оценку замены из оценки дополнения, они получают оценку сильного дополнения \(s_{ij} = p_{ij} - q_{ij}\). Товары с высоким \(s_{ij}\) являются сильными дополнениями и потому используются как кандидаты для пушей.

Они также обучили модель смеси (mixture model) для представления разных когорт пользователей, более склонных либо к популярным, либо к дополняющим товарам. Модель выучивает скрытые предпочтения каждой когорты и рекомендует товары соответственно. (С современными контекстными рекомендательными системами мы, вероятно, обучили бы двухбашенную сеть или трансформер, который мог бы обучаться напрямую на исторических действиях и контексте клиентов.)

В целом рекомендация дополняющих товаров (CPR) повысила open rate на 44% относительно обычных персонализированных рекомендаций (PPR). Сочетание её с моделью смеси (с четырьмя когортами \(k\)) дало дополнительное улучшение на 11%.

Прирост open rate при различных вариантах воздействия

JOOL Health, приложение для психического здоровья и изменения поведения, обнаружило, что у опытных пользователей и обычных пользователей разные предпочтения по шаблонам пуш-уведомлений. В частности, опытные пользователи предпочитали уведомления, основанные на их исторических данных мониторинга, тогда как обычные пользователи предпочитали более общие уведомления.

Их цель состояла в том, чтобы побудить пользователей открывать приложение и самостоятельно отмечать различные факторы благополучия — такие как сон, креативность, энергия и сила воли. Они протестировали два типа уведомлений:

Советы: общие подсказки вроде «Более длинные и медленные вдохи могут повысить силу воли». Инсайты: персонализированные сводки на основе исторических данных, например «Завтра ваш прогноз по силе воли высок — это возможность сформировать новую полезную привычку».

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

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

Duolingo также рассказала о своём кастомном многоруком бандите (MAB), который исследует и отбирает высокоэффективные шаблоны пуш-уведомлений. В их схеме каждая «рука» — это вариант шаблона, а наградой служит вовлечённость пользователя.

Целью было решить две задачи. Во-первых, повторение одного и того же шаблона ведёт к привыканию и убывающей отдаче по вовлечённости. Поэтому более свежие шаблоны, которых пользователь давно не видел, оказывают большее воздействие. Во-вторых, не все шаблоны допустимы во всех ситуациях. Некоторые доступны, только если пользователь держит серию (streak), а другие — если пользователь указал предпочтение, связанное с путешествиями.

Различные шаблоны пуш-уведомлений Duolingo и критерии их допустимости

Чтобы учесть эту динамику, Duolingo вдохновилась «восстанавливающимися бандитами» (recovering bandits) и «спящими бандитами» (sleeping bandits). В первом случае ожидаемая награда руки зависит от числа раундов с момента её последнего выбора — недавно выбранные руки получают меньшую награду. Во втором случае некоторые руки, например недопустимые шаблоны, неактивны в течение некоторого числа раундов.

Чтобы реализовать восстанавливающиеся руки, они вводили штраф за недавность для руки, если она ранее была выбрана для данного пользователя. Цель — дать более свежим шаблонам прибавку за новизну. Штраф снижается со временем, имитируя угасание памяти, и изменённая оценка \(s_{a,t}^*\) руки \(a\) выглядит так:

\(d_{a, t}\) — число дней с момента выбора руки \(a\) для пользователя. \(\gamma\) и \(h\) — гиперпараметры, обозначающие базовый штраф за недавность и период полураспада затухания.

Чтобы реализовать спящие руки, они измеряли ценность каждой руки, контролируя допустимость. В частности, они использовали исторические данные для оценки награды/полезности, когда рука допустима и используется (\(\mu_{a}^{+}\)) и когда рука допустима, но не используется (\(\mu_{a}^{-}\)). Таким образом, разность контролирует эффекты допустимости — обе величины оцениваются по обратной связи, удовлетворяющей одним и тем же критериям допустимости, что изолирует подлинное влияние шаблона.

В онлайн-экспериментах этот подход увеличил DAU на 0,5%, а число завершённых уроков — на 0,4%. Примечательно, что удержание новых пользователей также выросло на 2%, что говорит о том, что оптимизированные уведомления и разнообразие шаблонов помогли удерживать новых учеников.

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

Чтобы это реализовать, они разработали функцию оценки пересечения по локациям, которая смешивает два соотношения:

Соотношение локаций, извлечённых из статьи, к локациям, о которых пользователь читал ранее. Это отражает предпочтения по локациям на основе истории чтения. Соотношение локаций, извлечённых из статьи, к локациям, которые пользователь физически посещал во время использования приложения. Это отражает релевантность на основе местоположения пользователя.

Эти оценки смешиваются в пропорции 7:3, чтобы придать больший вес предпочтениям по локациям. Затем результат комбинируется с оценкой сходства контента, основанной на косинусной близости между статьёй и прошлым чтением пользователя. Эмбеддинги контента строились на основе модели word2vec.

Чего не пушить: быть безвредным и ненавязчивым

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

LinkedIn решал эту задачу, предсказывая, на какие пуши с меньшей вероятностью отреагируют. Сначала они разделили уведомления на две категории:

Всегда уведомлять: высокоприоритетные события, такие как сообщения и запросы на соединение. Подлежащие фильтрации: активность в сети пользователя — например, репосты, упоминания и упоминания соединений в новостях.

Поделился-вашей-сетью, Опубликовано-вашей-сетью, Обсуждается, Упомянут-в-новостях

События, подлежащие фильтрации, обычно имеют больший объём, но более слабый сигнал, и потому их нужно фильтровать. Такие уведомления также снабжаются понятными причинами вроде «Джилл сделала репост впервые», чтобы помочь пользователям понять, почему их уведомили.

Их система пуш-уведомлений повторяет устройство обычной recsys: сначала они отбирают кандидатов-получателей для каждого события (retrieval), а затем фильтруют события, для которых прогнозируется низкий отклик (ранжирование и фильтрация).

Для retrieval они сначала отбирают кандидатов-получателей для каждого события по аффинности рёбер (edge affinity) и силе связи (connection strength). Аффинность рёбер находит пользователей, которые недавно взаимодействовали с обновлениями актора. Это эффективно для пользователей, часто пользующихся лентой LinkedIn и взаимодействующих с ней. Сила связи — это вероятность взаимодействия двух пользователей в LinkedIn вне ленты; это позволило LinkedIn расширить набор кандидатов до 10-кратного объёма по сравнению с тем, что давала аффинность рёбер. От этого выигрывают недавно зарегистрировавшиеся или менее вовлечённые пользователи.

Затем, чтобы убедиться, что на каждый пуш скорее всего отреагируют, они оценивают кандидатов с помощью модели предсказания отклика. Чтобы начально набрать обучающие данные для этой модели, они стартовали с эвристической модели на основе признаков аффинности, где пуши отправлялись только при превышении этими признаками порога. Собрав достаточно данных обратной связи, они перешли к логистической регрессии с L2-регуляризацией.

Мне показалось интересным, что помимо стандартной офлайн-метрики ROC-AUC они также измеряли отношение observed-to-expected (наблюдаемое к ожидаемому). Оно вычисляется как число положительных тестовых примеров (наблюдаемое), делённое на сумму предсказанных вероятностей по всем тестовым примерам (ожидаемое). Идеальным было отношение, равное 1. Это гарантировало, что предсказания модели откалиброваны и она не отправляет в продакшене слишком много или слишком мало пушей.

Pinterest применил несколько иной подход к фильтрации пуш-уведомлений: вместо того чтобы предсказывать, отреагирует ли пользователь на уведомление, они сосредоточились на том, не приведёт ли уведомление к отписке пользователя.

Чтобы собрать несмещённые обучающие данные для модели предсказания отписки \(p(s_{unsub}\vert u, k_u)\), Pinterest случайным образом назначал каждому пользователю \(u\) максимальное число уведомлений, которое тот мог получить за неделю (т. е. объём уведомлений \(k_u\)), и собирал их реакции. Пользователи, которые отписывались, получали положительную метку, а те, кто оставался подписанным, — отрицательную.

Ключевая идея состояла в том, чтобы обучаться на назначенном объёме уведомлений \(k_u\), а не на фактическом числе отправленных уведомлений. Это позволило избежать систематической ошибки выжившего, ведь если пользователь отписался, он не мог получить больше уведомлений. В результате могло показаться, что пользователи с меньшим числом отправленных уведомлений более склонны отписываться, хотя реальным фактором был назначенный объём.

Они также обучили модель долгосрочного эффекта отписки \(p(aL \vert u,s_{unsub})\), чтобы предсказывать активность пользователя после отписки. В частности, модель предсказывает, сколько активных дней будет у пользователя на пятой неделе, если он отпишется. Они нашли, что задержка в четыре недели — хороший баланс: достаточно времени, чтобы активность пользователя стабилизировалась, но не настолько долго, чтобы замедлить сбор данных и петлю обратной связи.

Сколько пушить: снижение отписок

Уникальная для пушей сложность — определить правильный объём уведомлений для каждого пользователя. Хотя отправка большего числа пушей повышает вовлечённость, она также рискует раздражить пользователей или быть воспринятой как спам. Чего мы хотим избежать — это отписок пользователей или удаления приложения.

Продолжая тему предыдущего раздела, Pinterest вычислял недельный объём уведомлений для каждого пользователя и хранил его в онлайновом key-value хранилище с ключом по ID пользователя. Функция награды для объёма уведомлений аппроксимирует долгосрочный эффект объёма уведомлений \(k_u\) на активность \(a\) пользователя \(u\):

\(p(s \vert u, k_u)\) — вероятность того, что пользователь совершит действие \(s\) за неделю при объёме уведомлений \(k_u\). Кроме того, \(p(a \vert u, k_u, s)\) — оценка активности пользователя \(a\) при объёме уведомлений \(k_u\) и действии \(s\). Чтобы упростить модель, они рассматривали только два возможных действия пользователя: отписаться \(s_{unsub}\) или остаться подписанным \(s_{sub}\). С этими двумя действиями функцию награды можно упростить до следующего вида:

Первая половина функции награды оценивает долгосрочную активность пользователей, которые отписываются, через \(p(s_{unsub} \vert u,k_u)×p(aL \vert u,s_{unsub})\). Вторая половина оценивает активность пользователей, остающихся подписанными, через \((1−p(s_{unsub} \vert u,k_u))×p(a \vert u,k_u,s_{sub})\). Эта функция награды моделируется тремя компонентами: (i) вероятность отписки, (ii) долгосрочная активность отписавшихся пользователей и (iii) предсказанная активность.

Первые два компонента мы обсудили в предыдущем разделе. Чтобы предсказать активность \(p(a \vert u,k_u,s_{sub})\), они обучили нелинейную модель (XGBoost), предсказывающую ежедневную активность каждого пользователя при заданных пользователе и недельном объёме уведомлений.

С функцией награды и тремя описанными выше моделями они могут оценивать инкрементальную ценность каждого дополнительного уведомления. Цель — отфильтровать пуши с низкой инкрементальной ценностью, оставаясь в рамках ограниченного числа уведомлений. Сначала они вычисляют оптимальный бюджет \(i_{max}\), при котором инкрементальная ценность от уведомлений максимальна. Затем они увеличивают бюджет, пока инкрементальная ценность дополнительного пуша не упадёт ниже порога. Этот алгоритм был реализован и масштабирован с помощью map-reduce.

Как Pinterest распределяет бюджет уведомлений для каждого пользователя

В результате им удалось снизить объём уведомлений на 6–24% при росте CTR на 11–31% и метрик вовлечённости на сайте на 1–3%.

Снижение объёма уведомлений при росте DAU

Интересно, что они заметили, как модель перераспределила объём от более активных пользователей (Рисунок 5 ниже) к менее активным (Рисунок 6 ниже). Основные пользователи (core users — те, кто сохранял пин более чем в 4 дня за последние 28 дней) получали меньше писем без существенного снижения DAU или WAU. Тем временем маргинальные пользователи (активные 1–3 дня за прошлые 28 дней) получали больше писем, что также повысило их клики по письмам, DAU и WAU.

Объём писем снизился для основных пользователей, но вырос для маргинальных

Twitter также рассказала о своём когортном и персонализированном контроле объёма (он же push caps — лимиты на пуши). Для когортной модели они использовали скрытую марковскую модель (HMM), чтобы сегментировать пользователей по последовательностям действий — таким как отсутствие входа, вход без открытия пуша и открытие пуша (что неявно включает вход). Использование когорт упростило выучивание оптимальных лимитов на пуши, поскольку данных для обучения было больше.

Гипотетическая трёхсостоянийная HMM

Чтобы подобрать число состояний, они обучили несколько HMM (с разным числом состояний) и обнаружили, что шесть состояний давали стабильную систему с хорошим качеством предсказания входов и открытий. Затем, чтобы определить оптимальный лимит на пуши для каждого состояния, они провели поиск по сетке через онлайн A/B-тестирование, выбирая лимиты, которые оптимизировали DAU и reachability. Reachability определяется как число людей, которые соглашаются получать уведомления от Twitter (т. е. противоположность отписке).

Будучи эффективной, HMM-модель была ограничена своей простотой. Добавлять более сложные признаки было непросто (чем больше признаков, тем больше измерений в HMM). Поэтому они дополнили её нейросетью, которая предсказывала долгосрочную полезность для клиента при заданном лимите на пуши. Как и Pinterest, они собирали метки после отложенного периода (два месяца), исходя из того, что хотя клиент поначалу может реагировать на высокие лимиты, часто открывая уведомления и заходя в приложение, со временем он может потерять чувствительность и сократить заходы на более длинном горизонте.

Чтобы сбалансировать DAU (аппроксимируемый через входы) и reachability, они взвешивали оба показателя через параметр \(\alpha\). При заданных признаках \(x\) и лимите на пуши \(c\) функция награды для полезности определяется так:

При \(\alpha = 0\) выбирается лимит на пуши с наивысшим предсказанием входов. Но по мере роста \(\alpha\) функция награды выбирает лимиты, сохраняющие reachability.

Для менее активных пользователей когортная модель работала лучше персонализированных лимитов на пуши, поскольку у когорт больше данных, чем у отдельного пользователя. Когортные лимиты было также проще поддерживать: они просто обновляли лимит клиента всякий раз, когда HMM предсказывала, что клиент перешёл в новое состояние. Тем не менее для более активных пользователей персонализированные лимиты работали лучше.

В результате они увеличили DAU на 0,62% на iOS и на 0,39% на Android при незначительной потере reachability.

• • •

На этом наше погружение в пуш-уведомления завершается! По сравнению с другими темами в области discovery (например, recsys, ранжирование, поиск) ресурсов по пуш-уведомлениям меньше, и общих паттернов в них тоже меньше. Тем не менее некоторые из этих идей применимы и к тому, как мы проектируем recsys, — например, рекомендация дополняющих товаров, повышение объяснимости и ограничение показов, а также калибровка моделей через отношение observed-to-expected.

Какие ещё ресурсы по пуш-уведомлениям оказались для вас полезными? Пишите!

Источники

Zhao, Huasha, et al. «Recommending complementary products in e-commerce push notifications with a mixture model approach.» Proceedings of the 40th International ACM SIGIR Conference on Research and Development in Information Retrieval. 2017. Loni, Babak, et al. «Personalized push notifications for news recommendation.» 2nd Workshop on Online Recommender Systems and User Modeling. PMLR, 2019. O’Brien, Conor, et al. «Should i send this notification? Optimizing push notifications decision making by modeling the future.» arXiv preprint arXiv:2202.08812 (2022). Bidargaddi, Niranjan, et al. «Predicting which type of push notification content motivates users to engage in a self-monitoring app.» Preventive medicine reports 11 (2018): 267-273. Yancey, Kevin P., and Burr Settles. «A sleeping, recovering bandit algorithm for optimizing recurring notifications.» Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. 2020. Gao, Yan, et al. «Near real-time optimization of activity-based notifications.» Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. 2018. Zhao, Bo, et al. «Notification volume control and optimization system at Pinterest.» Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. 2018. Biyani, Prakhar, and Ragain, Stephen «A hybrid approach to personalize notification volume Twitter Engineering Blog. 2022. Yue, Yuguang, et al. «Learning to Rank For Push Notifications Using Pairwise Expected Regret.» arXiv preprint arXiv:2201.07681 (2022). Okoshi, Tadashi, Kota Tsubouchi, and Hideyuki Tokuda. «Real-world product deployment of adaptive push notification scheduling on smartphones.» Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. 2019. Yuan, Yiping, et al. «A state transition model for mobile notifications via survival analysis.» Proceedings of the Twelfth ACM International Conference on Web Search and Data Mining. 2019. Yuan, Yiping, et al. «Offline reinforcement learning for mobile notifications.» Proceedings of the 31st ACM International Conference on Information & Knowledge Management. 2022.

Если этот материал оказался полезным, пожалуйста, ссылайтесь на него так:

Yan, Ziyou. (Dec 2023). Push Notifications: What to Push, What Not to Push, and How Often. eugeneyan.com. https://eugeneyan.com/writing/push/.

или

@article{yan2023push, title = {Push Notifications: What to Push, What Not to Push, and How Often}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Dec}, url = {https://eugeneyan.com/writing/push/} }

Присоединяйтесь к 11 800+ читателей, получающих обновления о машинном обучении, RecSys, LLM и инженерии.