- Pixelii din browser pierd comenzile care se finalizează în afara checkout-ului obișnuit, cum ar fi formularele de plată ramburs, checkout-urile externe, formularele de comandă și funnelurile.
- O comandă cu plata ramburs rămâne neplătită până când curierul încasează banii, așa că o configurare care trimite achizițiile la plată o raportează târziu sau deloc.
- Meta respinge evenimentele cu o oră a evenimentului mai veche de 7 zile, așa că majoritatea magazinelor cu plata ramburs ar trebui să trimită achiziția când comanda este creată sau confirmată.
- Comenzile refuzate rămân în Ads Manager, așa că împarte ROAS-ul de break-even la ponderea comenzilor care ajung să fie plătite.
- În ROASaurus, alege External / COD checkout în Store settings ca să trimiți achizițiile Shopify când comanda este creată.
Tracking-ul conversiilor pentru plata ramburs înseamnă trimiterea fiecărei achiziții către platformele tale de publicitate din comanda însăși, de pe server, în loc să te bazezi pe un pixel din browser de pe o pagină de mulțumire. Comenzile din aplicațiile de plată ramburs, din checkout-urile externe, din formularele de comandă și din funnelurile de vânzare se finalizează adesea în afara checkout-ului obișnuit, așa că pixelul le pierde sau le raportează în momentul greșit.
Acest ghid explică de ce dispar aceste comenzi și de ce contează statusul plății. Compară trei momente în care poți trimite achiziția: când comanda este creată, când este confirmată și când este plătită. Acoperă și comenzile refuzate și rambursările, precum și felul în care ROASaurus gestionează checkout-urile externe.
De ce pierd pixelii comenzile cu plata ramburs?
Un pixel din browser raportează o achiziție atunci când cumpărătorul ajunge pe o pagină care îl rulează. De obicei este pagina de mulțumire a checkout-ului tău. Fiecare traseu de comandă care sare peste această pagină sau o rulează pe alt domeniu pierde evenimentul de achiziție sau click-ul pe reclamă care îi aparține.
| Traseul comenzii | Unde se finalizează comanda | Ce merge prost cu un pixel din browser |
|---|---|---|
| Aplicație cu formular de plată ramburs | Un formular pe pagina produsului; aplicația creează comanda | Checkout-ul magazinului nu rulează niciodată, deci evenimentul lui de achiziție nu se declanșează niciodată |
| Checkout extern | Un checkout rulat de o altă aplicație, adesea pe alt domeniu | Pixelul tău poate să nu se încarce acolo, iar cookie-urile click-ului pe reclamă rămân pe domeniul magazinului tău |
| Formular de comandă sau comandă manuală | Un formular, un chat sau un apel telefonic; comanda este introdusă de personal | Nu există nicio sesiune de browser pe care s-o vadă un pixel |
| Funnel cu propriul checkout | Un builder de landing page-uri pe propriul domeniu | Click-ul pe reclamă este pe un domeniu, iar achiziția pe altul |
Comanda în sine nu se pierde niciodată. Ajunge în magazinul tău online sau în instrumentul tău de funnel, cu un id de comandă, o sumă, o adresă de email și adesea un număr de telefon. De aceea soluția fiabilă este să trimiți achiziția din datele comenzii, server-side, și să transmiți click-ul pe reclamă până la comandă. Tracking-ul server-side pe Shopify explică metoda generală. Acest articol tratează comenzile care necesită mai multă atenție.
Unele aplicații de plată ramburs declanșează și propriile evenimente de pixel. Dacă folosesc același pixel ca tracking-ul tău server-side, dar un event id diferit, platforma numără comanda de două ori. Dezactivează acele evenimente ale aplicației sau urmează pașii pentru a evita numărarea dublă.
De ce contează statusul plății
O plată cu cardul este încasată în checkout, deci comanda este plătită din momentul în care există. O comandă cu plata ramburs este diferită. Shopify listează plata ramburs ca metodă de plată manuală, iar aceste comenzi rămân Payment pending până când le marchezi ca plătite. În practică, asta se întâmplă după ce curierul încasează banii, ceea ce poate dura zile. Unele comenzi nu sunt plătite deloc, pentru că cumpărătorul refuză coletul sau nu este acasă.
Multe configurări de tracking trimit achiziția atunci când comanda este plătită, pentru că pentru comenzile cu cardul acesta este cel mai sigur moment. Pentru o comandă cu plata ramburs, aceeași regulă înseamnă că achiziția ajunge cu zile întârziere sau deloc. Jurnalul de mai jos arată un caz tipic într-un magazin care trimite achizițiile la plată.
14 Oct 10:02 orders/create #4821 $50.00Comandă plasată cu plata ramburs, plată în așteptare14 Oct 10:02 PurchaseNetrimis: acest magazin trimite achizițiile la plată16 Oct 09:40 #4821 shippedColet predat curierului22 Oct 15:12 orders/paid #4821Marcat ca plătit după ce curierul a virat banii22 Oct 15:12 Purchase event_time=14 OctRespins: ora evenimentului este mai veche de 7 zileWooCommerce funcționează invers. Setează comenzile cu plata ramburs pe Processing până la încasarea plății, cu excepția comenzilor cu un produs descărcabil, care merg pe On hold. O configurare care trimite comenzile aflate în Processing le trimite deci imediat ce sunt plasate. Verifică ce status dă platforma ta acestor comenzi înainte să decizi orice altceva.
Create, confirmate sau plătite: când ar trebui să trimiți achiziția?
Poți alege dintre trei momente. Fiecare schimbă viteza pe acuratețe.
| Trimite achiziția când comanda este | Întârziere tipică după comandă | Include comenzi care nu sunt niciodată plătite | Riscul principal |
|---|---|---|---|
| Creată | Secunde | Da: refuzuri și comenzi false | Ads Manager arată mai multe venituri decât încasezi |
| Confirmată de echipa ta, prin telefon sau mesaj | De la câteva ore la o zi | Doar refuzuri | Necesită un pas de confirmare care poate declanșa evenimentul |
| Plătită sau livrată | De la zile la săptămâni | Nu | Târziu sau pierdut: click-ul pe reclamă iese din fereastra de atribuire sau evenimentul este respins |
De ce sunt o problemă evenimentele de achiziție întârziate
Platformele de publicitate atribuie o achiziție unei reclame doar dacă aceasta are loc în fereastra de atribuire de după click. Cu o setare de atribuire de 7 zile după click în Meta, o achiziție se atribuie unei reclame până la 7 zile după click. Meta Conversions API refuză, de asemenea, evenimentele al căror event_time este mai vechi de 7 zile și respinge întreaga cerere dacă un singur eveniment este prea vechi. O achiziție trimisă la plată are deci două opțiuni proaste:
- Trimite-o cu ora comenzii. Dacă plata a venit la mai mult de 7 zile după aceea, Meta o respinge.
- Trimite-o cu ora plății. Meta o acceptă, dar click-ul pe reclamă poate avea acum mai mult de 7 zile, așa că achiziția nu este atribuită reclamei.
Viteza contează și pentru optimizare. Campaniile care optimizează pentru achiziții învață din achizițiile pe care le trimiți. Un semnal care ajunge cu o săptămână întârziere îi spune algoritmului despre publicul de săptămâna trecută.
Ce moment să alegi
Pentru majoritatea magazinelor cu plata ramburs, trimiterea la creare este varianta implicită mai bună. Semnalul este imediat, click-ul este încă în fereastră și nimic nu este respins. Prețul este că, în Ads Manager, comenzile refuzate se numără ca achiziții. Corectezi asta în țintele tale, așa cum arată secțiunea următoare.
Dacă echipa ta confirmă fiecare comandă prin telefon sau mesaj înainte de expediere, confirmarea este un compromis bun. Elimină comenzile false și are loc, de obicei, în decurs de o zi. Folosește-o atunci când sistemul tău poate trimite achiziția în acel moment, de exemplu printr-un API. Comenzile false contează mai mult decât pare: dacă platforma de publicitate învață din ele, caută mai multe persoane care plasează comenzi și nu plătesc.
Cum gestionezi comenzile refuzate, anulările și rambursările
Odată trimisă, o achiziție rămâne în Ads Manager. Un colet refuzat la ușă nu o elimină. Nici ROASaurus nu trimite rambursări sau anulări către Meta, TikTok și majoritatea celorlalte platforme de publicitate, așa că veniturile raportate de ele includ comenzi pe care nu le-ai încasat niciodată. Doar valorile din Google Ads și Microsoft Advertising pot fi corectate după o rambursare, când corecțiile de valoare sunt activate. Soluția este să îți măsori rata de refuz și să ajustezi cifrele cu care compari.
Iată un exemplu calculat pentru o lună. Ca să fie simplu, prețurile sunt fără TVA.
| Linie | Sumă |
|---|---|
| Comenzi trimise către Meta la creare | 200 de comenzi × $50 = $10,000 |
| Refuzate la ușă (18%) | 36 de comenzi, $1,800 |
| Livrate și plătite | 164 de comenzi, $8,200 |
| Costul produselor pentru comenzile livrate (30%) | −$2,460 |
| Livrare pentru toate cele 200 de colete la $6 | −$1,200 |
| Transport retur pentru cele 36 de colete refuzate la $6 | −$216 |
| Comision de încasare a banilor, $1.50 pe comandă plătită | −$246 |
| Handling, $1 pe comandă | −$200 |
| Profit brut | $3,878 |
Cu $3,000 cheltuiți pe reclame, aceeași lună arată foarte diferit, în funcție de veniturile pe care le folosești:
Rata marjei brute pentru veniturile livrate este $3,878 ÷ $8,200 = 47.3%, deci ROAS-ul de break-even este 1 ÷ 0.473 = 2.11. Acest break-even se aplică veniturilor livrate. Ads Manager numără și comenzile refuzate, așa că trebuie să-l convertești înainte de comparație. ROAS-ul de break-even explică formula de bază.
- ROAS de break-even
- 1 ÷ rata marjei brute, calculată doar pe comenzile plătite.
- Rata de plată
- Ponderea comenzilor care sunt plătite, de exemplu 82% atunci când 18% sunt refuzate.
2.114 ÷ 0.82 = 2.58. O campanie care arată sub 2.58 în Ads Manager pierde bani, chiar dacă pare cu mult peste 2.11.
Poți verifica direct rezultatul. Reclamele ies la break-even când cheltuielile cu reclamele sunt egale cu profitul brut de $3,878, iar $10,000 venituri raportate ÷ $3,878 = 2.58.
Ratele de refuz diferă adesea în funcție de regiune, produs și campanie. Calculează-le pe campanie atunci când ai suficiente comenzi și folosește calculatorul POAS ca să verifici rezultatul pe profitul brut.
Rambursările și anulările în propriile tale cifre
Pe Shopify, anulările și rambursările ajung la ROASaurus prin webhook, așa că analiza profitului scade rambursările din venituri. Tu alegi dacă se iau în calcul comenzile anulate care nu au fost niciodată expediate; implicit, ele sunt excluse. O comandă anulată care fusese deja expediată rămâne inclusă, pentru că livrarea ei te-a costat totuși bani. Pentru comenzile recente care pot încă reveni, setarea Predicted returns reține o pondere estimată din vânzări până când sosesc rambursările reale.
Cum gestionează ROASaurus plata ramburs și checkout-urile externe
Shopify
Fiecare magazin Shopify are un Checkout type în Store settings, cu două opțiuni:
- Shopify checkout: achiziția este trimisă când Shopify raportează comanda ca plătită, prin webhook-ul
orders/paid. - External / COD checkout: achiziția este trimisă când comanda este creată, prin webhook-ul
orders/create. Folosește-l pentru plata ramburs și pentru checkout-urile externe, cum ar fi CheckoutChamp sau Checkify, care creează singure comanda Shopify.
Setarea se aplică fiecărei comenzi din magazin. Comenzile cu cardul, plătite în checkout, sunt create și plătite aproape în același moment, așa că alegerea schimbă în principal momentul în care sunt trimise comenzile neplătite. Fiecare comandă este trimisă o singură dată. Când actualizarea de plată pentru o comandă cu plata ramburs sosește mai târziu, nu se trimite o a doua achiziție.
Achiziția folosește datele proprii ale comenzii: suma, moneda, produsele și emailul, telefonul și adresa cumpărătorului, transformate în hash înainte să plece. ROASaurus asociază comanda cu click-ul pe reclamă prin id-ul de vizitator pe care scriptul său îl salvează pe coș. Când o comandă nu îl are, ROASaurus încearcă, în această ordine: token-urile de coș și de checkout, evenimentul de achiziție din checkout, un email pe care vizitatorul l-a dat mai devreme pe site-ul tău și aceeași adresă IP și același browser cu puțin timp înainte de comandă, atunci când se potrivește exact un vizitator. Pagina integrării Shopify conține configurarea completă.
WooCommerce și alte magazine online
Pluginul WooCommerce trimite o comandă imediat ce ajunge în Processing sau Completed. Comenzile cu plata ramburs ajung în Processing când sunt plasate, deci sunt trimise imediat. Comenzile cu transfer bancar sunt trimise când trec în Processing. Ceilalți conectori de magazine online trimit o comandă în aceste momente:
- Wix, Squarespace, Ecwid, Lightspeed, CCV Shop și Shopware: când statusul de plată al comenzii este plătit.
- BigCommerce: când comanda ajunge într-un status precum Awaiting Fulfillment, Awaiting Shipment, Shipped sau Completed.
- Magento: când starea comenzii este Processing sau Complete.
- PrestaShop: când comanda este marcată ca validă.
- Webhook personalizat și API-ul de comenzi: când propriul tău sistem trimite comanda.
Verifică cum marchează platforma ta comenzile cu plata ramburs. Dacă rămân neplătite până când curierul virează banii, achizițiile lor ajung târziu.
Funnelurile și propriul tău checkout
- Adaugă scriptul pe paginile funnelului
Folosește aceeași cheie de magazin ca magazinul tău online, astfel încât un vizitator să păstreze același id de vizitator pe ambele domenii.
- Listează-ți domeniile
În Store settings, adaugă domeniile funnelului și ale magazinului în Linked domains. Linkurile dintre aceste domenii poartă apoi id-ul de vizitator și click id-urile.
- Trimite comenzile prin API-ul de comenzi
Dacă funnelul preia singur comanda, trimite fiecare comandă către
/api/v1/orderscu cookie-ul_tlcavisitor_id. Sistemul tău decide momentul: la creare, la confirmare sau la plată. - Verifică Event log
Când sosesc primele comenzi reale, deschide Event log și verifică dacă fiecare a fost trimisă către fiecare platformă conectată.
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-ul de comenzi păstrează prima copie a fiecărui id de comandă. Dacă sistemul tău îl apelează la creare și din nou la plată, doar primul apel trimite o achiziție. Mai multe detalii găsești la funnelurile și domeniile multiple.
Greșeli frecvente de evitat
- Așteptarea statusului plătit într-un magazin cu plata ramburs. Achizițiile ajung cu o săptămână întârziere sau deloc, iar evenimentele întârziate sunt respinse sau ies din fereastra de atribuire.
- Compararea ROAS-ului din Ads Manager cu un break-even calculat pentru comenzile plătite. Împarte mai întâi break-even-ul la rata ta de plată.
- Două surse pentru aceeași achiziție. Pixelul propriu al unei aplicații de formulare și evenimentele tale server numără aceeași comandă de două ori. Vezi evenimentele de achiziție duplicate.
- Pierderea click-ului între domenii. Un funnel pe alt domeniu are nevoie de script și de domenii asociate, altfel comenzile lui ajung fără click pe reclamă.
- Excluderea comenzilor manuale. Comenzile prin telefon și chat nu au sesiune de browser, dar au totuși o adresă de email sau un număr de telefon. Trimise din datele comenzii, ele oferă platformei de publicitate ceva cu care să le asocieze.
Surse
- Meta for Developers: Server Event Parameters
- Shopify: WebhookSubscriptionTopic (GraphQL Admin API)
- Shopify Help Center: Manual payment methods
- Shopify Help Center: Understanding your order statuses
- WooCommerce: Cash on Delivery documentation
În ROASaurus
- Integrare Shopify
- Integrare WooCommerce
- Ajutor: funnel-uri și mai multe domenii
- Analiza profitului în ROASaurus