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

Звонит знакомый – владелец интернет-магазина электроники в Алматы. Голос расстроенный до невозможности: «Слушай, мы потратили полгода на внедрение CRM. Работает. Данные о заказах есть. Но до сих пор не понимаем главного – почему клиенты уходят. Почему положили товар в корзину и исчезли? Что происходит между "зашёл на сайт" и "купил"? Куда они вообще деваются?»

Спрашиваю: «А какие события вы собираете с сайта?» Пауза. «Ну... Google Analytics стоит же. Там вроде всё видно.» Вздох. История повторяется в сотый раз.

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

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

«Вы не можете управлять тем, что не измеряете. Но важнее – вы не можете персонализировать то, чего не видите. Event model – это глаза вашего бизнеса на всём пути клиента.»

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

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

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

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

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

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

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

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

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

{
  "event_id": "evt_8f2a4b6c-1234-5678-9abc-def012345678",
  "timestamp": "2025-12-29T14:32:15.234Z",
  "user_id": "usr_almaty_12345",
  "anonymous_id": "anon_cookie_abc123",
  "event_name": "product_added_to_cart",
  "source": "website",
  "properties": {
    "product_id": "SKU-IPHONE15PRO-256",
    "product_name": "iPhone 15 Pro 256GB",
    "price": 599900,
    "currency": "KZT",
    "quantity": 1,
    "category": "smartphones",
    "page_url": "/products/iphone-15-pro",
    "referrer": "google_organic",
    "utm_campaign": "winter_sale_2025"
  },
  "context": {
    "device": "mobile",
    "os": "iOS 17.2",
    "browser": "Safari",
    "ip": "2.134.xxx.xxx",
    "city": "Алматы"
  }
}

Несколько моментов, на которые стоит обратить внимание. И 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 – это не просто техническая задача. Это способ перевести поведение клиентов на язык, который понимает бизнес. И чем раньше вы начнёте этот «перевод» – тем больше преимуществ получите.

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

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