Proving provenance: how you, as a lead generator, trace every request back to the source

What provenance is

Provenance is the complete story of where a request came from and the path it travelled before it reached your platform. It is more than a source name in a single field: it is the chain of source, channel, campaign and landing page, tied to the moment and the publisher that supplied the request.

Why that matters is immediately practical for you as the operator. A buyer in your network wants to know whether a lead really matches what they ordered. A regulator wants to see that a request was acquired lawfully. And you yourself want to be able to steer quality per publisher: which publisher delivers good requests, and which does not? Without provenance, none of those questions can be answered. With provenance, every lead carries its own history, all the way through your operation.

Which metadata you record as a lead generator

Proving provenance starts with deciding what exactly you keep. A single source name is too coarse; you want the full context. So for every request entering your platform, record at least these elements, at the moment of arrival:

• Source: The publisher or lead supplier the request originally came from, the starting point of the chain in your network.
• Channel: The medium the request arrived through: organic, advertising, email, comparison site or API.
• Campaign: The specific action or campaign the request was acquired under, so you can trace performance per campaign.
• UTM parameters: The utm_source, utm_medium, utm_campaign and utm_content from the URL, exactly as they arrived.
• Publisher ID: The verified ID of the supplying publisher in your network, so every request is traceable to a known relationship.
• Landing page: The exact page on which the request was made, including the version of the form that was live there.
• IP & timestamp: The IP address and the moment down to the second, recorded at the point of arrival and immutable from then on.

Together these fields are not loose notes but a provenance record: a traceable mini-dossier that demonstrates, per request, where it came from and along which path. What that looks like in practice, you can see below.

What a provenance record looks like

A good provenance record shows at a glance the path a request travelled through your network. Here is what a record for a single lead request could look like:

Each field is verifiable on its own, and together they tell one coherent story: this request arrived via a paid advertisement from a verified publisher on a known landing page, at a recorded moment. Nothing has to be guessed, not even by the buyer you deliver the lead to.

Why capturing provenance at intake is stronger

The temptation is to determine provenance only later: from a log file, a report, or a lookup in the CRM. That rarely works well. UTM parameters disappear the moment a visitor clicks through, IP addresses can no longer be reliably linked after a while, and forms get new versions. Whoever reconstructs afterwards fills the gaps with assumptions, and a filled-in gap does not convince a buyer or a regulator.

Capturing provenance at the moment of arrival flips that logic. It is recorded immutably as it was, before anything can change. That gives you, as the operator, three advantages: it is complete (nothing was lost), it is indisputable (nothing was adjusted afterwards), and it is immediately usable (you can steer on publisher and quality right away). Reconstruction produces a likely story; capture at intake produces proof.

How you keep out unknown and fraudulent sources

Recording provenance only has value if the provenance itself is trustworthy. A request from an unknown or falsified source pollutes your data and your delivery to buyers. The filter therefore belongs at the front of your platform, at intake, not only during processing:

The common thread: a request without traceable, verified provenance is not a lead, but a risk. By verifying publishers up front and making provenance fields mandatory, you keep your dataset clean as a lead generator, and every request you do deliver to a buyer stays demonstrably legitimate.

How provenance travels in the audit trail

Provenance is not a snapshot you can forget after intake. A request gets verified, matched, delivered, accepted or disputed, and at every step it must stay clear where it originally came from. That is why the provenance record travels along in the audit trail: it is never overwritten, only appended with the events that follow.

The effect is that a buyer in your network sees the full provenance for every lead received, and that you, as the operator, can read back exactly along which path a request arrived and what happened to it afterwards in the event of a dispute. Provenance that only exists at intake loses value the moment a lead moves further down your chain. Provenance that travels in the audit trail stays demonstrable to the end, under your own brand, across your entire operation.

How OXIAE automates this at intake

The theory above is clear; the manual work is not. That is why OXIAE records provenance automatically the moment a request enters your platform. Source, channel, campaign, UTM parameters, publisher ID, landing page and the timestamp are registered at intake, immutably, before anything can change. Requests without a valid publisher ID or without complete provenance are kept out or flagged, so unknown and fraudulent sources never enter your dataset.

That provenance then travels along through the entire chain you manage as a lead generator. Verification, matching, delivery and disputes are added to the audit trail as separate, traceable events: records are never overwritten, only appended. The result is that every lead carries its own provenance, verifiable by your buyers and exportable whenever you need it, all under your own brand.