Автоматизация сквозной аналитики: расходы, обращения и подтверждённые продажи

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

Результатом должен стать проверяемый реестр: для каждого рекламного расхода понятно, какие подтверждённые денежные события с ним связаны, какие возвраты учтены и какие записи остались без связи. Только после этой сверки имеет смысл рассчитывать ROAS и обсуждать экономику.

Какую задачу решает этот процесс

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

Процесс решает конкретную задачу: рекламные расходы, обращения и подтверждённые продажи сопоставляются по заранее согласованным идентификаторам и правилам. На выходе руководители получают не одну «магическую» цифру, а объяснимую цепочку:

1. канал и расход за выбранный период;
2. обращение с известным идентификатором;
3. сделка или заказ, связанный с обращением;
4. подтверждённая оплата;
5. отмена или возврат, если они произошли;
6. итог по каналу и отдельный список несвязанных записей.

Группировка трафика и подтверждение выручки — разные операции. Согласно официальной документации Google Analytics, каналы представляют собой источники трафика, сгруппированные по правилам; параметры могут относиться к событию, сеансу или пользователю. Такая классификация помогает описать происхождение контакта, но сама по себе не подтверждает получение денег.

Граница этого руководства — сверка рекламы и денежных событий через идентификаторы. Здесь не разбирается сбор или перенос UTM-меток. Также статья не оценивает эффективность пилота автоматизации: для такой оценки нужны отдельные исходные замеры, критерии и фактические результаты.

Какие данные и правила подготовить

Сначала владельцы процесса составляют словарь полей. Для каждого поля нужно зафиксировать источник, ответственного и статус: обязательное, условное или неизвестное. Если значение неизвестно, его нельзя восстанавливать догадкой и незаметно подставлять в отчёт.

Ниже — короткий синтетический образец. Названия, идентификаторы и суммы условны и не относятся к клиенту или результатам Switch On AI.

Одних полей недостаточно. До сборки отчёта стороны письменно согласуют правила:

• какой статус означает подтверждённую продажу;
• какая дата относит расход и денежное событие к периоду;
• как учитывать отмену, полный и частичный возврат;
• в какой валюте строится итог и по какому источнику берётся курс;
• какая модель и какое окно атрибуции применяются;
• на каком уровне считается результат: заказ, кампания, канал или канал за период;
• что происходит с дублем и записью без ключа;
• кто разбирает исключения и кто утверждает исправление.

Неизвестное лучше оставить видимым вопросом. Например: «Источник курса и дата пересчёта не согласованы; решение принимает финансовый специалист». Такая запись полезнее условного курса, который выглядит точным, но не имеет основания.

Как связать расходы, обращения и продажи

Связь строится от наиболее конкретных идентификаторов, доступных в системах заказчика. Учебная цепочка может выглядеть так:

идентификатор рекламного контакта → идентификатор обращения в CRM → идентификатор сделки или заказа → идентификатор оплаты и возврата.

Это описание проектного правила, а не заявление о проверенной совместимости конкретной CRM, рекламной или платёжной системы. Реальные поля, API, права и качество данных проверяются отдельно.

Работу удобно разделить на пять шагов.

1. Зафиксировать исходную запись расхода с каналом, датой, валютой и суммой.
2. Найти обращение по согласованному ключу, не меняя исходное значение идентификатора.
3. Связать обращение со сделкой или заказом.
4. Получить подтверждение оплаты из согласованного источника и присоединить возвраты.
5. Сформировать итог и реестр исключений, сохранив причину каждой несвязанной записи.

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

Запись цели в веб-аналитике считается обращением или иным измеряемым событием, но не фактической выручкой. Денежная сумма появляется в отчёте только после статуса из согласованного источника оплат или CRM. Если цель есть, а подтверждённой продажи нет, отчёт сохраняет обращение без выручки. Если продажа подтверждена, но ключ потерян, она попадает в реестр несвязанных, а не распределяется между каналами на глаз.

Полезно хранить не только итог, но и основание связи: тип ключа, исходные идентификаторы, время сопоставления и применённое правило. Тогда при расхождении можно восстановить решение, а не пересчитывать отчёт вслепую.

Как выбрать модель и окно атрибуции

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

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

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

Рассмотрим синтетическую запись: пользователь сначала пришёл из условного канала «Поиск», через пять дней вернулся из условного канала «Социальная сеть», а ещё через два дня оплатил заказ. Для учебного пересчёта зададим окно 14 дней до оплаты.

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

Окно — согласованный интервал между контактом и денежным событием. Значение 14 дней выше выбрано только для иллюстрации, а не как универсальная норма. Рабочее окно зависит от цикла сделки и правил заказчика.

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

Как сверять отчёт с CRM и оплатами

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

• валовая подтверждённая выручка = сумма подтверждённых заказов;
• чистая выручка после возвратов = валовая подтверждённая выручка − возвраты;
• доля несвязанных записей = число несвязанных подтверждённых продаж / общее число подтверждённых продаж × 100%;
• ROAS в этой статье = чистая выручка после возвратов / рекламный расход.

Затем проверяют исключения.

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

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

Частичный возврат. Из подтверждённой выручки вычитают фактически возвращённую сумму, а не стоимость всего заказа. Статус и сумма возврата должны приходить из согласованного источника.

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

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

Перед обсуждением окупаемости сравнивают четыре величины: расход из рекламных источников, валовую подтверждённую выручку, возвраты и чистую выручку. Отдельно показывают количество и долю несвязанных подтверждённых продаж. Если контрольные суммы расходятся, сначала исследуют период, статусы, дубли, валюту и ключи, а не объясняют расхождение выбранной моделью.

Учебный пример: путь от входных данных до результата

Все каналы, идентификаторы, записи и суммы в этом разделе синтетические. Это не клиентский кейс, не выгрузка из CRM и не результат Switch On AI.

Условие: на рекламу потрачено 10 000 условных денежных единиц. Есть три подтверждённых заказа по 6 000. Два заказа относятся к условному каналу «Поиск», один — к условному каналу «Социальная сеть». Последний заказ полностью возвращён. Все три заказа имеют ключи связи.

Исходные записи

Промежуточное решение

Сначала считаем валовую подтверждённую выручку:

3 × 6 000 = 18 000.

Затем вычитаем полный возврат:

18 000 − 6 000 = 12 000.

Получаем чистую выручку после возврата — 12 000 условных денежных единиц. Теперь можно рассчитать ROAS:

ROAS = 12 000 / 10 000 = 1,2.

В расчёте ROAS используется чистая выручка после возвратов. Значение 1,2 означает 1,2 единицы такой выручки на одну условную единицу рекламного расхода. ROMI здесь не рассчитывается: в исходных данных нет маржи и полного состава маркетинговых расходов.

Итоговая таблица

Для каждой строки действует одна формула: (подтверждённая выручка − возврат) / расход. Контрольные суммы сходятся: расходы — 6 000 + 4 000 = 10 000; подтверждённая выручка — 12 000 + 6 000 = 18 000; возвраты — 0 + 6 000 = 6 000; чистая выручка — 12 000.

Отдельное исключение

Представим дополнительную синтетическую подтверждённую продажу order-504, у которой отсутствует ключ обращения. Она нужна только для демонстрации исключения и не входит в три заказа, исходные 18 000 или ROAS 1,2.

Такую запись помещают в очередь ручной проверки с причиной «нет ключа обращения». Её нельзя незаметно приписать поиску или социальной сети. Человек ищет первичный идентификатор в разрешённых источниках. Если основание не найдено, продажа остаётся несвязанной и видимой в отчёте.

Как проверить результат перед запуском

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

Итоговый чек-лист приёмки:

• ROAS рассчитан как отношение выручки после возвратов к рекламному расходу;
• ROAS и ROMI не смешаны, ROMI без маржи и всех нужных расходов не рассчитан;
• все числа и названия учебного примера обозначены как условные;
• сбор и перенос UTM не включены в этот процесс и относятся к соседней задаче;
• неполные связи видны отдельным числом и списком причин;
• рекламная цель не названа фактической выручкой;
• первый и последний контакт сравниваются на одинаковых исходных записях;
• период, окно, валюта и уровень агрегации указаны явно;
• отмены, возвраты, дубли и поздние события не исчезают из контроля.

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

Что согласовать для внедрения

Готовый аналитический инструмент может группировать трафик, хранить события и строить отчёты в пределах своих функций. Собственная интеграция нужна, когда требуется регулярно получать расходы и денежные события из разных систем, связывать их по правилам заказчика, обрабатывать возвраты и показывать очередь исключений.

До разработки нужно разделить две области.

Функции выбранных систем. Команда заказчика проверяет доступные поля, экспорт, API, тариф, права доступа, ограничения, состав денежных статусов и историю изменений. Упоминание Google Analytics в статье не означает проверенную совместимость с CRM или платёжной системой заказчика.

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

Switch On AI может разработать ИИ-помощника, бота или обычную интеграцию для описанной операции после проверки данных и API. Если сверка полностью описана фиксированными правилами, рассматривают интеграцию и отчёт. Бот рассматривают, когда сотруднику нужен диалоговый способ запросить сводку или передать исключение. ИИ-помощник рассматривают только для согласованной работы с неструктурированными сведениями; финансовые правила задаёт специалист заказчика.

Правила бухгалтерского, юридического, кадрового и отраслевого учёта задаёт и проверяет специалист заказчика. Работа с 1С в этот объём не входит. Статья также не подтверждает опыт внедрения конкретного вендора: совместимость, тарифы, API и права проверяются отдельно на системах заказчика.

Подходящий первый шаг — разобрать источники и один отчёт сквозной аналитики: выбрать период, сопоставить контрольные суммы, проверить несколько связанных записей и одно исключение. На странице услуг Switch On AI описаны доступные форматы решений. Смежную задачу подготовки отчётности можно сравнить с автоматизацией отчёта CRM.

После разбора одной операции можно согласовать границы прототипа и критерии проверки. Прототип показывает выбранный фрагмент и не равен полному внедрению. Чтобы обсудить исходные системы и условный пример без клиентских данных, свяжитесь со Switch On AI. Состав и сроки разработки оценивают после проверки данных, доступов и API. Ожидаемый эффект и способ его проверки стороны фиксируют отдельно; статья не обещает результат внедрения.