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

No IDFA? No problem. Continue to drive growth with Singular’s best-in-market SKAdNetwork solution. Click here to learn more!

What is SKAdNetwork?

SKAdNetwork (StoreKit Ad Network) is a framework, a set of software and protocols created by Apple for privacy-safe mobile attribution for user acquisition campaigns. SKAdNetwork, or SKAN, allows marketers to get deterministic but aggregated attribution of mobile app marketing campaigns. That means marketers know which advertising campaigns worked and what marketing channels are performing, but it’s still privacy-safe: they don’t get device-level data on what individual people are doing.

Apple made SKAdNetwork essentially mandatory for mobile marketers in iOS 14.5 and on.

First, App Tracking Transparency (ATT) required apps to ask permission to access their app users’ IDFAs so they could track ad campaign effectiveness. Then, Apple made it clear that an alternative form of mobile attribution known as fingerprinting — tracking users by following their semi-unique device signatures around the internet — was never kosher: with or without tracking authorization via ATT.

Read on for all the details …

More than 5 years ago, in May 2018, Apple introduced a new concept and API called SKAdNetwork.

That API would allow mobile app install attribution while preserving privacy. At that time, many questions were raised about the future of mobile attribution on iOS and the place of SKAdNetwork in it. But with iOS 14.5, Apple made massive updates to SKAdNetwork and released SKAN 3, the first version that became functionally useful for mobile attribution. The updates to App Tracking on iOS in April of 2021 manifested in the AppTrackingTransparency framework and Apple’s new privacy guidelines.

In 2022, Apple further updated SKAdNetwork with the launch of version 4, commonly referred to as SKAN 4. And at WWDC 2023, Apple announced SKAN 5, which will offer the ability to attribute re-engagements. There are no further details about SKAN 5, however, and we don’t know exactly when it will become available.

SKAN 4 is much more capable than SKAN 3, with several key differences:

  • Privacy thresholds became crowd anonymity, which should reduce null values in install postbacks
  • Campaign IDs became source identifiers, providing more insight into campaigns that work
  • 1 postback became 3 postbacks, offering more insight into quality and cohorts
  • Postbacks became separated into two types: fine and coarse. The first postback can be fine, which  offers 64 different potential values. The second and third postbacks are coarse: 1 of only 4 possible values.
  • Timing changes, with marketers able to lock postbacks when a significant conversion event happens and get earlier data
  • Web-to-app support
  • Conversion values can decrease as well as increase in SKAN 4

(See a full SKAN 3 to SKAN 4 conversion guide right here.)

Singular has been preparing to utilize SKAdNetwork for a long time, and we made those plans a reality very early. We still get many questions from customers and partners who want to learn more, and we’ll continue to update our blog with multiple series to explore how SKAdNetwork works, what kind of data points it provides, and how it can be used for marketing measurement.

In this post, I will try to keep things high level.

What does SKAdNetwork 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.

Apple iOS 14 Attribution

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.

With SKAN 4, which is still being implemented throughout the adtech ecosystem, marketers can also get a second and a third postback, providing more insight into how installs from certain campaigns are doing over time. The 3 postbacks, however, are not connected via an identifier or any other key: any cohort insights must be modeled.

What to expect when using SKAdNetwork install attribution

First, let’s cover what you get:

  1. Click-through attribution for ads displayed in mobile apps.
  2. Publisher ID of the publishing app, supporting full visibility and transparency into publishers.
  3. Under SKAN 3
    1. 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.
  4. Under SKAN 4
    1. Source identifier which — at high levels of crowd anonymity — can provide 4 digits of information on campaign, creative, ad set, geo, and so on
  5. Under SKAN 3
    1. SKAdNetwork will tell you if this is the first time the user installed the app or not (is it a redownload).
  6. Under SKAN 5 (announced by Apple at WWDC 2023)
    1. SKAdNetwork will add the ability to attribute re-engagements with people who already have your app installed.
  7. Under SKAN 3
    1. 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.
  8. Under SKAN 4
    1. The first postback offers the same 0 to 63 number for what is now called a fine conversion value, if you achieve sufficient volume per campaign
    2. Apple has added 2 additional postbacks with conversion payloads that are coarse: 1 of only 3 possible values
  9. 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.
  10. Accurate and mostly fraud-free attribution.

Now, to what you don’t get:

  1. View-through attribution wasn’t initially supported, but Apple has since added some limited capability for view-through attribution
  2. Click-through attribution for all ads displayed in a browser, email campaigns, and any other media apart for native ads
    1. Note though, that Apple added support for web-to-app measurement in SKAN 4. It is only for mobile Safari, however, so desktop and Chrome and Firefox and Brave (etc!) are not supported.
  3. Real-time data
    1. Notifications are sent to the network after 24 to 48 hours. Any subsequent update to the conversion value will 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 to deter attempts to tie in the notifications with app activity to identify users.
    2. Under SKAN 4, the second and third postbacks have even longer postponements.
  4. User-level data: notifications do not include user identifiers.
  5. Data on small campaigns or publishers: Apple will send notifications only after a certain amount of conversions happened for the same publisher app and campaign ID. Apple does not publish what the privacy thresholds in SKAN 3 or the crowd anonymity in SKAN 4 levels are, nor does Apple specify how this count is actually being done.
  6. Advanced attribution services such as deferred deeplinking and long cohorts / LTV.
    1. Though you can get these via Singular’s SKAN solution, with some modeling.

Getting the most out of SKAdNetwork as an advertiser

As an advertiser, you must be asking yourself what’s the best way to utilize this mechanism that Apple has created.

Here’s a short checklist of the must-haves:

  1. You’ll need your media partners to support it by correctly integrating with the SKAdNetwork API. You’re mostly covered here for SKAN 3, and the ecosystem is building support for SKAN 4 now. Expect that to be fairly widespread by late summer 2023.
  2. 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. (Of course, your MMP — Singular — does all this collecting and validating for you.)
  3. 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. (Singular provides super-simple ways to encode SKAN 3 and SKAN 4 campaign and  conversion information.)
  4. 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 such as Singular 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’re pretty confident that we provide the best possible solution for implementing SKAdNetwork, and the above are the foundations we have built into that solution. 

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.

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

Ad fraud tutorial series: What is click injection?

Digital ad fraud, including click injection, is a growing challenge for mobile app marketers.

Fraudsters are constantly developing new methodologies to deliver fake installs. This series of posts is designed to help app marketers understand the key methodologies for perpetrating mobile ad fraud and how they can detect and defend their businesses against bad actors that would steal digital advertising investment from their brand.

The good news: Singular’s best-in-industry fraud detection suite can catch and eliminate click injection fraud. And we integrate with the Google Play referrer API to make this — and other types of fraud — much harder for the bad guys.

This post is about the challenges that arise from fraudster use of click injection, which is similar to click spamming but not identical.

What is click injection?

The traffic flow for an install is a bit more complicated than for other forms of desirable digital advertising actions. With an install, there are extra steps that need to be considered — steps which provide an opportunity for app ad fraud.

Here’s a brief synopsis of the process in five discrete steps.

  1. A user sees an ad and clicks on it, and is redirected to an app store (either Apple App Store or Google Play.) The ad network records the click and sends information about the time the click occurred to the attribution platform.
  2. The user downloads the app and installs it on their device
  3. The user must then launch the app in order for the install to register with the attribution provider.
  4. When the attribution provider receives the signal of an install, it then examines all of the ad signals it has received from ad networks to determine which network(s) deserve credit for that install. In most cases, credit for the install is awarded to the advertiser that delivered the last click before an install.
  5. If no clicks have been registered, then the install is counted as an organic install, and no credit is awarded to an advertiser.

Note: with self-attribution media sources, there’s an additional step, but it is not relevant to understanding click injection.

While sometimes apps are launched immediately after an install, in other cases there is a delay of minutes, hours or days. This delay provides fraudulent actors with the opportunity to claim credit for an install even though they actually did not drive it.

Innocuous-looking fraud apps

The trick they use to do this is to encourage users to download and install a seemingly innocuous free app. For example, a flashlight or toolbar app. The app can function as advertised, but its real purpose is to perpetrate click injection fraud.

Often such mobile apps originate in third-party Android app stores.

It does this by listening for an “install broadcast” — a signal that an app has been launched for the first time on a device. The signal can include a campaign id, and the attribution provider uses this to determine which media source drove the last click.

When the install broadcast is sent, the app goes into action, informing the attribution provider that they just registered an ad click for the campaign, even though no click has taken place. By timing the fraudulent click to the moment of install, the fraudster ensures that it is the “last click” — it will get credit for the install when the app is actually launched for the first time.

An android phenomenon

Click injection is a type of ad fraud unique to Android, because only Android sends install broadcast messages to the apps on a user’s device at the moment of first launch. That broadcast is necessary to alert the fraudulent app to send a click signal to the attribution provider.

How click injection hurts your data

The clicks that these fraudulent app claim to have occurred never actually occurred. Instead, they falsely claim credit for installs driven by other ad networks. Thus they can significantly distort attributions and through them budget allocations.

Detecting click injection

The primary way that companies detect possibly injected clicks by examining the timing of the reported click versus the first launch. With click injection, the timings are likely very close to one another. With other installs, the timings tend to take place farther apart, and follow a fairly consistent distribution. This pattern recognition is an important part of how companies detect and prevent ad fraud.

Defending your business against all forms of ad fraud

Click injection is one of the many ways that app businesses can be affected by ad fraud. Here are a few strategies to help you detect ad fraud in a variety of forms, and protect your business from the costs of ad fraud.

  • Anti-fraud tools: Some attribution and analytics suites offer tools to help marketers identify and prevent ad fraud. Singular, for example, automatically offers many protections. Such tools often use signals like IP addresses, click and install pattern detection, and activity monitoring to pinpoint campaigns, partners and buying models that are driving suspicious app installs.
  • Common sense: A deal that sounds too good to be true is likely to result in low-quality app installs. Marketers must constantly resist the temptation to sign up for media deals that sound too good to be true.
  • Focusing resources on trusted partners: Most brands spend a great deal of money on installs. It makes sense, then, to focus dollars on partners that you know and trust.
  • Leveraging retention and uninstall data: By comparing the set of user traffic attracted by different media companies, brands can learn a lot about user quality. Low user retention or high uninstall rates increasingly are seen as signals of possible fraudulent activity.
  • Use ROI analytics as a primary KPI: When app publishers measure and optimize to ROI, you get both a true picture of the value of the user traffic that you are driving, and a powerful way to optimize your digital advertising investments.

Even a cursory review of this list reveals that seriously addressing ad fraud on your own, including click injection, requires a significant investment of time and money. That’s one of the reasons why companies look to their attribution and analytics providers to carry much of the water. Fortunately, Singular clients are protected from many of the costs and hassles of ad fraud with an unsurpassed set of fraud detection and prevention capabilities.

Singular and ad fraud

Singular offers an industry-leading fraud solutions that you can learn more about right here. For a capsule summary of some of the steps we take to detect and prevent ad fraud for our clients, read on.

With Singular, app publishers have visibility into ad performance, media investment, and revenue data. That provides unique advantages in detecting and protecting clients from fraud.

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

No IDFA? No problem. Continue to drive growth with Singular’s best-in-market SKAdNetwork solution. Click here to learn more!

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.

Update:

We’ve also had major news about Facebook and SKAdNetwork. Facebook has largely decided how it will be handling SKAdNetwork, and MMPs like Singular are a big part of it. Follow that link for the latest from on Facebook and SKAdNetwork.

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?”

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.

Update December 23: Facebook has now revealed its SKAdNetwork strategy and Singular CEO Gadi Eliashiv unpacked some of the implications. What we now know: AEO will be supported. Attribution windows, however, have been severely impacted, as you might expect. Get all the latest details here.

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.

More answers and more insights coming

It’s still early. It’s only a week after Apple’s World Wide Developers Conference. There’s going to be more to learn, possible changes to SKAdNetwork, and more information on how Singular is supporting our customers and helping them get through this massive change.

Keep checking our blog for updates, and please do join the Slack channel for Mobile Attribution Privacy (MAP).

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

  1. Click validation requires an almost-impossible level of adoption to to be effective across all channels.
  2. There are better tools to fight click injection/spamming, ad fraud, and fake users.
  3. 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.

mobile attribution fraud prevention
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:

  1. 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.
  2. 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.