7 September 2025 · Recovery
Attribution windows for re-permission campaigns
Once a user has denied the OS dialog, many apps ship a settings deep-link and then claim every later Allow inside 30 days. That window is long enough for an OS update, a family member tinkering with the phone, or simple curiosity to impersonate your campaign. Re-permission work needs a shorter leash.
Eligibility first
Before attribution, ask whether the user is even eligible. iOS after a deny usually requires a settings visit. Some Android OEM skins make “ask again” indistinguishable from a dead end. If your ledger cannot separate eligible from ineligible, stop the campaign. You will otherwise “convert” people who were going to remain denied no matter what copy you wrote.
A window we will put in a memo
For in-app recovery CTAs that deep-link to settings, we credit an OS Allow only if it occurs in the same session or within two hours of returning to the app, and only if no other permission education screen fired in between. That is strict. It under-credits some genuine slow readers. It also stops the monthly dashboard from looking like a revival tent.
Email or line-of-business messages that mention “turn on alerts” get an even shorter same-day window, and only for users who opened the message. Last-click across all channels for 30 days will make the CRM tool look like a hero and the product prompt look useless, or the reverse, depending on who owns the report.
What not to do
Do not fire a second system prompt after a clear deny and call it “re-permission.” That is not a windowing problem; it is a policy problem. The Re-permission Eligibility lab exists to map the legal and technical ceiling. Attribution comes after that map, never before.
If finance needs a longer window for budget theatre, keep it in a side tab labelled as such. Do not let it overwrite the ledger the product team uses to decide whether the deep-link stays.