CRM-аналитика
Как задать понятные требования к качеству CRM данных
Время чтения: 6 мин
Уровень материала: Для экспертов
Содержание
Интеграция отмечена зелёным индикатором, но часть покупок появляется в рассылках только на следующий день. Или все заказы переданы, а возвраты пропущены, из-за чего отчёт завышает результат. Техническая доступность соединения ещё не показывает, достаточно ли хороши данные для решения маркетолога.
Качество данных удобно оценивать по отдельным свойствам. Свежесть показывает, насколько своевременно доступны сведения. Полнота — получены ли все ожидаемые записи. Корректность — соответствуют ли значения фактам и согласованным правилам. Например, покупка может прийти вовремя, но с неверной суммой.
Для договорённостей используют три понятия. SLI — измеряемый показатель качества, например доля покупок, обработанных за две минуты. SLO — целевое значение: допустим, не менее 99%. SLA — соглашение об уровне услуги, где закрепляют обязательства сторон и последствия нарушения. SLI расшифровывается как Service Level Indicator, SLO — Service Level Objective, SLA — Service Level Agreement. Внутренней команде и внешнему поставщику могут потребоваться разные соглашения.
Разберём, как связать эти показатели с конкретными сценариями, выбрать способ измерения и заранее определить действия при нарушениях.
Начните с решения которое зависит от данных
Для корзины важно вовремя узнать о покупке. Для отчёта о дополнительной прибыли — получить заказы и возвраты с правильными суммами. Для общего ограничения частоты — видеть актуальные отправки по всем участвующим каналам.
Запишите последствие ошибки. Если покупка задерживается, клиент может получить лишнее напоминание. Если возврат не пришёл, отчёт завысит результат. Такое описание помогает выбрать показатель и порядок реакции.
Google в рекомендациях по SLO рассматривает не только доступность и задержку, но и свежесть, корректность, качество и охват данных. [1] Для CRM эта рамка позволяет договориться о том, что действительно важно бизнес-процессу.
Измеряйте свежесть от нужной начальной точки
CDP — платформа объединения клиентских данных; профиль — связанная запись с данными клиента. Задержка от приёма события CDP до обновления профиля не включает время, проведённое в магазине и интеграции. Если бизнес ждёт остановки сценария после оплаты, измерение начинается с подтверждения оплаты в исходной системе и заканчивается применением ограничения.
Не ограничивайтесь средним. Укажите долю событий, обработанных вовремя, и контролируйте длительное отставание. Для события, которое ещё не дошло, итоговая задержка неизвестна, но его возраст уже можно сравнить с допустимым сроком.
Период расчёта задаётся явно. Суточное значение удобно для отчёта, однако нарушение в первые десять минут распродажи требует более оперативного сигнала. Оперативные уведомления о сбоях и итоговый SLO могут использовать разные окна, если их смысл описан.
Как измерять полноту без самообмана
Сверяйте полученные уникальные события с ожидаемыми в источнике за один и тот же период. Сначала согласуйте границы времени, статусы, исключения и время ожидания запоздавших данных.
Условный пример: в источнике 10 000 подходящих оплаченных заказов. Через согласованное время ожидания в CRM обнаружено 9 970 соответствующих идентификаторов (ID) — уникальных кодов заказов. Полнота составляет 99,7%, а 30 заказов требуют разбора. Повторные копии уже полученных заказов не увеличивают число учтённых заказов.
Если в источнике нет доступного реестра, честно укажите ограничение измерения. Счётчик на входе CDP не доказывает отсутствие потерь до CDP. Можно использовать контрольные события и альтернативную сверку, но их охват также нужно описать.
Проверяйте корректность отдельно
Полнота 100% не означает правильные данные. Все заказы могут присутствовать с неверным статусом, суммой или привязкой к клиенту. Для критичных полей нужны проверки формата, допустимых значений и связей.
Например, возврат должен ссылаться на существующий заказ, количество возвращённых единиц должно соответствовать согласованной модели, а валюта — быть определена. Часть проверок выполняется для всех записей, часть требует выборочной сверки с первоисточником.
Не складывайте эти проверки в непрозрачный общий «индекс качества», если по нему нельзя понять действие. Отдельные показатели позволяют остановить только зависимые сценарии и направить исправление нужной команде.
Пример соглашения для трёх потоков
Все пороги ниже условные. Они иллюстрируют структуру документа и должны быть проверены на данных и нагрузке проекта.
| Поток | Целевой показатель | Измерение | Реакция на нарушение |
|---|---|---|---|
| Оплаченные заказы | Не менее 99% применены к остановке корзины за 2 минуты | От времени оплаты до решения сценария | При отставании свыше 5 минут приостановить зависимые напоминания |
| Возвраты | Не менее 99,9% ожидаемых ID получены к закрытию дня | Сверка после оговорённого ожидания поздних записей | Не выпускать итоговый финансовый отчёт без отметки о неполноте |
| Плановый сегмент | Возраст результата не превышает 2 часов | Время расчёта модели | Остановить новые входы и уведомить владельца |
В рабочем соглашении дополните таблицу владельцами, каналом обращения, сроком реакции и процедурой восстановления. Пример SLO-документа Google также связывает метрики с конкретными окнами и определениями расчёта. [2]
Как использовать допустимую долю нарушений
Если целевой показатель — 99,5% своевременных событий за месяц, оставшиеся 0,5% образуют допустимый объём нарушения данного показателя. При 200 тысячах событий это 1 000 событий. Но из этого не следует разрешение отправить тысячу сообщений вопреки действующему запрету.
Операционные цели не заменяют обязательные ограничения процесса. Для некоторых ситуаций нужно безопасное поведение при отсутствии актуальных данных. Также общий процент может скрыть концентрацию проблем: все нарушения в одном магазине способны полностью сломать его сценарий.
Поэтому анализируйте качество по значимым источникам и типам событий. Это помогает заметить локальную неисправность, которая теряется в большом общем потоке.
Настройте сигналы с понятным действием
Каждый сигнал должен иметь владельца и инструкцию: где проверить источник, какой сценарий остановить и как подтвердить восстановление. Оповещение «ошибок больше обычного» без контекста создаёт шум.
Полезны и проверки тишины. Отсутствие ошибок при нулевом потоке покупок может означать остановившуюся интеграцию. Сравнивайте ожидаемую активность с фактической, учитывая часы работы и сезонность, а не реагируйте на любой ночной спад.
Разделите срок реакции и срок устранения. Подтверждение обращения через 15 минут не означает восстановление за 15 минут. Внешний SLA поставщика также может покрывать только его компонент; сквозной результат требует согласованных внутренних действий.
Принимайте восстановление по данным и решениям
После сбоя проверьте, что очередь разобрана, потерянные записи восстановлены и текущие сценарии используют актуальное состояние. Не выпускайте просроченные предложения только потому, что данные наконец дошли.
Зафиксируйте затронутый период, клиентов и ограничения отчётности. Если нарушение повлияло на эксперимент, его результаты требуют отдельной оценки. Хорошее соглашение о данных помогает не только обнаружить сбой, но и понять, какие бизнес-выводы после него остаются надёжными.
Источники
[1] Google. Implementing SLOs. The Site Reliability Workbook, 2018.
[2] Google. Example SLO Document. The Site Reliability Workbook, 2018.