-
INFOnline Measurement anonymous
-
- Articles coming soon
-
-
INFOnline Measurement pseudonymous
-
INFOnline Measurement Tools & Tips
-
customer center
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
Alternative implementation of the JavaScript as “minified”
Body implementation
Add the variables “site ID” (st) for your site and the “page code” (cp) required.
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:
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.
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
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:
BODY integration:
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”).
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()):
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
Measurement of AMP web pages (pageview)
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
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)
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>