Замовлення ≠ гроші: як передавати в рекламні кабінети викуп, повернення і маржу

Рекламна кампанія працює, замовлення йдуть, у кабінеті 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).

Перед стартом: три питання, які закривають половину проєктів

Відповіді на них треба зібрати до того, як ставити задачу розробнику. Будь-яке з цих питань може закрити проєкт.

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

Уся конструкція має сенс тільки там, де в кабінеті сегменти виглядають однаково, а в касі поводяться по-різному. Накладений платіж проти передоплати, повернення у fashion, різна маржинальність асортименту, підтвердження кол-центром — це саме такі випадки. Якщо у вас передоплата, викуп 97% і рівна маржа по всьому каталогу, то передавати нема чого — різниці для алгоритму не виникне.

2. За скільки днів у вас фіналізується статус?

Від відповіді залежить уся архітектура. Помилка тут дорога: переробляти доведеться пайплайн цілком.

3. У якої частки замовлень у CRM збережений валідний GCLID або fbclid/fbc?

Порахуйте це до початку робіт. Якщо клік-айді є у 60% замовлень — стеля ефекту 60%, і жодні налаштування в кабінеті цього не піднімуть. Якщо менше половини, то спершу лагодьте збереження клік-айді на сайті, а пайплайн відкладіть. Це найдешевша перевірка з усіх і найчастіше пропущена.

Яку подію передавати

Три різні вікна: імпорт, звітність, автобідинг

Їх плутають, і через це пайплайн, який технічно працює, не впливає на ставки.

Третій рядок — головне обмеження всієї конструкції. 

Довідка Google каже: коригування, зроблене пізніше ніж через 7 днів після первинної конверсії, автобідинг ігнорує. У звіт воно потрапить, у навчання — ні.

Повернення на 30-й день ви в кабінет підтягнете, звіт стане правдивішим, але алгоритм на цьому вже не вчиться. Реально керувати ставками через коригування можна тільки там, де фінальний статус з'являється за тиждень: підтвердження кол-центром, відмова, невикуп у межах кількох днів.

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

Дві архітектури, і вибір робиться на старті

Переробляти цей вибір потім дорого.

Варіант А. Передавати тільки фінальну подію. Первинна конверсія в момент оформлення в кабінет не йде взагалі. Через 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 → тип коригування», де фінальними позначені лише ті статуси, з яких замовлення вже не може повернутися.

Мапа статусів: як це виглядає на практиці

Приблизний каркас для ecommerce із накладеним платежем. Конкретні назви у вас будуть свої — важлива сама структура й колонка «Це фінальний статус».

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

Meta: коригувань немає. Три обхідні шляхи

Для COD-магазину це половина задачі. Прямої аналогії до 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. Алгоритм перестає гнати дешеві продажі збиткових позицій заради красивої цифри в кабінеті.

Умова та сама, що й у першому питанні чекліста: маржа як value має сенс тільки якщо вона суттєво різна між товарами. Якщо в каталозі скрізь 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 проти самого пікселя за A/B тестами Meta; 

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

Це різні речі і посилатися на них як на очікуваний ефект від цього проєкту некоректно. Публічних бенчмарків саме по цьому шару немає, тому єдиний спосіб виміряти ефект — тест на своїх кампаніях і подальше порівняння в P&L.

Підсумок

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

Але головне рішення ухвалюється до будь-якої технічної роботи і зводиться до двох питань із початку статті:

1. Чи справді ваші сегменти поводяться по-різному після оформлення замовлення? Це відповідь на «чи варто взагалі».

2. Як швидко у вас з'являється фінальний статус? Це відповідь на «як саме» — варіант А чи Б, коригування чи прогнозована цінність, і чи встигнете ви в 7-денне вікно автобідингу.

Помилка в другому питанні найдорожча: пайплайн працюватиме, у звітах все зійдеться, а ставки не зміняться. Алгоритм відпрацює реальну цінність краще за ручні ставки. Але тільки якщо побачить її вчасно.