But, back here in real life, there’s another important takeaway: as usual, WWDC also brought its annual collection of user privacy improvements. Apple clearly doesn’t want privacy headlines getting in the way of VR goggles, so these updates didn’t even earn a mention in the keynote. Don’t let that fool you, because they are still a pretty big deal.

Here’s the theme: Apple made no privacy policy changes this year, but they have come up with an array of new things that are designed to help developers more easily comply with the policies already in place…and prevent compliance “mistakes” (whether accidental or otherwise).

In other words, if you’ve already embraced the new world of privacy-centric measurement (for example, if you work with Branch), the next few months should be relatively straightforward for you (and — as always — our team will be here every step of the way to guide you through the process).

On the other hand, if you’ve been investing in workarounds for the last two years, your life just got waaaaay harder. It’s absolutely clear what Apple wants now. Perhaps there is still wiggle room to get away with ignoring the policies after this year’s changes, but the stakes are rising and the rewards are shrinking. The Privacy Engineering team at Apple operates on a timeframe of years, and they’re not giving up.

In this post, I’m going to share a summary of what we have learned so far. This is based on information from Apple’s public WWDC developer session videos, updated iOS documentation pages, and follow-up Q&A sessions with the Apple Privacy Engineering team.

First, a quick recap. The App Tracking Transparency (ATT) framework, which Apple introduced at WWDC in 2020, essentially does four things:

1. It defines “tracking” as activity related to advertising and data brokers.*
2. It gates IDFA access.
3. It contains policy limitations against other forms of cross-company “tracking” (i.e., hashed email addresses) without user consent.
4. It reiterates that policy prohibitions against fingerprinting (which have always been in the Apple Developer License Agreement) continue to apply, separate from restrictions on “tracking” and regardless of user consent.

* As defined on this page: “Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.”

The improvements this year seem designed to ensure that 3 and 4 are no longer just policy.

What’s new in privacy on the App Store this year?

Here are the main components of what Apple announced this week:

1. Privacy Manifests. Standardized files that outline the privacy practices of an app or third-party framework (SDK).
2. Privacy Report. An auto-generated reference doc, based on the details contained in all relevant Privacy Manifest files, designed to make it easier to fill out the Privacy Nutrition Label questionnaire during App Store submission.
3. SDK Signing. A way for app developers to be confident that the third-party SDKs they use (such as Branch) are the original, validated versions and have not been tampered with.
4. Privacy-impacting SDKs. A list of SDKs that Apple judges to have particularly high impact on user privacy. Any SDK on this list will be required to include a Privacy Manifest file, and be signed by the original developer (these steps are also recommended but not required for SDKs that are not on the list).
5. Required Reason APIs. A limited selection of iOS functionality that could potentially be used for fingerprinting, for which an “allowed reason” for usage must be declared in the Privacy Manifest file. (Note that “API” in this context means things like accessing disk space, not service APIs the way we typically think of them in the world of mobile marketing).
6. Tracking Domains. Internet domains that an app or SDK connects to that engage in “tracking.” These must be declared in the Privacy Manifest file, and network requests to these domains will fail until the user gives ATT consent.
7. Domain Profiler in Instruments. Tooling in Xcode that developers can use to compare an app’s network requests against a list of internet domains the OS believes to be capable of “profiling” across multiple apps and websites.
8. Link Tracking Protection and Safari Private Browsing Improvements. New functionality in Messages, Mail, and Safari Private Browsing to strip URL query parameters used to track users across websites, and block various other forms of cross-site tracking.
9. SKAdNetwork 5.0. The new version will support re-engagement attribution (app opens), and is coming “later this year.” That is literally all we know so far.

We’ll go through each of these in more detail.

Privacy Manifests

The Privacy Manifest file is a centralized place to set privacy-related configuration items. An app can have one, and SDKs can also each have their own (for SDKs on the privacy-impacting list, this will be required).

There are four sub-sections in a Privacy Manifest file:

1. NSPrivacyTracking. This is a Boolean that indicates whether an app or third-party SDK uses data for “tracking,” as defined under the ATT framework. While not officially confirmed, we suspect setting true for this value will trigger Apple to look for the ATT consent modal in the app during App Store Review.
2. NSPrivacyTrackingDomains. An array of strings that lists the internet domains an app or third-party SDK connects to that engage in “tracking” (see Tracking Domains section below). If the user has not granted tracking permission through the ATT framework, network requests to these domains fail.
3. NSPrivacyCollectedDataTypes. An array of dictionaries that describes the data types an app or third-party SDK collects. Xcode will use these values to generate a report (see Privacy Report section below) for easy reference when answering the Privacy Nutrition Labels questionnaire on App Store Connect.
4. NSPrivacyAccessedAPITypes. An array of dictionaries that describe the iOS APIs an app or third-party SDK accesses that have been designated as APIs that require reasons to access (see Restricted APIs section below).

These files are created in Xcode, and look like this:

Source: Apple, Get started with privacy manifests

Privacy Report

The Privacy Report is a PDF generated in Xcode, based on the values reported in the Privacy Manifest files for the app and any included SDKs. These are the same values (data types and uses) that have existed in Privacy Nutrition Labels for several years, so this isn’t technically new. However, collecting this information for the app and any included SDKs has always been a bit of a pain.

Source: Apple, Get started with privacy manifests

Having a centralized reference report should simplify the process of answering the Privacy Nutrition Labels questionnaire on App Store Connect. But it’s important to know this won’t be a full solution: in follow-up Q&A this week, Apple has suggested that SDKs are expected to disclose everything that might be collected, and then provide additional guidance (outside of the Privacy Report) for developers to consider when determining what the final Nutrition Label questionnaire answers should be, depending on what SDK functionality the app developer has actually implemented.

SDK Signing

Xcode now checks to confirm that app dependencies (i.e., third-party SDKs from partners like Branch) come with a valid code signature. For SDKs on the privacy-impacting list, Apple will require the SDK to be signed by the original developer.

The security of the software supply chain is rarely an issue with reputable SDK partners (especially those that follow open-source best practices), but this change likely has an additional objective: requiring privacy-impacting SDKs to be signed by their original developers will drive accountability, and make it far more difficult to surreptitiously modify SDKs in order to bypass other privacy protections.

Privacy-impacting SDKs

This is a new list (not expected until later this year) of third-party SDKs that Apple considers to have particularly high impact on user privacy. SDKs on this list must include a Privacy Manifest file, and a code signature from the original SDK developer.

Some might consider inclusion on this list to be a significantly negative thing. But in reality, being included will simply require SDK developers to implement best practices that any reputable software vendor should be following anyway. 

Apple has also confirmed in follow-up Q&A that this list will be available well in advance of any enforcement actions.

Required Reason APIs

Apple has identified “a small number” of platform APIs that enable valuable functionality, but also have a high potential for misuse (i.e., a liability for fingerprinting). While the actual list is not expected until later this year, Apple specifically clarifies that most apps likely use one or more of them.

Apps and SDKs that require these APIs will need to specify an approved reason for access. For example, one of the approved reasons for calling NSFileSystemFreeSize (which indicates the amount of free space on the file system) will be checking whether there is sufficient disk space before writing files to disk. Reasons will be specified through the Privacy Manifest file, and Apple will provide a feedback form to suggest new reasons for calling covered APIs.

Tracking Domains

We’ll let Apple’s highly-diplomatic language stand on its own:

“In cases when a user has not provided tracking permission, iOS 17 automatically blocks connections to tracking domains that have been specified in any privacy manifest included in your app. […] By preventing accidental connections, this feature helps to preserve your intention to not track users without their permission.”

In other words, ATT compliance is no longer just on the honor system. Yes, an unscrupulous actor could technically try to evade including all their tracking domains, or even set up a first-party proxy relay to do server-to-server fingerprinting, but Apple already knows how to detect that on the web. Who really wants to keep fighting an annual insurgency against an omnipotent adversary, whose desired outcome seems to be backed by both public opinion and regulatory momentum?

From a technical perspective, Apple specifically recommends separating traffic types into different domains, such as tracking.example.com and non-tracking.example.com. Apple also clarified in follow-up Q&A that user-initiated activities (for example, tapping on a link) will not be blocked, even if the link is on a tracking domain.

Domain Profiler in Instruments

To help detect unexpected tracking domains, Apple is giving developers new tooling to analyze their app’s network traffic. It lives in Xcode, and looks like this:

Source: Apple, Detecting when your app contacts domains that may be profiling users

Note the alert in the corner of the image: “Fault: www.example.com is not listed in your app’s NSPrivacyTrackingDomain key in any privacy manifest. It may be following users across multiple apps and websites to create a profile about users of apps that contact this domain”

In follow-up Q&A, Apple confirmed that this list of domains will be consistent for an OS version both on device and the simulator, suggesting that domains are not being classified locally on the device (unlike Intelligent Tracking Prevention in Safari).

It appears the output of this tool will be for informational purposes only, as Apple has also indicated in follow-up Q&A that it is not expected that every domain flagged in this tool is necessarily a “tracking domain” — rather, it’s simply a list of domains that the OS considers to be technically capable of tracking. 

However, the documentation page states: “If you determine that the domains your app connects to are using data sent from your app to track people, declare them in your privacy manifest and ask for permission to track under the App Tracking Transparency framework.” It’s reasonable to expect that App Store Review will also have access to this data, and may ask pointed questions if they suspect a discrepancy.

Link Tracking Protection and Safari Private Browsing Improvements

Websites often use URL parameters for measurement and cross-domain tracking. iOS 17 will remove “known tracking query parameters”from links that users share in Messages and Mail, and Safari’s Private Browsing mode will get the same query parameter functionality, along with a number of additional upgrades to block web-based fingerprinting and other cross-site tracking techniques.

In the video describing these changes, Apple recommended Private Click Measurement (PCM) to replace URL parameters for web ad attribution, and we’ve already seen claims that this is “the end of UTM tracking.” That’s probably overblown at this stage, given the changes only apply to the Private Browsing mode of Safari and shared links in Messages and Mail, but it’s not difficult to see where the current trend eventually leads.

SKAdNetwork 5.0

We know SKAdNetwork (SKAN) 5.0 is coming, because Apple mentioned it for about 18 seconds. SKAN 5 will support attribution for app opens (not just installs), which was one of Branch’s wishlist items and counts as an incremental improvement. That’s literally all Apple said about it, so we’ll just have to stay tuned for “later this year.”

In reality, support for app opens may not seem like a huge improvement for two reasons:

1. Major networks have already introduced aggregate attribution frameworks (for example, Facebook AEM and Google GBRAID) to solve a similar problem.
2. Re-engagement ads often involve a direct deep link into the destination app. While proper policy compliance would still require ATT consent to attribute these conversions, many in the industry have chosen to ignore this restriction and simply pass a click ID through.

However, it’s likely the new Tracking Domain protections in iOS 17 will have at least some impact on both of these approaches, meaning SKAN support is necessary to fill the gap of re-engagement attribution for users who do not provide ATT consent.

What about deferred deep linking and owned/earned attribution?

Apple has taken great pains to emphasize that no policies have changed this year, particularly around what is considered to be “tracking.” In other words, they want to make compliance easier and don’t intend to cause significant disruption for anyone already following the spirit of the existing policies.

However, these are fairly substantial technical changes, and there is the possibility of collateral damage to other, policy-compliant functionality. We don’t currently anticipate any impact on Branch’s ability to continue delivering services like deferred deep linking or owned and earned attribution, but we’ll have more updates as Apple releases additional details.

How does it all work together, what happens next, and who is responsible for what?

That was a lot of detail. What do you actually need to DO?

Here’s a summary of the timeline Apple provided:

• Starting in fall 2023, App Store will check if new and updated apps include a privacy-impacting SDK. If the privacy-impacting SDK does not include a signature and Privacy Manifest, Apple will send an informational email to the app developer. Apple will also send informational emails for apps that access Required Reason APIs without declaring approved reasons.
• Starting in spring 2024, signatures and Privacy Manifests for privacy-impacting SDKs will be expected, and become part of App Review. You’ll need to address any issues before you submit new and updated apps to the App Store.

Your vendor partners (including Branch) will be responsible for most of the heavy lifting with these changes. This involves:

1. Providing Privacy Manifests, including disclosing tracker domains and ensuring any uses of covered APIs are for permitted reasons.
2. Signing SDKs.
3. Updating SDKs and backend infrastructure to avoid any unintended collateral damage, now that Apple has articulated a clear distinction between “tracking” and “non-tracking” network traffic.

As an app developer or marketer, you’ll also be responsible for a few things:

1. Confirm your vendor partners are aware of these changes. Apple didn’t mention anything in the keynote this year, and you don’t want to be caught unprepared in a few months.
2. Schedule development time for SDK updates. As with most iOS privacy changes, these are inevitable.
3. Prepare your own app’s Privacy Manifest. Apple says you don’t need to cover data collected by third-party SDKs, but you’ll still want to disclose everything related to your own functionality.
4. Continue to answer the Nutrition Label questionnaire in App Store Connect. This will be simplified in some ways with the new Privacy Report, but will also still require conversations with your privacy and legal teams, and referencing outside resources.
5. Use Instruments in Xcode to confirm your tracking domains. There will be false positives in this report, and Apple has indicated that it is not expected every domain flagged in this tool is a “tracking domain” so you’ll likely need to confirm things with your partners.

As always, your Branch team is here for you every step of the way. Don’t hesitate to reach out with any questions!

The post The Dark Horse of WWDC 2023: Privacy Policies Finally Get Real appeared first on Branch.

The release notes for beta 4 of iOS 15 included a tiny note: 

“Background pushes will only be delivered if the app has been used in the foreground in the past few weeks.”

It sounds like a minor update, but this is relevant to mobile marketers and product managers. It means uninstall tracking is significantly limited on iOS, beginning with iOS 15. This is a good thing for the mobile ecosystem: uninstall tracking, while popular, has always been a policy-violating, privacy-invasive hack. At Branch, we made the deliberate decision to not support it, despite the market demand, because we felt it was not in line with our mission and the privacy principles we live by.

Let’s back up and define a few things:

Background pushes are the silent, invisible version of push notifications that can be delivered to apps behind the scenes. They don’t show up on the device as banners or alerts, but they’re useful as a way to wake up inactive apps in the background for a short time window (on iOS, up to 30 seconds of processing time) to update content or perform some other action.

Uninstall tracking involves hacking these background push notifications to detect when an app has been uninstalled. It works as a sort of “dead man’s switch” by sending background pushes continuously until one isn’t delivered successfully (which indicates an uninstall has occurred). It’s pretty easy to see how Apple’s iOS 15 change will get in the way: when the OS stops delivering background notifications to an inactive app after “a few weeks,” every user will appear to have uninstalled.

Tracking uninstalls has been popular in the past because it can provide a sort of “anti-conversion metric.” In other words, typical mobile attribution measures desirable outcomes (e.g., campaigns that positively influence a user so much that they purchase in-app). Uninstall tracking is a tool to help avoid undesirable outcomes (e.g., campaigns that irritate users so much they uninstall the app in frustration). While there are often better ways to achieve the same objectives, tracking uninstalls isn’t necessarily a bad metric…in theory.

So, what’s the issue with uninstall tracking? In practice, there are actually three:

1. Abusing the push notification system this way is explicitly forbidden in developer policies by both Apple and Google. These policies have not been widely enforced in the past, but the stakes are rising.
2. The data quality has always been extremely dubious (for example, users can opt out of push notifications).
3. The most typical use case (audience generation) is extremely offensive to users: most consumers have no idea they could be added to a retargeting audience for ad campaigns when they uninstall an app, but there is a long history of outraged responses when they find out. In fact, this is exactly the kind of “creepy tracking” that Apple targeted for extermination with the AppTrackingTransparency policy in iOS 14.

At Branch, we’ve always thought uninstall tracking was a poor metric. It’s invasive to user privacy, the data is unreliable, and it puts apps at risk for rejection from the store due to policy violations. That’s why we never built it — it does not align with our values, and it creates a major liability for our customers.

We’re glad Apple closed the uninstall tracking loophole in iOS 15, and the way they went about it is remarkably similar to some of the other privacy improvements in iOS 15: by using technical changes to flood the data with noise, Apple kneecaps privacy-invasive tracking without needing to take more direct action. Given the new, far more privacy-aware age we’re entering, we won’t be surprised if Google takes similar measures on Android.

We’ve already seen claims that limited uninstall tracking may still be technically possible on iOS, even after this change. While that could be true, we suggest taking this as an opportunity to reset the stage: if your team is still relying on uninstall tracking, this is the right time to move on. You won’t be making decisions based on incomplete data, users will appreciate your respect for their privacy, and you’ll be safe from the risk of running afoul of app store policies.

The post Apple Killed Uninstall Tracking on iOS 15, and That’s a Good Thing appeared first on Branch.

More specifically, the FTC alleges that Kochava has been selling geolocation data that “can be used to identify people and trace their movements.”

At Branch, we typically try to avoid commenting on situations like these. However, the headlines for this story are alarming enough that a number of our customers have reached out to us with questions. They want to know what this news means for Branch, and what it might mean for them.

In other words, customers are asking if the data of their own users might also be for sale.

This answer is very simple, so I want to make sure it is completely and impeccably clear: Branch does not sell our customers’ user data. We never have, and we never will. This has been one of our core principles going back to the beginning of the company.

But how did this situation happen?

I could end this blog post right here. But I know at least a few readers will want to understand why we are having this conversation in the first place. The ad tech ecosystem is complex, and we don’t always do a good job of explaining things in a way that makes sense for people outside the circle.

In Kochava’s case, the FTC lawsuit stems from a different line of business known as the Kochava Collective. This is completely separate from Kochava’s MMP (which provides ad attribution), and does not include any data collected by their MMP product (for a full explanation, here is the open letter from Kochava’s CEO).

Why does this matter? Keeping customer data private and confidential is inherent to an MMP’s existence. In fact, this is a fundamental tenet of what it means to be a mobile measurement partner: we exist to serve as your trusted independent arbiter, acting on your behalf to provide accurate and unbiased ad measurement. And just to avoid any confusion, there is no valid reason why an MMP would need access to a user’s precise location coordinates (you can’t send this kind of geolocation data to Branch even if you wanted to — we can’t use it, and we don’t want it).

Unfortunately, the distinction between Kochava’s MMP offering and the Kochava Collective is almost universally getting lost in the noise.

As a brand, what should you be thinking about for the future?

Stories like this one are not exactly new for the adtech industry, but the importance of user privacy has only grown over the past two years. This means it will become even more critical for brands to carefully consider the vendors they partner with, and to understand not only the risk of the products they are using, but also any reputational risks relating to the vendors that they select.

Yes, any respectable MMP will keep your user data private and confidential. That is true by definition today, and is unlikely to change in future. But in this new world, where privacy has become an insanely complex, three body problem and news stories about user privacy and data security can spread like wildfire, companies have to look at an even bigger picture: are there other areas of reputational exposure relating to this vendor that could hurt my brand?

At the end of the day, you cannot succeed in the digital world without working with partners, so it’s critical to make sure you’re keeping good company. At Branch, our commitment is to be an industry-leading MMP and a partner that you can be proud to work with.

The post When You Work With Branch, Your Data Is Yours. Period appeared first on Branch.

I’ve participated in many roundtables during my time in the mobile industry, but these were some of the most sophisticated, insightful conversations I’ve ever had. In this post, we want to share a few key insights and takeaways, including strategies on how to grow, measure, and retain your mobile app users.

Find ways to make your app attractive and sticky for users

Differentiation is key to making your app stand out. One good option for this is personalization, which can be used for both user acquisition (e.g., via personalized content, including content generated by other users in the app) and effective engagement (e.g., gamification of the app experience).

However, while personalization has been a key differentiator for driving growth, rigorous testing to confirm its effect is crucial. Deploying personalization at scale is also a challenge, and some companies are looking at systems powered by machine learning as a way to accomplish this. 

Gamification can also help with differentiation, but it’s difficult to get right. Even agreeing on the definition of ‘gamification’ is hard. The challenge is finding a gamification strategy that actually fits with the app or product rather than simply relying on giving referral discounts or monetary incentives. 

It’s more important than ever to control your own data

With the continuing reduction in data signal, due to new regulations and changing platform privacy policies, having a first-party data strategy is increasingly important. This includes controlling and centralizing your own data so it can be used effectively throughout your organization as a competitive advantage. Data centralization — considering how to both collect and standardize inputs from multiple external channels, as well as how to distribute consistent data across the company — has always been a challenge, but it has become much harder in part due to iOS privacy changes. 

Loyalty programs can be a useful key tactic to control your own data, but the continuing interaction over time must feel authentic to your customers, as well. Implementation decisions also matter since third-party management of loyalty programs can result in loss of data control.

Data is now less reliable and complete now than in the past

There is no doubt attribution data is now less reliable and complete. This is in comparison to what was available prior to iOS 14 and also to Apple’s introduction of the AppTrackingTransparency (ATT) policy. What’s less clear is whether there ever was a ‘golden age of attribution’, because no one was ever completely satisfied with their mobile attribution data in the first place. The old systems already ignored a lot of gaps, and no one totally trusted them. 

Still, the gaps have become more prominent with increased lack of data signal, especially from iOS 14 privacy changes. This has led brands to question if paid ads are worth the investment now that targeting and proving ROI is more difficult. Advertisers agree it’s important to maximize the signal they’re getting from a limited amount of data, but the path forward isn’t clear. The new world is harder for smaller companies to navigate, and it will get even harder from this point forward. 

When it comes to prompting for ATT opt-in permissions, the timing of when to make the request, and how to embed it into the user journey, is critical. This is because it’s important to ensure you hit at the right time to maximize the likelihood of a positive user response. This right time could be different for different cohorts, and activation actions can differ more based on user goal than user profile.

New measurement approaches may help but require major changes

In recent years, performance marketing on mobile has become a precise, metrics-driven science. With the ongoing disruption of data signal, in some ways we are returning to a simpler time and bringing back the art of marketing.

As people are trying new options to centralize their data, new approaches to measurement have promise. These include media mix modeling (MMM), incrementality, and data clean rooms. But these approaches will also come with their own challenges. In reality, it’s hard to trust black boxes, especially when justifying to other stakeholders. However, there is some good news. These new measurement approaches may open up more non-traditional growth channels that previously weren’t measurable, and, therefore, not considered. 

There are still many challenges to work through with all these new solutions. Most brands are looking for ways to minimize the gap during this transition period. Media mix modeling requires a huge amount of data, and most smaller companies don’t have enough of it to build a usable model (at least, using traditional MMM techniques). Many brands feel it’s important to start collecting whatever data they can now, to make it possible to build differentiated models before everything disappears. 

Despite these challenges, iOS users are still considered more premium. Privacy changes may be making it harder to reach them, and they may no longer be reliably more valuable for ad audiences than Android. But brands are not ready to throw in the towel on iOS users yet.

It’s no longer cost-effective to fill the bucket without fixing leaks

With the increasing difficulty and cost of user acquisition, throwing money at the top of the funnel via ads, influencers, or discounting isn’t always the answer to increase user base. Instead, it’s critical to focus on retention and reengagement for the users you already have. And because it’s very hard to bring back churned users unless you know why they churned, it’s important to find people who are already ‘on the bubble’. In fact, sometimes the most effective option is to reuse your existing top-of-funnel or brand content (like info on new product improvements) with existing or churned customers. Or use basic, FOMO-based messaging, like a subject line that says ‘Pending’ or ‘New in your membership’ to bring users back.

The truth is, with the attrition of device IDs, the yield on paid reengagement is low, and it’s becoming even more difficult. Most now agree the future of ad targeting is contextual — at least until the implementation of next-generation technologies like Topics and FLEDGE in Privacy Sandbox. And it’s almost impossible to reliably find your existing (or churned) users via contextual targeting. This makes it much more difficult to justify paid reengagement campaigns. Some brands are no longer bothering to run them for iOS users at all. 

Discounts bring new customers, engagement, and headaches

Discounting can seem like an easy fix, but companies and customers risk getting addicted to it. Once you start discounting, your customers expect it to continue. Discounts and coupon codes are rarely a first-choice strategy, but if others in the space are doing it, companies can be forced to play along despite concerns about how discounting affects the value of their brands. 

Discounts tend to be more important at the lower-cost end of offerings, while premium product buyers usually don’t care about getting a deal. Customers say they want traditional ‘dollars-off discounting’, but for many brands, using discounts to add value or encourage adoption of more products is a better strategy. Ideally, determining the value of a user via A/B testing or other strategies and providing a custom discount code to that individual is preferred over handing out the same discount to everyone. 

Some level of discount fraud exists for nearly everyone who uses discounting as a strategy. Companies are monitoring this and combating it with limits, single-use codes, monitoring for duplicate accounts, and, in some cases, geohashes and AI to detect suspicious behavior. Codes that leak and go viral are always a challenge, but if the code doesn’t hurt your business, sometimes it’s okay to let it go. In fact, sometimes brands are ‘hacking the hackers’ in that the perceived value can go a lot further if customers think they found a secret.

Appetite for alternative and experimental growth channels increases

Measuring the ROI of experimental growth channels has always been more difficult than paid advertising. However, measurement of ads is also harder today, which helps make alternative growth hacks easier to justify. 

Given all the changes in the world, what is old is new again. Brands have tried everything from programmatic direct mail services to send cards in the mail to hiring a plane to fly a banner. And the effects of campaigns like these can be amplified when people are incentivized to extend reach on social media. Tactics like gamification, referrals, preloads on new devices, and influencer marketing/ambassadors are all directions brands are considering.

Referrals are a popular and increasingly important channel but need care to get right. The incentive has to be enough for users to see the value in recommending to their friends. And while monetary rewards are the easy choice, they’re often not the most effective. Other options that can work better include gamification, physical gifts, or special VIP-type access to things. Pairing up with another app to access their audience through cross-promotion is another great way to access a new audience. 

Web-based SEO is also increasingly important as an acquisition channel for brands with native apps. But the shift from technical SEO to content-driven SEO opens the door for new questions around what makes good content and how to turn content visits into app users. (Web-to-app banners are a popular solution!) Also, a content-driven strategy may not be relevant to every vertical. For example, should you generate content if you’re a utility-type app?

If you’re going to experiment, you have to be in an interactive mindset. This is because digital attention constantly shifts. The things you did a couple years ago will not work today. TikTok is often cited as an example where very unintuitive videos do well compared to the viral videos of yesteryear. You also have to be ready to scale a campaign once you find something that works. For example, if a PR article hits, or a viral post starts to scale, be ready to push it out to all channels within minutes. Taking even one day could cause you to miss the opportunity.

Measuring an experimental campaign is done in a variety of ways. Those with more tech investment can utilize MMM (even the more traditional solutions available today). But other, faster ways include monitoring direct/organic traffic around the time/geo of the campaign to observe the lift. 

Apps are now just one part of a broader brand <> customer relationship

For many brands, making the app part of the broader customer relationship — not just a destination of its own — can extend its value. Physical campaigns like QR codes help drive conversions, and it makes sense to use them everywhere, such as on receipts, boxes, menus, coupons in mail, flyers, and so on. User-generated content (UGC) is another great flywheel for understanding what users care about. UGC has the added benefit of providing ready-made raw material that brands can use to enhance marketing campaigns. 

Freemium models can also be used as part of an acquisition strategy, but it’s important to consider how much to give away for free. To determine this, you need to understand how customers are using the product during onboarding. However, it is important to do this carefully since the collection of more information could impact conversions. Freemium models can also help to identify champions that assist in building audiences. 

Finally, not every brand has the same goal for app engagement and marketing campaigns. Sometimes app installs are the goal, and sometimes the goal is to drive as much ongoing engagement as possible. But in other cases, not all app engagement is good. Some brands grapple with finding ways to engage customers without unintentionally reminding them to cancel a subscription. Or they grapple with keeping costs in control with the right level of interaction when more app usage equals more costs. 

Bring teams together with flexibility for comfort levels

The post-COVID adjustment is challenging for every organization to manage, not just in mobile. COVID has affected trust and engagement, making it much harder to connect and feel unified. Many people moved to other time zones during the pandemic, which has made it harder to meet both in person and even virtually. 

Collaboration itself has changed, too. Many teams are having new discussions about how to best use Slack, Slack threads, meeting pre-reads, and Zoom meetings. (No one has yet discovered a good solution for Zoom meetings where some participants are in a room while others are remote!) 

Most leaders want people to come back to the office to foster innovation and creativity, at least occasionally, but it’s hard to find what motivates their teams to do so. And the lack of clarity on company policies creates uncertainty that is hurting retention. Some companies report losing their best talent because of a too-strict policy on office work. This is why it’s key to meet 1:1 before making a request for anyone to return to office. 

New hybrid work models are also emerging. Rather than requiring a regular in-person office presence, some companies are experimenting with monthly, quarterly, or annual get-togethers as a way to build bonds. Companies reported these are becoming a lot more fun and activity-based, rather than being about working together in the same location.

Want to join the conversation?

If you would like to apply to join the LIM community or find out more about upcoming LIM events, please email info@leadersinmobile.com.

Get in touch

The post Critical Conversations: What Are Mobile Leaders Discussing in 2022? appeared first on Branch.

In this blog post, I’m going to recap what Privacy Sandbox is, share some early thoughts on what it means for mobile linking and measurement, and give you a preview of what to expect over the next few months.

What is Privacy Sandbox on Android?

Google first introduced Privacy Sandbox several years ago. This original version focused on Chrome, with the intention of developing replacements for third-party cookies on the web, and is what gave us proposals like FLoC (recently revised into Topics).

Privacy Sandbox on Android is an expansion of that original initiative to also cover native Android apps. Now, it’s no longer just about third-party cookies — the Google Advertising ID (GAID) is also in scope, and this starts to look a lot like the privacy updates Apple introduced with iOS 14.

Google is eager to note that none of these changes are coming imminently: the current techniques (including GAID access) won’t change for at least the next two years, and beta releases of the new technologies aren’t expected until late in 2022. There’s no need for immediate concern, and we’ll all have plenty of time to prepare.

Screenshot from Privacy Sandbox on Android website, February 16, 2022

There are four ‘design proposals’ in Privacy Sandbox on Android:

• SDK Runtime. This is a new framework designed to provide a safer way for apps to integrate with third-party SDKs.
• Attribution Reporting. This is an API for measurement of ad performance without the need for user-level identifiers (like the GAID).
• Topics. This facilitates interest-based ads personalization, also without relying on user-level identifiers.
• FLEDGE. This makes it possible to show customized ads to users based on their prior app activity, without needing to share data with third parties.

The latter two proposals deal primarily with ad targeting, so I won’t go into them in depth with this post — if you’re interested, you can find a great rundown of the details here.

SDK Runtime

The SDK Runtime is the only component of Privacy Sandbox on Android that doesn’t have a parallel in the web version of Privacy Sandbox. It’s an ingenious solution that will effectively isolate the execution of SDK code from the rest of the app.

On iOS, one of the challenges Apple has had with enforcement of the AppTrackingTransparency policy is finding a way to prevent bad actors from collecting too much data. So far, the only option for this has been policy enforcement. But by isolating the SDK code from the app itself, Google will be able to sidestep those challenges with a technical solution that makes it impossible for an SDK to collect data it shouldn’t need.

There are also other benefits to this approach: a big one is that SDKs can be distributed and updated separately from the app itself. This will make it possible for vendors to roll out minor updates (bug fixes, security patches, etc.) without requiring developers to issue a new version of the app each time.

Look for a deep-dive blog post on this proposal in the coming weeks.

Attribution Reporting API

Attribution Reporting is Google’s solution for private, aggregate-level ad attribution. This API also exists in the web version of Privacy Sandbox, but for apps, you can think of it as basically equivalent to SKAdNetwork…except with a lot more functionality.

We’ll also have a deep-dive blog post on this proposal soon, but here are a few of the highlights:

• Does not require deterministic, user-level identifiers like GAID.
• Allows configurable attribution window length (anywhere from 2-30 days).
• Can be configured to support either true last-touch attribution or install-touch attribution.
• Supports all combinations of cross-platform user conversion paths (app-to-app, but also web-to-app, app-to-web, and web-to-web).
• Allows reporting on additional in-app events that happen after the install. This reporting has limits (1-2 additional events in the current proposal, depending on ad touch type) so there is still going to be an adjustment from what is possible today with GAID-based attribution, but it’s a significant improvement on SKAdNetwork.
• Supports re-engagement attribution. This means it’s possible to measure conversions (like registrations or purchases) from ads that are shown to users who already have the app installed. The lack of re-engagement support has been a major pain point with SKAdNetwork.

• Allows custom segmentation dimensions for aggregated reports. This will make it possible to report on things like geographic regions and campaign creatives, which has also been a major challenge with SKAdNetwork.
• Allows multiple ad tech platforms to register to receive data. This means no need to build additional complicated infrastructure to forward data around behind the scenes, as was necessary for SKAdNetwork.

Perhaps most importantly, the Attribution Reporting API provides two different types of reporting: 

1. Aggregate-level reports. These give richer, higher-fidelity data, but only in aggregate format. This is equivalent to SKAdNetwork reporting with more detail.
2. Event-level reports. These make it possible to associate conversion events back to specific ad touchpoints, though with only a limited amount of detail. Event-level reports won’t be a replacement for the log-level data that is currently available via GAID-based attribution, but will provide important, granular input for purposes like training ML models.

There are obviously still some gaps in the proposal. For example, there doesn’t currently appear to be support for anything that would enable multi-touch attribution, but the documentation contains a note about potential exploration of more advanced attribution models. Perhaps this will be added in the coming months.

Other top questions

Was this expected? Yes. Most observers agreed that Google would eventually make changes to match Apple’s iOS 14 privacy updates. Google is clearly aware of how their moves impact the broader mobile ecosystem, and they obviously intend Privacy Sandbox to be seen as a contrast to the ivory-towerish strategy Apple took with ATT.

Is GAID really going away? Google hasn’t specifically addressed this…and it’s possible they haven’t made a final decision yet. However, it’s clear that things will be significantly different two years from now.

Will there be an ‘ATT prompt for Android’? Google also hasn’t specifically addressed this. We can assume that if these design proposals are successful, there won’t need to be universal, user-level identifiers (like GAID) for attribution on Android in future, which could make a platform-level permission prompt like ATT unnecessary.

Is it truly good for user privacy? Yes. Once rolled out, these changes will significantly improve privacy for Android users. Universal platform identifiers (like GAID, IDFA, and third-party cookies) are very useful for many legitimate purposes, but they also form a significant tracking vector. The issue is that brute-force removal of those techniques can simply push the behavior underground, into a sort of ‘tracking black market’, which is what we’re currently seeing on iOS. However, I’m hopeful that Google’s proposals are substantial enough that this will not happen on Android.

Will this actually DO anything? Isn’t Privacy Sandbox still basically ‘stuck in committee’? The web version of Privacy Sandbox seems to be progressing fairly slowly (in part, due to attention from the UK’s antitrust authorities), but there are some reasons to think things could move faster on Android: for one, Google has already run this playbook for the last three years on the web, so they’re not starting from zero on Android. Also, while Chrome is the biggest browser globally, it has real competition and the web is built on shared standards. In contrast, the Play Store absolutely dominates Android app distribution in most of the world, so it will likely be much easier for Google to make a change happen.

How does this map into other upcoming Android privacy changes? In Android 12, Google has already been making several other privacy-related changes:

1. Removing access to the GAID when users opt out of ads personalization. This is basically equivalent to Limit Ad Tracking, as introduced on iOS years prior to ATT.
2. Requiring a new permission to access GAIDs at all, even for users that did not opt out. This is purely a technical implementation change for developers, and has no other impact.
3. Adding a Data Security section to the Play Store. These are essentially ‘privacy nutrition labels’ to give users more visibility into what data an app is collecting and how it will be used.

Like Privacy Sandbox, these other changes were announced with plenty of lead time over the past year, but are all more tactical, catch-up developments. Privacy Sandbox is much bigger in scope, which likely explains Google’s major focus on community collaboration and collecting feedback.

What does this mean for you?

The good news is you can relax for a while. Even if you wanted to, right now there’s pretty much nothing you can do other than reading the documentation: these proposals won’t be available for testing until later in 2022.

Looking forward a few years, the obvious questions are around what this will mean for measurement and linking on Android, so let’s look at these two separately.

Will Privacy Sandbox be ‘bad’ for ad attribution?

‘Bad’ is a relative term, and there are two extremes of how to look at this:

1. One extreme is ‘the good old days’ of unfettered access to attribution via universal platform IDs like GAID. Compared to that, you could objectively say this future is ‘worse’. Data will be more limited, and getting it will be complicated than before.
2. The other extreme is the complete removal of existing attribution methodologies without replacement. Compared to that, what Google announced today is like Christmas in February. Yes, it’s still early, but I’m optimistic that these solutions will allow mobile advertisers to continue measuring the performance of their campaigns in a way that allows them to run their businesses, without risks to user privacy.

However, there is another, more important way to think about these changes: if the last two years have taught us anything, it is that most mobile users now view their privacy as a very legitimate concern. This means that in tech, protecting privacy is now equivalent in stature to guarding against security breaches: yes, building with privacy in mind often requires more work and might seem ‘harder’, but it’s a non-negotiable requirement.

Privacy concerns are not something that will go away, and finding ways to balance these needs with responsible attribution is the key to the future. Apple may have made the first really big move with iOS 14 — and their move arguably accelerated the timeline for everyone else — but the landscape has been shifting for years. 

Will Privacy Sandbox impact linking and owned/organic channels?

At this point, there is no indication that this will have an impact on linking (including deep linking), or measurement of owned and organic channels. In fact, some changes (like the auto-update functionality coming with SDK Runtime) could be quite helpful for allowing Branch to catch and solve new edge cases even more quickly, and with less work from you.

What happens next?

So far, the reaction to Privacy Sandbox on Android in the mobile industry has been almost surprisingly quiet, especially after the chaos of iOS 14. It’s possible this reflects general exhaustion with the pace of recent ecosystem changes, or it could simply be the priced-in expectation that something like this was inevitably coming for Android.

At Branch, we’ve already got multiple teams digging into all of the new design proposals in Privacy Sandbox, and we’ll be working closely with Google to incorporate them into our platform. Thanks to the collaborative communication and extended rollout timeline from Google, we’re not expecting any major disruptions, and we look forward to sharing more information in the coming weeks.

Branch provides the industry’s leading mobile linking and measurement platforms, offering solutions that unify user experience and attribution across devices and channels. Branch has been selected by over 100,000 apps since 2014 including Adobe, BuzzFeed, Yelp, and many more, improving experiences for more than 3 billion monthly users across the globe. Learn more about Branch or contact sales today.

Contact sales

The post What Is Android Privacy Sandbox? Is This The IDFA Apocalypse All Over Again? appeared first on Branch.

Of course, some people really do watch the game itself…but the real reason many tune in to the Super Bowl is for the ads, which now cost at least $6.5m per 30-second slot. This year, crypto was everywhere, and Coinbase is getting most of the follow-up buzz thanks to a quirky commercial that featured nothing more than a simple, color-shifting QR code bouncing around on a black screen.

While the ad itself seems to have confused many viewers (audiences ranked it dead last in the USA TODAY Ad Meter rankings for the game), the results have still been huge for Coinbase: their chief product officer revealed that they saw over 20M hits on their landing page in just a single minute, and Coinbase has dominated the online techy conversation for the last 24 hours since the ad ran.

QR codes are everywhere today, and this is certainly not the first time a QR code has been used as part of an app download campaign on TV — in fact, we’ve seen many similar examples over the past year here at Branch. However, this was likely the first time many consumers in the US have encountered a QR code used this way, and when it comes to mobile apps, not every QR code is created equal.

In this post, we’re going to take a closer look at the Coinbase campaign to see how it was put together (and, spoiler alert, how you can use a mobile linking platform like Branch to create your own).

A step-by-step walkthrough of the Coinbase QR-to-app experience

First of all, it’s worth noting this ad is truly a product of the COVID era. Without the incredible surge in mainstream adoption over the past two years, which has made scanning a QR code almost second-nature, this campaign simply would not have worked.

The Coinbase QR code itself is basic and completely unbranded. This is the kind of code that can be generated by pretty much any QR code tool, including anything from free online services to open-source python modules.

Let’s see what happens when we scan it:

The QR code leads to https://drops.coinbase.com/?qr, a web landing page with two buttons:

• Sign up and get $15.
• Opt in to win $3M.

There are also a few other analytics scripts embedded in the landing page, including Amplitude (product analytics) and Facebook/Google SDKs (conversion tracking and retargeting audiences). The latter will likely be helpful to Coinbase as they look to extend the long tail of conversions from this campaign over the next few weeks.

Now, proceeding with each of the two CTA buttons in turn:

Sign up and get $15. This is the option for new customers who want to sign up and receive free Bitcoin, clearly Coinbase’s primary audience for this campaign. The URL behind this button is a standard mobile measurement partner (MMP) tracking link from AppsFlyer, meaning it is primarily designed for tracking app-to-app install ads, but also capable of being repurposed to measure other marketing campaigns like this one.

Clicking the CTA leads to the App Store. After the user installs and launches the app for the first time, they’re greeted by an onboarding experience that references the same $15 in Bitcoin offer mentioned on the web landing page:

Opt in to win $3M. This is the consolation prize for existing Coinbase customers. If the Coinbase app is not installed on the device, this CTA links to another web landing page where the user can sign in to claim their spot in the drawing:

If the app is installed, the CTA deep links to the sweepstakes entry page inside the app:

(There is also a third, edge case scenario: if the user is logged out of the app for some reason, they are taken to the same $15 offer screen that new users see, and they must sign in before proceeding. The Coinbase app appears to forget where the user was trying to go in this scenario, and brings them to the standard app dashboard after authentication is complete. This kind of deep linking implementation flaw is — unfortunately — not unusual, and can be quite frustrating to users).

What did Coinbase get right with this QR code campaign?

Aesthetic and design

The aesthetic of Coinbase’s ad drives curiosity, and it’s obviously designed to evoke memories of the old bouncing DVD screensaver from 20 years ago:

It’s also cheeky, similar to the very first internet banner ad from 1994: 

In other words, it’s simplistic, radically minimal almost to the point of naïvité, and based on a novelty factor that works once or twice (but would wear off quickly if everyone started doing it).

Custom in-app onboarding experience

Coinbase implemented a custom onboarding experience inside the app for this campaign…though it doesn’t specifically reference the Super Bowl campaign. This lack of continuity could impact conversion rates — more on that in the next section.

No unexpected URL wrapping

QR codes generated with online tools often wrap the destination URL in a redirect. This can be useful, because it provides analytics data and the ability to edit the QR code after publication…but these tools often have unexpected limits on the permitted number of QR code scans.

Even worse, many QR code tools are simply not ready for the massive spike of traffic generated by major campaigns like this one, and can quickly become overloaded at exactly the worst time.

Coinbase managed to avoid these pitfalls by using a plain web URL, but at the cost of other benefits (keep reading!)

Where could Coinbase have done things even better?

The QR code itself

The QR code Coinbase used is an example of a ‘dumb QR code’. This means it points to a basic web URL…and that is the only thing it does. From both UX and data usability perspectives, this was probably the biggest missed opportunity of the campaign.

For the UX side, there was no need to take existing Coinbase users to the web landing page at all — if users already have the app installed, they can be sent into it directly from the QR code scan:

Now, it’s possible that Coinbase made the decision to send existing users through this additional step on purpose, so that they could use visits to the landing page as the baseline metric for their conversion rates, across both users and non-users. However, there’s a better way to implement a user conversion flow like this: taking the baseline metric a level further up, via the link behind the QR code.

This brings us to the second missed opportunity of using a dumb QR code: it has forced the Coinbase team to use a patchwork of different tools, which means they will likely have incomplete data and will need to stitch numbers together across tools to understand the full picture.

A mobile linking platform (or MLP, such as the one provided by Branch!) is purpose-built for campaigns like this one, and gives everything in a single view:

• Use a Branch-generated QR code to track scans and intelligently route users to the right place based on whether they have the app installed or not.
• Embed the Branch web SDK into your landing page to track pageviews and generate deep links for your CTAs.
• Integrate the Branch mobile SDKs to attribute installs, implement custom onboarding behavior, and connect down-funnel events all the way back to the original QR code.

QR code scannability

While the ad leaves the QR code on the screen for almost the entire 60-second spot (plenty of time for viewers to pull up their phones and scan it), the code itself was still relatively small. This caused scanning issues for many people (TV screens can be hard for smartphone cameras to focus on).

Infrastructure and capacity planning

Once this campaign launched, the Coinbase app crashed within minutes.

(Though it’s worth noting that this appears to have been an issue with the in-product offer redemption, rather than any of the plumbing of the marketing campaign itself).

The QR code was completely unbranded

With most consumers now familiar with QR codes, QR code phishing is a growing issue. Normally, an unbranded QR might lead viewers to ignore the opportunity to scan, because a basic QR is a door to the unknown (and not always a smart one to walk through, given the risks lurking on the internet).

But in this case, the implied safety of the high-profile event could have helped encourage viewers to see what’s behind that secret door. And with a full minute of screen time, many users might have laughed, paused, and still had time to scan it before it was gone.

However, adding even a subtle Coinbase logo to the QR code in this ad would have increased its credibility, while also providing the added boost of giving those ‘in the know’ about Coinbase a feeling of belonging to the club.

Not using a Custom Product Page

Apple released Custom Product Pages in December, and a massive branded campaign like this is a perfect situation to use one.

A Custom Product Page would have allowed Coinbase to fully customize the App Store page to match the Super Bowl campaign, including Super Bowl-themed content or reminders of the $15 bitcoin special offer, reinforcing again that the new user is on the right track.

Incomplete custom onboarding in the app after download

Coinbase implemented custom onboarding for users from this campaign, which means these users received a different experience than standard downloads. This is a big win, but there are two ways they could have made it even better:

• Reference the Super Bowl campaign directly. This would provide continuity and reassure new users that they’re in the right place.
• Remember the special offer. The Coinbase app does not remember that new users are in the ‘Super Bowl Special Offer’ cohort if they do not sign up right away. This means if the user gets distracted mid-way through the process, they lose their $15 offer and receive only the standard $5 signup bonus.

How did Coinbase do overall, and how can you replicate it for your app?

Though there were a few notable opportunities for improvement, this was a highly successful campaign that boosted the Coinbase app from 186th place to 2nd in the App Store — in fact, the biggest downside for Coinbase is likely the amount of custom work their team needed to do in order to duct tape all the pieces together.

As mobile apps become increasingly integral to our lives (and traditional app-to-app install ads continue to lose efficacy), we’ll almost certainly see more campaigns like this one. Linking on mobile is hard – and especially QR code linking – but the good news is you don’t need to be a duct tape expert to achieve similar results: with a mobile linking platform like Branch, all of the pieces needed for a campaign like this one are available off-the-shelf (and specifically optimized for mobile apps). If you’d like to talk with our experts about how you can pull off an out-of-the-box campaign like this one, please get in touch!

Contact sales

The post How Coinbase Did It: A Teardown of the 2022 Super Bowl QR Code Commercial appeared first on Branch.

For most app marketers, Facebook ads have always been a key part of any user acquisition strategy. Many things have changed in the world of mobile over the last few years — especially after iOS 14 brought us into the new age of AppTrackingTransparency — but the importance (and relatively predictable effectiveness) of Facebook ads has not been one of them.

However, a significant update is coming to the data available from Facebook’s app campaigns later this fall. This has brought some confusion and concern, as you’d expect for anything that impacts a component of the mobile landscape that so many marketing professionals consider critical infrastructure. Fortunately, Branch is here to help guide you through everything you need to know.

First, and most importantly: if you (like the majority of Branch customers) get your campaign reporting from our dashboard or aggregate export APIs, nothing is changing. Branch will continue to receive attribution data directly from Facebook on your behalf, and it will look exactly the same as it always has (at least, setting aside the major changes already caused on iOS by the shift to SKAdNetwork).

The upcoming change will affect you if you previously signed the optional Advanced Mobile Measurement (AMM) agreement with Facebook, and rely on exporting device-level Facebook ads data from Branch for in-house measurement purposes. In that case, here is what you need to know:

1. As previously announced in July, Facebook will deprecate the AMM program on October 29, 2021. This means Branch will no longer be able to provide log-level exports of conversion data from the Facebook MMP API.
2. Facebook is launching a new way for advertisers to get device-level conversion data on Android. The new solution is based on the Google Play Install Referrer, and has the potential to unlock many of the same use cases for advertisers. It will be fully supported by Branch.

Let’s discuss each of these changes separately in more detail.

Facebook AMM Program Deprecation

The Facebook AMM (Advanced Mobile Measurement) program allows advertisers to export log-level data for Facebook campaigns from their MMP. It requires the advertiser to accept a data use agreement with Facebook, committing to only use this data for allowed measurement purposes (i.e., not for building user profiles or retargeting audiences).

Facebook started down the road toward deprecation a year and a half ago by removing view-through data from the AMM program, leaving data only for click-through conversions. Now, beginning October 29, click-through data is going away too.

In reality, this will not have an impact on the majority of advertisers, as the aggregated reporting available from an MMP (via either dashboard or API) satisfies all of the most common measurement use cases. However, for brands that want to create in-house predictive LTV models or run more complex internal attribution analyses, ingesting the event data available through AMM is critical.

This means its deprecation without any alternative would be quite disruptive. Fortunately, Facebook has a replacement offering — more details in the next section!

Why would Facebook get rid of AMM now? We can assume that user privacy is a key reason. This data is already extremely limited on iOS, due to iOS 14 and Apple’s new AppTrackingTransparency policy, and is inevitably going to become less complete on Android as Android 12 begins to zero out GAIDs for users who opt out of ads personalization. 

A few other details worth mentioning about the AMM deprecation:

• The difference between AMM and MMP. MMPs (Mobile Measurement Partners) are companies integrated with Facebook in order to provide mobile ad attribution. AMM (Advanced Mobile Measurement) is a program that gives advertisers access to device-level data exported via their MMP. The Facebook MMP program is not going away — Branch will continue to receive and process data from Facebook, and can use it to generate aggregate reporting on behalf of our customers. The only change is we can no longer export it to you in log-level form.
• Branch’s unique SAN Deferred Deep Linking solution will be deprecated for Facebook. This feature requires advertisers to accept AMM terms, and won’t function after October 29. 2021.
• Log-level data sharing with FMPs (Facebook Marketing Partners). After the AMM program is deprecated, this will also no longer be possible. It is important to note that this is an update from the guidance Facebook released in September 2021. 

Facebook’s Solution for Post-AMM Data

Fortunately, Facebook has built a new way to share granular attribution data with advertisers, unlocking many of the same use cases AMM used to power.

This new solution passes an encrypted payload via the Google Play Install Referrer, which is a data parameter that can be sent to the Play Store when a user is directed there to download an app. The Play Store stores this value and the app developer can then programmatically retrieve it inside the app post-install.

Facebook will secure the data inside the parameter using symmetric-key encryption, and once decrypted, the data available for each attributed install will look like this:

{
    "ad_id":"<integer>",
    "adgroup_id":"<integer>",
    "adgroup_name":"<string>", 
    "campaign_id":"<integer>", 
    "campaign_name":"<string>", 
    "campaign_group_id":"<integer>", 
    "campaign_group_name":"<string>", 
    "account_id":"<integer>", 
    "ad_objective_name":"APP_INSTALL", 
}

Translation: granular Facebook attribution data will be available on click-through conversions for Android installs that take place via the Google Play Store. This data will not be available for installs on iOS, for view-through conversions, or for Android installs that happen on other app stores.

What is Branch doing

The Play Install Referrer has been part of the Android ecosystem for years — in fact, Branch already uses it for various purposes, including both deferred deep linking and attribution.

To prepare for the launch of Facebook’s new solution, we’ve updated our Android SDK to ensure the Google Play Referrer is always collected, and we’re collaborating closely with the Facebook team to test the new data flow with mutual customers.

Once this is complete, here is what you can expect:

• The Branch SDK will automatically collect Play Install Referrer values on your behalf when your app is installed.
• Branch will accept the secret key you receive from Facebook, and we will take care of the decryption process for you.
• We’ll make the decrypted campaign metadata available to you for export via our existing export APIs and webhook systems, deduplicated alongside all of the data for your other ad network partners and non-paid acquisition channels.
• Our attribution engine will seamlessly incorporate this data into your attribution decisions. If there is ever a conflict between the Install Referrer and the data Branch receives from Facebook’s MMP endpoint, we’ll defer to the Install Referrer due to it being guaranteed last-touch by definition — we don’t expect this to happen often, but we’ll monitor closely as the new solution rolls out (note: this will also ensure your attribution data remains reliable when Android 12 begins to zero out GAIDs for users who opt out of ads personalization).
• Finally, we’ll make this data available in-app for deferred deep linking.

In other words, Branch will continue doing exactly what you have always trusted us to do: take care of the technical complexity inherent in the mobile ecosystem, so that you can focus on your business. Your users will receive amazing experiences, and you’ll have a single source of truth for your measurement data.

What happens next?

Facebook is moving very quickly to make the new Play Install Referrer solution available, and the Branch engineering teams are working with Facebook to make sure our platform is ready. Facebook expects the full GA date for all advertisers to be later this year, following successful testing.

In the meantime, you can ensure you’re ready as soon as the program is launched by updating to Branch Android SDK v5.0.13 or higher. Please reach out to your Branch CSM if you have further questions or want to share feedback or thoughts about this upcoming functionality!

The post Facebook Mobile Attribution Update: AMM Deprecation and Google Play Install Referrer Support appeared first on Branch.

The Branch team has been busy digging through the details of Apple’s announcements, and we’ll get into them below. But perhaps the most notable news from this year wasn’t any specific feature — rather, it’s how the updates combine to demonstrate the continuation of two long-term trends for Apple:

1. Apple is swinging for the fences on data protection and tracking prevention. With the latest round of new privacy features, it’s clear that AppTrackingTransparency in iOS 14 was just the first step in a much grander plan.
2. Apple is trying hard to revitalize the app discovery process inside the store itself. With the context of increasing developer unrest about App Store policies and the potential of new regulations around the globe, it’s more critical than ever for Apple to show why their walled garden approach brings value.

Apple clearly has a vision in mind for where they want the iOS ecosystem to go. In this article, we’ll recap the updates from WWDC 2021, and then share some thoughts on what this means for the world of mobile growth.

What did Apple announce at WWDC 2021?

Some of the new iOS 15 introductions will be a big deal for end-users, but less relevant to mobile marketers and product managers who care about driving growth. For this article, we’ve selected a subset of WWDC announcements to explore:

1. SKAdNetwork enhancements
2. App Clip enhancements
3. App Store variant pages
4. iCloud+
5. iCloud+ Private Relay
6. App Privacy Report
7. Hide My Email
8. Mail Privacy Protection
9. IP masking with ITP

1. SKAdNetwork enhancements

With the AppTrackingTransparency (ATT) policy announced last year finally in effect, SKAdNetwork is now the primary solution for ad attribution on iOS. In iOS 15, SKAdNetwork will support sending a copy of the winning postback directly to the advertiser (or their MMP!) in addition to the ad network that received credit.

What do these SKAdNetwork enhancements mean for mobile growth?

Direct access to SKAdNetwork postbacks is unequivocally great news for mobile advertisers. It addresses one of the most common requests for SKAdNetwork improvements, and will enhance transparency and reduce complexity. At Branch, we’re very glad Apple has made this change, and we look forward to supporting it for our customers.

What would make SKAdNetwork even better? We’re still hoping Apple will eventually add support for non-paid channels and additional post-install conversion events.

2. App Clip enhancements

App Clips are now available in more places, including Spotlight Search and Siri Suggestions. Additionally, iOS 15 provides a new Safari full-page interstitial (shown below) known as an App Clip Card, which can be configured to pop up when a website has a corresponding mobile app. At a technical level, this new interstitial is an extension of the basic smart app banner that has existed on iOS for years.

What do these App Clips improvements mean for mobile growth?

While a promising new feature in iOS 14, App Clips still haven’t seen widespread adoption. Apple is clearly hoping that these changes will change that.

For anyone familiar with existing web-to-app solutions (like Branch’s Journeys), the new App Clip Card probably looks familiar. However, while it validates the importance of giving users a simple path from web to mobile app, it’s not customizable and can only be triggered once. We feel it is likely too much of a blunt instrument for most sophisticated mobile brands.

3. App Store variant pageshttps://branch.io/journeys

The App Store itself is adding two new features that will allow developers to customize their product pages.

The first allows split-testing of up to three different variants of various app assets (icons/screenshots/app preview videos/etc.), and then automatically setting the best variant as the default.

The second provides unique URLs that link directly to up to 35 different versions of a product page, each of which can be extensively customized. An example of this might be a sports app creating a unique App Store experience for a specific team. 

What do App Store variant pages mean for mobile growth?

While the standardized format of the App Store experience has helped users know what to expect when evaluating apps, one big challenge has always been its limited options for customization. Web-to-app flows help with this by making it possible to give the user additional information before reaching the App Store, and deferred deep links help by keeping the user engaged post-install, but the store itself still interrupts the user’s journey. This breaks the context of what the user was trying to do, and leads to frustration, confusion, and dropoff.

The new, highly-customizable App Store variant pages in iOS 15 will make it possible to deliver a consistent context to the user all the way through the install process, likely leading to higher user conversion rates and lower in-store dropoff. We’re quite excited about this new feature, and feel it will make a great complement to brands’ existing deep linked acquisition strategies.

Support for A/B testing of store assets is also a welcome improvement, and brings the App Store in line with functionality that has been available from third-parties and on the Play Store for many years.

4. iCloud+

iCloud+ is a monthly subscription service that unlocks several of the new iOS privacy features that Apple introduced at WWDC.

While iCloud+ is a new product name, it’s actually just a re-branding and expansion — at no additional cost — of the upgraded iCloud storage plans that already exist. This means that many (perhaps most) iOS users will have access by default.

5. iCloud+ Private Relay

iCloud+ Private Relay is part of the iCloud+ subscription, and is the iOS 15 privacy feature receiving the most attention so far. 

While Private Relay is not a VPN at a technical level, the concept of a VPN is a useful metaphor for the purposes of mobile marketing: Private Relay reroutes all Safari web traffic (and a limited amount of unsecured in-app traffic) via a series of proxy services to hide the requested URLs from ISPs and cloak the user’s IP address from websites.

What does Private Relay mean for mobile growth?

We’ll get into the long-term implications of Private Relay in the next section, but the immediate technical effect is pretty straightforward: IP addresses will become increasingly less precise for purposes like geolocation, fingerprinting, and household-level analytics data.

6. App Privacy Report

The App Privacy Report is a new section in the Privacy section of the iOS Settings app. It’s very similar to the Safari Privacy Report introduced last year, except for native apps instead of website traffic.

This report will highlight two things:

1. How often apps use the permissions they have been granted (e.g. accessing the location, camera, and microphone).
2. Which web domains apps send traffic to.

What does the App Privacy Report mean for mobile growth?

End users will be able to keep closer tabs on how apps they install are behaving, and which third-party services are being used behind the scenes. Better transparency is a win for both users and responsible app developers and marketers, who should have nothing to worry about.

7. Hide My Email

Hide My Email is part of the new iCloud+ subscription service. It allows users to easily generate single-use email addresses, which Apple will seamlessly forward to their real email address.

This is a natural extension of the (identically-named) Hide My Email component of the Sign in with Apple functionality introduced with iOS 13. With iOS 15, this option is now implemented more widely in additional areas of iOS.

What does Hide My Email mean for mobile growth?

Because a version of Hide My Email has been available via Sign in with Apple for the last two years, the main challenges are already well known: developers have to handle additional implementation complexity and user confusion. However, it was previously possible to avoid this by removing all third-party logins (Apple’s policy only required supporting Sign in with Apple if other third-party logins like Facebook or Google were also available).

Making the Hide My Email feature available in more places will likely increase the rate of these challenges, and it will no longer be possible for developers to completely side-step the issues by opting out of Sign in with Apple support.

Additionally, for brands leveraging identity solutions that incorporate hashed email addresses to track users, this change will likely impact match rates. However, the real-world impact will be more limited since these solutions were already subject to AppTrackingTransparency requirements beginning with iOS 14.5.

8. Mail Privacy Protection

Mail Privacy Protection is designed to disrupt tracking pixels in emails, which are traditionally used by marketers to track email open rates and reader demographic information like device type and geographic location.
Interrupting these pixels is not a new idea — many email apps offer this option today — but Apple’s implementation is unusual: instead of blocking the pixels outright by not loading them, Apple is going to use the Private Relay infrastructure to load all these pixels, all of the time.

What does Mail Privacy Protection mean for mobile growth?

This feature will be available for all iOS 15 users (no iCloud+ subscription required), and because of how widely-adopted the default Mail app is on iOS, the result will be a significant impact on metrics for email marketing campaigns — essentially, the open rate for iOS users will be 100%.

Marketers and Email Service Providers will need to find alternative ways to quantify the impact of their email campaigns, such as by focusing more on click-through-rates (which should be unaffected) or by excluding data for iOS users from reports.

9. IP masking with ITP

Apple has been iterating on Intelligent Tracking Prevention (ITP) in Safari for many years. The latest update will obscure the user’s IP address for requests to domains that ITP classifies as “trackers.”

This ITP functionality sounds similar to iCloud+ Private Relay (it is even implemented using the same selector in the iOS Setting App), and that’s no accident: it appears to use the Private Relay infrastructure to selectively relay only those requests going to a “tracker domain.” However, unlike the full Private Relay experience, IP masking via ITP is not part of the new iCloud+ subscription and will be available for all iOS 15 users.

What does IP masking with ITP mean for mobile growth?

This change represents a further tightening of the WebKit team’s long-running initiative to close off tracking vectors in Safari. ITP is already quite mature, which makes this more of an incremental update, but it’s still notable because privacy updates tend to roll out in Safari a year or so ahead of similar moves for mobile apps.

What do these updates tell us about Apple’s long-term strategy for iOS?

User privacy has been a long-term pillar of Apple’s market positioning, and this year’s changes indicate that they are doubling down even further. Apple is also reasserting the App Store’s position as the primary source of app discovery on iOS.

In other words, Apple is attempting to execute a transformational change around how end users interact with the digital ecosystem. If they’re successful, it will position iOS as the premium experience that costs more but comes with better privacy protections, in contrast to Android where more apps are free and supported by ads.

To make this reality, Apple is steadily expanding their strategy of reigning in potential “tracking” vectors on iOS, which started years ago with third-party web cookies, expanded to limitations on IDFA in iOS 14, and now includes protections for email and IP addresses in iOS 15.

Even though Private Relay is only for web traffic in this initial version, Apple has a well-established precedent of testing new privacy initiatives on web before then rolling them out for apps, too:

• ITP → ATT
• PCM → SKAN
• Safari Privacy Report → App Privacy Report

This means it’s quite possible — even likely — that Private Relay will be available for all iOS network traffic (including native apps) at some point in the future. In the meantime, Apple is already setting the precedent of opting specific types of traffic in as needed for all users.

What’s the latest on the iOS 14.6/ATT rollout, and how does that play in?

As of publication, iOS 14.5+ now comprises the majority of iOS traffic. This means that Apple’s AppTrackingTransparency policy is broadly in effect, and IDFAs are increasingly unavailable. However, while fingerprinting appears to clearly violate the ATT policy, many vendors are still supporting it as a relatively seamless fallback.

If Apple begins to enforce ATT’s restrictions on fingerprinting, it will close off this loophole while also triggering an endless game of cat and mouse between Apple and adtech vendors. Instead, iCloud+ Private Relay could indicate that Apple’s long-term plan is to focus more on technical solutions rather than policy enforcement.

That said, most observers still expect some form of policy enforcement will come — Apple has put an enormous amount of public messaging firepower behind AppTrackingTransparency, and it would compromise their efforts to not follow through against blatant violations of the rules.

What do all the iOS15 changes mean for apps that work with Branch?

Compared to last year’s IDFA changes, iOS 15 will most likely cause far less industry disruption. In fact, for marketers and developers who have been taking Apple’s messages seriously for the last couple years, there’s not really much that changes.

On the other hand, for anyone who is still trying to exploit workarounds to Apple’s privacy initiatives, the announcements from WWDC 2021 further decrease the wiggle room available.

At Branch, we’re fully aligned with Apple on the importance of protecting user privacy. We believe this opens the door to an exciting “ecosystem reset,” giving back the advantage to companies that perhaps always wanted to be a lot more respectful of user privacy, but felt caught in a competitive arms race against others who were willing to engage in excessive tracking more openly.

We know our customers rely on Branch to deliver products that live right on the messy front lines of mobile — in fact, that’s why most of our customers work with us. Our technical teams are actively testing all of the new announcements, and we’ll have more updates soon on steps that customers may need to take prior to the launch of iOS 15 this fall. In the meantime, you can rest assured that nothing introduced at WWDC 2021 will get in the way of us continuing to offer the very best mobile linking and measurement solutions.

The post WWDC 2021 and iOS 15: What Apple Announced and What Mobile Marketers and Product Managers Need To Know appeared first on Branch.

Yet, somehow, the music hasn’t stopped. What happened to the long-promised apocalypse?

We’ve been monitoring the data closely over the past few weeks, and there is a clear explanation for this unexpected period of calm. And unless Apple has changed its mind about the whole AppTrackingTransparency initiative, this calm is also not going to last forever.

Here are the four key things you need to know:

1. Adoption of iOS 14.5+ is still really low. That means ATT and its associated technical limitations only apply to a small fraction of iOS users so far (20.6% as of publication).

 

2. Apple hasn’t started enforcing the policy component of ATT yet. While Apple rejected a few app updates right after the launch of iOS 14.5, almost every example so far has been a case of helping developers align their ATT prompt implementation with the self-reported details on their app’s privacy “nutrition labels.” In other words, Apple has taken care of honest mistakes…but they haven’t yet begun auditing for real malfeasance.

3. The “ATT opt-in rates” we’re seeing don’t all mean the same thing, and are easy to misinterpret. Theoretically, these metrics should indicate how app users feel about “tracking.” In reality, the numbers floating around are so widely divergent (depending on the date and the source, they’ve ranged anywhere from 4% to 60%+) that it’s easy to find data to support almost any spin you want.

4. ATT opt-in rates are vanity metrics that do not reflect the true impact of ATT. Even if these metrics were more consistent, they’re at best a distraction. The only number that really matters is how often attribution is still available…and no one has been sharing that data (spoiler alert: until now — keep reading).

Let’s take a look at each of these to try and untangle the real story.

What is the iOS 14.5+ adoption rate, and why is it so low?

There are always two phases to the release of a new iOS version:

1. Apple makes the update available to users who know to go looking for it. These are the early adopters who follow the news and want to stay up to date with the latest and greatest.
2. Apple begins pushing out the update proactively. This is when the red dot shows up on the Settings app, but the new version is also proactively installed in the background for users who would never remember to update otherwise.

Apple generally doesn’t move past phase one until they’re really sure that the new release has no issues. In the case of iOS 14.5, there were a few ATT-related bugs in the initial version, and a pretty serious unrelated security issue with WebKit. Apple patched one of the ATT bugs and the security issue with iOS 14.5.1, but still held off pushing users to update from iOS 14.4.2.

Looking at past iOS 14.x releases, we can clearly see that iOS 14.5 and 14.5.1 never moved past the first phase. However, there’s a clear group of updates that took off after about a week, and iOS 14.6 is ripe to hit a similar inflection point any day now.

With ATT enforced, how many installs can be attributed via IDFA?

All of the ATT opt-in numbers floating around right now (which we’ll discuss in the next section) are for only one side: either the advertiser or the publisher app. But in order to use the IDFA for attribution, the user must consent via ATT on both ends.

To get an idea of the true impact of ATT, we need to compare the rate of installs attributed to ads on iOS 14.5+ with the baseline from previous iOS versions. This metric is the real deal — the elephant in the room that no one is talking about yet. And as you’d expect, it’s much lower:

As of writing, the rate of successful attributions is slightly above 6.5% of the pre-ATT baseline. This means that compared to how things used to be, device-level insights are now missing for 14 out of every 15 ad-driven installs.*

However, there are two important caveats to this:

• Apple Search Ads is a completely different ballgame. Because ASA uses its own AdServices API for attribution, it is exempt from ATT restrictions. In fact, the rate of device-level attributions for ASA is tracking slightly higher on iOS 14.5+ and has even grown a bit over the last few days.
• Several MMPs are violating the ATT policy by fingerprinting opted-out users. This means that much of the enormous gap created by missing IDFAs is hidden right now, but that won’t last once Apple starts enforcing the policy component of ATT.

* For the mathematically-inclined, this metric is calculated by taking a sample of apps known to be showing the ATT prompt and running ad campaigns, and then comparing the difference between the attribution rate (attributed installs / all installs) for versions of iOS < 14.5 and > 14.5. For example, if 10 out of every 100 installs are attributed on iOS < 14.5, and only 1 out of every 100 is attributed on iOS > 14.5, the metric would be 10% (indicating that data for the other 90% of ad-driven installs is now unavailable due to ATT).

How many users are opting in via ATT, and what does this data tell us?

While the attribution rate discussed above is the most important metric, the number of ATT opt-ins is also useful because it (theoretically) indicates how many users give consent to “tracking” when asked, and what overall end user sentiment is toward ATT.

In reality, there has been a lot of confusion about these numbers, and what they mean.

The next section will take a dive into the various public ATT opt-in metrics, how they’re being calculated, and why this leads to so many discrepancies. But this is a case where looking at the raw data is actually helpful too, so let’s begin with a few basic breakdowns of ATT data we see in Branch traffic:

This graph shows ATT status for users of apps showing the ATT modal (bottom) and apps not showing it (top). As a reminder, these are the definitions for each status, adapted from Apple’s documentation:

• authorized: The value returned if the user authorizes access to app-related data that can be used for tracking the user or the device. This includes access to the IDFA.
• denied: The value returned if the user denies authorization to access app-related data that can be used for tracking the user or the device. This value is returned when the user sees the ATT prompt and selects “Ask App Not to Track”, and also when the user opts out device-wide.
• notDetermined: The value returned if a user has not yet received a request to authorize access to app-related data that can be used for tracking the user or the device.
• restricted: The value returned if authorization to access app-related data that can be used for tracking the user or the device is restricted. Apple lists an array of situations for when the restricted status is expected, including child iCloud accounts, device management profiles or brand-new iCloud accounts.

Here is the same raw data for apps showing the ATT prompt, broken down by country of traffic origin and top app verticals:

 

Finally, here is a comparison of how widely implemented the ATT modal is across verticals:

 

What do the various “ATT opt-in rates” mean, and why are they all so different?

Here’s a quick explainer of top-line numbers getting most of the attention over the last few weeks.

ATT opt-in metric 1: Percentage of opted-in iOS user base.

 

• Where have you seen it? This is the top-line number being reported by major platforms, including the widely cited iOS 14.5 opt-in rate report by Flurry.
• What is the current range of numbers? Depending on the source and region, this opt-in rate has fluctuated between 12% and 25% thus far. Unfortunately, some of the early calculations of this metric incorrectly included data from apps that weren’t even showing the ATT prompt, leading to artificially low numbers that many privacy advocates – and most mainstream media articles – trumpeted as overwhelming evidence that users hate “tracking.” 
• How is it calculated? The equation is authorized / (denied + authorized), measured from active app users on the date in question. This means a user who interacts with 10 different apps on a given day will be included in the calculation 10 times, with each reflecting the user’s ATT status for that app.
• What does it mean and why is it useful? This metric reflects what you can think of as the live opt-in status of iOS users, meaning that it stays up to date as users opt in and out of ATT for individual apps over time. It helps to quantify how much AppTrackingTransparency is reducing the overall “tracking capacity” of iOS apps, compared to pre-ATT launch.
• What are the gotchas? This metric does not provide useful insight into how users are responding when presented with the ATT modal.

ATT opt-in metric 2: Percentage of users who select “Allow” when shown the prompt.

Source: AppsFlyer

• Where have you seen it? The broadest study of this metric appears to be coming from AppsFlyer. If you’ve heard any anecdotal reports from individual app developers, this is most likely the number that they are referencing.
• What is the current range of numbers? Because this metric is often being shared at the individual app level, it literally runs the gamut. Reports are floating around of opt-in rates that range anywhere between 1% and 60%. However, according to AppsFlyer‘s data, the global average is currently around 37%.
• How is it calculated? The equation is authorized / (denied + authorized), measured at the time the user interacts with the prompt. When the requestTrackingAuthorization() method is called to display the ATT prompt, a developer can immediately capture the ATT status after users make their selection. (If the user has disabled ATT at the device level, a status of “denied” is returned by default.)
• What does it mean and why is it useful? This is the number that most closely answers the question of how many users decide not to share their data after seeing the ATT prompt. That makes it useful for measuring user sentiment toward ATT, and the impact of the optimizations developers make to their ATT presentation.
• What are the gotchas? Unfortunately, this data is challenging to get at scale, because collecting the data requires some additional instrumentation work at the individual app level. And although it’s a helpful indication of user preferences toward tracking, it does not reflect the full impact of ATT on the app’s measurement capacity.

ATT opt-in metric 3: Percentage of ad impressions containing an IDFA.

• Where have you seen it? If you’ve come across opt-in rates that originated from an ad network (for example, in an article like this one from VideoWeek), this is the metric being cited.
• What is the current range of numbers? Depending on the ad network and region, the rate appears to range between about 15% and 30%. 
• How is it calculated? This is the number of individual ad impressions that contain an IDFA, which is only possible after the user has opted into ATT for the app that is showing the ad. A single app can generate multiple ad impressions for the same user, each of which will be included separately in the calculation.
• What does it mean, and why is it useful? Unlike the first two metrics, which are closely aligned to opt-in rates in advertiser apps, this metric almost exclusively reflects the publisher side of the equation. That makes it useful for apps looking to get an idea of what impact ATT will have on their monetization strategy.
• What are the gotchas? Since this metric can reflect opt-in data from multiple ad impressions per user session, it’s not an accurate way to demonstrate how many users select to not share their data when they see an ATT prompt.

While all of these opt-in metrics are interesting, they don’t tell the whole story for two reasons:

• There is a cohort of users with an ATT status of “restricted.” This status indicates that a user is not allowed to make ATT selections at all. Apple lists an array of situations for when the restricted status is expected, including child iCloud accounts, device management profiles or brand-new iCloud accounts.
• Users who have not seen the ATT prompt are de facto the same as opted-out. Whether this is due to the app developer choosing not to implement ATT, or simply delaying the presentation of it for optimization purposes, users who have not seen the prompt cannot be “tracked” for as long as this is the case.

Because of these last two points, any rate calculated with the equation of authorized / (authorized + denied) might help us understand user sentiment toward ATT but doesn’t tell the whole story of how it’s impacting mobile marketing overall.

A more insightful metric — and the one we’ve been recommending to Branch customers who want to understand the true opt-in rate — is a “tracking allowed” rate calculated as authorized / (authorized + denied + restricted + not_determined).

We’ve been looking at this rate from Branch data, and it’s obviously somewhat lower than the other metrics…but still high enough to raise doubts about the media narrative that “all users hate tracking,” and continuing to grow gradually as more users see the ATT prompt over time.

What other rates are useful, and what do they tell us?

The restricted rate (users who cannot be shown the ATT prompt for various Apple-defined reasons) was artificially high for the first few weeks, presumably due to a bug on Apple’s end. It abruptly on May 18, suggesting that Apple finally fixed this issue:

The device-wide opt-out rate indicates how many users have enabled the device-level ATT toggle. This is calculated by looking at the rate of denied statuses for apps that are not showing the ATT prompt. It’s decreased slightly over the past few weeks, perhaps reflecting the preferences of users who update quickly.

What happens next?

There are a few key inflection points to watch for over the next few weeks:

• When will Apple start pushing the iOS 14.6 (or 14.7) version to a broader audience? They’ve clearly been slow-rolling this update so far, but that can’t last forever.
• When will Apple begin truly enforcing the ATT policy? Right now, several MMPs are providing fingerprinting-based workarounds, which is leading to a false sense of security among many advertisers and ad networks, and some doubts about whether Apple is actually serious about this initiative.
• What will Apple announce at WWDC 2021? Though it seems incredible to think about this, the announcement of iOS 15 is less than a week away. If Apple doubles down on additional privacy-related OS changes, it will be a good indication that they’re in this for the long haul.

Ultimately, one thing is clear: obsessing over these data points doesn’t change the reality that Apple has used AppTrackingTransparency to fundamentally shift the narrative around mobile user privacy: IDFA-based, device-level attribution data is now far scarcer. SKAdNetwork will help fill the gap, but going forward, app marketers will need to find new ways to drive growth and measure results. Branch is here to help.

The post Attribution After iOS 14.5: What Does the Data Tell Us About Why the Apocalypse is So Quiet? appeared first on Branch.

If you prefer, we also have a video walkthrough of this material.

Let’s begin by clarifying the overall impact of what we’re discussing today:

On the left, we have an example of your Branch attribution data up until now: a single, combined dataset, with conversion credit deduplicated across all channels. Like any attribution system, there will always be a bucket of “unknown” conversions. This bucket is also sometimes called “organic” or “unattributed”, but all of these terms mean the same thing: conversions the system did not attribute back to a marketing campaign.

On the right, we show what your Branch data will look like after Apple’s new iOS 14 privacy policy is enforced: in that single combined report you’re used to seeing, all of the conversions previously attributed to the Ads channel will now appear as “unknown”. And there will be a separate pool of attribution data for your ads, provided via Apple’s new SKAdNetwork framework.

Due to the way Apple designed SKAdNetwork, this ads data is only available for some of the common ad campaign types currently used today. It is not device-level data, which means it’s far less granular than you’re used to, and it cannot be deduplicated against any other marketing channel.

Fortunately, there is a way to win back some of that granular, device-level ads data within the combined, de-duplicated report: you can get your users to opt in via Apple’s new AppTrackingTransparency framework:

It’s worth getting something clear right up front: there is no silver bullet solution that will make things continue working the way they always did in the past. Everyone in the ecosystem — from MMPs to ad networks to publishers to advertisers like you — has to figure out how to deal with Apple’s changes.

Ad attribution on iOS will be far more complex after the release of iOS 14.5. The Branch product improvements we cover in this post are designed to help with this, but it is impossible to keep things the way they were.

How will your Branch data change?

Let’s start with a simple flowchart that explains which Branch customers will experience these changes: 

If you are using Branch for ads attribution and you’re planning to show the ATT prompt to your users, these product changes affect you.

Why does Branch need to make these updates? The core issue is that the ATT opt-in process causes a chronology problem. Here is a typical user conversion journey: click an ad, download the app from the App Store, and open the app. Easy so far.

The problem is what happens next: once the app opens for the first time, the Branch SDK fires and install attribution needs to happen…however, you have not yet had a chance to show the ATT modal to the user:

This is the chronology problem: until you get permission via the modal (likely sometime later, after the initial app open), you don’t get the IDFA nor will you have permission to attribute the ad conversion at the device level.

The analytics product changes that Branch is making are designed to help recover ad attribution for installs in this flow. The solution we’ve built needed to reflect a few important requirements, which are worth explaining:

1. The new behavior must fully comply with Apple’s ATT policy. We’ve heard that some other MMPs are planning to “cheat” behind the scenes with probabilistic matching, even without securing user opt-ins via the ATT prompt. We believe Apple intends to crack down on this sort of behavior, and we’re serious about protecting our customers from being banned from the App Store for policy violations.
2. Branch must not “rewrite history” by changing events that have already been reported. Retroactive data updates would cause problems and make your workflows far more complex.
3. The Branch SDK still needs to fire on initial app open. This is necessary for deep linking and attribution of owned and organic channels, both of which are unaffected by Apple’s ATT policy.

You might be looking at all those new complications and thinking “is trying to get my users to opt-in with the ATT modal even worth it?”

Branch’s advice is yes, in most cases it is worth it. The changes that Apple is making will decrease the level of insight you have into your ads attribution. That is unavoidable, and an unpleasant reality that every single advertiser in the mobile ecosystem needs to deal with.

However, the choice you can still make is between having some data, or no data at all. And even a limited amount of device-level insight will still allow you to make better decisions about things like campaign optimization and LTV.

Examples of the new data flow

Here are the changes we’re making in a nutshell.

First, what we ARE doing:

• We are tracking an additional analytics event we call a “second install.” These second install events are processed the same way as a normal install, and come with data parameters to allow deduplication. Second installs will be triggered for ad-driven installs, after we see user opt-in via ATT. This change will happen automatically for all Branch iOS SDK versions, and no SDK update is necessary.
• Also, while not required, you may update to iOS SDK v1.39.2+ to capture ATT opt-ins and opt-outs as new, dedicated events, and report ATT status on all events.

Now, what we are NOT doing:

• We are not doing any form of device-level attribution for ad-driven installs if the user does not opt in via ATT. Again, this is to make sure that we adhere to Apple’s policy and protect you.
• We are also not re-writing any log-level data on the initial install event after the user opts in. This is to provide simplicity and predictability for your data workflows.
• Finally, we are not triggering “second installs” for opt-ins from non-paid sources, because in those cases we are already able to attribute at a device level without ATT opt-in.

The best way to understand how all of this works is with some hands-on examples that demonstrate what your Branch data will look like for users on iOS 14.5 and above.

Immediate opt-in

The first example flow is the simplest one: when a user clicks an ad link, installs your app, and opts in via ATT immediately after installing.

This flow assumes that the user has already opted in to ATT in the publisher app, which is necessary to make the IDFA available on the first side of the transaction:

Because the user previously opted in, their ad clicks in the publisher app will include IDFAs:

Next, the user installs your app. This install event cannot be credited to the ad click, because the user has not opted in via ATT, which means the attribution data will be ‘incomplete’, and reported as unattributed:

In this scenario, the user opts in to ATT immediately after the install happens, before any other in-app activity. The opt-in triggers the ‘second install’ that can be credited back to the ad click:

When the user then performs a down-funnel conversion event, such as a purchase, that conversion can also be attributed back to the ad click:

Now, let’s imagine the user subsequently clicks another Branch link, such as an email link. It’s worth pointing out that in this case, even though the user has already opted in via the ATT prompt, it’s technically not necessary under Apple’s policy because your emails are an owned channel:

As expected, any conversion events that occur after this email click will be attributed to the email campaign instead of the ad click. This is unchanged from pre-iOS 14 behavior:

To summarize, in this scenario the initial install event will be reported as unattributed or organic. The “second install”, triggered when the user opts in via ATT, will be correctly attributed to the ad click.

Conversion events like purchases will be attributed to the ad click, up until another qualifying link click occurs, after which they will be attributed to that subsequent event as expected:

Delayed opt-in

Now, let’s look at a slightly more complex example. In this scenario, the user clicks an ad, installs, but does not opt in via ATT until some time has passed after the install. This could happen if you decide to delay presenting the ATT prompt until after you’ve had a chance to demonstrate value to the user, in order to increase the chance that they will accept.

As before, this flow assumes that the user has already opted in to ATT in the publisher app, making the IDFA available on the first side of the transaction:

Because the user previously opted in, their ad clicks in the publisher app will include IDFAs:

However, in this scenario, the user does not opt in via ATT right away. This means that the user’s early down-funnel conversion events will also be reported as unattributed:

When the user eventually does opt in, the ‘second install’ is triggered and will be credited back to the ad click:

After opt-in, subsequent conversion events will also be correctly attributed back to the ad click:

To summarize, in this scenario the initial install event will be reported as unattributed. And until the user opts in via ATT, conversion events will ALSO be unattributed.

Once the user opts in, a second install will be triggered and correctly attributed to the ad click. Later conversion events will also be correctly attributed to the ad click.

Branch product changes

Now that we’ve looked at some example user flows, let’s go through how we’re updating various parts of the Branch platform to reflect this raw data.

The changes we’re making fall into two broad categories:

Pre-aggregated reports Because this data is generated at the time of view or request, Branch can dynamically “fix” the data as users gradually opt in after install. These products include:

• The Branch dashboard.
• Query API.

Raw data products. These provide log-level event data, which Branch will not retroactively rewrite. However, depending on your use case, you can choose to perform your own deduplication process. We’ll describe the logic to do that later in this post. Our raw data products include:

• Webhooks.
• Ad network postbacks.
• Custom export API.
• Data Integrations.

The Branch dashboard and Query API “just work”

The good news is if you, like many of our customers, primarily rely on the Branch dashboard and our Query API, those will both “just work” without any additional steps from you.

This means we’ll automatically deduplicate the first and second install events, so that the final numbers you see stay accurate as users opt in:

We automatically deduplicate Second Install events that occur up to 7 days after initial Install. Second installs that occur beyond this window are not deduplicated.

As a reminder, if a paid ads-driven user never opts in, then they will not have a Second Install. As such, we will not be able to remove them from the unattributed data.

The “organic checkbox”

There is one other feature of the Branch dashboard that deserves a special mention: the “organic checkbox.”

By default, most reports on the Branch dashboard show only attributed data. This makes sense, because if you’re looking at a report for something such as ad campaign performance, you usually want to see only conversions attributed to ad campaigns.

In the past, when the Organic checkbox was checked, the report would show a separate segment for unattributed (or ‘organic’) conversions:

This won’t work as expected after iOS 14.5, because that unattributed segment will also include paid ad conversions that have not yet been completed by the user opting in to ATT:

This means the Organic checkbox simply won’t be useful in as many reports, so we are removing it from some dashboard pages to avoid confusion.

Locations where the Organic checkbox will be removed include:

• Summary page
  • Journeys tab
  • Quick Links tab
  • Universal Email tab
• Journeys → Activity tab
• Email → Activity tab

Locations where the Organic checkbox will still be available include:

• Summary page
  • All Data tab
  • Universal Ads tab
• Ads Analytics → Activity tab

Most customers used the Organic checkbox as a way to compare their campaign performance against a non-campaign baseline.

As an alternative, we’ll be adding a new checkbox to dashboard reports called “Show Total App Traffic”. This will display an additional segment in the report for all traffic (both attributed and unattributed), which will provide a similar baseline for performance comparisons.

Raw data products

With these changes, there are a few data schema updates to be aware of:

First and Second Install events are both reported as installs, and there are two new fields on each event: user_data_opted_in, and days_from_install_to_opt_in. 

The user_data_opted_in field reflects the user’s ATT opt-in status, which means it is false for the first install and true for the second. The days_from_install_to_opt_in field gives you the number of days between the first and second Install events.

The timestamp field reflects the time each event occurred (for the first install, this is when the install itself arrived in our system, and for the second install, this is when the user’s opt in arrived). Additionally, on the second install, the event_timestamp field reflects the date that the corresponding first install originally happened.

This table shows the expected behavior for an ad-driven install, broken down by Branch product:

What do you need to DO?

If you only use the Branch dashboard, things are pretty simple: you don’t need to do anything except be aware that your report data may change slightly day-to-day as more users opt in to tracking inside your app

If you use the Query API to pull pre-aggregated data, you should recognize that your report may reflect incomplete attribution data if users have not yet opted in at the time you make the query. To solve for this, you should re-pull data from previous days if users might have opted in after your initial request.

For example: if it’s April 15 and you call the Query API for April 1 through 14, but your app might show the ATT prompt to users up to 6 days after installing, we suggest pulling the data again on April 21 so have you “final” numbers.

If you use the custom export API, you’ll need to be aware that if we return a record for a Second Install, there will already be an incomplete (meaning, unattributed or “organic”) initial Install for that same user somewhere in your data. You can use the deduplication logic discussed below to accommodate this.

You should also continue to pull data within seven days of install. This is because Branch hashes device identifiers in raw data after 7 days.

If you use webhooks, we recommend including the IDFV field in your webhook body, because IDFAs will not always be available. Optionally, you can also implement the deduplication logic discussed below.

For ad partner postbacks and data integrations, no changes are needed if configured to send only attributed events. If configured to send all events, you’ll want to work with the partner to determine the preferred path forward.

If you want to capture ATT opt-ins and opt-outs as separate analytics events, update your Branch iOS SDK integration to v1.4 or above. If you don’t want to measure these dedicated analytics events and only need “second install” tracking, no SDK update is required at this time.

How to deduplicate first and second installs

The Branch dashboard and Query API will continue to provide accurate reporting by automatically de-duplicating these events, however, you may want to make updates to your systems if you use any of our raw data products (including webhooks, Data Integrations, the Custom Export API, or ad network postbacks configured to send all events instead of just attributed installs).

To do so, you should reference the IDFV in your API pull or webhook body which you can use to overwrite the unattributed Install with the corresponding Second Install.

Optionally, you can also use the IDFV to reassign any down-funnel events that occurred between the initial Install and Second Install.

Summary

We recognize there is a lot to process when it comes to iOS 14 and Apple’s new privacy policies. The Branch team is here to help — please reach out to your Branch contact or our support team with any questions!

The post Branch Ads Analytics Changes for iOS 14.5 appeared first on Branch.