We’re excited to now include our ads measurement (MMP) product, also completely free, to new apps under 10K MAU. Because this is an essential part of growing your business, we also now include the MMP product as part of the core package for apps over 10K MAU.

Before Branch, our founders struggled to promote their own app. From those struggles, they started Branch. The success we’ve had since then shows how valuable this technology is to the app community. Branch can help your app grow — we’ve seen it a hundred thousand times!

Announcing a change to 10K MAU overages

As more of our customers become dependent on paid marketing as a channel, and we have invested more in our ads measurement tooling to support you, the cost to support Branch links has grown. To date, we’ve largely ignored the overages when customers have exceeded the 10K MAU limit. You’ll see some changes in the dashboard over the next couple months as we look to tighten this up.

We’re committed to supporting you, and giving you the flexibility you need to grow your business. You can always reach out to discuss more flexible options via our sales team.

What does this mean?

Today

After a 30-day trial, new customers and new apps signing up for the Branch self-serve platform get both linking and ads for free under 10K MAU. They are also required to add a credit card.

Coming soon

Current Branch self-serve customers will see the same changes. Ads will be available as part of the self-serve platform, and a credit card will be required after a 60-day grace period. We’ll also have in-dashboard, daily MAU tracking so no one is surprised by a bill for their app’s success.

In either case, the Branch platform will still be completely free for apps with less than 10K MAU. Pricing for apps over 10K MAU is simple: $5 per 1K MAU charged to the card on file. Larger apps can work with our sales team for a contract with invoice-based billing.

Our commitment to developers, growth marketers, and the broader app ecosystem has not changed. We’re excited to continue helping apps grow and expand the ways new apps can find and engage customers — with ads and linking included from the start.

The post Our Commitment To Growing the App Ecosystem appeared first on Branch.

Opening an installed app from a browser is known as “deep linking,” and with this guide you’ll learn how to deep link into your Android app from the mobile web. We’ll focus exclusively on how to trigger an app open from a website page, rather than from the click of a link inside other apps. 

Android is, by far, one of the most fragmented platforms that developers have ever had to manage, due to Google’s decision to force device manufacturers to be responsible for porting the OS, which requires backwards compatibility and support of a multitude of devices. In this ecosystem, we, the app developers, are left to pick up the pieces. Deep linking on Android is unfortunately no different— over the years, we’ve seen a plethora of technical requirements that must be used depending on the circumstance and context of the user.

Note that Branch will implement all of this complexity for you, host the deep links, and even give you robust analytics behind clicks, app opens, and down funnel events. You can play around with Branch links for free by signing up here. We highly recommend using our tools instead of trying to rebuild them from scratch, since building deep links is incredibly complicated. 

Overview of Android App Links

Android App Links are Android’s solution to take users to specific in-app content. They allow your users to bypass the disambiguation dialogue where they select if they want to see content on the mobile web or in the app, such as in the following image:

App Links use HTTP and HTTPS URLs associated with your website domain, and allow a specific app to be the default owner of a given type of link. This ensures that no other app can use your links for deep linking. Note that with App Links, users who do not have your app installed will be taken to your mobile website. Therefore, for the best user experience, configure your mobile website to handle your App Link to prevent users from viewing a 404 page.

Steps to Create Android App Links:

1. Create intent filters for incoming links, and define values in your manifest

To link to your app content, create an intent filter with the following elements and attribute values to be used in your Activity tag within your manifest:  

• <action>: To specify the VIEW intent action so that the intent filter can be reached from Google Search or other web link clicks.
• <data> : The <data> tag must include the android:scheme attribute. The data tags represent a URI format that resolves to the activity.
• BROWSABLE category: required in order for the intent filter to be accessible from a web browser. Without it, clicking a link in a browser cannot route users to your app. 
• DEFAULT category: to allow your app to respond to implicit intents. 

Here’s an example of an intent filter within a manifest for deep linking, using the URI “https://www.example.com/gizmos” : 

<intent-filter 

    android:autoVerify="true"        

    android_label="@string/filter_view_http_gizmos">

        <action android_name="android.intent.action.VIEW" />

        <category android_name="android.intent.category.DEFAULT" />

        <category android_name="android.intent.category.BROWSABLE" />

        <!-- Accepts URIs that begin with "https://www.example.com/gizmos” -->

        <data android_scheme="https"

              android_host="www.example.com"

              android_pathPrefix="/gizmos" />

        <!-- note that the leading "/" is required for pathPrefix-->

Note that you can use http but then add the network configuration XML file with cleartextTrafficPermitted=true. More information here. Also, note that cleartext information transmitted is not encrypted and is not secure. 

Adding intent filters with URIs for activity content to your app manifest allows Android to route any Intent that has matching URIs to your app.

2. Read data from incoming intents

Use data from your intent to determine the content to show your users. Call the getData() and getAction() methods to retrieve the data and action associated with the incoming intent. 

Here’s a code snippet showing how to retrieve data from an intent in Java:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

    Intent intent = getIntent();
    String action = intent.getAction();
    Uri data = intent.getData();
}

Or in Kotlin:

override fun onCreate(savedInstanceState: Bundle?) {

   super.onCreate(savedInstanceState)

   setContentView(R.layout.main)


   val intent: Intent = intent

   val action: String? = intent.action

   val data: Uri? = intent.data

}

3. Verify ownership of your app and website

As of January 2023, the Google Play Store is requiring all new apps and updates to target at minimum Android 12, or API level 31. Starting with Android 12, you must verify ownership of both your app and your website in order to deep link your users to your app content. Follow these steps:

Request automatic app link verification in your manifest. 

This will ask the Android system to verify that your app belongs to the URL domain used in your intent filters.

Setting android_autoVerify=”true” declares your app to be the default handler for a type of link for any one of the web URL intent filters in your app manifest that include the android.intent.action.VIEW intent action and android.intent.category.BROWSABLE intent category.

Declare the relationship between your website and your intent filters 

To indicate the Android apps associated with your website and app URL intents, start by publishing a Digital Asset Links JSON file at https://domain.name/.well-known/assetlinks.json.

You’ll need the following information to publish the Digital Asset Links JSON file: 

• namespace: This value is “android_app”
• package_name: The application ID declared in the app’s build.gradle file.
• sha256_cert_fingerprints: The SHA256 fingerprints of your app’s signing certificate. You can use the following command to generate the fingerprint via the Java keytool:

$ keytool -list -v -keystore my-release-key.keystore

Here’s an example:

https://branchster.app.link/.well-known/assetlinks.json

Make sure that your assetlinks.json file is:

• served with content-type application/json.
• accessible over an HTTPS connection, regardless of whether your app’s intent filters declare HTTPS as the data scheme.
• accessible without any redirects (no 301 or 302 redirects) and accessible by bots (your robots.txt must allow crawling /.well-known/assetlinks.json).
• published on each domain if your app links supports multiple host domains

Finally, confirm that the Digital Asset Links JSON file is properly hosted and defined by using the Digital Asset Links API.

4. Test URL Intents

After verifying the websites associated with your app and ensuring that the hosted JSON file is valid, install the app on your device. Wait at least 20 seconds for the asynchronous verification process to complete. Use the following command to check whether the system verified your app and set the correct link handling policies:

adb shell am start -a android.intent.action.VIEW 
    -c android.intent.category.BROWSABLE 
    -d "https://domain.name:optional_port"

The adb tool will launch an implicit intent android.intent.action.VIEW with the category BROWSABLE and data being your website URL you’ve configured.

You can also review a list of the links handled by all your apps with the following command: 

adb shell dumpsys package domain-preferred-apps

You’ll see in the output all the linking behaviors for apps. Ensure that your app is set to always open on a link click.

“Package: your.app.package

Domains: your.domain.com

Status: always : 20000000c

The hexadecimal value is the Android system’s record for app linking behavior. 

And you’re done! That being said, deep linking on Android is incredibly complicated, and there are edge cases everywhere. You’ll think everything is going well until you come across unique edge cases and broken links. That’s why you should use a tool like Branch — to save you from that nightmare and ensure that your links work everywhere. Contact us to discover how you can implement deep links that transform your user experience, reduce churn, and increase ROI.

The post How to Open an Android App from the Browser appeared first on Branch.

Branch’s mission to break down the walled gardens and help brands grow on mobile is more important than ever. We’ve made tremendous progress with over 400B links created, that help billions of users to easily get to the content they want in the apps they love, every day. Despite how impactful Branch has been, we continue to look forward, and we see so much opportunity to help build better customer connections.

As we consider the future, the first place we look is to you, our customers and partners. Over the course of the last year, we’ve asked you to fill out over four different surveys to better understand how we can better support you. The message was clear: better customer consulting and more dedicated technical support.

With this in mind, we’re going to be revamping Branch’s customer relationship organization, with an eye towards more dedicated technical support and consulting. We’re introducing the concept of the “technical account manager” to Branch and they will be able to guide you through the tumultuous changes happening in the mobile ecosystem today. 

Additionally, we’re investing heavily in our technical services offerings. We’ve found that sometimes you might need much more involved support, with an expert who can deeply embed with your team to ensure successful project execution. You’ll be hearing much more about the opportunities for this level of service over the next year.

Lastly, outside of the human touch, we understand the importance of self-service and scalable software. We’ve grown our software development organization dramatically with an eye towards staying ahead of the constant change in the ecosystem and arming you with the right tools to adapt to the change. We’re also tripling our investment in our teams dedicated to customer education and documentation.

We’re confident that this is the right model to ensure you stay up to date, both with knowledge and technology.

That said, part of this change is a restructuring that forces us to part ways with some of the fantastic team members who helped bring Branch to where we are today. These are loyal, caring, and hardworking individuals that we were unable to find places for in the new structure. We thank them for their contribution and are doing everything we can to help them with a smooth transition to their next role.

I’m more excited than ever about the things we will do together in 2023. Ecosystem change brings opportunity, and Branch is well capitalized and now better structured to help you capture it. Let’s tear down those walls.

The post Redefining Our Customer-focused Approach to Better Serve Our Customers and Community appeared first on Branch.

At Branch, we eat, breathe and sleep mobile deep linking. We created a single link that you can use everywhere: every platform, every device and every app store to drive users to your app. It’s a single link, fully configured to link to your app off of every channel (Facebook, Twitter, Gmail, etc) and be listed in every search portal (Firebase App Indexing, Bing search, Apple Spotlight).

It just works. In fact, we’ve already written blog posts about How to Set Up Google App Indexing and How to Deep Link on Facebook, check them out.

When Apple announced “Universal Links” in its WWDC pitch back in 2015, we were excited to incorporate it into the Branch deep linking platform. Little did we know how complicated it would be to get it working, so we thought we’d share a guide on how to do it in order to save everyone else.

How Do Universal Links Work in iOS?

Before Universal Links, the primary mechanism to open up an app when it was installed was by trying to redirect to an app’s URI scheme in Safari. This put the routing logic in Safari, but there was no way to check if the app was installed or not. This meant that developers would try to call the URI scheme 100% of the time, in the off chance that the app was installed, then fallback gracefully to the App Store when not by using a timer.

Universal Links were intended to fix this. Instead of opening up Safari first when a link is clicked, iOS will check if a Universal Link has been registered for the domain associated with the link, then check if the corresponding app is installed. If the app is currently installed, it will be opened. If it’s not, Safari will open and the http(s):// link will load.

Functionally, it allows you to have a single link that will either open your app or open your mobile site.

Branch’s deep links support Universal Links, but also offer capabilities that Universal Links don’t. For example, when a user who doesn’t have an app installed clicks on a Branch link, they’ll be redirected to the App Store, where they can download the app in question. After they do, they’ll be taken to the exact link they had clicked, in the app. This process is called deferred deep linking.

How Have Things Changed in iOS 15?

With the introduction of iOS 15, Apple has unveiled a new feature called Private Relay. Private Relay works to mask iCloud+ subscribers’ IP addresses, which are often used to bridge the gap through the App Store. This makes deferred deep linking through install more difficult on iOS. 

Branch has an innovative solution for this  with our NativeLink technology, which eliminates the need for IP addresses – or any other sort of personally identifiable data — during the deferred deep linking process. NativeLink works by copying the initial destination to the user’s clipboard, and once the app is installed, NativeLink pastes the URL and brings the user directly to the content to which they were initially headed. Therefore, brands that leverage NativeLink are able to provide a seamless user experience even with the launch of Private Relay.

Click here to learn how to start implementing NativeLink, and check out our video to learn how NativeLink works.

Universal Link Integration Guide

Here are the high-level steps to get Universal Links working for your app:

1. Configure your app to register approved domains

1. Register your app at developer.apple.com.
2. Enable Associated Domains on your app identifier.
3. Enable Associated Domains on your Xcode project.
4. Add the proper domain entitlement.
5. Make sure the entitlements file is included at build.

If you use Branch, you can stop here. Otherwise, continue to section two.

2. Configure your website to host the apple-app-site-association file

1. Buy a domain name or pick from your existing.
2. Acquire SSL certification for the domain name.
3. Create structured apple-app-site-association JSON file.
4. Sign the JSON file with the SSL certification.
5. Configure the file server.

If you use the Branch hosted deep links, we’ll save you all of the complexity of creating SSL certs and signing and hosting your server’s JSON file, so you only need to modify your app’s code to leverage it. We’ll introduce this at the bottom of the post.

Note: We’ve also built a tool to check if your apple-app-site-association file is configured properly.

Section 1: Configuring your app entitlements

Note: newer versions of Xcode can typically handle entitlement provisioning for you automatically. You can most likely skip to the Enable Associated Domains in your Xcode project section below, and refer back to these instructions only if you encounter problems.

In order to register your Xcode project for Universal Links, you need to create an App ID in the Apple developer portal and enable the proper entitlements. This is very similar to the configuration required for in-app purchases.

You cannot use a wildcard app identifier for Universal Links.

Register your app on developers.apple.com

First, head to developer.apple.com and log in. Then click on Certificates, Identifiers & Profiles, and then click on Identifiers.

If you don’t have a registered App Identifier already, you’ll need to create one by clicking the + sign. If you do have one, skip ahead to the next section.

You need to fill out two fields here: name and bundle ID. For name, you basically enter whatever you want. For bundle ID, you’ll fill in the value of the bundle

You can retrieve this by looking at the General tab of your Xcode project for the proper build target.

Enable Associated Domains in your app identifier on developers.apple.com

For your pre-existing or work-in-progress App Identifier, scroll down to the last section and check the Associated Domains services.

Scroll down and click Save.

Enable Associated Domains in your Xcode project

Now, you’ll want to enable the Associated Domains entitlement within your Xcode project. First, make sure that your Xcode project has the same Team selected as where you just registered your App Identifier. Then go to the Capabilities tab of your project file.

Scroll down and enable Associated Domains so that the accordion expands.

If you see an error like this, check:

1. That you have the right team selected.
2. Your Bundle Identifier of your Xcode project matches the one used to register the App Identifier.

Add the domain entitlement

In the domains section, add the appropriate domain tag. You must prefix it with applinks:. In this case, you can see we added applinks:yourdomain.com.

Make sure the entitlements file is included at build

Lastly, for some reason, Xcode 7 did not include my entitlements file in my build. In the project browser, make sure that your new entitlements file is selected for membership to the right targets so that it’s built.

If you use Branch links, you can stop here! If not, keep reading to learn more, or request a Branch demo.

If you want to save yourself hours of headache, you can avoid all the JSON hosting and SSL cert work and just use Branch links to host it for you. However, if you’re a control freak and glutton for punishment, by all means continue.

Section 2: Configuring your apple-app-site-association file

Universal Links turn your website URL into an app link, so you need be running a web server in order to leverage them. To help with this process, use our Universal Links Validator to check if your apple-app-site-association file is configured properly.

Pick a domain

First, identify the domain that you’d like to use for your Universal Links. You can register a new one or use an existing. If registering a new one, we prefer to use a clean, non-spammy registrar like gandi.net.

Acquire SSL certification

You need to acquire SSL certification files for the domain you’ll use to host the Universal Links. In order to do this, you’ll need to use a third party service to register your domain for SSL, and create the files you need. After looking around, we’ve chosen Digicert to handle branch.io and associated subdomains.

Here are the steps to create your SSL certification:

1. Visit https://www.digicert.com/easy-csr/openssl.htm and fill out the form at the top to generate an openSSL command. Keep this window open.
2. Log into your remote server.
3. Execute the openSSL command to generate a certificate signing request (.csr) and certification file (.cert).
4. Pay for your SSL certification at https://www.digicert.com/.
5. Wait for Digicert to approve and send you the final files.
6. In the end, move yourdomain.com.cert, yourdomain.com.key and digicertintermediate.cert into the same directory on your remote server.

Create your apple-app-site-association JSON

There is a pretty standard structure of this JSON file, so you can basically just copy this version and edit it to fit your needs. I’ll break down where to get the correct values below.

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "T5TQ36Q2SQ.com.branch.sdk.TestBed",
        "paths": ["*"]
      }
    ]
  }
}

The only fields you need to change are associated with: T5TQ36Q2SQ.com.branch.sdk.TestBed. This is actually two values joined together with a period. Both values are found on developers.apple.com in the Identifiers -> App IDs section. Just click on the corresponding registered App ID as shown below.

In this example, connect the Prefix and the ID together with a period so that it looks like so: T5TQ36Q2SQ.com.branch.sdk.TestBed.

Save this JSON file as apple-app-site-association-unsigned.

Sign the JSON file with your SSL certificates

Note: if you have certified your domain as HTTPS, you can skip this step and send the JSON in plaintext, as explained in Apple’s updated requirements:

If your app runs in iOS 9 or later and you use HTTPS to serve the apple-app-site-association file, you can create a plain text file that uses the application/json MIME type and you don’t need to sign it. If you support Handoff and Shared Web Credentials in iOS 8, you still need to sign the file as described in Shared Web Credentials Reference.

All apple-app-site-association files on the Branch platform are now served as unsigned application/json.

Upload the apple-app-site-association-unsigned file to your server into the same directory as the certification and key files from the previous steps. Using the command line, change directory into that folder and issue the following command:

cat apple-app-site-association-unsigned | openssl smime -sign -inkey yourdomain.com.key -signer yourdomain.com.cert -certfile digicertintermediate.cert -noattr -nodetach -outform DER > apple-app-site-association

This will generate the file apple-app-site-association.

Configure your file server

Alright! So you have your signed apple-app-site-association file. Now you just need to configure your file server to host this for you. There are a few caveats:

1. It must be sent with the header application/pkcs7-mime (or application/json, as noted above).
2. It must be sent from the endpoint youdomain.com/apple-app-site-association, and/or youdomain.com/.well-known/apple-app-site-association.
3. It must return a 200 http code.

We set up the one for all Branch integrated apps using our Node+Express link servers. Here’s the code we used, in case that’s helpful:

var aasa = fs.readFileSync(__dirname + '/static/apple-app-site-association');
app.get('/apple-app-site-association', function(req, res, next) {
     res.set('Content-Type', 'application/json');
     res.status(200).send(aasa);
});

Branch and Universal Links Integration Guide

Again, as a reminder, you can avoid all the JSON hosting and SSL cert work and just use Branch. Happy Linking!

The post How to Set Up Universal Links to Deep Link on Apple iOS appeared first on Branch.

It has been well known for many years that users prefer native mobile apps to mobile websites. However, deep linking to and from apps is still not as robust as it should be compared to the web. Because of that, mobile websites are still a prominent part of mobile phone usage, especially for discovering new apps.

For example, imagine an existing user shares an article from your mobile app to Facebook, and a number of new visitors click on that article. If your links are taking those visitors to the App Store page for your app, instead of showing them the article, that’s a lot of disgruntled users who lose interest and return to Facebook. This is where a mobile site with a Smart App Banner can come into play.

In this post, we’ll describe the various smart app banner options available on iOS and Android, including how to create fully customized smart banners using Branch Journeys. 

What Is A Smart App Banner?

A mobile smart banner uses a fraction of the screen on a mobile website to inform and encourage users to open the native app, or to install it if they don’t have it. It’s a smart link that includes all the routing logic needed to automatically open up the app when it’s installed, or fall back to an App Store page if not.

What Does Apple’s iOS Smart App Banner Do?

In iOS 6, Apple released a smart app banner for Safari. Its look and feel has evolved since then, but it still functions the same way.

Apple’s banner does have some unique characteristics that other 3rd party smart banners cannot easily replicate:

• The call to action “View” will always change to “Open” when iOS detects that the app is installed.
• While downloading the app, the smart banner will show a progress bar.

It also comes with some significant limitations:

• It only works on iOS Safari.
• The layout, color, and contents cannot be changed.
• No click or download attribution.
• Deep linking (taking users to specific content) only works if the app is already installed. In other words, deferred deep linking is not supported.

Implementing Smart App Banners on iOS

If you want to use the basic Safari smart banner, all you need to do is include the following meta tag in the HTML head of your web page:

 <meta name="apple-itunes-app" content="app-id=myAppStoreID, app-argument=myURL"> 

Your app argument allows you to associate your app and the intended in-app destination with the corresponding webpage on your site. This association passes the destination, along with other information (for example whether the user is logged in) on to the app.

To learn more about the default Safari banner, check out Apple’s documentation page: Promoting Apps with Smart App Banners.

Note: if you have enabled Universal Links for your domain and the app is already installed on the device, Safari will automatically show a smaller version of the app banner. This “Universal Links banner” cannot be disabled.

Is There An Android Smart App Banner?

Because of the fragmentation of the Android ecosystem and browser choice, Google has never released an Android smart banner. Chrome offers something called the Native App Install Prompt, but it is difficult to implement, provides very little developer control, and has never been widely adopted. 

Apple’s introduction of the iOS smart banner initially spawned the development of a few different open-source options with Android compatibility. Unfortunately, progress on these alternatives has stalled in recent years, leaving developers out of luck once again. 

This is a major hassle if you are a mobile developer who has built for both Android and iOS, and are looking for consistent behavior and attribution measurement. 

Custom Smart Banners: Branch Journeys

Fortunately, there is a solution: tens of thousands of apps use iOS and Android smart app banners powered by Branch’s Journeys tool. These work on every operating system and browser to deliver users to your app or to the App Store, depending on the situation.

Gone are the days of worrying about how to make a smart app banner for your app’s mobile website, or finding an external smart banner creator. With Branch Journeys smart banners, you get all the functionality of Apple’s iOS smart app banner, plus all of the following:

• Dynamic Smart Routing. When the banner is tapped and the app is currently installed, it will open the app. If the app is not installed, it will take the user to the appropriate App Store page.
• Cross-Platform Support. Works on all mobile browsers and mobile operating systems. Easily create an iOS smart banner or Android smart banner once, and use it everywhere.
• Installed App Detection. If you have the Branch SDK in your app and the user has opened it at least once, we are able to automatically update the call to action from “Install” to “Open”, just like Apple – or allow you to customize the respective call to action messages.
• Custom Audience Targeting. Tailor the look and feel of the Smart Banner, and create customized CTAs based on specific behaviors of your users across both mobile web and your app. For example, use a different banner for your most active users.
• A/B testing. Without changing any code on your page, run experiments to optimize audience targeting.
• Localization. Deliver text and designs that are localized to specific cities, states, and countries.
• Download Tracking. On the Branch dashboard, we provide rich analytics to track how many people viewed and clicked the banner, and how many installed or opened the app. This can tell you how well a mobile web page is converting, and help you optimize your growth efforts.
• Deep Linking. You can specify a dictionary of data that you want to pass into the app, so that you can take the user to a specific product, or piece of content within the app – also referred to as deep linking. Branch’s industry-leading matching accuracy means that you even receive those deep link parameters on first install from an App Store, in order to customize the onboarding flow for all users – newly acquired or re-engaged.

Customizable Smart App Banner – Layout, Color, Content, and Icons

To support a native look and feel with your mobile website, or just to customize the experience, Branch Journeys enables you to fully customize all visual aspects of your banner using a graphical editor or by directly editing CSS. This includes the app title, description, call to action button, rating stars, and number of reviews. It’s all tuneable to fit your site’s design.

Guide to Configuring Journeys Smart App Banners

It’s very easy to get started with Branch Journeys. You can either follow the step-by-step guide below, or request a Branch demo to meet with a member of our team.

Step 1: Create Your Branch Account and Configure Your Link Routing

First, head to our dashboard and follow the instructions to create your free account. You’ll define all the different endpoints so that Branch knows where to redirect the user in every scenario.

Step 2: Add the Web SDK to Your Site

Next, retrieve your Branch key from the dashboard under Account Settings > Profile. Paste the code snippet below into the Javascript tags on your site. Add the key you retrieved from the settings page in the ‘’key_live_YOUR_KEY_GOES_HERE’’ section.

<script> // load Branch (function(b,r,a,n,c,h,_,s,d,k){if(!b[n]||!b[n]._q){for(;s<_.length;)c(h,_[s++]);d=r.createElement(a);d.async=1;d.src="https://cdn.branch.io/branch-latest.min.js";k=r.getElementsByTagName(a)[0];k.parentNode.insertBefore(d,k);b[n]=h}})(window,document,"script","branch",function(b,r){b[r]=function(){b._q.push([r,arguments])}},{_q:[],_v:1},"addListener applyCode autoAppIndex banner closeBanner closeJourney creditHistory credits data deepview deepviewCta first getCode init link logout redeem referrals removeListener sendSMS setBranchViewData setIdentity track validateCode trackCommerceEvent logEvent disableTracking".split(" "), 0); // init Branch branch.init('key_live_YOUR_KEY_GOES_HERE'); </script>

Step 3: Set Up Your Journeys Smart App Banner

Head to the Journeys section of the Branch dashboard and follow the wizard to configure your smart app banner. If you have under 10k monthly active users (MAUs), you can activate Journeys for free. You can also find full Journeys documentation on our developer portal.

Step 4: Configure Your iOS or Android App for Deep Linking

Lastly, you can set up your native app for deferred deep linking and install tracking very easily by following our integration instructions for iOS or Android. 

All done!

Explore our guide for more thoughts on how to optimize Journeys for app users, read up on how to track app downloads from smart banners, or get inspiration from this collection of mobile web-to-app banners.

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 How to Set Up An iOS and Android Smart App Banner appeared first on Branch.

Since its inception, the world wide web has opened up the internet to everyone. It makes it possible for all of us to connect, share, and communicate like never before in history. The introduction of the mobile smartphone made that even easier: suddenly, you can have the world’s information in your pocket and get instant access to friends, entertainment, and information. 

But the smartphone and its ecosystem of apps also brought new challenges: mega platforms that own the device, the operating system, and even the flow of information. These platforms, which survive by owning the user’s time and eyeballs, started erecting walls to keep people inside and ward off competition.

Nine years ago, my co-founders and I built an app in this ecosystem full of barriers. We faced these challenges first hand. We struggled to get our app discovered, run basic campaigns and to build the pathways for sustainable business growth.

Branch is the solution to walled gardens. Branch links break down the walls and make the mobile ecosystem more open, connected, and relevant for the end user, regardless of the platform they are on. 

Now, seven years later, Branch’s platform has been selected by over 100,000 mobile brands and we directly reach more than 3 billion users around the world, tens of billions of times per day. We have expanded our products to go beyond just mobile, connecting users from offline-to-online, desktop-to-app, TV-to-app, and beyond. We help our customers both create and measure those experiences. 

Branch’s growth speaks to the continued fragmentation and shifts in the mobile ecosystem. Mobile device adoption is now over 90% of the global population, which means it’s universal. And COVID accelerated the adoption curve by years, turning mobile apps from a nice-to-have into table-stakes for pretty much every consumer brand on the planet — our digital lives are now lived in a world of mobile apps, not websites, and mobile is no longer just the realm of ad-supported gaming. In fact, we now spend more than a third of our waking hours on our phones, with 92.5% of that time spent in apps. 

But the recent changes in the mobile ecosystem, from sweeping industry privacy changes like ATT, to the explosion of new device types, to new regulations around the world, mean that apps are struggling to survive. The mobile ecosystem is more siloed and fragmented than ever, despite the progress we’ve made. We have a lot more work to do.

Today, I am excited to announce that Branch has raised $300 million in new funding at a valuation of over $4 billion. This will allow us to double down on our product investments to solve these new ecosystem challenges, while also delivering on our commitment to the protection of user privacy:

• We are significantly expanding our industry-leading mobile linking platform (MLP), to help brands unlock new ways to grow through their owned and organic channels, and better integrate mobile as cross-device and offline-to-online crossover experiences become part of users’ everyday lives.
• We will continue transforming our mobile measurement partner (MMP) solutions for paid media, providing customers with state-of-the-art, privacy-first measurement to navigate mobile advertising in a post-IDFA world.
• We will accelerate our research into new, next-generation solutions to improve app discovery and move the ecosystem forward into a more privacy-centric era.

Our new valuation (more than double any traditional MMP in the industry) shows the confidence from the market — and belief from our investors — in the need for a bridge across all the chasms in mobile that break experiences and prevent measurement.

Since my earliest days as an entrepreneur, I’ve been in awe of the power of an open and connected internet. Branch has truly built the internet of apps, and there’s so much more left for us to build. This passion and vision is now shared with a team of extremely talented people that now numbers more than 500 across 16 Branch offices around the globe. 

I want to take a moment to thank everyone who has worked to bring Branch to this point. For your initiative, passion, and commitment. As a team, we have worked hard to make the mobile experience better for every smartphone user on the planet, and this new round of funding will create countless opportunities to put our shared values into action bringing a more connected, open, and relevant ecosystem.

And, as we enter this new chapter of our business, we are always looking for talented, driven, and passionate new teammates to join our team. If you’d like a seat to help change the future of mobile, check out career opportunities at Branch. Build together. Grow together. Win together.

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.

The post Branch Raises $300 Million at $4 Billion Valuation to Crack Open Walled Gardens appeared first on Branch.

This week, on the cusp of the iOS 14.5 public release and accompanying enforcement of the AppTrackingTransparency policy, Apple made a last-minute change to their User Privacy and Data Use marketing page. A superficial reading of this new addition could seem like an extremely broad limitation on deep linking. However, the reality is that Apple is simply closing a loophole related to ad tracking.

Let me explain.

Over the years, Branch has seen just about every application of deep linking technology, but the primary use case has always been to drive overall mobile adoption and retention by improving the user experience.

This means deep linking itself is a UX tool: it delivers tremendous value by removing friction from the user experience. However, like many technologies, this core functionality can be reused for purposes it was never intended to support. 

Gaps like these, between what is technically feasible with a tool and what is permissible use under platform policy or applicable law, are sometimes purposefully exploited to create convenient “grey areas”. Misusing deep links designed for user experience as an “alternative” to a tracking link designed for advertising measurement is just such a grey area. Yes, the technology theoretically makes it possible, but only when intentionally abused.

As it turns out, we have a precedent for exactly this situation when it comes to deep linking: back in 2017, Facebook closed a loophole that allowed access to device-level advertising attribution data without the contractual and technical standards of their MMP program. This workaround was most famously used by TUNE, after they were removed from the MMP program in 2014: by calling Facebook’s deep linking API to retrieve parameters intended for UX optimization, TUNE could instead hack this data to perform device-level advertising measurement.

Once Facebook discovered this workaround, they made a policy change to address it and TUNE was forced to retract their offering.

That brings us to the section Apple added to their User Privacy page this week:

This addition might appear quite disruptive on the surface, but it is actually just closing the same tracking loophole that Facebook addressed in 2017.

At first glance, it’s possible to read the question itself as Apple upending the use of all deep linking until users have given consent to tracking via the ATT opt-in. However, we believe interpreting the question this way would not be a sincere reading of Apple’s intent, based on their full public answer immediately below it.

Why? Apple’s answer explicitly clarifies that deep linking requires ATT opt-in if those links are being used to power ad targeting, ad measurement, or sharing with a data broker. This is a direct parallel to their existing guidance against using probabilistic “fingerprinting” or first-party data (like a hashed email address) as IDFA alternatives. In other words, this is a simple clarification that data collected by any means, if used for purposes related to advertising tracking, is subject to the ATT policy.

We agree with Apple’s stance on this, and we’re glad to see them make this move to keep deep linking focused on its original purpose: creating great product experiences for users.

In summary, if you plan to use deep linking technology, tracking link technology, fingerprinting, hashed user email addresses, or any other data collection technique for advertising tracking applications, you must collect opt-in permission via the AppTrackingTransparency framework.

However, if you — like the vast majority of developers — are using deep links to enhance user experiences by enabling users to find the content they want, and carefully ensure that the data from these links is not misused to subvert the ATT framework, Apple’s updated guidance should not create any new compliance concerns. 

The post Like Facebook in 2017, Apple Closes “Deep Link” Ad Tracking Loophole appeared first on Branch.

On the other hand, as a third party service provider, these businesses place immense trust in us. They trust that our code is robust and reliable. They trust that we invest in security and data protection to ensure their data remains safe. They trust that we go the extra mile to protect the end user and their data. And most of all, they have to trust that we comply with all regulatory and policy rules. Branch must never add risk to the operations of these businesses.

Occasionally, there are choices that require us to balance these two: fighting for their rights, and policy compliance. The iOS 14 / AppTrackingTransparency (ATT) / IDFA changes are a perfect example of this. Let me explain.

In January, Apple removed all ambiguity (see FAQ in Attributing App Installs) about whether or not a company could perform advertising attribution in the case where AppTrackingTransparency (ATT) had not been accepted. It’s absolutely clear that if a user has not accepted ATT, no one – not even the advertising app or its CRM tools – can attempt to join an app install to an advertising click for attribution. They must use Apple’s SKAdNetwork (SKAN) framework or get permission via ATT.

At this point, at Branch, we faced two paths:

1. We could manufacture a convoluted interpretation of Apple’s policy language that allows us to somehow still justify tracking the user without their consent.
2. We can fundamentally alter our product to stop tracking users without ATT consent, and only use SKAdNetwork for ad attribution until the user opts in.

The pressures to pursue path #1 (policy workaround) are very strong. Attributing users at a device level is an incredibly important service for advertisers. Shouldn’t we fight back on behalf of all the companies that depend on this data? Plus, if Branch can’t do this, will our customers still continue to pay money for advertising attribution? 

But what of the risks of path #1? If Apple does crack down on any service that attempts to exploit a fuzzy interpretation of their new policy, the thousands of apps that trust Branch could face rejection or worse from the App Store. Their brands could be unfairly tarnished with a public perception of poor privacy behavior based on Apple’s arbitrary rules.

As you might have seen in our blog post from February, we decided to go the conservative route with path #2 (full compliance). This will impact the value of paid ads attribution and could be very disruptive to the many businesses who depend on this data. While we may not agree fully with some of Apple’s decisions around the ATT implementation, we understand the intent and have built our product to ensure you are safe. Our choice makes us confident that the companies who trust Branch will be following the spirit and the letter of Apple’s new policy and will be safe from store rejection. 

Every company in the ecosystem faced this choice. And if you think it was an easy one, the jury is still out on whether path #2 was correct. There are still app tracking companies that have decided to pursue path #1 and put their entire customer base at risk of rejection. 

If Apple’s enforcement actions over the next year will establish the precedent (as they have in past cases) that Apple doesn’t intend their policy language to be interpreted this strictly, the iOS industry may be in a situation where the risk of rejection goes away and Branch will revisit this decision to remain competitive.

In the meantime, just know that by trusting Branch as your mobile linking and measurement partner, you’ll be in compliance with Apple’s new policies on iOS 14 and you do not run the risk of being removed from the App store. 

The post iOS 14 App Tracking Transparency: Balancing Rebellion and Conservation appeared first on Branch.

Update: we have published a follow-up post: How To Prepare Your Mobile App and Attribution Stack for Apple’s iOS 14 Privacy and IDFA Changes

The world of app install attribution as we know it has come to an end. At WWDC in 2020, Apple announced that in iOS 14 (likely Sept/Oct this year), the IDFA is no longer a relevant or widely-used identifier. There are two changes that put the writing on the wall for this:

1. iOS 14 will default all devices to limit ad tracking enabled, which zeros out the IDFA

2. If the publisher app or destination (advertiser) app wants to read the IDFA, they must each separately receive permission from the user with the following prompts

I can’t imagine a single user that would ever agree to let themselves be “tracked around the internet”. There’s no way this will see anything but accidental adoption. Therefore, we must assume that IDFA is no longer usable. Even with the proposed SKAdNetwork replacement, this is a fundamental elimination of basic capabilities like user-level attribution, retargeting audiences, look-alike audiences and so much more. 

What about Android? At least we still have GAID you might be saying. With Google’s recent announcement to remove 3rd party cookies from Chrome, the writing is on the wall for GAID to follow suit, especially with Apple setting the industry precedent.

Fortunately, Branch has been building the linking platform and matching technology designed specifically for the world where universal identifiers such as IDFA and GAID don’t exist. We’ve long believed that user privacy must be maintained by the service owners, since users often don’t take the time to read privacy policies and terms of use. We must be good data citizens, and “tracking users across the internet” contradicts that concept at its core.

The Branch system uses an industry-unique, anonymous, probabilistic algorithm that incorporates historical attributions to deliver high accuracy matching where there is no universal ID. This means where the rest of the industry is reliant on fingerprinting technology with accuracy rates of 60-70%, Branch can deliver superior, more accurate attributions. Today, our predictive matching engine already covers in the high 90s% of your mobile user base. We expect high coverage rates to continue in a world without IDFAs, providing you reliable and correct numbers where others fail. We will no longer be able to deliver deterministic matches on iOS without a user logged in across your properties, but are confident in this alternative approach. The best part is that all this is accomplished while no user data from your app is linked to other companies’ apps’ data. You can review this and more details on our privacy principles page.

Summarizing so far, we’re confident that Branch will continue to deliver its services and users will gain huge amounts of control over their data, so we see this as a massive win for the mobile ecosystem. That said, there will certainly be changes to the advertising measurement functionality within Branch, specifically when it comes to app-based measurement from install-focused paid campaigns.

We believe this to be ultimately pushing the industry towards the world that Branch has been promoting since inception: one where organizations can finally think about their campaigns more holistically, focusing on the user experience and full customer lifecycle rather than the unhealthy obsession with install ad tracking.

True customer value only begins at acquisition but is fully realized when you give them a great user experience, can re-engage them in a meaningful way, and can provide value seamlessly across platforms. Ultimately, companies will emerge stronger from this shift, and their users will greatly appreciate it.

What does the advertising measurement industry look like in a post-IDFA world? To be honest, there is still a lot of uncertainty, and we expect the specifics will evolve as iOS14 continues in development. The key unknown is the language that Branch will use to communicate with other ad networks to do validation. There are a few options moving forward to consider:

1. Apple has proposed usage of the SKAdNetwork framework, which completely anonymizes the attribution and eliminates user-level data. This will certainly break most marketing processes. There are also challenges in the actual implementation of this, requiring publisher apps to actively register the approved ad networks in a newly-released version of the app. We think it’ll be challenging for most to adopt and incorporate this technology.

2. Another alternative is the approach Google has taken on iOS search inventory earlier this year, where they internally model out the estimated number of conversions for a given campaign, only sharing aggregate numbers with advertisers. This also would restrict user-level data entirely, breaking most marketing processes.

3. The last and most likely outcome is the traditional tracking link methodology, which is widely used today outside of the self-attributing networks like Google and Facebook. Generally, the industry-standard method leverages IP-based fingerprinting to attribute in-app actions back to advertising clicks. This is the most tried and true method, since it has existed for some time, and we expect most will shift to this at least in the short term. This is an area of course where Branch’s accuracy is unparalleled.

The Branch team is working with Apple and the community to sort these details out with ad networks and partners, and we’ll be sharing more information as soon as it is available. We are starting with a webinar in partnership with Allison Schiff, AdExchanger’s Senior Editor for cross-device, measurement, privacy, and the app economy next Thursday, July 2nd at 10 am PT.

In the meantime, trust that you’re in the right hands and we’ll guide you every step of the way.

The post The App Attribution Industry Is Dead. Embrace the Post-IDFA Era with Branch appeared first on Branch.

We Never Rent or Sell Personal Data

No Branch customer can access another Branch customer’s end-user data. And we are not in the business of renting or selling any customer’s end-user data to anyone else. To enable customers to control their end-user personal data, they can request deletion of that data here at any time, whether in bulk or for a specific end user. These controls are available to customers worldwide, although we designed them to comply with GDPR requirements as well.

One of our foundational principles is that of trust. Customers must trust Branch in order to put our service front and center in every email, social post, share, advertisement, or general message they send to their users. One of the essential ways we build trust is by guaranteeing that our customers’ user data is secure, private, and never accessible by any other customer on our platform. We deliver this through data isolation architecture and industry-leading investments in security such as SOC2, ISO27001, and rigorous security investments.

The principle seems simple enough but it’s important to understand how it applies to Branch products. At the heart of our platform is a predictive modeling algorithm that supports and is used by all of the products on our platform. This algorithm is powerful because it links the identity fragments of a user that are spread across the devices, browsers, and apps they use, enabling Branch to deliver a connected experience and measurement to the user regardless of channel or device, and to provide a full picture to marketers of which campaigns and touchpoints are actually working.

But if we’re connecting all those identity fragments, does that mean that companies who implement Branch have access to the user data of other companies using the platform? Never. Does it mean that companies who implement Branch are essentially buying into this data? No. They will never have access to it. Here’s why: Our predictive modeling algorithm is advanced privacy technology that keeps data isolated and secure between customers, but allows us to build far better connected experiences and more accurate measurement because of Branch’s scale.

For example, if a user clicks on an email sent by Acme Books, Acme Books will only be able to see parameters of that link click because it happened inside their own platform. They cannot see any other information (like advertising identifier) that has not yet been “earned” by Acme — because that user hasn’t gone into the app yet. Now, if a user opens the Acme app, Acme Books will then be able to see app-specific information — but only because the user chose to engage directly with Acme’s app. No other user data is transferred to Acme Books. The only incremental information the predictive modeling algorithm provides to Acme Books is that both of those activities — the email link click and the app open, both of which came from a user’s direct interaction with Acme properties — came from the same person. It’s the connections between earned user data. That’s it. Acme will never be able to see where or how the connection was made or by what method, but it’s done in a far more accurate way than any technology on the market today.

Privacy Principle #3 can be distilled down to this: Your data is your data no matter what, and neither your competitors nor any other company will ever have access to it. Furthermore, you’ll never be able to access any other company’s data. We never make it available in any form to anyone. And we certainly never sell it to anyone. Your data is YOUR data. This is a key part of the foundation of trust in Branch.

The post Data Privacy Principle: Branch Will Never Rent or Sell Our Customers’ User Data appeared first on Branch.