Привет, друзья!
В предыдущей статье я рассказывал, как делал устройства для музыкантов — продукт в сфере рок-музыки. Это незабываемый трип, после которого я решил научиться разрабатывать взрослые IT-решения.
Многие спрашивали, на что я променял рочину — чем занимаюсь сейчас? И сегодня расскажу о другом проекте с рабочим названием Jetfire (спёр имя у робота из Трансформеров). Он не такой фановый, скорее даже приторно-айтишный, но делается на тех же морально-волевых дрожжах, что и железки для музыкантов.
Постарался уделить больше внимания принятию решений в условиях пет-проджекта. Возможно, этот опыт будет полезен при разработке ваших собственных проектов, а может быть, вы просто посмеётесь с кул-стори — это тоже будет успехом. Лонгрид получается неприлично длинным, поэтому разбил его на части и это первая.
Итак, всё началось с банального — открыл Яндекс.Навигатор на своём айфончике и сразу со старта получил в лицо поп-ап с промо каких-то новых фич. Естественно, сразу начал искать, как его закрыть, желательно не читая.
Помню, подумал — жаль, нельзя на мобилке сделать ad-block, как в браузере, чтобы запретить выпрыгивание любого кала. В общем, зародилось во мне желание избавить мир от поп-апов.
Вторым звоночком стали наблюдения, как лихо люди на интервью пролистывают красивые онбординги (экраны при первом старте с объяснением функций приложения, которые мы так долго придумывали), чтобы разобраться со всем позже — по ходу дела.
Случай другой, но суть похожа: пытаемся нанести людям добро, научив их пользоваться сервисом, но только раздражаем, потому что обучение получается не к месту.
Ну и финальным аккордом для решения покопаться в теме обучения фичам стал момент, когда я поймал себя, проектирующим точно такой же выпрыгивающий фичеринг на старте для раздела аналитики в рабочем приложении — Деле. Стоп! Я же должен был бороться со злом, а не... В общем, задача про поп-ап уехала в бэклог, а я предался размышлениям о человеческой натуре и причинах переживаемых ей эмоций.
Идеи
Очевидно, любое промо фичи делают, чтобы научить человека новым возможностям — сделать ему лучше. Но почему я, как пользователь, испытал резкий негатив, когда с этим столкнулся?
Три мысли, почему это может происходить с людьми (помечаю догадки цифрами):
— 1️⃣ Не интересна промотируемая фича
— 2️⃣ Фича интересна, но мы не вовремя
— 3️⃣ Фича интересна, но не нравится форма рассказа (может, надо видео?)
Чтобы чуть лучше разобраться в причинах, попросил подписчиков в инстаграме рассказать про крутую новую фичу, о которой они узнали, а потом выяснил, откуда они о ней узнали. Результаты были такие:
Ответ "Рассказали друзья" исключим — друзья ж тоже как-то узнали о фиче впервые. Тогда получается:
≈ 50% пользователей узнали о запомнившихся фичах из онбординга,
≈ 30% из соц сетей
≈ 20% из What's New
Предположил, что доля пункта "Из Whats New" завышена (среди моих подписчиков доля айтишникиов наверняка выше среднего), так что онбординг и фичеринг — самые действенные способы рассказа о фичах.
Получается, расходимся? Онбординги и фичеринги на самом деле работают, а вызываемое ими раздражение — сопутствующий ущерб под крепким сапогом продуктовых метрик? Ну нет, есть ещё зацепка.
Гипотезы
Респонденты, ответившие про онбординги и фичеринги, рассказали, почему они в них вчитались, а не скипнули. Ответы можно свести к двум случаям:
- Был предварительный интерес к фиче. Уже осознал решаемую ей задачу, выхватил интересные ключевые слова на экране, или в целом интересуется темой фичи. То есть уже был контекст
- Было особо нечего делать. Мотивация ответивших про соц сети тоже сюда укладывается — тик-ток и инстаграм листают же, когда не заняты
или на горшке
Треть людей узнала о новых фичах из сториз и твитов в соц-сетях, а ещё половина — из фичерингов и онбордингов, которые выглядят как сториз. Итого, сториз как формат фичеринга — вроде огонь, здесь проблем не должно быть, вычёркиваем 3️⃣.
Получается, карусель с кругляшами сториз вроде должна неплохо работать в роли FAQ по приложению, который изучают при наличии свободного времени.
Только вот конкурировать за внимание и время пользователя очень тяжело. Наша карусель со сториз-объяснением фич точно разгромно проиграет тому же тик-току. Нужно подумать, как вовремя подсунуть нужный фичеринг пользователю и не раздражать.
То есть обратить на себя внимание:
— когда он не особо занят (догадка 2️⃣),
— угадать, когда ему это вот прям нужно = он в контексте нашей фичи (догадка 1️⃣)
Но как это понять? Задача про фичеринг раздела статистики в рабочем приложении была поднята из бэклога и на базе неё спроектирован эксперимент.
Эксперимент
Цель эксперимента — понять, будут ли пользователи лучше погружаться в продукт (проходить глубже по воронке его использования), если мы начнём показывать фичеринг, когда пользователю это может быть интересно?
Ниже опишу его подробно, но главные выводы такие — просто подгадывая нужный момент показа фичеринга и никак не меняя приложение, получилось:
- Снизить раздражение пользователей в 2 раза (люди реже закрывают фичеринг, чаще тапают по экшен-кнопке, переводящей из сториз на фичу)
- Увеличить частоту использования фичи почти в 2 раза (люди лучше понимают, зачем им фича и возвращаются в неё)
- Увеличить retention фичи на 30—50% (то же, что и выше, но на временном промежутке и с оговорками)
Естественно, я захотел использовать этот подход не только для рабочего приложения, но и для своих сайд-проектов. Офигеть — всего лишь разложи подсказки по приложению и метрики подрастут.
Но встроить один тост в приложение — это одно, а наводнить его системой из таких подсказок, да ещё и чтобы она была расширяемой для новых фич — это вообще другое. А, ещё хотелось бы не тратить время разработчиков на эту историю — у них задач по развитию основной функциональности по горло.
Нужен какой-то внешний сервис, который умеет это из коробки. И такие сервисы действительно есть, но там поджидало и некоторое разочарование.
Подробное описание эксперимента
Это глава для задротов продактов — описание эксперимента, который вы можете повторить у себя в проекте. Надеюсь, найдётся человек, кому это интересно так же, как мне 🙂. Если вы не из таких — смело пропускайте и двигайтесь к следующему разделу о доступных решениях.
Итак, самое сложное — ответить на вопрос «когда пользователю нужно показать фичеринг»? В нашем случае я предположил, что пользователи, зашедшие в раздел действий клиента в карточке его компании, заинтересуются и аналитикой компании — то есть промотируемой фичой.
Суть эксперимента свелась к сравнению поведения пользователей, которые:
- None. Вообще не видели фичеринга (контрольная группа)
- Application Start. Стандартный «фичеринг на лицо» на старте приложения (привычное промо, как у всех)
- Toaster. При заходе на экран действий клиентов, показываем тост-приглашение изучить раздел аналитики. По тапу в него открываем фичеринг (угадываем контекст пользователя, но не рвём его неожиданным поп-апом)
- Push. После выхода из приложения шлём пуш-приглашение изучить раздел аналитики (после предполагаемого получения ценности, пока пользователь благосклонен и у него есть время, предлагаем изучить новую функцию)
Пользователей поделили на 4 группы в Firebase, пробросили атрибуцию в Amplitude и поведение рассматривал уже там. Метрики для отслеживания эффективности взял такие:
- Воронка прохождения фичеринга. Доля людей, перешедших на фичу из фичеринга, как метрика интереса. Доля закрытий, как метрика раздражения.
- Медиана количества заходов на фичу за период
- Классический retention в фичу по неделям и месяцам
В каждый сегмент попало около 1000 человек и результаты оказались вообще огонь. Давайте на них посмотрим.
Retention по месяцам
Вкратце, чего хорошего здесь нашёл. Это график возврата в промотируемую фичу из первого её запуска в последующие по месяцам.
- Зелёная и синяя линии — ретеншен пользователей, увидевших фичеринг после тоста и пуша соответственно.
- Фиолетовая — увидевших фичеринг на старте приложения.
- Голубая — не читавших фичеринг вообще.
Ретеншен после тоста и пуша на 30—50% выше остальных. А пользователи с фичерингом на старте возвращаются так же, как те, кто его не видел вообще. Тост и пуш рулят!
☝️Здесь важно исключить ошибку сегментации: ведь тост показывается людям на экране контекстной фичи. Возможно, на этот экран попадают более погружённые в продукт пользователи и мы им этим событием просто сегментируем более лояльную аудиторию.
Чтобы исключить эту ошибку, я добавил красную линию — люди, открывавшие экран контекстной фичи, но не видевшие тостера или пуша. То есть пользователи, опыт которых отличается именно непоказом тостера или пуша. Результат вы видите — красная линия ещё ниже, чем фиолетовая и голубая. Тостер с пушем работают.
Медиана и среднее количество открытий фичи
Диаграмма выглядит сложной, но сейчас мы её прочитаем.
Синие столбики — это среднее количество запусков фичи на пользователя трёх сегментов пользователей, увидивших фичеринг.
Голубой справа — среднее количество запусков референсной группы без фичеринга.
Картина маслом, как с retention — фичеринг на старте приложения не увеличивает количество запусков (синий столбик application_start по сравнению с голубым). А вот после пуша и тоста метрика здорово растёт.
Зелёные столбики — подсегмент аудитории, перешедшей со сториз на фичу. Фиолетовые — закрывшие сториз. Эти цвета — вовлечённость тех же людей из синих столбиков, но распавшихся на два случая: закрыли они сториз или перешли на фичу. Кароче, кто перешёл сразу, те и пользуются фичой чаще.
На медиане разброс становится не такой сильный. Столбики нарисованы с разным масштабом, поэтому важно обратить внимание на цифры.
Интересно, что у сегментов push и application_start значения сходятся. На самом деле, отличие можно увидеть, чуть углубившись в настройки и данные, но его размаха не хватает, чтобы увидеть разницу на таких цифрах — как-будто не хватает разрешения.
Метрика бесячести — доля закрытия фичеринга
Назвал этот график метрикой бесячести — чем больше людей закрывают показанный фичеринг, тем сильнее раздражаются. Есть ещё среднее время показа фичеринга, там похожая картина, убрал график из статьи, чтобы сэкономить время чтения.
Кажется, что фичеринг после пуша не так уж и сильно выигрывает у фичеринга на старте приложения, но не забывайте, что тапая на пуш, пользователь уже ждёт какого-то его продолжения и испытывает меньше негатива, чем в случае, когда неожиданно видит фичеринг на старте. В общем, после пуша хоть и тапают в Закрыть, но не с такой злобой.
Ну а с тостером всё ясно — в 2+ раза его закрывают реже. Но и попадают на такой фичеринг не все пользователи, а только те, кто совершил нужное нам целевое действие.
Скоринг
Чтобы свести довольно разные метрики к одной синтетической чиселке, составил скоринг метрик каждого из сегментов. По нему выходит, что тост и пуш работают сильно лучше, чем фичеринг на старте по сумме параметров.
В общем, вроде тема работает, осталось только развесить тосты по всему приложению так, чтобы они приходили на помощь пользователю очень деликатно в ситуациях, когда он системно проходит мимо важной фичи.
Решения из коробки
Окрылённый результатами эксперимента, представил себе идеальный инструмент — это должна быть помесь сториз с системой аналитики (типа Amplitude или Firebase Answers) с двумя сценариями:
- При использовании приложения, пользователь получает контекстные подсказки — тосты. Тапает в них, открывает сториз и изучает фичу, которая необходима прямо сейчас. Подсказки объединяются в апп тур и пользователь, как по дереву исследования, узнаёт обо всех функциях, просто пользуясь приложением. При этом подсказки на изученные фичи не выпадают.
- Пользователь читает о фичах в карусели сториз, как в инстаграм, если ему нечего делать (например, едет в такси и заглянул в наше приложение). Если сториз про фичу прочитана, считаем её изученной и пользователь контекстных подсказок по ней не получает.
Первый сценарий — необходимый, второй — приятный. С этим видением начал искать готовые сервисы с такими требованиями:
Немного покопав интернет, нашёл варианты. Ниже вкратце их достоинства и недостатки. У всех есть отличные онлайн-редакторы контента сториз с большими возможностями, кастомизируемый UI, аналитика просмотров.
The Storyteller
Эти ребята работали, как аутсорс-студия. Поняли, что сториз нужны всем клиентами и сделали общее решение, которое превратилось в публичный проект Storyteller. Выглядит, как лучшее решение, если хочется попробовать сториз в приложении.
👊 Супер-силы:
— Крутой онлайн-редактор: можно делать даже опросы, квизы, шаринг в соц сети
— Есть возможность показывать в сториз fullscreen-гуглорекламу и зарабатывать
— Есть таргетинг сториз по лейбелам, которые присваиваются пользователям
— До 100k MAU бесплатно, то есть можно встроить в любой проектик и наслаждаться
🗿Из минусов:
— Нет реализации контекстных подсказок. А это главное, что хотелось проверить
— Доступ к SDK получить можно только написав им письмо, но это легко
— При достижении 100k MAU стоимость сразу $349. В целом ок для приложения со сходящейся экономикой на закупке трафика, но по году прям ощутимо. А для для пет-проджекта хотелось бы раза в 2—3 дешевле.
Story.ly
Прямой конкурент сторителлера.
👊 Супер-силы:
— Доступ к SDK можно получить без контакта с менеджером — прям в консоли
— Есть классный инструмент импорта сториз из Instagram — можно затащить сториз из корпоративного аккаунта инсты прямо в приложение
— На разные экраны приложения можно добавить карусели с разными сториз
— Есть таргетинг сториз по сегментам пользователей
🗿Минусы:
— Нет реализации контекстных подсказок. А это главное, что хотелось проверить
— Swift sdk на iOS не компилировалось несколько недель после обновления Swift, а в демо-приложении сториз отображаются с некрасивыми артефактами рендеринга
— Стоимость от $249 за тариф до 25k MAU с триалом в 1 месяц. Дороговато для пет-проджекта, но для рабочего проекта норм
Push Woosh
Всегда знал ребят, как авторов лучшего решения для управления пушами, а оказывается у них есть мощнейшая поддержка in-app мессенджинга.
👊 Супер-силы:
— Ура, есть реализация контекстных подсказок! Да ещё какая — с люто крутым редактором сценариев, включая отправку пушей и email по совершённым пользователям событиям в приложении
— Онлайн-визуализация прохождения сценариев, просто пушка
— Очень грамотные специалисты, которые рассказывают про продукт невероятно качественно и хорошо. Ребята, вам привет и большое спасибо за уделённое время!
— Есть демо-приложение в сторе, на котором можно увидеть и потестить сценарии подсказок, которые можно завести в консоли с демо-доступом
🗿Минусы:
— Дорого. Прайсинг рассчитывается индивидуально на базе количества подписчиков (пуш-токенов) приложения, которое кратно выше MAU. Озвученные в нашем случае цифры говорить не буду, но для моих сайд-проектов они совершенно неприемлемы, и для рабочего проекта оказались болезненны
— Нет сториз в карусельках. Без них можно было и прожить, да и это не такая огромная функция, чтобы ребята её не запилили. Возможно, ко времени публикации статьи сториз у них уже появятся
Получается, у всех сервисов:
— очень мощные редакторы контента сториз,
— неплохие возможности по таргетингу,
— но довольно высокая цена (от $250 в месяц за 100k MAU и выше)
Решение от Push Woosh отлично подходит под задачу, но не вписалось в наш рабочий бюджет и тем более не впишется в бюджет моих пет-проджектов.
А хочется, наоборот:
— очень мощные возможности по таргетингу (которые есть только у пуш-вуш),
— простейшее редактирование контента сториз,
— и чтоб раз в 10 дешевле
Если представить в табличке, то что-то такое (огоньками пометил супер-силы):
Ну то есть такое sdk, которое по умолчанию добавляешь в каждый проект, как Firebase. Только киллер-фича Firebase — бесплатная аналитика, а киллер-фича нужного сервиса — бесплатный апп-тур из сториз, который будет погружать пользователя в продукт и сфокусирует разработчиков на разработке новых фич, а не на разработке обучалок этим фичам.
Когда стало ясно, что с готовыми сервисами не получается, прикинул — можт, собрать своё решение? Сначала в ужасе отбросил эту затею — это ведь sdk, там требования по стабильности эмм.. ну так скажем, повыше, чем у просто пет-проджекта. Несколько недель сомневался, стоит ли тратить кучу времени на велосипед, закидывал идею друзьям-продактам и владельцам приложений, слушал их мнение.
Но дурная голова рукам покоя не даёт, безумие и отвага победили. В итоге расчехлил XCode и начал писать sdk для iOS, которое решит эти задачи на минималках в собственных проектах, чтобы проверить работу апп-тура из подказок на масштабе хотя бы одного приложения.
Именно тогда появилось и название для ещё не появившегося продукта — Джетфайер. Во-первых, в слове тоже есть Fire — как в Firebase, ведь хочется поддержать его startup-friendly идеологию. А во-вторых — это имя древнего трансформера, который, хоть и обладал скверным характером, но пожертвовал свои запчасти Оптимусу Прайму в сложный момент. Как и sdk, которое будет баффать сильные стороны любого приложения, которому отдаст свои функции 😄.
Забегая вперёд, его альфа-версия уже приносит пользу в нескольких продуктах, но задача естественно оказалась сложнее, чем выглядела. Зато и ценность ощутима. И хоть ещё и не было официального релиза, у него даже есть своя страничка.
Заключение первой части
Здесь рассказал о том, как из личной боли (надоедливые поп-апы, мешающие использовать приложение), через осознание ценности (промо фич в рабочем продукте) появилась гипотеза и эксперимент, который решил задачу в частном случае — сделал эффективное промо конкретной фичи.
А по результатам эксперимента выросло какое-то видение продукта, способного решить проблему в общем виде, и его не получилось найти на рынке.
Возможно, я всё-таки плохо искал и в комментариях мне набросят лучший вариант решения, чем пилить свой велосипед. Или в самой идее всё-таки есть подводные камни, которых я пока не увидел, из-за которых она не взлетела у других разработчиков. Но если результаты эксперимента или какая-то из частей истории вам оказались интересны, я уже буду рад.
Надеюсь, статья не выглядит рекламным проспектом — как минимум, потому что рекламировать ещё нечего, и поделиться могу только графиками, гифками и очередной кул-стори.
А о дальнейших событиях — почему и как у проекта появилась команда и кто эти прекрасные люди; об общении с потенциальными партнёрами; про то, как мы чуть всё не забросили, убедившись в правомерности ценников Push Woosh на практике, но всё же нашли решение, расскажу уже в следующей части.
А пока маленькие просьбы:
- Расскажите, может быть, вы уже решали такую задачу другим способом? Или у вас есть соображения, как сделать лучше?
- Не слишком ли я подробно пытаюсь описать происходящее? Может быть, сократить повествование?
На этом спасибо за прочтение, до следующих встреч! 👋