Проследяване на конверсии при плащане при доставка и външни страници за плащане

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

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

Защо пикселите пропускат поръчки с плащане при доставка?

Пикселът в браузъра отчита покупка, когато купувачът достигне страница, която го изпълнява. Това обикновено е страницата за благодарност след плащане във вашия магазин. Всеки път на поръчка, който прескача тази страница или я изпълнява в друг домейн, губи събитието за покупка или свързаното с него кликване върху реклама.

Самата поръчка никога не се губи. Тя се озовава във вашия онлайн магазин или във вашия инструмент за фунии с ID на поръчката, сума, имейл адрес и често телефонен номер. Затова надеждното решение е да изпращате покупката от данните за поръчката, от страна на сървъра, и да пренасяте кликването върху реклама до поръчката. Проследяването от страна на сървъра в Shopify обяснява общия метод. Тази публикация се занимава с поръчките, които изискват допълнително внимание.

Някои приложения за плащане при доставка задействат и свои собствени събития на пиксела. Ако използват същия пиксел като проследяването ви от страна на сървъра, но с друг 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 чрез webhook, така че анализът на печалбата изважда възстановените суми от приходите. Вие избирате дали анулираните поръчки, които никога не са били изпълнени, да се отчитат, и по подразбиране те са изключени. Анулирана поръчка, която вече е била изпратена, остава, защото доставката ѝ все пак ви е струвала пари. За скорошни поръчки, които все още може да бъдат върнати, настройката Predicted returns задържа очаквания дял от продажбите, докато пристигнат реалните възстановявания.

Как ROASaurus се справя с плащането при доставка и външните страници за плащане

Shopify

Всеки магазин в Shopify има Checkout type в Store settings с две опции:

• Shopify checkout: покупката се изпраща, когато Shopify съобщи, че поръчката е платена, чрез webhook-а orders/paid.
• External / COD checkout: покупката се изпраща, когато поръчката е създадена, чрез webhook-а orders/create. Използвайте го за плащане при доставка и за външни страници за плащане, като CheckoutChamp или Checkify, които сами създават поръчката в Shopify.

Настройката важи за всяка поръчка в магазина. Поръчките с карта, платени на страницата за плащане, се създават и плащат почти в един и същ момент, така че изборът променя главно кога се изпращат неплатените поръчки. Всяка поръчка се изпраща веднъж. Когато по-късно пристигне актуализацията за плащане на поръчка с плащане при доставка, втора покупка не се изпраща.

Покупката използва собствените данни на поръчката: сумата, валутата, продуктите, както и имейла, телефона и адреса на купувача, хеширани, преди да напуснат системата. ROASaurus съпоставя поръчката с кликването върху реклама чрез ID на посетителя, което скриптът му запазва в количката. Когато поръчката не го носи, ROASaurus опитва в този ред: токените на количката и на страницата за плащане, събитието за покупка от страницата за плащане, имейл, който посетителят е въвел по-рано във вашия сайт, и същия 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: когато поръчката е маркирана като валидна.
• Персонализиран webhook и API за поръчките: когато вашата собствена система изпрати поръчката.

Проверете как вашата платформа маркира поръчките с плащане при доставка. Ако остават неплатени, докато куриерът не преведе парите, покупките им пристигат късно.

Фунии и собствена страница за плащане

1. Добавете скрипта към страниците на фунията

   Използвайте същия ключ на магазина като вашия онлайн магазин, така че посетителят да запази едно ID на посетителя и в двата домейна.

2. Посочете домейните си

   В Store settings добавете домейните на фунията и на магазина под Linked domains. Връзките между тези домейни след това носят ID на посетителя и click ID-тата.

3. Изпращайте поръчките през API за поръчките

   Ако фунията приема поръчката сама, изпращайте всяка поръчка към /api/v1/orders с бисквитката _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 с точка на рентабилност, изчислена за платени поръчки. Първо разделете точката на рентабилност на процента на платените поръчки.
• Два източника за една покупка. Собственият пиксел на приложението за формуляри и вашите събития от сървъра отчитат една и съща поръчка два пъти. Вижте дублираните събития за покупка.
• Загубване на кликването между домейните. Фуния в друг домейн се нуждае от скрипта и от свързани домейни, иначе поръчките ѝ пристигат без кликване върху реклама.
• Пропускане на ръчните поръчки. Поръчките по телефон и чат нямат сесия в браузъра, но все пак имат имейл адрес или телефонен номер. Изпратени от данните за поръчката, те дават на рекламната платформа нещо, с което да съпостави.

Източници

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

Продължете да четете