Рекомендации по созданию или развитию системы отслеживания Analytics

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

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

И зачем он тебе нужен? Что ж, без плана отслеживания очень сложно понять, какие события вы фиксируете в своем продукте и что они означают. Это также помогает гарантировать, что данные, которые вы собираете, согласуются между вашими источниками (например, iOS, Android, Интернет, серверная часть) и дает потребителям данных понимание того, какие данные они могут исследовать для анализа с помощью таких инструментов, как Amplitude, или непосредственно в вашем хранилище данных. .

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

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

Начните со своих целей и показателей

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

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

Не забывайте свойства событий и пользователей

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

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

Установите последовательность и будьте проще

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

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

Наряду с вашими соглашениями об именах определите структуру для ваших событий, например, «Object-Action». Сначала выберите свои объекты (например, «Песня»), затем определите действия, которые пользователи будут выполнять над этим объектом (например, «Воспроизведение», «Приостановлено»), чтобы создать такие события, как «Песня воспроизведена» или «Песня приостановлена». И, наконец, договоритесь о времени (например, «Song Played» или «Song Play»).

Определите, где фиксировать события

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

Сбор событий на сервере более надежен, и мы рекомендуем всегда фиксировать критически важные события там. Хотя отслеживание на стороне сервера несколько ограничено меньшим доступом к информации о пользователе (например, IP-адресу, пользовательскому агенту, рефереру и параметрам UTM), оно гораздо более надежно и гибко.

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

Держите отдельные среды разработки и производства

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

Обеспечить соблюдение плана отслеживания

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

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

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

Назначить владельца

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

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

Документируйте все

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

Документирование вручную может быть утомительным и легко забываемым, но мы настоятельно рекомендуем документировать как минимум следующее:

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

Многие компании используют страницы Google Sheets, Notion или Confluence для управления этими документами. Благодаря функциям управления данными Amplitude все это делается за вас автоматически, обеспечивая синхронизацию всей компании с аналитикой.

Получите лучшие практики с Amplitude

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

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