Когда CRM действительно нужны данные в реальном времени

Клиент уже оплатил заказ, а через десять минут получает письмо «Вы забыли товары в корзине». Одна из возможных причин — система рассылок ещё не узнала о покупке. Исправляя такие ситуации, команда может прийти к требованию передавать все данные «в реальном времени». Но ускорение каждого потока требует ресурсов, а для разных задач допустимая задержка различается.

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

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

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

Разделите время события и время его обработки

Покупка произошла в 12:00. Магазин передал её в 12:01, CDP обработала в 12:03, сегмент обновился в 12:10, а остановка сценария сработала в 12:11. Задержка до решения составила 11 минут, хотя входной API — программный интерфейс для приёма данных от другой системы — принял запрос почти мгновенно.

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

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

Начните с момента потери смысла

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

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

Почему среднего времени недостаточно

Предположим, 990 из 1 000 событий обработаны за минуту, а десять — через два часа. Среднее время составит примерно 2,19 минуты. Такой отчёт выглядит благополучно, хотя десять клиентов получили результат слишком поздно.

Поэтому дополните среднее долей событий, уложившихся в срок, и процентилями. Процентиль показывает время, в которое укладывается заданная доля измеренных событий. Например, p95 в пять минут означает, что 95% измеренных событий обработано примерно за пять минут или быстрее; остальные могут ждать значительно дольше. Точная граница зависит от способа расчёта процентиля. Для редких, но критичных ошибок также нужна отдельная проверка максимальной давности и потерянных записей.

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

Условный расчёт стоимости ускорения

За месяц в сценарий пополнения попадают 80 тысяч клиентов. Команда считает, что переход от суточного обновления к обновлению каждые 15 минут может увеличить долю дополнительных покупок на 0,15 процентного пункта. Процентный пункт показывает разницу между двумя долями: например, рост с 5% до 5,15% равен 0,15 процентного пункта, или 0,0015 в расчёте. Ожидаемый прирост здесь — гипотеза, которую ещё предстоит проверить экспериментом.

Если эффект подтвердится, расчётное число дополнительных заказов составит 80 000 × 0,0015 = 120. Под вкладом заказа понимаем выручку после скидок и возвратов за вычетом переменных расходов — например, себестоимости товара и комиссии за оплату. При вкладе 900 рублей потенциальный дополнительный результат равен 108 тысячам рублей в месяц. Дополнительные вычисления, интеграция и сопровождение стоят условные 170 тысяч в месяц. В этих предположениях ускорение не покрывает расходы.

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

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

Как проверить пользу более свежих данных

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

Основной показатель выбирают до запуска: например, вклад от заказов на клиента за 30 дней. Дополнительно смотрят ошибочные отправки после покупки, отписки и обращения. В эксперименте нельзя намеренно задерживать обязательные запреты ради измерения выручки.

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

Выберите разные способы передачи для разных задач

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

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

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

Запишите требование так чтобы его можно было проверить

Вместо «интеграция должна быть real-time» укажите событие, начало и конец измерения, допустимую задержку, долю соблюдения, период расчёта и действие при нарушении. Условный пример: «Для новых оплаченных заказов не менее 99% запретов на напоминание применяются в течение двух минут от подтверждения оплаты; при отставании потока свыше пяти минут новые отправки сценария приостанавливаются».

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

Источники

Google. Data Processing Pipelines. The Site Reliability Workbook, 2018.