Auditing Consent on the Order Confirmation Page
The confirmation page fires the most valuable tags on the store, and it is the page most often missing from consent audits. Check what runs after the purchase.
A customer completes a purchase and lands on the confirmation page. Behind the scenes, the page fires the purchase event, the affiliate tag, the review request pixel, and the ad platform's conversion tag, all in a few hundred milliseconds. If the customer declined marketing cookies on the product page, most of those tags should not fire. On many stores, they do, because the confirmation page was never part of the consent audit.
The confirmation page is the most valuable page on the store and the least audited. It is also the page where a consent failure is easiest to prove, because the tags it fires are the ones that carry personal data to third parties.
What runs on the confirmation page
A typical confirmation page fires four kinds of tags: the analytics purchase event, the advertising conversion tag, the affiliate or referral tag, and the post-purchase survey or review pixel. Each of these sends data to a different third party, and each of them needs a lawful basis. For marketing and analytics tags, that basis is usually consent, and a declined consent state should block them.
The problem is that the confirmation page is often built by a different team, or a different app, from the rest of the store. The consent tool covers the product and checkout pages, and the confirmation page loads its tags from a separate snippet that never checks the consent state. The audit that covers the storefront and skips the confirmation page misses the tags that matter most.
How to audit it
Make a test purchase with marketing consent declined, and watch the network requests on the confirmation page. Every request to an advertising or analytics domain is a tag firing, and each one needs to be justified against the consent state. A tag that fires after a decline is a finding, whether it sends personal data or not, because the consent state was ignored.
Check the purchase event itself. The analytics purchase event carries the order value and the product list, and it should respect the consent state like any other analytics tag. If the store uses consent mode, verify that the denied state actually suppresses the tag, not just the cookie, because a tag that fires without writing a cookie can still send data.
The fix that holds
Route every tag on the confirmation page through the same consent check as the rest of the store. If the store uses a tag manager, put the consent condition on the confirmation triggers, not just on the page view triggers. If the tags are hardcoded, wrap them in the same consent check, and test the denied state after every change to the confirmation page.
Add the confirmation page to the consent audit checklist explicitly, with a test purchase in the denied state. The page changes less often than the product pages, but when it changes, it changes the tags, and a new tag that bypasses the consent check is the most common way a store drifts out of compliance.
Related reading: Consent Mode in the Denied State: Auditing Tags When the Answer Is No, Auditing the Mobile Banner: When Consent Covers the Whole Shop, Auditing Consent After a Theme Update: Banners That Silently Reset.
Frequently asked questions
Why audit consent on the confirmation page?
It fires the most valuable tags on the store: the purchase event, the advertising conversion tag, the affiliate tag, and the review pixel. If the customer declined marketing cookies, most of those should not fire, and the confirmation page is the page most often missing from consent audits.
How do I test consent on the confirmation page?
Make a test purchase with marketing consent declined and watch the network requests on the confirmation page. Every request to an advertising or analytics domain is a tag firing, and each one must be justified against the declined consent state.
Does consent mode stop tags from firing?
Consent mode in the denied state should suppress the tag or send it without identifiers, depending on the configuration. Verify that the denied state actually suppresses the tag, not just the cookie, because a tag that fires without writing a cookie can still send data.
Who usually owns the confirmation page tags?
Often a different team or app from the rest of the store, which is why the page gets missed. The tags may be hardcoded in a separate snippet that never checks the consent state, so route them through the same consent check as the rest of the store.