Кейс из России: Как команда сервиса редакционной аналитики onthe.io изучала своих пользователей
Команда сервиса редакционной аналитики onthe.io написала для рубрики «Кейсы» колонку о том, как они изучали работу редакций, как собирали обратную связь от пользователей и к каким изменениям в проекте это привело.
В июле этого года мы уже рассказывали читателям vc.ru о том, как развиваем систему аналитики для медиа onthe.io. За те несколько месяцев, которые прошли с момента интервью, мы успели создать решение для интернет-магазинов, подключить к отслеживанию сайт vc.ru и несколько сотен других медийных проектов. Официальные цифры по развитию нашей системы аналитики можно увидеть здесь.
Сегодня хотели бы рассказать о том, как мы учились понимать наших пользователей, и к каким результатам это привело.
В какой-то момент времени нашего развития Евгений Волков (Life.ru) задал нам вопрос: «Для кого ваша система? Кто должен ее использовать?». На то время мы не особо заморочились над данным вопросом, отделавшись общей фразой «Для всех в редакции». Но сам вопрос крепко засел в нашем коллективном мозгу и периодически напоминал о себе похожими вопросами других клиентов.
И только после того, как количество наших клиентов достигло нескольких сотен, удалось осознать, что уникальные кейсы применения системы onthe.io заканчиваются и начинают повторяться. Проблемы разных проектов стали пересекаться, а мы начали искать между ними общие нити.
То, к чему мы пришли, поразило своей простотой - проблемы редакции и поиск их решений отлично укладываются в задачи сотрудника, работающего с контентом. Ответ был на поверхности - система или решает его задачи, или нет. И в момент, когда проект вышел на европейский рынок, где рост ускорился, и требовал более системного подхода в работе с медиа, стало ясно, от чего зависит вектор нашего общения с клиентом - от того, является ли он главным или выпускающим редактором, автором публикаций или новостей, маркетологом или SMM-менеджером. И главное, как конверсия из начатого общения в платящего клиента пляшет от 20 до 40 процентов.
Так мы начали собирать досье по каждой роли редакционного цеха, узнавать проблемы и вызовы, с которыми представители каждой должности сталкиваются ежедневно, приходить к решениям, за которые каждая из ролей была готова заплатить.
Что мы сделали
- В течение двух месяцев провели более 100 интервью с сотрудниками редакций популярных медиа. Все сотрудники были разбиты по должностям - их оказалось 12. Каждой роли задавался уникальный пул вопросов, обязательно лично и всегда очень тщательно, чтобы зафиксировать любую головную боль, которая была у человека.
- Всех пользователей системы (около 2000 сотрудников редакций посещают нашу систему ежедневно) пропустили через форму на сайте, которая запрашивала его должность.
- Сделали эту форму обязательной при регистрации.
- Построили аналитику на основании того, какие отчеты и фичи системы использует каждая из ролей.
- На выходе получили очень точный портрет проблем и задач, которые нужно решить для каждой из ролей.
Распределение своих пользователей мы получили в таком виде:
Сама система оказалась достаточно универсальной, чтобы не быть идеальной ни для одной из ролей.
Приведу примеры вопросов, которыми мы донимали людей во время интервью. Главного редактора мы спросили о том, как для него ставится задача руководством, какие цели он, в свою очередь, ставит перед редакцией, и как он отслеживает выполнение поставленных целей.
К автору статей были следующие вопросы: анализируется ли им написанный материал после публикации и по каким показателям, в каком виде он представляет отчетность руководству, есть ли у него премия, и от чего она зависит и так далее.
Вопросы к другим респондентам задавались в том же ключе. Точные ответы удавалось получать не всегда. Но всегда получались интересные кейсы. Примером может быть то, в каком виде собственник ставит цели главному редактору, и как последний превращает полученную цель в более понятный писательскому цеху пул задач - это одни и те же цифры, но в разной подаче.
Про анализ аналитики:
Основные направления, которые мы отслеживали при использовании своей системы:
- Как часто каждая из ролей должна использовать нашу систему в течение дня (выпускающий, шеф-редактор) и в течение недели (главный редактор, менеджер по рекламе).
- Какие отчеты наиболее востребованы у каждого сотрудника.
- Какие показатели эффективности публикаций интересны каждой из ролей (автор смотрит на дочитываемость материала; выпускающий смотрит CTR заголовка; SMM-менеджер - количество лайков, которое статья собрала в разных соцсетях).
- За какой период просматриваются данные отчеты (как оказалось, эффективность авторов отслеживают на промежутке недели или месяца, но редко в течение дня, хотя данную возможность мы часто озвучивали в процессе продажи).
- Поиски, сортировки данных, фильтры публикаций по рубрикам, авторам, дате публикации нужны только нескольким людям в редакции, а не каждому, кто видит их в интерфейсе системы.
- Воронки движения в системе, когорты возвращаемости - все стандартные точки зрения на данные были также нами разделены для каждой из ролей.
На выходе мы получили цифровой портрет пользователя редакции: что, когда и зачем ему нужно, каким является его распорядок дня, и какие данные ему нужны в каждый момент времени.
Процент зарегистрированных пользователей, которые посещают систему ежедневно
Что тут скажешь, даже топовый показатель в 65% активных выпускающих редакторов очень далек от ожидаемых 100%. Маркетолог и SMM, на которых мы часто делали ставку на этапе триального периода проектов, оказались нашим слабым местом.
Старт коммуникации с этими ребятами сразу снижал наши шансы на начало полноценного сотрудничества. Аналитики, которые всегда были нашими активными тестировщиками в начале работы с проектом, затухали в дальнейшем и уходили в свои более настраиваемые системы (Google Analytics, «Яндекс. Метрика»).
Ролевая аналитика
Ранее мы говорили о системе редакционной аналитики, как о простом инструменте, который понятен гуманитариям и отвечает на важные для них вопросы. Сейчас же мы поняли насколько сильно мы ошибались. Вопросы и задачи у всех разные. И простой инструмент - это тот, который решает только твои задачи, а не всего твоего коллектива. Простой инструмент - тот, который позволяет на одном экране, без использования фильтров, кнопок и сортировок, ответить на любой необходимый вопрос в нужный момент времени.
Так мы пришли к необходимости создать ролевые дашборды, где есть ответы только шеф-редактора или только главного редактора. Например, главному редактору редко нужна информация с воронкой дочитываемости публикации. Он даже не всегда успевает отреагировать на плохо читаемую в течение дня статью, но завтра он хотел бы видеть данную информацию на утренней планерке, чтобы использовать ее для обучения команды. И не обязательно в виде воронки, ему может быть достаточно маркера «плохо» или «хорошо». А детали - это задача исполнителя, автора, который еще вчера должен был среагировать на эти показатели. Ниже представлено несколько примеров ролевых отчетов.
Шеф-редактор
Одной из задач данной роли является наполнение главной страницы кликабельными публикациями. Несмотря на часто повторяемый тезис о том, что главная страница умирает, у большинства наших клиентов она продолжает собирать не менее 30-40% входящего трафика.
И размещение на главной странице публикаций с высоким CTR - важная составляющая работы с лояльной аудиторией, глубина посещения которой растет с ростом общего CTR главной страницы. Обычно наполнение главной не отдают на сторону рекомендательных систем (таких как Relap.io), а продолжают делать руками. Если же в редакции нет шефа или выпускающего, то эту задачу могут выполнять любые другие сотрудники редакции. Одна задача - один экран:
Выпускающий, шеф, главный редактор
Мы увидели это решение таким:
Автор публикаций
Авторы сами следят за своими публикациями, и могут вносить правки в результат своей работы на основании первых собранных цифр. Несмотря на то, что многие уже привыкли, не всегда корректно оценивать популярность публикации только просмотрами. Обычно смотрят как на читаемость публикации, так и на ее социальный эффект. Мы постарались собрать в одном экране ответы на те вопросы, которыми задаются авторы:
Про универсальность
На текущий момент Google Analytics проделал колоссальную работу. Он дал тот инструмент, в котором каждый из нас вырос, и при этом постоянно учится решать свои рабочие задачи. Но эта универсальность имеет свои минусы:
- Ее нужно освоить.
- До ответа на свои вопросы всегда есть расстояние в несколько кликов.
- Там могут быть не учтены те данные, которые нужны в работе.
Про планы
Если вспомнить тренд на упрощение (покупки в один клик или даже без клика - просто по входу в магазин), то в системах аналитики должно происходить то же самое. Ты не должен махать руками у обочины каждый раз, когда тебе нужно поймать ответы на нужные вопросы. Достаточно открыть интерфейс в нужном тебе устройстве, и ты сразу увидишь, как система уже заказала твои любимые блюда.
Естественно, дальше больше: мы идем к тому, чтобы такие вопросы просто не нужно было задавать. В нужный момент ответы будут приходить сами, просто вычисляя, что сейчас они вам нужны. Но об этом мы расскажем в следующий раз.
