INFOnline Consent String Notation¶

Note on the use of manual code notation

The use of the measurement procedure is the responsibility of the provider of digital sites, who is also responsible for fulfilling the information obligations specified in Art. 13 DS-GVO and for obtaining the consent of its users (§25 TTDSG) when using the pseudonymous measurement method. This also applies when using manual consent transmission.

1.1 Why a separate notation?¶

The TCF 2.0 framework provides its own notation for the storage and transmission of the consent, which provides a character string with dynamic length at the end. This is finally stored locally in the browser (LocalStorage or Cookies). For INFOnline, this character string is unsuitable for processing the measurement data, since it contains too much unnecessary information and does not allow a quick query of the Consent for a particular vendor without prior parsing.

For this reason, INFOnline has decided to store the consent for the downstream vendors in the measurement (IVW etc.) in a much more compact character string with a notation based on bit field arithmetic.

1.2 Representation of the notation¶

Below you will find an illustration of the INFOnline notation of the Consent String:

CMP - bit field	IO Consent - bit field	Additional Consent- bit field
Range: 00 - FF Possible values 00: no CMP 01: TCF 2. x compatible FF: other CMP	Range: 0000 - FFFF Possible values 0000: no Consent 0001: Purpose 1 0080: Purpose 8 0081: Purpose 1+8	Range: 0000 - FFFF Fixed Values 0000: no Consent

_{tab. 1: INFOnline Consent String Format}

Note

To ensure your data quality, it is necessary that at least 0081 is transferred to the measuring system for INFOnline/IVW.

1.3 Explanation¶

Like the tc-string in the TCF 2.0 framework, the INFOnline's Consent String has a dynamic length, but this is specified by the INFOnline. In contrast to the 'tc-string', the INFOnline's Consent String is considerably shorter in total. Currently the string has a defined length of 14 characters. In future, the INFOnline can increase this length as desired and thus extend it to include further vendors.

The character string has individual reserved fields with a defined start and end position. It is started at position 0 and the fields have the following meaning:

1st field(0-1): The CMP used. 2nd field (2-5): INFOnline Consent 3rd field (6-9): Additional Consent

Each field is hexadecimal coded and can accordingly accommodate the number ranges '00-FF' for a 2-digit range and '0000-FFFF' for a 4-digit range. Except for the first field (simple numeric enumeration), the remaining fields are bit fields. These store the Consent of the corresponding Vendor via bit field arithmetic.

1.4 Conversion table for Purposes in bit field¶

To determine the Consent for a Vendor, the conversion table shown below can be used and the example sketched next to it can be used:

Conversion table

	P1	P2	P3	P4	P5	P6	P7	P8	P9	P10	SFO*	SFO*
Purpose	1	2	3	4	5	6	7	8	9	10	1	2
Bit	2^0	2^1	2^2	2^3	2^4	2^5	2^6	2^7	2^8	2^9	2^10	2^11
Dec	1	2	4	8	16	32	64	128	256	512	1024	2048
hex	1	2	4	8	10	20	40	80	100	200	400	800

*Special Feature Options

note

The bit field is encoded in hexadecimal!

2.1 Prerequisites¶

In order for automated processing of a TCF 2.0 compliant Consent to take place within the measurement, a Publisher must use a TCF 2.0 compliant CMP. For this, the CMP must make the IAB TCF 2.0 Toolkit available in the browser at runtime via a stub function. Only when these requirements are met can automated processing and transmission take place. If you are not sure whether you meet the requirements, please contact your CMP provider. As a rule, all TCF 2.0 compliant CMPs work according to this requirement.

note

INFOnline recommends the following installation sequence. The CMP script should be loaded first in the page source text, followed by the Measurement Manager.

2.2 Transmission¶

The transmission of the Consent takes place in the request parameter ct and is sent with each measurement call, with the automatically determined or manually set Consent. If a Publisher neither has a TCF 2.0 compatible CMP nor sets the Consent manually, a default Consent value of '00000000' is transmitted.

2.3 Intermediate storage¶

The determined consent is stored in the form of a first-party cookie in the user's browser. The cookie has a maximum expiry date of 4 weeks.

In addition to the consent, the date of the consent decision is also stored in the cookie as a Unix epoch timestamp. If the user changes his or her Consent decision via the CMP over time, the measurement script automatically updates the value and date in the cookie.

2.4 Effects on the Publisher's Implementation¶

If the Consent is processed automatically via a TCF 2.0 compliant CMP, there is no implementation impact. You do not need to make any changes.

3.1 Prerequisites¶

Manual transmission of the Consent by a Publisher is necessary if:

the site processes data subject to the DSVGO and a legal basis must be obtained from the user for this purpose.
the site does not use a CMP or a non-TCF 2.0 compliant CMP for obtaining the legal basis.

3.2 Transmission by the publisher¶

For a manual transmission of the Consent without TCF 2.0, 2 variants are available to the Publisher via the INFOnline measurement script:

Variant 1: Transmission by a public method (long form).

<script type="text/javascript">
// Manual transmission of the consent
iom.consent('0000810000');
// Measurement call
iom.count({
  st: 'site ID', // site
  cp: 'pagecode', // pagecode
  co: 'comment' // comment
});
</script>

Variant 1: Transmission by a public method (short form).

<script type="text/javascript">
// Manual transmission of the consent
iom.ct('0000810000');
// Measurement call
iom.c({
  st: 'site ID', // site
  cp: 'page code', // page code
  co: 'comment' // comment
});
</script>

Variant 2: Transmission in the measurement call (long form).

<script type="text/javascript">
// Measurement call
iom.count({
  st: 'site ID', // site
  cp: 'page code', // page code
  co: 'comment' // comment
  ct: '0000810000' // Consent
});
</script>

Variant 2: Transmission in the measurement call (short form).

<script type="text/javascript">
// Measurement call
iom.c({
  st: 'site ID', // site
  cp: 'page code', // page code
  co: 'comment' // comment
  ct: '0000810000' // Consent
});
</script>

4.1 IAB Vendor 730 (INFOnline) Purpose 1 and 8¶

4.1.1 Legitimate interest¶

???+ info "Note

As of the effective date of the TTDSG on December 1, 2021, the Legitimate Interest of INFOnline Vendor 730 is no longer available. The Vendor will be expanded to include Purpose 1 as of November 24, 2021. If you continue to pursue the Legitimate Interest after the cut-off date, the pseudonymous measurement procedure must be implemented manually in the source code and deactivated in the Measurement Manager.

???+ info "Continue legitimate interest".

Should you continue to declare Legitimate Interest (pursuant to Art. 6 Par. 1 f) DSGVO) in the context of data collection for INFOnline (Vendor 730), please contact Customer Service. To do so, please send an email.

Accordingly, we have extended the technical requirements of our measurement procedure in such a way with the Measurement Manager that processing of user data, dependent on the granting of consent by the website visitor, takes place.

If you currently use the standalone solution of pseudonymous measurement, it is necessary to make the request only under Consent as of December 1, 2021. The implementation of the query (programmatic measure) is to be realized independently by the site. Due to the different systems - both in CMS and CMP - it is not possible to provide a standard template for this.