Your Website as Your Mobile App Attribution Hub

Austin Hay
Mobile Growth
Published in
6 min readOct 2, 2016

Punchlines:

  • Integrated Platform: Your website should be the central hub where you drive people to the app and where you ensure solid source attribution.
  • You need Web & App Attribution SDKs to work in cooperation with your current web only attribution: You can use lots of 3rd parties or Branch to achieve this strategy.
  • Commit to a singular linking platform.
  • Web SDKs can save you a lot of time and hassle in grabbing referring attribution information.

Web SDK Reference: here.

Full Code Sample: here.

The Problem with Mobile Source Tracking

One of the things I think about a lot in my role at Branch is how to make source tracking easier.

On web the concept of source tracking fairly simple — there are free and paid tools, like Google Analytics and Mixpanel respectively that do a sufficient job of telling you where and how people access your website.

With native applications, however, it’s not as easy mainly because people often download directly (direct traffic to your website for example). But unlike on web, there are a lot more sources that are easy to miss with mobile apps.

For example, 30–40% of all app traffic is usually driven from an app’s mobile website if they have a strong one. And most companies I’ve worked with aren’t accurately measuring this download channel or creating experiences in it.

When you start layering in the obvious channels — Email, Social (Facebook esp.), Affiliate, and other mobile advertising — you pretty much have lost any sense of how people are getting the first time user experience.

But what’s surprising is there’s a really simple solution to this problem: use your website as your single attribution hub. What this means in practice is driving web and native traffic through your website across all your channels to ensure you’re capturing as much of the attribution pie as possible.

This is very easy to do with Branch’s Web SDK, but you could easily do it with some homemade Javascript. Let’s first outline the concept:

Right now, information flows differently depending on your channel, but your app isn’t well connected as a platform, like mobile web:

You’re spending a ton of money on all these different channels to create a full platform product experience. Typically they all live in a silo — some things serve web, other serve the native app. Rarely do teams think about their web and app strategy as an integrated, single platform. This usually means the app has much worse attribution and source tracking information than mobile web. It’s hard to double down on mobile if you’re not getting a clean shot of what’s going on.

By piping app traffic through your website, consolidating your tracking, and using one system for all channels, it makes it dead simple to get a clear picture of what’s going on:

Let your website handle the hand-off to the app. Piping traffic through and attributing on web, then tying those pieces to within the app with a 3rd party app SDK is a great solution.

There are lots of tools you can do this with: Google, Mixpanel, Adjust, TUNE. I’m going to talk about how you’d do it with Branch because I’m somewhat biased, and because speaking truthfully as a developer, it’s easiest to do with Branch’s Web SDK. No other 3rd party provides an SDK that serves the omni-channel function that I’m describing.

Where the rubber really meets the road is in grabbing incoming link traffic sources and re-attributing a download call to action on your website.

As I mentioned before, your website already drives 30–40% of all mobile download traffic. Why make things more complex? Hijack that awesome download channel and pipe your other channels to it. The missing link is that you need to “re-attribute” people when they land on your mobile website. Doing so just requires some understanding of Javascript.

A Solution: Using Branch & Referring Link Data

Each Branch link you create on your mobile website contains Branch Analytics Values (Channel, Feature, Campaign, Stage, Tags) as well as a deep link data dictionary (data{}) that can hold any number of key:value pairs.

Sometimes you want to attribute the install, open, or custom event in the app, to the initial source.

If you are sending users from Email or Social with a Branch link to your website, where you serve them a Branch banner, you would want the app install or open to be counted towards the originating source, and not the banner.

Example Flow:

User A is on Facebook

Link: http://go.4sq.com/facebook-test-link

Channel: Facebook

Campaign: Free Food

Tags: [‘June’]

Data: { $deeplink_path = 123 }

*Note* for testing purposes, I recommend setting your iOS, Android and Desktop redirects to a custom web banner demo or to your test environment.

User A redirects to your Website, which leverages the Web SDK

What most people don’t realize is that you can put a Branch link, banner, or other Branchified, deeplinking Call to Action on your website. Then, you can drive all Facebook traffic, including paid web campaigns, to your website where you can then allow them to passively download the app — all the while getting full attribution behind this complex series of customer touchpoints.

So, a user tapped on the Facebook link and was directed to your mobile website in the Facebook Web View. You might have a stunning piece of content and perhaps a Branch banner at the top or bottom.

Here’s the cool part: when you initialize the Web SDK you can access referring branch data straight from a callback that Branch provides.

This is one of the reasons why I said it was easier to perform this type of advanced attribution strategy with Branch — because there are out of the box tools that help make it easy.

Testing for Yourself

If you implement the following code, with your own Branch Key, on you website you’ll see the following in your console. This is the information about where the referring person came from. The best way to test this is to do the following:

  1. Put the code snippet above on your website.
  2. Make sure you can redirect to this page via a URL
  3. Grab the URL and put it as the iOS, Android or Desktop redirect in a test Branch link.
  4. Navigate to the Branch link. You should end up on the place where your snippet was placed.

You should also be able to inspect and see the following in the developer console.

Branch’s Web SDK has a method called branch.init() that automatically provides referring link information alongside other useful data that makes it easy to attribute and deeplink users between web and app. This in turn makes it easy for you to turn your website into a central hub for your platform.

As you can see, structurally, the callback will return these fields:

  • data (string)
  • data_parsed (object)
  • has_app (boolean)
  • identity (string)
  • referring_identity (string)

In this case, the data object is the same thing as data_parsed… it’s just a string. If you were to call JSON.parse(data) you would be returned data_parsed. We just provide this for you automatically to make your life easier.

You can access anything from these returned objects or parameters:

Notice how the referring information is automatically piped into the data {} in the callback.

You can access any of these fields either inside the callback, or by assigning to a global variable and storing for use in other parts on the page.

This is a really important point, so I want to repeat it:

You can now use Javascript to assign any of this data for use on your webpage, including re-attribution!

A basic example would be if you had a Branch CTA or link on the page that is supposed to attribute to mobile web. Instead, you might want to re-assign the referring link channel to be “Facebook” instead of whatever is set as default for the banner.

Accessing referring deep link data at other times? No problem. You can use Branch.data() or Branch.first() to get referring data or first referring data at any time.

Wrapping Up

The longer you wait to have a completely integrated web and app experience, the further behind you’ll be on mobile. The biggest challenge in committing resources to an app strategy is derived from poor source and download attribution. How can you build an effective strategy if you can’t identify your primary audience and where low hanging fruits might be?

With this in mind, let’s bring things all together with a few main takeaways.

  • Integrated Platform: Your website should be the central hub where you drive people to the app and where you ensure solid source attribution.
  • You need Web & App Attribution SDKs to work in cooperation with your current web only attribution: You can use lots of 3rd parties or Branch to achieve this strategy.
  • Commit to a singular linking platform.
  • Web SDKs can save you a lot of time and hassle in grabbing referring attribution information.

Want to try it yourself? Here’s a full example with Branch. We’ve included a method to create a Branch Web Banner or a Journey.

--

--

Austin Hay
Mobile Growth

marketing technology & assorted hobbyist. dog dad, water skiing fanatic.