As Privacy Regulations Tighten, There May Be An SDK-Based Solution For Ad Tech And RTB

“Data-Driven Thinking” is written by members of the media community and contains fresh ideas on the digital revolution in media.

Today’s column is written by Brian Crook, chief technology officer at Verve.

The United Kingdom’s Information Commissioner’s Office (ICO) recently put the ad tech industry on notice that its real-time bidding (RTB) practices for handling consumer data are not compatible with European regulations. As recent reports tell us, when RTB auctions begin, many players typically enter the equation. The ICO wants to ensure that controls are in place for that process.

“Legitimate interest” – an exception often cited by ad tech to work within GDPR rules while still conducting RTB – is the wrong legal basis for allowing companies to pass data from cookies back and forth in the RTB ecosystem, according to the ICO. A different regulation governs cookie data: the European Privacy and Electronic Communications Regulations (PECR) of 2003.

Ad tech’s RTB practices must first comply with PECR before it worries about GDPR. And after that, ICO argues that ad tech still needs to acquire consumer consent.

This is not an unsolvable problem. We can get ahead of the ball before these opinions dramatically influence the California Consumer Privacy Act (CCPA) and federal laws about to come down the pike. The solution I propose would make consent work better for publishers, advertisers and consumers.

The SDK as a governance layer

Contractual agreements protect how bid request data is shared. The ICO believes this isn’t appropriate given the data’s sensitivity and the number of intermediaries involved. This is where the legitimate interest argument falls down. Without sufficient provenance, data leakage creates a free-for-all.

If we add controls as part of the RTB consent path, however, we can better govern data on behalf of publishers and consumers to prevent leakage. For a solution, we should first acknowledge how identity typically works in the consent chain. Identity platforms today are often constructed from the exhaust of the consumer experience, generally without a contract at the level of the publisher and the consumer. Managing identity from the consumer perspective typically runs into adoption barriers.

Clearly, we should be thinking about what the consumer wants. Individuals are more willing to share sensitive information if they understand why and how that data is getting used – and if the solution is lightweight and easy to understand at the point of consent. So here is an opportunity to re-approach the role of the software development kit – the SDK as a governance layer.

Ad tech tends to pitch the value of the SDK as lying in its pole position with the consumer: SDKs give stakeholders a better look at data and a better opportunity to market to the consumer. It is also the place where we must already obtain consumer consent.

So, a logical extension of this is that the SDK could also serve the consumer and the end publisher by governing the data usage – edge computing, processing on the device itself – and thus providing a safer proxy to the consumer context, all without sharing user data to external and potentially vulnerable cloud environments.

An SDK-agnostic solution

The idea is to bump the publisher-buyer transaction back to the SDK from the server, sandboxing sensitive consumer data to the device itself. It could work within existing SDK frameworks – in a sense, location SDKs in general already manage this kind of scenario with region monitoring and beacons. This next step substantially extends its capabilities to another use case, to what I’d consider a kind of cutting-edge, supply-side private marketplace.

Here’s where it gets slightly technical – the basis of how all this actually works.

• The advertiser asks the consumer for consent for data that defines a device’s context. If granted, a contract is set that allows for future transactions.
• Matching occurs to enable an ad decision.
• The contract and decision context are passed via RTB in a portable secure protocol.

In the future, a rules engine can perform more complicated segmentation and decisions on the device. Keeping it all lightweight would always be critical for the publisher and the user experience. Granted, the evolution of the SDK’s role, as proposed, could make for potentially larger instances of SDK tech down the line, but that depends on how far a publisher wants to lock down the device on behalf of the consumer.

There are choices available to keep this lighter while still better protecting consumer data and responding to the guidelines that ICO has highlighted. All of this is a knife’s edge on which ad tech developers already walk. Right now, we have to do it with unfolding privacy concerns buffeting the industry; my proposal mitigates data-privacy threats and returns us to happier engineering challenges.

As regulations drive transformation and data leakages dry up, confidence in the new systems will improve. That should make it easier to get consent from an advertiser to share context, using this SDK approach to better protect consumers in RTB.

Ad tech and regulators are not on opposite sides. Introducing new steps to manage consumer context and positioning the SDK as the governance layer for consent between publishers and consumers could be the paths forward for bringing ad tech into the future of consumer privacy.

Follow Verve (@vervemobile) and AdExchanger (@adexchanger) on Twitter.

This post was syndicated from Ad Exchanger.