Fraud, SKAdNetwork, and iOS 14.5: the definitive guide

For about three seconds when we got the details of how Apple is enabling privacy-safe advertising attribution via SKAdNetwork, we celebrated. Five seconds after that, we regained our sanity.

Why were we so excited initially?

Because the arrival of SKAN meant that Apple was inserting its mobile attribution framework into the iOS mobile user acquisition advertising ecosystem. In doing so, Apple was essentially taking a leading role in determining the validity of conversions. After all, if the platform owner told you an install happened, it happened. And if the platform owner’s technology told you which ad from what network caused that app install … that’s pretty definitive. Fake installs and app installs on emulated mobile devices living in server farms in the cloud seemed to be a thing of the past.

Well, the more things change, the more things stay the same.

Although all of that is true, there are still multiple vectors for fraud to enter the iOS advertising ecosystem even when governed by the SKAdNetwork framework for attributing ad views and app installs. We’ve talked about some of these before, but given that the state of the art is constantly changing — view-through attribution is now a thing in SKAN, just for one example — it’s worth updating again.

Potential sources of iOS app install fraud in SKAdNetwork

Let’s start by simply listing the potential sources of iOS app install fraud under the SKAN framework.

• Attribution manipulation
  • View-through spamming
  • StoreKit spam
• Postback manipulation
  • SKAN install notification replay fraud
  • SKAN conversion value fraud
• Fake installs
  • Fake new installs
  • Fake redownloads

Clearly, there are still a lot of sources of potential user acquisition and ad fraud in iOS 14, even with SKAdNetwork. There’s a lot of fraud that can happen, and there are entirely new ways fraudsters can perform it. One adtech executive looking at the landscape with a particularly active imagination says that “fraudsters are having wild raves and sharpening their knives right now.”

That’s probably a stretch. But let’s dive into each fraud source and sharpen our own knives, the fraud prevention tools.

Attribution manipulation in SKAdNetwork

Attribution manipulation and postback manipulation are probably the two biggest potential sources of fraud threats in iOS 14.5 and following under SKAdNetwork.

View-through spamming is going to be a significant source of concern. Clearly, it’s a great thing to have view-through attribution added to the SKAN framework just recently. However, it’s self-reported by a publisher. Apple has put in some guardrails here: the attribution window is just 24 hours, there’s a maximum of 15 attributions per publisher app — so fraud at scale is going to be harder — and view-through attributions get a lower priority than other SKAdNetwork touchpoints.

But.

A publisher app can “show” an ad that no-one can see. A publisher app can show an ad for less than the required three seconds. And a publisher app can try other potentially nefarious activities, as long as the fraudsters behind it manage their SKAdNetwork API calls properly.

The goal here isn’t to create a fake install. It’s simply to be set up to be credited as the instigator of an app install. That might be capturing an organic install, or stealing credit for an app install that a legitimate ad network has caused.

StoreKit spam is another attribution manipulation problem.

A StoreKit rendered ad is an app listing page that loads up inside a publisher app. You’ve probably most commonly run across them when playing a casual game and watching a rewarded ad to get JUST ONE MORE CHANCE at being completely awesome, crushing a level, and nuking the big boss.

This is a high-level high-value touchpoint in SKAdNetwork, and one that Apple rewards with a full 30-day attribution window and no maximum number of touchpoints per publisher apps. It’s also fully under control of the developers behind a publisher app and at least one version, accomplished via SKAdNetworks’ SKOverlay command can make it appear as well as disappear without user input. Plus it doesn’t take up the whole screen so it could happen quickly with minimal user disruption, and maybe even not fully visibly. Again, this isn’t about creating a fake install; it’s about falsely getting credit for a real app download.

Yikes.

So, what can be done?

Much of the technology that Singular’s built over the years to combat click spamming and other methods of fraud is relevant here. So reporting cases where the number of view-through attributions is much higher click-through attributions is one way to find suspicious actors. And seeing those with a much higher ratio than similar publishers is a good way to start.

There might also be campaigns or publishers where you don’t expect view-through attributions … perhaps in influencer marketing campaigns, for example, where there’s an explicit link provided for interested viewers, or perhaps from video networks.

In addition, because Singular has literally thousands of integrations with media sources, platforms, and networks, we can in many cases get view-through reporting from the network and correlate that with the number of SKAdNetwork-reported views.

“We would expect to see only a small percentage of views actually convert to VTA, if the ratio is too high than there are views that are not reported,” says Yonatan Komornik, Singular’s top fraud expert. “On the other hand, if many fake views are reported to Singular as well, then we can in turn look at CTR and CVR and notice that views are spammed.”

Setting automatic alerts in Singular enables marketers to monitor every ratio in their conversion funnels. That means you can quickly detect statistical anomalies and find outliers, but some of the spam might be able to slip through.

Singular enables marketers to analyze every ratio within the conversion funnel, using its unique ability to aggregate every data point. This enables marketers to easily build reports to detect statistical anomalies and find outliers, but some of this spam might be able to slip through.

Postback manipulation in SKAdNetwork

SKAN postbacks are sent out by Apple, which is a good thing. They’re also cryptographically signed by Apple. That is also a good thing, and it makes them hard if not impossible to forge.

However.

The conversion value part of an SKAdNetwork attribution postback is not signed. Which makes it fairly trivial for fraudsters to take a one-and-done D1 app-deleting user and make him or her look like someone with high engagement, good retention, and maybe even a purchase.

Instant upgrade, baby. At least for the fraudulent ad network.

In addition, country data and geolocation data isn’t included in the signed data. Fraudsters could manipulate the data to pass off installs from Uzbekistan as installs from the UK, for instance. They could even be real installs, just much cheaper to acquire.

Singular’s fighting this with a good old-fashioned 307 redirect integration with as many ad networks as possible. In other words, since in the SKAN framework Apple sends postbacks to ad networks — not advertisers — networks that are taking their SKAdNetwork integration with Singular to this level are simply implementing a HTTP 307 (temporary redirect) on postbacks. That essentially gives them the data while also reflecting it immediately to Singular as the measurement partner.

Some don’t, of course.

For these, Singular can leverage the data from app activity reported by our SDK and compare it with data reported for SKAN postbacks. Overall, the two should at least correlate, and anomaly analysis between the two can uncover potential fraud.

But 307s can also be faked, so Singular also has to check IP address distribution of the postbacks it gets via 307 redirects to ensure they match a realistic distribution of devices, as well as compare them with the data in the postback to ensure that the IP addresses match.

Another postback manipulation that SKAN fraudsters could try to implement is postback replay. In other words, re-send fully legit signed SKAdNetwork postbacks originally from Apple. SKAN postbacks aren’t timestamped by default, so this could work for unwary advertisers, or those who lack the ability to compare new postbacks with old ones.

Singular has implemented replay protection for customers, Komornik says.

Fake installs and bots in SKAdNetwork

Fake installs to fake users will be harder under SKAdNetwork because Apple is now in the attribution mix. For every fake install, fraudsters have to have a fake user to assign it to, and while you could probably assign low hundreds of app installs and reinstalls to a fake user, you wouldn’t be able to easily assign thousands or tens of thousands: it would be too easy to spot on Apple’s end.

(Assuming Apple is watching, of course.)

In addition, fake users need an Apple ID and an iCloud account to download apps from the App Store. Fraudsters who try to create thousands or tens of thousands of fake Apple IDs may find that Apple will shut them down fairly quickly. Apple, after all, knows how many iPhones and iPads it sells. It knows when people sell them or give them away and an Apple ID is deleted from the device while a new Apple ID gets associated with it. And, I’m guessing that since Apple is now at least partly in the business of helping advertisers attribute the result of their advertising, Apple’s going to pay a bit more attention to this than it has in the past.

So creating fake significant numbers of Apple IDs may not be a profitable pathway for iOS user acquisition fraudsters.

However, you can reset Apple IDs programmatically, and so you could potentially create fake new users for real iPhones, or multiple fake new users out of one legitimate one, and fake users for simulated iPhones. With all this fakery, you can also invent, fake, or remove the need to use a publisher app that the “ad” theoretically “runs” in.

So this is still a possible source of fraud that needs to be watched.

(Oh, and when you simulate a device, you should be able to send out an SKAdNetwork postback at any time you wish, rather than waiting for 24 hours to elapse. Because, after all, you control the universe the “app” and the SKAdNetwork framework that you’re manipulating live in.)

In addition, the technical challenges here don’t apply to redownloads.

If fraudsters have or acquire old and still-existing Apple IDs, they could likely re-attribute new downloads and installs of apps users previously had. These are fake installs to real users, but it’s probably not easy, and it’s probably not hugely scalable, so fake installs and bots will likely be less of a problem in iOS 14 under SKAdNetwork than we’ve had in the past.

Also, Singular’s methods for detecting fake installs still apply on iOS14. And, as in postback manipulation, we can match IP addresses between detected fake installs and SKAdNetwork postbacks to look for evidence of fraud

Oh and by the way, IDFA still exists

If that’s not all bad enough, IDFA still exists.

And while fraudsters have often in the past concealed their fraud by masquerading as Limit Ad Tracking – On devices, after iOS 14.5 they could potentially preferentially report IDFAs. Advertisers could get very excited, thinking consumers trust them, love them and are OK with them tracking for marketing purposes, only to find out that this traffic and these installs are a costly mirage.

So you still need an entire fraud suite for the way things were.

(Oh, and don’t forget the same level of fraud protection for devices that don’t upgrade to iOS 14.5. You’ll have to view old devices with a new level of suspicion now.)

And keep in mind: this is early days still

We’re still very early in the implementation of SKAdNetwork. Much of the framework is fairly new, and basically none of it has been stress-tested in the rapidly-changing inferno that is the global mobile advertising ecosystem.

There will be new attacks that we haven’t seen before.

There will be cracks that didn’t exist before.

And, like always, Singular will continue to monitor mobile app attribution data flow and adjust its fraud prevention solutions in near real-time, as well as develop new solutions.

Singular can help

Need help implementing SKAdNetwork or adapting your fraud prevention tactics and tools to the new reality of mobile marketing in iOS 14?

Get in touch, pick a slot, and let’s have a chat.