The post-load ad refresh rule: consent on every refresh, not just page load
Publishers refresh ad slots. A reader sits on an article for three minutes and the ad units reload, sometimes several times, to sell more impressions per session. Every refresh is a new auction, new bidders, new data flowing to new vendors. Here is the question most publisher stacks answer wrong: was consent checked on the refresh, or only on the page load?
On many sites the answer is page load only. The consent string was attached to the first auction and assumed to carry forward. Whether that assumption holds depends on what changed between the first auction and the fifth.
Why refreshes are different auctions
An ad refresh is not a replay of the initial auction. Bidder sets shift. A bidder that sat out the first auction can join the third. Floor prices change. And the consent state itself can change mid-session if the reader opens the preference center and updates their choices while reading. A consent string captured at page load describes the world as it was, not the world as it is on refresh number four.
The TCF framework has machinery for this. The consent string carries a timestamp, and the framework expects the string to reflect the current state. But machinery only works if the ad stack uses it. If the wrapper reuses a stale string for every refresh, the string's timestamp is honest about when it was generated and dishonest about the current auction.
The mid-session choice change
This is the case that turns a theoretical problem into a real one. A reader loads the page, accepts everything, reads for two minutes, then opens the footer link and switches to reject. The preference center updates the stored consent. The question is whether the next ad refresh reads the new value.
On stacks where the wrapper fetches the consent string fresh on each refresh, the new choice propagates naturally. On stacks where the string was captured once and cached in a variable, the refresh keeps running under the old consent until the next page load. The reader did everything right. The stack kept the old answer.
Vendor lists drift between refreshes
There is a second, quieter drift. Lazy-loaded ad units, infinite scroll, and refreshed slots can pull in vendors that were not in the initial auction. Each new vendor needs to be covered by the consent the reader actually gave. If your vendor list at refresh time is wider than the list the consent string was generated against, some of those vendors are operating outside the reader's choice.
This is worth checking explicitly because it is invisible in normal testing. The first auction looks correct. The consent string is valid. The problem only appears on the third or fourth refresh, on a long session, with a vendor that joined late. Nobody tests the fourth refresh.
What to verify on your stack
Four checks cover most of it. First, confirm the wrapper re-reads the consent string on every refresh rather than reusing a cached copy. Second, change consent mid-session and watch the next refresh: the auction should reflect the new choice without a page reload. Third, compare the vendor set on the first auction against the vendor set on a late refresh and confirm the consent covers the union. Fourth, check that consent-mode style signals, where you use them, are re-evaluated per refresh and not just per pageview.
Run these checks on your real refresh configuration, including the longest refresh intervals and the pages with the most aggressive refreshing. The pages that refresh the most are the pages where stale consent compounds the fastest.
Document the refresh behavior
When this is working, write it down. Your ad operations documentation should state plainly: consent is re-checked on every ad refresh, mid-session changes propagate within one refresh cycle, and the vendor list is reconciled against current consent. That sentence is worth more than a screenshot of a correct first auction, because it describes the behavior your readers actually experience across a whole session.
Consent is a per-auction question for publishers, not a per-page question. The stacks that treat it that way are the ones that hold up when someone looks past the first impression.