Вот чейнджлог iOS приложения фейсбук. Версии именуют без мозгоебства, релизятся часто, что поменялось сами не знают.

Очень жду когда искусственный интеллект заменит тех кто пишет про искусственный интеллект

Главное что надо знать про аналитику – что это процесс.
Ей надо заниматься каждый день: смотреть цифры, копать что влияет на изменение той или иной метрики и как работает система в общем.

Если просто смотреть на красивые циферки в дашборде – результата будет немного.

Я собственноручно запускал четыре стартапа. Каждый раз было ощущение что сейчас запустимся и оно само полетит. В Pact.im например мы запустили сервис, налили траф, получили 100 регистраций и ноль продаж (хотя должна была быть минимум одна). Я решил что это ошибка, ливанул еще 100 регистраций, и тоже ноль продаж.

Коуб первый год жизни был в районе 200-300 DAU, и тоже было не очень понятно чего не хватает.

Выход тут только один: надо идти общаться с клиентами. Не в мессенджерах и почте, а по телефону или встречаться. Клиенты расскажут что не так, и будет понятно что делать дальше.

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

В iFunny тестим меню приложения. Слева вариант по умолчанию, справа новый вариант.

У нового варианта оказался хуже ретеншен и меньше сессий на уника. Начали разбираться, выяснили что просели заходы в ленту Shuffle (лучшие из лучших в случайном порядке). Она потянула вниз шаринг и сессии на уника в день.

Решили что уберем иконку чата и протестим еще раз.

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

Я довольно долго пытался понять как можно на это влиять, потому что это нигде особо не описано. Что я понял:

– Само написание кода съедает только 50% времени. На это время мы влиять не можем.
– Вторые 50% забирают QA, Code Review, Release и все дополнительные этапы. На них мы можем влиять, и это поле для оптимизации.
– Выстроенное общение внутри команды и с заказчиком это 80% успеха. Во всех моих командах дейлики, на которых мы каждый день обсуждаем статус задач и проблем
– Чтобы быстро получать результаты ты как заказчик должен сам во все вникнуть и искать пути как ускориться.

Почитать советую эти две книжки:
– "Цель" Голдратта
– "Priming Kanban" Jesper Boeg

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

Факт в том что 60% разработчиков на рынке труда не умеют программировать. Несмотря на то что по резюме они работают в топовых IT компаниях и уверенно отвечают на любые технические вопросы, они теряются при виде элементарных задачек по программированию.

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

В начале pact.im я думал что SAAS это когда клиенты платят каждый месяц равными суммами. Я попробовал воплотить это в жизнь, посчитал юнит-экономику и получилось что клиент стоит в районе 7 тыс рублей, а чек в лучшем случае 4000.

Начал думать, посмотрел на игроков рынка, понял что все стараются продавать несколько месяцев вперед. Лучше конечно год или полгода. Квартал тоже катит. Клиент не факт что будет пользоваться продуктом, потому что это всегда усилия с его стороны, но деньги на продажу и его обучение мы все равно тратим.

У многих популярных SAAS такая модель: вам звонит менеджер и продает годовую подписку. В той же AmoCRM вы просто не купите меньше чем на квартал. Все крупные западные B2B игроки работают только по годовому коммитменту (Akamai например).

В результате я поправил цены и сделал такие тарифы:

1 мес – 5000
3 мес – 12000 (стоимость месяца 4000)
6 мес – 20000 (стоимость месяца 3333)
12 мес – 30000 (стоимость месяца 2500)

Сейчас самый популярный тариф – 3 месяца. С таким чеком можно спокойно тестить каналы маркетинга и не переживать по поводу того продлит клиент или нет.

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

Формула выведена собственным горьким предпринимательским опытом.

В iFunny зарелизили билды с AppSee. Это SDK для записи экрана пользователей. Мы пишем первые 10 сессий в надежде найти косяки онбординга и таким образом найти способы увеличения ретеншена.

То что мы нашли никак не найти через аналитику построенную на эвентах. Пишет она конечно не на всех девайсах, и с косяками, но все равно дает важную инфу.

Например что мы нашли:
– Часть новых пользователей просто не видит дефолтного онбординга (баг)
– Если пользователю пошарили мем, и он по этой ссылке ставит приложение – то онбординга тоже нет
– Много новых пользователей на самом деле не новые (а существующие с новым девайсом)
– Пользователи смотрят в первую очередь контент а не приложение, и какой он будет в первую сессию скорее всего драйвит ретеншен

В общем будем копать дальше, это крутой канал фидбека.

Ретеншен по новым (RR) – это ключевая метрика для развлекательных проектов. У сильных продуктов типа Snapchat или Facebook RR1 (возврат на первый день) больше чем 60%. У слабых – 30% и ниже.

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

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

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

В iFunny например хорошо остаются те кто в первую сессию много смотрят. Как увеличить их количество непонятно: конкретной проблемы с ушедшими нет. Возможно им не нравится контент, возможно реклама, возможно UI, возможно у них специфические ожидания. Методом тыка это не подобрать.

В любом случае нужно сначала общаться с пользователями и понять что у них в голове, а потом тестить гипотезы исходя из полученных знаний.

Продолжим тему ретеншена.

Чтобы его улучшать сначала его нужно правильно посчитать. Если считать в среднем оставаемость по всем новым, то вы получите цифру, но будет непонятно что делать дальше.

На примере iFunny я понял что бывает два вида пользователей которых мы считаем как новые:

1) Те которые уже ранее пользовались iFunny и ставят повторно (у юзера новый телефон, удалил потом поставил заново, итп)
2) Пользователи которые пришли совсем в первый раз (трафик из стора и платный)

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

Чтобы это решить мы сделали экран-классификатор пользователей (см картинку выше). Пользователь на первом запуске подтверждает точно ли он новый, или пользовался iFunny раньше.

Данные с него показали что реально новых установок всего 50-70% от общего числа (в зависимости от канала трафа). Особенно удивило что по платному трафику старых приходит довольно много (30-50%) и они драйвят ретеншен этого канала.

Ну и теперь все новые эксперименты мы сегментируем в зависимости от того что ответил пользователь на классификаторе.

Все кто вписывает вас в секту любителей АБ-тестов не договаривают следующее:

1) Это очень дорого в разработке и аналитике
2) Это не дает краткосрочных результатов (иногда вообще не дает результатов)
3) У 99% проектов мало аудитории чтобы полноценно их проводить

Разговоры с пользователями или запись их экрана гораздо проще и дешевле поможет понять что не так в продукте.

Спустя шесть лет с момента старта coub.com мне удалось полностью выйти. Vaizra Capital Льва Левиева выкупила мои акции. Спасибо им за это.

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

За первый квартал команда роста iFunny сделала около 15 АБ-тестов на улучшение онбординга новых пользователей. Чем могу поделиться:

– В первую сессию пользователь приходит за контентом а не за функциями приложения. Мы меняли местами ленту featured на ленту subnoscriptions, и ретеншен сразу падал на 10 п.п. По AppSee я вижу подтверждение этому: 99% пользователей листают мемы и залипают в них. Больше никуда не ходят и ничего не нажимают.
– Принудительная регистрация в первую сессию убивает ретеншен. Мы протестили несколько вариантов: регистрация, регистрация + подписка на пользователей, регистрация по телефону + инвайты друзей. Результаты всегда хуже, от 5 до 15 пунктов.
– Подробные объяснения функций приложения на онбординге добавили нам 1-2 п.п. к ретеншену.

Еще хочу отметить что если в тесте RR1 высокий – то будет высоким RR7 и RR21. И наоборот: если RR1 низкий, то дальше всё тоже будет плохо.

Можно это использовать чтобы быстро проверять гипотезы и не ждать например данных по RR7.

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

Например FMCG компании. Colgate за безумные деньги покупает клиента, и в этом есть смысл ведь он будет довольно долго чистить зубы их зубной пастой каждый день.

Так и в наших интернетах. У B2C продукта есть две метрики: RR по новым (например до 21 дня) и частота использования продукта в день и в неделю.

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

Например пользователь Facebook делает в среднем 13 сессий в день, и для пользователя это выглядит как очень сильная привычка к конкретному приложению. Но с точки зрения менеджеров facebook это довольно четкий набор фич которые заставляют пользователя вернуться и делать эти 13 сессий.

У развлекательных проектов все зависит от DAU. DAU падает - всё плохо, растет – всё хорошо.

Это очень общая метрика, и сходу не очевидно как с ней можно работать. Для iFunny я придумал DAU отчет, где DAU бьется по нескольким группам показателей. Всего там больше 60ти колонок. Вот два примера как это работает:

1) Бьем DAU по активности пользователей. Тут DAU = Новые пользователи + Пользователи которые были в аппе вчера + Пользователи которые вчера не заходили но сегодня пришли
2) Бьем DAU по типу входа в апп. DAU = входы по иконке + входы через пуш + входы по диплинку

Любое колебание DAU я анализирую по куче таких групп метрик. В 99% случаев причина колебания в одной группе.

Например: падает DAU андройда последние три дня. Начинаю разбираться – видно что в группе 1 падают новые пользователи, а в группе 2 входы по диплинку. Смотрю структуру по входам через диплинк: упали входы с Facebook Messenger. Сразу понятно куда копать и что происходит.

Если вы растете – важно понимать как сохранить этот рост и как его умножить. Если вы падаете или стоите на месте – то вам надо понимать в чем проблема и где точки роста.

В АБ-тестах часто побеждают варианты которые логически не объяснить. Это нормально, и не стоит в них эту логику искать. Нужно просто накинуть еще десяток вариантов.

Вот пример тестирования заглавной картинки в Google Play. Пример справа дает на 7% больше инсталлов. Я могу дать 5 причин почему так должно быть, и 5 причин почему не должно. Смысла в этом копаться нет, лучше брать количеством.