SZM tag
Page codes
A page code is a string of characters that can be freely selected by the web page provider and stored in the SZM tag 2.0. It is used to identify the tagged web pages and is the basis for the subsequent category/characteristic assignment in the Customer Center according to the Kat 2.0 category model. When evaluating the page count, the page codes are recorded and added up by the system. This allows aggregation of page impressions and visits to (thematically or similarly) related web pages.
In the Kat 2.0 category model, one characteristic of each category is maintained per page code.
Maintenance of categories, i.e. assignment of page codes to categories in Kat 2.0, must be carried out by the web page provider in the INFOnline Customer Center. This is explained in the Configuration section in the Customer Center.
Number of page codes
The total number of active page codes should not exceed 3,000.
If you need more than 3,000 active page codes for operational or other reasons, a fee will be charged for the service.
INFOnline uses an alarm system to indicate when the maximum number of page codes has been exceeded. You will be informed automatically if your site exceeds or even approaches the limit of 3,000 active page codes.
Length of page codes
A page code may contain a maximum of 255 characters!
If a page code has more than 255 characters, it is truncated after 254 characters and a “+” is inserted as the 255th character. If page codes differ only in the part that has been truncated, they cannot be distinguished in the SZMnG system (new generation of scalable central measuring procedure) and thus cannot be assigned separately.
Special characters in page codes
- Permitted characters: a-z, A-Z, 0-9, comma “,”, hyphen “-”, underscore “_”, slash “/”
If characters other than those listed above are used, those characters are replaced by a dot at the beginning of the measurement chain.
- Characters that are not recommended: Question mark “?” and hash “#”
If a question mark “?” or a hash “#” is used in the page code, the code will only be applied up to this special character. The special character itself and all following characters are discarded.
- Characters that are not recommended: Backslash “\”
If a backslash “\” is used in the page code, a different modification is carried out depending on the browser in which the SZM tag 2.0 is called. Please do not use a backslash.
Reserved strings
For some of our services, it is necessary to reserve certain strings at the beginning of a page code (prefix).
These are as follows:
- Newsletter = Push_ (includes an underscore)
HTML newsletters can be counted in our measuring system. To differentiate, a page code is prefixed with the string “Push_” when it is used in a newsletter. - Page codes from hybrid apps = ___hyb___ / ___hyb2___ (contains 2 x 3 underscores)
This string is used for automatic synchronization of code assignment within a hybrid app and must only be used as an automatic prefix for hybrid page codes. - Page code identification for mobile content = szmmobil_ (contains an underscore)
- Page code identification for INFOnline = ___saw___ (contains 2 x 3 underscores)
Note
- The strings “___hyb___” and “___hyb2___” must not be used as page code!
- The string “___saw___” must not be used at the beginning of a page code!
Structure and notes
The SZM tag 2.0 consists of two code parts:
- External JavaScript file (inclusion in <head> (…) </head>)
- JavaScript variables (inclusion in <body> (…) </body>)
Note
- To ensure correct measurement, the SZM tag 2.0 must be transferred unchanged to the source code of the site being measured.
- Only the specified variables may be changed.
- Line breaks, upper and lower case letters should be retained.
Implementation
Head implementation
<script type="text/javascript" src="https://script.ioam.de/iam.js"></script>
Alternative implementation of the JavaScript as “minified”
<script type="text/javascript" src="https://script.ioam.de/iam.js?m=1"> </script>
Body implementation
Add the variables “site ID” (st) for your site and the “page code” (cp) required.
<!-- SZM VERSION="2.0" -->
<script type="text/javascript">
var iam_data = {
"st":"site id", // site/domain
"cp":"page code", // code
"sv":"ke", // No invitation ad is delivered.
"co":"comment", // comment
"sc":"yes" // MCVD activation
}
iom.c(iam_data);
</script>
<!--/SZM -->
Errors may occur in AJAX applications related to adblockers if the “iom” object is not found. In this case we recommend the following implementation of the SZM tag:
<!-- SZM VERSION="2.0" -->
</strong><script type="text/javascript">
if (window.iom) {
var iam_data = {
"st":"site id", // site/domain
"cp":"page code", // code
"sv":"ke", // No invitation ad is delivered.
"co":"comment", // comment
"sc":"yes" // MCVD activation
};
iom.c(iam_data,1);
}
</script>
<!--/>SZM-->
A tag generator that allows you to create the tag required quickly and clearly with the site ID of the selected site can be found in the Customer Center. You select whether the FRABO variable should also be included and you can easily generate the SZM tag 2.0 for your site with any page code.
Note
- If you use other scripts in your pages, do not use the variables “iam_data” and “iom.c” there.
- If you create and implement additional variables, please use at least 3 characters for the name of these additional variables. This is the only way to ensure that INFOnline does not overwrite undocumented variables when they are used.
- Download of the external JavaScript “iam.js” and delivery via your own servers leads to incorrect measurement results.
Variables for the SZM Tag 2.0
Abbreviation | Meaning | Description |
st | Site ID | The site ID assigned to your site; this is created by INFOnline and assigned once; the ID is a maximum of 8 characters long. |
cp
| Page code
| The page code is used to identify tagged pages. It is the basis for subsequent category assignment. You are free to choose the page codes. A page code may contain a maximum of 255 characters and consist only of alphanumeric characters (a-z, A-Z, 0-9) and the following special characters: comma (,), slash (/), hyphen (-), underscore (_). The total of active page codes for the site should not exceed 3,000. There is a charge for using more than 3,000 active page codes. More information about the specifications for page codes is available in a separate document: INFOnline Configuration Guide. For test purposes, “cp” can be replaced by “xp”. In this case, the requests are rejected by the measuring system. |
sv | FRABO control | “sv”:”ke” NO ad invitation is delivered on the page. The variable “sv” is always set to “ke” by default in SZM tag 2.0. You can find more information on how to use the Frabo control in a separate document – Frabo Integration Guide (only relevant for agof customers!) The Frabo variable is NOT implemented for Connected TV. |
co | Comment (optional) | The call can include a comment, but this is not evaluated by INFOnline and is not displayed in the analysis tools. If you use the service to provide the log files centrally, you can evaluate the comments in your own tools. |
ps | Privacy settings (default “lin”) | Measurement of your site is fundamentally carried out on the legal basis of legitimate interest in accordance with the EU General Data Protection Regulation (EU GDPR). If this is not what you want, please contact our Customer Service team. |
sc | MCVD activation | The parameter “sc” is used to activate the SZM MCVD add-on. The value “yes” must be specified for this. For more information, see section 2.7. |
Note
- Do not change any variables.
- When using the variables, please be sure to separate the transition from the first to the last variable with a comma.
- However, the line of the last variable must not contain a comma.
Alternative transmission methods
SZM tag 2.0 offers a choice of different transmission methods for transmitting the measuring pulse (i.e. the measuring pixel request) to the measuring system. For certain website architectures, it may be necessary to change the transmission mode.
The content of <Transmission mode> can be set to the value you want.
<!-- SZM VERSION="2.0" -->
<script type="text/javascript">
var iam_data = {
"st":"site id", // site/domain
"cp":"page code", // code
"sv":"ke", // No invitation ad is delivered.
"co":"comment", // comment
"sc":"yes" // MCVD activation
}
iom.c(iam_data,transmission method);
</script>
<!--/SZM -->
There are three values to choose from:
- Transmission method 1 (iam_data,1)
Transmission of the data by means of the AppendChild() method.
- Transmission method 2 (iam_data,2)
Transmission of the data by means of the newImage() method.
- Transmission method 0 (iam_data,0) or (iam_data)
Transmission of the data via document.write(). Default method is set automatically if no alternative is selected.
Example with transmission method 1
<!-- SZM VERSION="2.0" -->
<script type="text/javascript">
var iam_data = {
"st":"site id", // site/domain
"cp":"page code", // code
"sv":"ke", // No invitation ad is delivered.
"co":"comment", // comment
"sc":"yes" // MCVD activation
}
iom.c(iam_data,1);
</script>
<!--/SZM -->
We recommend using transmission method 1(iam_data,1) especially if your WebApplications use technologies like AJAX for user interaction.
Dynamic web content measurement
Dynamic web content refers, for example, to AJAX-based web pages that allow HTTP requests to be made while the web page as a whole is already displayed. This allows individual content to be reloaded (e.g. when scrolling through an image gallery) without having to reload the entire page.
Reloading of individual content can be measured by SZM tag 2.0. For this we recommend transmitting the data to the measurement server via the AppendChild method (iam_data,1) or the newImage method (iam_data,2) in SZM tag 2.0.
It must also be ensured that the iom.c method in the BODY part of SZM tag 2.0 is reloaded each time web content is reloaded.
Multistage Client & Visit Detection (add-on to SZM procedure)
Multistage Client & Visit Detection (hereafter referred to as MCVD) is an extension of the SZM measurement procedure for optimizing determination of the clients and visits performance indicators.
This add-on to SZM measurement is used to determine clients and visits as accurately as possible, even in an environment with low acceptance of 3rd party cookies and data-protection-related weak fingerprint characteristics for the familiar hash method.
The MCVD is a multi-stage procedure in which, in addition to the characteristics already described for determining clients and visits, a 1st-party cookie can also be used to differentiate a client hash in more detail.
If this option has been activated by you for your site, this 1st-party cookie can be used if a client does not accept 3rd-party cookies and recognition via a client hash should only be possible to a limited extent in a special environment.
1st option:
3rd-party cookie
2nd option:
Fingerprint (client hash)
3rd option:
1st-party
cookie
The procedure for client and visit detection that provides the highest accuracy is always selected – priority is still given to detection via the cross-site 3rd-party cookie. The fingerprint can be differentiated more precisely with the help of the 1st-party cookie and thus clients and visits can be recorded even in more difficult environments.
Why is MCVD important?
As experienced measurement service providers, we at INFOnline are continuously monitoring technical changes on the market. Of course, we look specifically at changes that have or could have a direct or indirect impact on the measurements collected via SZMnG.
In addition to the new data protection conditions within the framework of the GDPR and the technical changes in the market – e.g. in the mobile environment with some Safari browsers – the preparations for upcoming browser updates (e.g. Firefox version 65) in particular have prompted us to implement an extended function for recognizing clients and thus also visits. Recording of these important performance indicators benefits from strong recognition characteristics. We therefore generally recommend that you activate the MCVD process for your sites (web + MEW).
MCVD activation
Activation of the MCVD as an extension to the previous client and visitor detection procedure can be completed by means of a small adjustment to the SZM tag you have installed. To do this, you need only add the new parameter “sc” (meaning set cookie) to your tag. You then activate the MCVD procedure by assigning the value “yes” to the “sc” parameter (see sample integration). This expansion should be implemented across the site if possible. Once this is done, an additional 1st-party cookie is set for clients visiting your site. MCVD is now activated for your site. Please note that on activation of MCVD, a 1st-party cookie is regularly set and transmitted to the measuring system.
The 1st-party cookie information is transmitted regardless of whether the 1st-party cookie is actually used for visit and client detection as part of the MCVD procedure. Based on this additional information, we recommend that you modify your data protection declaration (DPD).
When MCVD is activated by setting the new “sc” parameter, the information about the 1st-party cookie is passed on to INFOnline and to service providers and systems that carry out further processing.
After initial activation for a client, MCVD is used domain-wide for that client. Once a 1st-party cookie has been recorded for a domain of your site, the cookie information is included in future requests for this domain. The “sc” variable will be used in future to send information to the 1st-party cookie. Please use the parameter only for transmitting information to the 1st-party cookie.
Sample integration
HEAD integration:
<script type="text/javascript" src="https://script.ioam.de/iam.js"> </script>
BODY integration:
<!-- SZM VERSION="2.0" -->
<script type="text/javascript">
var iam_data = {
"st":"infonlin", // site/domain
"cp":"EXAMPLE", // code
"sv":"ke", // No invitation ad is delivered
"co":"comment", // comment
"sc":"yes"
}
iom.c(iam_data, 1);
</script>
<!--/SZM -->
What else do I need to consider when activating MCVD?
Adaptation of the data protection declaration (DPD)
If you wish to use MCVD on your site, we recommend that, in addition to activating the extension in the tag, you also adapt your data protection declaration (DPD).
We have adapted our draft (web) data protection declaration for you for this purpose.
The following sections of bold text have been added to the web data protection declaration in Section 2 Type of data under the bullet point “a randomly generated client identifier”:
“Range processing uses either a third-party cookie, a first-party cookie, a “local storage object” or a signature created from various pieces of information transmitted automatically from your browser to recognize computer systems.”
Checklist for MCVD on your site
- Adjustments made to your data protection declaration (DPD)
- MCVD activation in SZM tag on your entire site (“sc”:”yes”)
Parallel SZM measurement in different countries
If a parallel measurement is to take place in Germany and Austria, the script calls must be built in directly via the tag in the body.
Please note that the implementation of the SZM tag described below is only required if you are also a member of “Österreichische Webanalyse (ÖWA)” (Austrian Web Analysis) and would like to arrange for parallel measurement in this context.
It is imperative here that you have an identifier from INFOnline and an identifier from ÖWA (in the format: “at_x_example”).
<!-- INFOnline -->
<script type="text/javascript" src="https://script.ioam.de/iam.js"> </script>
<script type="text/javascript">
if (window.iom)
{
var iam_data = {
"st":"testidentifier",
"cp":"test",
"ps","lin",
"sv","ke",
"co":"",
"sc":"yes"
};
iom.c(iam_data,1);
}
</script>
<!--/INFOnline -->
<!-- OEWA -->
<script type="text/javascript"src="https://script-at.iocnt.net/iam.js"></script>
<script type="text/javascript">
if (window.iom)
{
var oewa_data = {
"cn":"at", // country
"st":"site id", // site/domain
"cp":"code/section", // code/section
"sv":"mo", // oewa-mobile-flag
"sc":"yes" // MCVD activation
};
iom.c(oewa_data,1);
}
</script>
<!--/OEWA -->
Configuration of the SZM tag 2.0 for hybrid app measurement
built into the native app frame and via the SZM tag 2.0 that is implemented in the web content to be displayed in the hybrid app.
To activate the SZM tag for hybrid measurement, the iom.c method must be changed to iom.h. This does not affect the measurement of web content outside the app.
Browser calls are therefore still counted properly.
Example (iom.h()):
<!-- SZM VERSION="2.0" -->
<script type="text/javascript">
var iam_data = {
"st":"site id", // site/domain
"cp":"page code", // code
"sv":"ke", // No invitation ad will be delivered.
"co":"comment", // comment
"sc":"yes" // MCVD activation
}
iom.h(iam_data,<transmission mode>*);
</script>
<!--/SZM -->
The integration guides for hybrid app measurement can be found in the download area of the INFOnline web page.
AMP analytics
To measure the number of hits on AMP web pages (https://www.ampproject.org), a special analytics tag (described later in this section) is required, which must be supplemented by the respective site ID, the page code and a URL. The URL must link to a web page that contains a special SZM tag and must itself be delivered via HTTPS. This web page must be delivered through a different subdomain to the AMP web page and must be included in the locallist. No invitation ad (agof BFE) is delivered on AMP web pages.
Insert in the header of the web page
<script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>
Measurement of AMP web pages (pageview)
<amp-analytics type="infonline" id="infonline">
<script type="application/json">
{
"vars": {
"st": "site id",
"co": "comment",
"cp": "code"
},
"requests": {
"url": "https://sub.example.com/amp-analytics-infonline.html"
}
}
</script>
</amp-analytics>
Please ensure that you do not insert additional line breaks and that you fill the variables (“vars”) “st” and “cp” with the respective values:
- st= site ID
- cp= corresponding page codeof the web page
- co= comment (optional)
Please note that the “url” property must point to a subdomain of your choice and provide the content of the HTML web page shown in Section 5 (below). You can choose any name for the HTML file.
AMP stories measurement
<amp-analyticstype="infonline">
<script type="application/json">
{
"vars": {
"st": "site id",
"co": "comment",
"cp": "code"
},
"requests": {
"url": "https://sub.example.com/amp-analytics-infonline.html"
},
"triggers": {
"storyPageVisible": {
"on": "story-page-visible",
"request": "pageview"
},
}
}
</script>
</amp-analytics>
Please ensure that you do not insert additional line breaks and that you fill the variables (“vars”) “st” and “cp” with the respective values:
- st= site ID
- cp= corresponding page code of the web page
- co= comment (optional)
Please note that the “url” property must point to a subdomain of your choice and provide the content of the HTML web page shown in Section 5 (below). You can choose any name for the HTML file.
If you want to measure even more AMP story interactions such as calls for the “bookend” etc., you can find the corresponding documentation here. The only important thing is that the request must be of the type “pageview”.
Measurement of events (e.g. video playback)
<amp-analyticstype="infonline">
<script type="application/json">
{
"vars": {
"st": "site id",
"co": "comment",
"cp": "code"
},
"requests": {
"url": "https://sub.example.com/amp-analytics-infonline.html"
},
"triggers": {
"myVideoPlay": {
"on": "video-play",
"selector": "#myVideo",
"request": "event",
"vars": {
"ev": "play"
}
}
}
}
</script>
</amp-analytics>
Please ensure that you do not insert additional line breaks and that you fill the variables (“vars”) “st” and “cp” with the respective values:
- st= site ID
- cp= corresponding page code of the web page
- co= comment (optional)
Please note that the “url” property must point to a subdomain of your choice and provide the content of the HTML web page shown in Section 5 (below). You can choose any name for the HTML file.
Please note that the specified selector for your video element must be adapted by you.
Please ensure that you transfer the correct events. You will find a corresponding mapping below:
AMP video event | INFOnline video event |
video-play | play |
video-pause | paus |
video-ended | sple |
Special HTML web page with SZM tag
< !DOCTYPE html>
< html>
<head>
<script src=https://script.ioam.de/iam.js></script>
</head>
<body>
<script>
var match,
pl = /\+/g,
search = /([^&=]+)=?([^&]*)/g,
decode = function (s) { return decodeURIComponent(s.replace(pl, " ")); },
query = window.location.search.substring(1);
var params = {};
while (match = search.exec(query)) {
params[decode(match[1])] = decode(match[2]);
}
if (params.type === 'event') {
iom.i(params, 2);
iom.e(params.ev);
} else {
iom.c(params, 2);
}
</script>
</body>
</html>
Note
Please do not modify the source code shown above. Changes will inevitably result in your AMP integration not being measured.
AMP integration with TCF 2.0 Requirements
For the integration of a TCF 2.0-compliant CMP in combination with AMP and INFOnline Measurement pseudonymous, it is necessary to check in advance whether the publisher is using a CMP which is also supported by AMP. If this is not the case, TCF 2.0 cannot be processed automatically. In addition, the publisher should always use the latest version of AMP. The following iframe content should also be hosted by the publisher on a sub-domain of the site:
<!DOCTYPE html>
<html lang="en">
<head>
<script src="//script.ioam.de/iam.js?m=1"></script>
<title>INFOnline AMP integration</title>
</head>
<body>
<script src="//script.ioam.de/amp.js?m=1"></script>
</body>
</html>
Integration
For the integration of TCF 2.0 the publisher requires the custom element <amp-consent> and must implement it according to the specifications of the CMP manufacturer (here is an example with Consent Manager):
<amp-consent id="ConsentManager" layout="nodisplay" type="ConsentManager">
<script type="application/json">
{
"postPromptUI": "postPromptUI",
"clientConfig": {
"id": "...Your CMP ID...",
"params": ""
}
}
</script>
<div id="postPromptUI">
<button on="tap:ConsentManager.prompt()" role="button">Manage privacy settings</button>
</div>
</amp-consent>
The custom element <amp-analytics> then only has to be declared in a slightly modified form to the regular installation
<amp-analytics data-block-on-consent="_till_responded" type="infonline" id="infonline">
<script type="application/json">
{
"vars": {
"st": "site id",
"co": "comment",
"cp": "code"
},
"requests": {
"url": "https://sub.example.com/amp-analytics-infonline.html"
}
}
</script>
</amp-analytics>
Note
The HTML attribute data-block-on-consent controls when a measurement is triggered. The measurement pulse is triggered by the _till_responded value as soon as the CMP has detected a consent decision (negative or positive). Use of the values _till_accepted or _auto_reject, which are described in the AMP documentation accordingly, automatically leads to an undermeasurement!
Facebook instant articles
Facebook instant articles can be measured via iframe. Please refer to the documentation at Facebook for developers.
The web page loaded in the iframe must be delivered via the subdomain “fbia” (fbia.domain.tld) and be included in the locallist so that separate IVW publication of the measurement is possible.
Sample implementation in instant article:
<figure class="op-tracker">
<iframe src="https://fbia.domain.tld/trackingcode"></iframe>
</figure>
On this web page, the SZM tag is implemented as follows:
1. HEAD integration (without line break!)
<script type="text/javascript" src="https://script.ioam.de/iam.js"> </script>
2. BODY integration
<!-- SZM VERSION="2.0" -->
<script type="text/javascript">
var iam_data = {
"st":"siteid", // site/domain (MEW)
"cp":"pagecode", // code
"sv":"ke", // No invitation ad is delivered.
"fb":"1", // tag for Facebook instant articles
"co":"comment" // comment
}
iom.c(iam_data,1);
</script>
<!--/SZM -->
Note
Please ensure that you do not insert additional line breaks and that you fill the variables “st” and “cp” with the respective values:
- st= site ID of the mobile enabled website (MEW)
- cp= corresponding page code of the web page
- co= comment (optional)
Newsletter measurement
Integration
In order for newsletter requests to be collected and processed fully in our pseudonymous measurement process, the newsletter script must be included as follows:
1. Paste the newsletter script into the <body> of the HTML newsletter:
<img src=”https://de.ioam.de/tx.io?st=site id&np=page code&mo=0&ct=010fff0fff" width="1" height="1" alt="szmtag" />
<!--/SZM -->
2. Adjust the variables “st” (site ID) and “np” (page code).
Note
- To ensure correct measurement, the SZM tag 2.0 must be included unchanged in the source code of the newsletter to be measured.
- Only the specified variables may be changed
- Line breaks, upper and lower case letters must be retained!
Attention
Please pay attention to the statutory regulations for sending newsletters.
Technical limitations
In order to facilitate a reach survey of HTML newsletters with the pseudonymous measuring system, a functionally restricted http call is employed without the use of Javascript.
The absence of JavaScript functionality results in the following limitations to data collection:
- no collection of URLs or referrers with data-protection-compliant automatic truncation
- no collection of screen resolution and color depth
- no consideration of DNT
- weaker client resolution, e.g. no separation for no-cookie clients hidden behind proxies
- reduced possibility of detecting forged or automatic requests
These technically determined restrictions may have a negative impact on the usage values determined for your site (e.g. a lower number of clients detected).
Meaning of the variables in the newsletter tag
The following variables should be adjusted as appropriate when integrating the newsletter tag into your newsletter:
Abbreviation | Meaning | Description |
st | Site ID (site) marked in the example under integration with “site id” | The site ID assigned to your site; this is created by INFOnline and assigned once; the ID is a maximum of 8 characters long. |
np | Page code marked in the example under integration with “page code” | The page code can be freely defined by the provider and is used to identify its tagged newsletters in the measuring system. The page code is the basis for subsequent category assignment in the INFOnline Customer Center (KAT 2.0). The page code may contain a maximum of 255 characters and consist only of alphanumeric characters and the following special characters: ‚,‘ ‚/‘ ‚-‚ ‚_‘. The total of active page codes for the site should not exceed 3,000. There is a charge for using more than 3,000 active page codes. NOTE: For test purposes, “np” can be replaced by “xp”. In this case, the requests are rejected by the measuring system. |
ct | Consent variable | The variable “ct=010fff0fff” informs the measuring system that this request may be processed in the IVW and agof context. Please observe the statutory regulations regarding newsletter collection. |
Analysis of newsletter requests in IDAS
Page codes from the newsletter measurement are automatically given the prefix “PUSH_” when entering the measuring system.
Example:
1. Using the following newsletter script with the page code “NLCODE123”:
<!-- SZM VERSION="2.0" -->
<img src=”https://de.ioam.de/tx.io?st=siteid&np=NLCODE123&mo=0&ct=010fff0fff" width="1" height="1" alt="szmtag" />
<!--/SZM -->
2. Call of the HTML newsletter by user – page code NLCODE123 is sent to the measuring system.
3. The page code NLCODE123 automatically becomes PUSH_NLCODE123
4. The page code “PUSH_NLCODE123” is then used in all downstream systems such as
- code allocation in the Customer Center
- IDAS evaluation
- Data delivery to IVW and agof
presented.
Note
Please pay particular attention to this when allocating page codes in the Category System 2.0, which you do in the INFOnline Customer Center (code management).
FRABO variable (only with agof participation)
If your website or MEW (mobile-enabled website) is measured for the daily digital facts study, the technical prerequisite for participation in agof is that an invitation ad can be delivered on all pages of your site.
The only exceptions are Smart TV, messenger sites and newsletters.
Further exceptions are possible, but must be approved individually by agof.
The invitation ad (referred to as BFE or on-site survey in documents) is implemented by a variable in SZM tag 2.0.
SZM tag with the variable "sv" for FRABO control
The SZM tag 2.0 consists of two code parts:
- External JavaScript file (integration via the header)
- JavaScript variables (integration in the body area)
1. HEAD integration (without line break!)
<script type="text/javascript" src="https://script.ioam.de/iam.js"> </script>
2. BODY integration
<!-- SZM VERSION="2.0" -->
<script type="text/javascript">
var iam_data = {
"st":"siteid", // site/domain (MEW)
"cp":"pagecode", // code
"sv":"<FRABO-Control", // Control of questionnaire delivery
"co":"comment" // comment
}
iom.c(iam_data,1);
</script>
<!--/SZM -->
Note
- Do not use the variables “iam_data” or “iom.c” in your scripts.
- Download of the external JavaScript “iam.js” and delivery via your own servers leads to incorrect measurement results
Implement the SZM tag 2.0 according to the documentation:
- Do not remove line breaks.
- Do not change any variables.
Add the site ID (st) and page code (cp) in the SZM tag as highlighted, using the site id and the page code required.
Definition of the “sv” variable (FRABO control)
Integration in the “Stationary/Desktop (WEB)” area
Abbreviation | Meaning | Description |
sv | FRABO control | With the SZM tag 2.0, control of the invitation to the survey is carried out directly from the SZM tag.
The following variables are possible:
“sv”: “i2″
“sv”: “in”
“sv”:“ke” |
Integration in the “mobile-optimized content (MEW)” area
Abbreviation | Meaning | Description |
sv | FRABO control | With the SZM tag 2.0, control of the invitation to the survey is carried out directly from the SZM tag.
The following variables are possible:
“sv”:“mo”
“sv”:“ke” |
Integration in the “connected TV (CTV)” area
Abbreviation | Meaning | Description |
sv | FRABO control | With the SZM tag 2.0, control of the invitation to the survey is carried out directly from the SZM tag.
The following variable is possible:
“sv”:“ke” The on-site survey is not currently intended for CTV measurement. Please set the FRABO control to disabled (“sv”:“ke”), otherwise there may be problems in delivering the BFE. |
Note
- When using the variables, please be sure to separate the transition from the first to the last variable with a comma in each case.
- However, the line of the last variable must not contain a comma. Do not use the variables “iam_data” or “iom.c” in your scripts
Example based on an extract of the SZM tag:
...
"cp":"page code", // code
"oc":"comment" // comment
...
Important information
- All information about the SZM tag and its implementation can be found in the SZM tag section
- The on-site survey must be deliverable on all web pages of a site, i.e. the variables “sv”:“in”, “sv”:“i2″ and “sv”:“mo” must be set in the SZM tag.
- Smart TV, messenger sites and newsletters cannot display the on-site survey. The on-site survey must be disabled: “sv”:“ke”.
- The SZM tag 2.0 can be implemented in the HTTPS area including the FRABO variables.
Function test of the on-site survey
The requirement of a successful test is explained to you as appropriate on the page.
Test system for on-site survey - website (FRABO tag)
Test system for on-site survey - MEW (FRABO tag)
TCF 2.0 integration in SZMnG
Problem
agof and IVW as downstream data processors of INFOnline GmbH, also referred to as Downstream Vendors, do not have access to a user’s consent decision in the TCF 2.0 Framework. This means that INFOnline GmbH has to query the user’s consent decision from the TCF 2.0 Framework in the measurement script via the TCF 2.0 API and to transmit it to the measuring system.
In addition, in the event of a negative consent decision by the user with regard to AGOF or Purpose 9, no survey may be delivered.
In the event that the user uses their own framework or the TCF 2.0 consent is not automatically determined for other reasons, the publisher can submit a consent string using the ct parameter.
Brief description of TCF 2.0
The European General Data Protection Regulation (GDPR) defines almost all profile data collected via cookies or mobile ad identifiers as personal data. Anyone who collects visitor data on their web page must inform the user about how it is used. Especially with modern advertising mechanisms such as RTB/RTA (Real Time Bidding/Advertising), a highly complex chain of different service providers involved in processing and enhancing user data is created. It must be known at every point and at all times which tracking and targeting processes are permitted for a user – and which must be avoided. The industry association IAB Europe has developed the “Transparency and Consent Framework” to ensure technical compliance. In September 2019, the supplemented 2.0 version was released. The rollout took place on 8/15/2020.
In addition to the user, the TCF defines three other categories of stakeholders: vendors, publishers and consent management platforms (CMPs).
- Vendorsare all service providers in the supply chain who intend to process data. These include, for example, website tracking systems, ad servers and ad verification providers, demand-side and sell-side platforms (DSPs and SSPs), and data management platforms (DMPs). Vendors must be registered with the TCF and declare the purposes for which they intend to process data. This information means that they can appear on the so-called Global Vendor List (GVL).
- Publishersprovide content and are in direct contact with consumers.
- Consent management platforms (CMPs)are special service providers that operate privacy centers and consent screens on web pages for publishers and advertisers, where they give users the opportunity to give their consent or to object. In the context of the TCF, they are responsible for providing the consent status of users to the delivery chain.
The TCF specifies a standard nomenclature for communication between the different parties, so-called signaling. In relation to the individual processing purposes of each vendor integrated by a publisher or advertiser on its pages, information is provided about whether the data processing is permitted and whether the user has explicitly opted out.
In version 2.0, the TCF distinguishes ten different purposes for processing of tracking data. These are supplemented by a total of seven additional processing options and purposes, which regulate specific use cases and their legal bases.
Application | ID | Processing purpose | Legal basis |
Setting cookies | 01 | Storing and/or retrieving information on/from a device | Consent or not used |
Technical targeting | 02 | Selection of simple ads | Consent, legitimate interest or not used |
Profile Targeting | 03 | Creating a personalized ad profile | „ |
„ | 04 | Selecting personalized ads | „ |
„ | 05 | Creating a personalized content profile | „ |
„ | 06 | Selecting personalized content | „ |
Tracking and market research | 07 | Measuring ad performance | „ |
„ | 08 | Measure content performance | „ |
„ | 09 | Using market research to gain insights into target groups | „ |
Product development | 10 | Developing and improving products | „ |
Table 1: Overview of purposes
Application | ID | Processing purpose | Legal basis |
Accurate location data and retrieval of device properties for identification purposes | 01 | Using accurate location data | Consent or not used |
„ | 02 | Actively querying device properties for identification | „ |
Table 2: Overview of special features
INFOnline Consent String Notation
Why use our own notation
The TCF 2.0 framework provides its own notation for storing and transmitting consent, which provides for a string of dynamic length at the end. This is ultimately stored locally in the browser (local storage or cookies). For INFOnline, this string may be unsuitable for processing measurement data: on the one hand, it contains too much unnecessary information and on the other, it does not allow a quick check of the consent for a particular vendor without prior parsing.
INFOnline has therefore 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.
Form of the notation
Below you will find an illustration of the INFOnline notation for the consent string:
Figure 1: INFOnline consent string format
Explanation
Like the tc-string in the TCF 2.0 Framework, the INFOnline consent string has a dynamic length, but it is specified by INFOnline. The INFOnline consent string is considerably shorter in total than the tc-string. Currently the string has a defined length of 14 characters. INFOnline can increase this length as necessary in the future and thus expand it to include additional vendors.
The string has individual reserved fields with a defined start and end position. It starts 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 has hexadecimal coding and can therefore 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 numerical enumeration), the remaining fields are bit fields. These store the consent of the corresponding vendor by means of bit field arithmetic.
Conversion table for purposes in bit field
The conversion table shown below and the example provided next to it can be used to determine the consent of a vendor:
Figure 2: Conversion table
Practical example of an INFOnline consent string
Here is a practical example for an INFOnline consent string to illustrate the calculation basis and notation:
Let’s assume a publisher uses INFOnline measurement, is a member of agof and measurement data is collected and processed for the daily digital facts study (ddf for short). In addition to the ddf, measurement data is also processed for the daily campaign facts (dcf for short). Thus the consent must be determined and transmitted for two vendors. Of course, the purposes which are regarded as a minimum requirement must be known for these vendors so that there is a legal basis for processing the measurement data for these three vendors in particular:
- INFOnline -> TCF 2.0 Purpose 8
- agof -> TCF 2.0 Purposes 1, 7 and 9
Note: Basically, the purposes can be taken from the Global Vendor List of the IAB for TCF 2.0.
Now you can use the conversion table for the individual purposes to determine the corresponding value:
- for INFOnline, this results in the 4-digit hex value 0080for Purpose 8. Since INFOnline requires only Purpose 8, this value also represents the hexadecimal-coded bit field.
- For agof, the hex values 0001(for Purpose 1), 0040 (for Purpose 7) and 0100 (for Purpose 9) are determined. The values are added and the hexadecimal-coded bit field 0141 is obtained.
Now all you have to do is merge the three bit fields and you will get the string 0000800141 for INFOnline and agof. Then you put the bit field for the CMP used at the 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 FF would be entered 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 of 01008000141. This consent string also represents the minimum possible information for a legal basis for processing the measurement data for both vendors.
Automatic processing of TCF 2.0-compliant consent
Requirements
In order for automated processing of TCF 2.0-compliant consent to occur within the measurement, a publisher must use a TCF 2.0-compliant CMP. For this the CMP must provide the IAB TCF 2.0 Toolkit via a stub function for the runtime in the browser. Only when these requirements are met can automated processing and transmission take place. If you are not sure if you meet the requirements, please contact your CMP provider. As a rule, all TCF 2.0-compliant CMPs operate according to this specification.
Note
INFOnline recommends adhering to the following installation sequence. First, the CMP script should be loaded in the page source text, then the SZM tag.
Determination
Here you will find a flowchart showing automatic determination, processing and transmission of consent information in the measurement script:
Here is a flowchart of how INFOnline extracts and processes the consent via the TCF 2.0 API:
Transmission
The consent is transmitted in the request parameter ct and is sent with each measurement call, together 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 will be transmitted.
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 the Unix Epoch timestamp. If the user changes their consent decision through the CMP over time, the measurement script automatically updates the value and date in the cookie.
Effects on implementation for the publisher
In the case of automatic processing of the consent via a TCF 2.0-compliant CMP, there are no effects on implementation. You do not have to make any changes.
Manual transmission of the consent by the publisher
Requirements
Manual transmission of the consent by a publisher is necessary if:
- the site processes data which are subject to the GDPR 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 facts and/or the digital campaign facts.
- the site does not use a CMP or uses a CMP that is not TCF 2.0-compliant for obtaining the legal basis.
Transmission by the publisher
For manual transmission of the consent without TCF 2.0, 2 options are available to the publisher via the INFOnline measurement script:
Option 1: Transmission by a public method (long form)
<script type="text/javascript">
// manual transmission of the consent
iom.consent('0000800141');
// measurement call
iom.count({
st: 'siteid', // site
cp: 'pagecode', // page code
co: 'comment' // comment
});
</script>
Option 1: Transmission by a public method (short form)
<script type="text/javascript">
// manual transmission of the consent
iom.ct('0000800141');
// measurement call
iom.c({
st: 'siteid', // site
cp: 'pagecode', // page code
co: 'comment' // comment
});
</script>
Option 2: Transmission in the measurement call (long form)
<script type="text/javascript">
// measurement call
iom.count({
st: 'siteid', // site
cp: 'pagecode', // page code
co: 'comment' // comment
ct: '0000800141' // consent
});
</script>
Option 2: Transmission in the measurement call (short form)
<script type="text/javascript">
// measurement call
iom.c({
st: 'siteid', // site
cp: 'pagecode', // page code
co: 'comment' // comment
ct: '0000800141' // consent
});
</script>
Notes on consent processing
INFOnline/IVW Vendor 730 “flexible purpose 8” (legitimate interest vs. consent)
We currently assume that the use of our pseudonymous measurement method (formerly SZMnG) continues to be covered by the overriding legitimate interest (pursuant to Art. 6(1) point (f) GDPR) of the website operator and that the pseudonymous measurement method can thus be used without the consent of the website visitor.
Accordingly, we have set up the technical requirements of our measurement procedure in such a way that user data is processed regardless of whether the website visitor has given their specific consent.
Consent
If you decide against legitimate interest (pursuant to Art. 6(1) point (f) GDPR) as the basis for data collection for INFOnline (Vendor 730), you must actively take programmatic measures to prevent the SZM tag from being implemented. The SZM tag may then be implemented only after the user has given their consent.
The query (programmatic measure) must be set up independently by the site. Due to the different systems – in the area of both CMS and CMP – it is not possible to provide a standard template for this.
agof studies Vendor 785 “purposes 1,7,9” (consent)
Processing is carried out in accordance with agof’s instructions.
Analyze
Analyze. Correct. Benefit.
Do you want to be able to check the count quickly and not always depend on your service providers or colleagues? Does error analysis always seem very complex and time-consuming?
With the help of these tips, your problems will solve themselves!
Desktop + mobile-enabled website
Analyze your site easily with browser developer tools!
- Open your web page in the browser of your choice
- Select the “Network” tab in the developer tool
- Search for “tx.io” or “ioam”
If implementation is successful, the following request is made in the corresponding developer tool:
GET https://de.ioam.de/tx.io?st=infonlin&cp=home&mg=yes&sv=in&co=ein
%20Kommentar&pt=CP&rf=&r2=&ur=www.infonline.de&xy=1920x1080x24&
lo=DE%2FNordrhein-Westfalen&cb=000c&vr=306&id=8zvc5k&
lt=1413543420531&ev=&cs=6ffk4l&mo=1
The unknown status does not generate any traffic in the measuring system!
NOTE!
With NewImage() or document.write() a 302 OK redirect comes first, which then points to the blank.gif and is delivered with a 200 OK. With the appendChild() method, a 200 OK is delivered directly. Depending on the browser, an additional “307 internal redirect” may be displayed in the developer tools – this is not an HTTP response from the system, but “internal” information from the relevant browser (e.g. in Google Chrome).
Apps
There are different methods for analyzing your app. In addition to analysis in the developer environment, auxiliary tools such as Fiddler are available to you. For all information about debugging, please refer to the Integration Guides of the corresponding operating system.
SZM)+Checker
Manual. Log file analysis
With the help of our experienced Customer Service team and log file analysis service, troubleshooting becomes a breeze.
Log file provision
The log files provide you with information about the measurement pulses that enter the measuring system for your site.
Responsive design
When converting your web page to a responsive design, make sure that the mobile identifier is used in the SZM tag as soon as mobile ads are integrated into a page.
Before converting your web page to a responsive design, the following questions must be discussed with the IVW office:
Do you want separate publication of desktop and mobile-enabled website for IVW and possibly agof?
If yes, both a stationary and a mobile site ID are required.
Do you include mobile-optimized ads on the mobile-enabled website?
If yes, both a stationary and a mobile site ID are required, as this is a guideline of the IVW.
If not, coordination directly with the IVW office is necessary to get the OK to show everything under one site ID.
If the answer to either of these two questions is “yes”, integration of the SZM tag should be carried out as follows:
Using a query (e.g. if/else query), the site ID (st parameter) and invitation ad (sv parameter) are swapped according to the device or ad display. The query must be implemented by the web developer. There is no template from INFOnline.
Here is an example:
If a mobile device is identified (e.g. detection database, ad server impulse for mobile ad), then the following parameters are implemented “differently”:
- “st”=“mobile site ID” (instead of “st”=“stationary site ID”)
- “sv”=“mo” (instead of “sv”=“in or i2”, only with agof participation)
If the code structure of the stationary and mobile-enabled web pages is identical, it can of course be carried over. If the code structures (“cp”=“codename”) differ, this must also be changed of course.
IMPORTANT NOTE
If you have replied “no” to both questions and the IVW office has confirmed to you that everything can be measured under one site ID, it is necessary to inform agof that no error logs will be sent to you for correction as part of the regular review of the BFE (invitation ad / “sv” parameters).
Creating code structure
The INFOnline measuring system (IVW publication or agof digital facts) does not serve as a tracking tool, but is based on the IVW category system.
A code structure must be created and assignment to the IVW category system is necessary so that web, app and CTV content can be compared.
Creation and implementation of the code structure for your site is the basis for participation in IVW publication and the agof daily digital facts study. Important: Please take a close look at the category model.
NOTE
The page code is the “cp” variable in the SZM tag, which must be included in your content.
Whether the code structure is sufficiently detailed or correctly allocated in code management is decided exclusively by the IVW office.
3,000 page codes are included in the measurement free of charge. The number of page codes used above this figure determines the additional costs.
There are different ways of creating a code structure, three of which are presented here.
Code structure based on the menu
In this example you will see 11 main menu items and 3 submenu items. The page codes for the total of 14 menu items could look like this:
homepage, world-news, world-news-politics, world-news-celebrities, world-news-lifestyles, travel, picture-galleries, games, videos, about-us, imprint, contact, login, premium
This would give you the basic framework for the code structure. Of course, this can be extended as required. Depending on whether the IVW categorization can be mapped in this way, creation of the code structure would be complete at this point. If there are category differences in the sub-items, further page code must be included of course. It is important that you always set aside the category system when creating a code structure.
Code structure based on the category model
To keep track of where exactly a page code is included, we recommend always working with meaningful codes (see the example above). If you prefer to follow the category system, you can also use the following codes for example: dronzbthka-n
This code would mean: Language: German (d), Producer: Editorial (r), Delivery: Online (o), Paid Content: Unassigned (nz), Format: Image/Text (bt), Homepage: Homepage of the site (h), App: No app (ka) and Topic: News (-n)
Do you have a marketer?
Most marketers already have experience with creating a code structure. Just ask us about this here without obligation!
Automatic code allocation
Save time and play it safe. Sign up for our automatic code allocation so that your code management is always reliably up to date!
Code monitoring
Are you responsible for categorizing your site according to the KAT 2.0 category model and manage the page codes used according to the relevant specifications?