Meta Pixel vs Ads Manager: glābj Conversions API pirkumus | SerpCtrl
2026-07-15·12min
Meta Pixel rāda vienu, Ads Manager - pavisam citu: kā ar Conversions API salabot pirkumu izsekošanu
Meta PixelConversion TrackingTracking Audit
Kāpēc tavs Meta Pixel 2026. gadā uzskaita par maz pirkumu
Pārlūka pikselis tika radīts tīmeklim, kāda vairs nav. Gadu gaitā ir izveidojušās četras atsevišķas noplūdes, un kopā tās summējas.
Pirmkārt, iOS un Safari ITP. Safari pēc septiņām dienām dzēš ar JavaScript iestatītās sīkdatnes - un tieši tādi ir pikseļa identifikatori - ja apmeklētājs nav atgriezies. Papildus tam tas ierobežo arī starpvietņu identifikatorus. Rezultātā pikseļa spēja sasaistīt pirkumu ar reklāmas klikšķi Apple ierīcēs strauji samazinās. Ja tava auditorija pārsvarā ir mobila un maksātspējīga, tā ir ievērojama daļa tavu pircēju.
Otrkārt, reklāmu bloķētāji un pārlūki ar izsekošanas aizsardzību. Tie pikseļa darbību nepasliktina - tie to vienkārši bloķē. Pikseļa skripts nemaz netiek ielādēts, tāpēc pirkuma notikums nekad nenostrādā. Pēc jaunākajiem mērījumiem reklāmu bloķētājus izmanto aptuveni 25–35 % interneta lietotāju pasaulē, bet Eiropā šis īpatsvars ir vēl augstāks - Vācijā tas pietuvojas pusei. Savas auditorijas pārlūku higiēnu tu izvēlēties nevari.
Treškārt, piekrišanas pārvaldības platformas un sīkdatņu baneri. Ja ES apmeklētājs atsaka mārketinga sīkdatnes, pikseļa notikumi vai nu vispār nenostrādā, vai arī nostrādā bez identifikatoriem. Tā nav kļūda - sistēma tieši tā arī ir paredzēta darbam. Taču rezultāts ir tas pats: Ads Manager redz mazāk pirkumu, nekā patiesībā ir tavā veikalā.
Ceturtkārt, tā garlaicīgā lieta, par kuru gandrīz neviens nerunā: norēķinu plūsmas, kas ir mainījušās tev aiz muguras. React vai Vue norēķinos "pirkums" bieži notiek bez pilnas lapas ielādes. Ja pikseļa Purchase notikums ir piesaistīts lapas skatījumam, kas tehniski nemaz nenotiek, tas vienkārši paliek nenostrādājis. Shopify pāreja uz Checkout Extensibility ir tas pats stāsts citā veidolā. Pielāgotie skripti, kas savulaik tika ielīmēti checkout.liquid, pārstāja darboties pēc pateicības lapas pārbūves, un veikali turpināja vainot iOS par tagu, kura tur vienkārši vairs nebija.
Saliec šos četrus kopā, un kļūst skaidrs, ka pārlūka pikselis vairs nav pilnvērtīgs mērīšanas rīks - tā ir tikai izlase. Conversions API nav nekāds papildpārdošanas gājiens, ko Meta izdomājusi tev par spīti. Tas ir vienīgais veids, kā nosūtīt notikumus no vietas, kur reklāmu bloķētāji un ITP netiek klāt - no tava servera.
Pixel vs Conversions API (CAPI) vs abi: kā deduplikācija patiešām strādā
Nu tā daļa, kas Meta pasaulē rada vairāk apmulsušu forumu tēmu nekā gandrīz jebkas cits. Ieteicamā konfigurācija ir izmantot Meta Pixel UN CAPI vienlaikus, sūtot vienus un tos pašus notikumus divreiz. Kamēr nesaproti, kā darbojas deduplikācija, tas izklausās pēc pilnīga neprāta.
Kad Meta vienā datu kopā (dataset - tas, ko agrāk sauca par tava pikseļa ID) saņem divus notikumus, tā pārbauda, vai tiem sakrīt event_name un event_id. Ja abi sakrīt un otrais notikums pienāk 48 stundu laikā pēc pirmā, Meta patur to, kuru saņēma pirmo, bet otru atmet. Vienāds nosaukums, vienāds ID, viena datu kopa, iekļaujas laika logā - uzskaitīts vienreiz.
Tehniski pastāv arī rezerves metode - Meta var deduplicēt pēc event_name un fbp sīkdatnes vērtības. Taču tā darbojas tikai tad, ja pārlūka notikums pienāk pirmais, un tieši tie apmeklētāji, kas ir vissvarīgākie - ar nobloķētiem pikseļiem vai atteiktu piekrišanu - pārlūka notikumu nemaz nenosūta. Uztver event_id kā īsto deduplikācijas mehānismu, bet rezerves metodi - kā drošības tīklu, uz kuru nekad nevajadzētu paļauties.
Kļūda numur viens - un ar to es domāju pašu biežāk sastopamo problēmu gandrīz katrā Pixel/CAPI tēmā, ko esmu lasījis - ir ieslēgt servera puses integrāciju blakus jau esošam pikselim, nesaskaņojot event_id. Pienāk abi notikumi, Meta nevar saprast, ka tas ir viens un tas pats pirkums, un katrs pasūtījums tiek uzskaitīts divreiz. Tavs ROAS pa nakti pēkšņi dubultojas, lai gan patiesībā tas ir tīrs izdomājums. Ir cilvēki, kas, balstoties uz šādu izdomājumu, ir palielinājuši reklāmas budžetus.
Ir arī pretējā kļūda. Dažkārt pārlūks ģenerē vienu nejaušu event_id, bet serveris - citu, tikpat nejaušu. Rezultāts ir tieši tāds pats: sakritības nav, un uzskaite dubultojas.
Lūk, kā izskatās pareizi izveidots pāris. Pārlūka pusē pikseļa izsaukums nodod pasūtījuma ID kā eventID - pievērs uzmanību camelCase rakstībai. Pārlūka parametrs tiek rakstīts citādi nekā servera parametrs:
<script>
fbq('track', 'Purchase', {
value: 129.99,
currency: 'EUR'
}, { eventID: 'order_84712' });
</script>
Servera pusē CAPI payload nes to pašu vērtību laukā event_id:
"client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X)...",
"fbp": "fb.1.1752234000000.1234567890",
"fbc": "fb.1.1752234000000.IwAR2xEXAMPLE"
},
"custom_data": {
"value": 129.99,
"currency": "EUR"
}
}]
}
Ievēro, kas te paveic darbu: event_name abās pusēs ir Purchase, un event_id abās pusēs ir order_84712. Pasūtījuma ID ir visdabiskākā izvēle, jo tas ir unikāls, nemainīgs un pieejams gan pārlūkam, gan serverim. Meta dokumentācija prasa tikai "identifikatoru, kas spēj viennozīmīgi atšķirt līdzīgus notikumus", taču pirkumiem neviens vēl nav izdomājis neko labāku par pasūtījuma ID. Laika zīmogs tam neder. Pārlūks un serveris atšķirsies par milisekundēm, un ar to pietiek, lai sakritība izjuktu.
Tāpēc strīdā par CAPI vs Pixel atbilde gandrīz vienmēr ir viena: abi, ar deduplikāciju. Pikselim joprojām ir sava vieta. Tas notver fbp un fbc pārlūka sīkdatnes pašā svaigākajā brīdī un aptver apmeklētājus, kurus servera notikumi varētu aprakstīt visai nepilnīgi. Savukārt servera notikumi aptver tos apmeklētājus, kuriem pikselis fiziski netiek klāt. Kopā, ar pareizi ieviestu deduplikāciju, tie dod pilnīgāku ainu, nevis dubultu pirkumu skaitu.
Event Match Quality: kas patiešām ietekmē vērtējumu
Nogādāt notikumu līdz Meta ir tikai puse darba. Pēc tam Meta katrs notikums ir jāsasaista ar reālu cilvēku, un Event Match Quality (EMQ) ir vērtējums tam, cik labi tavi nosūtītie parametri to ļauj izdarīt. Tas tiek aprēķināts atsevišķi katram notikuma veidam. To atradīsi Events Manager - vērtējumu skalā līdz 10, kā arī pārskatu par to, kurus parametrus konkrētajam notikumam tu sūti.
Taču vēl pirms pašiem parametriem ir viens dzelžains noteikums, kas ir svarīgāks par tiem visiem: vietnes notikumiem client_user_agent un event_source_url nav izvēles parametri - tie ir obligāti. Servera notikumi bez tiem var tikt vienkārši atmesti. Nevis novērtēti zemāk, bet vispār atmesti. Tāpēc šos divus parametrus pārbaudi vispirms, pirms ķeries pie jebkā cita optimizēšanas.
Kas ietekmē vērtējumu, parametru pēc parametra:
em ir klienta e-pasta adrese, kas pirms nosūtīšanas tiek hašēta ar SHA-256. Vispirms pārvērt to mazajos burtos un noņem liekās atstarpes, tikai pēc tam hašē. Šis ir pats spēcīgākais identitātes signāls. Ja sūti tikai vienu identitātes parametru, lai tas ir šis.
ph ir tālruņa numurs, arī hašēts ar SHA-256. Tam jābūt tikai ar cipariem, ar valsts kodu un bez nacionālā numura sākuma nullēm. Tas ir ļoti spēcīgs signāls, kuru bieži neizmanto tikai tāpēc, ka norēķinu plūsma ne vienmēr to savāc.
fbp ir pārlūka ID sīkdatne, ko iestata pikselis, savukārt fbc ir klikšķa ID sīkdatne, kas rodas, kad lietotājs atver vietni no Meta reklāmas ar fbclid parametru adresē. Abus sūta neapstrādātā (raw) veidā, nevis hašētus. Tieši fbc sasaista konversiju ar reklāmas klikšķi, tāpēc tā zaudēšana atribūcijai kaitē daudz vairāk, nekā to atspoguļo pats EMQ skaitlis. Taču ir viens svarīgs brīdinājums: fbc eksistē tikai tad, ja reklāmas klikšķis tiešām ir noticis. Nekad to neizdomā, lai mākslīgi uzlabotu vērtējumu - tā tu Meta sūtītu nepatiesus atribūcijas datus.
external_id ir tavs paša klienta identifikators, un to ieteicams hašēt. Vislielāko vērtību tas dod tad, ja tiek sūtīts konsekventi visos notikumos, ļaujot Meta salikt kopā viena lietotāja ceļu.
client_ip_address un client_user_agent sūta neapstrādātus un tikai servera pusē. Te arī slēpjas viena no biežākajām lamatām. Tavam serverim ir jāpārsūta klienta IP adrese un user agent, nevis paša servera. CAPI integrācija, kas visus pirkumus nosūta no viena datu centra IP ar curl user agent, patiesībā apraksta Meta tavu serveri, nevis pircēju. Esmu redzējis, kā EMQ pieaug par vairākiem punktiem, salabojot tikai šo vienu lietu.
Un tagad par to daļu, kas cilvēkus satrauc visvairāk. Forumi ir pilni ar cilvēkiem, kuri uztraucas, ka viņu EMQ ir 6,8, nevis 10, un ir pārliecināti, ka viņu kontā kaut kas nav kārtībā. Parasti tā nav. Pašas Meta vērtējumu skalā 6–7 tiek uzskatīts par "labu", bet 8–10 - par "lielisku". Savukārt 10 praksē gandrīz vienmēr nozīmē pieteikušos lietotājus ar pilniem kontaktinformācijas datiem katrā notikumā. E-komercijas veikalam ar viesa norēķinu EMQ virs 6 jau nozīmē labi sakārtotu konfigurāciju, bet virs 8 - ļoti spēcīgu. Dzīties pēc pēdējiem diviem punktiem ir daudz nepateicīgāk nekā salabot deduplikāciju vai trūkstošu fbc. Vispirms aizlāpi īstās noplūdes.
Uzstādīšanas ceļi salīdzinājumā: iebūvētās integrācijas vs sGTM vs maksas rīki
Ir trīs izplatīti veidi, kā ieviest Meta Conversions API, un vēl ceturtais - pašas Meta risinājums, ko vairums salīdzinājumu nemaz nepiemin. Kurš ir pareizais, atkarīgs no tavas sistēmas un no tā, cik lielu kontroli tev patiesībā vajag.
Pirmais variants ir iebūvētās integrācijas. Shopify piedāvā CAPI caur Meta izstrādāto Facebook & Instagram lietotni. Iestati datu koplietošanu uz Enhanced vai Maximum, un tā pati sūtīs gan pikseļa, gan servera notikumus, parūpējoties arī par event_id un deduplikāciju. Standarta Shopify veikalam tas patiešām ir labs risinājums. Man daudz labāk patīk, ka tu izmanto šo, nekā līdz pusei nokonfigurētu kaut ko sarežģītāku.
Kompromiss ir kontrole un pārredzamība. Tu pieņem notikumus tādus, kādus tos sūta Shopify, un, kad kaut kas šķiet greizi, atkļūdošana pārvēršas par melno kasti. Ir arī divas lietas, kas 2026. gadā ir īpaši svarīgas. Pirmkārt, kopš janvāra Shopify noklusējuma iestatījums Optimized ļauj platformai apturēt lietotnes pikseļa pārlūka notikumus, ja signāla kvalitāte tiek novērtēta kā zema. Tas klusi maina attiecību starp pikseļa un CAPI notikumiem, tāpēc šo iestatījumu ir vērts pārbaudīt, nevis pieņemt par pašsaprotamu. Otrkārt, nekad neliec virsū vēl vienu CAPI risinājumu. Abi sūtīs vienus un tos pašus pirkumus ar atšķirīgiem event_id, un deduplikācija tevi vairs neizglābs.
Otrais variants ir servera puses Google Tag Manager - pašhostēts vai hostēts pie tāda pakalpojuma kā Stape. Šeit notikumi tiek pārsūtīti uz Meta no tava paša tagošanas servera. Tā ir lielākā kontrole, ko vari iegūt. Tu pats nosaki, kuri parametri nonāk user_data, vari bagātināt notikumus, ievērot piekrišanas nosacījumus un vienu un to pašu servera konteineru izmantot arī GA4 un Google Ads vajadzībām.
Cena par šo kontroli ir sarežģītība. Tagad tev pašam ir jāuztur infrastruktūra, un slikti konfigurēts konteiners rada savas problēmas. Ja apsver šo ceļu, vispirms izlasi manu ceļvedi par Google Tag Gateway un servera puses GTM. Pusei cilvēku, kuri domā, ka viņiem vajag pilnvērtīgu tagošanas serveri, patiesībā pietiktu ar daudz vienkāršāku risinājumu. Un esmu redzējis, kas notiek, kad servera konteineri tiek uzturēti pavirši - GTM konteinera drošības analīze ir labs brīdinājums, kā tas var beigties.
Trešais variants ir maksas izsekošanas platformas, piemēram, Elevar - pēc 2025. gada iegādes tagad Audiense Online, lai gan visi to joprojām sauc par Elevar - vai Triple Whale. Tās uzstādās uz tava veikala un kā gatavs produkts nodrošina servera puses notikumu piegādi. Bieži dzirdu jautājumu "Stape vai Triple Whale?", taču patiesībā tas nav korekts salīdzinājums. Tie ir dažādu kategoriju rīki. Stape hostē tavu sGTM konteineru, bet visa loģika joprojām ir tavās rokās. Triple Whale ir analītikas un atribūcijas platforma, kas piegādi paveic tavā vietā un uzreiz pievieno savu atskaišu slāni. Elevar atrodas tuvāk data layer un notikumu piegādes galam. Tu maksā par to, lai nebūtu jādomā par payload. Komandai ar reklāmas budžetu, bet bez inženiera tas ir pilnīgi pamatots kompromiss. Tas kļūst problemātisks tikai tad, ja sāc pieņemt rīka skaitļus kā neapstrīdamu patiesību, jo iespēju tos pārbaudīt esi atdevis ārpakalpojumā.
Ir arī ceturtais variants, par kuru ir vērts zināt - pašas Meta Conversions API Gateway. Tas ir bezkoda relejs, ko vari palaist savā mākoņkontā vai hostēt pie pakalpojuma sniedzēja par aptuveni desmit dolāriem mēnesī uz katru pikseli. Tas vienkārši pārsūta pārlūka signālus uz servera pusi. Nekādas notikumu loģikas, nekādu pārveidojumu, nekādu piekrišanas noteikumu - tikai Meta. Pēdējā laikā Meta šo risinājumu reklamē daudz mazāk, un, ja esi jau izaudzis no iebūvētās integrācijas, parasti tāpat gribas sGTM sniegto kontroli. Taču Meta-only videi bez inženiera tas joprojām ir pilnīgi saprātīgs starpposms.
Arī EMQ "griesti" atšķiras atkarībā no izvēlētā ceļa. Iebūvētās integrācijas var nosūtīt tikai tos datus, kurus platforma zina. Shopify risinājums lielākajai daļai notikumu parasti sasniedz EMQ 4–6, bet Purchase notikumiem ar Maximum datu koplietošanu bieži tiek līdz 6–8. Labi uzbūvēts sGTM stabili sasniedz 7–8,5 un, atkarībā no datiem, var kāpt vēl augstāk, jo tu kontrolē katru parametru. Maksas platformas parasti atrodas kaut kur pa vidu - viss atkarīgs no tā, cik daudz klienta datu tām ir pieejams.
Un viens brīdinājums, kas attiecas uz visiem četriem variantiem. Pārcelt konversiju notikumus uz servera pusi nozīmē mainīt ne tikai Meta, bet arī citas reklāmas platformas. Visbiežāk pirmais to izjūt Google Ads. Servera puses izsekošanai ir savi atribūcijas slazdi, un tos daudz vieglāk novērst pirms migrācijas nekā pēc tās.
Kā pārbaudīt, vai tas strādā, kad paši Meta testēšanas rīki runā pretī paši sev
Meta tev dod Test Events rīku Events Manager, un tas noteikti ir jāizmanto. Taču tikpat svarīgi ir saprast, kādos veidos tas mēdz tevi maldināt -jo maldinās gan.
Īpatnība numur viens: parametri, kas izskatās kā iztrūkstoši, lai gan patiesībā tādi nav. Man bija klients, kurš eskalēja it kā "salauztu" integrāciju, lai gan katrs notikums korekti nodeva hašētu e-pasta adresi. Test Events skats to vienkārši neuzrādīja kā veiksmīgi atpazītu. Payload stāstīja patiesību; informācijas panelis -nē. (Protams, pastāv arī daudz ikdienišķāka šīs problēmas versija: e-pasts tiek hašēts, pirms tas pārvērsts mazajos burtos. Rezultātā iegūsti tehniski derīgu hašu, kas praksē nesakrīt ne ar ko.)
Īpatnība numur divi: deduplikācijas attēlošanas aizkave. Test Events var rādīt pārlūka un servera notikumu blakus viens otram un tā arī nekad nepiezīmēt tos kā deduplicētus. Kopienas forumos netrūkst piemēru, kur marķējums "Deduplicated" parādās tikai daļai notikumu pāru vai pazūd pavisam, lai gan produkcijā deduplikācija strādā perfekti. Dod sistēmai laiku un skaties uz apstrādātajiem datiem, nevis uz tiešraides plūsmu.
Īpatnība numur trīs: dažādās vietās dati parādās ar atšķirīgu aizkavi. Test Events darbojas gandrīz reāllaikā, un parastiem notikumiem tur vajadzētu parādīties aptuveni divdesmit minūšu laikā. Taču atribūcijas atskaites -īpaši modelētās iOS konversijas -var atpalikt par vienu līdz trim dienām. Šī rīta pasūtījumu salīdzināšana ar šī rīta Ads Manager skaitļiem tev pasaka ļoti maz.
Tāpēc pārbaudi pēc neapstrādātajiem payload, nevis paļaujies uz saskarni. Mana kārtība ir šāda.
Pārlūka pusē atver DevTools, dodies uz cilni Network, uzliec filtru facebook.com/tr un veic testa pasūtījumu. Apskati pieprasījumu un pārliecinies, ka event_name, eventID, value un currency ir tieši tādi, kā gaidīts.
Servera pusē reģistrē (log) precīzi to JSON payload, ko tavs serveris sūta uz Conversions API. Ja izmanto servera puses GTM, apskati izejošo pieprasījumu priekšskatījuma režīmā. Noliec abus payload blakus un pārbaudi vienu lietu, kas ir svarīgāka par visu pārējo: vai event_id vērtības ir zīme zīmē identiskas.
Testiem izmanto test_event_code no Test Events cilnes un pārliecinies, ka produkcijā tas ir noņemts. Un te ir detaļa, kas šo padara nepatīkamāku, nekā sākumā šķiet. Notikumi ar testa kodu netiek nolikti kaut kādā izolētā karantīnā -tie nonāk tavā reālajā mērīšanā. Esmu sastapis īstus auditus, kuros reāli Purchase notikumi joprojām tika sūtīti ar testa kodu.
Ja abi payload sakrīt un satur kvalitatīvus lietotāja datus, tava konfigurācija strādā - neatkarīgi no tā, ko konkrētajā brīdī rāda informācijas panelis.
10 punktu pirkuma notikuma audita saraksts
Izej tam cauri savā veikalā. Ar atvērtiem DevTools un Events Manager tas aizņem apmēram stundu.
Veic testa pasūtījumu un notver abus notikumus: pārlūka pikseļa pieprasījumu (DevTools, filtrs facebook.com/tr) un servera CAPI payload (tavos žurnālos vai sGTM priekšskatījumā).
Pārliecinies, ka event_name abās pusēs ir tieši Purchase. Nevis purchase, ne kāds pielāgots nosaukums vienā pusē.
Pārliecinies, ka event_id abās pusēs ir identisks, zīme zīmē. Ideālā gadījumā tam jābūt atvasinātam no pasūtījuma ID. Pārbaudi arī, ka abi notikumi tiek nosūtīti uz vienu un to pašu datu kopu (dataset).
Pārbaudi Purchase notikuma Event Match Quality Events Manager. EMQ virs 6 ir stabils rezultāts, virs 8 -lielisks. Savukārt 10 viesa norēķinu plūsmai nav reālistisks mērķis.
Pārbaudi, ka value un currency ir klāt un pareizi abos notikumos. Bez value Meta optimizē gandrīz akli.
Pārliecinies, ka servera notikums sūta klienta client_ip_address un client_user_agent, nevis tava servera datus. Tāpat pārbaudi, ka client_user_agent un event_source_url vispār ir klāt, jo bez tiem vietnes notikumi var tikt atmesti.
Pārbaudi, ka em (un ph, ja to vāc) ir hašēti ar SHA-256 un ka pirms hašēšanas tie ir pārvērsti mazajos burtos un attīrīti no liekajām atstarpēm.
Pārbaudi, ka fbp un fbc tiek notverti un pārsūtīti neapstrādātā veidā. Uzklikšķini uz reklāmas (vai testam pievieno fbclid manuāli), veic pirkumu un pārliecinies, ka fbc parādās payload.
Pārliecinies, ka produkcijas notikumos nav test_event_code un ka piekrišanas ierobežojumi vienādi attiecas gan uz pārlūka, gan servera notikumiem.
Salīdzini nedēļas pasūtījumu skaitu veikalā ar Purchase notikumu skaitu Ads Manager. Neliela atšķirība ir normāla atribūcijas realitāte. Taču divkārša atšķirība jebkurā virzienā parasti nozīmē salauztu deduplikāciju, mirušu notikumu avotu vai divus rīkus, kas abi pretendē uz vienu un to pašu pirkumu.
Nokopē šo sarakstu, izej tam cauri reizi ceturksnī un atkārto pēc katras dizaina (theme) maiņas, norēķinu migrācijas vai jauna izsekošanas rīka ieviešanas. Pirkumu izsekošana nebojājas skaļi - tā pūst klusiņām.
FAQ
Vai man vēl vajag Meta Pixel, ja man ir Conversions API?
Jā. Turpini darbināt Meta Pixel līdzās CAPI. Pikselis notver svaigākos pārlūka signālus, piemēram, fbp un fbc, kas uzlabo lietotāju sasaisti, bet deduplikācija nodrošina, ka pārklājošie notikumi tiek uzskaitīti tikai vienu reizi. Pikseļa noņemšana parasti tikai pazemina Event Match Quality, neko būtisku pretī nedodot.
Kāpēc mani pirkumi Ads Manager ir sadubultojušies?
Sadubultoti pirkumi gandrīz vienmēr nozīmē, ka vienu un to pašu notikumu sūta divi avoti bez saskaņotiem event_id. Tas var būt Meta Pixel un CAPI vai arī divi servera puses rīki, kas darbojas vienā veikalā. Meta deduplicē notikumus pēc event_name un event_id vienas datu kopas ietvaros 48 stundu laikā. Ja event_id nesakrīt vai viena puse to vispār nesūta, katrs pirkums tiek uzskaitīts divreiz. Salabo event_id abās pusēs un atbrīvojies no liekā rīka - turpmāk skaitļi izlīdzināsies.
Kāds Event Match Quality vērtējums ir labs?
Tipiskam e-komercijas veikalam ar viesa norēķinu EMQ virs 6 ir labs rezultāts, bet virs 8 - ļoti labs. Tas sakrīt arī ar pašas Meta vērtējuma skalām. Savukārt ideāls 10 praksē gandrīz vienmēr nozīmē pilnus kontaktinformācijas datus katrā notikumā, ko lielākā daļa veikalu nevar un arī nevajadzētu censties panākt. Pirms dzenies pēc pēdējām decimāldaļām, sakārto hašētu e-pastu, korektu IP un user agent pārsūtīšanu, kā arī fbc notveršanu.
Vai Conversions API atrisina iOS izsekošanas zudumus?
Daļēji. CAPI atgūst notikumus, kurus reklāmu bloķētāji un Safari ITP neļauj pārlūka pikselim nosūtīt, tāpēc Meta redz lielāku daļu tavu reālo pirkumu. Taču tas nevar atgūt identitātes signālus, kurus iOS privātuma mehānismi patiešām ir noņēmuši. Tāpēc daļa atribūcijas vienmēr paliks modelēta. Reālistiskais maksimums ir pilnīgāka notikumu piegāde kopā ar iespējami spēcīgiem sasaistes parametriem.
Ko izmantot par event_id?
Izmanto pasūtījuma ID vai no tā atvasinātu deterministisku vērtību. Tas ir unikāls katram pirkumam un pieejams gan pārlūkam, gan serverim - tieši tas, kas deduplikācijai ir vajadzīgs. Nejauši vai uz laika zīmoga balstīti ID, kas katrā pusē tiek ģenerēti atsevišķi, nekad nesakritīs.
Vai Shopify iebūvētā CAPI integrācija ir pietiekami laba?
Vairumam standarta Shopify veikalu - jā. Ar Enhanced vai Maximum datu koplietošanu tā automātiski parūpējas par event_id, deduplikāciju un neprasa nekādu papildu infrastruktūru. Vienīgi pārbaudi, vai jaunākais Optimized pikseļa iestatījums klusi neaptur tavus pārlūka notikumus. Uz servera puses GTM vai tādiem rīkiem kā Audiense Online (agrāk Elevar) ir vērts pāriet tikai tad, kad tev vajag pielāgotus parametrus, sarežģītāku piekrišanas loģiku vai notikumu apstrādi, ko iebūvētā integrācija neatbalsta.
Ja Ads Manager skaitļi arī pēc šī kontrolsaraksta iziešanas joprojām nesakrīt ar tavu veikalu, tā parasti vairs nav sīka konfigurācijas kļūda. Visbiežāk tā ir strukturāla problēma - nepareizi savienota piekrišanas loģika, līdz galam nepabeigta migrācija uz servera puses izsekošanu vai vairāki rīki, kas vienlaikus pretendē uz vienu un to pašu pirkumu. Tieši šādām situācijām ir paredzēts SerpCtrl izsekošanas audits. Es pārbaudu neapstrādātos payload, lai tev nebūtu jāpaļaujas uz informācijas paneļiem uz vārda.
