When an Ad Platform Asks for Consent Proof: What to Send
Ad platforms increasingly audit the consent behind conversion data. What they ask for, what your records need to show, and how to answer without chaos.
Stores used to treat consent records as something only a regulator would ever read. That era is ending. Advertising platforms now audit the consent signals behind the conversion data they receive, because their own measurement products depend on those signals being real. When the audit email arrives, it does not ask whether you have a banner. It asks for evidence that specific conversions carried valid consent.
Answering well is mostly about having records that can be searched the way an auditor searches. This guide covers what platform audits typically request, how consent proof actually works per conversion, and the gaps that turn a routine audit into a scramble.
What a platform audit asks for
The requests vary by platform but converge on the same shape: for a sample of conversions in a period, show the consent state that applied, when it was given, under which notice, and that the data you sent matches the state. They are testing the join between three systems that stores run separately: the consent tool that recorded the choice, the tag layer that acted on it, and the platform feed that received the result.
They also ask about mechanism: how consent is collected, how denial is honored in the tags, how long records are kept, and who can access them. A store that answers the mechanism questions from documentation, calmly and specifically, is most of the way through the audit. A store that answers by describing its banner's colors is at the beginning of a longer conversation.
The per conversion join is the hard part
Proving 'we had consent' in general is easy and nearly worthless. The audit wants the specific conversion's story: this order, this timestamp, this consent record, this signal value in the payload you sent. That join exists only if your records carry identifiers and timestamps that line up with the order and event data, and if the signal you transmitted is itself logged rather than assumed.
Most stores discover their gap here. The consent tool kept records keyed to a cookie ID. The order system knows an order ID. The tag layer logged nothing. Reconstructing the join after the fact ranges from painful to impossible, which is precisely why audits ask: the discipline of keeping joinable records is the control being tested. Build the join before you need it.
Denials are the evidence that matters most
Auditors weight one thing above the rest: proof that denial works. A log full of granted consents and perfectly matching signals demonstrates collection. A log that also shows denied choices, with the corresponding events absent or properly limited in what was sent, demonstrates a functioning system. Anybody can record yes. Recording no, and visibly honoring it in the data, is the part that cannot be faked cheaply.
Test this yourself before an auditor does. Make a denied choice in a clean browser, complete a purchase on your test path, and trace what the platforms received. If the answer is 'the same as a granted purchase', your consent signaling is decorative, and it is far better to learn that from your own trace than from an audit finding with a deadline attached.
Keep an audit packet ready
Assemble the standing packet once: how consent is collected, the record fields and retention, how signals map from choice to payload, who owns the system, and two or three worked examples joining a real past conversion to its consent record and transmitted signal. Update it when the stack changes, the same trigger as every other consent review.
With the packet ready, an audit becomes a correspondence exercise: send the packet, answer specifics from the records, done. Without it, the same audit becomes an archaeology project conducted under time pressure by people reconstructing decisions they did not make. The work is identical. Only the timing, and the stress, differ.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Consent Records for Phone and Chat Orders, What to Keep When a Consent Tool Contract Ends, and Cookiebot Alternatives Compared Side by Side.
Frequently asked questions
Why do ad platforms audit consent now?
Their measurement and modeling products consume consent signals, and regulators hold platforms responsible for the quality of what they ingest. Audits verify that the signals behind conversion data are real: collected, recorded, and honored. Stores should expect them as a routine cost of sending conversion data.
What does consent proof for a single conversion look like?
A joinable chain: the consent record with its timestamp and notice version, the order or event it covers, and the signal value actually transmitted to the platform for that event. Keeping identifiers and timestamps aligned across the consent tool, the store, and the tag layer is what makes the chain possible.
What is the strongest evidence in a consent audit?
Proof that denials are honored: records of refused choices with the corresponding events absent or properly limited in the platform payloads. Granted consents show collection. Honored denials show a functioning system, and they are much harder to fake, which is why auditors look for them.
How do we prepare before an audit arrives?
Keep a standing audit packet: collection mechanism, record fields and retention, signal mapping, ownership, and worked examples joining real conversions to records and transmitted signals. Test the denial path yourself periodically. Prepared stores answer audits from documentation; unprepared stores answer from archaeology.