Life After the UDID

There are numerous problems that still need to be solved in the mobile advertising world. These include patchy cookie support (and a lack of understanding of how cookies actually work); inconsistencies around device identifiers (or as they’re otherwise known – UDID’s); and the lack of ad tracking information pass-through within the Apple App store, to name just a few.

The good news? There are solutions on the market right now that allow advertisers and agencies to very precisely track and attribute downloads, conversions and even in-app events such as frequent use, purchases, game level completion and much more - and the information is usable by media buyers to plug into automated or programmatic buying solutions such as Demand Side Platforms (DSPs), in order to understand and adjust their buying strategy.

By plugging app download tracking data into a DSP, its learning mechanisms can automatically adjust the buying strategy to buy more of the traffic that has the same profile as that which delivered the best results. The DSP effectively finds a “pattern” of the traffic that is most likely to result in a download, by looking at many variables, such as device types, versions, location, time of day, day of the week, the site the ads are shown on, and much more.

When there are enough statistics for the events that the advertiser wants to buy (such as a download and install), the DSP will find the same recurring set of variable values and make a note of them. It will then bid higher for such traffic and buy more impressions with such a profile – all on an impression-by-impression basis. And we're talking 10 thousand plus impressions per second here. That's 20 billion plus impressions a month.

Traffic profile
A typical traffic profile might look something like this: iPhone or Samsung Galaxy S, Saturday and Sunday lunch time, on sites from publisher XYZ and apps from game-maker ABC and so on. At StrikeAd, we use about 30 different variables to determine this pattern.

Think of this as a large number of criteria to distinguish between different people, such as personality, hobbies, height, weight, eye colour, hair colour and so on, as used on a dating site. The more parameters you use, the more precisely you can identify a person that’s right for you.

The result is then a much more focused buy, which delivers massively larger yields than that of a blind buy that is done in bulk, rather than on an impression-by-impression basis. This way, the advertiser knows exactly who drove the most effective traffic, and can adjust the spend in the right direction accordingly.

This all sounds fine in theory. But how does a DSP - or anybody for that matter - track and attribute impressions and clicks to a download or subscription if there is “dead space” between the “entrance” and “exit” of the mobile app advertising workflow? The answer is not a single solution, but a combination of approaches and technical implementations, which together deliver the required result.

Currently, when a DSP or an ad network buys a mobile banner that runs on a mobile media exchange (or a Supply Side Platform – aka SSP), the latter’s code in the app passes the UDID back, often one-way encrypted (aka hashed).

So, many ad networks quickly adopted a “match the ID” approach, where they would record the UDID of the click and ask the advertiser to send the UDID of the device which installed the app to their server, where they would check to see if that UDID is in the click records – attributing the download if there was a match.

But there are several problems here right off the bat. Typically, an advertiser will use many different banners to advertise an app, and the above approach does not precisely pinpoint which banner drove the download. And no, you can’t always argue that last view or last click won.

Secondly, the exchange may be sending the UDID hashed using one algorithm (e.g. SHA1) and the advertiser may be sending it hashed using another (e.g. MD5) – so there will never be any match. It’s a bit like trying to match a phone number and a postcode. They’re just never going to match, even if they’re for exactly the same house.

Thirdly, the Android OS has several IDs available to app developers, including AndroidID, IMEI, MEID or ESN. Exchanges and advertisers often will use and send different ones again. Combine that with different hashing algorithms and it’s a right mess!

Lastly, Apple is deprecating the UDID; it will no longer be available within apps to be pulled out by the SSP SDK, so this free ride will end soon. There will be other IDs one can use on the device, such as the MAC address of the wi-fi card, but this may not be very reliable either, for several reasons.

Lack of clarity
There is often a lack of clarity when setting up a campaign between the advertiser, agency, media buyer and the exchange, and again, the wrong IDs are often compared, and therefore never match. Many attributions are missed and don’t go back into the mix – driving up the cost of the download, and reducing the number of downloads too.

There's one more reason still to ditch the UDID. One of the main other problems with UDIDs is that only media running inside an app – as opposed to that seen on mobile sites in a mobile web browser – can be bought, if UDIDs are to be used for download attribution.

This is because a UDID can only be obtained when you have access to the operating system API, i.e. you are some code running inside an app. If you’re a simple meat and potatoes HTML page, or even a fancy one with some JavaScript, you just cannot get the UDID of the device you’re being shown on. It's like arriving in a building blindfolded and only being able to go into one room with no windows to the outside world. You won’t be able to work out where you are, unless you can peek outside and glance at a street sign.

This is a problem, because there are a huge amount of mobile-optimized sites, which could be driving punters to the app store to download that app. 100 per cent more, in fact, in addition to the app traffic.

The net effect is that app inventory becomes more sought after, and in turn the price, yield and cost of a download goes up. Yes, this keeps the app developers happy - which isn't necessarily a bad thing - but doesn't benefit anybody else.

“But if the app stores are a dead end where advertising tracking dies, how do you tie an impression to a download without a device ID?!”, you ask. Surprisingly it is back to the old veteran – the cookie.

Cookies actually work fine on most mobile devices, especially on all the main ones that have app stores and apps, such as iPhones, iPads, Androids, BlackBerrys, Nokias etc. If they didn’t, many sites where you have to log in, such as Gmail, eBay, Facebook etc. would be pretty hard to use, as the site would not remember who you were from page to page.

So a cookie is a bit like that ultraviolet stamp that a bouncer in a nightclub would put on your hand so they know who you are after you pop out for some fresh air (or a cigarette!) and decide to go back in. The only issue that exists with cookies is on the Apple Operating system, iOS – but only with the setting – and not reading – of third-party cookies. If you’re not sure what I mean by first- and third-party cookies, I simply refer to the domain of the page you are looking at, and the domain of the server where the tracking cookie was set from.

For example, let’s say you’re looking at a page on amazon.com and there is a tracking pixel pointing to strikead.com, which tries to set a cookie. This strikead.com cookie will be classed as a third-party one - as it’s not from the same domain as the page you’re on. Cookies from amazon.com, however, are first party, since they’re from the same domain as the page.

Setting a third-party cookie in iOS Safari – the iPhone browser - won’t work. The attempt to set a cookie will be blocked by Safari. However, reading both first- and third-party cookies is just fine on iOS Safari on the iPhone, iPad and iPod touch.

Getting to cookies from an iPhone app
That’s all fine and dandy, you say, but how do I read that cookie from inside the app? The simple answer is – you can’t, since Safari is just another app and apps on iOS cannot share data, for security reasons. The longer answer is that you can, but there are a few workarounds to be done.

The problem with reading cookies from inside an app is that they are set in the device’s browser, and only it has access to them. You can, however, launch one app from another. For example, you could launch the device’s web browser, such as Safari, from inside the downloaded app.

When you do so, you tell the server to go to the same tracking page where the cookie was set earlier during the click. You can also pass the server any necessary information for the download to be attributed to the click, and this info gets passed to the server. The server then tells the browser to go back to the app it came from and the loop is complete. No more “dead space”. It may sound like magic, but this is possible and it works very well.

The only negative effect of this process is a brief “flash” of the browser window whilst you are in the app. The StrikeAd SDK does this, but only for a very brief moment – a few hundred milliseconds – blink and you definitely will miss it.

Many advertisers are already using this method, and have found that it does not affect user experience, and gives them much better insight into the app life. Think back to the desktop computer and the standard browser – pop-ups are still common there, and nobody really cares about them.

Furthermore, the StrikeAd SDK only does the pop-up once – on first launch. After this, the unique ID from the cookie, which drove the download, is passed to the server in the background, and completely seamlessly to the user.

What about Android market?
Good old Google – being deeply steeped in advertising, it understands that certain things need to happen for the advertising machine to keep turning its wheels and provide free app developers with a source of income.

So, Android Market actually has a mechanism that allows variables to be passed to it from a click on a banner, and from there, to be passed to the app. The app can then pass this information back to the media buyer for attribution and optimization. So for those advertisers who really cannot have a pop-up in their app – at least on Android – there is a way.

This technology is a reality now – our app tracking and reporting solution does all this and more. We can even pass data into third party analytics packages such as Omniture or Google Analytics, so it can be examined there alongside other data, all in one place.

It's clear that there are solutions out there to make mobile app advertising more successful and cost effective, but it will take the triumvirate of the advertiser, agency and media to adopt them. Without all three parties understanding the options and utilising them, nothing will happen – or at least not easily and not quickly.

Michael Dewhirst is CTO at StrikeAd