Контрольная группа получила другую рассылку: что делать
Контроль получил промописьмо из другой цепочки: как сохранить назначенные группы, описать нарушение эксперимента и решить, нужен ли повтор.
Выделили контроль без winback-письма, но через два дня он получил акцию из общей рассылки. Теперь тест сравнивает другие условия, чем планировали. Первое действие — сохранить историю назначения и отправок. Перетасовать людей после результата особенно соблазнительно и особенно вредно.
Что именно было обещано контролю
«Не получать конкретное письмо» и «не получать никаких рекламных коммуникаций» — разные условия. Если протокол исключал только одну цепочку, общая рассылка может быть частью фоновой политики. Если исключались все промокасания, произошёл сбой. Ответ найдите в исходном протоколе, а не придумайте после просмотра продаж.
В руководстве NIST выбор дизайна связан с целью эксперимента. Практический вывод здесь простой: до вычисления разницы нужно восстановить, какой фактор действительно отличался между группами.
Журнал загрязнения
| Поле | Содержание |
|---|---|
| Назначенная группа | Контроль или вариант на момент старта |
| Ожидаемая политика | Какие коммуникации исключались |
| Фактическое касание | Идентификатор отправки, дата, предложение |
| Причина | Другая цепочка / ручной импорт / ошибка исключения |
| Связь с результатом | Окно до заказа, без переопределения группы |
Учебный пример: в контроле 1 000 назначенных контактов, из них 120 получили постороннюю акцию. Это 12% загрязнения по факту отправки. Оно не равно 12% изменения продаж: влияние зависит от предложения, доставки, времени и реакции людей. Не вычитайте из эффекта произвольный коэффициент.
Почему нельзя просто удалить 120 человек
Получение другой цепочки могло зависеть от активности или покупки. Исключив этих людей, вы измените состав контроля по признаку, возникшему после назначения. Группы перестанут соответствовать исходной логике. Основной анализ по назначению сохраняют, а нарушение описывают как ограничение.
Дополнительный описательный срез по фактическим касаниям допустим, если ясно назвать его описательным. Он поможет понять масштаб и механизм сбоя. Сам по себе он не восстанавливает случайное сравнение и не даёт права объявить очищенный результат причинным.
Когда результат ещё полезен
- Посторонняя коммуникация была разрешена одинаковой фоновой политикой — уточните реальный вопрос теста.
- Нарушение локально, история полная — покажите основной результат и анализ чувствительности с ограничениями.
- Группы получили разные сильные акции, история неполная — не выбирайте победителя по чистой разнице.
- Нарушение связано с оплатой или активностью — особенно осторожно с исключениями после назначения.
Формулы дополнительной прибыли уже разобраны в материале про winback-контроль. Здесь они не меняются; меняется достоверность предпосылок, на которых их интерпретируют.
Как подготовить следующий запуск
Создайте единый список исключений для всех промосценариев, назначьте владельца и проверьте его на тестовых контактах. Учитывайте пересечение рассылок и ручные отправки. Система исключений должна работать в момент отправки, а не только при первом входе в цепочку.
Верните правила в паспорт email-кампании. Повторный тест имеет смысл после устранения причины; ещё одна отправка поверх прежней ошибки добавит данных, но не ясности.
Что сохранить, если повтор теста откладывается
Иногда повторить кампанию сразу невозможно: сезон закончился, условия предложения изменились или люди уже получили письмо. Не пытайтесь восстановить чистый эксперимент простым переносом даты в таблице. Сохраните фактический результат, исходный протокол, список нарушений и границу интерпретации. Такой отчёт полезен для исправления системы коммуникаций, даже если он не выбирает победителя.
Проверьте направление загрязнения. Контроль мог получить акцию, а часть варианта — не получить основное письмо. Бывает и обратное: глобальное исключение остановило обе группы. Раздельные числа назначений, отправок, доставки и других касаний позволяют понять, что сравнивалось на практике. Одна строка «тест испорчен» скрывает устранимую причину.
Перед следующим запуском проведите техническую репетицию исключений без массовой отправки. Создайте разрешённые тестовые профили, которые входят сразу в несколько сценариев, и посмотрите решение очереди для каждого. Убедитесь, что ручной импорт не обходит контроль. Список исключений должен иметь версию и владельца, а в журнале — объяснение, почему конкретная коммуникация была отменена. Это конкретное улучшение, которое можно проверить ещё до нового эксперимента.