Google’s Play Integrity API has a new beta feature called device recall, and it closes a loophole free-trial and promo-abuse fraud has relied on for years: reinstalling an app, or resetting a device, to get a “new” identity and claim the same free trial or referral bonus again. Device recall lets an app store a small amount of custom data against a device — flagged for high-severity abuse, already redeemed a trial, already created an account — on Google’s servers rather than locally, so the flag survives exactly the actions a repeat abuser relies on to wipe it. For any app whose revenue model depends on a free trial, referral credit, or first-purchase discount, this is the first reliable answer to “is this really a new user.”
The catch is that device recall only helps if the flag actually gets written and checked at the right moments, and that’s an instrumentation problem before it’s a fraud-prevention one. A team that turns the feature on but doesn’t track how often flags are set, checked, and hit is trusting a black box to fix a problem it has never precisely measured. Worse, teams that have historically approximated repeat-abuse rates from downstream signals — trial-to-paid oddities, referral-credit spikes, suspicious LTV segments — have no way to tell whether device recall actually reduced the abuse or just moved it somewhere the existing proxy metrics can no longer see it.
Data Points to Track
- Recall writes, logged every time your app sets or updates a device’s stored flag, with the reason (trial redeemed, high-severity abuse detected, account created), so the write side of the system is auditable independently of whether it’s ever read back
- Recall reads and hit rate, tracking how often a device check returns an existing flag versus a clean result, since the hit rate is the direct measure of how much repeat activity the feature is actually catching
- Action taken on a positive recall, whether that’s blocking a trial, denying a referral credit, or just logging for review, because the business impact of device recall depends entirely on what happens after a flag is found, not on the flag itself
- False-positive disputes, tracking legitimate users who get incorrectly blocked by a stale or wrongly-set flag, since a device recall record has no natural expiry unless the app builds one in
- Trial and referral conversion rate before and after enabling recall, segmented by whether device recall was active for that user, to isolate the feature’s actual effect from concurrent changes to onboarding or pricing
Setup Steps
- Apply for the device recall beta through Play Console’s interest form before building against it, since the feature isn’t generally available and access has to be approved first.
- Define your flag schema before writing any code — what values you’re storing (abuse severity, trial redemption, account creation) and what each one triggers downstream, so the recall data has a consistent meaning across every place it’s checked.
- Log every write and read event to your own analytics pipeline, not just to Play Integrity’s storage, since Google’s device recall API is a lookup service, not a reporting dashboard — the audit trail has to be built on your side.
- Set an expiry or review policy for stored flags, particularly for lower-severity signals like “redeemed a trial,” so a device isn’t permanently locked out of promotions over what may have been a one-time legitimate use years earlier.
- Build a dispute path for users who get blocked, and route false-positive reports back into the same event stream as writes and reads, so the flag-accuracy data includes the cases where the system got it wrong.
Actionable Insights
A recall hit rate meaningfully higher than your prior estimate of repeat-abuse from proxy signals confirms the old measurement was undercounting, and is worth using to recalibrate how much promo and trial spend was actually being lost. A hit rate that stays flat while trial-to-paid conversion improves suggests the deterrent effect — abusers not bothering to try, knowing the flag persists — is doing more work than the direct blocks, hard to see without write and read counts side by side. And any sustained rise in false-positive disputes is the signal to tighten the flag schema, since device recall’s value depends entirely on legitimate users trusting a reinstall or new phone won’t itself trigger a wrongful block.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert