В прошлом посте про события мы разобрали то, как их отправлять из приложения, а в конце я в двух словах рассказал про такой инструмент как RudderStack. Но эта тема заслуживает своего поста, потому что позволяет значительно улучшить архитектуру (не только как инструмент, но и как концепт).
В общем продакты, маркетологи и другие бизнесовые ребята, будут постоянно хотеть данных для аналитики, воронок (посмотрел страницу => оформил заказ), возможности показывать баннеры и делать рассылки. Для всего этого добра нужны разные сервисы и каждый из этих сервисов ожидает на вход события из вашей системы, для того, чтобы по этим событиям можно было формировать сегменты пользователей и реализовывать триггеры.
При этом у каждого такого сервиса свой формат событий, свои обязательные поля, свои ограничения и свои способы интеграции. Один хочет
userId, другой работает только с email, третий требует отдельные “e-commerce события”, четвертый не умеет принимать серверные события и живёт только в браузере.В начале это не кажется большой проблемой. Добавили один сервис, потом второй, потом оказалось, что надо переехать на другой сервис не забыв добавив туда существующие события и пользователей. Ну и так далее, управление всем этим добром и интеграция становится проблемой. Особенно учитывая, что у многих сервисов нет нормальных sdk (особенно в рф). Все это начинает напрягать разработчиков и делаться в последнюю очередь. Короче не хотелось бы этим заниматься.
CDP (Customer Data Platform) решает эту проблему архитектурно: вы перестаёте интегрировать приложение с каждым сервисом напрямую и вместо этого делаете один стабильный канал событий. Приложение отправляет события в CDP, а уже CDP маршрутизирует их в нужные инструменты: аналитику, CRM, рассылки, рекламные кабинеты, data warehouse, и так далее.
Но дело не только в этом. CDP это не просто медиатор. CDP формирует связку между пользователями и всеми действиями, которые мы отслеживаем. Все это хранится в каком-то warehouse. В нашем случае rudderstack подключен к clickhouse. К которому в свою очередь подключены, например, аналитики, через yandex datalens.
Кто-то мог бы сказать, а чем это лучше какого-нибудь n8n? В отличие от универсальных коннекторов различных сервисов, CDP заточен конкретно под продуктово-маркетинговые задачи. Он встраивается на сайт как универсальная аналитика на фронтенд, бекенд и самостоятельно занимается трекингом, установкой visitor_id связью с user_id. А дальше все это отправляется во внешние системы по заранее сформированному маппингу (с возможностью кастомизации). То есть вы не просто сами настраиваете пересылку, а она уже спроектирована под конкретные связки. Поэтому в большинстве случаев достаточно просто добавить нужный сервис и дальше все работает автоматически.
Пример. Существует спека Ecomerce Events (https://www.rudderstack.com/docs/event-spec/ecommerce-events-spec/) описывающая события, которые понимает примерно одинаково большинство систем. Если отправлять эти события так как описано внутрь CDP, то она сама распознает их и сделает правильный маппинг во внешние системы (https://www.rudderstack.com/docs/destinations/streaming-destinations/yandex-metrica/)
p.s. А как в ваших проектах решается эта задача?
Telegram | YouTube | Сообщество