3 Biggest Mobile Ad Tracking Pitfalls Explained & How to Avoid them
Mobile advertising has a big problem which hardly anyone talks about: tracking is a nightmare. Wondered why it’s been so hard to show a healthy ROI for your mobile investment? By the end of this article, you will realise that you’re probably losing 30% of your tracked revenue due to leaky tracking.
Why is no one talking about it? My guess: a mix between deliberately opaque and dubious practices in the advertising industry (leading to this), and a highly complex technical infrastructure, which only a few digital marketers truly understand. During my time as PayPal EMEA’s Display & Mobile Advertising Manager, we made some interesting findings that I’d like to share with you. Please don’t hesitate to add comments or questions… I am certainly not covering every aspect here and tried to keep things simple.
Why should I even care? Mobile advertising is hot, predicted to reach 70% of digital spend by 2019. Not surprising, as consumers spend more and more time on mobile devices, advertisers are never far away. Especially in the battle for the attention of millennials, mobile needs to be at the front. Also, In-App ads are particularly interesting, as ad-blockers aren’t working there; a growing concern for browser environments. Advertisers need to be on mobile. Naturally, they want to measure what they’re getting from it. For that, you need tracking.
Why is mobile tracking different to desktop? Let’s have a look at three different scenarios.
1 Desktop & Mobile Web advertising, i.e. banner ads or social ads sending people to your website
2 Advertising within apps aka ‘In-App Advertising’, sending users to your website (e.g. Facebook newsfeed ads)
3 ‘In-App Advertising’ sending users to your app (or to download your app in the Google Play Store or AppStore)
Important: in all these scenarios, I am going to assume you’re using a 3rd Party Ad Server such as Google DFP, OpenX, Facebook Atlas, AppNexus or Conversant Mediaplex (and there are many good arguments to do so). Also I don’t expect you’re able/willing to implement tracking pixels/SDKs of every publisher you’re using, e.g. Facebook SDK, Adwords SDK. While it helps to decrease some of the leakage, it’s going to make comparisons & attribution difficult (one main reason to be on one ad server). That said, if your investment is very heavy for single publishers, this might be a prudent decision.
Alright, without further ado…
1.Desktop & Mobile Web advertising, i.e. banner ads or social ads sending people to your website. The classic example: A user visits a website on their desktop or mobile device, your banner shows (if not blocked by an ad blocker) and bamm! You drop a cookie on the visitor’s computers — even if they don’t click. The cookie remains on the user’s device for up to 2 years (depending on the ad-server setting). If the user performs your desired action, for example ordering your beautiful sunglasses, the cookie fires again and you have a tracked sale that you can attribute to your campaign. Happy days!
Well, the good news is that this works on Chrome, Firefox, IE & Opera (> 95% of the desktop market). However, Apple decided to make things slightly more complicated (otherwise, what would people like me be hired for?). On Safari, 3rd party cookies are blocked by default. This leaves us in a slightly messy situation with 2 scenarios:
- User does click on your ad: Cookie will be dropped, happy days😎.
- User does not click on your ad: Cookie will not be dropped, unless:
i) the user has visited the ad server’s domain before e.g. by clicking on another ad using the same ad server OR
ii) the cookie is from the same domain as the one that’s requested (typically a First-Party-Cookie)
On mobile, this presents a challenge to advertisers as Safari’s market share is around 36% globally. It basically means that no-view through-tracking is possible for a large share of that traffic. A conservative estimation is 50% of that, leaving us with 18% of mobile traffic untracked for post-view conversions.
See how things are getting messy?
2Advertising within apps aka ‘In-App Advertising’, sending users to your website (e.g. Facebook newsfeed ads, Instagram, Twitter).
This is a common case: You’re running advertising on one of the big name apps, let’s say Instagram, and send people to your website. You want to be using a cookie-based tracking solution (e.g. Google floodlights tags), so you can track the event (e.g. an order) on your website. For this to function successfully, the 3rd party pixel needs to be implemented in your ad on the platform (normally, this isn’t a problem, as long as your ad-server has been approved by publishers).
All good then? Well, not quite! Technology doesn’t quite work in favour of tracking. When you open a link in an app, you have probably noticed that it doesn’t open a new browser window; instead, it opens an “in-app browser”. This is to make it easy for you to return to your original content.
The problem with it: while this does drop a cookie on your phone (naturally, only for a click), it only does so for the in-app browser session.
That means, if your prospect doesn’t convert straight away (but maybe a day later, using the normal browser) — you won’t be able to attribute the sale to your Facebook ad. Bummer!
3 ‘In-App Advertising’ sending users to your app (or to download your app in the Google Play Store or AppStore).
Firstly, it’s important to understand that cookies are not used in the app realm. Hence, if you want to measure anything between mobile web and in-app… it gets a little more complicated. The solution is to use a specific mobile attribution tool that helps to bridge these two worlds (or even within the world itself). Bear in mind though — even if you have that, you can only track POST-CLICK.
So, no 🍪? Yap! Instead of cookies, mobile publishers are using different unique identifiers which are passed back to your mobile app tracking solution. What are these unique identifiers?
i) Your mobile device’s unique ID. In Android, this is known as the Google Advertising ID (Google AID or AAID), iOS uses the Identifier for Advertising (IDFA or IFA) and on Microsoft it’s known as the Windows Advertising ID (Windows AID)
ii) Click IDs — a unique ID that’s generated on a click
Okay, so what happens with these IDs? As soon as the desired action (e.g. app install, in-app purchase) has been performed by the user, your mobile app tracking solution connects the dots and attributes the event to the right ad (or even more granular: banner, message etc.) AND sends a ‘post back’ (or: callback) to the publisher (this is usually optional). The post back allows you to run fixed “cost per download” or “cost per action” campaigns, or incentivised campaigns (you give someone a new sword in his/her favourite mobile game for downloading your app and the ad network gets a fixed amount of $).
This is incredibly simplified — the reality is, in many instances your unique ID cannot be passed at all, or not directly (e.g. when your app needs to be downloaded first via the app store) or there’s too much time between the events (depending on the attribution window of your solution, typically 14d).
Confused? Here’s a visualisation of what’s going on:
What does this leave us with? The 3 pitfalls in summary…
1.If you’re running advertising on mobile web, you’ll have to live with at least 18% tracking leakage (coming from Safari) giving your ROI a big hit, especially in comparison with desktop.
What can you do about it?
- If you’re a big advertiser, it might be worth looking into serving ads directly from your domain (first-party ad-serving) which completely solves this problem. There are many other benefits of doing so (here’s a good overview) and there are vendors that take care of the whole implementation (e.g. AppNexus, TrueEffect).
- Remember, if people have clicked on your ads before, you can “unlock” tracking view-through for subsequent ads. Hence, consider running your direct-response (DR) campaigns before switching on your next awareness-driving campaign.
- Sounds obvious, but: if you can, try to avoid Safari, especially on desktop. Although it might not sound right (Apple users are likely to have a higher disposable income), if you really need to bring your cost per (tracked) acquisition down, that might just be the missing inch.
2. Measuring effectiveness of ads on Facebook, Twitter and apps when sending people to your website not only exclusively measures Post-Click; it only tracks events which happen in the In-App Browser session. You can assume at least 30% tracking leakage here.
What can you do about it? Make sure your mobile web flow is extremely simple and try to capture at least some information about your prospect to make the cookie fire. For example, if you want a user to register, only ask for their email address (and let them complete the full form later). Also, create some urgency (e.g. limited time offer) to make the action happen in the in-app browser session.
3.If you’re sending traffic from in-app ads directly to your app (or to the App store / Google Play Store), your cookie-based tracking won’t work at all. 🤖
What can you do about it? You must be using a mobile attribution solution which can establish a match based on the user’s advertising ID and the publisher. There are some very capable solutions on the market such as Adjust, Tune, AppsFlyer, Apsalar & Kochava. Most of them give you additional benefits such as cohort analysis and re-marketing (e.g. show all your users who came through facebook a new, tailored offer). Also, if you’re on a budget, Branch.io is completely free and gives you a lot of these features. These attribution solutions have built-in integrations with all major publishers (see list for Adjust). Usually they are paid based on the number of tracked events (e.g. number of app-installs). Alternatively, you can measure the results for individual publishers by implementing their SDK, but it will be hard to compare their results across different partners.
___
At PayPal, we calculated missing at least 15% of total marketing-driven revenue. As mobile ad spendings rise, this figure is only going to increase. Depending on your investment, this can equate to a sizeable amount, so get your infrastructure in a good place before running into these problems.
Thanks for reading! I would love to hear your own experiences in the comments.
Thanks! Johannes😊
This article has previously been released on my blog. Sign up to my newsletter to receive other articles on digital marketing & growth in the future. 😍
👉🔝 Tweet me | Add me | More about me 👌
