Events
—
Connecting…
—
—
—
—
Each stage counts the events that got at least that far, so every step is a subset of the one above it
Country is read from the request at the edge, never from the browser
| Country | Events | vs prev. | Leads | CR |
|---|
Parsed server-side from the user-agent
The last ten rows to reach the database. Send one yourself — your own country and device will be read from the request.
| Time | Type | Country | Device | Browser |
|---|
Crawlers that spoof a browser user-agent and run JavaScript are not among these — catching those needs a datacentre-IP feed this project does not buy, and the same limit applies to GA4 and Plausible.
What the conversions were attributed to, and where the traffic came from
| Campaign | Ad | Conv. | Revenue |
|---|
| Source | Events |
|---|
Once a conversion is settled it is sent back to the ad platform, so the platform can optimise on it. This is that queue’s own record.
What this page shows. Every figure here is a real row in a Postgres database, written by a tracking endpoint of my own. Nothing is seeded and nothing is simulated: the traffic is whatever has actually reached the pipeline in the selected period, which on a portfolio project is modest by definition.
How an event is captured. A one-line snippet on a page fires a POST to a serverless endpoint. The browser sends almost nothing — a type, a site name, the click ids in the address bar. Country, city, device, OS and browser are read from the request itself at the edge, so an ad blocker that kills a third-party pixel does not remove the event, and a spoofed client value cannot reach the database. The visitor's IP is salted and hashed before storage; it is counted, never kept.
Why a conversion appears after a lead. A lead is the visitor's action — a form sent. A conversion is the advertiser's verdict on it, and it arrives later, from their server, as a postback: a plain HTTP request carrying the click id, a status and a payout. The click id is what ties the two together, which is why a conversion can be approved, left pending, reversed, or land with no matching click at all. Those four outcomes are in the funnel and in the figures below it.
What delivery means. Once a conversion is settled it is worth telling the ad platform about, so it can optimise on it. That is a Conversions API request — server to server, no browser and nobody on a telephone, with the identifiers hashed, a deduplication key so a browser pixel and this request are not counted twice, and a retry queue for the ones that fail. Delivery health at the foot of the page is that queue's own record: delivered, failed, skipped, and how long the round trip took.
And where those requests actually go. With no Meta credentials attached they go to an endpoint of ours that answers with the Graph API's own contract, and the page says so rather than implying otherwise — real delivery to Meta can only be verified inside the account owner's Events Manager, which a visitor cannot open. Attaching META_PIXEL_ID and META_ACCESS_TOKEN changes the destination, not the code; the block below reads the destination off the delivery rows, so it will say the other thing on its own the day that is true.