Conflicts & Unified Consents

Summary

The purpose of Conflicts & Unified Consents is to describe how to create a conflict.

What You'll Learn

In this document, you'll learn:

  • How to create a conflict
  • Unified Consents

How to Create a Conflict

A conflict is created when you get consents from two channels with opposing actions.

πŸ‘

Key Features of Conflict Resolution

  • The system automatically identifies conflicts and resolves them based upon a configurable algorithm.

  • You can look up a user on the dashboard and find all the consents, including any conflicts.

πŸ‘

Profiles and Conflicts

Note that you can store custom attributes on a subject profile. You cannot print these for security (privacy) reasons. Rather, those are brought into scope when you push that data to your internal systems using the Integrations function.

Conflict Flow

The endpoint for creating consents is /consents. A consent can be ACCEPT or REJECT.

When a conflict arises, that fires the resolution process, which automatically picks one consent based on predefined rules.

The example here uses USE_NEWER_ACTION resolution. That means whatever consent was given last is assigned to the subject.

Then a conflict data record is attached to the consent to show the conflicting data, where it came from, and when.

Create two channels

Here we create a conflict on purpose, to show how it works.

First, you need a brand. Then create two channels as it would make no sense to have opposing actions in the same channel (plus the logic won't fire). Refer to this link to see how to create a channel.

πŸ“˜

Channel Defined by IssuerURL

For the purpose of using an API, you can say that a channel is the same as the issuerURL. This is because the clientId and clientSecret are the same for all channels and for all brands. So you pick a channel by using its issueURL in a GET or POST.

Post First Consent

Post a consent to the /consents endpoint. You could use the JSON below. Notice here that for the target and vendor we post an ACCEPT action. In the conflicting consent we will create next we will put REJECT.

{
              	  "subject": {
               	        "verifiedId": "waterfall"
                	},
       	 	   "actions": [{
                        "target": "promotion",
               	        "vendor": "bank",
                        "action": "ACCEPT"
                	}],
                    "attributes": {}
       		}

Get consent

Now get the consent, just to verify it. Issue a GET to the endpoint /consents/unified/{subject ID}.

{
	'unifiedConsent': {
		'subjectId': 'waterfall',
		'brandId': '2BM8que5kNxLtIO8MblQhfOjlDt',
		'region': 'US',
		'actions': [{
			'target': 'promotion',
			'vendor': 'bank',
			'action': 'ACCEPT'
		}],
		'attributes': {}
	},
	'conflicts': []
}

Switch channel

Now create a new channel and change ACCEPT to REJECT in the JSON.

Post Second Consent

Post the conflicting consent using the issuerURL from the second channel.

{
                  "subject": {
                        "verifiedId": "waterfall"
                        },
                   "actions": [{
                        "target": "promotion",
                        "vendor": "bank",
                        "action": "REJECT"
                        }],
                    "attributes": {}
                }

Now notice 2 things:

  1. The computer used the USE_NEWER_ACTION resolution rule (contact wirewheel support about other rules in Wirewheel) to change the action to REJECT.

  2. Now you have a conflict object attached to the consent object.

{
	'unifiedConsent': {
		'subjectId': 'waterfall',
		'brandId': '2BM8que5kNxLtIO8MblQhfOjlDt',
		'region': 'US',
		'actions': [{
			'target': 'promotion',
			'vendor': 'bank',
			'action': 'REJECT'
		}],
		'attributes': {}
	},
	'conflicts': [{
		'type': 'REPEATED_ACTION',
		'resolution': 'USE_NEWER_ACTION',
		'actionsInConflict': [{
			'target': 'promotion',
			'vendor': 'bank',
			'action': 'REJECT',
			'consentId': '2BydV4JoX8YtDYK7B1kCRuOiVmI',
			'channelId': '2BvPbgt5UiIZfIBpjokr2kZcse5',
			'createdAt': '2022-07-15T10:51:18.970Z'
		}, {
			'target': 'promotion',
			'vendor': 'bank',
			'action': 'ACCEPT',
			'consentId': '2Byd0KCkyh2LW2KYEkzHkwaSLa8',
			'channelId': '2BVx73DNwzfxLcPTFhx9SpHdu1Q',
			'createdAt': '2022-07-15T10:47:14.787Z'
		}]
	}]
}

Unified Consent

A unified consent is a roll-up of all consents for that person across all channels within the brand. It also contains conflicts being resolved. So it collapses channels into their parent brand and shows actions by target and vendor as an array.

Here is a sample unified consent:

'unifiedConsent': {
		'subjectId': 'waterfall',
		'brandId': '2BM8que5kNxLtIO8MblQhfOjlDt',
		'region': 'US',
		'actions': [{
			'target': 'promotion',
			'vendor': 'bank',
			'action': 'REJECT'
		}],
		'attributes': {}
	},

Get a Unified Consent

You get a Unified Consent by GET 'https://api.demo.upcp.wirewheel.io/v2/consents/unified/<subjectiD>

{
	"unifiedConsent": {
		"subjectId": "2GLYTX8DTvHI8IeV26lxyozKK13",
		"brandId": "2BvS6wql6A2WUE0mHCC7Gj1vzVo",
		"channelIds": ["2BvSJifBX2K9ZAWlAseypkQaWKf"],
		"region": "CY",
		"actions": [{
			"target": "promotion",
			"vendor": "bank",
			"action": "ACCEPT"
		}],
		"attributes": {
			"dob": "2002-08-23",
			"email": "[email protected]",
			"sex": "f",
			"ipaddr": "255.255.255.254"
		},
		"lastUpdateDate": "2022-10-19T08:48:58.741Z"
	},
	"conflicts": []
}

Didn’t find what you were looking for?

Email our team: [email protected]?subject=UPCP