Android Archives - Mike Dixon's Blog

App referral traffic to your web site and how to track it

Measuring referrals from mobile and tablet apps to web sites is extremely difficult – actually, its practically impossible. Over the past few years you will have seen traffic from direct/typed/bookmarked sources increase steadily as app usage has increased. Unfortunately this is not because your web site has become a destination for your chosen content, but instead its because your analytics platforms are unable to attribute traffic to apps.

I am specifically finding traffic from social media apps, so Facebook and Twitter, the hardest to track down. There are techniques that I discuss below that can help you to track content that you post yourself, but unfortunately this doesn’t help with organic sharing.

While Facebook Insights for domains does give you some level of overall referrer information, it does not breakdown the traffic between desktop and mobile.

This post explains why your analytics package is currently unable to track this traffic and tries to find some solutions to help you to make sense of it all.

So how do analytics platforms track referrals?

Most analytics packages use header information contained in your user’s web browser to determine which site the user had been to previously to visiting your web site. This header information only appears if a user clicks on a link to your site. For example, if I am on web site A, click on a link to web site B, then the header information would show that the referrer was web site A.

Just so we are clear, if I am on web site C, then type web site D’s domain name into my web browser, then there would be no referrer and the traffic source would be Direct.

No referrer in the header

This latter example explains why measuring app traffic is extremely difficult; an app is not a web site, it is not viewed in a web browser and they do not contain header information when linking out to a web site.

There are two different techniques that apps can use to open up web content:

Open the content in a native mobile or tablet browser – such as Safari, Chrome, Android Browser, Opera etc
Open the content in an in-app version of the native browser

In both cases, because the app is opening up a new instance of a web browser, whether its the native browser app or the in-app version of the browser app, there is no referrer in the headers. So when your analytics package is seeing the user visiting your web site, it is seeing that there is no referral and it will deem the traffic to have no source and therefore assign that referral as direct.

So how can we track app referral traffic?

There are a couple of things that we can do as content creators to get around this:

Google’s UTM Tracking: https://support.google.com/analytics/answer/1033867?hl=en

If you use Google Analytics, you can use the built in UTM tracker to track links that you post to other web sites or platforms. Quite a few URL shortening services and sharing plaforms such as Buffer, Bit.ly and Owl.ly allow you to add these dynamically so you don’t need to keep adding the tracking manually.

When a user visits your site using a UTM tracked link, this will override what is contained in the web browser’s header and attribute the source of the traffic to relevant keyword that you add to the tracking. You need to be very careful here as I have seen instances where these have been setup incorrectly and links posted to Facebook with Twitter as the source have been shared which makes the data inconsistent and unreliable.

One thing to note on this, is to only use this method for external, inbound site links. You should not use these links on internal links as they automatically start a new site visit – meaning that you will see a spike in visits whenever someone clicks on your tracked links.

Using a similar service for other analytics platforms:

Many other analytics platforms have a similar method for campaign tracking. While these have been primarily used for more traditional marketing campaign tracking, there is no reason why you cannot do use this same method for the sharing of content.

Limitations

This would only work for content that you share yourself. There is no way to enforce this for any organic shares – so when a user copies and pastes a url from your web sites into a social status update for example.

Also, as you cannot post content to a specific device or platform, you cannot differentiate easily between a social media’s desktop, mobile web or mobile app experience. So while you may get closer to tracking Facebook traffic, you will still not know the make up of desktop, mobile web or mobile app referrals.

Mobile Native Browsers vs In-App Browsers

I was surprised to find that Adobe Analytics (Adobe SiteCatalyst or Omniture, depending on how far back you go) doesn’t allow you to report on mobile browsers. Even though, I’ve been using Adobe SiteCatalyst for many years and I had always assumed that the ability was there. I am actually a little ashamed that I hadn’t noticed this before.

SiteCatalyst Device Type with Browser Breakdown

The main reason for me to look at this was that a colleague sent me a link about Embedded Mobile Browser Usage on http://www.lukew.com. While the blog post is more to do with how developers should be testing on in-app versions of mobile browsers as well as native browsers. This is mainly due to the in-app versions of Safari and the native Android browsers having less functionality and lower rendering powers. Luke explains that the in-app version of Safari for example does not include the Nero Javascript engine, certain Safari caches, or the “asynchronous” rendering mode. Meaning that web sites could appear to load more slowly, contain errors etc that would normally not be detected if testing on the native versions.

As Facebook and Twitter app usage continues to grow, its going to become more and more important to understand the differences between these different browser types and how users browse your sites when using these apps. In addition, when users click on your content from apps such as Facebook and Twitter, they appear as either Direct or Typed/Bookmarked depending on which analytics package you use and whether you are using any form of campaign tracking or not.

When I realised that Adobe Analytics does not track mobile device browsers, I turned to our implementation of Google Analytics. Fortunately, GA does track in-app browsers on iOS – so you can see data for Safari and Safari (in-app).

What I have found in my initial dive into this is that users browsing our sites using an in-app verison of the native browser consume less content (in terms of pages per visit), has a higher bounce rate and are on the site for about half the time than the native version.

In-app browsers vs native mobile browsers

What is going to be hard to work out is whether this is due to a behavioural or technical motivation.

If the site renders slowly, contains certain errors, or is not fully optimsied for the in-app experience, you could attribute some of the reduction of usage to this rationale.

In terms of behavioural, you need to consider what users are doing. If I am on my Facebook app on my phone, its probably while I am in the middle of doing something else. Potentially on the toilet, in a meeting (hopefully my boss is not reading this) or in transit therefore I have limited time to view.

Also, to move this point further, if I am in my Facebook app, I’m also interested in seeing what other content my friends have posted. So I might just read the article that a friend posted, then click back in the app so I go back to my feed and continue my Facebook journey.

One of the main things that I tell colleagues at my job is that Analytics is great at telling you what happened. Trying to find the reasons behind a person’s behaviour is not generally achievable. You can find commonalities between certain types of users, segment them and try to implement changes to convert users to behave in the same way. But in terms of understanding the drivers for users to act in a particlular way is not something that I believe Analytics will answer.

You need to be talking to your users and understanding why they are doing what they are doing – whether it be done through social media, email or surveys. You really need to have all the information to make decisions and I believe that Analytics is only one part of it in this case.

Mobile Apps vs Mobile Sites

I was browsing the ThoseInMedia group on LinkedIn and came across this question: Mobile Sites Vs. Mobile Apps: Which Is Best For Your Business?

It made me think about what had worked and not worked in previous roles and projects and like most questions like this, its all about your digital strategy and how you monetise your content.

The main driver for me to make this decision would be to look at my business model and look at what would be the best to deliver this. Then the secondary benefits would slot in, such as deep linking, SEO, marketing etc.

Apps can be expensive to get right. I tend to look to apps if I have a sponsor that can help to fund the development of the app. In addition, it is extremely hard to make profitable apps so having a sponsor on board helps to make the app free to users and to help increase the exposure of the app.

If you do not have a sponsor and you are trying to recoup your investment through charging for your app, remember that it takes a lot of 69p/99c purchases to recoup a five figure investment. According to this report, 50% of games make less than $3k in Apple’s App Store.

If you goal is to try to increase incremental revenue – ad revenue, sales, etc – then I would go for a mobile site. You benefit from deep linking, SEO, lower costs to develop, higher accessibility to more users etc.

If you do build an app, one piece of advice would be to try to deliver something that a web or mobile site cannot do and also try to utilise the phone’s features – location, camera, etc – as this can help to really set you apart from other apps out there.

In addition, with the ever improving HTML5 standards, you can achieve many app like features through a smartphone site. There are also plenty of frameworks out there that allow you to take advantage of the device’s capabilities. Such frameworks include PhoneGap that allow web developers to deliver app like experiences through a browser. It also ensures compatibility between the main devices such as iPhone, Android and Blackberry.