Как создать план отслеживания?

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

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

Преимущества создания плана отслеживания

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

• Соберите новое событие, свойство события или свойство объекта
• Изменить название события
• Изменить имя или тип данных свойства
• Остановить отслеживание события или свойства

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

• Избыточность данных: сбор одних и тех же данных несколько раз.
• Неточность данных: сбор противоречивых или неверных данных
• Беспорядок данных: сочетание избыточных и неточных данных

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

Простота реализации

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

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

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

Краткий справочник

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

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

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

Обмен знаниями

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

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

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

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

Достаточно было сказано о содержании плана слежения; теперь давайте сосредоточимся на том, как должен выглядеть план отслеживания.

Окончательный шаблон плана отслеживания

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

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

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

1. События
2. Свойства события
3. Свойства пользователя
4. Свойства организации

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

События

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

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

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

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

Перечислите события

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

Лист содержит примеры событий Signed Up и На данный момент игнорируйте свойства и просто сосредоточьтесь на событиях.

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

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

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

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

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

Если вам все еще нужны идеи для отслеживания, ознакомьтесь с руководствами по внедрению Amplitude с предлагаемой таксономией для электронной коммерции, финансовых технологий, потокового мультимедиа, печатных СМИ и B2B SaaS. Даже если ваш продукт относится к другой отрасли, вы можете черпать вдохновение из этих или других отраслевых таксономий.

Добавьте источник и владельца

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

Как вы можете видеть в шаблоне плана отслеживания, Signed Up — это событие на стороне клиента, поскольку оно происходит на клиенте, как только форма регистрации успешно отправлена.

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

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

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

Рекомендация: вводите данные из внешних источников на втором этапе инструментирования.

Свойства события

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

Добавьте свойства для каждого события

Беритесь за одно событие за раз и думайте о свойствах, которые дают вам больше контекста о событии.

Полезно помнить, что пользователь выполняет событие Signed Up только один раз (во время создания учетной записи), и именно тогда генерируется уникальный идентификатор user_id .Если свойства группы применимы к вашему продукту, идентификатор группы Organization_id также генерируется, когда пользователь регистрирует новую учетную запись. Если пользователю предлагается присоединиться к существующей организации , для этого пользователя не создается новый идентификаторorganization_id.

Помимо идентификаторов, сгенерированных системой, Signed Up содержит свойство для каждой части информации, полученной от пользователя, когда происходит это событие (first_name, last_name, электронная почта и т. д.) .

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

Интересное примечание: поэтому эти свойства также действуют как свойства пользователя и добавляются на листе свойств пользователя .

Другие события, такие как Project Created , могут выполняться несколько раз, и свойства, связанные с событием, должны быть ограничены только теми, которые предоставляют контекст об одном появлении этого события.

Помимо идентификатора проекта (project_id) и метки времени (project_created_at), свойства project_name и project_user_count предоставляют дополнительную информацию каждый раз, когда создается проект (выполняется событие Project Created ).

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

Укажите типы данных и ожидаемые значения

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

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

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

Упомяните направления

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

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

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

Свойства пользователя

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

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

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

Обратите внимание, что значение свойства is_email_verified изменяется на false при изменении адреса электронной почты, а после подтверждения нового адреса is_email_verified возвращается к значению true.

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

Идите вперед и перечислите все свойства пользователя, их типы данных, ожидаемые значения и места назначения на листе с надписью « Свойства пользователя».

Свойства организации

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

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

Как вы, возможно, уже знаете, групповые свойства являются общими для продуктов B2B SaaS, где пользователь является частью учетной записи или организации с несколькими пользователями. Имя учетной записи (organization_name) и ее план подписки (subscription_plan_name) — общие свойства группы, применимые к большинству компаний.

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

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

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

Начать отслеживание

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

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

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

Удачного отслеживания!