Konversijų sekimo specialistas - Meta CAPI, GA4, server-side
Meta Events Manager rodo 40 pirkimų, GA4 - 28, o užsakymų sąraše jų 33. Taip nutinka, kai konversijų duomenys reklamos platformas pasiekia tik per naršyklę: ad blocker'iai, iOS apribojimai, sutikimo baneriai ir skriptų klaidos dalį įvykių numeta, o kiti užsiskaito po du kartus.
Esu Rytis Balys, server-side konversijų sekimo inžinierius. Dirbu iš Vilniaus, klientai - visame pasaulyje. Žemiau - kaip per 20 minučių patiems pasitikrinti, ar jūsų tracking sveikas, ir ką darau, kai jis nesveikas.
Kodėl sulaužytas tracking kainuoja pinigus
Meta ir Google algoritmai kampanijas optimizuoja pagal tą purchase signalą, kurį gauna. Ne pagal realius užsakymus - pagal signalą.
- Kai įvykių trūksta, algoritmas mokosi iš mažesnės imties, kampanijos ilgiau stringa mokymosi fazėje (learning phase), CPA atrodo blogesnis nei yra, ir jūs išjungiate kampanijas, kurios iš tikrųjų uždirba.
- Kai įvykiai dubliuojasi, ROAS ataskaitose atrodo dvigubai geresnis nei realybėje. Keliate biudžetą kampanijai, kuri nuostolinga, ir tai pamatote tik banko išraše.
- Kai atribucija kreiva, GA4 nuopelnus priskiria ne tiems kanalams. Įprasta pasekmė - nurėžtas el. pašto ar prekės ženklo paieškos biudžetas, kuris iš tikrųjų ir nešė pardavimus.
Kuo mažesnis biudžetas, tuo brangesnė kiekviena tokia klaida - algoritmui kiekvienas signalas sveria daugiau.
Pasitikrinkite patys per 20 minučių
Atskaitos taškas visada tas pats - realūs užsakymai jūsų sistemoje (Shopify, WooCommerce, CRM). Ne platformų ataskaitos.
- 1. Suskaičiuokite tiesą. Backend užsakymai per paskutines 30 dienų, be atšauktų ir testinių. Šis skaičius - etalonas.
- 2. Meta Events Manager. Atsidarykite savo pixelį ir pažiūrėkite Purchase įvykių kiekį per tą patį laikotarpį. Lyginkite įvykių kiekį, ne kampanijų konversijų stulpelį - kampanijų skaičiai priklauso nuo atribucijos lango ir su backend niekada nesutaps vienas prie vieno. Įvykių kiekis sutapti turi, plius minus keli procentai.
- 3. Testinis pirkimas per Test Events. Events Manager skiltyje Test Events atlikite testinį užsakymą. Purchase turi atvykti vieną kartą. Jei naudojate ir pixel, ir Conversions API, matysite du įrašus - browser ir server - ir serverio įvykis turi būti pažymėtas kaip deduplikuotas pagal sutampantį event_id. Du įrašai be deduplikacijos reiškia, kad kiekvienas pirkimas skaičiuojasi dvigubai.
- 4. GA4 DebugView. Įjunkite Tag Assistant (tagassistant.google.com) preview režimą, GA4 eikite į Admin, DebugView, ir pakartokite pirkimą. Turi atvykti purchase įvykis su transaction_id ir teisinga value.
- 5. Naršyklės Network skirtukas. F12, Network, filtruokite pagal facebook.com/tr (pixel) ir /g/collect su en=purchase (GA4; jei jau naudojate sGTM, užklausa eis į jūsų subdomeną). Užsakymo patvirtinimo puslapyje paspauskite refresh: jei purchase iššauna dar kartą, kiekvienas to puslapio perkrovimas jums kuria fiktyvų pardavimą.
Jei bent viename žingsnyje skaičiai išsiskiria daugiau nei keliais procentais, problemą turite.
Ką darau
Keturios paslaugos, visos apie tą patį - kad platformos matytų tikrus skaičius.
- Tracking auditas. Sutikrinu Meta, Google Ads ir GA4 duomenis su realiais backend užsakymais. Gaunate dokumentą: kur duomenys dingsta, kur dubliuojasi, kiek tai kainuoja ir ką taisyti pirmiausia.
- Server-side tracking. Meta Conversions API su event_id deduplikacija, GA4 per server-side GTM (sGTM ant Stape arba jūsų infrastruktūros). Įvykiai siunčiami iš serverio, todėl jų nebenumuša ad blocker'iai ir naršyklių apribojimai.
- Gaisrų gesinimas. Pixelis nešaudo po temos ar checkout atnaujinimo, konversijos nuliuose, dvigubi pirkimai, purchase be vertės - randu priežastį ir sutvarkau.
- Consent Mode v2. Sutvarkau, kad sutikimo signalai (ad_user_data, ad_personalization) Google žymes pasiektų teisingai ir ES srauto konversijos nedingtų vien dėl blogai sukonfigūruoto banerio.
Dažniausios klaidos, kurias randu audituose
- Pixel ir CAPI abu siunčia Purchase, bet be sutampančio event_id - kiekvienas užsakymas Meta pusėje tampa dviem.
- Purchase pririštas prie padėkos puslapio URL ir iššauna kaskart jį perkrovus ar atsidarius iš išsaugotos nuorodos.
- Siunčiama ne ta value: avansas vietoj pilnos užsakymo sumos, arba suma be PVM viename įrankyje ir su PVM kitame - skaičiai niekada nesutaps.
- Dvi GA4 instaliacijos vienu metu, pavyzdžiui, per platformos integraciją ir per GTM - dvigubos puslapių peržiūros ir dvigubi pirkimai.
- Consent baneris blokuoja žymes net ir gavus sutikimą - konversijos iš ES srauto tyliai dingsta, nors lankytojai sutiko būti skaičiuojami.
- Testiniai ir atšaukti užsakymai skaičiuojami kaip tikri, todėl platformos rodo daugiau nei bankas.
D.U.K.
Kodėl Meta Ads rodo daugiau pirkimų negu turiu užsakymų?
Dvi dažniausios priežastys: pixel ir Conversions API siunčia tą patį pirkimą be event_id deduplikacijos, arba purchase įvykis iššauna kaskart perkrovus padėkos puslapį. Pasitikrinkite Events Manager skiltyje Test Events - testinis pirkimas turi užsiskaityti vieną kartą.
Ar mažai parduotuvei reikia server-side tracking?
Jei mokate už reklamą - taip. Vien naršyklinis pixel dalį įvykių praranda dėl ad blocker'ių ir iOS apribojimų, o kuo mažesnis biudžetas, tuo kiekvienas prarastas signalas algoritmui kainuoja daugiau. sGTM hostingas, pavyzdžiui Stape, kainuoja mažiau nei vienas prarastas užsakymas per mėnesį.
Kas yra event_id deduplikacija?
Kai tas pats pirkimas siunčiamas ir iš naršyklės (pixel), ir iš serverio (Conversions API), abu įvykiai turi turėti tą patį pavadinimą ir tą patį event_id - tada Meta juos sujungia į vieną. Be šito Meta mato du pirkimus vietoj vieno, ir ROAS ataskaitose išpūstas dvigubai.
Kiek trunka ir kaip atrodo tracking auditas?
Man reikia prieigos prie Events Manager, GA4 ir užsakymų sąrašo skaitymo teisėmis. Per kelias darbo dienas gaunate dokumentą su sutikrintais skaičiais, rastų klaidų sąrašu ir taisymo eiliškumu pagal tai, kiek kuri klaida kainuoja.
Šitą darbą darau kasdien - iš Vilniaus, klientams visame pasaulyje. Jei norite, kad jūsų skaičius sutikrinčiau aš, parašykite work@rytisbalys.com.
work@rytisbalys.com