Backendové eventy pro leady a e-commerce: event_id, idempotence, retry logika a monitoring

Krátká odpověď

Backendové eventy jsou nejlepší způsob, jak měřit finální obchodní události, ale jen pokud mají stabilní identifikátor, idempotenci, retry logiku, consent stav a monitoring. Nestačí „poslat serverem purchase“. Musíte vědět, co se stane při refreshi, opakovaném webhooku, selhání API, změně stavu objednávky, refundaci nebo duplicitním leadu.

Zdroje backendových eventů

Backendový event může vzniknout při zápisu formuláře do databáze, vytvoření leadu v CRM, potvrzení rezervace, zaplacení objednávky, změně statusu objednávky nebo uzavření obchodu. Výhodou je, že event nevzniká z kliknutí uživatele v browseru, ale z reálné obchodní akce.

Typické eventy: lead_created, lead_qualified, booking_confirmed, order_created, order_paid, purchase, subscription_started, deal_won. Názvy by měly odpovídat tomu, co se opravdu stalo.

Event_id a obchodní ID

Každý backendový event musí mít stabilní ID. U nákupu použijte order_id nebo payment_id. U leadu lead_id. U kvalifikace leadu například lead_123_qualified. U stejného obchodního eventu nesmí při retry vznikat nové ID.

Pokud stejnou událost posíláte i browserově, event_id musí být sladěné. Browser Purchase a server Purchase pro jednu objednávku mají mít stejný event_id, pokud chcete deduplikaci v Metě. V GA4 je zásadní transaction_id.

Idempotence

Idempotence znamená, že opakované zpracování stejné události nevyrobí duplicitní konverzi. Backend webhooky se často opakují: platební brána pošle notifikaci víckrát, CRM zopakuje request, server retryne neúspěšný požadavek. Bez idempotence vzniknou nafouknuté konverze.

Prakticky si ukládejte tabulku odeslaných eventů: event_id, platforma, čas odeslání, status, response code, payload hash. Když přijde stejný event_id znovu, nepošlete novou konverzi, ale vrátíte existující stav nebo provedete kontrolovaný retry.

Retry logika

API request může selhat. Rozlišujte 4xx a 5xx chyby. 4xx často znamená problém v payloadu, tokenu nebo oprávnění. 5xx může být dočasný problém platformy. Retry používejte s backoffem, limitem pokusů a logem. Neposílejte event donekonečna každou sekundu.

Při retry musí zůstat stejné event_id a stejný obchodní význam. Pokud retry vytvoří nový event_id, deduplikace selže a platforma může započítat více konverzí.

Consent a user data

Backend má často přístup k e-mailu, telefonu, adrese nebo CRM ID. To neznamená, že je máte automaticky posílat všem platformám. Backendový event musí nést consent stav nebo právní rozhodnutí, podle kterého server ví, jaké platformy a jaká data smí dostat.

U Google Ads řešte ad_user_data a Enhanced Conversions podle dostupného nastavení. U Mety řešte customer information parameters, hashování a action_source. U LinkedInu řešte li_fat_id nebo další matching data podle implementace.

Monitoring

Bez monitoringu nevíte, jestli serverové měření funguje. Logujte počet eventů podle typu, platformy, response code, chyb, duplicit, retry a rozdíl proti zdroji pravdy. U e-commerce porovnávejte backend order_paid vs GA4 purchase vs Google Ads conversions vs Meta Purchase. U leadgenu porovnávejte CRM lead_qualified vs importované konverze.

Dobrý dashboard neukazuje jen „eventy odcházejí“. Ukazuje coverage: kolik obchodních událostí mělo click ID, kolik mělo e-mail, kolik mělo consent granted, kolik se poslalo do každé platformy a kolik platforma přijala.

FAQ

Časté otázky

Je backendový event vždy lepší než browserový?

Co je idempotency key?

Co mám monitorovat?