Event model для продаж и поддержки: какие события собирать

Однажды мне позвонил знакомый — владелец интернет-магазина электроники в Алматы. Голос был расстроенным: «Мы потратили полгода на внедрение CRM, но до сих пор не понимаем, почему клиенты уходят. У нас есть данные о заказах, но это верхушка айсберга. Что происходит до покупки? Почему человек положил товар в корзину и исчез? Куда он потом делся?»

Я задал ему простой вопрос: «А какие события вы собираете с сайта?» Пауза. «Ну... Google Analytics стоит. Там вроде всё видно.» Я вздохнул — история повторялась в сотый раз.

Проблема в том, что Google Analytics показывает агрегированные метрики: сколько людей зашло на страницу, сколько процентов ушло. Но он не отвечает на вопрос: «Что делал конкретный Асланбек Сериков из Караганды за три дня до того, как написал гневный отзыв?» А именно такие вопросы важны для продаж и поддержки.

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

Что такое event model и зачем она нужна бизнесу

Если упростить до предела, event model — это договорённость о том, какие действия клиента мы фиксируем и в каком формате храним. Не просто «пользователь был на сайте», а структурированные записи: кто, что сделал, когда, в каком контексте.

Представьте себе детектива, который расследует преступление. Ему нужны не общие слова «что-то произошло», а точная хронология событий: в 14:32 подозреваемый вошёл в здание, в 14:35 поднялся на третий этаж, в 14:38 вышел через чёрный ход. Event model для бизнеса — то же самое, только «преступление» — это уход клиента к конкуренту, а «подозреваемый» — цепочка его действий, которая к этому привела.

Без event model вы работаете вслепую. С ней — понимаете, что именно привело к покупке (или отказу), можете воспроизвести успешные паттерны и предотвратить проблемные.

Я часто слышу возражение: «У нас и так данных много, зачем ещё?» Дело не в количестве, а в связности. Когда данные разбросаны по Google Analytics, CRM, телефонии и чат-платформе — они бесполезны. Event model объединяет их вокруг одного клиента, создавая цельную историю.

О том, как построить единый профиль клиента, мы подробно писали в статье Единый профиль клиента Customer 360: как собрать. Сегодня сфокусируемся на событийной модели — фундаменте для такого профиля.

Анатомия события: из чего состоит правильная запись

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

Вот как выглядит реальное событие в JSON-формате:

Несколько моментов, на которые стоит обратить внимание. И user_id, и anonymous_id в одной записи — это позволяет связать поведение до и после регистрации. В properties лежит вся бизнес-логика: что за товар, какая цена, откуда пришёл. А context содержит техническую информацию для сегментации (например, отдельная аналитика по мобильным пользователям).

Важно договориться о naming convention заранее. Я видел проекты, где одно и то же событие называлось add_to_cart, addToCart, cart_item_added, product_added_to_basket в разных частях системы. Это кошмар для аналитики. Выберите один стиль (рекомендую snake_case с глаголом в прошедшем времени: product_viewed, order_placed, call_ended) и придерживайтесь его везде.

События с сайта: что реально важно, а что шум

Начнём с самого популярного источника — веб-сайта. Здесь легко впасть в две крайности: собирать вообще всё (включая каждое движение мыши) или ограничиться базовыми page views. Оба подхода ошибочны.

Расскажу историю. Один казахстанский e-commerce проект решил «собирать все данные, потом разберёмся». За три месяца накопили 2 терабайта событий. Когда пришло время анализировать — оказалось, что 95% данных бесполезны (события hover_over_element, scroll_10_percent, mouse_moved), а нужных для бизнеса событий толком нет. Потратили ещё два месяца на переделку.

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

Важные события добавляют контекст. search_performed показывает, что человек искал (и нашёл ли). filter_applied — какие критерии важны для покупателя. Это ценно для персонализации, но бизнес не рухнет без этих данных.

Шум — события, которые генерируют огромный объём данных с минимальной пользой. Да, heatmaps бывают полезны, но для этого есть специализированные инструменты (Hotjar, Clarity). Тащить scroll_percentage в CRM — пустая трата ресурсов.

События из продукта: SaaS, приложения, сервисы

Если у вас не просто сайт, а продукт — мобильное приложение, SaaS-платформа, личный кабинет — события из него критически важны. Именно они показывают, как клиент на самом деле использует то, за что заплатил.

Приведу пример из практики. Казахстанский стартап — платформа для бухгалтерского учёта малого бизнеса. Продажи шли хорошо, но через 3 месяца отток достигал 40%. Почему? Без product analytics было непонятно.

Когда внедрили event model, картина прояснилась. Клиенты, которые уходили, имели характерный паттерн: регистрировались, создавали одну-две накладные, никогда не подключали интеграцию с банком — и пропадали. А клиенты, которые оставались, в первую неделю обязательно делали три вещи: подключали банк, импортировали контрагентов и создавали хотя бы один отчёт.

Это знание позволило перестроить онбординг: теперь новым пользователям активно помогают сделать эти три действия в первые 7 дней. Отток снизился до 22%.

Главный принцип: события должны отражать ценность для клиента. Не «кнопка нажата», а «отчёт сгенерирован». Не «экран открыт», а «интеграция подключена». Простой тест: это действие приближает клиента к получению ценности от продукта? Если да — собирайте.

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

О том, как использовать такие сигналы для предсказания оттока, читайте в статье Churn prediction: прогноз оттока клиентов и удержание.

События из чатов и мессенджеров: диалоги как данные

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

Важно понимать: мы не предлагаем хранить каждое сообщение в event model (это вопрос другой системы — диалогового хранилища). Мы говорим о событиях, которые можно извлечь из диалогов.

Семантические события — это следующий уровень. С помощью AI (NLP-моделей) можно автоматически извлекать из текста диалога структурированную информацию. Клиент написал «Вчера заказал iPhone, а сегодня увидел, что у Sulpak дешевле на 20 тысяч» — это не просто сообщение, это три события: intent_detected (жалоба на цену), product_mentioned (iPhone), competitor_mentioned (Sulpak).

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

Подробнее о том, как анализировать настроения клиентов в реальном времени, читайте в статье Sentiment analysis в CRM: мониторинг удовлетворённости в реальном времени.

События из звонков: телефония всё ещё актуальна

Несмотря на рост мессенджеров, телефон остаётся важным каналом — особенно в B2B и для сложных продуктов. Звонок — это концентрат информации: за 5 минут клиент скажет больше, чем за 20 сообщений в чате.

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

Особенно ценно событие call_transcribed в связке с AI-анализом. Современные системы speech analytics могут автоматически извлекать из разговора: упомянутые продукты, возражения клиента, эмоциональный тон, соблюдение скрипта оператором.

Пример из практики. Страховая компания в Казахстане внедрила автоматический анализ звонков. Система выявила, что операторы, которые в первые 30 секунд упоминают слово «защита» (а не «страховка»), имеют конверсию на 15% выше. Это знание невозможно получить без event model на уровне содержания звонков.

О речевой аналитике подробнее читайте в статье Речевая аналитика: инсайты из звонков.

Архитектура сбора событий: как всё это связать

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

Есть два основных подхода: централизованный и федеративный. Расскажу о плюсах и минусах каждого.

Мой совет: если у вас до 5 источников событий — начинайте с федеративной архитектуры. Webhooks и прямые API-интеграции быстро решат задачу. Когда источников станет больше или появится потребность в real-time обработке — переходите к централизованной.

Вот как выглядит типичный поток событий:

Важный момент — связывание пользователей. Один и тот же человек может прийти с анонимного визита на сайте (anonymous_id), потом зарегистрироваться (user_id), потом позвонить по телефону (phone_number). Event model должна связывать все эти идентификаторы в единый профиль.

Технически это называется identity resolution или identity stitching. Большинство современных CDP (Customer Data Platform) и продвинутых CRM умеют это делать. Если у вас такой системы нет — придётся реализовывать логику связывания вручную.

Подробнее об архитектуре интеграций читайте в статье Событийная архитектура (event-driven) для бизнеса.

Антипаттерны: как не надо строить event model

За годы работы я видел много ошибок в построении event model. Некоторые из них типичные — и вы можете их избежать.

Отдельно скажу про over-engineering. Я видел проекты, где на этапе MVP строили сложнейшую event-driven архитектуру с Kafka, schema registry, stream processing — и застревали на месяцы. Начинайте просто. Webhooks в CRM. Когда упрётесь в ограничения — усложняйте.

Практический чек-лист: с чего начать

Если вы дочитали до этого места и думаете «окей, понятно, но с чего конкретно начать?» — вот пошаговый план.

Заключение: события — это язык, на котором говорит бизнес

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

«Слушай, — сказал он, — я наконец понимаю своих клиентов. Вижу, что люди, которые смотрят больше трёх товаров в категории "смартфоны" за сессию, покупают с вероятностью 40%. А те, кто сразу идёт на страницу конкретной модели — с вероятностью 65%. Мы перестроили главную страницу, чтобы быстрее показывать конкретные модели. Конверсия выросла на 12%».

Ради этого и нужна event model. Не абстрактные графики в Google Analytics, а конкретные инсайты, которые превращаются в действия. Не «трафик вырос» или «трафик упал», а понимание, почему конкретный клиент купил или не купил.

Event model — это не просто техническая задача. Это способ перевести поведение клиентов на язык, который понимает бизнес. И чем раньше вы начнёте этот «перевод» — тем больше преимуществ получите.

Часто задаваемые вопросы

Читайте также