Один заказ в двух email-отчётах: как убрать дубли
Один заказ приписан двум письмам: как собрать реестр транзакций, выбрать правило атрибуции и сверить сумму без двойного учёта выручки.
После первой рассылки заказ попал в отчёт кампании, после второй — снова. Каждая карточка выглядит правдоподобно, но сумма доходов стала больше продаж магазина. Начните с реестра уникальных транзакций. Выбор «первого» или «последнего» письма идёт после удаления дублей.
Две операции с разной задачей
Дедупликация отвечает: сколько отдельных заказов действительно было. Атрибуция отвечает: как распределить эти заказы или их стоимость между касаниями. У одной покупки могут быть несколько email-переходов; они не создают несколько покупок. Сначала определите факт заказа, затем правило распределения.
Google Analytics использует transaction_id для удаления повторных web-покупок. Идентификатор должен быть уникальным и непустым. Это правило не означает, что кабинет рассылок автоматически использует ту же логику или что система учёта не требует своей сверки.
Как появляется двойная сумма
| Система | Что записала | Сумма в отдельном отчёте |
|---|---|---|
| Письмо А | Касание за пять дней до заказа | 10 000 ₽ |
| Письмо Б | Касание за день до заказа | 10 000 ₽ |
| Реестр заказов | Один заказ №Z-42 | 10 000 ₽ |
Если отчёты показывают полную ценность каждого касания, сложение 20 000 ₽ не имеет смысла как общая выручка. При выбранном последнем касании Б получает 10 000 ₽, А — ноль в этой модели. При условном равном распределении оба получают по 5 000 ₽. Модель нужно назвать, а не угадывать по красивому итогу.
Минимальные поля общей таблицы
- Уникальный идентификатор заказа из учётной системы.
- Дата и сумма с явным составом: товары, скидки, доставка, налоги.
- Валюта и правило пересчёта, если валют несколько.
- Список допустимых касаний и их время.
- Выбранная модель, окно и доля атрибуции.
- Связанные возвраты с собственной датой операции.
Сумма долей по одному заказу должна отвечать принятой модели. Если модель намеренно показывает полный кредит каждому касанию, такой отчёт остаётся несуммируемым. Не называйте его общим доходом канала.
Четыре теста перед сдачей отчёта
- Один заказ с повторно отправленным событием purchase остаётся одним заказом.
- Два разных заказа с одинаковой суммой не объединяются.
- Заказ без идентификатора попадает в исключения, а не сливается со всеми пустыми.
- Частичный возврат уменьшает деньги ровно один раз.
Последняя проверка подробнее разобрана в доходе рассылки после возвратов. Если источник теряется ещё до заказа, вернитесь к цепочке редиректов и UTM. Суммирование исправляют в общей таблице, а не ручным уменьшением итогового слайда.
Что показывает исправленная сумма
Она показывает результат выбранного учёта без повторов. Она не доказывает, что все эти продажи появились благодаря email. Для такого вывода нужно другое сравнение с контролем или подходящей экспериментальной схемой. Удобная модель атрибуции не заменяет вопрос причинности.
Сохраните определения в email-отчёте, рядом с уровнями уникальности кликов. Тогда два специалиста смогут воспроизвести одну сумму из одного реестра, даже если каждый предпочитает свою картинку в кабинете.
Проверка суммы в обе стороны
После объединения сгруппируйте реестр по заказам, а затем по письмам. При распределительной модели общий итог должен совпасть с допустимой суммой уникальных заказов на той же основе. Если часть продаж осталась без email-касания, они не обязаны искусственно распределяться между кампаниями. Отдельная строка «не отнесено» сохраняет честность модели.
Проверьте отменённые и переоформленные заказы. Новый номер в системе может означать замену старого, а повторная отправка события — прежний номер. Без операционной связи оба случая выглядят как лишняя продажа, но требуют разных правил. Аналитик должен знать, какой идентификатор отражает экономическую покупку, а какой — технический документ.
Рейтинг писем полезно пересчитать при нескольких разумных правилах атрибуции, если решение существенно зависит от модели. Если порядок меняется полностью, вывод об эффективности отдельного письма слабее, чем кажется по одной панели. Сохраните основную модель для регулярного отчёта, покажите чувствительность и не называйте разницу причинным эффектом. Такая граница особенно важна при серии касаний, когда первое знакомит, второе объясняет, а третье лишь оказывается последним перед заказом.