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 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 10 characters. In future, the INFOnline can increase this length as desired and thus extend it to include further vendors. Additional rules apply to apps, see section 5.

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

*Special Feature Options

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 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 0000000000 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. 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 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('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).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

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: '0000810000' // 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: '0000810000' // 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 TDDDG 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.

5. Consent string in apps (IOLib)¶

This section applies to the pseudonymous app library (IOLib) on iOS and Android, for measurement in Germany (session type SZM) and in Austria (session type OEWA).

5.1 Automatic or manual processing¶

If a CMP stores the TCF data in the app's native storage (UserDefaults or SharedPreferences, keys IABTCF_*), the IOLib builds the consent string itself. Otherwise you pass it with the setCustomConsent method (iOS, Android).

5.2 Structure¶

Use 10 characters in Germany and Austria. The IOLib only checks that the string consists of hex characters, is 2 characters plus a multiple of 4 long, and holds at least one 4-character block per vendor in the app configuration. A 10-character string meets this in both markets.

The bit field for vendor 730 is made up of Purposes 1 to 10 (conversion table in section 1.4). A purpose is set if

• vendor 730 has consent and the purpose has consent, or
• vendor 730 has legitimate interest and the purpose has legitimate interest.

Examples (Germany and Austria):

5.3 Effect on measurement¶

Before sending, the IOLib discards all measurement data whose bit field for vendor 730 does not contain at least Purpose 1 and Purpose 8 (0081). This does not apply if the CMP has set IABTCF_gdprApplies to 0. If that value is missing, the IOLib assumes that the GDPR applies.

The IOLib copies the consent into every event when the event is recorded. Events recorded before the consent is set carry the default consent and are discarded.

For Austria (ÖWA), the IOLib checks the consent as of iOS 2.5.0 and Android 2.4.0.

5.4 Hybrid apps with the CMP in the WebView¶

If the CMP runs only in the WebView, no TCF data reaches the app's native storage, and the IOLib cannot determine the consent automatically. Convert it in the WebView and pass it to the app:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

function toIoConsent(tcData) {
  let bits = 0;
  const add = m => Object.keys(m || {}).forEach(p => {
    if (m[p] && p >= 1 && p <= 10) bits |= 1 << (p - 1);
  });
  if (tcData.vendor.consents[730]) add(tcData.purpose.consents);
  if (tcData.vendor.legitimateInterests[730]) add(tcData.purpose.legitimateInterests);
  return '01' + bits.toString(16).padStart(4, '0') + '0000';
}

__tcfapi('addEventListener', 2, (tcData, ok) => {
  if (ok && ['tcloaded', 'useractioncomplete'].includes(tcData.eventStatus)) {
    const consent = toIoConsent(tcData);
    if (window.webkit && window.webkit.messageHandlers && window.webkit.messageHandlers.ioConsent) {
      window.webkit.messageHandlers.ioConsent.postMessage(consent); // iOS: WKScriptMessageHandler "ioConsent"
    } else if (window.IOConsent) {
      window.IOConsent.setConsent(consent); // Android: addJavascriptInterface(..., "IOConsent")
    }
  }
});

The example applies to Germany and Austria: the last four characters are always 0000.

In the app:

1. Store the received string and set it with setCustomConsent. On iOS, a WKScriptMessageHandler named ioConsent receives it; on Android, an object registered via addJavascriptInterface under the name IOConsent with a method setConsent(String) (annotated with @JavascriptInterface).
2. After every session start, before the first event, set the stored string again. Without this step, all events recorded before the WebView has loaded are lost.

Alternatively, use a CMP in the native part of the app that writes the TCF data to native storage. The IOLib then determines the consent automatically.

5.5 Checking¶

Check the implementation before release with debug mode enabled: on iOS with IOLDebugLevelTrace, on Android with IOLSession.setDebugModeEnabled(true). Only then does the IOLib report whether measurement data is discarded.

• Correct: consent (iOS) or getConsent() (Android) returns the expected string, and the log shows "Keeping N consent filtered events out of N total enqueued events" with both numbers equal.
• Errors: "Not a valid IO TCF consent" (wrong format), "did not pass the consent validation and will be deleted" or "Removed N events" with N greater than 0 (consent missing or incomplete), on iOS "Consent could not be set because the session is not active" (consent set before the session was started). On Android, calling setCustomConsent before initIOLSession throws an exception.

Disable debug mode before releasing the app.