Digital Governance
cancel
Showing results for 
Search instead for 
Did you mean: 

Training For Consent as a Service

Mobile App Implementation Using CaaS

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:
    1. 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.
    2. 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:

CaaS Mobile.png

 

 

 

 

 

 

 

Labels (3)
Version history
Revision #:
1 of 1
Last update:
‎10-15-2019 12:50 PM
Updated by:
 
Contributors
Looking for more?
Ask in Discussions
Developers

Peer-to-peer support  and answers on developing CMS templates, modifying privacy scripts or building integrations.

Digital Experience Management

Find answers and ask questions on content management, personalization and targeting.

Digital Quality Management

Find answers and ask questions on WCAG and SEO quality management.

Digital Governance

Find answers and ask questions on consent and monitoring solutions.