Lead source tracking means every lead arrives knowing where it came from: the source, medium and campaign of the link that brought the visitor, the ad platform's click id, and the landing page they filled in. We do it without a tag manager, by reading the link once when the visitor lands and stamping it onto the submission on the server, so the answer to "which campaign sent this lead" is a column in the inbox rather than a report someone builds on a Friday.
Ask anyone running paid traffic what their worst reporting problem is and you get the same answer. The leads arrive, and nobody can say which campaign produced them. The ad platform claims more conversions than the inbox contains. The spreadsheet reconciling the two is somebody's Friday.
The usual fix is a tag manager, three container versions, and a data layer that a developer maintains. We wanted the answer to be a column in a table instead.
What lead source tracking has to record
A lead is only half a lead without the context it arrived in. Every lead landflow stores carries:
- Source, medium and campaign, taken from the link's campaign parameters.
- The click id the ad platform added to the link, which is what lets the platform match the lead back to the ad.
- The landing URL the visitor came through, so two pages in the same campaign stay apart.
- The consent state at the moment of submission.
Those are columns in the inbox, not a report you build later.
Tag the links, or there is nothing to stamp
Tracking starts before anyone lands. A link with no campaign parameters arrives as nothing more than a visit, and no amount of clever storage can recover which ad it was. Before a campaign goes live:
- Give every ad, email and post link a source (where it ran), a medium (what kind of link it is) and a campaign (which push it belongs to), and spell them the same way every time. "Facebook", "facebook" and "fb" are three sources in a report.
- Leave the platform's own click id switched on. It is added after the click, so it never appears in the link you write.
- Point each campaign at the page made for it. A page per offer is also a page per question in the report.
Stamp at submit, on the server
When someone lands on a page, the query string carries whatever the ad platform put there. We capture it once, keep it with the session, and attach it to the submission on the server rather than asking the browser to remember and re-send it. Ad blockers, a bounced tab, a refresh from a bookmark: none of them lose the stamp, because the stamp is not the browser's job.
The same holds when the page is not on our domain. A landflow page published onto your own WordPress site through the landflow Connector for WordPress is served from your domain and your theme, but its form still posts to your landflow inbox, so the stamp survives the move.
Inbox first, fan-out second
The order matters more than it sounds. The write to your inbox is the transaction. Everything after it is delivery: the notification email, the Slack message, the conversion event to Meta, the row in Sheets, the contact in your CRM.
If we fired the pixel first and the storage write failed, the ad platform would optimise towards a lead you can never contact. That is the worst possible failure because it is invisible and it compounds daily. It is also why the order is one of the six checks we run before a page can go live.
One queue, one retry policy
Every destination is a row on the same delivery queue. That gives each lead a timeline you can actually read:
- Stored in inbox, 09:12:04
- Email to reservations, 09:12:05
- Slack, 09:12:05
- Conversions API, deduplicated by event id, 09:12:06
- CRM contact, retry one of five, in forty seconds
When a hand-off fails it says so, with the attempt count and the next retry. Compare that with the normal experience, which is discovering three weeks later that the CRM integration stopped working and nobody noticed because nothing ever said it had.
Deduplication is not optional
Browser pixel and server-side event both report the same lead. Without a shared event id the ad platform counts it twice and optimises against inflated numbers. We mint the id at submit and send it on both paths, which is unglamorous and removes an entire category of argument about whose numbers are right.
What we do not do
We do not build a profile of the visitor, and we do not sell what we collect. The stamp exists so a merchant can answer one question about their own traffic. Consent Mode is on by default in the EU and the UK, which means in those regions nothing fires until somebody says it can.
Tracking is built into every page rather than added afterwards, which is easier when there is only one kind of page and one form to track. Every template in the landing page template library starts with it in place, from booking pages such as Hotel Booking Platform to dated releases such as Waitlist Drop.