Key considerations when comparing DMPs and CDPs to InfoSum’s UDP - Part Three

In our previous two blogs, we looked at the infrastructure and data types used by DMPs, CDPs and InfoSum’s UDP, as well as how each solution enables data collaboration and manage identity and data cleansing. In the final part of our blog series, we’ll look at how each solution supports data privacy, the use of second-party data and ensure that control is maintained. 

Data privacy

The focus on data privacy has never been more prevalent than it is in 2020. With GDPR introduced in 2018 and the ICO promising great enforcement, and the introduction of CCPA in January; data privacy is on the minds of every marketer when assessing data platforms.

Both DMPs and CDPs are designed to be compliant with data privacy laws on the basis that consent has been obtained. With correctly obtained consent in place, they can utilise the data for both insight and advertising targeting. In theory, this is true, but consent is difficult to manage, track and sustain. Cookie-based consent is coming under greater scrutiny from the Regulators and becoming less and less available as a result.

Data privacy sits at the very heart of InfoSum’s UDP. Raw identity data is never required during analysis, and no raw data ever passes between parties during analysis and segmentation. InfoSum utilises various differential privacy techniques to ensure that no individual’s identity is ever exposed during analysis. This approach greatly reduces the burden on compliance and helps businesses more readily adhere to both GDPR and CCPA.

Second-party data

As we have covered in a previous article, the use of second-party data to unlock new enrichment, validation and activation opportunities, is on the rise. However, neither DMPs or CDPs currently offer a privacy-simple way for data owners to make their data available as second-party data, or for brands, publishers and media agencies to access second-party data. This is due to the fundamental requirement of both DMPs and CDPs to centralise data, meaning that data must be physically pooled to unlock these rich data sources. 

This sharing and centralisation of data, results in the privacy, security and commercial risks previously outlined in part one of this series. 

As we covered in part two of this series, data collaboration becomes seamless through InfoSum’s UDP, so does the second-party data opportunity. Our federated architecture and various privacy controls make it easy and safe for companies to make their rich first-party data available to other parties as second-party data. 

Neither the data owner or the party wishing to access the second-party data have to share or pool their data assets. Instead, they can conduct statistical audience analysis across their first-party data and the second-party data any data, making powerful enrichment, validation and activation seamless.

Control

The value of data has never been greater, and therefore the commercial value wrapped up in that data has also never been higher. In the advertising industry, it has often been a requirement to give up this control to achieve cross-site tracking and targeting. Predominantly through the identity resolution process. 

In both a DMP and CDP, activating this data in the wider ecosystem requires the data to be ‘onboarded’ through a third-party. This process requires the raw data to be shared, at which point either cookies are synced, or a third-party ID appended.

During this sharing process, control of both the data and the identities in the data is lost completely. As we have covered extensively, InfoSum doesn’t require data to be shared to be used alongside second and third-party data. This ensures that parties retain complete control of their data and identity during onboarding, analysis, segmentation and activation.

Side-by-Side Comparison

That covers the full list of considerations businesses should make when comparing DMPs, CDPs and InfoSum’s UDP. To summarise all three blog posts, we’ve created a side-by-side comparison table. 

	DMP	CDP
Infrastructure	Centralised	Centralised	Federated / Decentralised
Data Types	Cookie-based third-party data	First and third-party data and capable of processing both online and offline data. However, requires data commingling.	First, second and third-party data. Additionally capable of processing both online and offline data.
Data Collaboration	None	None	Federated architecture and use of various privacy controls create a trusted and secure environment to connect first-party datasets between parties.
Identity Resolution	Cookie Syncing	Single identity graph.	Both deterministic and probabilistic identity resolution, based on personally identifiable information (PII). Flexibility to use multiple identity graphs and data sources to create a virtual identity graph.
Data Cleansing	None	Manual ETL required prior to upload.	Requires no changes to the original data, global schema and normalisation translate to unified language
Data Privacy	Consent based processing.	Consent based processing.	Multiple levels of privacy controls which greatly reduce the compliance burden. Including: For analysis, raw identity data is not stored No change in data owner as data remains decentralised and no raw data passes between parties Differential privacy concepts ensure individuals can't be identified
Second Party	Requires second-party data to be physically shared and centralised.	Requires second-party data to be physically shared and centralised	Second-party data can be securely analysed and used for enrichment, validation and activation. The non-movement of data and use of various privacy controls, greatly reduce the compliance burden.
Control	Activation requires loss of control, due to requirements to share data.	Activation requires loss of control, due to requirements to share data.	Parties retain full control of their data assets, as data is never shared or pooled.