Consent Docs
Open console

Key ideas

The eight ideas a newcomer needs, from project and property to keys and test records, each in a few sentences.

Concept3 min readFor everyone new to the product

Eight ideas cover most of what you see in the console. The examples follow a made-up retailer, Kaveri Stores. Every other term is in the glossary.

How they fit together#

Project                      your organisation's workspace
├── Purposes                 why you use personal data
└── Property                 one website or app
    ├── Consent forms        what you ask, in published versions
    ├── Keys                 what connects the site or app
    └── Consent records      what each person answered

Purposes belong to the project and are shared by all its properties. Forms and records belong to one property. A key belongs to one property, or works for every property of the project.

Project and property#

Project#

A project is your workspace. It comes from the PIEDAP platform: when you switch project there, the console switches with it. Nothing is shared between projects.

Kaveri Stores has one project for its shop website and its mobile app.

Property#

A property is one website or one app. A website is recognised by its origins, the web addresses it is served from. An app is recognised by its app id. Each property has its own consent forms, keys and records.

Kaveri Stores has two properties: the website at https://shop.example.in and the Android app.

Purpose, form and version#

Purpose#

A purpose is one reason you use personal data, such as analytics. It has a name and a description that visitors read, a key that your tags check, and a legal basis. Purposes are kept once for the project and reused by every form that offers them.

A consent form is one thing you ask people to agree to, with the exact wording you ask it in. The banner is a form of the type Cookie and tracking consent. A form belongs to one property for its whole life, so a record always shows which site asked the question.

Version#

You edit a form as a draft. Publishing freezes the wording, the purposes and the settings into a numbered version. Visitors only ever see a published version. A published version cannot be edited: to change something, you publish the next one.

Version 1 of the Kaveri Stores banner offers Analytics. The team adds a Marketing purpose and publishes version 2. Visitors who answered version 1 see the banner again, with a note of what changed.

A consent record is what one person answered on one form. It holds the decision for each purpose, the form version shown, the country, the law, the language and the time. It is filed under an identifier, by default a random id made in the visitor's browser. By default the identifier is stored only as a keyed hash, which cannot be turned back into the original value.

Meera Iyer opens the shop, allows Analytics and declines Marketing. A record cns_… is created with the status Partial, the form version 2, the country IN and the law DPDP.

Keys, test and live#

Key#

A key connects your site, app or server to your project. A publishable key (pk_…) goes in the page or the app, and answers only on the origins you list. A secret key (sk_…) stays on your servers and is shown once.

Test and live#

Every new key is a test key. It works on localhost and on the origins you list. Its records are marked as test and kept apart from live ones. Overview counts both together until you choose Live evidence there. They are deleted 30 days after their last change.

A live key writes live records, which are your evidence. A test key becomes live when the team that runs your deployment approves your request. The key string stays the same.

The developer at Kaveri Stores creates a test key, installs the banner on a staging page, answers it once, then asks for the key to go live.

↑↓ to move, Enter to open