UDID and the MoPub client library

Posted March 29, 2012 by | Filed under: Industry Perspectives, iOS News, Product Updates

This weekend, TechCrunch reported that mobile apps using a device’s UDID (unique device identifier) were being rejected from the Apple AppStore. Due to this uncertainty, many publishers are wondering what identifier they should send to ad networks and ad servers like MoPub.

We’ve looked at all of the viable alternatives to UDID and have concluded that the best near-term replacement for UDID is the OpenUDID open source project. As a result, we are adding support for OpenUDID as a drop-in replacement for UDID in our open-source client library in today’s release – you can find the latest source files on our GitHub repository.

Because our library is open source, you have the flexibility to decide if you want to continue using UDID with MoPub, or if you want to move to a replacement identifier and avoid any potential issues with AppStore approvals. Note that this is not necessarily an obvious choice… if you have questions about how to make this decision, please get in touch with us at support@www.mopub.com – we’d be happy to help.

I’ve written a bit more below about UDID, why it came to be used, the various alternatives that are available and what I hope the end state of this transition period will look like. Please drop me a line if you have additional thoughts, or find me on twitter @jimpayne.

What is UDID and how is it used?

UDID stands for “unique device identifier” and it is a string of bits derived from several hardware components on the iPhone (Bluetooth radio, WiFi radio and some others). As the name implies, it is tied to a specific individual iPhone and cannot be changed. For several years, it has been used by mobile advertisers and ad networks to count how often users install apps when they view and click on advertisements promoting those applications. This is known as the “conversion rate” of a particular ad. It is the most important performance metric used by advertisers to compute how cost-effectively they can acquire new users. The UDID is used as the key piece of information tying the two events together. The app that generates the click and the app that are installed send a hashed version of the UDID to a central third party. A conversion is recorded when these events can be attributed to the same UDID within a certain time period.

Many applications are provided through the AppStore as free content with the intent to monetize them down the line using advertising. Severing the link between click and conversion will make it impossible for advertisers to accurately compute their cost-per-install (CPI) across different acquisition channels. As a result, they will have a hard time justifying and appropriately targeting their advertising dollars. This threatens advertising revenue that many publishers depend on in order to support the creation of that content.

Why UDID matters and why it was deprecated

As described above, the UDID is the critical link in matching a click and a downstream conversion because the iOS platform prevents applications from sharing data for the most part. They have done this in order to protect users from malicious content and in general, this is good for users. The UDID has historically been used by the mobile advertising ecosystem as a “shared secret” that can be used to match conversions without actually passing data between apps. This has been the state of the world for many years, and I worked directly on conversion tracking products for AdMob when it was acquired by Google in 2009.

The primary issue around UDID is that it is derived from the physical device and once it is set, it cannot be changed or erased. On the web, conversion tracking is typically something that an end-user can opt out of, but with UDID, this is not possible. Clearly, this is not ideal from a privacy standpoint. This is the basis of Apple’s move away from UDID and their recent actions to guide publishers away from using it as well.

Some alternatives to UDID

Since UDID was deprecated with the release of iOS 5 a few months ago, the mobile advertising industry has provided numerous alternatives for accomplishing the goal of tying click to downstream conversion. Here are the most popular among them:

  • MAC address. A device’s MAC address is tied to its physical networking hardware and is used in Wi-Fi communications to uniquely identify a device that is sending or receiving data. Although it is unique to a device and is accessible to a developer without using deprecated APIs, it has the same (or worse) privacy issues as the UDID. Because it is tied to the physical device and cannot be changed, this does not solve the conversion tracking problem elegantly.
  • HTML5 cookies. An alternative approach is to pass a user through the Mobile Safari browser both after she clicks on an ad and after she launches an app for the first time. Although this approach is technically feasible and allows a user to clear cookies and opt-out of tracking, it offers a poor user experience as some have observed.
  • Device fingerprinting. This refers to collecting a number of interesting pieces of information from a device (IP address, OS version, etc.) and combining them together to statistically identify a unique device. Typically, collisions would be so rare as to be essentially impossible, allowing for conversion tracking to function properly. However, fingerprinting approaches, as above, do not allow for the user to opt-out of tracking entirely nor do they allow the user to reset their fingerprint. Furthermore, many of these algorithms are proprietary and require license fees to use. It is unlikely that they will achieve widespread adoption.
  • OpenUDID. Of the conversion tracking solutions proposed by the ecosystem, we have concluded that OpenUDID is most consistent in spirit with the goals outlined above. It allows for conversion tracking without relying on information encoded in hardware, and also provides a mechanism for a user to opt out or reset their ID. OpenUDID is not perfect – it uses the iOS platform’s clipboard to pass tracking data between applications, which is an unintended use of those APIs. Any third-party can read or write this value and even reset it without a user’s knowledge. These are downsides, but the approach achieves the most important goal of tracking conversions while respecting a user’s privacy.

MoPub’s client library is being updated to support OpenUDID

We understand that the recent policy change from Apple is disconcerting to our publishers and as a result we are adding support for OpenUDID as a drop-in replacement for UDID in our open-source client library.

By default, MoPub’s client library will still use the UDID and will rely on the deprecated deviceIdentifier API to access it. We expect that the UDID will continue to be in widespread use for a considerable period of time, due to the lag in pushing software to devices through the AppStore and the number of apps still shipping that leverage UDID.

We have detailed instructions on how to enable OpenUDID in the MoPub client library if you prefer to use this method. Bear in mind though that your near-term revenue may be considerably impacted if you stop sending UDID!

We believe that the right way to solve this is through the iOS platform

As we indicated above, our company is dedicated to the idea of a flourishing app ecosystem where publishers can create great content and if they choose, monetize that content through advertising. As we’ve seen above, we know that tracking conversions is part and parcel of those advertising dollars and breaking this conversion loop puts these at considerable risk.

There would not be much of an issue around this – for advertisers, publishers and users alike – if the iOS platform were to offer a common solution similar to third-party cookies as part of the platform. On the web using this mechanism, conversions can be attributed properly within a short-term time frame but the user is ultimately in control of resetting those cookies or opting-out entirely if they so choose. It is a good balance that has worked successfully on the web for a decade or more. It is in everyone’s best interest to have the solution come from the OS and resolve this issue once and for all, so publishers can stop worrying about short-term impacts to their revenue and get back to creating great content.

blog comments powered by Disqus