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

eugeneyan

eugeneyan

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

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

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

[ teardown recsys machinelearning production ] · 18 min read

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

Push notifications can be considered a form of recommender system, where instead of showing recommendations directly on a website or app, we proactively send suggestions via email or mobile alerts. While this may seem like a small change, it leads to meaningful differences in how people engage with pushes versus regular recommendations.

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

How does push differ from recsys or search?

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

One difference is that with pushes, we don’t know the customer’s intent. Compare this to search, where the intent is made obvious via the search query. Or recommendations on the website or app, where we can guess the intent based on the context, such as the product page a user is browsing or their in-session activity. But with pushes, we have to guess what the customer might be interested in given triggers such as events, promotional offers, or location. Thus, as we go from search to recommendations to pushes, it becomes harder to understand the customer’s intent.

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

The user's intent is less clear as we go from search to recommendations to push/email

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

Another difference is that the form of the notification may matter more than the product recommended. Alibaba found that personalized pushes which convey why an item matters—to the customer—increased open rates. For example, tying the push to the customer’s activities, such as suggesting complementary products based on a recent purchase. DPG Media suggests explaining why users are receiving new notifications, such as having previously signed up for updates or including information about the topic or location. The transparency helps the push feel less random and may encourage forgiveness when it misses the mark on relevance.

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

Another challenge is that irrelevant or unwelcomed pushes risk having the user disable notifications, uninstall apps, or start ignoring them due to low usefulness. This results in a permanent loss of a channel for sharing timely, useful information, leading to reduced app usage. Unfortunately, as Twitter found, most recommendation engines take a myopic view, over-optimizing on immediate user responses at the cost of long-term satisfaction.

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

Some other differences between push notifications and conventional recommendations:

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

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

Next, we’ll discuss what to push versus what not to push. Generally, “what to push” is about being helpful while “what not to push” tackles being harmless. The former is more relevant for use cases in e-commerce or education where we want to generate proactive suggestions such as reading recommendations or study reminders. The latter is more relevant in use cases such as social media or news where the volume of organic events is already high and we want to filter pushes that will likely underperform or annoy users.

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

Also related is volume control: How many pushes until diminishing returns is reached, or notifications are disabled? While engaged users may appreciate multiple well-targeted pushes a day, less active users may prefer a few thoughtful pushes a week so that their normal flow isn’t disrupted. The ideal frequency varies from individual to individual.

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

What to push: Being helpful and engaging

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

Alibaba found that pushes for products that complement a customer’s past purchases increased open rates. They hypothesized that, by recommending complementary products, they built an explicit connection to the customer’s purchase history, as opposed to personalized recommendations or top-sellers.

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

Intuitively, it makes sense that recommending complements (instead of substitutes) for push notifications does well. Complements are products that are bought in addition to the previous product while substitutes are products that are bought instead of another product. Thus, complements enhance each other’s value while substitutes are alternatives. For example, phone accessories complement an iPhone while a Google Pixel is a substitute for an iPhone. One concern is that recommending substitutes via pushes may annoy customers by being redundant since they already own a substitute product.

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

To identify strongly complementary products, they first computed a complement score \(p_{ij}\) and a substitute score \(q_{ij}\) between all products \(i\) and \(j\). The complement score measures the probability of purchasing \(j\) after purchasing \(i\):

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

\(A_{ui}\) represents the user \(u\) purchasing product \(i\) while \(t(A_{ui})\) is the timestamp of the purchase. Essentially, \(j\) is a complement of \(i\) if \(j\) is purchased after \(i\) is purchased.

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

The substitute score is defined similarly but based on view of \(i\) and purchases of \(j\):

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

\(B_{ui}\) represents the user \(u\) viewing product \(i\) while \(t(B_{ui})\) is the timestamp of the view event. At the risk of oversimplification, \(j\) is a substitute of \(i\) if \(j\) is purchased after \(i\) is viewed.

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

Then, by subtracting the substitute score from the complement score, they can compute the strongly complementary score \(s_{ij} = p_{ij} - q_{ij}\). Products with high \(s_{ij}\) are strong complements and thus used as candidates for pushes.

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

They also trained a mixture model to represent different cohorts of users that are more inclined towards either popular products or complementary products. The model learns each cohort’s latent preferences and recommends products accordingly. (With modern contextual recommenders, we’d likely train a two-tower network or transformer that can learn directly from customers’ historical behavior and context.)

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

Overall, complementary recommendation (CPR) increased open rate by 44% relative to generic personalized recommendations (PPR). Combining it with a mixture model (with four cohorts \(k\)) led to a further 11% improvement.

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

Increase in open rates across various treatments

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

JOOL Health, a mental health and behavioral change app, found that power users and regular users had different preferences for push notification templates. Specifically, power users preferred notifications that were based on their historical monitoring data while regular users preferred more generic notifications.

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

Their goal was to encourage users to open the app and self-report on various well-being factors such as sleep, creativity, energy, and willpower. They tested two notification types:

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

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

Overall, relative to personalized insights, generic suggestions led to more app interactions and monitoring. However, for highly active users, insights increased engagement while the generic suggestions reduced interaction and monitoring.

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

They hypothesized that because new users have limited recorded data, personalized insights lacked the depth to be relevant compared to generic suggestions. Thus, simple tips worked better initially. But as they use the app more regularly, the depth of personalized insights increases and thus becomes more meaningful than broad suggestions.

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

Duolingo also shared about their custom multi-armed bandit (MAB) that explores and selects high-performing push notification templates. In their setup, each arm is a template variant and the reward is user engagement.

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

The goal was to address two challenges. First, repeating the same template leads to familiarity and diminishing returns on engagement. Thus, fresher templates that a user hasn’t seen recently have a higher impact. Second, not all templates are eligible in all situations. Some are only eligible if the user is on a streak, while others are eligible if the user has indicated a travel preference.

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

Various Duolingo push notification templates and their eligibility criteria

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

To incorporate these dynamics, Duolingo drew inspiration from “recovering bandits” and “sleeping bandits”. In the former, an arm’s expected reward is based on the number of rounds since the arm was last chosen—more recently chosen arms received less reward. For the latter, certain arms, such as ineligible templates, are inactive for some rounds.

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

To implement recovering arms, they had a recency penalty for an arm if it was previously selected for a given user. The goal is to give fresher templates a novelty boost. The penalty decreases over time to mimic fading memory, and the modified score \(s_{a,t}^*\) of arm \(a\) is:

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

\(d_{a, t}\) is the number of days since arm \(a\) was selected for the user. \(\gamma\) and \(h\) are hyperparameters representing the base recency penalty and the decay half-life.

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

To implement sleeping arms, they measured each arm’s value while controlling for eligibility. Specifically, they used historical data to estimate the reward/utility when the arm is eligible and used (\(\mu_{a}^{+}\)) and when the arm is eligible and not used (\(\mu_{a}^{-}\)). Thus, taking the difference controls for eligibility effects, where both values are estimated from feedback that meets the same eligibility criteria, isolating the template’s true impact.

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

In online experiments, this approach increased DAU by 0.5% and lessons completed by 0.4%. Notably, new user retention also increased by 2%, suggesting that the optimized notifications and template variety helped to retain new learners.

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

Finally, DPG media shared their approach for news-related push notifications. One of their objectives was to provide hyper-local personalization by pushing notifications for news that was happening near the user.

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

To enable this, they developed a location overlap scoring function that blends two ratios:

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

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

These scores are blended at 7:3 to weigh location preference higher. Then, it’s combined with a content similarity score that is based on cosine similarity between the article and the user’s past reading. The content embeddings were based on a word2vec model.

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

What not to push: Being harmless and unobtrusive

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

In contrast to the section above that focused on selecting the best items or templates for pushes, this section focuses on filtering pushes that are likely to underperform.

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

LinkedIn addressed this by predicting which pushes were less likely to be engaged on. First, they split notifications into two categories:

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

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

Shared-by-your-network, Posted-by-your-network, Talking-about, Mentioned-in-the-news

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

Filter-eligible events tend to have higher volume but lower signal and thus need to be filtered. These notifications are also decorated with interpretable reasons, such as “Jill shared for the first time”, to help users understand why they were notified.

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

Their push notification system mirrors the design of a conventional recsys, where they first select candidate recipients for each event (retrieval) before filtering events that are predicted to have low response (ranking and filtering).

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

For retrieval, they first select candidate recipients for each event via edge affinity and connection strength. Edge affinity retrieves users who have recently interacted with the actor’s updates. This is effective for users who frequently use the LinkedIn feed and engage with it. Connection strength is the probability of two users interacting on LinkedIn outside of the feed—this allowed LinkedIn to expand the candidate set to 10x the pool of users offered via edge affinity. This benefits newly onboarded or less engaged users.

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

Then, to ensure that each push is likely to be engaged on, they score candidates via a response prediction model. To bootstrap training data for this model, they started with a heuristic model based on affinity features where pushes were sent only when affinity features exceeded a threshold. Once they had collected enough feedback data, they transitioned to logistic regression with L2 regularization.

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

I found it interesting that, beyond the standard offline evaluation metric of ROC-AUC, they also measured the observed-to-expected ratio. This is computed as the number of positive test samples (observed) divided by the sum of predicted probabilities for all test samples (expected). A ratio of 1 was ideal. This ensured that the model’s predictions were calibrated and it wasn’t over or under-sending pushes in production.

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

Pinterest adopted a slightly different approach to filtering push notifications: Instead of predicting whether a user would engage with a notification, they focused on whether a notification would cause the user to unsubscribe.

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

To collect unbiased training data for the unsubscribe prediction model \(p(s_{unsub}\vert u, k_u)\), Pinterest randomly assigned each user \(u\) a maximum number of notifications they could receive a week (i.e., notification volume \(k_u\)) and collected their responses. Users that unsubscribed would be assigned a positive label while users that continue to subscribe would receive a negative label.

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

The key insight was to learn on the assigned notification volume \(k_u\) instead of the actual number of notifications sent. This avoided survivorship bias, because if a user had unsubscribed, they could not have received any more notifications. As a result, users with fewer sent notifications seemed more likely to unsubscribe even though the assigned volume was the real driver.

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

They also trained an unsubscribe long-term effect model \(p(aL \vert u,s_{unsub})\) to predict user activity after unsubscribing. Specifically, the model predicts that, if a user unsubscribes, how many active days the user would have in the fifth week. They found a four-week delay to be a good balance—enough time for user activity to stabilize yet not too long to slow down data collection and the feedback loop.

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

How many to push: Reducing unsubscribes

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

A challenge unique to pushes is determining the right notification volume for each user. While sending more pushes drives engagement, they also risk annoying users or being perceived as spam. What we want to prevent is users unsubscribing or uninstalling the app.

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

Continuing from the section above, Pinterest computed the weekly notification volume for each user and stored it in an online key-value store keyed on user ID. The reward function for notification volume approximates the long-term effect of notification volume \(k_u\) on the activeness \(a\) of user \(u\):

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

\(p(s \vert u, k_u)\) is the probability of user performing action \(s\) in the week, given notification volume \(k_u\). In addition, \(p(a \vert u, k_u, s)\) is the estimate of user activeness \(a\) given notification volume \(k_u\) and action \(s\). To simplify the model, they considered only two possible user actions: unsubscribe \(s_{unsub}\) or continue to subscribe \(s_{sub}\). With these two actions, the reward function can be simplified into the following:

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

The first half of the reward function estimates the long-term activeness of users who unsubscribe via \(p(s_{unsub} \vert u,k_u)×p(aL \vert u,s_{unsub})\). The second half estimates the activeness of users who continue to subscribe via \((1−p(s_{unsub} \vert u,k_u))×p(a \vert u,k_u,s_{sub})\). This reward function is modeled by three components: (i) probability of unsubscribing, (ii) long-term activity of unsubscribed users, and (iii) predicted activity.

Первая половина функции награды оценивает долгосрочную активность пользователей, которые отписываются, через \(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) предсказанная активность.

We’ve discussed the first two components in the previous section. To predict activity \(p(a \vert u,k_u,s_{sub})\), they trained a non-linear model (XGBoost) to predict the daily activity for each user given the user and weekly notification volume.

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

With the reward function and the three models above, they can then score the incremental value of each additional notification. The goal is to filter pushes with low incremental value while staying within a limited number of notifications. They first compute the optimal budget \(i_{max}\) where the incremental value from notifications is maximized. Then, they increase the budget until the incremental value of an additional push falls below a threshold. This algorithm was implemented and scaled via map-reduce.

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

How Pinterest allocates notification budget for each user

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

As a result, they were able to reduce notification volume by 6-24% while increasing CTR by 11-31% and site engagement metrics by 1-3%.

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

Reduced volume from notifications but with increased DAU

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

Interestingly, they observed that the model shifted volume from more active users (Figure 5 below) to less active users (Figure 6 below). For core users (who had saved a pin on more than 4 days in the last 28 days), they received fewer emails without a significant decrease in DAU or WAU. Meanwhile, marginal users (who were active 1-3 days in the past 28 days) received more emails which also increased their email clicks, DAU, and WAU.

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

Email volume decreased for core users but increased for marginal users

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

Twitter also shared about their cohort-level and personalized volume control (aka push caps). For the cohort model, they used a hidden Markov model (HMM) to segment users based on sequences of actions such as no login, login without opening the push, and open push (which implicitly includes logins). Using cohorts made it easier to learn optimal push caps since there was more data to learn from.

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

Hypothetical three-state HMM

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

To tune the number of states, they trained multiple HMMs (with different numbers of states) and found that having six states led to a stable system that had good predictive performance on logins and opens. Then, to determine the optimal push cap for each state, they did a grid search via online A/B testing, selecting push caps that optimized for DAU and reachability. Reachability is defined as the number of people who choose to receive notifications from Twitter (i.e., the opposite of unsubscribe).

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

While effective, the HMM-based model was limited by its simplicity. It was challenging to add more complex features (as more features led to more dimensions in the HMM). Thus, they augmented it with a neural network that predicted the long-term utility a customer receives based on a given push cap. Similar to Pinterest, they also collected labels after a delayed period (two months), reasoning that while a customer may initially respond to high push caps by opening notifications and logging on often, they may eventually become desensitized and reduce log-ins over a longer period of time.

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

To balance between DAU (proxied via logins) and reachability, they weighted both via parameter \(\alpha\). Given features \(x\) and push cap \(c\), the reward function for utility is defined as:

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

When \(\alpha = 0\), the push cap with the highest login prediction is selected. But as \(\alpha\) increases, the reward function selects push caps that maintain reachability.

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

For less active users, the cohort model performed better than personalized push caps due to cohorts having more data than an individual user. The cohort-based push caps were also easier to maintain: They simply updated a customer’s push cap whenever the HMM predicted that the customer had transitioned to a new state. Nonetheless, for more active users, the personalized push caps performed better.

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

As a result, they increased DAU by 0.62% on iOS and 0.39% on Android while having insignificant reachability loss.

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

• • •

• • •

That’s all for this dive into push notifications! Compared to other topics in discovery (e.g., recsys, ranking, search), resources for push notifications are sparser and have fewer common patterns. Nonetheless, some of these ideas are also applicable to how we design recsys, such as recommending complementary products, improving explainability, and limiting impressions, as well as calibrating models via the observed-to-expected ratio.

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

What other resources on push notifications have you found useful? Please reach out!

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

References

Источники

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.

If you found this useful, please cite this write-up as:

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

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

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

or

или

@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/} }

@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/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

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