The launch of Apple’s iOS 14 in April of 2021 sent the entire mobile marketing landscape into a realignment process.

Suddenly,  a number of key elements were either removed or dramatically limited. User ID limitations, different measurement time frames, in addition to SKAdNetwork (SKAN) and its conversion values mechanism fundamentally changed the iOS landscape. 

In an industry that is used to seeing its fair share of changes, most key stakeholders were quick to respond and adapt to the new reality.

Some decided to put their focus elsewhere and reallocate their marketing budgets, leading to a 25% decrease in iOS budgets, while others decided to take the innovative approach and modify their work methods to fit the new reality.

New products and solutions were introduced to the market in an effort to solve the market’s measurement concerns, but one key question has yet to be answered.

What is the state of ad fraud in iOS since the launch of iOS 14?

To answer this question, let’s try and make sense of what’s going on.

A multidimensional landscape

Since the release of iOS 14 the vast majority of installs attributed in SKAN originated from direct traffic sources, with the absolute majority of traffic coming from either self reporting networks (SRNs) and SDK networks.

SRN traffic includes well established media channels like Google and Facebook (and others), where, historically, fraud rates have been significantly lower than the industry average and almost 0% in iOS specifically. 

Protect360 analyzes all traffic running through AppsFlyer’s ecosystem, regardless of its source, and SRNs are no different. However, their consistent maintenance of very low fraud rates over time, combined with the high level of communication and integration we have with such media partners puts them in the “safe traffic” category when it comes to mobile attribution fraud.

As for the rest of the sources active in SKAN, these can be segmented into two main types of media partners: SDK networks, accounting for 49% of SKAN traffic, and other sources that mainly include DSPs and ad networks. 

While the latter group with its relatively low volume of traffic seem to only be testing the new waters, the leading SDK networks in the market are more keen to adapt to the new SKAN reality. This is still a relatively small group of media companies that are also fully integrated with AppsFlyer and have historically presented relatively clean traffic with much lower fraud rates than average.

These two media partner groups are currently dominating the SKAN landscape, which allows us to consider Apple’s new SKAN environment as “fraud free” at this point in time. Keep in mind that the data presented above reflects the current media mix and may very well change down the line, making constant vigilance a must.

However, iOS activity is not just SKAN. There’s still plenty of activity that is not (strictly) reliant on SKAN. In fact, it’s currently responsible for the majority of iOS activity, as the following chart shows:

To better understand this, let’s explore how measurement can be broken down in iOS.

Get the latest marketing news and expert insights delivered to your inbox

iOS attribution measurement options

There are three types iOS attribution frameworks that are currently available for marketers:

1. SKAN only
   Mobile app campaign attribution that strictly relies on SKAN measurement. 
   
2. MMP only
   Attribution can be done either through ID matching for consented users (users who have allowed companies to share their IDFA), or through probabilistic modeling across all users.
   
3. Hybrid
   Attribution will be done through a combination of the two types described above. In this scenario, networks continue sending engagement data to their MMP even for SKAN activity.
   
   Example: when a publisher reports an ad view engagement by a certain user to SKAN, an impression URL will also be sent to the MMP

The hybrid model offers advertisers and media partners the benefit of leveraging  many of AppsFlyer’s measurement capabilities, while aligning with Apple’s privacy requirements. However, it also creates an issue of double measurement records.To solve this problem, we recently launched our Single Source of Truth (SSoT) solution. Whenever an install attribution is recorded by both AppsFlyer and SKAN, AppsFlyer will only record the attribution once by a unique process of deduplication. This presents our clients with reliable and accurate single truth reality of their activity.

Monitoring fraud in an era of limited data

AppsFlyer customers using Protect360 who also measure their iOS campaigns with probabilistic attribution (in hybrid or MMP only models), will continue to enjoy Protect360 fraud protection. 

At the moment, nearly all Protect360 anti-fraud models and detection logic can be applied to probabilistic attribution models. Anti-fraud logic has evolved dramatically over the years and no longer relies on user identifiers to detect fraudulent behavior patterns.

Advanced detection techniques like Bayesian networks give Protect360 the ability to base anti-fraud logic on large scale behavior patterns and apply detection logic onto a single occurrence regardless of specific identity. These advanced machine learning based techniques learn from past events and apply sophisticated logic for future detection with maximal accuracy.
User cluster behavior, biometric analysis, and large scale statistical models apply multiple measurement techniques that correlate with probabilistic attribution models, while aligning with very strict accuracy thresholds to ensure minimal false positive cases. 

Relying on AppsFlyer attribution also means advertisers have full transparency of engagement and install timestamp data. These not only play an important role in the fraud detection mechanism, but also provide greater value for advertisers since they can be leveraged for further analysis and optimization. 

It is vital to understand that common fraud protection methods are fully covered by Protect360 in the new iOS landscape, while relying solely on SKAN will leave you significantly exposed. These methods include:

• Click flooding: The two basic metrics required for click flooding detection are click volume and the time between click and install (CTIT). This fraud can be detected with the complete click data that’s available through MMP and hybrid attribution. 
  
  SKAN doesn’t currently provide advertisers with full engagement data, making click flooding impossible to detect.

• Click injection: Detection of click injection fraud is mainly done through anomaly analysis across click and install timestamps. These signals are only available when MMP attribution is involved, as SKAN does not report any attribution timestamp data.
  
• Fake installs: Faking the entire attribution cycle through emulators, bots, or device farms can only be detected through a comprehensive analysis of all available measurement points like timestamps.
  
  MMP attribution will ensure this data is reported and monitored by both the advertiser and Protect360.

Innovation powered vigilance

While the logic, models, and ability to detect fraud in the new iOS landscape are here, it’s imperative that all marketing parties take an active part in the reporting effort.

Advertisers and media partners should strive for an open and transparent relationship to make sure their best interests are kept, and fraud is eliminated from their relationship. 

It is highly recommended to have AppsFlyer’s probabilistic attribution a part of every advertiser’s campaigns when heading into SKAN campaigns. This will not only enable Protect360’s fraud protection (for Protect360 customers), but also open up additional measurement capabilities and insights available through AppsFlyer’s SSoT and other great products. 

Different SKAN fraud scenarios have long been identified and discussed by our team, with relevant technical fraud solutions to follow.

The Protect360 team, powered by AppsFlyer’s innovative solutions like SSoT, is keeping a close eye on iOS developments and the ecosystem at large, as we’re rapidly heading into a privacy-centric future. 

The post Everything you need to know about iOS 14+ fraud appeared first on AppsFlyer.

Let’s take a quick trip down memory lane to June 23rd, 2020, when Apple introduced the iOS 14 updates that would forever change the mobile app ecosystem. 

Everyone across the ecosystem began asking the same questions:

• Is SKAdNetwork going to be a good way to measure marketing efforts or not? (hint: both)
• What will the opt-in rates be for the App Tracking Transparency (ATT) pop-up? (hint: higher than expected)
• If most users won’t opt in anyway, why should I even bother showing the ATT pop-up? (hint: because this sample set of users will help answer many questions about the full set of users)

All of the above were totally legitimate questions of course, but over time it became evident that the most critical concern was actually:

How can I consolidate all of these siloed data sources into a single source of truth?

The reality of this new reality is that there are multiple realities. With the onset of iOS 14, marketers began receiving data streams from many different sources: SKAdNetwork, ATT-consented users, aggregate data from probabilistic modeling, incrementality-based insights, dedicated APIs for Apple Search Ads, and more… 

But which data stream is the actual truth here? How are marketers supposed to look at all of this incoming data and feel confident in the decisions they’re making? Good question.

We’re happy to say that we’ve got a solution for this critical problem. Before we get into it, let’s take a deeper look at the issue at hand.

The problem

For the sake of this analysis, let’s focus on the following 3 sets of attribution data:

1. SKAdNetwork: attribution performed by iOS, on the device itself
2. ATT-consented users: attribution based on ID matching
3. Non-consented users: attribution based on the Aggregated Advanced Privacy framework (for paid media) or probabilistic modeling (for owned media)

SKAdNetwork has two significant advantages over the others: it’s deterministic and covers all users. However, it also has major disadvantages: LTV measurement is limited (to say the least), it doesn’t cover all flows (mobile web, for instance), postbacks are delayed, and there are potential fraud loopholes, to name a few.

ID matching, aggregated advanced privacy, and probabilistic modeling on the other hand have their own advantages, but also their own set of disadvantages.

Suggested solution: Choose the preferred model based on the specific need. 

Why it won’t work: In theory: problem solved. In reality…this isn’t possible. As SKAdNetwork data is anonymized, no entity can know if the same conversions were attributed by other models or not. And the same goes in reverse.

Potentially, each install could be:

• Attributed only by SKAdNetwork
• Attributed only by other attribution modes
• Attributed by both
• Attributed by none

This is the very essence of SKAdNetwork: anonymization. By design, it prevents reverse-engineering for user-level matching thanks to features such as randomized delays in firing the postback. 

In reality, however, advertisers were faced with two parallel realities.

Most solutions for the new iOS 14 era currently look like this:

Multiple APIs and dashboards make it nearly impossible for advertisers to reach actionable insights. The only solution is a consolidated dashboard or API where the data is combined, deduplicated, and unified, all while preserving user privacy and aligning with Apple’s policies. However, as explained above – this is was not possible.

Get the latest marketing news and expert insights delivered to your inbox

Problem solved

SKAdNetwork has limitations, and many of them can be overcome by innovating on top of the protocol’s conversion values. This case is not different. 

Conversion values are the only way for iOS advertisers to measure user LTV in SKAN campaigns. By properly mapping out those 64 possible values, advertisers can measure post-install revenue, activity, and retention. 

Our recent release of the AppsFlyer Conversion Studio provides our customers with a hyper-flexible configuration environment, where each value can be maximized and fully accounted for in the mapping.

While conversion values do limit the advertiser’s ability to measure LTV (both in time and range), they do offer up a solution for deduplication.

Let me walk you through it:

1. When a user launches a newly-downloaded app for the first time, AppsFlyer attempts to attribute the install. 

2. Assuming AppsFlyer can attribute the install, a single bit from the SKAN conversion value is utilized to indicate a “found attribution” flag in the conversion value via the updateConversionValue call.

3. If a SKAN postback is received by AppsFlyer later on, AppsFlyer aggregates the single-source-of-truth data according to this equation:
   AppsFlyer attributed users + SKAN postbacks for which the ‘found attribution’ flag is false. 

Critical milestones on the path to a single source of truth

In order for this to work, there is one important step in the process: advertisers must dedicate part of their conversion value to deduplication. This choice must be one that the advertiser can control and have the flexibility to turn on or off as they choose.
In the newly-released Conversion Studio, where advertisers can easily configure multi-metric conversion value mappings, we’re adding this very option.

When toggled on, this setting will consolidate, deduplicate, and unify reported data in aggregate reports.

But wait, doesn’t it breach end user privacy?

Absolutely not. Data remains completely anonymized; thresholds, timers, and delays still ensure that no one can attain user-level granularity. All SKAdNetwork defense layers are still in place to ensure that end-user privacy is not harmed even a bit. 

The bottom line remains fully aggregate with no means to de-anonymize the data. It just helps to deduplicate the aggregate realities and reach a purely aggregative single source of truth. 

Let’s summarize real quick:

The pros

Siloed data points → Single source of Truth

The formula is simple:

Parallel realities → hard to make decisions

Single source of truth → actionable marketing insights

Maximize the advantages of each model

Once advertisers can deduplicate data from both aggregate models, they can enjoy benefits of each one, for example:

• Full LTV based on traditional attribution models
• Full coverage and deterministic data points from SKAdNetwork

Maximizing these advantages will help marketers make better decisions, even in an iOS 14+ reality.

No compromise on end users’ privacy

The SKAdNetwork privacy framework is in place and untouched.

SKAdNetwork campaign optimization remains the same

The fact that SKAdNetwork postbacks are sent for all users, whether they were also attributed in parallel modes or not, ensures that networks can continue optimizing based on SKAN conversion values.

The cons

6 bits of conversion value → 5 bits of conversion value

As mentioned, one bit will be allocated to indicate whether or not the current install was also attributed in a parallel attribution mode. To allow this, the precious resource of conversion values will become a bit more limited (pun intended).

Some of our biggest customers took part as design partners in planning this solution, and they were more than willing to allocate a single bit for the promise of a single source of truth. Having said that, this is still a decision that needs to be made by the advertiser.

Final words

As the industry continues to acclimate to the new era, it is critical that data accuracy and user privacy continue to coexist. At AppsFlyer, it is our mission to empower advertisers as they go through these changes.

Having 100% certainty in the true results of your marketing efforts is mission-critical. A single source of truth for marketing performance ensures that marketers optimize their ad spend, grow their business, and supply superior experience to the end users.

The post Attribution in iOS 14+: From silos to a single source of truth appeared first on AppsFlyer.

What’s inside

iOS 14 and SKAdNetwork have introduced challenges that have never been tackled by Gaming app marketers before. 

As a result, they’ve had to rethink how to measure, attribute, and optimize their campaigns in the age of privacy.

To help Gaming apps understand how to navigate this new reality, we held in-depth interviews with three leading experts from top studios: CrazyLabs, Pixel Federation, and Product Madness.

In this guide we address the main challenges for Gaming apps in iOS 14 and how the featured  studios are confronting them, including: 

• The prompt and pre-prompt – what techniques worked for increasing opt-in rates
• Conversion value optimization – how to split the bits and what insights you can gain 
• The SKAN timer – whether to delay or extend and which early events help to predict LTV and ROAS
• And much more!

The post A whole new ballgame: Gaming app marketing in iOS 14+ and SKAN appeared first on AppsFlyer.

The post The impact of iOS 14 & ATT on the mobile app economy appeared first on AppsFlyer.

• Updated after iOS 14 release
• The App Clip Invocation flow
• Invocations and Experiences for Apple App Clips
• App Clip Experiences
• Developing an App Clip
• App Clip limitations
• Testing iOS14 App Clips
• Conclusion – The here-and-now is here

Introduction

Updated after iOS 14 release

With the release of iOS 14, we view App Clips as an innovative step by Apple.

At AppsFlyer we see Apple App Clips as the future and evolution of apps, especially for apps that you do not use on a daily basis. We’ve put together this comprehensive guide to assist you in developing your first App Clip.  

Why App Clips? Why now?

Let’s imagine for a moment that you walk into a coffee shop and notice that there is a long line.

Next to the cash register, you see a sign inviting you to skip the line and purchase your coffee via the coffee shop’s app.

Any first thoughts?

Let me tell you, mine would be, “No way am I going to install an app that will take up precious real-estate on my device.”

It would then lead me to question what kind of data they will collect about my life and then I will probably be spammed.

No thanks. And all this just to skip the line…

Skip the line without giving up on privacy

Apple App Clips are about to change the way you think, and; moreover, they will probably change the way that we interact with our environment using our mobile devices. iOS14 App Clips enable you to do ‘here-and-now’ activities using your device almost instantly without sacrificing privacy or sharing your geolocation.

In the coffee shop example above, the QR code will invoke an App Clip where you are identified by using Apple Sign-in and can purchase using Apple Pay, allowing you to complete your purchase within seconds, effectively skipping the line.

App Clips requires app developers to understand a few new concepts and develop the App Clip alongside their app, which may require some refactoring.

Important: This blog is based on the actual development of an App Clip that was thoroughly researched with careful documentation, and video, collecting all App Clips related WWDC 2020 videos, with iOS 14 release notes, post-release experience. See the full app and paired App Clip here.

Chapter 1

The App Clip Invocation flow

This section will cover the App Clip life cycle – from a user who interacts with an App Clip to the various methods of switching to the full app.

App Clips starts when a user interacts with an Invocation. 

Invocations are a very important notion in App Clips which we’ll go into full detail.

Let’s assume the user tagged an NFC tag, which is an App Clip Invocation.

This is what follows:

1. The iOS system detects that the NFC tag is an App Clip Invocation and extracts an ‘Invocation URL’.
   
   The Invocation URL defines the functionality expected from this Invocation. It will be passed to the App Clip together with all the data needed to point the user to the functionality required to service the NFC tag. If the app is already installed, the app will be launched and the Invocation URL will be passed along just as it’s passed in a Universal Link flow.
   
   Important notice for developers: The invocation URL is not passed to the full app if the user chooses to install the full app from the App Clip Card or from the App Clip banners. In these types of cases, the user must trigger the invocation again (scan the QR code or tap the NFC tag). The invocation URL will then be passed in NSUserActivity as described above.
   
   The developer can pass the invocation URL from the App Clip to the full app using shared storage.
   
   Here are a few examples:
   1. https://megacoffee.com/buy/paris/table/6 – The App Clip is opened in the buy menu of the Paris branch where table #6 is already set-in the preferences. The user identifies via Apple Sign-in, pays using Apple Pay, and voilà, the order is complete. This flow requires location verification, explained in full detail here. 
      
   2. https://scooter.me/rent?scooter_id=3456 – The App Clip is opened in the rent menu with a scooter ID already set-in place. The App Clip can notify the user that their rent period is about to end. This flow requires an App Clip notification, explained in full detail here. 
      
2. The iOS verifies the Invocation URL which is indeed valid, by reading an Apple-App-Site-Association (AASA) file from the Invocation URL domain. Setting the AASA file is explained in full detail here. 
   
3. Once the Invocation URL is verified, the iOS presents an App Clip Card to the user.
   
   While any given app can only have one App Clip, developers can create several cards for different experience use cases.

Each App Clip Card is associated with a single App Clip Experience (App Clip experiences are explained in full detail in Chapter 5).

The iOS system displays the App Clip Card of the Experience which is the closest match to the Invocation URL that the user has clicked.

The App Clip Card is then presented by the system, without any developer interaction or code involved.

The App Clip Card serves a few purposes:

1. It presents the user with a general introduction as to the functionalities of the App Clip, which is similar to the App Store app page on a full app download flow. This could be presented as a picture of the coffee shop with a short description of the business.
2. It states permissions from the developer and enables the user the option to turn them off. Please note, that iOS14 App Clips have very few permissions and contain a very small list. As an added bonus, users will gain confidence with App Clip’s stronger privacy policy.
3. It presents a call-to-action button, which informs the user of the main functionalities expected from the App Clip, such as: to rent, buy, share, or check-in, etc.
4. It places a small banner which directs the user to the full version of the app in the App Store.

When the card’s call-to-action is clicked, the iOS downloads the App Clip from the App Store. This is done quickly as the maximum size of an App Clip is 10MB.

For reference, this is quite a decent size as recently-submitted apps have an average size of 38MB.

The Invocation URL is passed to the App Clip via NSUserActivity. The developer uses the URL to create a deep link to the specified functionalities. The developer can use parameters from the URL, for example, the developer may extract the branch name and table number from the URL in this example: https://megacoffee.com/buy/paris/table/.

When the App Clip initially uploads it will display a banner that directs the user to the full app in the App Store. The developer can display the banner again using SKOverlay which is described in full detail here.

Chapter 2

Invocations and Experiences for Apple App Clips

This section describes in detail how an App Clip is invoked, which App Clip Card is displayed, what data is passed into the App Clip, and how.

An App Clip is generated from an Invocation.

An Invocation is not just a click, as you are probably familiar with from Universal Links.

An Invocation is an object created by Apple, which currently only Apple tools or infrastructure can create for you. It remains unclear on how you attain an ‘App Clip URL’ which would allow you to simply send via SMS, or place behind a QR code (we will update this process as soon as Apple provides more clarity).

Invocation methods

Safari Smart App Banner

Metadata can be added to the header of a website in order to create a Smart App Banner that will be presented in Safari.

Here is a sample code snippet that you are required to add:

The app-id is included in cases where the device is running on iOS 13 or earlier.

At this time the banner will direct the user to the full app within the App Store.

For this click, the URL that presents the banner is the Invocation URL.

iMessages 

When a user shares a link to a site that displays a smart banner, the message will present a banner that will invoke an App Clip.

The Invocation URL, in this case, is configured in the site’s URL.

NFC tag 

• A tap on a tag, which encodes an Invocation URL associated with an App Clip, will invoke the App Clip. 
• An Invocation URL is configured inside the tag.
• The NFC tag can be created using any tool or infrastructure, capable of creating NFC tags readable by Apple devices.
• The tag can be read even when the screen is locked.

Get the latest marketing news and expert insights delivered to your inbox

Visual codes

• App Clips can be invoked using any QR code, which encodes an Invocation URL associated with an App Clip.
• In order to invoke the App Clip, the QR code must be scanned using the Camera app or Apple’s native Barcode reader.
• Apple plans to release a visually distinct code that will host both an NFC tag in the middle, surrounded by a circular scannable code. One of Apple’s goals is to familiarise iOS users that when you tap or scan this code it will direct you to an App Clip. 

Locations

Location-based suggestions from Siri – Apple has yet to share the full disclosure (updates to come).

Maps 

Tags on a map may include a tag that invokes an App Clip. Verifying the App Clip’s Invocation URL is described in full detail here.

Every App Clip Invocation is associated with an Invocation URL.

The URL always starts with `https://mygreatapp.com/`. `https` is the scheme and `mygreatapp.com` is the host or domain. 

iOS must verify the Invocation URL to ensure that the publisher of the App Clip indeed owns the domain. If not, the user is most likely vulnerable to fraud and other malicious acts. 

Since the scheme is ‘https`(as opposed to ‘http’), the Invocation URL will be verified using the SSL certificate, ensuring the App Clip developer owns the domain.

iOS verifies the domain by accessing an Apple-App-Site-Association (AASA) file. This file is usually known for verifying Universal Links for a given domain.

In order to verify iOS14 App Clips you must add the following section to the AASA file:

{
“appclips”: {
“apps”: [“ABCED12345.com.fruitstore.feedmeapp.Clip”]
}
…
}

Important note about AASA files: Apple announced at WWDC2020 that they intend to improve the access mechanisms of the AASA files from devices. Instead of the devices fetching the AASA directly from the domain associated with a given app, Apple fetches the AASA files and caches them in a CDN. The devices will access Apple’s CDN, and aggregate the AASA files fetching into more optimal reads and operations. 

As a result, App Clips may increase the number of AASA file fetches, and this proposed mechanism could aid in decreasing this.

The state of this cache in relation to the Invocation URLs defined for a specific App Clip can be found in App Store Connect version information under ‘Domain URL Status’.

The build must have a valid App Clip (‘HAS APP CLIP’ value is ‘YES’).  

The cache status column is what drives App Clip Invocation on the customers’ devices. Clicking ‘Debug Status’ enables Apple with access to your AASA file in real-time and validates the URLs. The Domain URL status is displayed above. 

Chapter 3

App Clip Experiences

The most important term to understand about Apple App Clips is probably its Experiences.

An App Clip Experience is an action offered to the user, for example, buying, renting, checking into a hotel, and the list goes on. Each Experience displays a different App Clip Card. If you’d like to display a specific App Clip Card, you must define a specific Experience.

So, how is an Invocation matched to an Experience, and how does this display the relevant App Clip Card?

As we learned above each Invocation carries an Invocation URL. iOS matches the Invocation URL against URLs that you registered as a part of your App Clip Experience. It will display the App Clip Experience together with the URL that has the specified matching prefix. 

For example, creating an App Clip experience with https://myrental.com/rent as the URL to cover URLs like https://myrental.com/rent/car, https://myrental.com/rent/suv, and so on and so forth.  

However, if a business has multiple operations, it is recommended that you configure App Clip Experience for one or more operations, and use a different App Clip Card and Invocation URL for each operation.

For example, https://myrental.com/rent/car/il, https://myrental.com/rent/car/jp, etc.

Default App Clip Experience

In App Store Connect, on the page, ‘new app version’, you must configure a default App Clip Experience and provide the following metadata for the App Clip card:

• A header image.
• A subtitle that provides more information about the App Clip.
• A call-to-action that appears on the button users will tap to launch the App Clip.

A default App Clip Experience is used to fire an App Clip from Smart App Banners and links that users share in the Messages app when Advanced App Clip Experiences are not configured.

No Invocation URL is required to register a default App Clip Experience.

If the system verifies an App Clip it will show the default, even if no Invocation URL was defined (see next section). Again, this is true only for Smart App Banner in Safari or links shared for these sites in the Messages.

Advanced App Clip Experience

Advanced App Clip Experiences allows you to do the following:

• Support all possible Invocations, including Invocations from NFC tags, and visual codes.
• Associate your App Clip with a physical location.
• Associate an Invocation URL with your App Clip.

As previously described, this enables the use of several App Clips Cards for various business cases. Each experience will lead to a specific card, customized in the App Store when creating the App Clip Experience.

Chapter 4

Developing an App Clip

To easily experience Apple App Clips we have created a simplified sample app that demonstrates the usage of App Clips and its integration with a full application. 

The sample shows the following App Clip features:

• App Clip creation.
• Configured Associated Domains Entitlements for both iOS14 App Clips and Universal Links in the full app.
• Sharing resources between the full app and App Clip.
• Extracting the Invocation URL from NSUserActivity in both the full app and App Clip.
• Notifications.
• Passing data from the App Clip to the full app using App group.
• Verifying location.
• Recommending the full app from the App Clip using SKOverlay.

Chapter 5

App Clip limitations

Apple has imposed several limitations on App Clips to allow users to enjoy instantaneous functionality with maximum privacy and transparency. 

These limitations serve to provide the user with greater control over their privacy and become more confident with the privacy standards of the app:

• App Clips are limited to 10MB in size.
• App Clips are not included in iOS backups (this is actually more of a feature than a limitation).
• The following frameworks are not available to App Clips: CallKit, CareKit, CloudKit, HealthKit, HomeKit, ResearchKit, SensorKit, and Speech. Using any of these frameworks in an App Clip does not result in compile-time errors, but their APIs return values that indicate unavailability, empty data, or error codes at runtime.
• Limit App Tracking is always enabled in Apple App Clips, to protect user privacy and prevent user tracking across apps and App Clips. App Clips cannot request authorization to track a user with AppTrackingTransparency, and both name and IdentifierForAdvertisers (IDFA) and IdentifierForVendor (IDFV) return all-zeros string.
• App clips cannot perform background activity, such as background networking with URLSession or maintain Bluetooth connections when the App Clip is not in use.
• To protect user data, Apple App Clips cannot access:
  • Motion and fitness data.
  • Apple Music and Media.
  • Data from apps like Contacts, Files, Messages, Reminders, and Photos.
• An App Clip cannot share data with any other app, except its corresponding full app.
• An Important limitation is location access. App Clips cannot request continuous location access. This may create an issue with Invocations that are associated with a geographical location. It is important to verify that the Invocation URL (e.g. https://mybigcup/seattle/table/17) is indeed in Seattle, so as to avoid the confusion of the user paying someone else’s bill. For this purpose, Apple App Clips allow users to verify the device location inside a polygon, instead of accessing an exact location. However, for continuous location access, they may request the <When In Use> authorization, which resets automatically to the next day at 4:00 AM local time.

Chapter 6

Testing iOS14 App Clips

Apple App Clips can be tricky to test, as the Invocation flow begins within the system and involves App Store Connect. Thus, when initially creating the App Clip, you will need to rely on the following measures to test the invocation:

Testing the processing of the Invocation URL 

A critical step in testing an App Clip is to ensure that the incoming Invocation URL is: 

1. Extracted successfully from the NSUserActivity.
2. Parsed correctly with its parameters.
3. Runs the appropriate flow.

Injecting an Invocation URL into a test, the steps are as follows:

1. Click Product -> Edit Scheme…
2. Set the Environment variable _XCAppClipURL to the Invocation URL value.
3. Run the App Clip scheme on the target. The NSUserActivity will hold this value.

To view an example of this code click here.

Get the latest marketing news and expert insights delivered to your inbox

Testing appearance of an App Clip Card using Local Experiences 

The appearance of an App Clip Card is an important part of user interaction. This is tested at the early stages, prior to submitting the application to App Store Connect and before setting the Apple-App-Site-Association file in your domain. 

Setting Local Experiences is equivalent to setting Advanced Experiences in App Store Connect. 

Local Experiences limitations:

• It is possible to invoke the App Clip Card using two methods:
  • QR code (read using the native iOS Barcode reader)
  • NFC tag
• Supported from iOS 14.2 combined with Xcode 12.2 and above.
• Local Experiences override the Advanced Experiences in App Store Connect.
• Local Experiences can only launch an app that is signed for Development, Ad Hoc, or TestFlight. It cannot launch an App that is already published to App Store Connect.   

How to set Local Experiences:

1. Ensure that your device is enabled to developer mode.
2. Connect your iOS 14.2 and above device to Xcode 12.2 and above using a cable.
3. Go to Local Experiences – Settings -> Developer -> Local Experiences (under ‘APP CLIPS TESTING’ section).
4. Create a new experience by choosing `Register Local Experience…`
5. Create the Experience as you would create an Advanced App Clip Experience within App Store Connect.

How to invoke using Local Experiences:

1. Add an App Clip to your device using the following methods:
   1. Build and run the App Clip using Xcode.
   2. Create an ipa file for the App Clip using the Archive functionality in Xcode, and install it on the device.
   3. Distribute the App Clip to users via TestFlight.
2. Scan a QR code using the native iOS barcode reader or tag an NFC. The QR code and NFC must encode an Invocation URL which overlaps with the URL defined in the Local Experience. This corresponds to the same overlapping rules of Advanced Experiences in App Store Connect.

Testing after submission to App Store Connect

When submitting the full app and App Clip to the App Store you can define App Clip Invocations in the TestFlight tab. Each Invocation is defined with its Invocation URL. 

The app’s beta testers recognize the Invocations in the TestFlight and run the App Clip as if an Invocation was clicked using the Invocation URL as defined in the previous stage.

Chapter 7

Conclusion – The here-and-now is here

App Clips represent a new stage in how applications will be consumed and developed while providing iOS users with greater instantaneous functionality. This enables designers and developers greater freedom. 

App Clips user experience can be categorized into two phases:

• ‘Here-and-Now’ – An App Clip for interactions between the user and their immediate environment, carried out in a simple but highly secure way.
• ‘On-Going-Universal’ – A full app that allows the user to constantly engage with the app’s functionality and receive notifications and services globally. 

Apple did an excellent job in creating the infrastructure for these two phases, and for designing a seamless transformation between the App Clip to the full app phases. 

We believe that many businesses can, and should, leverage this new technology to provide their customers and users with greater value and better interactions. We compiled this comprehensive guide to assist you in extending your knowledge about Apple App Clips.

For more information please visit Apple App Clips documentation.

The post Apple’s iOS 14 App Clips: A definitive guide for developers by AppsFlyer appeared first on AppsFlyer.

What’s inside

Privacy has taken center stage in mobile app marketing and iOS 14 in particular – dramatically impacting measurement technology, remarketing, UX, and overall made it much harder for brands to monetize on iOS.

To help make sense of it all, this guide provides industry pro tips, tricks, and strategies that will help you navigate through the iOS 14 terrain, and gain a bold new competitive advantage for your business.

Highlights include:

• An overview of the changes introduced with iOS 14 and the impact on measurement technologies 
• An in depth look at SKAdNetwork’s timer mechanism and how to overcome the timer challenge
• Different strategies for splitting your 6-bits and making conversion values work for you
• Tactics that will help you optimize IDFA opt-in rates
• AppsFlyer’s suite of solutions for iOS 14

The post App monetization strategies for iOS 14: The complete guide appeared first on AppsFlyer.

Within the general feeling of confusion and uncertainty surrounding SKAdNetwork, one question remains unanswered – is there a risk of attribution fraud with Apple’s new attribution protocol?

Apple has introduced several anti-fraud mechanisms that are meant to obstruct different types of attribution manipulations. All transactions that are tied to an SKAdNetwork event are cryptographically signed and verified by Apple in order to prove that the postback is attached to a known conversion event by Apple.

The postback includes a unique transaction ID (a unique identifier for a transaction, such as a purchase or re-download) in order to detect replays of valid conversion events.

The mechanisms above are meant to validate the postback’s authenticity, but neglect to address the user’s interaction authenticity (impression or click).

Can these mechanisms be bypassed? And can fraudsters find creative ways to work around these limitations while being unnoticed?

To answer the above, let’s break down the possible attribution fraud scenarios in SKAdNetwork:

1. Manipulating a postback before it reaches the advertiser: The signature and transaction ID mentioned above are meant to treat such cases. However, both the signature and transaction ID can be bypassed. For example, the conversion value is not part of the signature, and the transaction ID can be used repeatedly (hoping that whoever’s on the other side doesn’t store all historical transaction IDs forever). The only real solution for this is sending the postback to its real owner – the advertiser.
2. Manipulating Apple with a wrong attribution decision at the device level: The examples discussed throughout will illustrate such cases.

We can say for certain that SKAdNetwork attribution protocol provides limited data for either measurement or optimization, offering only source app and campaign ID. 

Device interaction time indications are also unavailable. These are critical for measuring time frames between key events – mainly click time and install time. Without these indications, normal user behavioral trends (very difficult to emulate at scale with bots) can’t be constructed – eliminating indication of abnormal behavior. 

But, as we try to identify potential loopholes that might be exploited for fraud, we approached the issue from another direction.

Imitating potential fraudulent behavior can help us construct the fraudster’s manipulation path, and in-turn allow us to analyze and identify potential weaknesses as we try to protect our advertisers from such fraud.

Fake install farming

Anyone with one or more devices can click, download, engage with apps, and reset their device ID to make it seem as though it is a different device. This, in a nutshell, is a device farm. Once a VPN solution is introduced the fraudster’s IP address can also be altered or hidden. 

Can this be carried out with SKAdNetwork?

The short answer is yes.

SKAdNetwork may have eliminated the use of IDFA but a user’s Apple account ID is still used for measurement purposes.  

Resetting the Apple account ID is something that can be done programmatically through various tools and services, thus generating multiple fake users from one device is very possible.

Moreover, when using a jailbroken device you also eliminate the need of using a publisher app, as you can generate fake clicks without one.  

The SK protocol logs all clicks in an internal device database. With the right technical knowledge, bad actors can easily create a fake app-like environment which connects to the ad-network’s server to attain its unique signature and campaign details. 

This fake app environment can then insert the click details into SK’s database – leaving iOS tricked into thinking that the click was delivered by a real app.

Jailbroken devices also give fraudsters the ability to programmatically control the SK timer through this fake app environment, meaning postbacks can be sent within 20 or 30 seconds, rather than the expected 24 hour window.

Since this timer manipulation occurs on the device, at which there’s no device time data to work with, the advertiser cannot tell whether timing was tampered with. 

The above manipulations explain that device farms can operate at scale without any ongoing human interaction.

Flooding the gates

Click flooding is meant to “flood” the advertiser with a wave of fake click reports, in the hopes that one of these clicks will be somehow associated to either an organic install (when a user downloads the app on their own), or a non-organic install (a click that is artificially injected after the user has viewed an ad from another publisher).

SKAdNetwork attributes credit for installs that occurred through the Apple App Store. When a user views an ad on a publisher’s app and clicks it, the app’s in-app store page will appear within the publisher’s app.

This App Store page view is registered as a click by the SK protocol.

Once the user downloads the app from the App store page and launches it, the install will be attributed to the publisher’s app.

How can this flow be manipulated?

Our tests show that publishers can simply trigger the advertiser’s App Store page to appear without a user’s ad click, thus creating a fake click report.

The app store page can be triggered repeatedly without a single ad click, creating a similar effect to click flooding. This is very similar to common manipulations where ad impressions are falsely reported as clicks.

How is this affected by Apple’s recent view-through addition?

With Apple’s latest addition of view-through to the SK protocol, flooding might even become easier. A click-through flow can theoretically be validated by Apple by checking the entire flow (click→ App Store → Install).

However, with view-through attribution, as we eliminate the click from the equation, this flow validation cannot occur. Anyone can theoretically claim to deliver impressions, hoping for installs to be attributed.

With SKAdNetwork, publishers can determine an impression’s start and end times. While Apple’s official statement says that this time frame should be over 3 seconds, It is not enforced in any way. This means publishers are free to generate fake impression reports, generate an impression flood, taking advantage of view-through flows.

An even simpler way to take advantage of view-through attribution is using the device database access mentioned above to insert false impression reports – making sure the publisher is always the one to provide the last impression.

This opens the possibility of creating either click flooding or impression flooding, by programmatically triggering click or impression reports. 

While the App Store page pop up is hoping to initiate an actual install from the user who sees the page, all other manipulations simply hope to steal the credit for an organic install that had nothing to do with any exposure to an ad or app page.

Our tests show that even installs that take place up to 24 hours post click-report receive attribution credit from SKAdNetwork. Apple’s official documentation actually discusses a 30-day lookback window, increasing the likelihood of such a scheme to be successful.

Malicious source apps like the ones described above can still be identified and treated by Protect360 (AppsFlyer’s fraud protection solution) using different detection methods. The behavior outlined above will still deviate from standard behavioral trends when viewed on a large enough database scale, even within the aggregate nature of SKAdNetwork.

Get the latest marketing news and expert insights delivered to your inbox

We’re just getting started

As we enter a new era of attribution measurement, we’re very likely just scratching the surface in terms of possible fraud methods and manipulations.

AppsFlyer is working in cooperation with Apple and the ecosystem at large to raise these issues when they occur, as we work hard to maintain a fraud-free environment in this new era of attribution.

As fraud researchers, it’s now our job to continue diving deeper into possible areas of weakness and identify how they might be exploited, so that we continue to adapt and protect our customers.

Stay tuned for more developments.

The post Immediate fraud risks within iOS 14 and SKAdNetwork appeared first on AppsFlyer.

What’s inside

The Mobile Marketing Association and AppsFlyer surveyed marketers about the implication of Apple’s privacy related updates to their business outcomes.

Key findings include:

• Marketers have varying degrees of familiarity with Apple’s new protocols for measurement that will be implemented with iOS 14 (IDFA). Thirty-seven percent have little to no understanding of the new protocol.
• The majority of marketers expect a negative impact of these changes on their capabilities. They expect to lose around 50% of identifiers under the new opt-in protocol with targeting, measurement and attribution the most challenged.
• Many marketers are not sure how to approach the upcoming changes, especially when it comes to adopting Apple’s SKadNetwork and are also not sure if their mobile attribution providers can tackle the new challenges.

The post Learn how leading mobile marketers prepare for iOS 14 appeared first on AppsFlyer.

On September 16th of this year, the highly-anticipated iOS 14 was widely-released to the public.

While the industry knew this version was due to come out sometime in September, Apple gave developers less than 24 hours’ notice about the public release date.

Unlike previous years, this year the new iOS was released ahead of the new iPhone models and not simultaneously. As one might expect, this slowed the adoption rate of the new iOS (as the new devices are sold with the new iOS installed). According to our data, iOS 14 surpassed 46% adoption just last week, and this rate is expected to rise dramatically when the new iPhone 12 becomes widely available in November.

Apple announced an abundance of new privacy features when iOS 14 was introduced in June, most notably the new App Tracking Transparency (ATT) framework that was expected to all but diminish IDFA collection.

While the release of this feature was postponed to early 2021, giving developers more time to prepare, a curious phenomenon has occurred: since the public release of iOS 14, the industry has noted a massive surge in iOS devices with zeroed IDFA.

Zeroed IDFAs were introduced with iOS 10 back in 2016, and are the result of the user opting out of ad tracking. Prior to the release of iOS 14, the average worldwide rate of devices with Limit Ad Tracking enabled was around 24%; the US and Europe had the highest prevalence of LAT devices (30% and 18.3%, respectively).

Since the release, the numbers of zeroed-IDFA devices have skyrocketed, and now stand at an astonishing 45% of all iOS 14 devices worldwide.

The aforementioned ATT was designed to replace LAT. Rather than offering iOS users the opportunity to opt-out of sharing their IDFA with advertisers in their device settings, the new AppTrackingTransparency framework (ATT) requires users to actively opt-in to IDFA collection when using the app.

Users that had turned on LAT previously would automatically be converted to ATT-negative users, maintaining their status of sending a zeroed IDFA to advertisers. For this reason, we expected the prevalence of zeroed IDFA devices to stay constant.
Clearly, this is not the case.

So what is happening? And why?

The four horsemen of the IDFA apocalypse

The surge in zeroed-IDFA devices post-iOS 14 release became immediately apparent, causing much confusion and frustration in the industry. After some research and investigation, we have uncovered the cause.

The shift from LAT to ATT didn’t turn out to be a binary “opt-in/opt-out” scenario, as we anticipated it to be.

In reality, the new iOS 14 user has four possible states of existence:

1. Not Determined – No ATT dialog was presented to the user, therefore the user made no active choice about sharing their IDFA. This status also includes user devices where LAT was turned on in earlier iOS versions. (IDFA shared/not shared accordingly)
2. Denied – The user chose via ATT to not be tracked by the app (IDFA not shared)
3. Allowed – The user chose via ATT to allow tracking (IDFA shared)
4. Restricted – Access to IDFA sharing is blocked without any end-user input (IDFA not shared).

Due to the delay in deployment of the ATT framework, we expected that most users would fall under the Not Determined status.

We expected roughly 75% of devices to be Not Determined after the public release of iOS 14. In reality, only 62% of devices are now in Not Determined status.

Surprisingly, the sum of Denied and Allowed is around 20%.

While Apple postponed the implementation requirement for ATT to early 2021, some developers went ahead and integrated it in their iOS 14 apps anyway. The ATT framework prompts the user to opt-in to allow tracking when they use the updated app. Unsurprisingly, when prompted, the majority of users (99%) choose not to allow tracking. 

The big surprise in these results, however, is the 18% of devices that fall under the Restricted category. These devices send zeroed IDFAs, without the users having made any proactive choice about sharing it whatsoever.

Restricted status: Explained

Let’s address the elephant in the room: why are we seeing an 87.5% increase in zeroed IDFA devices in iOS 14?
The answer lies in the Restricted devices category. This vaguely-defined category creates complexities for the industry, bringing on scenarios that weren’t foreseen. 

First, let’s define what Restricted means here.

A Restricted device will report similarly to a LAT-enabled device: the IDFA will be zeroed across all apps.

Users with Restricted devices have reported that the LAT privacy setting (“Allow Apps to Request to Track”) on their devices is grayed out, meaning they cannot change this setting on their own.

What’s more, this setting appears to be open to some manipulation and prone to bugs. Savvy iOS users have reported that they’ve been able to “ungray” the setting, by logging out and back into their iCloud account.

Why would a user be restricted in the first place?

This is a good question, with no official answer to be found. There are some assumptions and partial answers from Apple.

We have collected what we know so far:

1. User age
   1. The user is under the age of 13, or between the ages of 13-18
   2. The user’s age is unknown
2. Education
   1. The device is in Education mode
   2. The App Store account was created by an educational institution (known as Managed Apple ID)
3. Restricted profile
   The device has a profile installed with a preset restriction. An example of this would be “MCFeatureLimitAdTrackingForced”. This may be set by an organization for employee devices, for example.

Get the latest marketing news and expert insights delivered to your inbox

Facing the future, head on

iOS 14 has disrupted the mobile marketing landscape and we expect the pace of disruption to increase as the adoption of iOS 14 grows. That’s why we built a culture of agility and innovation into the heart of our company that allows us to not simply adapt to, but anticipate and plan for, whatever changes lie ahead.

We admit it – this sudden uptick in IDFA-zeroed devices was surprising to us; surprising, but not alarming. It is simply another aspect of the evolving landscape that we are well-equipped to support.

With mobile attribution and measurement becoming ever more complex, we’ve invested in building the largest and most experienced team of developers in the industry to support brands with the measurement tools they need to succeed and make sure they stay competitive in today’s ever-changing market. 

The post The untold story about zeroed IDFAs on iOS 14 devices appeared first on AppsFlyer.

The post iOS SDK v6.14.0 with Privacy Manifest appeared first on AppsFlyer.