An SDK that fires before consent: the vendor’s blind spot
An SDK provider sees its own servers: the requests that come in, the identifiers they carry. What it does not see is the moment and the context in which those requests left. Yet that is where respecting consent is decided.
The gap between the server and the device
From the server, a request looks clean: it arrives, sometimes with a consent signal attached. From the device, the same request may have left before the banner appeared, or after the user refused.
This gap is not hypothetical. Apps send data before consent or after a refusal, and the provider of the SDK involved has no simple way to know.
Why a contract is not enough
An SDK’s documentation describes expected behavior: “fires only after consent”. The real integration depends on the publisher, on its initialization order, on how it wires its banner and CMP.
Between the promise and the execution there is a space only the field reveals. A well-designed SDK can be badly integrated, and fire too early, with no ill intent from anyone.
What a real phone measures
Running the app on a real device, interacting with the banner, then placing each exchange in time: that is what makes the gap visible. Before the banner, after a refusal, every request takes a dated place in the sequence.
The measurement stays factual. It does not say whether the integration is “compliant”: it says what the SDK did, and when, with evidence. The assessment then belongs to the publisher and its counsel.
Taking back your blind spot
For a vendor, knowing this behavior across a representative sample of apps that embed the SDK means taking back what it cannot see. Spotting problematic integrations before they become an incident.
That is the purpose of a check for ad networks and adtech: observing the SDK where it actually runs, app by app.