Кейс из России: Как команда сервиса редакционной аналитики 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, у некоторых Chartbeat), но только один человек отвечает за реакцию на то, что в этом экране происходит: что популярно прямо сейчас, за счет каких источников формируется эта популярность.

Мы увидели это решение таким:
Автор публикаций


Авторы сами следят за своими публикациями, и могут вносить правки в результат своей работы на основании первых собранных цифр. Несмотря на то, что многие уже привыкли, не всегда корректно оценивать популярность публикации только просмотрами. Обычно смотрят как на читаемость публикации, так и на её социальный эффект. Мы постарались собрать в одном экране ответы на те вопросы, которыми задаются авторы: Про универсальность

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

Её нужно освоить.
До ответа на свои вопросы всегда есть расстояние в несколько кликов.
Там могут быть не учтены те данные, которые нужны в работе.

Про планы

Если вспомнить тренд на упрощение (покупки в один клик или даже без клика — просто по входу в магазин), то в системах аналитики должно происходить то же самое. Ты не должен махать руками у обочины каждый раз, когда тебе нужно поймать ответы на нужные вопросы. Достаточно открыть интерфейс в нужном тебе устройстве, и ты сразу увидишь, как система уже заказала твои любимые блюда.

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