Kontakt zur INFOnline

Service Center im Überblick

Sie erreichen uns montags bis freitags zwischen 09:00 Uhr – 18:00 Uhr

Customer Service | e-Mail | 0228 / 41 0 29 77

Service Center IVW digital | e-Mail | 0800 / 58 91 788 

agof service center | e-Mail | 0800 / 41 0 29 77

MMC Service Center Webradio | e-Mail | 0800 / 41 0 29 29

Usercentrics | e-Mail

Print

Websensor

1. Preamble

This Integration Guide for INFOnline Measurement anonymous provides you with all the information you need to set up the INFOnline Measurement anonymous web sensor on your site.

The document explains the technical integration of the web sensor into your stationary site (WEB), your mobile-enabled website (MEW) and your site in the area of Connected TV (CTV).

Separate documents for the measurement of applications (apps) for each operating system will be provided at a later date.

Note

As the new measurement tag does not yet replace your existing INFOnline Measurement pseudonymous (SZMnG), please leave the INFOnline Measurement pseudonymous web sensor as is in your web page. INFOnline Measurement pseudonymous will be used as an opt-in panel in the future and, for example, be required in order to participate in the agof ddf.

2. Function

INFOnline Measurement anonymous was developed to enable complete and anonymous measurement of basic performance indicators (page impressions, visits and technical clients) without the use of unique identifiers (cookie IDs, advertising identifiers, fingerprints, etc.).

As a first party solution, the web sensor (JavaScript, which is integrated into the web page) communicates exclusively with the system component service platform, for which the website operator is technically responsible.

This service platform takes over the anonymisation of the measuring pulses and will also be capable of taking over control tasks (provision of a configuration) at a later date. Following anonymisation, the service platform automatically forwards the measuring impulse to the central components of the measuring system.

Anonymisation in the service platform ensures that the IP addresses of web page users are not transmitted to INFOnline. Within the scope of the measurement, neither IP addresses nor unique identifiers are used, nor are other interdependencies involved with the use of unique clients recorded and passed on. The basic idea behind INFOnline Measurement anonymous is to provide a measuring system for which the publisher is responsible and which is operated by the publisher itself, taking into account the principle of third-party independence. This means ensuring good testability and offering the highest possible degree of security against manipulation.

During the planned migration period (in 2021), the service platform will initially be operated at INFOnline. Only one DNS entry (CNAME1), which points to an INFOnline host name, is thus required on the customer side. The service platform will be made available at a later date (e.g. as a docker image or in another form) for participants who want to take over operation themselves. INFOnline will offer other solutions to measurement procedure participants who do not wish to take over operation of the service platform.

11INFOnline closely monitors developments in the field of ad and content blocking. INFOnline is aware of current developments enabling well-known ad blockers to identify hidden third-party content on web pages by means of DNS aliasing. INFOnline will thus once again use CNAMEs to critically scrutinise solutions in the future productive system in order to rule out unlawful filtering.

3. Implementation of INFOnline Measurement anonymous

3.1 Diagram of the implementation of INFOnline Measurement anonymous

3.2 Explanations for the implementation of INFOnline Measurement anonymous

Implementation of INFOnline Measurement anonymous begins with the registration of your site with INFOnline. Please use the Order Center in the INFOnline Customer Center to do so.

The next step is to validate your current locallist in the Customer Center. As the locallist should be up to date in order to generate the CNAMEs (communication interface), please check the validity of all existing entries and remove any duplicate entries.

Note

Please keep in mind that changes to the locallist have immediate effects on the existing pseudonymous measurement (SZMnG)!

If you use DNS Certification Authority Authorization (CAA) for your domains, please make sure that LetsEncrypt is on your whitelist. Only in this way can the corresponding SSL certificates be created by INFOnline in the further process.

Note

If you use CAA for your domains, LetsEncrypt must be on the whitelist.

INFOnline will generate the required CNAME entries from the existing locallist in the next step and make them available to you. In order to assist you as well as possible with the administrative effort and automation of INFOnline internal processes, INFOnline provides a CNAMES nomenclature:

data-<hash>.<domain> IN CNAME <Angebotskennung>-relay.iocnt.net

Example:

data-1a79a4d60d.example.com IN CNAME example-relay.iocnt.net

Note

The publisher has no possibility of deviating from this nomenclature.

In a later development step, INFOnline plans to enable the transmission of CNAMES via a user interface of the locallist module in the Customer Center.

The next step is to set this up on your relevant DNS server. Please also ensure that the CNAMES for third-party domains are registered accordingly with your business partners.

Beispiel:

For a locallist entry = meinesubdomain.fremddomain.de, the CNAME must be entered in the fremddomain.de domain area. This is the only way to ensure collection takes place in a first-party context.

After successful creation of the CNAMES by the publisher, INFOnline will set up the service platform system component.

As soon as the service platform system component is available, the publisher can start implementing the web sensor.

4. Regulations for implementing the web sensor

Please observe the requirements and guidelines of the respective institution during implementation.

The following content can be measured:

  • HTML (XHTML from version 1.0 and implementations using AJAX)
     

The web sensor can only be requested in the content frame. For a site with several frames, you must ensure that only one measurement impulse is triggered per frame set.

Note

Caution

As the INFOnline Measurement anonymous web sensor does NOT replace your existing pseudonymous measurement (SZMnG), please leave the pseudonymous integration (SZMnG) as is in your web page.

5. Implementing the web sensor

Implementation of the web sensor in your site is explained below. Installation consists of the following steps:

1. Loading the web sensor
2. Initializing the web sensors
3. Triggering the measurement request

Caution

Measurements can only be taken once all parts of the web sensor have been correctly installed.

5.1 Loading the web sensor

5.1.1 With preload

Integrating the web sensor with preload consists of two parts. In the first part, the web sensor is preloaded via a preload-link, that is built into the <head> of the web page. This ensures optimal and fast processing of the web sensor by the user agent.

In the second part, a bootstrap code is built into the <body> or <head> of the site to be measured. The task of the bootstrap code is to check the user agent. Information on the available JavaScript language standard (ECMAScript version) and the security context is queried in the process. This check results in the retrieval of a web sensor that is optimally tailored to the user agent deployed and the security context executed. The following two steps must be taken in order to integrate the bootstrap code on the web page:

1. You integrate a preload link in the <head> of the web page:

 
<!-- start preload of ima web sensor -->
<link rel="prefetch" as="script" href="https://<cdn-url>/sensor.modern.ncl.min.js" data-name="ima">
<!-- end preload of ima web sensor -->

Note

The placeholder <cdn-url> must be replaced by the URL of the CDN that hosts the various web sensor scripts. As the service platform is used as a CDN in the migration phase, please replace <cdn-url> with the domain’s CNAME created by INFOnline.

2. You can integrate the bootstrap code directly into the <head> or the <body> of the web page:

<!-- start bootstrap of ima web sensor -->
<script type="text/javascript">
!function(e,n,c,r,t,l,o,a,d){r=e.IMAGlobalObject=r,e[r]=e[r]||function(){(e[r].q=e[r].q||[]).push(arguments)},l=n.querySelector("[data-name="+r+"]"),t=t&&!l?t+"/sensor.modern.ncl.min.js":l.href,e[r].src=t,o=n.createElement("script"),d=e.crypto&&e.crypto.subtle,a="noModule"in o&&!/Edge/.test(e.navigator.userAgent),o.src=a?d?t:t.replace(".ncl",".lcl"):t.replace(".modern.n",".legacy.l"),n.head.appendChild(o)}(window,document,0,"ima");
</script>
<!-- end bootstrap of ima web sensor -->

5.1.2 Without preload

In contrast to installing the web sensor with preload the preload link is not specified in this case. You must nevertheless implement bootstrap code in the <head> or the <body> of the web page:

<!-- start bootstrap of ima web sensor -->
<script type="text/javascript">
!function(e,n,c,r,t,l,o,a,d){r=e.IMAGlobalObject=r,e[r]=e[r]||function(){(e[r].q=e[r].q||[]).push(arguments)},l=n.querySelector("[data-name="+r+"]"),t=t&&!l?t+"/sensor.modern.ncl.min.js":l.href,e[r].src=t,o=n.createElement("script"),d=e.crypto&&e.crypto.subtle,a="noModule"in o&&!/Edge/.test(e.navigator.userAgent),o.src=a?d?t:t.replace(".ncl",".lcl"):t.replace(".modern.n",".legacy.l"),n.head.appendChild(o)}(window,document,0,"ima", "<cdn-url>");
</script>
<!-- end bootstrap of ima web sensor -->

Note

The placeholder <cdn-url> must be replaced by the URL of the CDN that hosts the various web sensor scripts. As the service platform is used as a CDN in the migration phase, please replace <cdn-url> with the domain’s CNAME created by INFOnline.

5.1.3 Advantages and disadvantages of both variants and our recommendation

Both variants have advantages and disadvantages. Although the variante with Preload is faster when it comes to initialising the web sensor, the preload link must be statically incorporated into the <head> of the HTML page on every web page. A CMS with an appropriate template can assist with this. This variant is thus very suitable for single page application (SPA). You should select the variante without preload if you have no way of setting the preload link on the web page. The disadvantage of this variant is that the web sensor is available somewhat later during the page impression and the rendering of the web page by the user agent. As this delays all downstream processes within the measurement chain, we recommend using the variante with preload if possible.

5.1.4 Script names and versions

You will find a list of versions of the web sensor here. These depend on the supported JavaScript language version of the browser, and the availability of the native cryptographic interfaces and whether the web page to be measured is executed in a sufficient security context.

FilenameJavaScript versionCryptographyDescription
sensor.modern.ncl.min.jsEcmaScript Version 6nativeES6 version of the web sensor with native cryptography
sensor.modern.lcl.min.jsEcmaScript Version 6legacyES6 version of the web sensor with proprietary cryptography
sensor.legacy.lcl.min.jsEcmaScript Version 3legacyES3 version of the web sensor with proprietary cryptography

Caution

NEVER retrieve the above scripts manually using a <script> tag. The scripts only work in conjunction with the bootstrap code.

5.2 Initialising the web sensor

Before the actual measurement can be taken, the web sensor must be initialised. To do so, the init command with defined initialisation variables must be transmitted to the web sensor. The example below illustrates the command to be used:

ima('init', {
  st: 'example',
  cp: 'foo',
  dn: 'data-1a79a4d60d.example.com',
});

The initialisation supports the transmission of the parameters with both a short and a long key variant:

ima('init', {
  site: 'example',
  code: 'foo',
  serviceDomainName: 'data-1a79a4d60d.example.com',
});

5.2.1 Initialization variables

Below is a list of possible initialization variables and their meaning:

Short versionLong versionRequiredDefault valueDescription
cpcodeyesThe page code is used to identify one of the tagged pages. It is the basis for the subsequent category classification. You have a free choice of the name of the page codes. The page code may contain a maximum of 255 characters and may only contain alphanumeric characters (a-z, A-Z, 0-9) as well as the following special characters: comma (,), forward slash (/), hyphen (-), underscore (_), question mark (?) and hash (#). The total number of active page codes for the site should not exceed 3,000. The use of more than 3,000 active page codes is subject to a charge. More information on the specifications for page codes can be obtained in a separate document: INFOnline Configuration Guide.
dnserviceDomainNameyesCNAME of the service platform of the domain to be measured. The service platform is also used as host for the web sensor scripts (CDN) in the migration phase
stsiteyesDie The site ID assigned to your site; this is created and uniquely assigned by INFOnline; the ID is a maximum of 8 characters long.

Hinweis

Im Gegensatz zum pseudonymen Verfahren (SZMnG) unterstützt INFOnline Measurement anonymous die Sonderzeichen ? und # als Bestandteil des Seitencodes. Sie können diese somit NUR im Kontext einer Messung mit INFOnline Measurement anonymous nutzen. Im Kontext einer pseudonymen Messung (SZMnG) werden Codes an der Stelle dieser Zeichen gekürzt. Nur der vor diesen Zeichen stehende Code wird verwendet.

Note

During the migration phase and for the sake of comparability between the two measurement procedures, it makes sense for the page code to initialise the same page code in both the pseudonymous procedure (SZMnG) and INFOnline Measurement anonymous. From our point of view, this also makes sense in connection with the use of a tag manager.

Remark

Since the Comment parameter or theco-parameter may be used to process personal identifiers, it is no longer offered. The basis for this is that, unlike the pseudonymous measurement procedure (SZMnG), INFOnline Measurement anonymous is an anonymous measurement procedure.

5.3 Triggering the measurement request

You can trigger a measurement request with the relevant command after initialisation:

ima('count');

5.4 Notes regarding the use of a tag manager

Although it is generally possible to use a tag manager with INFOnline Measurement anonymous, INFOnline Measurement pseudonymous (SZMnG) and INFOnline Measurement anonymous should be populated with logically separated initialisation variables. INFOnline Measurement pseudonymous (SZMnG) and INFOnline Measurement anonymous generally contain different initialisation variables. In order to prevent unwanted side effects, we recommend you separate the initialisation parameters and also use logically separate containers to display both systems.

6. Third-Party Integrations

6.1 Google AMP

6.1.1 Preparations

As with the pseudonymous measurement (SZMnG), AMP pages are measured using an <amp-analytcis /> tag. This CustomElement and its implementation must be downloaded from the AMP CDN using the relevant script call:

<script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>

The service platform you have been assigned also provides you with the Iframe for communication between AMP and our web sensor. As you can use your site-specific CNAME to access this Iframe, the subdomain criterion, that Google specifies in this case is thus fulfilled.

Example:

  • AMP web page -> https://www.example.com/start.html
  • IFRAME web page -> https://data-1a79a4d60d.example.com/amp.html

Note

If you want to operate an individual solution for AMP, please arrange this with us in advance.

6.1.2 Measurement of AMP web pages

In order to measure AMP web pages you have to implement the <amp-analytics /> tag with an appropriate configuration:

<amp-analytics type="infonline_anonymous">
  <script type="application/json">
  {
    "vars": {
      "st": "example",
      "cp": "foo",
      "dn": "data-1a79a4d60d.example.com"
    },
      "requests": {
        "url": "https://data-1a79a4d60d.example.com/amp.html"
    }
  }
  </script>
</amp-analytics>

Hinweis

Please make sure to populate the <amp-analytics /> tag with the correct <... type="infonline_anonymous" /> type. Click here for the explanation of the individual variables.

6.1.3 Measurement of AMP stories

The measurement of AMP-Stories is taken in the same way as measurement of AMP web pages (page view) except that you must configure the relevant AMP-specific triggers:

<amp-analytics type="infonline" id="infonline-anonymous">
  <script type="application/json">
    {
      "vars": {
        "st": "example",
        "cp": "foo",
        "dn": "data-1a79a4d60d.example.com"
    },
    "requests": {
      "url": "https://data-1a79a4d60d.example.com/amp.html"
    },
    "triggers": {
      "storyPageVisible": {
        "on": "story-page-visible",
        "request": "pageview"
      },
    }
  }
  </script>
</amp-analytics>

7. Newsletter Integration

7.1 Limitations regarding the use of newsletter measurement

Similar to the pseudonymous measurement, the anonymous measurement also offers an integration for newsletter measurement. In order to enable the measurement of HTML newsletters, a functionally restricted HTTP call is used without the use of JavaScript. This measurement variant comes with a number of restrictions, which result from the lack of JavaScript functionality:

  • no collection of time-related metrics (visits, clients, etc.)
  • no collection of URLs or HTTP referrers with privacy-compliant automatic shortening
  • no collection of screen resolution and color depth
  • no consideration of DNT
  • reduced possibility of detecting false or automatic retrievals

Note

These technical limitations have a direct impact on the extent of usage data collected by your site. In the context of newsletter measurement, it is not possible to create visit and client metrics for technical reasons.

7.2 Integration

The HTTP call for HTML newsletters is implemented using a simple  tag that is built into the of the HTML newsletter:

<img src="https://[dsn]/relay.io?np=[code]&st=[site]" alt="ima_np" width="1" height="1" />

Note

  • To ensure correct measurement, the tag must be copied unchanged into the source code of the relevant newsletter.
  • Only the placeholders framed by [] may be changed.
  • Line breaks, upper and lower case letters must be kept!

7.3 Meaning of the placeholders

The following placeholders have to be adapted accordingly when integrating the <img> – tag into your newsletter:

ParameterMeaningRequiredDescription
[site]site IDyesThe site ID assigned to your site; this is created and uniquely assigned by INFOnline; the ID is a maximum of 8 characters long.
[code]newsletter codeyesThe code is used to identify the newsletter. It is the basis for the subsequent category classification. You have a free choice of the name of the codes. The code may contain a maximum of 255 characters and may only contain alphanumeric characters (a-z, A-Z, 0-9) as well as the following special characters: comma (,), forward slash (/), hyphen (-), underscore (_). The total number of active codes for the site should not exceed 3,000. The use of more than 3,000 active page codes is subject to a charge.
[dsn]service domain nameyesCNAME of the service platform of the domain to be measured.

Note

When processing the measurement of HTML newsletters, the hash in the [dsn] or in the CNAME is compared with the transmitted [site]. If the hash (hashed site ID) does not match the transmitted site ID, the request is accordingly rejected during processing.

7.4 Special treatment of the newsletter codes

All codes used in the newsletter measurement are prefixed with PUSH_ when entering the measurement system. The consequences of this special treatment are shown below using an example.

You use the following call in the HTML source code of the newsletter e-mail:

<img src="https://data-1a79a4d60d.example.com/relay.io?np=foo&st=example" alt="ima_np" width="1" height="1" />

When a user calls up the newsletter e-mail, a measurement pulse containing the code foo is sent to the anonymous measurement system. The anonymous measuring system automatically prefixes the code with PUSH_ when collecting the measuring pulse. Consequently, foo becomes PUSH_foo and is consistently transferred to the following downstream systems using the notation shown above:

  • Code allocation in the Customer Center
  • IDAS reporting
  • Data delivery to IVW and agof

Note

Please pay close attention to this, especially when assigning codes in the Category System 2.0, which you do in the INFOnline Customer Center (Code Management).