Трекинг конверсий при наложенном платеже и внешних чекаутах

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

Это руководство объясняет, почему такие заказы пропадают и почему важен статус оплаты. Оно сравнивает три момента для отправки покупки: когда заказ создан, когда он подтверждён и когда оплачен. Также рассматриваются отказы от заказов и возвраты и то, как ROASaurus работает с внешними чекаутами.

Почему пиксели не видят заказы с наложенным платежом?

Браузерный пиксель сообщает о покупке, когда покупатель попадает на страницу, где он запускается. Обычно это страница благодарности вашего чекаута. Каждый путь заказа, который пропускает эту страницу или запускает её на другом домене, теряет событие покупки или клик по рекламе, который к ней относится.

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

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

Почему важен статус оплаты

Оплата картой списывается в чекауте, поэтому заказ оплачен в тот момент, когда он появляется. С наложенным платежом всё иначе. Shopify относит наложенный платёж к ручным способам оплаты, и такие заказы остаются в статусе Payment pending, пока вы не отметите их как оплаченные. На практике это происходит после того, как курьер получает наличные, а на это могут уйти дни. Некоторые заказы так и не оплачиваются, потому что покупатель отказывается от посылки или не оказывается дома.

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

В WooCommerce всё наоборот. Он ставит заказам с наложенным платежом статус Processing, пока платёж не получен, кроме заказов со скачиваемым товаром, которые получают On hold. Поэтому настройка, отправляющая заказы в статусе Processing, отправляет их сразу после оформления. Проверьте, какой статус ваша платформа даёт таким заказам, прежде чем принимать другие решения.

Создан, подтверждён или оплачен: когда отправлять покупку?

На выбор есть три момента. Каждый обменивает скорость на точность.

Почему запоздавшие события покупки — это проблема

Рекламные платформы засчитывают покупку объявлению, только если она происходит внутри окна атрибуции после клика. При 7-дневной атрибуции по клику в Meta покупка засчитывается объявлению в течение 7 дней после клика. Conversions API Meta также отклоняет события, у которых event_time старше 7 дней, и отклоняет весь запрос, если одно событие слишком старое. Поэтому у покупки, отправляемой при оплате, два плохих варианта:

• Отправить её со временем заказа. Если оплата пришла более чем через 7 дней, Meta её отклонит.
• Отправить её со временем оплаты. Meta её примет, но клик по рекламе может быть старше 7 дней, поэтому покупка не засчитается объявлению.

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

Какой момент выбрать

Для большинства магазинов с наложенным платежом лучше по умолчанию отправлять при создании. Сигнал приходит сразу, клик всё ещё внутри окна, и ничего не отклоняется. Минус в том, что отказные заказы учитываются в Ads Manager как покупки. Вы компенсируете это в своих целевых показателях, как показано в следующем разделе.

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

Как обрабатывать отказы от заказов, отмены и возвраты

Как только покупка отправлена, она остаётся в Ads Manager. Посылка, от которой отказались у двери, её не убирает. ROASaurus также не отправляет возвраты и отмены в Meta, TikTok и большинство других рекламных платформ, поэтому выручка в их отчётах включает заказы, оплату за которые вы так и не получили. Только значения в Google Ads и Microsoft Advertising можно скорректировать после возврата, если включены корректировки ценности. Решение — измерить долю отказов и скорректировать числа, с которыми вы сравниваете.

Вот разобранный пример за один месяц. Для простоты цены указаны без НДС.

При рекламных расходах $3,000 один и тот же месяц выглядит совершенно по-разному в зависимости от того, какую выручку брать:

Валовая маржа по доставленной выручке составляет $3,878 ÷ $8,200 = 47.3%, поэтому ROAS безубыточности равен 1 ÷ 0.473 = 2.11. Эта безубыточность относится к доставленной выручке. Ads Manager считает и отвергнутые заказы, поэтому перед сравнением её нужно пересчитать. Базовая формула объяснена в материале ROAS безубыточности.

Результат можно проверить напрямую. Реклама выходит на безубыточность, когда рекламные расходы равны валовой прибыли в $3,878, а $10,000 заявленной выручки ÷ $3,878 = 2.58.

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

Возвраты и отмены в ваших собственных числах

В Shopify отмены и возвраты приходят в ROASaurus по вебхуку, поэтому аналитика прибыли вычитает возвраты из выручки. Вы сами выбираете, учитывать ли отменённые заказы, которые так и не были выполнены, и по умолчанию они не учитываются. Отменённый заказ, который уже был отправлен, остаётся, потому что его доставка всё равно стоила вам денег. Для недавних заказов, которые ещё могут вернуться, настройка Predicted returns удерживает ожидаемую долю продаж, пока не поступят реальные возвраты.

Как ROASaurus работает с наложенным платежом и внешними чекаутами

Shopify

У каждого магазина Shopify есть параметр Checkout type в Store settings с двумя вариантами:

• Shopify checkout: покупка отправляется, когда Shopify сообщает, что заказ оплачен, через вебхук orders/paid.
• External / COD checkout: покупка отправляется при создании заказа через вебхук orders/create. Используйте его для наложенного платежа и для внешних чекаутов, например CheckoutChamp или Checkify, которые сами создают заказ в Shopify.

Настройка действует на каждый заказ в магазине. Заказы по карте, оплаченные в чекауте, создаются и оплачиваются почти одновременно, поэтому выбор в основном меняет момент отправки неоплаченных заказов. Каждый заказ отправляется один раз. Когда позже приходит обновление об оплате заказа с наложенным платежом, вторая покупка не отправляется.

Покупка использует собственные данные заказа: сумму, валюту, товары, а также email, телефон и адрес покупателя, хешированные до отправки. ROASaurus сопоставляет заказ с кликом по рекламе через visitor id, который его скрипт сохраняет в корзине. Если у заказа его нет, ROASaurus пробует по порядку: токены корзины и чекаута, событие покупки из чекаута, email, который посетитель ранее указал на вашем сайте, а также тот же IP-адрес и браузер незадолго до заказа, если подходит ровно один посетитель. Полная настройка описана на странице интеграции с Shopify.

WooCommerce и другие интернет-магазины

Плагин WooCommerce отправляет заказ, когда он получает статус Processing или Completed. Заказы с наложенным платежом получают Processing при оформлении, поэтому отправляются сразу. Заказы с банковским переводом отправляются, когда переходят в Processing. Остальные коннекторы интернет-магазинов отправляют заказ в такие моменты:

• Wix, Squarespace, Ecwid, Lightspeed, CCV Shop и Shopware: когда статус оплаты заказа — оплачен.
• BigCommerce: когда заказ получает статус, например Awaiting Fulfillment, Awaiting Shipment, Shipped или Completed.
• Magento: когда состояние заказа — Processing или Complete.
• PrestaShop: когда заказ отмечен как действительный.
• Собственный вебхук и API заказов: когда заказ отправляет ваша собственная система.

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

Воронки и собственный чекаут

1. Добавьте скрипт на страницы воронки

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

2. Перечислите свои домены

   В Store settings добавьте домены воронки и магазина в разделе Linked domains. Тогда ссылки между этими доменами будут передавать visitor id и click id.

3. Отправляйте заказы через API заказов

   Если воронка принимает заказ сама, отправляйте каждый заказ на /api/v1/orders с cookie _tl в качестве visitor_id. Момент выбирает ваша система: при создании, при подтверждении или при оплате.

4. Проверьте Event log

   Когда придут первые реальные заказы, откройте Event log и убедитесь, что каждый был отправлен на все подключённые платформы.

POST /api/v1/orders
X-Roasaurus-Key: <store key>
Authorization: Bearer <API key>
Content-Type: application/json

{
  "order_id": "F-20931",
  "created_at": "2026-10-20T14:05:00Z",
  "total": 50.00,
  "currency": "USD",
  "email": "buyer@example.com",
  "phone": "+15555550123",
  "country": "US",
  "visitor_id": "<value of the _tl cookie>",
  "click_ids": { "fbc": "<_fbc cookie>", "fbp": "<_fbp cookie>" },
  "client_ip": "203.0.113.7",
  "user_agent": "Mozilla/5.0 ...",
  "items": [{ "variant_id": "SKU1", "quantity": 1, "price": 50.00 }]
}

API заказов сохраняет первую копию каждого id заказа. Если ваша система вызывает его при создании и ещё раз при оплате, покупку отправляет только первый вызов. Подробнее — в материале воронки и несколько доменов.

Типичные ошибки, которых стоит избегать

• Ожидание статуса оплаты в магазине с наложенным платежом. Покупки приходят с опозданием на неделю или не приходят вовсе, а запоздавшие события отклоняются или выходят за окно атрибуции.
• Сравнение ROAS из Ads Manager с безубыточностью, рассчитанной для оплаченных заказов. Сначала разделите безубыточность на вашу долю оплаты.
• Два источника для одной покупки. Собственный пиксель приложения формы и ваши серверные события считают один и тот же заказ дважды. См. дублирующиеся события покупки.
• Потеря клика между доменами. Воронке на другом домене нужны скрипт и связанные домены, иначе её заказы приходят без клика по рекламе.
• Игнорирование ручных заказов. У заказов по телефону и в чате нет браузерной сессии, но у них всё равно есть адрес email или номер телефона. Отправленные из данных заказа, они дают рекламной платформе то, по чему можно сопоставлять.

Источники

1. Meta for Developers: Server Event Parameters
2. Shopify: WebhookSubscriptionTopic (GraphQL Admin API)
3. Shopify Help Center: Manual payment methods
4. Shopify Help Center: Understanding your order statuses
5. WooCommerce: Cash on Delivery documentation

В ROASaurus

• Интеграция с Shopify
• Интеграция с WooCommerce
• Справка: воронки и несколько доменов
• Аналитика прибыли в ROASaurus

Читайте дальше