Как превратить отслеживание аналитики в непрерывный совместный процесс

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

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

Аналитика затрагивает всех в компании, основанной на данных

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

Все ключевые заинтересованные стороны, участвующие в отслеживании аналитики, привнесут в историю свои уникальные идеи и опыт — здоровое сочетание знаний в предметной области и технических ноу-хау. Мы получили:

• Руководители / руководство
• Менеджеры по продукту
• Аналитики/группы данных
• Разработчики

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

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

Как эти команды (должны) сотрудничать друг с другом в области аналитики.

Руководители / руководство

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

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

Основные принципы совместной работы этой команды:

• Руководство должно приложить все усилия, чтобы вдохновить на сотрудничество во всей организации и развивать культуру, которая понимает ценность принятия решений на основе данных.
• Отмечайте успехи, связанные с принятием решений на основе данных.
• Грубо говоря, если ваш руководитель не заботится о качественном отслеживании аналитики, то зачем вам? ‍

Менеджеры по продукту

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

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

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

Основные принципы совместной работы этой команды:

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

Аналитики

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

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

Частью процесса сотрудничества аналитиков является предоставление другим командам возможности максимально самообслуживаться. Основным примером этого может быть работа с менеджерами по продукту и маркетологами для создания предопределенных запросов в таком инструменте, как Tableau, чтобы можно было ответить на наиболее часто задаваемые вопросы одним нажатием кнопки. Команды по продуктам и маркетингу также могут использовать платформу цифровой аналитики самообслуживания, такую ​​как Amplitude, для самостоятельного построения диаграмм и анализа поведения клиентов.

Основные принципы совместной работы этой команды:

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

Разработчики

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

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

Хорошие разработчики гораздо чаще заботятся о том, как работают продукты, которые они создают, — они также лучше, чем кто-либо, знают, как работает продукт на самом деле, поэтому лучше всего подготовлены для реализации плана отслеживания наиболее эффективным способом.

Основные принципы совместной работы этой команды:

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

Содействие сотрудничеству в области отслеживания аналитики

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

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

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

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

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

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

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

Figma: инструмент, который отлично демонстрирует беспрепятственное сотрудничество между командами; Figma позволяет дизайнерам продуктов передавать разработчикам прототипы, которые четко показывают, как все элементы сочетаются друг с другом. Совет: используйте планировщик событий Amplitude в Figma.

Amplitude поможет вам в сотрудничестве

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

Лучшие процессы — это те, которые вы даже не замечаете: у нас есть инструменты для разработчиков, чтобы никто не нарушал рабочий процесс, что позволяет инженерам легко и точно реализовывать отслеживание аналитики с помощью безопасных для типов SDK с открытым исходным кодом, CLI и CI/CD. интеграция.

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