Meta Pixel (agrāk Facebook Pixel) un Conversions API ir divi ceļi, pa kuriem Jūsu mājaslapas notikumi nonāk Meta sistēmā. Šis raksts skaidro, ko katrs no tiem dara, kā Events Manager pārbaudīt, vai mērījumi strādā, un kāpēc dati, kas pienāk, vēl nav dati, kuriem var uzticēties.
Ko Meta redz un ko ne
Meta reklāmu sistēma redz tikai to, ko Jūsu mājaslapa tai nosūta. Ja vietnē nav mērījumu, platforma zina, cik reižu reklāma tika parādīta un cik cilvēku uz tās noklikšķināja, bet nezina, kas notika pēc tam: vai cilvēks nonāca lapā, vai aizpildīja formu, vai nopirka.
Tam ir divas sekas. Pirmā: bez mērījumiem kampaņu var optimizēt tikai uz klikšķiem vai rādījumiem, ne uz pieteikumiem vai pirkumiem, jo sistēmai nav notikuma, uz kuru optimizēt. Otrā: Ads Manager kolonnā Results nekas neparādās, un lēmumi tiek pieņemti pēc klikšķu cenas, nevis pēc rezultāta. Ko platformas skaitļi vispār spēj pierādīt, esam izklāstījuši rakstā par Meta Ads metrikām.
Tāpēc mērījumu gatavība ir stratēģijas solis, ne tehniska detaļa: tā jāpārbauda pirms naudas tērēšanas, ne pēc pirmā mēneša, kad skaitļi nesakrīt.
Meta Pixel: pārlūka signāls
Meta Pixel ir neliels kods, kas ievietots Jūsu mājaslapā un darbojas apmeklētāja pārlūkā. Tas nosūta Meta ziņu par to, ka lapa ir atvērta (notikums PageView), un, ja tā ir iestatīts, arī par konkrētām darbībām: aizpildītu formu, pievienošanu grozam, pirkumu. Meta šīm darbībām ir standarta nosaukumi, piemēram, Lead, Contact, Purchase, AddToCart, InitiateCheckout un ViewContent, un tieši šos nosaukumus pēc tam redz kampaņas rezultātos. Notikumam var pievienot arī parametrus, piemēram, pirkuma vērtību un valūtu; bez tiem platforma zina, ka pirkums notika, bet ne to, cik tas bija vērts.
Interfeisā Pixel dzīvo Events Manager sadaļā, kur Meta šobrīd datu avotus sauc par Datasets. Viens dataset apvieno visus notikumus no vienas vietnes neatkarīgi no tā, vai tie nāk no pārlūka vai no servera, un tam ir savs ID, kuram jāsakrīt ar vietnē ievietoto kodu.
Pixel robežas ir tikpat svarīgas kā tā iespējas. Tas nosūta datus tikai tad, ja skripts pārlūkā vispār tiek izpildīts: ja apmeklētājs nav devis piekrišanu, ja pārlūks vai paplašinājums skriptu bloķē, ja lapa neielādējas līdz galam vai ja darbība notiek ārpus vietnes, piemēram, pa telefonu, Pixel to neredz. Tā nav kļūda, tā ir pārlūka signāla daba.
Conversions API: servera signāls
Conversions API ir otrs ceļš: notikumi tiek sūtīti uz Meta tieši no Jūsu servera, e-komercijas platformas vai CRM, apejot apmeklētāja pārlūku. Ja pirkums ir reģistrēts Jūsu sistēmā, to var nosūtīt neatkarīgi no tā, vai pārlūka skripts tobrīd strādāja.
Meta savā izstrādātāju dokumentācijā iesaka izmantot abus ceļus vienlaikus un sauc to par redundant setup. Iemesls ir vienkāršs: pārlūka signāls ir ātrs, bet trausls, servera signāls ir stabilāks, bet tam vajag tehnisku ieviešanu. Kopā tie viens otru papildina.
Šeit rodas viens obligāts nosacījums, kuru bieži aizmirst. Ja viens un tas pats notikums tiek sūtīts pa abiem ceļiem, Meta tas jāatpazīst kā viens notikums, nevis divi. Tam kalpo deduplikācija: abiem sūtījumiem jābūt ar vienādu notikuma nosaukumu un vienādu unikālu identifikatoru (event_id). Meta dokumentācija skaidri norāda, ka bez šī mehānisma notikumi tiks skaitīti divreiz, un ka dublējošos gadījumā sistēma patur pirmo saņemto. Praksē tas nozīmē: Conversions API bez deduplikācijas nevis uzlabo datus, bet tos dubulto.
Conversions API ieviešana ir tehnisks darbs. Dažām platformām un pluginiem tā ir iebūvēta, tad to ieslēdz ar dažiem klikšķiem; pielāgotai mājaslapai vai CRM tā prasa izstrādātāju.
Uzstādīšanas ceļi: bez koda un ar kodu
Nav viena pareizā veida, kā Pixel un Conversions API nonāk vietnē. Ir vairāki ceļi, un galvenais noteikums ir viens: katram notikumam viens ceļš, ne divi. Divas paralēlas instalācijas ir viens no biežākajiem dubultu skaitļu cēloņiem.
| Ceļš | Kam tas der | Vai vajag izstrādātāju |
|---|---|---|
| Partneru integrācija (e-komercijas platformas, veidotāji) | Standarta platformām ar gatavu Meta savienojumu; bieži ietver arī Conversions API | Parasti nē |
| WordPress vai CMS plugin | Vietnēm uz izplatītām satura sistēmām | Parasti nē, bet jāpārbauda, ka nav otras instalācijas |
| Google Tag Manager | Vietnēm, kur mērījumus pārvalda centralizēti vairākiem rīkiem | Jā, vai vismaz cilvēks, kas GTM pārzina |
| Manuāls kods vietnes galvenē | Pielāgotām vietnēm bez plugina | Jā |
| Conversions API bez partneru integrācijas | Servera vai CRM notikumiem pielāgotās sistēmās | Jā, vienmēr |
Izvēle starp ceļiem nav stratēģisks jautājums, bet pārbaude pēc uzstādīšanas ir. Kurš ceļš izvēlēts, to lasītājam nevajag atcerēties; vajag zināt, ka ceļš ir viens un ka tas strādā.
Piekrišana maina skaitļus
Sīkdatņu piekrišanas rīks ir daļa no mērījumu sistēmas, ne atsevišķa juridiska formalitāte. Vairums piekrišanas rīku aiztur mārketinga skriptus, tostarp Pixel, līdz brīdim, kad apmeklētājs piekrīt. Apmeklētāji, kuri piekrišanu nedod, Pixel datos vienkārši neparādās.
No tā izriet divas lietas. Pirmā: pārlūka notikumu skaits vienmēr būs mazāks par reālo apmeklētāju skaitu, un tā nav kļūda, ko var salabot. Otrā: ja piekrišanas rīks ir nepareizi konfigurēts, tas var bloķēt Pixel arī pēc piekrišanas, un tad datu nav vispār. Abas situācijas izskatās vienādi (zemi skaitļi), bet nozīmē pilnīgi dažādas lietas, tāpēc tās jāatšķir pārbaudē, ne jāmin.
Šis raksts nav juridisks padoms par to, kāda piekrišana Jūsu situācijā ir nepieciešama; to nosaka Jūsu apstākļi un normatīvie akti. Mērījumu līmenī pietiek ar apziņu, ka piekrišana ir viens no iemesliem, kāpēc platformas skaitļi nesakrīt ar biznesa skaitļiem.
Kā pārbaudīt, vai mērījumi strādā: Events Manager kontrolpunkti
Pārbaudei nevajag izstrādātāju. Vajag Events Manager, savu mājaslapu un desmit minūtes. Galvenais rīks ir cilne Test events: tajā ievada savas vietnes adresi, atver to un veic darbību, piemēram, aizpilda formu; cilnei jāparāda notikums, ko šī darbība radīja, ar tā nosaukumu un avotu. Meta piedāvā arī pārlūka paplašinājumu Meta Pixel Helper, kas rāda, vai lapā Pixel ir aktīvs un kādus notikumus tas nosūta.
| Kontrolpunkts | Kur skatīties | Kas jāredz |
|---|---|---|
| 1. Datu avots eksistē un ID sakrīt | Events Manager, Datasets | Viens dataset ar ID, kas sakrīt ar vietnē ievietoto kodu |
| 2. PageView pienāk | Dataset pārskats, kolonna Status | Statuss Active un nesens laiks pie “Last received” |
| 3. Biznesam svarīgais notikums ir definēts | Notikumu saraksts | Ne tikai PageView, bet arī Lead, Contact, Purchase vai cits notikums, uz kuru kampaņa optimizē |
| 4. Notikums nostrādā pareizajā brīdī | Cilne Test events | Veiciet darbību vietnē un redziet notikumu ar pareizo nosaukumu tieši tad, kad darbība pabeigta |
| 5. Nav dubultu notikumu | Kolonna Integration un Test events | Viena darbība rada vienu notikumu; ja avots ir gan Meta pixel, gan Conversions API, notikumi ir deduplicēti |
| 6. Datu kvalitātes signāli pārskatīti | Kolonna Event match quality un cilne Actions | Kvalitātes vērtējums ir redzams, un Meta ieteikumi ir izlasīti, nevis ignorēti |
Divas piezīmes, kas ietaupa nervus. Notikumi Events Manager var parādīties ar kavēšanos, interfeiss pats brīdina par laiku līdz pusstundai, tāpēc tukšs saraksts uzreiz pēc darbības vēl neko nepierāda. Un Test events cilnē rādītā uzvedība var atšķirties no dzīvās vides, tāpēc pēc testa ir vērts pēc dienas apskatīties arī pārskata skaitļus.
Tipiskās kļūdas, kas izskatās pēc strādājošiem mērījumiem
ACCESSIO praksē visbiežāk sastopamā situācija ir nevis mērījumu trūkums, bet iesākti un līdz galam nepabeigti mērījumi. Pixel ir ievietots, PageView skaitās, Events Manager rāda zaļu statusu, un šķiet, ka viss ir kārtībā. Bet notikums, kas biznesam patiešām svarīgs, pieteikums vai pirkums, nav definēts vai nenostrādā. Kampaņa tad nevar optimizēt uz to, kas Jums vajadzīgs, un Results kolonna rāda vai nu neko, vai lapas skatījumus, kas ar biznesu nav saistīti.
Bez šīs ir vēl dažas tipiskas situācijas, kuras der pazīt:
Divas instalācijas. Pixel ievietots gan ar pluginu, gan manuāli kodā, bieži no dažādiem izpildītājiem dažādos laikos. Katra lapas atvēršana rada divus PageView, un visi skaitļi ir dubulti. Pazīme: Test events rāda vienu darbību divreiz.
Conversions API bez deduplikācijas. Servera ceļš pieslēgts, bet event_id nesakrīt vai tā nav. Konversijas skaitās divreiz, un kampaņa izskatās divreiz labāka, nekā ir. Pazīme: notikumu skaits pēkšņi dubultojas pēc servera ceļa pieslēgšanas.
Notikums nepareizajā brīdī. Pieteikuma notikums nostrādā, klikšķinot uz pogas, nevis tad, kad forma tiešām nosūtīta; vai pirkuma notikums ir uz pasūtījuma lapas, nevis uz apstiprinājuma lapas. Skaitļi ir, bet tie mēra nodomu, ne rezultātu. Pazīme: platformas pieteikumu ir vairāk nekā reālo.
Piekrišanas rīks bloķē visu. Rīks aiztur Pixel arī pēc piekrišanas nepareizas konfigurācijas dēļ. Pazīme: PageView skaits ir daudz mazāks par vietnes apmeklējumu citos rīkos.
Tehniskie notikumi aizsprosto sarakstu. Citi vietnes rīki, piemēram, piekrišanas vai čata risinājumi, sūta savus tehniskos notikumus tajā pašā datu avotā, un biznesa notikumi pazūd starp tiem. Pazīme: notikumu sarakstā ir nosaukumi, kurus neviens apzināti nav veidojis.
Vecs vai svešs Pixel ID. Vietnē palicis iepriekšējā izpildītāja vai citas vietnes ID, un dati aizplūst uz datu avotu, kuram Jums nav piekļuves. Pazīme: savā Events Manager notikumu nav, lai gan Pixel Helper lapā rāda aktīvu Pixel.
Katrai no šīm situācijām ir viens kopīgs risinājums: pārbaudīt, nevis pieņemt. Neviena no tām nav redzama Ads Manager pārskatā, visas ir redzamas Events Manager.
Dati pienāk nav tas pats, kas dati ir uzticami
Pat ideāli uzstādīti mērījumi nedod pilnu ainu, un tas ir jāsaprot pirms lēmumiem.
Platformas notikums nav biznesa rezultāts. Lead notikums nozīmē, ka forma tika nosūtīta, ne to, ka kontakts ir sasniedzams vai kvalificēts. Purchase nozīmē, ka vietne nosūtīja pirkuma notikumu, ne to, ka pasūtījums ir apmaksāts un nav atcelts. Šo robežu esam sīki izklāstījuši rakstā par Meta Ads metrikām.
Piekrišana un pārlūka ierobežojumi nozīmē, ka daļa reālo darbību platformā nekad neparādīsies, un neviens tehnisks uzlabojums šo daļu nesamazina līdz nullei. Atribūcijas iestatījumi nosaka, kuras darbības tiek piedēvētas reklāmai, un tie ir platformas noteikumi, ne fakts par cēloņsakarību.
Tāpēc uzticamu mērījumu pazīme nav zaļš statuss Events Manager, bet regulārs salīdzinājums: cik notikumu rāda platforma, cik pieteikumu vai pasūtījumu ir Jūsu pašu uzskaitē, un cik liela ir atšķirība. Atšķirība ir normāla; nezināma atšķirība ir problēma. Kā šo salīdzinājumu iekļaut stratēģijā jau pirms starta, aprakstīts rakstā par Facebook reklāmas stratēģiju.
Ko pārbauda pamata audits un kas ir atsevišķs tehniskais darbs
Šī raksta kontrolpunkti veido to, ko var saukt par pamata mērījumu pārbaudi: vai datu avots ir pareizs, vai pienāk PageView, vai biznesa notikums ir definēts un nostrādā pareizajā brīdī, vai nav dublēšanās, un vai datu kvalitātes signāli ir pārskatīti. Šo pārbaudi var veikt bez izmaiņām vietnes kodā, un tieši tāda pamata Pixel un notikumu pārbaude ietilpst ACCESSIO Meta reklāmu pārvaldības pakalpojumā.
Atsevišķs tehniskais darbs ir viss, kas prasa koda vai infrastruktūras izmaiņas: Conversions API ieviešana pielāgotā vietnē, servera puses mērījumi, Google Tag Manager pārbūve, datu slāņa izveide, CRM integrācija. Tas nav sliktāk vai labāk, tas ir cits darbs ar citu izpildītāju, un to ir godīgi nodalīt jau sarunas sākumā.
Kopsavilkums
Meta Pixel ir pārlūka signāls, Conversions API ir servera signāls, un abi kopā ir viena mērījumu sistēma, kurai vajag deduplikāciju, lai neskaitītu divreiz. Pārbaudīt, vai sistēma strādā, var bez izstrādātāja, ar sešiem Events Manager kontrolpunktiem. Bet zaļš statuss nozīmē tikai to, ka dati pienāk; vai tie ir pietiekami uzticami lēmumiem, parāda tikai salīdzinājums ar Jūsu pašu uzskaiti.
Ja vēlaties, lai pamata mērījumu pārbaudi un reklāmu pārvaldību uzņemas pieredzējis izpildītājs, apskatiet ACCESSIO Facebook un Instagram reklāmu pārvaldības pakalpojumu.
