On a marketplace, a lead is never just an anonymous line in a file: it's a customer request whose origin is documented, timestamped and tied to an identifiable source. Provenance tracing is precisely the ability to answer, for every distributed request, four basic questions — who captured it, when, through which channel, and on the basis of what consent. It's this origin chain, kept up to date end to end, that separates a structured platform from a reseller passing on contact details it cannot account for. leads-qualifie.ch applies this traceability requirement across its entire catalogue, regardless of the category involved.
This dossier explains how traceability actually works, mechanism by mechanism: what provenance really means on a marketplace, what origin metadata is attached to each request from the moment of capture, how the platform tells a verified source apart from an opaque, uncontrollable flow, how the provenance log continuously feeds source scoring, and finally why this traceability isn't a mere technical convenience but a condition of the FADP legal framework that governs a three-party relationship — the final customer, the source and the receiving company.
What "provenance tracing" means on a marketplace
Tracing a lead's provenance means being able to reconstruct its full path, from the moment a final customer expressed a need through to being matched with a company. On a serious marketplace, every request carries a unique identifier to which its birth conditions are attached: the source that captured it, the precise instant of capture, the channel used — online form, call, simulation — and the category and geographic zone it belongs to. This lineage is not rebuilt after the fact, nor taken on the partner's word: it's recorded at the source, at the very moment purchase intent is expressed, which makes it verifiable later on.
This requirement structurally sets a marketplace apart from a resold contact list. A file bought once and for all says nothing about the origin of each line: there's no way to know whether a contact was entered yesterday or three years ago, whether it came from a dedicated form or an aggregated list with no clear consent, nor how many buyers have already received the same details. Traceability reverses this logic: it makes origin a permanent property of the request, carried along throughout its journey, and readable both by the operator who arbitrates and by the receiving company that wants to understand where what it receives actually comes from.
The origin metadata attached to each request
In concrete terms, traceability rests on a set of metadata recorded at the moment of capture and bound to the request through to its distribution. It includes the identifier of the submitting source, the precise capture timestamp, the channel through which the need was expressed, the category and geographic zone, and proof of the customer's consent — box ticked, exact wording accepted, moment of acceptance. To these are added control markers used to detect anomalies: internal coherence of the information provided, technical validity of the phone number and e-mail address, and signals that flag a duplicate of a request already in circulation.
This set of metadata is not merely an archive: it's actively used at every step. At validation, it automatically screens out a request whose origin is incomplete or inconsistent — missing consent, unidentified source, absent timestamp. At distribution, it determines the destination queue and documents the exact number of receiving companies. And if a receiving company later disputes a request, it's this same origin record that is reopened to settle the matter: a request whose provenance cannot be established cannot be defended either, which strongly encourages sources to look after the quality of what they declare upstream.
Verified sources versus opaque flows
The whole value of traceability rests on the reliability of what is recorded at entry. A marketplace therefore doesn't just collect metadata: it first verifies the source itself before activating it. A verified source is a partner whose identity, capture methods and consent-collection mechanisms have been examined, and whose flow is then monitored over time. At the opposite end, an opaque flow is a channel that passes on contact details without being able to document their origin — an aggregated list of undetermined provenance, contacts resold in cascade, unverifiable consent. The difference isn't cosmetic: it determines the very possibility of tracing anything afterwards.
leads-qualifie.ch applies this distinction symmetrically, as with all its two-sided rules: a source that refuses to make its origin verifiable cannot feed the platform, whatever its commercial relationship with the operator. This upstream selection avoids the classic reseller trap of stacking heterogeneous flows without controlling their provenance, then finding itself unable to justify a disputed request. By admitting only sources whose origin chain is established and monitored, the marketplace guarantees that the traceability shown on each request matches a controllable reality, rather than a mere declarative label with no verification behind it.
The provenance log and its link to source scoring
Traceability only fully makes sense over time, through a provenance log that keeps the history of the requests submitted by each source. This log doesn't merely archive individual origins: it aggregates the quality signals observed downstream — share of reachable contacts, proportion of duplicates, complaints received, coherence of the information — and ties them to the source that produced them. It's this accumulation of history that makes it possible to tell a consistently reliable source apart from one that occasionally submits mediocre requests, a distinction impossible to establish from a single isolated request.
This log feeds directly into the source scoring system, the marketplace's central mechanism. A source whose provenance is systematically complete and verifiable, and whose requests convert well downstream, sees its flow valued and better ranked; conversely, a source whose traceability is regularly patchy, or whose contacts turn out to be unreachable, sees its flow downgraded, regardless of its seniority. Traceability and scoring thus form a loop: documented origin feeds the score, and the score in turn steers the volume granted to each source. It's this coupling that pushes partners to maintain clean provenance over time rather than optimising one-off volume at the expense of quality.
Traceability and the three-party FADP legal framework
Traceability isn't just good operational practice: it's the material condition for complying with the legal framework that governs how a request circulates. On a marketplace, the relationship involves three distinct parties — the final customer who expresses a need, the source that captures the request, and the company that receives it — and the Swiss data protection law (FADP) assumes the final customer has given informed consent to be recontacted, and knows the framework within which their details circulate. Without documented provenance, that consent becomes unverifiable, and the legitimacy of the whole chain collapses.
By keeping, for each request, the proof of consent collected, the exact wording accepted and the moment of acceptance, traceability makes this legal requirement operational rather than declarative. It lets the receiving company know on what basis it is authorised to recontact a customer, lets the operator arbitrate a dispute on the strength of facts, and lets the final customer exercise their rights — access, rectification, objection — by precisely identifying the origin of the approach. Provenance is therefore not an isolated technical refinement: it's the thread that ties together compliance, trust between the two sides of the market, and the lasting quality of the requests in circulation — the three pillars a structured marketplace rests on.