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

Журнал воздействий — это история решений и действий CRM по отношению к клиенту. Для эксперимента он должен различать назначение варианта, допуск к сценарию, попытку отправки и подтверждённые события доставки. Одной таблицы «отправлено писем» недостаточно.

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

Разделите назначение и исполнение

Назначение отвечает на вопрос: «Какой вариант должен применяться к этому клиенту?». Исполнение — «Что система фактически сделала?». Они не совпадают, если адрес невалиден, сработал частотный лимит или клиент успел купить до отправки.

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

Условный пример. Клиент назначен в тест, но письмо отменено из-за покупки до отправки. Он остаётся в тестовой группе, а отмена фиксируется отдельной причиной. Участник контроля тоже получает запись назначения, хотя попытки отправки у него вообще не было.

Минимум — две связанные таблицы

Набор данныхОдна строка означаетКлючевые поля
НазначенияКлиент в конкретном эксперименте и этапеexperiment_id, phase_id, customer_id, variant, assigned_at, версия правил
События исполненияОдно решение или изменение статуса попыткиevent_id, attempt_id, customer_id, campaign_id, тип события, время, причина
Справочник сценариевВерсию механикиКанал, оффер, ограничения, время действия

Для простого эксперимента назначение уникально по клиенту и эксперименту. Если дизайн предусматривает несколько этапов, ключ и анализ должны включать этап; нельзя просто перезаписать старый вариант.

В событиях сохраняют время действия и время получения записи. event_id помогает устранить повторную доставку одного события, attempt_id связывает статусы одной попытки. Идентификатор сообщения провайдера полезен для сверки, но не заменяет собственные ключи.

Записывайте причины отсутствия контакта

Различайте контроль, отписку, отсутствие разрешения, лимит частоты, конфликт приоритетов, завершение цели, техническую ошибку и истечение срока актуальности. «Не отправлено» слишком широкое значение для диагностики.

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

Необязательно копировать весь профиль. Обычно достаточно версии правил, нужных признаков решения и ссылки на воспроизводимый срез. Состав и срок хранения должны соответствовать задаче и установленным правилам работы с данными.

Не приравнивайте отправку к просмотру

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

Открытия email могут содержать автоматические события. Поэтому поле «увидел» нельзя безоговорочно строить из одного пикселя. Для анализа нужны определение события, источник и известные ограничения.

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

У одного клиента десять контактов и два заказа. Прямое соединение всех строк по клиенту даст двадцать сочетаний. Если сложить сумму заказов после такого соединения, выручка вырастет искусственно.

Для основной экспериментальной метрики сначала агрегируйте заказы до уровня клиента и нужного окна, а затем присоединяйте одну запись назначения. Атрибуция конкретным контактам — отдельная задача со своими правилами; её нельзя незаметно подставлять вместо эффекта эксперимента.

Как проверить готовность до запуска

На тестовой группе пройдите успешную отправку, отмену, контроль, повторную доставку события и поздний статус. Убедитесь, что назначение не теряется, причины различимы, а итоговый отчёт не удваивает суммы.

После запуска контролируйте полноту журналов и расхождения между системами. Если журнал построен правильно, он отвечает не только «какое письмо ушло», но и «почему клиент получил именно такое воздействие и к какому сравнению относится его результат».

Источники

Microsoft Experimentation Platform. Patterns of Trustworthy Experimentation: Pre-Experiment Stage. Microsoft Research. 31 июля 2020.