Having Access To Data Doesn’t Mean It Should Be Used

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 Yigael Chetrit, global CTO at SRDS.

Privacy regulations are moving quickly, and publishers need to make decisions about the kind of data to collect and how to monetize it.

But having access to data doesn’t always mean that it should be shared, or used for that matter. The real challenge comes with knowing what to do with the data once it’s been acquired. 

New data collected, new data use cases

First-party data is a broad term, and it’s important to be specific. Publishers need to think strategically about the data they’re collecting, and planning to collect, as they develop a better understanding of their audiences. 

The current subscription models that allow publishers access to first-party data will shift. In exchange for website access, consumers will provide more data than they have grown accustomed to, potentially including full names, email addresses, physical addresses, age, gender, occupation, interests, purchase behavior, as well as much more demographic info, depending upon the site and the vertical they represent. 


Not all data is created equal though. 

Different types of data require different minimum levels of consent - unambiguous consent and explicit consent. Unfortunately, though, the regulations are not clear on which data points fall into which bucket, although they do provide some guidance, especially on more sensitive data. 

Types of consent

Unambiguous consent means that there doesn’t need to be a specific opt-in selection. The consent is implied when the user supplies the requested information, as well as by a disclaimer explaining the usage of the data. 

For example, if a publisher requests that an email address be provided and there is a disclaimer  that the email may be used for promotional purposes, the email address can be stored and used once the user enters it, as they are implying their consent by entering their email in the first place. Generally speaking, digital identifiers, such as cookies, IP addresses, mobile IDs, and other similar types of data can permissibly be collected and used by acquiring this unambiguous consent.

On the contrary, explicit consent is exactly what it sounds like - a user needs to provide explicit consent to the publisher allowing them to capture and use this data. Furthermore, the consent must be an opt-in, not a pre-checked opt-out. 

Because of the sensitivity of this data requiring explicit consent, a good rule of thumb is, unless you absolutely need the data, don’t collect it. Some might say it’s okay to collect it and not use it, but if the data is not going to be used, there is no point in collecting it. As such, it will be important for publishers to align data strategies to new emerging technologies while maintaining users’ trust and abiding by privacy regulations.  

Thinking ahead

Realizing that publishers may be less likely to capture data with all of these new regulations in place, there will be a need for a new technology solution. An ideal solution would help publishers and advertisers alike, while also providing a service for the users and allowing them to have confidence that their identities are safe and secure. There are three areas that, when used together, would show the most promise in providing a unified solution - federated identity, blockchain, and cohort analysis. 

Federated Identity

Federated identity allows for the anonymized ID of an individual to be confirmed and linked to, across several identity management systems. Think of it as being able to log into several sites with your Gmail account once, but your identity is totally anonymized. This would solve the problem of being able to identify and segment new vs repeat visitors to your site, and would provide trust to the users that they cannot be identified.

Blockchain

Blockchain is the Play-Doh of technology. The fun molding clay we all played with growing up was not originally developed as a toy but as a wallpaper cleaner. Similarly, blockchain was developed as a multi-ledger system for Bitcoin. Since then, it has been leveraged to be used as the basis of an evolving advertising economy, to validate citizens’ identities in some third-world countries, and even to validate the ownership of an artist’s or musician’s content. 

Cohort Analysis

A cohort is defined as “a group of individuals having a statistical factor (such as age or class membership) in common in a demographic study.” For our purposes, the idea is being able to anonymously track these demographics, creating groups based on these demographics, and then comparing these groups and their relative behaviors over time. 

The viability of such a solution from a technical perspective is achievable, but the biggest real-world challenge for this type of solution to succeed is adoption, specifically by the users, in agreeing to use a federated identity partner. It would require a well-established company, such as Google, with pre-existing reach into the user, publisher, and advertiser worlds, to drive this initiative. 

Currently, Google is preparing to roll out Federated Learning of Cohorts, or FLoC, which centers around much of the same ideas discussed here in regards to cohort analysis. This could very well be the first step in multiple phases of achieving this type of solution. 

Combining these technologies could form one proposed solution, and there is no doubt that new solutions with varying offerings and strategic differentiators are on the horizon. I for one, am excited to see what solutions will come out of these latest challenges.

Follow SRDS (@srdsplatform) and AdExchanger (@adexchanger) on Twitter.

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!

 

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>