Что такое объекты в контексте данных о событиях?

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

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

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

• Сколько уникальных пользователей выполнили событие Campaign Sent ?
• Какие пользователи выполнили это событие?
• Каково среднее количество событий, выполненных пользовательским сегментом перед первым выполнением события Campaign Sent ?
• Какие события были выполнены пользовательским сегментом до этого события?

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

Давайте копнем глубже.

Одно событие, несколько сущностей

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

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

• Сколько аккаунтов активировано?
• Каково среднее количество пользователей для активных учетных записей?
• Сколько учетных записей содержат X или более пользователей?

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

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

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

Например, если пользователь Джон Доу создает новый проект в приложении для управления проектами, используемом организацией Acme Corp с 10 пользователями, генерируются две важные части информации:

1. Джон Доу создал новый проект: Джон Доу провел мероприятие Project Created
2. Внутри организации Acme Corp был создан новый проект: внутри организации Acme Corp состоялось мероприятие Project Created .

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

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

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

Один пользователь, несколько учетных записей

Довольно часто пользователь связан с несколькими учетными записями в контексте инструментов SaaS. Notion, ClickUp и Integromat — это несколько популярных инструментов, которые позволяют уникальному пользователю присоединяться или создавать несколько организаций или рабочих областей, каждая из которых имеет отдельную подписку.

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

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

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

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

Не просто идентификатор

Данные объекта не только помогают идентифицировать пользователя (который выполняет событие) или организацию (под которой было выполнено событие), но также предоставляют намного больше информации как о пользователе, так и об организации.

Может быть полезно классифицировать данные объекта по следующим блокам:

• Личная информация , такая как Демографические данные , такие как Персонажи, такие как отрасль, job_role и Предпочтения , такие как Данные учетной записи , такие как « Указание свойств объекта — важный шаг в процессе настройки отслеживания событий, который будет рассмотрен в следующем руководстве.

  Дальнейшие действия с сущностями и данными о событиях

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

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

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

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