Yonatan Komornik, Author at Singular

iOS 14 and the deprecation of the IDFA: Answers to your questions

Join us for a special AMA (ask me anything) webinar about UA in iOS 14
on August 12th @ 10am PT with experts from Lyft, Homa Games, and ironSource

Mobile marketing as we know it on iOS is changing. In September when Apple launches iOS 14, the Identifier for Advertisers will be opt-in, and the opt-in dialog will have some very scary language about tracking across the internet.

We expect 0-20% of people will actually opt in.

It’s possible that we’re being optimistic.

This is a very big deal. Eric Seufert calls it apocalyptic, “book of Revelation stuff.” And that means that mobile marketers have a lot of questions. There’s unprecedented demand for information about SKAdNetwork, Apple’s framework for attribution, and how it will work. Marketers also want to know how attribution and post-install conversions will happen, and what MMPs will do to support this new world.

We’re here to help.

Singular was the first mobile measurement partner to announce SKAdNetwork support, and we just gave a massive webinar where 700 marketers got all the latest information on how their jobs are going to change in September, October, and November. If you didn’t see it, here’s how to get full access to the deck and video.

We also have a Slack group for Mobile Attribution Privacy (MAP) Coalition where advertisers, ad networks, publishers, and more can have an open discussion about all the changes. We’d love to have you join and share your perspective, questions, and answers. You can join the Slack group here.

And finally, we had a ton of great questions on IDFA, SKAdNetwork, MMPs, Singular, conversions, and attribution. We’re answering a lot of them right here.

iOS 14 & IDFA: Questions from the webinar

Question: IDFA percentages today

From Dzenis: “How much traffic out there really does have IDFA? Isn’t most traffic still attributed via fingerprinting?”

Answer: About 70% of people using iOS in the U.S. have not turned on Limit Ad Tracking, and therefore are still measurable and targetable via the IDFA. On Android, fewer than 5% have turned the equivalent setting (Ads Personalization) off, so more than 95% on Android are still measurable and trackable.

More details, and data on more countries, here:

Privacy checkup: Limit Ad Tracking up 216% on iOS, but down 85% on Android

Question: Advertisers plans for iOS 14

From Kamara: “What have your customers (advertisers) been saying? Are they planning to ask users for privacy permissions in their app? Any thinking about requiring tracking?”

Answer: Customers are still mapping the best options for their use-case. While some are looking into integrating a more elaborated consent flow, others would try to avoid it at all costs. In any case, that would probably not be enough. We work with our customers to support them and provide the tools to accommodate different situations and scenarios.

More details here:

IDFA iOS 14 FAQ: What’s true, what’s fake, and what’s total fantasy

Question: Impact on programmatic

From Stan: “What will be the implications on programmatic mobile ads and measurement/attribution? Will the IDFA become virtually invisible?”

Answer: The availability of IDFAs will be very minimal … most industry experts assume something like 0-20%. This means DSPs would have to adapt since today, they usually rely on their knowledge of specific devices (by IDFA) to place bids. They may move to a contextual model, but it remains to be seen if that’s an adequate method of estimating ad placement value.

At the same time, big publishers (for example, casual gaming publishers) might be more aggressive about asking for consent. If many do — and if they are successful — it might create a market with a hybrid approach where those who incentivize their users to opt-in would make more money from advertising than those that do not.

Question: Postback data

From Jeevan: “What is the scope of the campaign in the install validation postback? Is it 100 campaigns per ad network? Or is it per ad networkid-advertised-app-id?

Answer: The campaign ID is absolutely in the control of the ad serving party and its meaning can be different for every combination of network, publisher, or advertiser. Within this breakdown, it’s still limited to 100 values.

More details here:

SKAdNetwork 101: What is it? What does it mean for you?

Question: Conversions data

From Jeevan: Is SKAdNetwork for install attribution and conversions as well?”

Answer: SKAdNetwork’s main usage is for install attribution, but it does allow advertisers to postpone the install postback and report a post-install conversion value when it’s finally sent. This can be used, for example, to encode conversion activities the user has performed after installing the app.

Question: Hyper casual games vs IAP games

From Wenfeng: “So hyper-casual games will have a big game, since they only need to compare the CPM for buying and CPM for selling ads. We shall buy hyper-casual games’ stocks if they go public; but for IAP games, they’re doomed. Any thoughts on this?”

Answer: We believe both hyper-casual and IAP-based games will face challenges in this new reality, but nothing really changes. Both will still work hard to achieve positive ROI and, eventually, the market will balance. And don’t forget, the success of hyper-casual games is tied to the success of IAP-based games: if IAP-based games stop advertising, that will hurt hyper-casual significantly.”

Hyper casual does have a simpler model, and in-app purchase games have a longer LTV curve. But a blended deterministic-probabilistic acquisition model that, while not as accurate as today, is still accurate enough to provide ad optimization power and predictive signals, will help both.

Question: Pop-ups allowed?

Goncalo: “Do you think pop-ups will be allowed to force users to enable the IDFAs?

Answer: Apple’s exact policy is not clear on that at the moment. We are still mapping and navigating the legal and policy implications to better understand that. But, a) it seems unlikely, and b) if all apps will work that way, user experience on iOS will be hurt.

As an example, see the following in Apple’s app review guidelines: “Apps must respect the user’s permission settings and not attempt to…force people to consent to unnecessary data access”. Is IDFA necessary for the app’s functions? Depends who you ask.

Question: All existing data dies?

Anonymous: “As users start upgrading their devices all this already existing data will be rendered useless is that right? The IDFA is unique for the device and not the AppStore ID?”

Answer: That’s correct. The IDFA is unique per device, so any IDFAs previously collected would degrade as time goes on. Additionally, Apple’s policy suggests that you are not allowed to cache IDFA values for later use.

Question: Facebook AEO and VO

Uriel: “Do you predict Facebook event-base (not custom audience based) optimization tools like LaL and AEO will also be hurt?”

Answer: Facebook has some options here. It’s not clear whether these would be against Apple’s policy or not, if collected via the Facebook SDK, for example.

What we do know: all other ad networks will have access to limited AEO-style post-install data now as well.

Question: Multi-touch attribution

Anonymous: “What do we see as the impact on MTA and other deterministic measurement that relies on an ID map? Will we see partial IDFA based on apps that were opted in?”

Answer: Data collected from IDFA opt-in users would likely not be generalizable to all your users: it will likely be too small a subset, and they’re also likely to be substantially different from the rest of your users anyway.

Within SKAdNetwork, there is no concept of an impression, so multi-touch attribution is impossible. Singular still collects data from ad networks on impressions and clicks, so it’s likely that we will be able to show probabilistic data highlighting MTA trends.

Question: Re-installs and re-downloads

Anonymous: “Will you be able to see any returning vs new users through SKAdnetwork?”

Answer: Yes. Apple provides a “redownload” flag in SKAdNetwork postbacks. That would allow you to know if this is the first installation of the app by the user or a returning user.

Question: SKAdNetwork data vulnerable to fraud?

Christopher: “If the data will be passed to the advertiser before the MMP, is the data vulnerable to being manipulated?”

Answer: SKAdNetwork notifications are cryptographically signed with Apple’s public key, so they are mostly unforgeable. However, you still need to check them to ensure that the ad network is not returning spurious notifications. Careful verification will still be needed, which Singular will do. Other forms of verification are required as well for fraud prevention purposes, for example, you will have to make sure each notification is unique and was never used before.

Question: Different publishers?

Matt: “How do you distinguish between installs from different publishers?”

Answer: SKAdNetwork 2.0 includes a source-app-id (publisher id) field. Which will allow advertisers to identify different publishers.

What is SKAdNetwork and what does it do?

SKAdNetwork is a framework for privacy-preserving mobile install attribution. It aims to help measure conversion rates of app install campaigns (CPI) without compromising users’ identities.

You might be asking yourself how it achieves that and the key to understanding that is that Apple, and as an extension, the App Store itself is serving as a facilitator. The whole attribution process is actually conducted by the App Store and attested by Apple’s servers. It is then disconnected from user identifiers and temporal information and sent off to the network.

How does it work? Simple… (well, not really, but we will try to simplify it)

When an ad is clicked and the store is opened, the publishing app and the network provide it with some basic information such as network, publisher, and campaign ID. The App Store will then send a notification of successful conversion to the network. It will report the attached values alongside a conversion value that can be reported by the advertised app.

That notification will be sent at least 24 hours after the first launch and will be devoid of any device or user identifying information. Additionally, the App Store conducts the process so the advertised app has no knowledge of the original ad and publisher. In such a way, the network receives an attestation that an install has happened, without tying the install to a specific user, thus preserving privacy.

What to expect when using SKAdNetwork install attribution

First, let’s cover what you get:

Click-through attribution for ads displayed in mobile apps.
Publisher ID of the publishing app, supporting full visibility and transparency into publishers.
Campaign ID which is limited to 100 values and can be used to code any other campaign information (outside of publisher) such as campaign, creative, and placement.
SKAdNetwork would tell you if this is the first time the user installed the app or not (is it a redownload).
Conversion Value, which is a number between 0 and 63 that can be set by the advertiser after a conversion happens, allows basic post-install tracking (for example, it can be used to show the highest level the user got to in the first day of playing). That value’s purpose is to give some estimates to the users’ quality.
Apple’s cryptographic, unforgeable verification of the attribution and parameters. This is important, as it means anyone can verify that an install really happened without compromising user privacy.
Accurate and mostly fraud-free attribution.

Now, to what you don’t get:

View-through attribution isn’t supported, an ad needs to be clicked for the process to start
Click-through attribution for ads displayed in a browser, email campaigns, and any other media apart for native ads
Real-time data – notifications are sent to the network after 24 to 48 hours. Any subsequent update to the conversion value would postpone the notification. (notifications are sent 24 to 48 hours after the app opened or the latest update to the conversion value). Apple is doing that so deter attempts to tie in the notifications with app activity to identify users.
User-level data – notifications do not include user identifiers.
Data on small campaigns or publishers – Apple would send notifications only after a certain amount of conversions happened for the same publisher app and campaign ID.
At this point, we do not know what the thresholds are and how this count is actually being done.
Advanced attribution services such as deferred deeplinking and long cohorts / LTV.

Getting the most out of SKAdNetwork as the Advertiser

As an advertiser, you must be asking yourself what’s the best way to utilize this new mechanism that Apple has created. Here’s a short checklist of the must-haves:

You’ll need your media partners to support it by correctly integrating with the SKAdNetwork API. Chances are you will be mostly covered here because it is expected that iOS 14 will have massive adoption, as is the case with all iOS versions. No one wants to be left behind.
You’ll also need to collect and validate, either yourself or with a vendor, the cryptographically-signed install notifications from each and every media partner, in order to identify any issue or misuse.
The goal here is to make sure everyone is telling the truth, and no funny business is going on. While we would all like to believe that everyone’s telling the truth, we also know that you can never be too safe, for the same reason that self-reported numbers should not be trusted.
Next up is analytics and reporting, to make sense of it all. The SKAdNetwork API provides a limited set of values and identifiers, which poses a challenge, yet not an impossible one. This is where smart encoding would help you maximize the amount of information you can pass via Apple’s API.
For example, Campaign IDs can be valuable but must be selected intelligently. You’ll want to ensure that the way that Campaign IDs are assigned is consistent across your channels and is supporting your reporting.
Intelligent parameter selection can also make a difference in optimization and post-install measurement. Having only 64 values (represented by 6 bits) for conversion information is limiting, yet a lot of information can be encoded using these 64 values if used smartly. For example, users can be categorized based on first-day activity to create segments that would later get grouped and evaluated for performance.
You will need an automated way of assigning and tweaking these values without requiring dedicated Engineering work for it, so you’ll likely want a tool that can manage them, and tie it back to your reports.

Measurement Partners are well-positioned to support this whole process, starting with media partner integrations and assuming the central role in verification, analytics, and reporting. Here at Singular, we have already announced a solution for implementing SKAdNetwork, and the above are the foundations we will be building into that solution. We expect others to follow us on this path.

Interestingly, we see this move as a natural progression of Singular’s product. Singular’s unique position and unique integrations with media partners allow us to make the most out of this new API and enable our customers a fluid, seamless transition into this new age. We will work tirelessly to make sure our customers can utilize all the tools that are available to them.

This article is the first part in a series of articles discussing SKAdNetwork specifics. The next one will take a deeper dive into the mechanisms behind this API. Sign up to follow our blog below!

Join our Mobile Attribution Privacy (MAP) group on Slack to exchange ideas and ask questions about these new privacy measures.

Can click validation solve the problem of app install fraud? (Big hint: no!)

Recently, we’ve seen some noise about click validation, claiming that this will solve the mobile app install industry’s problem with fake users. Sadly, this is far from true.

In fact, there are far better tools to fight fake users, and click validation is one of the worst. Read on to learn why.

TL;DR

Click validation requires an almost-impossible level of adoption to to be effective across all channels.
There are better tools to fight click injection/spamming, ad fraud, and fake users.
Click validation is not useless, but there are more effective options and better ways to spend time and energy.

Click validation: what it is and how it works

In a recent white paper, a competitor claimed that a leading cause of fraud (I would call it an enabler, not a cause) in the industry is that there’s no proof of actual user engagement when a click is reported to an MMP. The white paper also claims that server-to-server clicks remove some of the data and make it harder to spot fraud.

Fraud is a significant problem. Get Singular’s recent fraud prevention report.

These things are definitely true. And their purpose with click validation is to solve these problems by introducing a new mechanism.

Here’s how it would work:

When an ad network serves an ad it would also fire an “Impression Proof” callback to the mobile measurement partner (MMP). Each impression will get a unique ID and the proof will be authenticated by the MMP in some way.
When the user clicks the ad, the click callback would also include that impression ID.
Validation would be performed by doing the following:
- Make sure an impression with matching ID and parameters (for example, device ID) was provided beforehand.
- Make sure the impression didn’t cause too many clicks.
- Optionally, do further statistical analysis to look at the time between the impression and the click, and potentially other parameters.

The claim: Click validation done this way would make app install fraud impossible … or at least very costly to do.

Let’s analyze different properties of the proposed click validation mechanism to spot its strengths and weaknesses.

Let’s start with the big one: Adoption

First, let’s look at ad networks. Pretty clearly, effective click validation requires support on the ad-serving side.

Let’s assume for a moment that click validation is in fact a silver bullet for fighting fraud in the mobile advertising space. Even if that’s true, it would still require all networks and affiliates to implement the feature.

Unfortunately, that’s next to impossible, unless this becomes a standard in the industry.

Findings from Singular’s 2019 mobile attribution fraud prevention report

Fact is, any given MMP’s weight and reach are limited and they would likely only be able to enlist a few quality ad networks who are already actively fighting fraud to work with them. That’s great … except that it means that customers are left open to fraud by all of the other networks in the industry. And if that’s the case, then all MMPs would need to work together to create a standard around click validation.

That alone would force the majority of clean ad networks to implement the solution.

Since this is not currently the case, marketers need to ask themselves what do they stand to gain by leveraging click validation. Currently, it probably only means that they can trust those networks which they already trust a little bit more. That’s not huge value.

Secondly, what about affiliates?

One big hole that click validation fail to address is affiliates and sub ad networks. There’s no solution for cases where the party serving the ads is not the actual network integrated with the MMP. And that would create a unique — and potentially dangerous — situation where these affiliates would actually be trusted just like the network itself (given keys and data).

Or, their impressions would not be verifiable at all, creating a data black hole.

What about click spamming? Can click validation stop it?

The white paper claims that click spamming would now be impossible as “the attackers cannot control the ad serving process.”

This is a big assumption about the parts some networks and affiliates play in some app install fraud. Singular has found more than one case where the ad-serving entity’s SDK was the one to include click injection and spamming code. In addition, these fraudsters had API endpoints supplying tracking links upon request to specific devices, apps, and other parameters.

Additionally, fraudsters do not need to control the actual ad-serving process. Often, they can just rely on the existing process by creating clicks for ads that are served but are not shown or not clicked.

The white paper then also claims that “Click spamming would be made impossible by the same principle, requiring an unviable amount of corresponding impressions with realistic click-through-rates (CTR).”

Here, there are two possible cases:

The attacker does NOT control the ad-serving process
In this case, creating a realistic CTR would indeed be harder for the fraudsters. But in such a case it would actually be easier to just compare the number of impressions reported by the network and the number of clicks reported by the tracker.
The attacker DOES control the ad-serving process
In this case it would be pretty easy for the attacker to create a realistic CTR as they would just game the impressions.

Realistically, there are better tools for the job.

Click spamming is usually used to poach organic users, claiming credit for installs that would have happened anyways. Singular provides Organic Poaching Prevention on Android which renders click spamming campaigns ineffective. (Plus many other fraud prevention tools on both Android and iOS.)

Conversion rate (CVR) is also a great tool for spotting click spamming at scale. Marketers don’t really need super-fancy mechanisms for stopping high-scale click spamming attacks. A simple look at conversion rates can and should be enough. Any source with less than 1% CVR should probably not be trusted.

Finally, as stated previously, comparing network data to MMP data can also help in spotting these cases. (And, by the way, Singular makes this extremely easy by putting all of the data in one place!)

And click injection … can click validation stop that?

Well, let’s start this section by assuming that click injection is still a problem. (It’s solved.)

The white paper claims that click injection is done by listening to “app install broadcasts and firing the click in between the broadcast and install completion.” It continues by claiming that “logically it’s impossible that the user was served a matching ad and clicked it within the same second that the app install was broadcasted.”

This assumption about how click injection works has been invalid for more than two years now.

Fraudsters have long ago found better methods than relying on the install broadcast and can now spot installs before they happen or at the same time the user presses the install button and the app starts to download. In both cases, that means that most of the time, attackers will have ample time to “serve” a new fake impression and then report a click.

Again, there are better tools for the job. Click injection is a problem that is present only on Android, where it’s solved by utilizing other mechanisms such as Google Play Referrer and its timestamps. (And yes, Singular does so very, very effectively.)

So, can click validation solve the problem of fake installs and fake users?

The white paper says that “spoofed users would require spoofed impressions for their clicks, either dramatically increasing the amount of data to be fabricated, or making it downright impossible to perform – as the attackers cannot control the ad serving process.”

Sadly, this is not true even if you assume that the fraudsters are not controlling the ad serving.

In fact, fraudsters can just serve ads and fake installs when they see an ad matching their faked “inventory.” In addition, they can also learn how to query ad-serving entities and make them serve them matching ads.

I’ve personally seen this happen before … even on the biggest Tier 1 networks.

So no, click validation cannot stop fake user attacks. And, to be clear, it’s pretentious to claim that it can. Once again, there are better tools for the job. Many tools, in fact.

Ready to go deeper?

Here are three ways to go deeper and get started on the process of eliminating fraud — and fake users — from your app install campaigns.

1. To learn more about those better tools, please refer to our recent blog post to read about the different methods and their pros/cons.

2. And, check out a short report with data from customers using Singular’s Fraud Prevention solution.

3. Even better? Get a demo of the solution first-hand.

Fixing a $13B problem: How Singular is killing app install fraud

You probably saw the news that we released last week: deterministic Android app install validation. This, along with a number of other improvements we’ve recently made, is a massive industry breakthrough that is completely game-changing for many of our clients.

Some of them are now saving massive amounts of money:

“Singular’s updated Fraud Prevention suite is the most powerful mobile app install fraud prevention I’ve seen,” says Channy Lim, Head of BI Department at Com2uS, maker of the hit mobile game Summoners War. “This will save us literally hundreds of thousands of dollars every month, and lead us to make more effective marketing decisions.”

The news is exciting, but I wanted to dive a little deeper.

I would like to share a little more detail about how app install fraud works, the problems with existing methods of finding it, and what we doing differently at Singular.

How app install fraud works

One of the ways fraudsters steal billions of advertisers’ dollars annually is app install fraud. Or, to put it another way: fake installs.

App install fraud is a collection of fraud methods that create fake mobile users and app installs. As opposed to attribution manipulation fraud, which steals credit for existing legitimate app installs, app install fraudsters take matters into their own hands and create app installs out of thin air.

There are multiple ways to perform fake installs fraud, and naturally, some are better than others.

The simplest and most low-tech way is a device farm. You get a bunch of devices, click a lot of tracking links, install a lot of apps, then open them, delete them, and reset each device’s Advertising ID (Android) or IDFA (iOS). Rinse and repeat regularly, and you’re collecting ad dollars.

But there are far more complex and advanced ways to perform fake installs that generate a lot more money far quicker.

One of the other ways fraudsters scale up their device farm operation is to use emulators and bots instead of real devices and real human beings who use the devices. This can be done in the cloud, and potentially on multiple servers in multiple locations, to try to look authentic.

One of the most notable techniques leveraged by smarter fraudsters is SDK spoofing.

Mobile marketers place software (an SDK) from a Mobile Measurement Partner (MMP) in their apps to monitor and measure the results of their marketing. In SDK spoofing, no app is ever actually installed … but an install is being reported to the MMP and potentially other analytics providers by faking the SDK’s traffic. This can be done by technically advanced fraudsters who understand how communication with the measurement service works and how to emulate that communication.

This is far more scalable than running a device farm, because once they have done the initial work, they can create a script to run on servers around the globe. That creates fake installs on fake devices. Alternatively, they can write code that can run on legitimate users’ devices anywhere, reporting installations of apps that have never been installed: fake installs on real devices.

Another example comes in the form of malware, where malicious apps install and run legitimate apps on real users’ devices. This happened for example with the Viking Horde malware. In such cases the user is real and the app is real but the install itself is fraudulent.

As fraudsters become more advanced they tap more and more into the power of the high-tech fake install techniques, and for good reasons. These attacks are highly scalable and hard to find, therefore netting the fraudsters huge amounts of money.

Detecting and preventing fake installs is hard

There are multiple ways to detect fake installs. The problem is that many are unreliable, inaccurate, and most importantly, ineffective.

SDK Message Hashing
Since SDK spoofing aims to fake an MMP’s SDK traffic, MMPs (including Singular) protect each message sent from the SDK. That’s typically done via hashing: taking the data from the message, a secret key that is different for each app, and combining them to create a blob of data that can be verified on the MMP’s backend.

The problem is that the secret is not so secret, as apps that run on users’ devices can create these hashes, so SDK fraudsters can extract the secret and algorithm from the publicly available app binary. At times they don’t even need to reverse engineer the algorithm since the SDK is open source.

Abnormal numbers of new devices
One interesting statistical technique to fight fake install fraud is to look for a high percentage of brand-new or never-before-seen devices coming from specific ad networks or publishers. When you see abnormally high ratios, it’s generally clear that something fishy is happening.

The problem however, is that fraudsters sometimes leverage existing devices or mingle their fake traffic with traffic from real devices, making it harder to spot anomalies.

Abnormal retention rate or other KPIs
Marketers can sometimes identify fraud by seeing abnormal rates of retention, in-app purchases, or other KPIs. For example, if your average retention is 15% on D14, but installs from a particular campaign, publisher, or network show a 1% retention rate, it’s clear that there’s something that deserves further investigation.

But Singular research shows that fraudsters have learned to fake retention and post install events/purchases.

For example, Singular uncovered a case of extremely sophisticated SDK spoofing campaign on iOS that fools most fraud prevention solutions in the industry. The fraudsters not only generated seemingly legitimate app installs but they also continued to send post-install events, in essence faking real users’ activity. They have even tried reporting in-app purchases, and while doing so reported revenue receipts for these fake purchases.

Sensor data and user behavioral analysis
Sensor data based solutions take post-install fake user detection one step further. These solutions try to detect abnormal devices or users by looking at non-marketing data points such as device movements (via a smartphone’s accelerometer and/or gyroscope), battery data, and user-screen interaction.

How?

Simple: sensor data for real devices should look different than simulators that don’t move.

The challenge is that this can be faked as well as shown in the huge “We Purchase Apps” scandal revealed in October 2018. In this massive ad fraud campaign the perpetrators bought real apps, studied the usage patterns of their real users, and then created fake users coming from those same apps.

One of the biggest targets of this campaign was none other than Google itself, the company who has probably put the most effort into profiling real user activities and protecting advertisers from fake user emulation.

And more …
There are multiple other methods, each of which has its strengths and weaknesses.

The problem with post-install fraud determination

While post-install methods do an important job of raising the bar against fraud they have some inherent caveats that stop them from being effective fraud prevention tools.

1: Statistical (in)significance
Post-install methods are statistical tools that work by looking at groups of installs and checking if one or more of these groups exhibit anomalous activities. Usually these groups would be installs coming from the same publisher. For example, when looking for new devices it’s unsurprising to see a legitimate user with a new device, as new devices are constantly being sold to consumers.

However, for a publisher driving thousands of installs, seeing 95% of those installs from new devices should be highly suspicious. Fraudsters have figured out that they can’t be so blatant, and so they take action and hide. Some drive their traffic from many different publisher IDs and even networks to keep numbers low; some mix their fraudulent installs with legitimate installs to make the anomaly less apparent.

Utilizing such techniques allows fraudsters to avoid detection by making the anomalies statistically less significant, making it a lot harder to distinguish legitimates traffic from fake traffic and so making it harder to stop the fraudulent activities without incurring high false positives.

2) Post postback friction
As the name suggests, post install methods only come into effect after an install has happened, and might be processed days or weeks after the install. That also means that they are evaluated after an install postback is sent to the media source, which means after conversion and billing notification in CPI campaigns.

The result is that the media source will charge for the now-known-to-be fraudulent conversion … unless a process of reconciliation is done. This process is often manual, messy, and a cause of great friction between ad networks and advertisers.

3) Non-optimized optimization
Ad networks often perform real-time optimizations based on initial success analytics: evidence of conversions such as app installs. Now, however, those optimizations will be skewed by fraudulent activities.

In effect, having been rewarded by fraud, they will now optimize for MORE fraud.

As an example, if publisher A drives more installs than publisher B for some advertisers, the network might prefer to prioritize publisher A over publisher B and send more ads its way. Now imagine publisher A is actually driving fake installs which are not prevented in real time (as happens in post-install detection). The network will funnel more budget to A over B.

Even if those fraudulent installs are detected post-install and reimbursed, the damage has already been done and goals will not be met because of the optimization changes and budget shift.

Singular’s solution: deterministic pre-attribution fraud decisions

Singular strives to have no false positives. We want to clearly identify fraud at a granular level. So Singular’s fraud results apply to actual individual installs, devices, and users, not blanket-level sources or publishers (although we can – and do – block those too).

We also want to find fraud as conversions or installs happen.

Anything less will suffer from the problems outlined above.

When we took time out earlier this year to consider everything, it was clear that we needed a different approach here. We needed something that would work in real time — install-time — and have an extremely low false-positive rate while still maintaining effectiveness.

To meet these requirements, we decided to disregard everything we thought we knew about ad fraud and look for something new. As we reported publicly last week, after an exhaustive search we found what we believed would be a high-quality deterministic fake install detection method that works at install time.

The new method we discovered depends on signals from the install device that allow us to verify that a user exists, they truly installed the app from the store, and they haven’t installed the app an unreasonable number of times (sorry-not-sorry, fraudsters who “install” an app on a phone hundreds or thousands of times).

Of course, once we found this method, we knew we needed to validate that it works as expected at scale, in the real world, on thousands of ad networks. To do so we tested with some of the most successful mobile publishers on the planet. And we validated our results against post-install metrics.

The actual implementation of our new fraud prevention method proved to have a tremendous effect on some of our customers, eliminating their fake install problem. (Find more about it in our report.)

In a later blog post we will share some more details about our findings, but it’s safe to say that we were blown away by the scale of the fraudulent activity we’ve found, and as more and more customers utilize the feature, the numbers are only going to grow.

Interested in learning more? Schedule a demo to go even deeper.

Author: Yonatan Komornik