What to do when a third-party SDK ignores your consent state
Some SDKs initialize on load and track regardless of what your banner says. When the SDK has no consent-aware mode, contain it yourself: lazy initialization behind a consent gate, a wrapper that holds calls until consent is granted, and network-level blocking as the last line of defense.
Confirm it is actually the SDK
Before reworking code, verify with a declined-consent test: open a private window, reject everything, and watch the network tab for the vendor's domains. If requests fire anyway, the SDK is initializing itself on load rather than respecting your consent state. Document which version behaves this way, because the next SDK update can change it silently. This test takes five minutes and separates an actual SDK problem from a misconfigured gate.
Lazy initialization behind the consent gate
The cleanest fix is to never load the SDK until consent is granted. Hold the script tag out of the initial page load and inject it only when the consent state includes the relevant category. If the visitor has already consented on a previous visit, your consent platform should expose that state early enough to initialize without a flash of the banner. When consent is withdrawn, you should also stop making calls, and ideally unload what you can, though most SDKs make teardown impossible, which is why gating the load matters more than gating the calls.
Wrap it when you cannot gate the load
Some SDKs must initialize early for the app to function, like crash reporting or feature flags with analytics attached. In that case, wrap the SDK: initialize it in its most limited mode, queue every analytics call you would have made, and flush the queue only when consent arrives. If consent never arrives, drop the queue. The wrapper pattern keeps application code unchanged while giving consent one choke point to control. It also gives you a single place to test, which matters when the SDK updates.
Block at the network level as a backstop
When the SDK offers no limited mode and no API for consent, treat its traffic like any other blocked tag. A consent-aware tag manager or a service worker can hold the SDK's requests until consent is granted. This is blunt, and it can break SDK functionality that depends on those calls, so test the refusal path thoroughly: some SDKs throw errors that surface in the console or, worse, in the user interface. But a broken analytics dashboard is cheaper than a consent violation the banner cannot prevent.
Escalate with evidence
File the issue with the vendor and include the network log. Vendors add consent modes when customers ask with evidence, and a report that says "your SDK fires 14 requests after the visitor declined" is hard to ignore. In the meantime, your containment keeps you compliant. Document the workaround and the vendor ticket together, so the next engineer knows the wrapper exists for a reason and the test suite keeps covering it.
Frequently asked questions
What is the difference between a cookie scan and a tag audit?
A cookie scan lists what is stored in the browser. A tag audit traces which scripts fire and what they send, including server side events a browser scan cannot see. Serious consent work needs both views.
Why do consent banners disagree with tag managers?
Because each is configured separately and changed on different schedules. A banner can record a refusal while a tag condition still fires, which is why denied state testing in the tag manager belongs in every release check.
How should consent purposes be grouped?
By what the data is actually used for, in language a reader can test against their own expectations. Purposes so broad that everything fits inside them describe nothing and consent to nothing specific.