Privacy · 9 min
PDPA consent timing for SDKs
If the SDK initialises on splash, you have already collected. Hybrid apps make this worse because the WebView has its own idea of “first paint.”
Thailand’s Personal Data Protection Act is not a European clone, but the operational question for measurement teams is familiar: when may an analytics or advertising SDK start talking? Logicqueuebase’s rule in class is blunt. No advertising or analytics init until a consent artefact is stored. That artefact must be readable by any WebView that loads later.
Splash is not a consent screen
Many shells initialise Firebase, an MMP, and a crash reporter while the splash animation plays. Crash reporting may be essential. Analytics and advertising usually are not. If legal has classified them as requiring consent, the init call is the collection event — not the first logEvent.
We ask students to diff their Application class (or Flutter plugin registration) against the consent screen timestamp. If the SDK process starts earlier, the measurement contract is already dishonest, regardless of what the privacy policy claims.
The late WebView
Hybrid checkouts often load HTML after the user is deep in a flow. That HTML may drop its own cookies, start its own analytics snippet, or hydrate a tag manager. Native consent does not automatically travel. You must pass a signed consent state across a narrow JS bridge, or the WebView must block its own snippets until it can read that state.
Consent Architecture for PDPA, the two-week desk, is almost entirely this plumbing. The legal language is short. The sequence diagram is long.
What we do not claim
This essay is not legal advice. Your counsel should classify each SDK. Our job is to make the timing implementable: a stored artefact, a blocked init, a WebView that does not freelance. If counsel says a particular crash SDK may start earlier, write that exception into the contract so analytics does not quietly follow it.