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

Существует несколько различных технологий (CDI, CDP, ELT), которые могут быть использованы для сбора поведенческих данных, а также множество инструментов (Segment, Rudderstack, Airbyte и др.), возможности которых охватывают несколько технологий.

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

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

Зачем собирать поведенческие данные?

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

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

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

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

Откуда берутся поведенческие данные? 

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

Первичные источники данных

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

Если ваш продукт создан с использованием no-code инструментов, у вас не будет первичного источника поведенческих данных — предполагается, что no-code инструменты будут предоставлять вам поведенческие данные (через веб-хуки или интеграции с инструментами сбора данных).  

Для сбора данных из первичных источников вы можете использовать клиентские и серверные SDK или API, предоставляемые инструментами сбора данных. 

Вторичные источники данных

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

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

Клиенты также взаимодействуют с внешними инструментами, которые, очевидно, не являются частью основного опыта использования продукта, но считаются неотъемлемыми точками соприкосновения. Открытие тикета поддержки через Zendesk, оставление отзыва через Typeform, открытие электронного письма, отправленного через Intercom, или участие в рекламе на Facebook — все это взаимодействия, которые помогают изучить процесс путешествия клиента. 

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

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

Технологии и инструменты для сбора поведенческих данных

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

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

Разница между CDI и CDP

CDI или Customer Data Infrastructure (инфраструктура клиентских данных) — это менее распространенный термин, который часто путают с CDP или Customer Data Platform (платформа клиентских данных)

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

CDI — это отдельное решение, которое может существовать без CDP, в то время как CDP продается в качестве аддона некоторыми вендорами CDI.

Ключевые аспекты CDI следующие:

  1. CDI (Customer Data Infrastructure) предназначена для сбора поведенческих данных из первичных или данных из оригинальных (first-party) источников, но некоторые решения также поддерживают ряд вторичных источников данных (сторонние инструменты).

  2. Данные обычно синхронизируются с облачным хранилищем данных, таким как Snowflake, BigQuery или Redshift, но большинство CDI-решений имеют возможность синхронизировать данные и со сторонними инструментами.

  3. Все поставщики CDI предлагают различные SDK и API для сбора данных.

  4. В некоторых CDI-решениях сохраняется копия данных, иногда это опция по выбору, а бывает, что ее нет. 

Основные функциональные способности CDP включают разрешение идентификации и возможность для пользователей создавать и синхронизировать аудитории с внешними инструментами с помощью интерфейса "перетаскивания" (без написания SQL). 

Инструменты CDI и CDP

Connections и Personas — это продукты CDI и CDP от Segment соответственно. mParticle использует несколько иной подход — он предлагает возможности CDI вместе с разрешением идентификации в редакции Standard, в то время как формирование аудитории доступно в редакции Premium. Segment и mParticle поддерживают хранилища данных и множество сторонних инструментов в качестве пунктов назначения, а также хранят копии ваших данных, к которым можно получить доступ позже, если это необходимо. 

RudderStack Event Stream и Jitsu — это решения CDI с открытым исходным кодом, позиционируемые как альтернатива Segment Connections. Оба продукта поддерживают хранилища и инструменты сторонних производителей, но RudderStack предлагает более расширенный каталог направлений.

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

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

Ссылки ниже приведут вас к интеграционным каталогам соответствующих инструментов: 

Инструменты ELT

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

ELT-инструменты не хранят никаких данных и не поддерживают сторонние инструменты в качестве пунктов назначения. 

Airbyte — это ELT-инструмент с открытым исходным кодом, с растущей библиотекой коннекторов и бурно развивающимся сообществом участников. Airbyte предлагает исходники коннекторов с 150+ инструментами, такими как Zendesk, Intercom, Stripe, Typeform и Facebook Ads, многие из которых генерируют данные о событиях. Airbyte также предлагает Connector Development Kit (отладочный комплект для коннектора) (CDK), который вы можете использовать при построении интеграций, поддерживаемых членами сообщества Airbyte.

Другие вендоры ELT включают Fivetran, Stitch и Meltano (также с открытым исходным кодом). 

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

При рассмотрении вопроса об использовании ELT-инструмента или исходной интеграции CDI-инструмента для извлечения данных из стороннего инструмента следует учитывать следующее:

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

  • ELT является лучшим в своем классе для сбора всех типов данных, включая поведенческие данные из вторичных источников — сторонних инструментов, которые обеспечивают различные виды клиентского опыта.

Инструменты продуктовой аналитики 

Amplitude, Mixpanel, Indicative, Heap и PostHog (с открытым исходным кодом) — это специально разработанные инструменты для анализа поведенческих данных. Одновременно с этим все они предлагают SDK и API для сбора данных из ваших основных (оригинальных) источников данных. 

Инструменты продуктовой аналитики по своей сути хранят копию ваших данных и позволяют экспортировать их (обычно за дополнительную плату). Вы также можете использовать интеграцию Airbyte с Amplitude, Mixpanel или PostHog для экспорта данных из этих инструментов в место назначения, поддерживаемое Airbyte. 

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

Лучшая практика предусматривает создание в компаниях хранилища данных, для содержания в нем копий всей собираемой информации. Использование специально разработанных инструментов сбора данных (CDI и ELT) более эффективно, это предотвращает привязку к поставщику и просто имеет смысл.

Кастомные решения для трекинга (отслеживания)

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

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

Заключение

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

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


Завтра пройдет открытое занятие «Аналитика ключевых метрик компании с использованием dbt Metrics». На уроке вы узнаете:

  • Что такое семантический слой и в чем разница между метрикой и витриной данных.

  • О правилах декларативной конфигурации метрик в yaml.

  • Как использовать продвинутые возможности dbt Metrics (derived metrics, secondary calculations).

Записаться на открытый урок можно на странице онлайн-курса "Data Warehouse Analyst".

Комментарии (0)