Consent as a Service (CaaS)
The Consent as a Service Privacy Information Collector (CaaS PI Collector) is used to connect consent data between the Crownpeak consent database and a customer’s application using a GET or POST request.
This document explains how to get started with the CaaS PI Collector and includes an example of how to implement CaaS into an android application.
Prerequisites
To get started implementing CaaS into your application, you will need the items below. Contact your Customer Success Manager if you need help locating these items.
- An account for Company/User.
- A Valid CaaS token to send data to CaaS collectors. Found here: https://caas.evidon.com/application/tokens
- Choose and assign from default RecordTypes to each application. (Can create custom recordtypes in future releases).
Definitions
In this documentation, these terms are defined as follows:
- Vendor/Tracker: 3rd party SDKs (analytics, ad networks, affiliate tools, etc.) and internal user tracking.
Compliance
To be in compliance, you can ask for user’s prior consent and honor their decision of giving consent/withdrawal of consent related to tracking.
- Prior Consent: You must get a user's consent before any trackers are started.
- Withdrawal of Consent: You must do one of these two things:
- If a tracker is enabled and can be disabled or stopped in the current session, that tracker must be turned off in a way that it is no longer tracking the user in this session and future sessions.
- If a tracker is enabled and it can NOT be turned off or disabled in the current session, you must notify the user that they will continue to be tracked until the app is restarted. Then when the app is restarted, don't start the specified trackers.
Implementation
GET – i.evidon.com/api/v1
This endpoint has five expected query string values: c, r, u, d, a.
This endpoint has one expected header: token.
The applicationId (a), companyId (c), are not needed if a token is sent, as the values from the token lookup overwrite the values from the query string. However, the values themselves are required, so if a token is not there then they are required fields.
Query String params:
c – companyId: (optional) internal identifier for the customer that is associated at onboarding.
r - recordType: this is the identifier for the type Record that are defined in the Application
u - userId: Unique userId (Adverstising ID or unique ID from Company)
d - data: this is the customer defined payload of json. A base64 encoded as well as URI encoded string is expected here.
a - applicationId: internal identifier for the customer that should be assigned on onboarding/ application creation in caas UI.
Headers:
token: 863effdf6cf94d2d9971640dcc393ae3
Status Codes:
204 – Successfully collected the request.
200 – Request hit the wrong endpoint but did not error.
And as far as generating the base64 encoded string, something along the lines of:
let jsonObj = {"testkey": "testvalue"};
let stringJsonObj = JSON.stringify(jsonObj);
let encodedJsonObj = Buffer.from(stringJsonObj).toString('base64');
let uriEncodedJsonObj = encodeURI(encodedJsonObj);
POST – i.evidon.com/api/v1
This endpoint has two expected headers: token, content-type.
This endpoint expects a JSON body with five values: c, r, u, d, a.
Status Codes
204 - Successfully collected the request.
200 - Request hit the wrong endpoint but did not error.
Headers
token - This should have been assigned to the customer during onboarding. These tokens map back to an applicationId and companyId.
content-type - this should be application/json every time.
Body
c - companyId: this is our internal identifier for the customer that should have been assigned at onboarding.
r - recordType: this is the identifier for the type of record the customer is sending us, per what they have already defined without our tool for setting up recordTypes. This is used to make the d param interpretable.
u - userId: this is the identifier that is used for tying the consent record back to the user. If one is not passed in, one is generated based off of the user's IP and useragent string.
d - data: this is the customer defined payload of json. This is json object wrapped in the parent json that is the rest of the body.
a - applicationId: this is our internal identifier for the customer that should have been assigned at onboarding.
The applicationId (a), companyId (c), are not needed if a token is sent, as the values from the token lookup overwrite the values from the query string. However, the values themselves are required, so if a token is not there then they are required fields.
An example request might look something like: https://i.evidon.com/api/v1
With the headers:
- token: 863effdf6cf94d2d9971640dcc393ae3
- content-type: application/json
With the body:
{ "c":242,
"r":"customRecordType",
"u":"abcdefg123456",
"a":"1",
"d":{ "testakey":"testavalue",
"testbkey":"testbvalue",
"testckey":"testcvalue",
"testdkey":"testdvalue" }
}
Example from Timber Application on CaaS implementation using Retrofit.
