Без пуш-уведомлений сегодня, наверное, не может обойтись ни одно мобильное приложение. На рынке уже есть немало готовых решений этой важнейшей задачи. Но, как это обычно и бывает, если хочешь сделать что-то хорошо, приходится делать это самому. В этой статье мы попросили разработчика UBANK Дениса Боровикова рассказать о своем опыте создания системы мобильных пуш-уведомлений для UBANK и поделиться советами для тех, кто захочет решить ту же задачу.
Среди существующих облачных систем пуш-рассылок можно отметить такие сервисы, как Infobip, Jeapie, Pushwoosh, Urban Airship. У них много общего: все они не кроссплатформенны, позволяют отправлять пуши с учетом временной зоны, делать рассылки по расписанию, а также дают статистику.
Звучит неплохо, но когда вникаешь в детали, понимаешь: это как готовые обеды. Купил замороженный полуфабрикат, сунул в микроволновку — получил на выходе съедобное блюдо. Живот набил, но без удовольствия.
Carl Lender
Для UBANK главный минус всех этих облачных решений в том, что они умеют пушить только всю клиентскую базу разом. А мы хотели иметь возможность разбивать аудиторию на группы и высылать каждой из них разные сообщения.
После небольшого исследования я оставил мысль о готовых решениях. Теоретически, что-то из них можно использовать как дополнение. Например, когда нам будет нужно поддерживать больше платформ (добавить Windows Phone и Web), станем отправлять пуши через облако, а не напрямую в APNS и GCM. Но пока все это нам не очень интересно.
Разработанная мной система рассылки UBANK — это отдельный модуль платежного приложения, написанный на Scala. На его разработку у меня ушло примерно два месяца. Можно было сделать и быстрее, но у меня было много параллельных задач.
У системы рассылки пушей своя база данных MongоDВ. Там хранится история каждой рассылки. В общей сложности это десятки миллионов записей — засорять ими основную базу приложения нам совсем не хотелось.
Работа модуля не затрагивает основную систему. Поэтому мы можем тестировать изменения (к примеру, выключать или перезапускать рассылку). Основное приложение при этом не будет затронуто.
Логика работы модуля такова: периодически с заданным интервалом запускается запрос, из базы основного приложения выбираются пользователи, которым надо отправить пуш (в соответствии с придуманными нами правилами).
Как мы тут уже рассказывали в предыдущей статье, наши пуши, причем разные по содержанию, приходят трем группам клиентов. Первая группа — это те, кто прошел регистрацию, но так и не воспользовался сервисом. Вторая — юзеры, которые когда-либо совершили один платеж, а потом перестали пользоваться UBANK. Третья — люди, которые пользовались приложением, но последние три месяца его не открывали.
Рано или поздно некоторые из них попали бы в третью группу. Но мы осознали, что в некоторых случаях напоминание через три месяца для них слишком запоздает. И не грех напомнить о себе чуть пораньше.
В общем, разрабатывая критерии выборки получателей для каждой рассылки, нужно отмерить семь раз, прежде чем резать. Чем ювелирнее вы будете обращаться аудиторией, тем выше будет полезный выхлоп.
janwillemsen
Но определить, кому в принципе нужно отправить пуш, это одно. Понять, как и когда именно это сделать, — другое.
Правила, кому и как мы отправляем пуши, формировались постепенно. Основные из них: частота отправки (раз в неделю), максимальное количество отправок (не больше пяти штук одному человеку). Еще мы не отправляем пуши ночью.
Мы проанализировали, в каких часовых поясах живут наши пользователи, и оказалось, что подавляющее большинство обитает в европейской части России, поэтому выбрали такие часы для рассылки, когда практически у всех день. Когда пользователей в других регионах станет больше, благодаря фильтрации с легкостью сможем сделать гео-привязку по часовым поясам.
Чтобы не спамить людей, нужно разработать систему постоянной проверки пользователя, попадает ли он под наши критерии или нет. Например, если мы послали пуш давно не платившему пользователю, и он заплатил, то наша цель выполнена — не надо его раздражать и снова рассылать ему уведомления.
Следует при этом не забыть про ручное управление и предусмотреть возможность отправлять пуши не только по расписанию, но и когда захочется. Ручная отправка пригодится для пробных рассылок, когда вы захотите сначала протестировать работу системы на небольшой выборке пользователей.
Нам важно отслеживать статистику ключевых показателей по каждой рассылке. Поэтому мы в UBANK сохраняем историю каждой из них, чтобы иметь возможность оценивать эффективность пушей.
Привязал ли человек карту, совершил ли он покупку — вся эта информация автоматически проверяется раз в час и отправляется в APNS или GCM, в зависимости от того, на Андроиде или iOS сидит клиент.
Для ускорения процесса мы используем batch-отправку. При отправке в GCM не забудьте, кстати, установить параметр отправки delay_while_idle в true — он говорит о том, что не нужно доставлять пуш пользоватлю, если устройство не активно.
У нашей системы рассылки пушей есть веб-интерфейс. Динамика по всем нашим ключевым показателям в веб-интерфейсе отображается в виде графиков и диаграмм.
Веб-интерфейс и графики используются для общей качественной оценки. Но у нас есть еще и выгрузка в Эксель. Все вычисления по каждой группе маркетологи, естественно, делают там.
Анализируйте результаты каждой пробной рассылки и вносите коррективы. Чем больше у вас информации о пользователях, тем эффективнее будет ваша рассылка.
Мы отслеживаем поведение наших юзеров через сервера — и благодаря этому про каждого клиента знаем, сам ли он скачал приложение, или оно было предустановлено, знаем версию его приложения, версию операционки смартфона, модель устройства и часовой пояс пользователя. Всю интересную для маркетинга статистику мы вытаскиваем и сохраняем на сервере.
Всем разработчикам, занимающимся пушами, я советую начинать делать рассылки небольшими порциями.
Запустив нашу систему в самый первый раз, мы в UBANK отправили пуши большому количеству целевых групп сразу. Многие тут же отреагировали и одновременно вошли в приложение.
The Hamster Factor
Чтобы избежать подобных казусов, мы теперь настроили работу системы так, что в течение дня она рассылает каждый час по несколько тысяч сообщений, а не пушит всю базу в один присест.
Ничто не работает так хорошо, как собственноручно изобретенный велосипед. Собственная разработка дает такие возможности, какие никогда не предоставит готовое решение. По крайней мере, такова реальность в случае с пуш-уведомлениями.
Разумеется, мы планируем развивать эту систему. Сейчас наша задача — увеличить эффективность рассылки. Для этого мы хотим разработать новый тип уведомлений, которые, во-первых, будут не просто текстом, а с картинками, и во-вторых, по нажатию отправят пользователей сразу на лендинговые страницы, а не просто в приложение.
Но об этом, пожалуй, в другой раз.
ПОЛУФАБРИКАТЫ НЕ ДЛЯ НАС
Среди существующих облачных систем пуш-рассылок можно отметить такие сервисы, как Infobip, Jeapie, Pushwoosh, Urban Airship. У них много общего: все они не кроссплатформенны, позволяют отправлять пуши с учетом временной зоны, делать рассылки по расписанию, а также дают статистику.
Звучит неплохо, но когда вникаешь в детали, понимаешь: это как готовые обеды. Купил замороженный полуфабрикат, сунул в микроволновку — получил на выходе съедобное блюдо. Живот набил, но без удовольствия.
Carl Lender
Для UBANK главный минус всех этих облачных решений в том, что они умеют пушить только всю клиентскую базу разом. А мы хотели иметь возможность разбивать аудиторию на группы и высылать каждой из них разные сообщения.
Я понял, что надо делать такую систему, которая создавала бы списки рассылки на основе различных критериев поведения пользователей. В этом случае покупными полуфабрикатами не обойтись, нужно учиться готовить хорошие домашние обеды.
После небольшого исследования я оставил мысль о готовых решениях. Теоретически, что-то из них можно использовать как дополнение. Например, когда нам будет нужно поддерживать больше платформ (добавить Windows Phone и Web), станем отправлять пуши через облако, а не напрямую в APNS и GCM. Но пока все это нам не очень интересно.
ИНТЕЛЛЕКТУЛЬНЫЙ ПОЧТАЛЬОН
Разработанная мной система рассылки UBANK — это отдельный модуль платежного приложения, написанный на Scala. На его разработку у меня ушло примерно два месяца. Можно было сделать и быстрее, но у меня было много параллельных задач.
У системы рассылки пушей своя база данных MongоDВ. Там хранится история каждой рассылки. В общей сложности это десятки миллионов записей — засорять ими основную базу приложения нам совсем не хотелось.
Работа модуля не затрагивает основную систему. Поэтому мы можем тестировать изменения (к примеру, выключать или перезапускать рассылку). Основное приложение при этом не будет затронуто.
Логика работы модуля такова: периодически с заданным интервалом запускается запрос, из базы основного приложения выбираются пользователи, которым надо отправить пуш (в соответствии с придуманными нами правилами).
Как мы тут уже рассказывали в предыдущей статье, наши пуши, причем разные по содержанию, приходят трем группам клиентов. Первая группа — это те, кто прошел регистрацию, но так и не воспользовался сервисом. Вторая — юзеры, которые когда-либо совершили один платеж, а потом перестали пользоваться UBANK. Третья — люди, которые пользовались приложением, но последние три месяца его не открывали.
Чуть позже мы поняли, что упустили довольно значительную аудиторию людей, которые не совершали платежей в течение месяца. Многие из них не попадали во вторую группу, потому что совершили больше одного платежа.
Рано или поздно некоторые из них попали бы в третью группу. Но мы осознали, что в некоторых случаях напоминание через три месяца для них слишком запоздает. И не грех напомнить о себе чуть пораньше.
В общем, разрабатывая критерии выборки получателей для каждой рассылки, нужно отмерить семь раз, прежде чем резать. Чем ювелирнее вы будете обращаться аудиторией, тем выше будет полезный выхлоп.
janwillemsen
РУЧНОЕ УПРАВЛЕНИЕ
Но определить, кому в принципе нужно отправить пуш, это одно. Понять, как и когда именно это сделать, — другое.
Правила, кому и как мы отправляем пуши, формировались постепенно. Основные из них: частота отправки (раз в неделю), максимальное количество отправок (не больше пяти штук одному человеку). Еще мы не отправляем пуши ночью.
Мы проанализировали, в каких часовых поясах живут наши пользователи, и оказалось, что подавляющее большинство обитает в европейской части России, поэтому выбрали такие часы для рассылки, когда практически у всех день. Когда пользователей в других регионах станет больше, благодаря фильтрации с легкостью сможем сделать гео-привязку по часовым поясам.
Чтобы не спамить людей, нужно разработать систему постоянной проверки пользователя, попадает ли он под наши критерии или нет. Например, если мы послали пуш давно не платившему пользователю, и он заплатил, то наша цель выполнена — не надо его раздражать и снова рассылать ему уведомления.
Будет довольно глупо с нашей стороны присылать ему сообщение: «Давненько ты что-то не платил!» Но именно так все и происходило бы, если б мы воспользовались готовым решением: пуш продолжал бы отправляться с заданной периодичностью.
Следует при этом не забыть про ручное управление и предусмотреть возможность отправлять пуши не только по расписанию, но и когда захочется. Ручная отправка пригодится для пробных рассылок, когда вы захотите сначала протестировать работу системы на небольшой выборке пользователей.
ОТГРУЗИТЕ НАМ ЦИФР, ПОЖАЛУЙСТА
Нам важно отслеживать статистику ключевых показателей по каждой рассылке. Поэтому мы в UBANK сохраняем историю каждой из них, чтобы иметь возможность оценивать эффективность пушей.
Привязал ли человек карту, совершил ли он покупку — вся эта информация автоматически проверяется раз в час и отправляется в APNS или GCM, в зависимости от того, на Андроиде или iOS сидит клиент.
Для ускорения процесса мы используем batch-отправку. При отправке в GCM не забудьте, кстати, установить параметр отправки delay_while_idle в true — он говорит о том, что не нужно доставлять пуш пользоватлю, если устройство не активно.
У нашей системы рассылки пушей есть веб-интерфейс. Динамика по всем нашим ключевым показателям в веб-интерфейсе отображается в виде графиков и диаграмм.
Веб-интерфейс и графики используются для общей качественной оценки. Но у нас есть еще и выгрузка в Эксель. Все вычисления по каждой группе маркетологи, естественно, делают там.
Анализируйте результаты каждой пробной рассылки и вносите коррективы. Чем больше у вас информации о пользователях, тем эффективнее будет ваша рассылка.
Мы отслеживаем поведение наших юзеров через сервера — и благодаря этому про каждого клиента знаем, сам ли он скачал приложение, или оно было предустановлено, знаем версию его приложения, версию операционки смартфона, модель устройства и часовой пояс пользователя. Всю интересную для маркетинга статистику мы вытаскиваем и сохраняем на сервере.
ВАША ПОРЦИЯ, СЭР
Всем разработчикам, занимающимся пушами, я советую начинать делать рассылки небольшими порциями.
Запустив нашу систему в самый первый раз, мы в UBANK отправили пуши большому количеству целевых групп сразу. Многие тут же отреагировали и одновременно вошли в приложение.
Мы такой высокой конверсии не ожидали. Наш сервер не выдержал этой нагрузки и подвис.
The Hamster Factor
Чтобы избежать подобных казусов, мы теперь настроили работу системы так, что в течение дня она рассылает каждый час по несколько тысяч сообщений, а не пушит всю базу в один присест.
Ничто не работает так хорошо, как собственноручно изобретенный велосипед. Собственная разработка дает такие возможности, какие никогда не предоставит готовое решение. По крайней мере, такова реальность в случае с пуш-уведомлениями.
Разумеется, мы планируем развивать эту систему. Сейчас наша задача — увеличить эффективность рассылки. Для этого мы хотим разработать новый тип уведомлений, которые, во-первых, будут не просто текстом, а с картинками, и во-вторых, по нажатию отправят пользователей сразу на лендинговые страницы, а не просто в приложение.
Но об этом, пожалуй, в другой раз.
