How Bangkok product teams handle ATT-style prompts on Android

We still see product briefs that say “do ATT on Android.” What they mean is: ask before we touch advertising identifiers or cross-app tracking, and honour a no. Android already has permission models; Thailand already has PDPA. The work is to make the warehouse obey the no, not to mimic an iOS screenshot.

Timing that is not a dark pattern

Ask after the person has done one meaningful action, not during first_open, and not in the middle of checkout. Explain in plain Thai and English what will not work if they decline — usually personalised ads and cross-app reporting, not basic crash notes. If basic crash notes actually break, that is an SDK design error, not a reason to pressure the prompt.

We refuse copy that implies the app will “stop working” if measurement is declined. We also refuse a second prompt in the same session. A settings path is enough.

What the warehouse may remember after decline

Aggregate counts. Surface. Build. Coarse duration. Consent state itself. Not advertising_id, not a hash of it, not a fingerprint of sensors. Signed-in account analytics may continue for actions taken while signed in, if the account is something the person controls and deletion is documented. Guest declined sessions start cold every time.

Bilingual reviews are part of the measurement

Many Bangkok teams review dashboards in English and ship UI in Thai. The prompt copy and the weekly funnel names drift apart. We ask that the declined funnel label match the in-app wording closely enough that counsel can point at both in the same meeting. That small alignment has ended more arguments than any slide about “privacy culture.”

The regional intensive, Bangkok Measurement Desk, spends a day on permission timing and warehouse rules. The flagship studio assumes you will arrive with a prompt already in production, even if it is imperfect.