Written by Erick Fang, Mintegral CEO
Recently, questions have been raised about how Mintegral’s SDK collects data and claims credit for installs.
Our ad serving practices have been misclassified as fraud in order to claim credit for app installs, when in practice, our ad optimisation algorithms are considering engagement with ads shown in the app (regardless of the source of the ad) as additional signals, for serving follow-up ads the user is more likely to engage with.
This is widely used by many SDKs, such as ad networks, publishers, security companies, etc., and a practice that we ourselves implemented as, in the past, it was considered best practice for targeting.
We use ad engagements to show better ads
There have been concerns about us collecting click data in order to claim credit for app installs over another ad network’s click. We have indeed collected URLs accessed by users, the data points referred to as “click data”, but we do not, and have never used this data for click hijacking. We use this for optimising our own ads, and to yield better results for our developers.
Knowing which ads have more engagement is valuable information when serving ads. It helps developers get more relevant ads to show, which is the very purpose of an ad provider. In the article below we will detail how we show ads, how we use the data we collect, the results of our analysis into the rate of secondary clicks, and why our ad technology is so good at driving these clicks (with no fraud involved).
We also protect our SDK, with various technologies, against reverse engineering. Different protections of this nature are common in the industry, as providers strive to develop unique strategies for targeting and gain a competitive advantage.
To underline this and further show complete transparency to our customers and partners into our data collection practices, we have also recently announced we will be open-sourcing the Mintegral SDK.
How we show ads
An important differentiator our ad serving technology has, compared to others, is the ability to show multiple dynamic ads in one placement, in real-time. This greatly increases our targeting ability and the efficiency of every impression shown in a placement.
Our system would recommend different groups of ads for every user, according to the context of each request and additional engagement signals. This new technology increases click rates and may introduce differences in many metrics, including secondary clicks between us and others, as it is unique to Mintegral.
The data we collect
Besides showing the ads themselves, a core function of the Mintegral SDK is to power better ad recommendations, through collecting engagement data related to the users and ads. The data points we collect are:
- Advertising identifiers: IDFA/IDFV on iOS, GAID on Google, and Android ID on non-Google Android devices
- IP Address - used to identify the country
- OS Version
- Device make & model Internet browser user agent used to access the ad
- Network connection: 2G / 3G / 4G / WiFi
- Charging state and phone battery capacity
- Mintegral SDK Version
- The app requesting the ad
- Ad engagements: opening the app store, app, or service in the app. This is the URL accessed by clicking on the ads - and was the primary target of the ad fraud concerns.
The collection of the above data is 100 per cent compliant with all rules set out by both Apple and Google, as well as privacy regulations.
How we used ad engagement data
We collect ad engagement data points to assess the potential of different ads, regardless of the source they come from. For example, if we see that ads for strategy games are getting more actions and clicks, we can simply show ads from the same category when requested. Collecting this data benefitted both the developers, who could rely on a supply of well-chosen ads, as well as the users, who saw more ads they were happy to engage with.
Analysis of secondary clicks
After the concerns surfaced, although we knew with certainty that click hijacking was not occurring, we immediately started an internal assessment of our rate of secondary clicks. We did this to obtain a more specific figure, and evaluate the accuracy of the figures called into question. Our findings were very different than those alleged.
With the help of several attribution partners and customers, we found that, on average, less then 7 per cent of app installs attributed to Mintegral had previous clicks from another network. Another way of saying this is that 93+ per cent of Mintegral installs are direct, so stopping these campaigns would mean a direct decrease in total installs.
If this were fraud, the installs would not decrease and just get attributed elsewhere. This level is also 3-4 times lower than the one specified in the allegations and can be explained by factors that were a standard part of our ad distribution, which we will detail below.
We analysed the click patterns in traffic from 10 advertisers on our platform, who agreed to share their data. Doing this, we found a broad range of secondary click rates, between 0.05 per cent and 12.26 per cent. This shows significant differences between campaigns, rather than a consistent, predictable pattern. This broad range of differences indicates that this rate is not purposefully created, but occurs organically as part of regular ad distribution.
Why ads and clicks can repeat
There are many valid reasons why multiple clicks for the same ad can occur. Some of the most common are:
- With large advertisers heavily promoting the same titles across different networks, seeing repeated ads for the same app is extremely common to a user, and an experience we’ve all had while playing games.
- The user clicked on the ad but did not go through with the install, yet when prompted again with an ad for the same app resumed the process and converted.
- Ad frequency in some apps is very high, it is a common occurrence to get ad requests from the same app every 30 seconds, leading to 10-15 ads being shown to a user in the span of a few minutes. This also further increases the likelihood of repeated ads and follow-up clicks, especially in hyper-casual and in-feed ads, which are our main markets.
Further showing this to be the case, we see a similar pattern from one major network, in data obtained from one of our top clients. This simply demonstrates what we believe to be a very common scenario in the ads industry.
Potential technical factors adding to this data pattern are:
- Multi-ads templates: Our ad templates serve multiple ads in one placement, which are sourced entirely from Mintegral. With many ads shown on one screen, the likelihood of an ad repeating is higher, especially, when ads are served across different apps.
- Large-scale user coverage: Mintegral is integrated into tens of thousands of apps, but we also far extend our reach through connecting with all large ad exchanges, which helps us reach more than 2 billion users per day. This significantly increases the chances that the same user will see Mintegral ads repeated in different apps, within a short time window.
- Higher eCPMs/bid price: Our premium traffic and algorithms enable us to offer higher bids for ads. As we combine more top-tier traffic sources than other providers, we are more likely to win placements and show more ads, thus increasing the probability of secondary clicks.
We removed ad engagements from the new SDK
We’ve so far explained what data we collect, how we use it, and that collecting ad engagements is compliant with privacy regulations. However, the current conversation has generated concern around this practice.
To put our partners and users at ease, we’ve decided to simply remove these signals from our collection process. The open-source SDK we are releasing will not contain these data points, and we will not collect them moving forward. We also stopped using these signals in our optimisation process entirely, as soon as the allegations were published.
Despite this challenging period, we appreciate efforts by the companies and media involved, to call for accountability in the mobile ad industry. This conversation has fueled our resolve to make our practices even more transparent, fully open-source our SDK, and put our support behind an initiative to advance the entire industry towards more open, and fair data practices.