How The Data Cookie Crumbled

Share on linkedin
Share on twitter
Share on facebook

In the last few months, we’ve seen a flurry of announcements regarding the Android and iOS updates. Released in 2017, the new Oreo software update is only now rolling out more broadly across Android phones, meanwhile, Apple released its iOS 11.3 just weeks ago.

Both updates are set to address concerns that have plagued the industry for a while – most notably battery health and privacy – which are coming to the fore only now amidst wide-reaching conversations around data security and compliance.

One of the solutions to this in Android’s offer is identifying and killing battery-draining apps, especially when not in active use. This is set to greatly affect data retrieval in apps, representing a huge move from the ‘always on’ systems we’ve been used to and a big change for advertisers, who won’t have the limitless, anytime/anywhere access to data they’ve had up till now, and will be looking for new and more varied sources of data. Specifically, the impact for advertisers relying on SDKs for location data is set to become much greater. This will have huge consequences for the wider industry too – especially with the added ramifications of GDPR.

Hands in the cookie jar

Over the last few years, the digital industry has pedalled half-truths and misinformation designed to confuse agencies and clients alike. “Fake news” is an issue most often associated with the political sphere, but the media industry also has its own unique approach to mistruths, especially when it comes to individual tech solutions. In recent months the Software Development Kit (or SDK) specifically has been prime territory for misunderstandings. It’s time to put these to rest once and for all.

Firstly, an SDK is a piece of code which can tell an app to collect mobile app data constantly and consistently. SDKs are widely available and not unique – all exchanges have deployed their own SDKs to manage programmatic publisher inventory, and third party tracking vendors like Moat use an SDK to enable them to track whether ads are seen or not.

Recent operating system updates by individual manufacturers, such as Samsung, provide power-saving modes by identifying and killing apps that drain battery life, so the traditional constant means of pulling background data via SDKs is no longer possible. Background data collection will consequently be more restricted. In fact, in the case of location data, this is limited to a few times per clock hour, and this lack of scale is already a problem associated with SDK use.

Additionally, background SDKs tend to wake up to location-change events, causing the majority of location points to be captured when the device is on the move; for example, when a consumer is walking down a high street. Foreground data relies on a consumer’s direct interaction with their phone, so is more likely to capture static data points, such as a consumer sat in a coffee shop playing a game on their phone. At Blis, we use both foreground SDK partners like MoPub and Oath, as well as background SDK partners like Unacast in the US in order to benefit from the advantages of both methodologies.

Software and hardware operators have started to accept the need to scale back this form of tracking as a result – and while this means consumer data is that much more preciously guarded, it’s clear advertisers will have to look elsewhere for their data.

There are a range of options: Bluetooth and wi-fi data, for example, is collected by external hardware, and therefore provides a great deal of accuracy. It’s made all the more promising with the increasing prevalence of Bluetooth technology and the ubiquity of wi-fi hotspots. As with any tech, all individual data sources have their drawbacks – whether issues of quality or scale – so it’s well worth using a range of different sources to paint the best possible picture of your consumer.

Permission please

Whatever mix of data you choose to harness, remember to always ask for permission. This shouldn’t be a challenge, as all your options should have very explicit opt-in processes. Why is this so important? In today’s GDPR-compliant world, obtaining data in the background without explicit consent is now out of bounds.

Understandably, battery-burning apps are not welcomed by consumers, and for app developers who depend on positive reviews of their apps, the ‘always on’ SDK data pull is a difficult sell. Whilst this is all great news for GDPR compliance – especially in the light of the Cambridge Analytica scandal – advertisers must get a better understanding of other sources of data they can harness.

This push towards data compliance certainly presents some challenges. We’re going to have to fundamentally change the way we value, handle, and source consumer data. Data will be rigorously protected across the board, and it’s important to be on top of asking the right permissions for the right types of data. But at the end of the day, the value this creates for the consumer and for business is huge: it presents us with an opportunity to regain consumer trust, to earn their consent, and with it build a more sustainable, transparent, system, based on a variety of more accurate data streams, so that we never come up against a situation like this one again.

To read the original article click here.

Share this article
Share on facebook
Share on twitter
Share on linkedin
Scroll to Top

Thanks for subscribing.

Blis Insights and solutions

You will soon receive our
latest news & insights

In the meantime, please check out the latest insights from Blis here

or read about our offerings  here