Store Review Experiences
Is your Data safety form accurate? Include your SDKs
A VIP Betting Tips rejection from 2024 illustrates why Data safety answers must cover third-party libraries as well as an app’s own code.
Updated: 2026-10-20
The real case
“We do not collect data” cannot be answered by considering only our own code. A VIP Betting Tips notice dated 10 August 2024 reported a mismatch between Data safety answers and app behaviour. It identified version code 21 and the device or other IDs data type.
What to check
The notice asked us to account for third-party libraries and SDKs too. Review advertising, analytics, crash reporting and purchasing tools separately. Provider documentation is a starting point; the installed version and enabled configuration matter as well.
For each data type, record which component sends it and why. Remove unnecessary behaviour or accurately disclose necessary, permitted behaviour. Compare the form with the privacy policy. This historical rejection does not establish that the discrepancy persists today.
- Inventory all SDKs and libraries.
- Identify data types, purposes, sharing and retention.
- Compare the final package, form and privacy policy.
Confirmed outcome
The historical rejection and version code are confirmed. These emails do not establish subsequent approval or current data behaviour.
These checks can help reduce avoidable issues; they do not guarantee store approval.
Related game or app
These are real product images from the stores, not evidence of the screens seen during the rejection.
More in this series
Explore the other lessons from our store review experiences.