INFOnline Consent String Notation¶

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, agof, 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:

_{tab. 1: INFOnline Consent String Format}

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): agof 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:

_{Fig. 2: Conversion table}

1.5 Practical Example for an INFOnline Consent String¶

Here is a practical example of an INFOnline Consent String to illustrate the calculation basis and notation:

Assuming a publisher uses the INFOnline measurement, is a member of agof and measurement data for the daily digital facts (short: ddf) is collected and processed. In addition to the ddf, measurement data for the daily campaign facts (in short: dcf) is also processed. This means that the consent for two vendors must be determined and transmitted. Now, of course, you have to know what the minimum requirements are for these vendors so that there is a legal basis for processing the measurement data for these three vendors:

• INFOnline -> TCF 2.0 Purpose 8 (from December 2021 also Purpose 1)
• agof -> TCF 2.0 Purposes 1, 7 and 9

Now you can use the conversion table to determine the corresponding value for the individual Purposes:

For INFOnline, the hex values '0001' (for Purpose 1) and '0080' (for Purpose 8) result. The values are added together again and the hexadecimal coded bit field 0081 is obtained.

For agof, the hex values '0001' (for Purpose 1), '0040' (for Purpose 7) and '0100' (for Purpose 9) result. The values are added together again and the hexadecimal coded bit field 0141 is obtained.

Now you only have to add the three bit fields together and you will get the string '0000810141' for INFOnline and agof. Then the bit field for the CMP used is placed in front. Here it is important to distinguish whether the Consent was determined via a TCF 2.0 compliant CMP, no CMP or another CMP. If the Consent is processed automatically via a TCF 2.0 compliant CMP, the first field of the INFOnline Consent string always contains '01'. If you have not determined the Consent via a TCF 2.0 compliant CMP, the value 'F' would appear here. If you have not used a CMP to determine the Consent, the first field must contain the value '00'.

Assuming that the Consent is processed automatically, this results in an INFOnline Consent String with the value '01008100141'. This Consent String also represents the minimum of possible information for a legal basis for processing the measurement data for all two Vendors.

2 Automatic processing of TCF 2.0 compliant Consent¶

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.

2.2 Determination¶

Here you will find a flow chart showing the automatic determination, processing and transmission of the Consent Information in the Measurement Script:

Here is a flowchart of how the INFOnline extracts and processes the Consent via the TCF 2.0 API:

2.3 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.4 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.5 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. manual transmission of the Consent by the Publisher, only valid pseudonymous standalone measurement¶

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 is a member of agof and participates in the daily digital fact and/or the digital campaign facts.
• 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).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

<script type="text/javascript">
// Manual transmission of the consent
iom.ct('0000810141');
// 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).

1
2
3
4
5
6
7
8
9

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

1
2
3
4
5
6
7
8
9

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

4 Consent processing notes¶

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

4.1.1 Legitimate interest¶

???+ info "Note

1

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".

1

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.

4.1.2 Consent under standalone solution pseudonymous measurement¶

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.

???+ info "Note

1

If no programmatic measure is taken, the data collection/processing is processed by default under legitimate interest in the INFOnline/IVW context.

4.2 agof studies Vendor 785 "Purposes 1,7,9" (Consent)¶

Processing is carried out in accordance with agof's instructions.