Pixeliai ir sekimo žymos yra šiuolaikinės skaitmeninės reklamos pagrindas. Remiantis pikseliais ir sekimo žymomis, galite tiksliai matuoti konversijas, kurti pakartotinės rinkodaros (retargeting) auditorijas ir optimizuoti kampanijas remdamiesi patikimais duomenimis. Kai sekimas sutrinka, visa sistema paveikiama: iškraipomi rodikliai, neauga auditorijos, o reklamos efektyvumas negali būti tiksliai įvertintas.
Šiame dokumente apibendrinamos dažniausios „Facebook Pixel“ ir „Google Tag“ sekimo klaidos, paaiškinamos jų priežastys ir pateikiami sistemingo tikrinimo bei taisymo būdai.
Dažniausios „Facebook Pixel“ problemos
Nerastas Pixel
Tai dažniausia klaida, kai „Facebook“ negali aptikti svetainės pikselio. Dažni požymiai apima „Pixel Helper“ pranešimą „No pixels found“, neaugančias auditorijas ir jokių įvykių neregistruojančią „Events Manager“.
Dažniausios priežastys yra tai, kad pikselis neįdiegtas, įdiegtas netinkamoje vietoje arba naudojamas neteisingas „Pixel ID“. Pikselis turi būti <head> žymoje, krautis visuose puslapiuose ir nebūti blokuojamas kitų skriptų.
Be to, reikia tikrinti naršyklės JavaScript klaidas. Bet kokia klaida, sutrikdanti puslapio įkėlimą, gali neleisti pikseliui veikti.
Pixel veikia, bet „Events Manager“ nerodo įvykių
Kai kuriais atvejais „Pixel Helper“ praneša, kad pikselis veikia, tačiau „Events Manager“ nerodo naujų duomenų.
Pirmiausia, būkite kantrūs. Duomenų apdorojimas gali užtrukti iki 20 minučių. Norėdami nedelsiant patikrinti, rekomenduojama naudoti įrankį Test Events.
Jei vis tiek nematote įvykių, reikia patikrinti domeno patvirtinimą ir deduplikacijos nustatymus, kai naudojate „Pixel“ ir „Conversions API“ kartu. Jei tinkamai nenustatysite event_id, „Facebook“ gali atmesti arba neregistruoti įvykio.
Trūksta standartinių įvykių (Standard Events)
„PageView“ veikia, tačiau „AddToCart“, „Lead“ ar „Purchase“ nėra registruojami, dažnai todėl, kad šie įvykiai nebuvo suaktyvinti tinkamu laiku.
Skirtingai nei „PageView“, standartiniai įvykiai turi būti aiškiai iškviesti atliekant konkrečius vartotojo veiksmus, pavyzdžiui, įtraukiant į krepšelį, siunčiant formą ar užbaigiant mokėjimą.
Ad blokeriuose taip pat gali būti blokuojamas naršyklės sekimas. Norint sumažinti šią riziką, reikėtų įdiegti „Conversions API“ kaip papildomą serverio pusės sekimo sluoksnį.
Sekimas smarkiai sumažėjo po iOS 14.5+
Jei konversijų skaičius staiga sumažėjo, auditorija tapo mažesnė arba priskyrimas (attribution) nestabilus, priežastis dažnai slypi „iOS“ privatumo pakeitimuose.
Sprendimai apima „Conversions API“ diegimą, „Aggregated Event Measurement“ konfigūravimą, domeno patvirtinimą ir UTM parametrų pridėjimą daugiaplatformiam matavimui palaikyti.
Dažniausios „Google Tag“ problemos
Nerastas „Google Tag“
Kai „Tag Assistant“ neaptinka žymos, konversijų sekimas ir pakartotinė rinkodara neveiks.
Reikia patvirtinti, kad žyma įdiegta teisingai, o konversijos ID kode sutampa su „Google Ads“ ID. Jei naudojate „Google Tag Manager“, įsitikinkite, kad žyma buvo publikuota ir paleidimo sąlygos (trigger) sukonfigūruotos teisingai.
Žyma rodo perspėjimus „Tag Assistant“
Žyma gali rodyti geltoną arba raudoną būseną:
- Žalia: veikia normaliai
- Geltona: nedidelė klaida, verta patikrinti
- Raudona: rimta klaida, reikia nedelsiant taisyti
Dažnos klaidos apima pasikartojančias žymas, trūkstamas konversijos reikšmes arba netinkamus nustatymus. Daugumą jų galima ištaisyti pašalinus pasikartojantį kodą ir pridedant reikiamus parametrus.
Pakartotinės rinkodaros auditorija neauga
Jei pakartotinės rinkodaros auditorija visada yra 0 arba „per maža naudoti“, reikia patikrinti pakartotinės rinkodaros nustatymus ir faktinį srautą. Naujoms auditorijoms pradėti rinkti duomenis reikia nuo 24 iki 48 valandų, ir jos turi pasiekti minimalų ribą prieš naudojimą.
Dinaminė pakartotinė rinkodara neveikia
Bendro pobūdžio reklamos, o ne konkretūs produktai, dažnai atsiranda dėl to, kad produkto ID nesutampa tarp žymos ir kanalo. Žymos siunčiamas ID turi visiškai sutapti su Merchant Center ID. Kanalo turi būti patvirtintas ir pasirinktas tinkamas verslo tipas.
Bendrosios sekimo problemos
CORS klaidos ir saugos politika
CORS klaidos arba turinio saugos politika gali blokuoti sekimo scenarijus, nesukeldamos akivaizdžių klaidų. Svetainė turi naudoti HTTPS ir leisti visus sekimo domenus saugos antraštėse.
Reklamų blokatoriai blokuoja sekimą
Apie 25–30% vartotojų naudoja reklamų blokatorius. Tai neišvengiama realybė.
Tvariausias sprendimas yra serverio pusės sekimo derinimas ir skaidrus bendravimas su vartotojais apie duomenų rinkimą.
Sekimas keliuose subdomenuose
Jei vartotojas keliauja per kelis subdomenu, reikia sukonfigūruoti tarpdomeninį sekimą, kad būtų išvengta sesijos nutraukimo ir priskyrimo klaidų.
Sekimo tikrinimas ir patvirtinimas
Prieš paleidžiant reklamas, visada reikia patikrinti sekimą:
- „Facebook“ atveju: Pixel Helper, Test Events ir auditorijos failų patikrinimas
- „Google“ atveju: Tag Assistant, realaus laiko ataskaitos ir konversijų testavimas
- GTM atveju: naudokite Preview mode, kad patikrintumėte paleidimo sąlygas ir eiliškumą
Išvados
Sekimo klaidos retai atsiranda dėl vienos priežasties. Dauguma jų atsiranda dėl netinkamos konfigūracijos, scenarijų konflikto arba naršyklės privatumo pakeitimų.
Sistemiškai spręsdami problemas, derindami naršyklės ir serverio pusės sekimą, galite išlaikyti tikslius duomenis ir užtikrinti, kad visi reklamos sprendimai būtų grindžiami patikimu matavimo pagrindu.
