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.
Note when participating in the agof daily digital facts
Please note the Technical requirements of agof.
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:
CMP - bit field | IO Consent - bit field | agof 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 Possible Values 0000: no Consent 0001: Purpose 1 0040: Purpose 7 0100: Purpose 9 0041: Purpose 1+7 0101: Purpose 1+9 0140: Purpose 7+9 0141: Purpose 1+7+9 |
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 and at least 0141
for agof.
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
note
The bit field is encoded in hexadecimal!
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
note
In principle, the purposes can be taken from the Global Vendor List of the IAB for TCF 2.0.
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.
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 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 |
|
Variant 1: Transmission by a public method (short form).
1 2 3 4 5 6 7 8 9 10 |
|
Variant 2: Transmission in the measurement call (long form).
1 2 3 4 5 6 7 8 9 |
|
1 2 3 4 5 6 7 8 9 |
|
4 Consent processing notes¶
4.1 IAB Vendor 730 (INFOnline) Purpose 1 and 8¶
4.1.1 Legitimate interest¶
???+ info "Note
1 |
|
???+ info "Continue legitimate interest".
1 |
|
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 |
|
4.2 agof studies Vendor 785 "Purposes 1,7,9" (Consent)¶
Processing is carried out in accordance with agof's instructions.