Meta Purchase

Meta Pixel + Conversions API pri nákupe: Purchase, event_id a deduplikácia

Pri jednom nákupe môže e-shop posielať Meta Purchase z prehliadača cez Pixel aj zo servera cez Conversions API. Ak obe cesty reprezentujú tú istú obchodnú udalosť, Meta ich má vedieť spárovať podľa aktuálnych pravidiel — najmä cez event_id a názov eventu.

Táto príručka vysvetľuje, čo ide browserom, čo serverom, čo je event_id, čo možno technicky overiť z prehliadača a kde už treba server-side alebo Meta account evidenciu.

Obsah vychádza z oficiálnej Meta dokumentácie a metodiky AdsLeak používanej pri overovaní odosielaných nákupných dát.

Diagnostika

Čo treba rozlíšiť

  • Meta Pixel Purchasebrowser
  • Conversions API Purchaseserver
  • Events Managerplatform-side

Pixel vs. Conversions API

Pixel posiela event z prehliadača. Conversions API posiela event zo servera na Graph API. Meta ich popisuje ako dva kanály na zdieľanie tej istej udalosti — nie ako tvrdenie, že CAPI je vždy presnejšie. Pozri Conversions API v dokumentácii Meta.

VrstvaMeta PixelConversions API
Odkiaľ ide eventPrehliadač (Pixel / fbq)Server (Conversions API)
Browser Network / HARTypicky pozorovateľnýNie priamo — Graph API request z prehliadača nevidno
Ovplyvnenie browseromÁno (consent, blokovanie, načítanie tagu)Odlišné — závisí od serverovej implementácie
Purchase parametrePodľa browser payloaduPodľa server payloadu (custom_data, user_data)
Overenie spracovania v MetaNie bez Events ManagerNie bez Events Manager alebo server evidencie

Tri evidenčné vrstvy

Pri diagnostike Meta Purchase nestačí jedna vrstva. Browser Pixel, server CAPI a Events Manager môžu o tom istom nákupe hovoriť rôzne.

  1. 1. vrstva

    Meta Pixel — browser

    Browser-side Purchase môže byť pri teste pozorovateľný v network vrstve: event, value, currency, eventID a content údaje, ak ich request obsahuje.

  2. 2. vrstva

    Conversions API — server

    Server → Meta request v bežnom browser HAR nie je viditeľný. Pixel v prehliadači nedokazuje, že CAPI odišlo, ani aký payload server poslal.

  3. 3. vrstva

    Events Manager / processing

    Prijatie, matching, výsledok deduplikácie a reporting sú platform-side. Bez prístupu do Meta alebo server-side evidencie AdsLeak túto vrstvu nepotvrdzuje.

Ako vyzerá Meta Purchase

Prioritou sú parametre pre ecommerce QA, nie kompletný API reference. Pixel syntax a CAPI payload sú dva formáty tej istej obchodnej udalosti. Oficiálny zoznam Pixel standard events je v Meta Pixel standard events v dokumentácii Meta; CAPI polia v Server event parameters v dokumentácii Meta a Custom data parameters v dokumentácii Meta.

ParameterČo to v praxi znamená
event / event_namePri nákupe má ísť o standard event Purchase. Pixel používa názov v fbq track, CAPI pole event_name. Na deduplikáciu sa musia zhodovať.
value + currencyMeta pri Pixel Purchase vyžaduje value a currency. CAPI ich posiela v custom_data. Nie sú automaticky celková suma, ktorú zákazník zaplatil — záleží na implementácii.
content_ids / contentsIdentifikátory a položky nákupu. Pre katalógové reklamy Meta vyžaduje contents alebo content_ids. content_type sa často posiela ako product.
eventID / event_idIdentifikátor udalosti na párovanie Pixel + CAPI. V Pixeli ide ako eventID v štvrtom argumente fbq. V CAPI ako event_id. Majú sa zhodovať.
event_time, action_sourceCAPI server event: čas udalosti a zdroj akcie (pri webe website). Pixel ich v tejto podobe neposiela.

Meta pri Pixel Purchase vyžaduje currency a value. Value nie je automaticky suma, ktorú zákazník zaplatil — záleží na tom, čo implementácia do payloadu vloží. Princíp source-side QA je rovnaký ako pri GA4 Purchase evente: porovnávať odoslané parametre s testovanou objednávkou, nie s reportingom v účte.

Modelový browser Purchase

Zjednodušený príklad podľa aktuálnej Meta Pixel dokumentácie. Nie je to jediný možný spôsob implementácie. Čísla nie sú z reálneho e-shopu. eventID ide ako štvrtý argument fbq('track'), nie ako pole vo vnútri custom objectu.

Zjednodušený príklad

fbq track Purchase

fbq("track", "Purchase", {
  value: 79.90,
  currency: "EUR",
  content_ids: ["SKU-001"],
  content_type: "product"
}, {
  eventID: "ORDER-12345"
});

Modelový CAPI event

Zjednodušený server payload tej istej objednávky. Nie je to produkčný request ani návod na credentials. User data sú placeholdery — Meta vyžaduje SHA-256 hash normalizovaných údajov, pozri Customer information parameters v dokumentácii Meta. event_id sa zhoduje s Pixel eventID.

Zjednodušený príklad

Conversions API Purchase

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1711929600,
      "event_id": "ORDER-12345",
      "action_source": "website",
      "user_data": {
        "em": ["HASHED_EMAIL_SHA256"],
        "ph": ["HASHED_PHONE_SHA256"],
        "client_user_agent": "Mozilla/5.0"
      },
      "custom_data": {
        "value": 79.90,
        "currency": "EUR",
        "content_ids": ["SKU-001"],
        "content_type": "product",
        "contents": [
          { "id": "SKU-001", "quantity": 1, "item_price": 79.90 }
        ]
      }
    }
  ]
}

Ako funguje deduplikácia Pixel + CAPI

Meta sa snaží rozpoznať, keď Pixel a Conversions API posielajú tú istú udalosť, a duplicitu zahodiť. Odporúčaná metóda je kombinácia identifikátora a názvu eventu. Pravidlá sú v Handling Duplicate Pixel and Conversions API Events.

  • eventID / event_id

    Pixel eventID sa musí zhodovať s CAPI event_id. Meta uvádza, že ID má byť unikátne pre danú udalosť — napríklad číslo objednávky, ak každá objednávka dostane iné.

  • Názov eventu

    Pixel event sa musí zhodovať s CAPI event_name. Purchase s AddToCart sa nespárujú, aj keď majú rovnaké ID.

  • 48 hodín

    Meta uvádza, že ak na ten istý Pixel ID príde rovnaká kombinácia ID + názov do 48 hodín od prvého eventu s daným event_id, následné eventy zahodí. Server event Meta nezahodí, ak v predchádzajúcich 48 hodinách ešte neprišiel browser event — aj keď identický Pixel event príde neskôr.

  • Preferencia pri takmer súčasnom príchode

    V server event parameters Meta uvádza: ak sa eventy zhodujú do 48 hodín, berie sa prvý. Ak server a browser/app event prídu približne v rovnakom čase (do 5 minút), Meta uprednostní browser/app event.

Ako sekundárnu pomôcku Meta v best practices spomína aj kombináciu external_id a fbp. Odporúčaná metóda ostáva event_id + názov eventu. Help Center verzia je v Deduplication for Meta Pixel and Conversions API events (Help Center).

Rovnaký event_id nie je celé riešenie

Aj keď browser a server používajú rovnaké ID, meranie stále môže zlyhať. Rozlišujte technicky pozorovateľný problém od výsledku platform-side deduplikácie v Events Manageri.

Technicky pozorovateľné z browsera

  • Pixel Purchase sa vôbec neodoslal.
  • eventID v Pixel requeste chýba alebo sa mení.
  • Rôzne objednávky v Pixeli zdieľajú rovnaké ID.
  • Browser payload má inú value / currency / content IDs ako objednávka.
  • Browser Purchase odišiel viackrát.

Platform-side výsledok

  • CAPI event sa neodoslal, alebo odišiel s iným ID.
  • event_name sa nezhoduje s Pixel eventom.
  • Meta eventy prijala, ale matching / EMQ je slabý.
  • Events Manager ukáže, či ich skutočne deduplikovala.

Tieto body z browser HAR nevyplývajú. AdsLeak ich bez Meta účtu alebo server evidencie nepotvrdzuje.

Čo možno overiť z browsera

Pri konkrétnom flowe môže byť Pixel Purchase v network vrstve pozorovateľný: či request odišiel, event name, value, currency, event ID a product/content údaje — iba ak ich request skutočne obsahuje.

Pixel request v browseri nie je dôkazom toho, čo server odoslal cez Conversions API.

First-party alebo server-side tagging endpoint v HAR tiež nie je Graph API request na Meta. Nedokazuje prijatie v Events Manageri ani úspešnú deduplikáciu.

Čo treba overiť na server-side / v Meta

Pre úplné vyhodnotenie CAPI implementácie treba inú evidenciu, ako je browser HAR. AdsLeak do týchto nástrojov prístup nemá.

  • Server logy a payload odoslaný na Meta Graph API.
  • Meta Events Manager — Test Events na overenie, či server eventy prišli a či ich Meta označila ako deduplikované. Nástroj popisuje Test Events tool v Meta Events Manager.
  • Diagnostics, Event Match Quality a reporting v reklamnom účte — platform-side spracovanie, nie source-side odoslanie.

Ako porovnať browser Purchase s objednávkou

Checklist platí pre zachytený Pixel payload. Nerozširujte ho automaticky na server CAPI.

  • Odišiel browser Purchase (nie iný event)?
  • Sedí value s definíciou implementácie a s objednávkou?
  • Sedí currency?
  • Zodpovedajú content_ids / contents testovanému produktu?
  • Je v requeste eventID, ak ho implementácia posiela?
  • Neodišiel browser Purchase pri tom istom flowe viackrát?
  • Zodpovedajú zachytené dáta testovanej objednávke?

Najčastejšie chyby

  • Chýbajúci browser Purchase

    browser

    Pri dokončenom nákupe sa Pixel Purchase v network nezachytil. To je source-side observation. Nehovorí, či CAPI odišlo zo servera.

  • Chýbajúci server Purchase

    server / Meta

    CAPI event z browser HAR nepotvrdíte. Overenie vyžaduje server log, payload na Graph API alebo Test Events v Events Manageri.

  • Chýbajúci alebo nekonzistentný event ID

    browser

    Ak Pixel eventID v zachytenom requeste chýba alebo sa pri tom istom nákupe mení, AdsLeak to vie z browser evidencie ukázať. Zhoda so serverom z HAR nevyplýva.

  • Rôzne ID medzi Pixel a CAPI

    server / Meta

    Meta deduplikuje, keď sa Pixel eventID zhoduje s CAPI event_id a názvy eventov sedia. Rozdiel server/browser z prehliadača samého nevidno.

  • Opakovane použité event ID

    obidve vrstvy

    Meta používa event_id na odlíšenie podobných udalostí. Rovnaké ID pre rôzne objednávky môže spôsobiť, že Meta udalosti zlučí. Browser vie ukázať len ID v Pixel requeste.

  • Nesprávna value / currency

    browser

    Meta pri Pixel Purchase value a currency vyžaduje. Ak sa nezhodujú s objednávkou, ide o payload voči scenáru — nie automaticky o výsledok v Ads Manageri.

  • Dva browser Purchase eventy

    browser

    Viac Pixel Purchase pri jednom flowe je source-side observation. Ako to Meta následne spracuje, bez účtu AdsLeak nepotvrdzuje.

  • Browser a server nesú rovnaké nákupné údaje

    server / Meta

    Ak Pixel a CAPI posielajú inú value, menu alebo content IDs pre tú istú objednávku, ide o nekonzistentný business payload. Browser scan ukáže len Pixel stranu. Server payload z HAR nevidno.

Body označené ako server / Meta browser scan sám nepotvrdí.

Čo vie overiť AdsLeak

Pri testovacej objednávke AdsLeak vie overiť zachytený browser-side Meta Purchase a údaje, ktoré obsahoval. Samotný server → Meta CAPI request bez ďalšieho evidence source z browser HAR-u nevidíme.

Source-side, ak je v requeste

  • či sa pri teste odoslal browser-side Meta Purchase
  • akú value a currency obsahoval, ak boli v requeste
  • aké eventID obsahoval, ak ho implementácia posiela
  • aké content / product údaje obsahoval
  • či sa nákupný Pixel signál pri tom istom flowe neodoslal viackrát
  • či zachytené browser dáta zodpovedajú testovacej objednávke podľa scope metodiky

Bez ďalšej evidencie neoveríme

  • či server odoslal CAPI event na Graph API
  • aký bol serverový payload
  • či Meta eventy prijala
  • či Pixel a CAPI v Events Manageri úspešne deduplikovala
  • event match quality, diagnostics a atribúciu

Overiť nákupné dáta na testovacom nákupe

AdsLeak vie na konkrétnej testovacej objednávke preveriť podporovanú source-side tracking vrstvu a porovnať odoslané nákupné dáta so scenárom. Server → Meta CAPI request z bežného browser záznamu nepotvrdzujeme.

Objednať Tracking Check

Doplňujúce informácie

Často kladené otázky

Pixel posiela event z prehliadača. Conversions API posiela event zo servera na Graph API. Pri jednom nákupe môžu ísť obe cesty. Pixel request v browseri nie je dôkazom toho, čo server odoslal cez CAPI.