Blochează blocantele de reclame pixelul Meta?

Multe blocante de reclame și browsere orientate spre confidențialitate îl blochează. Când scriptul este blocat, niciun eveniment din browser nu ajunge la Meta de la acel vizitator, dar achizițiile trimise server-side din datele comenzilor tale ajung în continuare.

Câți cumpărători folosesc blocante de reclame?

Depinde de publicul, dispozitivele și țările tale, așa că o cifră generală îți spune puține despre magazinul tău. Măsoară-ți propria diferență comparând comenzile web cu evenimentele Purchase trimise de pixelul tău în aceeași perioadă.

Pot blocantele de reclame să blocheze tracking-ul server-side?

Nu pot bloca achiziția trimisă din datele comenzii, pentru că acea cerere pleacă de la un server către API-ul platformei. Un blocant poate însă opri scriptul din browser care salvează click id-ul, motiv pentru care colectarea first-party contează.

Este un blocant de reclame același lucru cu refuzul consimțământului?

Nu. Refuzul consimțământului este o alegere făcută în bannerul tău de cookie-uri, pe care tracking-ul tău trebuie s-o respecte. Un blocant de reclame este un instrument din browser. Ambele reduc evenimentele pixelului, așa că măsoară-le separat.

Mai am nevoie de pixel dacă trimit achizițiile server-side?

Da, pentru vizitatorii fără blocant. Pixelul adaugă evenimente de navigare și cookie-uri din browser, iar cu același event id platforma păstrează o singură copie a fiecărei achiziții.

Blocantele de reclame și tracking-ul: ce pierde magazinul tău

Ideile principale

Blocantele de reclame folosesc liste de filtrare ca să oprească scripturile de pixel și cererile lor, așa că platforma de publicitate nu primește niciun eveniment de la acel browser.
Un pixel blocat pierde vizualizările de pagină, adăugările în coș și achizițiile, iar achiziția contează cel mai mult, pentru că determină ROAS-ul raportat și licitarea.
Achizițiile trimise server-side din datele comenzilor tale nu sunt afectate, pentru că browserul cumpărătorului nu le trimite.
Măsoară-ți propria diferență comparând comenzile web din magazinul tău cu evenimentele Purchase trimise de pixelul din browser, nu cu conversiile atribuite.
Tracking-ul server-side nu poate recupera evenimentele de navigare sau click id-urile care nu au fost salvate niciodată, iar colectarea first-party reduce această pierdere.

Blocantele de reclame opresc tracking-ul împiedicând încărcarea, în browserul cumpărătorului, a scriptului de pixel al platformei de publicitate sau a cererilor pe care acesta le trimite. Când se întâmplă asta, platforma nu află niciodată de vizualizarea paginii, de adăugarea în coș sau de achiziție, deși comanda există în magazinul tău. Achizițiile trimise server-side din datele comenzilor tale nu sunt afectate, pentru că browserul cumpărătorului nu participă la trimiterea lor.

Acest ghid explică cum funcționează blocantele de reclame și funcțiile de confidențialitate ale browserelor, ce evenimente pierde magazinul tău, ce recuperează tracking-ul server-side și ce nu poate recupera. Se încheie cu o metodă simplă de a măsura diferența în propriul magazin.

Cum opresc blocantele de reclame pixelii de tracking?

Majoritatea blocantelor de reclame funcționează cu liste de filtrare. O listă de filtrare este o listă lungă de reguli care se potrivesc cu adrese web: domenii, căi și nume de fișiere ale scripturilor cunoscute de reclame și de tracking. Când o pagină cere browserului să încarce ceva care se potrivește cu o regulă, blocantul anulează cererea.

Cele mai cunoscute liste sunt EasyList, pentru reclame, și EasyPrivacy, pentru tracking. Ele funcționează cu extensii precum Adblock Plus, AdBlock, uBlock Origin și AdGuard. Pixelul unei platforme mari de publicitate este o țintă ușoară pentru aceste liste, pentru că încarcă același script de pe același domeniu pe multe site-uri diferite.

Pagina se încarcăTema ta include scriptul de pixel al platformei de publicitate.

Blocantul verifică adresaAdresa scriptului se potrivește cu o regulă dintr-o listă de filtrare.

Cerere anulatăScriptul nu rulează niciodată, deci nu se creează niciun eveniment.

Platforma de publicitateNu primește nimic din această vizită.

Un pixel blocat nu trimite un eveniment mai slab. Nu trimite niciun eveniment.

Browsere cu protecție integrată

Unele browsere blochează trackerele fără extensie. Brave activează implicit Shields pentru fiecare site, iar Shields blochează reclamele third-party, trackerele și cookie-urile cross-site. Firefox blochează conținutul de la domeniile cunoscute de tracking cross-site în ferestrele private, iar utilizatorii pot alege setări mai stricte, care se aplică tuturor ferestrelor. Intelligent Tracking Prevention din Safari blochează toate cookie-urile third-party și scurtează durata de viață a cookie-urilor setate de scripturi. Ghidul nostru despre Safari ITP și tracking-ul reclamelor explică aceste limite.

Blocante la nivel de rețea

Unii oameni blochează trackerele pentru un întreg dispozitiv sau pentru toată rețeaua de acasă, cu un blocant bazat pe DNS sau cu un VPN care filtrează trackerele. Acestea opresc cererile către domeniile de tracking în orice browser și în orice aplicație din acea rețea. Schimbarea browserului nu schimbă rezultatul.

Ce evenimente pierde magazinul tău?

Când pixelul este blocat, fiecare eveniment pe care l-ar fi trimis din acel browser se pierde. Pagubele nu sunt aceleași pentru fiecare eveniment.

Eveniment	La ce se folosește	Se pierde când pixelul este blocat?	Îl pot înlocui datele comenzii?
PageView, ViewContent	Audiențe de vizitatori ai site-ului, retargeting de produse	Da	Nu
AddToCart, InitiateCheckout	Optimizare către cumpărătorii care încep o achiziție, retargeting pentru coș	Da	Nu
Purchase	Conversii raportate, ROAS, optimizarea pentru achiziții, licitare bazată pe valoare	Da	Da
Click id pe landing page	Legarea achiziției de click-ul exact pe reclamă	Da, când este blocat și scriptul de tracking	Nu, trebuie salvat în browser

Achiziția este cel mai valoros eveniment și este cel pe care datele comenzii îl pot înlocui întotdeauna.

Evenimentele de navigare pierdute îți micșorează audiențele de retargeting. Achizițiile pierdute fac mai mult rău. Platforma raportează mai puține conversii, ROAS-ul din raportul de reclame scade, iar algoritmul de licitare învață din mai puțini cumpărători. O campanie profitabilă poate părea atunci neprofitabilă, iar tu ai putea s-o oprești.

De ce evenimentele server-side din datele comenzilor nu sunt blocate

Un blocant de reclame rulează în browserul cumpărătorului. El poate opri doar cererile pe care le face browserul. Când achiziția este trimisă din datele comenzilor magazinului tău, cererea pleacă de la un server către API-ul platformei de publicitate. Browserul cumpărătorului nu face parte din acest traseu, deci blocantul nu are ce anula.

14:02:11 PageView pixelBlocat de o listă de filtrare din browser

14:09:47 Purchase pixel order-1042Niciodată trimis, pentru că scriptul de pixel nu s-a încărcat

14:09:52 webhook order-1042 paidMagazinul raportează comanda plătită către server

14:10:12 Purchase server order-1042Trimis către Conversions API, cu email și telefon cu hash

Exemplu: o vizită cu un blocant de reclame. Browserul nu trimite nimic, dar achiziția ajunge totuși la platformă din comandă.

Apoi platforma asociază achiziția cu o persoană pe baza datelor din eveniment: emailul și telefonul cu hash din comandă, adresa IP și user agent-ul, plus click id-ul, dacă a fost salvat unul. Nimic din toate acestea nu trece prin blocant. Pentru traseul complet al datelor, citește ce este tracking-ul server-side.

Ce nu poate recupera tracking-ul server-side?

Click id-ul depinde de browser

Comanda în sine este în siguranță, dar legătura cu click-ul pe reclamă se face în browser. Un script trebuie să citească click id-ul din URL-ul de landing page și să-l salveze. Dacă un blocant de reclame blochează și acel script, comanda ajunge fără click id. Platforma poate asocia în continuare achiziția prin datele de client cu hash, dar potrivirea este mai puțin sigură.

Două lucruri reduc această pierdere. În primul rând, colectează evenimentele first-party: servește scriptul de tracking și cererile lui de pe propriul domeniu, de exemplu printr-un app proxy Shopify sau printr-un subdomeniu al site-ului tău. Listele de filtrare vizează adresele de tracking third-party cunoscute, așa că o cale first-party este mult mai greu de blocat, deși nu imposibil. În al doilea rând, folosește landing page-ul pe care unele magazine online, precum Shopify, îl salvează împreună cu fiecare comandă. Dacă acel URL conține încă click id-ul sau UTM-urile, comanda poate fi atribuită fără niciun eveniment din browser.

Evenimentele de navigare se pierd în continuare

Datele comenzilor conțin comenzi, nu vizualizări de pagină. Trimiterea achizițiilor din comenzi nu recuperează vizualizările de pagină și evenimentele de adăugare în coș ale unui vizitator al cărui browser a blocat totul. Un colector first-party poate redirecționa aceste evenimente de pe server atunci când propriile lui cereri trec.

Refuzul consimțământului nu înseamnă blocare

Un vizitator care refuză cookie-urile de marketing în bannerul tău de cookie-uri nu este același lucru cu un vizitator care folosește un blocant de reclame. Primul vizitator a făcut o alegere pe care tracking-ul tău trebuie s-o respecte. Cu Respect visitor consent activat, ROASaurus nu setează niciun id de vizitator pentru acel vizitator, deci click-urile lui pe reclame și vizitele lui nu sunt legate de el. Evenimentele lui din browser sunt păstrate fără id de vizitator, adresă IP sau detalii despre browser și nu sunt trimise către platformele de publicitate. Comanda plătită este totuși trimisă server-side, cu datele de client cu hash din comandă și cu adresa IP și user agent-ul comenzii. Ține cele două grupuri separate când îți măsori pierderea și vezi consimțământul și confidențialitatea pentru detalii.

Cum îți estimezi propria pierdere

Nu ai nevoie de medii din industrie, care depind de public, dispozitiv și țară. Îți poți măsura propria diferență comparând comenzile din magazinul tău cu achizițiile raportate de pixelul din browser pentru aceeași perioadă.

Alege o perioadă și o platformă
Folosește 14 sau 30 de zile și o singură platformă, de exemplu Meta. Folosește același fus orar în ambele sisteme.
Numără comenzile web din magazinul tău
Pornește de la toate comenzile. Elimină comenzile care nu trec niciodată prin checkout-ul tău online: comenzile de la punctul de vânzare, cele manuale și ciornele, reînnoirile de abonamente și comenzile de test.
Numără evenimentele Purchase din browser
În instrumentul de evenimente al platformei, numără evenimentele Purchase trimise de pixelul din browser. Cel mai simplu este înainte să adaugi evenimente server. Dacă evenimentele server rulează deja, folosește vizualizarea pe metodă de conexiune a platformei, acolo unde există una. Meta Events Manager arată metoda de conexiune a fiecărui eveniment și numără acolo evenimentele înainte de deduplicare. Nu folosi achizițiile atribuite din raportul de reclame.
Împarte
Achiziții din browser ÷ comenzi web este ponderea pe care a văzut-o pixelul. Restul este diferența ta.
Separă consimțământul de blocare
Estimează comenzile vizitatorilor care au refuzat cookie-urile de marketing, folosind rata de refuz din instrumentul tău de consimțământ. Ce rămâne ține mai ales de blocantele de reclame, de setările de confidențialitate și de paginile care nu s-au încărcat.

Magazin exemplu, 30 de zile	Comenzi	Pondere din comenzile web
Toate comenzile din magazin	1,240
Comenzi de la punctul de vânzare, manuale și de reînnoire	−90
Comenzi web	1,150	100%
Evenimente Purchase de la pixelul din browser	874	76%
Diferență	276	24%
Comenzi estimate de la vizitatori care au refuzat consimțământul (rată de refuz de 10%)	115	10%
Rămân: blocantele de reclame, setările de confidențialitate, paginile care nu s-au încărcat	161	14%

În acest magazin exemplu, pixelul ratează aproximativ 1 din 4 comenzi web. Aproximativ 1 din 7 se pierde din cauza blocării și a erorilor din browser, nu a consimțământului.

Diferența schimbă și ROAS-ul. Să presupunem că Meta raportează un ROAS de 2.0 pentru acest magazin, iar ROAS-ul lui de break-even este 2.3. Pe baza datelor din pixel, campaniile pierd bani. Dacă comenzile generate de reclame au fost ratate în aceeași proporție de 24% ca toate comenzile web, pixelul a văzut doar 76% din veniturile din reclame. ROAS-ul real ar fi atunci de aproximativ 2.0 ÷ 0.76 = 2.6, peste break-even. Aceasta este o estimare maximă, pentru că nu fiecare comandă lipsă a venit dintr-o reclamă. Ghidul nostru despre ROAS-ul de break-even explică cum stabilești acest prag.

Cum reduci ce pierzi

Soluțiile sunt aceleași pentru orice platformă de magazin online. Funcționează cel mai bine împreună.

Trimite achizițiile din datele comenzilor. Aceasta închide diferența de achiziții pentru fiecare platformă pe care o conectezi, indiferent ce blochează browserul vizitatorului.
Păstrează pixelul, cu un event id comun. Vizitatorii fără blocant trimit în continuare evenimente din browser, cu cookie-uri și context de pagină. Același event id pe ambele copii îi permite platformei să păstreze una singură. Vezi cum eviți numărarea dublă.
Colectează first-party. Servește scriptul de tracking și evenimentele lui de pe propriul tău domeniu, astfel încât click id-urile să fie salvate pentru mai mulți vizitatori.
Trimite datele de client cu hash. Emailul și telefonul din comandă permit platformei să asocieze achizițiile care nu au click id.
Măsoară din nou. Repetă comparația peste o lună. Evenimentele Purchase primite de platformă ar trebui să corespundă acum comenzilor tale web.

Magazin exemplu: evenimente Purchase primite de Meta în 30 de zile

Doar pixelPixel + server, deduplicat

Evenimente Purchase

874

1,150

După ce achizițiile sunt trimise din datele comenzilor, toate cele 1,150 de comenzi web ajung la platformă. Pixelul adaugă în continuare date din browser pentru cele 874 de comenzi pe care le-a văzut.

Cum gestionează ROASaurus blocantele de reclame

ROASaurus trimite fiecare comandă plătită server-side către platformele de publicitate pe care le adaugi în Tracking & platforms, așa că un blocant de reclame din browserul cumpărătorului nu oprește achiziția. Pe Shopify, evenimentele din vitrină trec prin app proxy-ul Shopify de pe propriul tău domeniu. Poți servi scriptul și evenimentele lui și de pe un subdomeniu CNAME al site-ului tău. Când un vizitator nu are niciun touch în browser, atribuirea ROASaurus se bazează pe click id-urile și UTM-urile din URL-ul de landing page al comenzii, dacă magazinul îl înregistrează, cum face Shopify.

Fiecare livrare și răspunsul platformei sunt listate în Event log, așa că poți verifica dacă fiecare comandă a ajuns la fiecare platformă. Vezi tracking-ul server-side și integrarea Shopify pentru configurare.

Surse

În ROASaurus

Continuă lectura

TrackingConsent Mode v2 și GDPR: ce are voie să trimită un magazin onlineConsent Mode v2 pentru magazine online: cele patru semnale de consimțământ Google, ce cere legislația UE și ce mai poate trimite tracking-ul server-side. Doar informații generale.TrackingEvenimente de achiziție duplicate: de ce vânzările sunt numărate de două oriEvenimentele de achiziție duplicate umflă conversiile și ROAS-ul. Vezi cauzele, cum deduplică Meta, TikTok, Snapchat, Pinterest și Reddit și cum remediezi problema.TrackingSafari ITP și tracking-ul reclamelor: ce mai funcționeazăSafari ITP limitează la 7 zile cookie-urile setate de scripturi, sau la 24 de ore după unele click-uri pe reclame. Vezi ce efect are asupra atribuirii și ce tracking mai funcționează.