Система аналитики: покупать или создавать собственную программу11.06.2016 18:22

Ведущий аналитик Devtodev Василий Сабиров

Я встречал следующие мнения от разработчиков:

• «Нам не нужна аналитика». Прекрасно понимаю тех, кто придерживается этой точки зрения. Для небольших студий, которые на одном энтузиазме делают свою первую игру, такой подход вполне оправдан — им лучше заниматься игрой, а не аналитикой.
• «Аналитика есть, а что с ней делать?» Команда интегрировала бесплатную систему и теперь гордо считает, что у нее есть аналитика. Но никто точно не понимает, как ей пользоваться.
• «У нас есть аналитика — вот 100 посещений в день». У многих проектов аналитика сводится к анализу посещаемости сайта и подсчёту денег, полученных от продукта. Однако между посещением и платежом происходит ещё много интересного — разработчики могут упускать это из виду.
• Аналитика есть, а специалиста нет. Команда смотрит на основные метрики, но не понимает, как выводы делать на их основе. Как построить прогноз? Как сработало последнее обновление? Для ответа на подобные вопросы нужен отдельный специалист.
• Аналитика и специалист. Эксперт нашелся и даже начал работать с системой аналитики, используя её для ответов на серьёзные вопросы.
• Специалист и аналитика. На первый план выходит аналитик, и все вопросы о данных решаются через него. Он даже использует какой-то аналитический сервис, но команда о нем не знает, да и не должна знать.
• Специалист + аналитика + аналитика + … Систем на рынке очень много. Среди них есть как универсальные, так и узкоспециализированные. Аналитик в такой ситуации по-прежнему остается точкой доступа к данным для всей компании, но использует множество систем, взяв лучшее от каждой из них.
• Полностью сами. Система аналитики с нуля разработана компанией, полностью кастомизирована и способна отвечать внутренним запросам. Компания имеет полный контроль над данными: структурирует, хранит и визуализирует их в созданной системе. Ничего на рынке не заменит эту разработку, потому что у проекта слишком много особенностей.

Многим кажется, что раз крупнейшие игроки из разных сегментов рынка (Zynga, Facebook, Airbnb) сами делают свою аналитику, то это действительно лучший путь. Всё не так просто — у этого варианта есть плюсы, минусы и подводные камни.

Доступ к данным и движущая сила

Итак, вы разработали собственную систему аналитики и создали целый отдел, который с ней работает. Представьте, что каждый сотрудник — маркетолог, PR-специалист, геймдизайнер и даже продюсер — будет задавать аналитику вопросы из серии: «Сколько вчера был DAU?», «Сколько в этом DAU было пользователей из России?», «Сколько всего пришло новых пользователей по стране»?

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

Куда удобнее, когда каждый сотрудник может зайти в систему и самостоятельно найти ответ на свой вопрос. Это то, что называется data-driven, — все знают, какие данные им нужны, знают, как их получить и не отвлекают при этом других людей. Менеджер по продукту Instacart Фарид Мосават, столкнувшийся в своё время с тем же выбором, сказал: «Если вы считаете себя data-driven, но все запросы проходят через аналитика, то вы не data-driven».

Недооцененность затрат на разработку аналитики

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

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

Представьте, например, насколько придётся изменить систему, если вы решите делать в ней A/B-тесты, которые не закладывались в изначальный проект. Со временем система обрастает новыми затратами и требует больше ресурсов, которые отнимаются у разработки самого продукта. Фарид Мосават говорил: «Я больше заинтересован в решении важнейших вопросов продукта, нежели в построении технической инфраструктуры для аналитики».

В одной статье на эту тему говорится: «ИТ-специалисты не должны выполнять работу библиотекарей, которые ищут данные и правильно их интерпретируют по каждому запросу. К тому же инженерам потребуется время на создание и поддержку структуры данных».

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

• Расчёт основных метрик. Речь не только про DAU, но и про любые другие метрики.

Скриншот из системы Amplitude

• Сегментация пользователей. Если вы хотите вести аналитику не по всем пользователям сразу, а в разрезах (страна, платформа, поведение), вам придётся выполнять отдельный запрос для каждого сегмента, затем оформлять результаты в таблицу или дашборд и сравнивать друг с другом. В системах аналитики эта функция автоматизирована, поэтому вы, однажды создав сегмент любой сложности, будете всегда видеть его данные.

Скриншот из системы Localytics

• Push-уведомления. Разрабатывать свой механизм рассылки push-уведомлений — дело хлопотное и неблагодарное. Слишком много особенностей придется учесть. Но в современных системах аналитики уже существуют инструменты для рассылки уведомлений. Более того, вы можете в одной вкладке браузера следить за отдельным сегментом пользователей, отправлять им уведомления и смотреть, как выправляются метрики.

Скриншот из системы Devtodev

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

Скриншот из системы Mixpanel

• A/B-тесты. Выделить сегменты, случайно или в определенном порядке «раскидать» по ним пользователей, одному сегменту показать «A», другому «B», выбрать метрики, посчитать их значения для каждого сегмента, рассчитать статистическую значимость — готова ли к этому ваша самописная аналитика? А продвинутые сервисы начинают внедрять такую функциональность, становясь больше, чем просто аналитикой, — они не только подсказывают, как изменить продукт, но и помогают внести и протестировать эти изменения.

Скриншот из системы deltaDNA

• Бенчмаркинг. Это та функция, которой в самописной системе аналитики нет и не будет, если у вас мало проектов. Преимущество сторонних сервисов в том, что у них много клиентов, и они могут их сравнивать. Разумеется, они не скажут вам, чему равно ARPU других проектов в том же жанре, но могут подсказать, как ваш ARPU соотносится с чужими.

Скриншот из системы GameAnalytics

«А как же кастомизация?» — спросите вы. Ведь если мы пишем систему аналитики с нуля под свой проект, то она учтёт все наши особенности и сможет ответить на любой вопрос. Действительно, сможет. И это основное преимущество самостоятельно созданных систем. Но и сторонняя аналитика кое-что предлагает: как правило, у нее есть возможность выгрузить данные в .csv, .xlsx и так далее. Используя эти данные, вы сможете ответить на любой вопрос, сэкономив на содержании серверов.

Как принять решение

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

• Что вы требуете от аналитики? Что бы вы хотели знать о своём проекте?
• Кто будет пользоваться системой?
• Какие роли будут выделены (маркетолог, гейм-дизайнер, менеджер по продукту, аналитик). Какие данные нужны каждому сотруднику?
• Смогут ли все пользователи системы быстро получить доступ к данным и визуализировать их?
• Важный вопрос — каков разброс между минимальной и максимальной компетентностью в аналитике у тех, кто будет пользоваться системой?
• Как изменятся ответы на вышеуказанные вопросы, когда компания вырастет?
• Сколько денег потребуется на содержание системы (даже если просто считать сумму затрат на аналитика и на серверы и сравнивать со стоимостью системы на рынке)?

Рекомендации

Наконец, несколько конкретных рекомендаций о том, как поступить.

• Если вы — небольшая инди-студия и вы уже задумались об аналитике, подключайте сторонний сервис, который всё сделает за вас. Вы в это время будете заниматься своим продуктом.
• Если вы начали расти, и вместе с тем растут ваши запросы к данным, наймите аналитика и вручите ему эту стороннюю систему. Пусть он отвечает на ваши вопросы с её помощью.
• Если у вас появляются отделы, иерархия, непересекающиеся продукты и функции, то вам подойдёт принцип «Специалист + аналитика + аналитика + …». На рутинные вопросы сможет ответить любой сотрудник с помощью одной из интегрированных систем, а для более сложных из них есть аналитический отдел.
• Если же вы уверены, что лучше вас аналитику никто не сделает, вперёд, создавайте её сами, это решение достойно уважения. Но прежде чем начать, посчитайте затраты на запуск и поддержку.

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

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru