Заказы ≠ деньги: как отражать в рекламных кабинетах выкуп, возврат и маржу

Рекламная кампания работает, заказы поступают, в кабинете Google Ads или Meta все выглядит прекрасно: ROAS 6, стоимость заказа в пределах нормы. А в конце месяца финансовый отчет показывает другую картину: часть заказов не выкупили, часть вернули, а наибольший объем принесли товары с минимальной маржой. Оборот есть, прибыли нет.

Креатив и ставки здесь ни при чём. Рекламная система видит только событие на сайте: добавление в корзину, заказ, сумму чека в момент оформления. Что было дальше — подтвердил ли клиент заказ, забрал ли посылку, вернул ли товар через две недели, сколько осталось после себестоимости и логистики — для неё это невидимо. Алгоритм оптимизируется под то, что видит: есть оформленные заказы — приводит оформленные заказы, а не выкупленные и прибыльные.

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

1. Какое событие передавать и когда: оформление или выкуп, сразу или задним числом, и что делать, если статус меняется после передачи.

2. Какую ценность присваивать этому событию: сумму чека, маржу, прогноз с поправкой на невыкуп.

Можно сделать первое без второго и наоборот. Но механика и риски в них разные, поэтому далее они рассмотрены отдельно.

Что стоит прочитать перед этим

Чтобы не повторять материалы, которые уже есть в Netpeak Journal:

1. Зачем передавать конверсии из CRM, какие данные хранить, как свести их в BigQuery и как безопасно тестировать новую конверсию (secondary → primary, параллельный ad set в Meta);

2. Чем Enhanced Conversions отличаются от Imported Conversions, как работает GCLID, хеширование SHA-256, формат timestamp, требования к согласию и Consent Mode. Там же о лимите в 90 дней с момента клика на офлайн-импорт (63 дня для любой загрузки с PII, в частности Enhanced Conversions for Leads).

Отдельно о согласии: всё, что описано далее, предполагает загрузку хешированных email и телефонов в рекламные системы. Правовые основания, баннер согласия на куки-файлы, Consent Mode и политика конфиденциальности — обязательное условие, а не деталь. Это разобрано в статье выше, и без этого блока построить пайплайн невозможно.

Перед стартом: три вопроса, которые решают половину проектов

Ответы на них нужно собрать до того, как ставить задачу разработчику. Любой из этих вопросов может закрыть проект.

1. Действительно ли ваши сегменты ведут себя по-разному после оформления?

Вся конструкция имеет смысл только там, где в кабинете сегменты выглядят одинаково, а в кассе ведут себя по-разному. Наложенный платеж против предоплаты, возврат в fashion, разная маржинальность ассортимента, подтверждение колл-центром — это именно такие случаи. Если у вас предоплата, выкуп 97% и равная маржа по всему каталогу, то передавать нечего — разницы для алгоритма не возникнет.

2. За сколько дней у вас финализируется статус?

От ответа зависит вся архитектура. Ошибка здесь дорого обойдется: придется переделывать весь пайплайн целиком.

3. У какой доли заказов в CRM сохранен валидный GCLID или fbclid/fbc?

Подсчитайте это до начала работ. Если клик-иди есть у 60% заказов — потолок эффекта 60%, и никакие настройки в кабинете этого не повысят. Если меньше половины, то сначала наладьте сохранение клик-иди на сайте, а пайплайн отложите. Это самая дешёвая проверка из всех и чаще всего упускаемая.

Какое событие передавать

Три разных окна: импорт, отчетность, автобидинг

Их путают, и из-за этого пайплайн, который технически работает, не влияет на ставки.

Третья строка — главное ограничение всей конструкции. 

В справке Google говорится: корректировка, сделанная позднее, чем через 7 дней после первичной конверсии, игнорируется автобидингом. В отчет она попадет, в обучение — нет.

Возврат на 30-й день вы подтянете в личный кабинет, отчет станет более достоверным, но алгоритм на этом уже не учится. Реально управлять ставками через корректировки можно только там, где финальный статус появляется за неделю: подтверждение колл-центром, отказ, невыкуп в течение нескольких дней.

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

Одно предупреждение о сроках. С 15 июня 2026 года импорт офлайн-конверсий и загрузка Enhanced Conversions for Leads перейдут в Data Manager API и будут заблокированы в Google Ads API. Интеграции с токенами разработчика, из которых такие запросы уже отправлялись до июня 2026 года, сохранят доступ к старому способу — всё новое нужно строить сразу на Data Manager API. 

Две архитектуры, и выбор делается на старте

Переделывать этот выбор позже будет дорого.

Вариант А. Передавать только финальное событие. Первичная конверсия в момент оформления в личный кабинет не отправляется вообще. Через Offline Conversion Import отправляется одно событие — «подтверждено» или «выкуплено» — сразу с реальной ценностью. Окно здесь — 90 дней с момента клика, но только если для конверсионного действия установлено именно такое окно конверсии, а не дефолтные 30. Тогда запоздалые корректировки действительно не проблема.

Вариант Б. Передавать сразу и корректировать задним числом. Заказ поступает в личный кабинет в момент оформления, а дальше RETRACT/RESTATE устраняют невыкупленные заказы и возвраты. Объем конверсий сохраняется, стратегии есть на чём учиться с первого дня, но только если финальный статус успевает попасть в семидневное окно.

Если выкуп отменяется на 10–14-й день (а для наложенного платежа это норма: доставка плюс хранение на почте), вариант Б просто не работает. Корректировка отразится в отчетности, но не в обучении, и вы получите правильный отчет при неизменно неправильных ставках.

У варианта А своя цена: конверсий меньше и они приходят с задержкой. Для магазина, который едва набирает объем на смарт-стратегии, это может оказаться критичным. Кейс из этой статьи — это вариант А в чистом виде: команда передавала только подтвержденные заказы, объем конверсий упал примерно вдвое, и кампания с более чистым сигналом все равно выиграла. Но это один проект с достаточным объемом, переносить вывод на всех не стоит.

Промежуточный вариант для средних объемов: первичная конверсия — как вторичное конверсионное действие (для отчетности и ремаркетинга), финальная — как основное, под которое оптимизируется стратегия. Так вы не теряете видимость воронки и в то же время не кормите алгоритм сырыми заказами. Механика переключения secondary → primary разобрана в статье Александра Конивенко (Head of Digital Data Department).

RETRACT и RESTATE: что можно сделать только один раз

Conversion Adjustments — штатный механизм Google Ads для изменения уже загруженной конверсии. Именно через него в личный кабинет поступает информация о возврате товара, отмененном заказе или невостребованной посылке.

Что можно передать:

• RETRACT — отмена конверсии по невостребованной посылке;

• RESTATE — уменьшение стоимости при частичном возврате или перерасчет на фактическую маржу;

• фильтрация тестовых, дублирующихся и фейковых заказов ещё до передачи;

• подтверждение заказа колл-центром как отдельная, «настоящая» конверсия.

Три вещи, которые стоит заложить в архитектуру сразу:

1. Order ID обязателен. Чтобы позже отменить или переоценить конверсию, нужен order ID, переданный ещё во время первичной загрузки. Google рекомендует идентифицировать конверсию для корректировки именно через него, а не через пару GCLID + дата/время. Если он не заложен с самого начала, корректировать нечем, и придётся переделывать весь пайплайн.

2. RETRACT практически необратим. После отмены конверсии (или сброса в ноль) корректировать её уже нельзя: все последующие попытки Google игнорирует молча, без ошибки, то есть ваш лог покажет успешную загрузку, а в кабинете ничего не изменится. Формально в справке есть обходной путь: перезагрузить те же самые конверсии со сдвинутым на несколько секунд timestamp, чтобы система приняла их как новые. Но это аварийная процедура, а не рабочая логика. Правило остаётся простым: если статус ещё может измениться — RESTATE; RETRACT только для финальных состояний.

3. Один статус — одна корректировка. В пайплайне должна быть явная карта «статус в CRM → тип корректировки», где финальными обозначены только те статусы, из которых заказ уже не может вернуться.

Карта статусов: как это выглядит на практике

Примерный каркас для e-commerce с наложенным платежом. Конкретные названия у вас будут свои — важна сама структура и колонка «Это финальный статус».

Две строки здесь самые важные. «Не дозвонились» — не финальный статус, и RETRACT на него ставить нельзя: заказ еще жив. «Частичный возврат» — тоже не финальный, потому что клиент может вернуть остаток, и если вы уже сделали RESTATE в ноль, второй корректировки не будет.

Meta: корректировок нет. Три обходных пути

Для магазина с оплатой при получении это половина задачи. Прямой аналогии с Conversion Adjustments в Meta нет: в API нет операции, которая отменяет или переоценивает уже отправленное событие Purchase.

Асимметрия между платформами: в Google на импорт отводится до 90 дней с момента клика, а в Meta ограничений на самом деле три, и путать их нельзя.

Дедлайн отправки события. CAPI принимает event_time не старше 7 дней. Если в партии есть хоть одно событие более старое, Meta возвращает ошибку на весь запрос и не обрабатывает ни одного. Исключение — action_source = physical_store, там 62 дня.

Окно атрибуции ad set. 7 дней с момента клика — это значение по умолчанию и одновременно максимальное; можно настроить более короткий срок (1 день с момента клика, 1 день с момента клика + 1 день просмотра). В отчётах Ads Insights 28-дневные окна ещё доступны, но на оптимизацию они не влияют.

Окно, в котором событие ещё способно повлиять на обучение, а не просто быть учтённым в отчёте.

Практическое следствие: если покупка происходит на 12-й день, отправить событие задним числом вы уже не можете — запрос не пройдет. Отправить его можно только с текущим event_time, и тогда оно выпадает из семидневного окна клика. Для наложенного платежа в Meta выбор из-за этого фактически сужен до третьего варианта.

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

2. Два события вместо одного. Браузерное Purchase остаётся как есть (отчётность и ремаркетинг), а поверх него сервером отправляется отдельное кастомное событие типа PurchaseConfirmed, и оптимизация переключается на него. Компромисс: пользовательское событие набирает объем медленнее, чем стандартное, поэтому при небольших объемах стратегии будет сложнее выйти из фазы обучения. Оба семидневных ограничения здесь остаются прежними.

3. Прогнозируемая ценность сразу. Purchase отправляется в момент заказа, но с ценностью, уменьшенной на ожидаемый процент отказов от покупки — желательно отдельным коэффициентом для каждого сегмента: предоплата / наложенный платеж / категория товара. Самый простой в реализации единственный вариант, который не нарушает объем событий, и единственный, который не упирается в окно атрибуции. Минус — точность: вы оптимизируетесь под прогноз, а не под факт, и прогноз нужно пересчитывать ежемесячно, иначе он постепенно расходится с реальностью.

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

Что ломается, когда Purchase идет из бэкенда

Когда событие перестает быть браузерным и начинает поступать из CRM, появляются три специфические для этой схемы сбоя: 

1. fbc и fbp исчезают. Это важные сигналы для сопоставления, и они чаще всего теряются, потому что их не сохраняют в CRM вместе с заказом. Браузерное событие берет их из куки автоматически; серверное — только если вы их туда поместили. Проверьте это вместе с пунктом три из чек-листа в начале.

2. Нормализация перед хешированием. Телефон в формате E.164 без пробелов и скобок, email в нижнем регистре с обрезанными пробелами. Хеш от +38 (050) 123-45-67 и от 380501234567 — это два разных хеша, и совпадения не будет. В браузере нормализацию выполняет пиксель, в вашем пайплайне — вы.

3. event_id. Если вы отправляете и браузерный, и серверный Purchase (вариант 2 выше — это как раз он), дедупликация держится на event_id. Без него алгоритм учится на дублирующихся цифрах.

Общее качество сопоставления событий — это Event Match Quality, и за ним стоит следить отдельно по каждому событию. EMQ нужно довести до нормы до того, как строить логику выкупа поверх. Пороги Meta не публикует, но если показатель ниже 6, стоит проверить, какие поля вы передаете и правильно ли их нормализуете.

Какую ценность передавать

Маржа вместо оборота

Вместо суммы чека можно передавать маржу и работать по показателю POAS (Profit on Ad Spend) вместо простого ROAS. Алгоритм перестает гнаться за дешевыми продажами убыточных позиций ради красивой цифры в личном кабинете.

Простой пример. Кампания А и кампания Б принесли по 100 заказов на 200 000 грн каждая. В кабинете они идентичны, ROAS одинаковый. Но кампания А продавала товар с маржой 35% и выкупом 90%, а кампания Б — акционную позицию с маржой 8% и выкупом 55%. Реальный вклад в прибыль отличается в разы, а система об этом не знает и продолжает одинаково вкладываться в обе.

Условие то же, что и в первом вопросе чек-листа: маржа как показатель имеет смысл только в том случае, если она существенно различается между товарами. Если в каталоге везде 30%, вы просто умножите все конверсии на 0,3 и не дадите алгоритму никакой новой информации.

Откуда взять себестоимость

Все вышесказанное исходит из того, что у вас есть COGS по SKU. Обычно его нет, по крайней мере, не в CRM. Он хранится в ERP, в 1С или у финансиста в Excel, обновляется раз в квартал и не имеет ключа для сопоставления с товарным фидом.

Что нужно решить до внедрения:

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

• как сопоставлять — по SKU, артикулу или категории, ведь если точного ключа нет, категорийная маржа часто даёт 80% эффекта при 20% работы;

• что включать, кроме COGS — доставку, эквайринг, упаковку; простой вариант «чек минус себестоимость» уже работает, полный P&L по заказу — отдельный проект;

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

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

Новые и повторные покупки

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

Прежде чем делать это вручную через value, в Google Ads для этого есть встроенный механизм — цель «Привлечение новых клиентов» (New Customer Acquisition goal), где можно задать повышенную ценность новому клиенту или вообще показывать рекламу только новым. Если задача сводится именно к этому, начните с него — это настройка в личном кабинете, а не строки в пайплайне. 

Пользовательская логика нужна тогда, когда ваше определение «нового» сложнее того, что видит Google (например, вы считаете по клиенту в CRM, а не по конверсии на сайте).

Что делать при любом переходе

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

Наиболее ярко это видно на примере маржи. ROAS 6 по обороту и ROAS 6 по марже — это разные цели. Если средняя маржа составляет 30%, прежняя цель в новых единицах превращается примерно в 1,8. Оставьте tROAS 6, и стратегия начнёт резко сокращать объём, поскольку цель стала физически недостижимой. То же самое, в меньших масштабах, произойдет при переходе на прогнозируемую ценность: если вы снижаете value на 30% ожидаемого невыкупа, цель нужно снизить пропорционально. Поэтому:

1. Рассчитайте коэффициент заранее — среднее соотношение новой ценности к старой за последние 30–60 дней. Это ваш множитель для пересчёта всех целей.

2. Зафиксируйте дату перехода и отметьте её во всех отчётах. Периоды «до» и «после» напрямую не сопоставимы — цифры изменятся без каких-либо изменений в реальной эффективности.

3. Заложите 2–4 недели на переобучение. Показатели будут нестабильными. Это не повод менять ставки вручную.

4. Не меняйте ничего другого в этот момент: ни бюджетов, ни структуры кампаний. Иначе вы не поймёте, что именно дало эффект.

Как понять, что это действительно работает

Риск не в том, что пайплайн не запустится, а в том, что конверсии идут, а рекламная система не сопоставляет их с кликами или игнорирует корректировки. Match rate 20% означает, что вы заплатили за инфраструктуру, а алгоритм получил те же данные, что и раньше.

Meta, Events Manager:

1. EMQ для каждого события отдельно. Purchase с EMQ 8 и AddToCart с EMQ 3 в сводной цифре выглядят приемлемо, а на самом деле половина воронки не сопоставляется. Ниже 6 — повод проверить, какие поля вы передаете и правильно ли их нормализуете.

2. Уровень дедупликации браузерных и серверных событий. Официального порога Meta не называет; на практике всё, что заметно ниже 90%, означает двойной учёт части покупок. Отдельно учтите задокументированное ограничение: дедупликация срабатывает, только если второе событие пришло в течение 48 часов после первого.

Google Ads, диагностика конверсионных действий:

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

2. Отдельно — разрыв между загруженными и принятыми корректировками. Эта метрика показывает, работает ли вообще ваша логика выкупа. Наиболее частые причины отсева: просроченный GCLID, попытка скорректировать уже отмененную конверсию, неправильный формат хеша.

3. Медианная задержка между первичной конверсией и корректировкой. Если она превышает 7 дней — ваша конструкция работает на отчетность, а не на ставки, и пора пересмотреть выбор архитектуры.

Эти цифры стоит зафиксировать до внедрения и отслеживать их еженедельно в течение первых двух месяцев.

Сколько это стоит

Сам API в Google и Meta бесплатный — вы платите за инфраструктуру передачи данных: server-side GTM на собственном хостинге, готовый коннектор с помесячной оплатой или кастомный сервис в облаке. Порядок величин сильно зависит от трафика: для небольшого магазина это десятки долларов в месяц, для проекта с миллионами событий хостинг контейнера уже измеряется сотнями.

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

Об окупаемости: мгновенной отдачи не будет. Первые 2–4 недели после перехода цифры в личном кабинете будут нестабильными и несопоставимыми с предыдущим периодом. Оценивать эффект имеет смысл не раньше, чем через месяц–полтора, и оценивать со своей стороны, в P&L, а не в личном кабинете.

Отдельно стоит сказать о бенчмарках. Публичные цифры платформ: 

• 13% более низкая стоимость результата для комбинации Pixel + CAPI по сравнению с одним только Pixel по данным A/B-тестов Meta; 

• 17,8% для рекламодателей с CAPI для веб-событий по сравнению с теми, у кого его нет (справка Meta) — касаются полноты передачи событий, а не передачи финального статуса или маржи. 

Это разные вещи, и ссылаться на них как на ожидаемый эффект от этого проекта некорректно. Публичных бенчмарков именно по этому слою нет, поэтому единственный способ измерить эффект — тест на своих кампаниях и последующее сравнение в P&L.

Итог

Передача финального статуса — это переход от «оптимизируем под заказы» к «оптимизируем под прибыль». Вы перестаете платить алгоритму за количество оформленных корзин и начинаете платить за деньги, которые дошли до кассы.

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

1. Действительно ли ваши сегменты ведут себя по-разному после оформления заказа? Это ответ на вопрос «стоит ли вообще».

2. Как быстро у вас появляется финальный статус? Это ответ на вопрос «как именно» — вариант А или Б, корректировка или прогнозируемая ценность, и успеете ли вы уложиться в 7-дневное окно автобидинга.

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