Кому действительно должен принадлежать ваш план отслеживания?

Примечание редактора: эта статья была первоначально опубликована в блоге Iteratively 11 января 2021 года.

«Данные — это командный вид спорта» — это то, во что мы твердо верим и о чем часто говорим в Amplitude. Планы отслеживания Analytics ничем не отличаются — планы отслеживания (и их инструменты) по своей природе являются совместными. Они работают лучше всего, когда соответствующие команды собираются вместе.

Давайте возьмем пример выпуска новой функции. Команда разработчиков определила цели и показатели для этой новой функции и будет иметь представление о том, какое отслеживание событий необходимо для измерения этих показателей. Команды iOS, Android и веб-разработчики несут ответственность за инструментирование (и, в идеале, тестирование) этих событий в коде, и у них будет мнение о том, что возможно. Аналитик или инженер-аналитик отвечает за моделирование данных и заботится об их структуре, и у вас может быть несколько команд, ответственных за создание отчетов и анализ данных в нескольких инструментах. Короче говоря, в компании, управляемой данными, в аналитику вовлечены почти все.

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

Если он принадлежит всем, он никому не принадлежит

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

Мы разговаривали со многими компаниями, которые хотят (пере)создать процессы, связанные с отслеживанием аналитики. Обычно это вращается вокруг электронной таблицы или страницы Confluence или Notion. Хотя в основном это выполняется вручную и нет возможности реализовать план отслеживания в коде, он оказывается полезным в начале и заставляет команды больше думать об отслеживании событий.

Однако через несколько месяцев страница Notion или Google Spreadsheet устаревают: отслеживание последней версии было задокументировано только в истории Jira, а для нескольких других выпусков функций теперь неясно, было ли реализовано отслеживание или нет. Никто не берет на себя ответственность поддерживать план отслеживания в актуальном состоянии.

Итак, как вы можете изменить это к лучшему и кто лучше всего может владеть вашим отслеживанием аналитики?

Начните с того, что поставьте аналитику на передний план

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

• ПМ работает над релизом
• Релиз происходит
• Генеральный директор спрашивает премьер-министра, как это работает
• Премьер-министр: «Позвольте мне спросить команду данных»
• Команда данных: «Вы никогда не привлекали нас — по этой функции нет данных».
• Премьер-министр возвращается к генеральному директору без ответов
• Команда данных и PM в растерянности

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

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

Что мы узнали из более чем 400 интервью со специалистами по данным и продуктам

За два года мы опросили более 400 менеджеров по продуктам, специалистов по работе с данными и инженеров. Мы видели некоторые вещи.

Конечно, ваш план отслеживания и процессы, связанные с ним, уникальны для вашего бизнеса, структуры команды и вертикали (и, вероятно, поэтому так трудно сделать все правильно). План отслеживания для компании электронной коммерции будет сильно отличаться от плана отслеживания для компании B2B SaaS. В них участвуют разные заинтересованные стороны, и они решают совершенно разные реальности. Чаще всего мы можем разбить то, что мы видели, по размеру компании.

Стартапы

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

МСП

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

Предприятия

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

Мы видели различные степени успеха этих типов установок. Итак, что, по нашему мнению, работает лучше всего?

Что работает: команда разработчиков — конечный владелец

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

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

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

Чтобы продуктовые команды успешно владели этим, вам нужен четкий процесс:

• Имейте четкие критерии успеха как для качественных, так и для количественных показателей как часть каждой пользовательской истории. Они должны быть определены менеджером по проектам и согласованы с группой данных или аналитиками.
• Отсутствует отслеживание? Сбой сборки. Понятие «сделано» должно развиваться, чтобы включить отслеживание аналитики в каждый выпуск. Это не означает блокировку выпусков прямо перед запуском, это означает внедрение процесса, который с самого начала включает в себя отслеживание соображений.
• Сотрудничество является ключевым. В то время как PM будет владеть спецификацией отслеживания событий, группа данных или аналитики должны быть доступны, чтобы вмешаться и помочь определить детали того, что следует отслеживать.

Предоставьте своим менеджерам по продуктам возможность взять на себя ответственность

Для некоторых продакт-менеджеров владение планом отслеживания является для них естественным. Они хотят контроля и имеют опыт. И они также не боятся просить о помощи, когда они в ней нуждаются. Но это не естественно для всех менеджеров проектов.

Во-первых, необходимо изменить культуру: отмечайте производительность и успех новой функции или выпуска продукта, а не факт их выпуска! Удивительно, но для многих по-прежнему хвалят доставку, а не то, работает продукт или нет.

Итак, как вы даете возможность вашей продуктовой команде владеть планом отслеживания? Это не исчерпывающий список, но, надеюсь, с него можно начать:

• Регулярное обучение . Правильное отслеживание событий — это не только наука, но и искусство (т. е. это непросто), поэтому убедитесь, что ваша команда наделена знаниями, необходимыми для комфортного управления. Обучение может проходить в формате обеда и обучения, семинаров или индивидуальных занятий (не забудьте записать свои занятия для будущих наймов).
• Рабочие часы : мы добились больших успехов, когда группы данных проводят обычные рабочие часы для других команд, чтобы использовать опыт и знания команды данных. Убедитесь, что у команд подготовлена ​​повестка дня или конкретные вопросы, чтобы избежать превращения собрания в «в стиле службы поддержки».
• Четкий процесс и контрольные точки: мы не можем не подчеркнуть важность определенного процесса. Убедитесь, что у вас есть четкий процесс, о котором все знают, понимают и которому следуют, и включите регулярные точки обзора для обеспечения качества, как обзоры кода и запросы на слияние в разработке программного обеспечения.
• Внедрить аналитика : это, конечно, не всегда вариант, но мы видели, как успешные команды внедряли аналитика данных в команду продукта либо на полставки, либо на неполный рабочий день, чтобы самостоятельно отслеживать аналитику и помогать менеджерам по проектам в исследовании и анализе данных.
• Самостоятельная аналитика: мы считаем, что лучше всего предоставить менеджерам по проектам и всем остальным в организации возможность легко просматривать наборы данных и быстро получать ответы на вопросы. Amplitude отлично подходит для этого и обеспечивает высокий уровень грамотности данных в вашей компании.

Напоминание: хорошим менеджерам не обязательно знать SQL

Зачем беспокоиться об отслеживании событий, если вы все равно не можете самостоятельно изучить данные? Чтобы расширить последний пункт выше, мы видели компании с центральными группами данных, которые владеют всей отчетностью и анализом данных. У него есть свои плюсы, но, по нашему опыту, он может ограничивать продакт-менеджеров и других, и они будут меньше заботиться об отслеживании аналитики или качестве данных.

Помните, что предоставление менеджерам проектов и другим лицам доступа к Redash или другим инструментам на основе SQL не равносильно предоставлению менеджерам проектов возможности самообслуживания. Не ожидайте, что ваши продакт-менеджеры будут знать (или изучать) SQL. Это не их работа. Вместо этого предоставьте им простой в использовании пользовательский интерфейс и большое количество обучения работе с инструментом и наборами данных. Конечно, знание SQL имеет свои очевидные преимущества, и если вы сможете найти или обучить таланты в компании (например, продукт, маркетинг, успех клиентов и т. д.), вы сможете заставить его работать, но оно имеет свои очевидные недостатки и ограничения.

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

Амплитуда вам в помощь

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

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