Meta Conversions API: kodėl vien Pixel nebeužtenka ir kaip įdiegti be dublių

Meta Pixel veikia lankytojo naršyklėje, todėl nuo jos ir priklauso. Jei naršyklėje įjungtas reklamos blokatorius, Pixel failas neįsikelia ir pirkimas Meta niekada nepasiekia — nors pinigai jau jūsų sąskaitoje. Conversions API (toliau — CAPI) tą patį įvykį siunčia iš jūsų serverio, kur blokatorių nėra.

Šis tekstas — apie tai, kada CAPI verta diegti, kaip jį sujungti su Pixel, kad pirkimai nesidvigubintų, ir kaip elgtis su asmens duomenimis. Rašome iš praktikos: neseniai CAPI diegėme WordPress svetainei su rezervacijų įskiepiu ir mokėjimu kortele.

Kodėl vien Pixel nebeužtenka

Pirmas ženklas paprastai matyti palyginus ataskaitas: pirkimas yra Google Analytics, o Meta jo nėra. Viena iš priežasčių — naršyklėje užblokuotas Pixel failas fbevents.js. Tokio pirkimo Meta nemato, nepriskiria reklamai ir iš jo nesimoko.

Paleidę CAPI, savo žurnale matėme būtent tokių atvejų: Pixel naršyklėje buvo užblokuotas, o serveris pirkimą išsiuntė. Be serverio pusės šių pirkimų Meta nebūtų gavusi.

Dvi išlygos iš karto:

• CAPI neapeina slapukų sutikimo. Jei lankytojas nesutiko su rinkodaros slapukais, serveris neturi siųsti nieko — lygiai kaip ir Pixel.
• CAPI nepataiso naršyklės pusės klaidų. Jei Pixel siunčia dublius ar Purchase dar prieš apmokėjimą, serveris tas klaidas tik pakartos. Pirmiausia sutvarkykite Pixel, tada imkitės serverio.

Kaip tai veikia

1. Lankytojas apmoka, mokėjimų sistema patvirtina mokėjimą.
2. Naršyklėje Pixel siunčia Purchase su unikaliu įvykio numeriu (event_id).
3. Jūsų serveris siunčia tą patį Purchase su tuo pačiu event_id į Meta Graph API adresą /<pixel_id>/events.
4. Meta abu pranešimus sujungia į vieną pirkimą. Jei Pixel buvo užblokuotas, lieka serverio pranešimas.

Serverio užklausa atrodo maždaug taip (sutrumpinta; prieigos raktas pridedamas parametru access_token):

POST https://graph.facebook.com/<versija>/<pixel_id>/events
{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1760000000,
    "event_id": "purchase-a1b2c3",
    "action_source": "website",
    "event_source_url": "https://example.com/aciu",
    "user_data": {
      "em": ["<el. pašto SHA-256>"],
      "ph": ["<telefono SHA-256>"],
      "client_ip_address": "…",
      "client_user_agent": "…"
    },
    "custom_data": { "value": 45.00, "currency": "EUR" }
  }]
}

Dublių nebus, jei sutampa event_id

Kai įvykis ateina ir iš naršyklės, ir iš serverio, Meta turi suprasti, kad tai tas pats pirkimas. Tam abu pranešimai turi turėti vienodą event_name ir vienodą event_id. Pixel kode jis perduodamas ketvirtuoju parametru:

fbq('track', 'Purchase', { value: 45.00, currency: 'EUR' }, { eventID: 'purchase-a1b2c3' });

Atkreipkite dėmesį: Pixel kode parametras vadinasi eventID, o serverio užklausoje — event_id. Juos lengva supainioti.

event_id geriausia sudaryti iš paties užsakymo duomenų, pavyzdžiui, iš vidinio užsakymo numerio ir įvykio pavadinimo. Tada naršyklė ir serveris jį žino nepriklausomai vienas nuo kito. Atsitiktinis numeris, sugeneruotas tik naršyklėje, serveriui nežinomas — ir dublikatų šalinimas neveiks. Jei event_id nesutampa arba jo nėra, tas pats pirkimas gali būti užskaitytas du kartus, ir grįžtate prie problemos, nuo kurios bėgote.

Asmens duomenys: hash'as prieš siunčiant

Kad Meta galėtų susieti įvykį su žmogumi, serveris kartu siunčia el. paštą ir telefoną. Bet ne atviru tekstu: abu užkoduojami SHA-256 hash'u prieš siunčiant. Prieš hash'uojant duomenis būtina sunorminti, kitaip jie nesutaps su tuo, ką turi Meta:

• el. paštas — mažosiomis raidėmis, be tarpų pradžioje ir gale;
• telefonas — tarptautiniu formatu, tik skaitmenys, be „+" ir tarpų: 8 6xx xxxxx virsta 3706xxxxxxx.

Nehash'intų duomenų niekur nesaugome — nei žurnale, nei papildomose lentelėse. Žurnale lieka tik tai, ar įvykis išsiųstas ir ką atsakė Meta. IP adresą ir naršyklės identifikatorių (user agent) Meta priima nehash'intus.

Kadangi duomenys keliauja iš jūsų serverio į Meta, tai turi būti aprašyta privatumo politikoje. Atnaujinkite ją prieš paleidimą, ne po.

Sutikimas galioja ir serveriui

Naršyklėje Pixel sutikimo laukia savaime — jį sulaiko slapukų įskiepis. Serveris to nežino, todėl sutikimą turi patikrinti pats: perskaityti sutikimo įskiepio (pavyzdžiui, Complianz) slapuką ir siųsti įvykį tik tada, kai lankytojas sutiko su rinkodaros slapukais. Be sutikimo serveris nesiunčia nieko, net hash'intų duomenų.

Prieigos raktas ir bandomasis kodas

CAPI prieigos raktas sugeneruojamas Events Manager nustatymuose. Jis saugomas serverio konfigūracijoje — WordPress atveju, pavyzdžiui, konstanta wp-config.php faile, — o ne duomenų bazėje ir ne el. laiškuose. Jei raktas keliavo el. paštu, po paleidimo sugeneruokite naują.

Testuojant Events Manager skiltyje „Test events" gaunamas test_event_code. Kol jis pridedamas prie serverio užklausų, įvykiai keliauja kaip bandomieji ir rodomi „Test events" skiltyje. Meta nurodo šį lauką naudoti tik testuojant, todėl po testo jį būtina ištuštinti. Patogiausia jį laikyti atskiru nustatymu: įrašai — testuoji, ištrini — veikia gyvai. Pamirštas bandomasis kodas — klaida, kurią lengva padaryti ir sunku pastebėti.

Meta atsako į kiekvieną užklausą — atsakyme yra laukas events_received, kiek įvykių priimta. Klaidingą atsakymą verta įrašyti į žurnalą ir iš karto pranešti atsakingam žmogui, o ne leisti klaidoms gulėti tyliai.

Kodėl skaičiai vis tiek nesutaps

Net ir su CAPI Meta, GA4 ir jūsų sistema rodys skirtingus skaičius. Svarbiausia priežastis — priskyrimo langai. Meta pagal nutylėjimą pirkimą priskiria reklamai, jei jis įvyko per 7 dienas po paspaudimo arba per 1 dieną po peržiūros. GA4 gali žiūrėti iki 90 dienų atgal. Tai normalu: lyginkite tendencijas, ne tikslius skaičius, o vienintele tiesa laikykite apmokėtus užsakymus savo sistemoje.

Kiek tai kainuoja

Kai kurios platformos ir įskiepiai turi CAPI integraciją per Meta partnerius — pirmiausia pasitikrinkite savąją. Rezervacijų įskiepiams ir savoms sistemoms jos gali nebūti arba ji gali siųsti ne tuos įvykius; tada rašomas savas srautas. Mūsų kainodaroje tokios integracijos patenka į 500–2 000 € rėžį, tikslią kainą pasakome pamatę jūsų sistemą. Plačiau — automatizacijos paslaugos puslapyje.

Jei darbą užsakote kitam programuotojui, į techninę užduotį įrašykite bent: event_id formatą, duomenų normavimą ir hash'avimą, sutikimo patikrą serveryje, prieigos rakto vietą ir klaidų žurnalą. Kaip tokią užduotį parašyti, rašėme straipsnyje apie techninę užduotį programuotojui.

Ką daryti rytoj

1. Palyginkite praėjusio mėnesio apmokėtus užsakymus: kiek jų yra jūsų sistemoje, kiek GA4 ir kiek Meta.
2. Patikrinkite, ar jūsų platforma ar įskiepis jau turi Conversions API integraciją.
3. Prieš diegdami nuspręskite, iš ko bus sudarytas event_id ir kaip serveris tikrins sutikimą.

Dažniausi klausimai

Ar Conversions API apeina slapukų sutikimą?

Ne. Serveris turi tikrinti tą patį sutikimą kaip ir Pixel. Be sutikimo rinkodaros slapukams jis nesiunčia nieko.

Ar galima naudoti tik Conversions API, be Pixel?

Galima, bet Meta rekomenduoja abu kartu. Pixel sukuria slapuką _fbp, kurį serveris gali perduoti kartu su įvykiu, — taip Meta lengviau susieti įvykį su žmogumi. O serveris apsaugo nuo blokatorių.

Kaip suprasti, ar duomenys susiejami gerai?

Events Manager prie serverio įvykių rodo atitikties kokybės įvertinimą (Event Match Quality). Jei jis žemas, pirmiausia patikrinkite, ar siunčiami el. paštas ir telefonas ir ar jie sunorminti prieš hash'uojant.