The Reject Button That Logs Nothing: Consent Records After a No
Open a consent log and filter for rejections. On most stacks the accept entries carry the full detail: the purposes, the vendors, the timestamp, the banner version. The reject entries carry one line, sometimes one word. That is backwards. The accept is the easy case. The reject is the record a regulator asks for, because the question after a complaint is never whether someone accepted. It is whether someone said no and the site kept going anyway.
The enforcement pattern makes this concrete. California's CPPA fined Honda $632,500 and Sling TV $530,000, and settled with Disney for $2.75 million, over how opt-out choices were presented and carried through. In each case the company had a tool that recorded the choice. The failure was downstream: the choice was logged and then not enforced. A reject that is logged in one line with no record of what stopped, and when, is a receipt for a violation that the company wrote itself.
What a rejection record has to prove
A rejection record has to prove three things, and most platforms prove one. First, the choice itself: which purposes were rejected, at what time, against which banner and policy version. Second, the propagation: which tags were blocked, which vendors were told, and when each one acknowledged it. Third, the negative: that no request carrying an identifier went out after the timestamp. The third is the hard one, because it needs the network log, not the consent log. The consent platform knows what the visitor chose. Only the tag manager and the server logs know what actually fired.
The practical fix is a monthly drill, not a new tool. Pick a real rejection from the log, then reconstruct the hour after it from the server logs and the tag firing history. List every request that carried an identifier, a fingerprint, or a tracking parameter. If the list is empty, the rejection worked. If it is not, the list is the remediation plan, and it usually points at one tag that was never gated, or a vendor that was never told.
The banner copy problem hiding underneath
There is a second reason rejects are thin in the log: the banner is designed to make rejecting hard. An asymmetric banner, accept in one click and reject buried two screens deep, is exactly what the Honda action targeted. The CPPA found the opt-out experience itself non-compliant, not just the enforcement. A reject that takes three clicks is a reject most visitors never reach, and the log then shows a suspiciously low rejection rate that a regulator reads as evidence of the design, not of consent.
Fix the record first, then the banner. A reject that is easy to give and fully logged is the cheapest compliance a site can buy. A reject that is hard to give and thinly logged is the most expensive banner on the site.
Keep reading: The Reject Button That Does Not Survive Navigation, The Consent Cookie That Expires in 30 Days: What Short Expiry Does to Your Records, and Push Notifications Are Not Cookies: The Permission Prompt That Still Needs a Consent Decision cover the nearby cases in this series.
Frequently asked questions
Why do consent logs record accepts in more detail than rejects?
Because most platforms were built to prove consent was collected, not to prove a refusal was honored. The reject is the record a regulator asks for, and it needs the same detail as an accept.
What should a rejection record prove?
Three things: the choice itself with timestamp and banner version, which tags and vendors were told and when, and that no request carrying an identifier went out after the timestamp.
How do I test whether rejections are actually enforced?
Pick a real rejection from the log and reconstruct the hour after it from server logs and tag firing history. Any request carrying an identifier after the timestamp is a failure.
Can the banner design itself be a violation?
Yes. An asymmetric banner that makes rejecting hard was central to the CPPA action against Honda, which fined the company $632,500 over the opt-out experience.