Phantom installs
About
Industry issues
We classify mobile ad fraud into three categories. For this article, we examine Phantom Installs. You may also be interested in our articles on Organic Poaching and Junk Installs.
.png)
The spookiest form of mobile ad fraud is what we call Phantom Installs, which covers any form of fraud where an install is reported by the MMP, but no install actually occurred.
We distinguish this from Junk Installs, (which covers where there was a human-driven install but it was useless, such as install farms and incentivized ads) and Organic Poaching (which covers misattribution of real installs). The most common kinds of Phantom Installs we observe are MMP SDK spoofing and passing off old versions of the app as a newer version.
Phantom Installs may be the most dangerous form of ad fraud because they have no theoretical upper limit. Organic Poaching is capped by the number of organic installs your app receives. Junk Installs have a ceiling dependent on the efficiency of any human driven install farm. However a Phantom Install is typically driven by malicious code and could generate as many installs as an MMP permits.
To understand how most Phantom Installs occur it helps to understand the guts of the attribution process.
Understanding the mobile attribution process
To understand how Phantom Installs occur it is helpful to understand the attribution process depicted in Figure 2.
In the ordinary course of events, a user will see and possibly click on an ad, which will fire corresponding impression and click events to the MMP server. While the user is visiting the app store and downloading the app, however, the MMP does not see anything. The MMP will not see the user again until they actually open the app for the first time, at which point the app sends an “open” event to the MMP. If the MMP has never seen this user inside the app before, they will attribute this as an “install”.
Fraudsters exploit this process to register Phantom Installs. It is quite easy for fraudsters to generate fake impression and click events and send them to the MMP. Spoofing the “open” event is a bit tougher, but they can usually accomplish this by utilizing a malicious SDK installed on a real device. This SDK can generate a fake “open” event to the MMP server which the MMP server will frequently misattribute as an install.
The final row in the diagram fills in these gaps by adding in timestamps confirmed by Google Play and iTunes. These timestamps were introduced more recently and may not be available if your app is using an outdated SDK. As a result, the mobile attribution process is essentially bifurcated: if the timestamp is available the it is relatively easy to check for Phantom Installs. If the timestamp is not available then the risk is far greater.
Check 1: Install Timestamps
Google and Apple have helped greatly in the fight against ad fraud by introducing the timestamps that fill in the blind spots in Figure 2. This provides MMPs access to trustworthy data about the user between their click and their open.
Google Play introduced their Referrer API in late 2017 to validate install timestamps against Google’s records. To receive the download timestamp, it is necessary for the user’s phone to ping the Google Play store. For privacy reasons, the request must come directly from the phone and its unique IDFA. If everything checks out, then the app will fire an “install” event the MMP can consider to be reliable.
The presence of the install timestamp makes it easy to verify whether installs are genuine. If the app is using an updated SDK that is compatible with the Google Referrer API, you can easily verify the install with a high degree of confidence. However, this is only possible if the MMP passes you the results of the Google Referrer API. At the time of publication, not all MMPs provide their users this level of transparency.
The process is similar on iOS, where the app store provides MMPs an “install receipt.” Every MMP claims they are checking the iOS install receipt, but again, it is not clear if this is actually the case. Just like with Android, we recommend all MMPs share the iTunes receipt id or timestamp, so advertisers have full transparency into their work.
Additionally, MMPs can help the mobile ecosystem by transparently passing app store install data back to the advertiser via postback. At the time this article was written, only about half of MMPs are passing this data in any form. If you are in the process of selecting an MMP, we urge you to consider whether or not they provide these data as part of your selection criteria. If you are currently integrated, you should ask your account representative how you may access these data.
We hope this convinces all app owners of the value of the importance of updating their SDK to the most current version. Running an outdated SDK significantly increases your risk of ad fraud so we urge everybody to update their SDK immediately.
Check 2: Version Data
The prior section details how easy it is to use the install timestamp to catch Phantom Installs. Unfortunately, many apps are still running on outdated SDK versions and remain at great risk of Phantom Installs.
If the app store download data are unavailable, then it is harder to detect Phantom Installs. We recommend looking for mismatches in (1) app version or (2) SDK version. For example, in Figure 3 below we look at the chart on the right to see that the typical organic install went from app version 1.1.5 to 1.2.1 over the course of the period. The network in question (on the left) demonstrates a similar profile so we do not expect this is suspicious.
Our case study goes into greater detail about a real case where an app was able to detect Phantom Installs using both the checks we have described.
Case Study
For our case study we consider the case of a large mobile commerce app running mobile user acquisition campaigns through multiple ad networks. They were highly concerned about uncovering new methods of fraud, and used DoubleCheck to make sure these two networks were legitimate.
Check 1: Install Timestamps
The first check was to consider the availability of the Google Play download timestamp.
The availability of the Google Play download timestamp was quite varied among their ad networks. Five good networks had download timestamps available in nearly every case. Eight horrible networks almost never had this information available. The remaining networks were in the process of upgrading their SDK and and only had this information partially available.
As a result, we were able to clear the top five networks for Phantom Installs. The remaining networks required additional scrutiny.
Check 2: Version Data
We had to inspect the second network more closely because so many of their installs lacked the Google Play download timestamp. We had to look more closely at this network to examine if the traffic they were sending looked similar to organic traffic. The results were particularly unusual:
The top chart represents organic traffic to the app, which moved between SDK version 4.12.3 and 4.13.0 over the course of the period. The bottom chart represents the SDK version being passed by the ad network. The ad network was primarily passing SDK version 4.3.0, which is a particularly archaic version. Due to this mismatch we can confidently declare that this network is fraudulent and passing Phantom Installs.
The most peculiar part is that the top chart shows some volume of organic installs with the archaic 4.3.0 SDK version (the pink tips). We suspect this fraudulent network is generating many fake installs of the 4.3.0 SDK version, most of which are attributed to the network but some are being passed to look like organic traffic. We suspect this is actually intentional, to make the fake installs look more legitimate.
At any rate, we were able to further consider the purchase rate of the installs that came from the archaic 4.3.0 SDK version. When neither the organic nor attributed installs made any purchases, it was easy to flag the whole category as fraudulent.
Further Reading
More Stories
How CrazyLabs unified UA and monetization to double ROAS and scale ad spend by 50%+
By feeding SDK monetization signals back into its UA campaigns, CrazyLabs more than doubled UA ROAS and grew daily ad spend roughly 50% in two months.
