devtodev data does not always match the data from app stores or other systems therefore the metric values may differ. There are several reasons for that and here are some of them:
App installs
There is a significant difference between installing an app and actually opening it, but these two metrics are often confused. An install is a downloading of the app and installing it while the opening is the first launch of the app on your device. To analyze the number of installs in devtodev, you can use the Market Downloads metric.
Second, the devtodev SDK only starts when the app is first opened (essentially, it needs to be activated by the user). Once the SDK is fired for the first time, it sends a signal to our servers, letting us know that a new install has occurred. So we get to know about an app install on a new device only when the SDK reports about it.
This can also influence the time of installation because devtodev considers it to be the first launch but Google and Apple - the time of download.
In devtodev, the number of new users does not equal the number of downloads from the stores. Make sure that you compare the number of installs with the number of installs but not the number of openings with the number of installs.
2. Installs based on user and gadget data
App stores calculate installs by drawing information from user accounts and gadgets. In the Play Console, for example, Installs by user are the number of unique users who installed the app for the first time (based on store user accounts). In the App Store, it is the total number of times your app has been installed on devices with iOS 8 or tvOS 9, or later. Redownloads on the same device, downloads to multiple devices, sharing the same Apple ID, and Family Sharing installations are included. devtodev calculates installs based on a unique gadget ID. As a result, if some of the users change their unique IDs, the user count in devtodev may be more than in other systems.
3. User geolocation
App stores base their data on the geolocation of the store’s account while devtodev identifies the IP address. Let’s say there is a user with a Russian account but he is currently located in the US. The stores will consider all installs from the account as they were made in Russia, but devtodev will write them as American on the user card. Therefore, there are some differences between the two platforms in terms of install time and user geolocation.
4. User time zone
Platforms may differ in how they handle time zones. It is better to agree on some universal standard to avoid data discrepancy. In devtodev you can change the time zone using the Space settings:
5. Installs from third-party sources
If your app (an APK file with integrated devtodev SDK) is available not only on the stores but also from third-party sources like forums etc., devtodev will take these installs into consideration, while the stores will not.
6. Motivated traffic: ad ID reset
If you run campaigns using motivated traffic, some of your users may engage in fraud to be rewarded. They often reset their ad IDs and reinstall the app. After they receive a new ID, devtodev considers them as new installs. The stores ignore the duplicate installs.
7. Fraudulent in-app purchases
In case you compare income data from the stores and devtodev and find out that they don't match, you can try using a devtodev’s anti-cheat method that validates all transactions and only the validated ones get passed to the analytics system.
A problem may occur if the app gets hacked and users start making in-app purchases for free. Purchase queries of this kind are not passed to the Google Play or Apple Store.
8. App update
Some users install the app without the devtodev SDK and that may cause the discrepancy. After they update the app, they will be added to our system as new users. The stores see it as a routine app update because the app was installed before the integration with devtodev. While in the devtodev statistics, you may see a spike immediately after the update, but later it will improve and the data will become more accurate.