Specifications for calling the IOMb Library¶

The user's app usage is captured by the app calling the IOMb Library on defined events that mark a user interaction.

The user interaction is referred to as an event.

Note The IOMb Library must be explicitly invoked by the app when the event occurs.

Furthermore, the IOMb Lib automatically measures certain system or app specific values. For this purpose, the integration of the IOMb Lib Android must be done as described in the chapter Integration of the IOMB Lib Android.

Interpretation of events as mobile PI events¶

The specifications listed below define how the INFOnline Measurement Library is to be used in the context of IOMb Mobile Applications measurement.

From a technical perspective, a distinction is made between 2 types of events:

PI events.¶

In the case of PI events, the event is used to generate a page impression, analogous to the stationary Web. A content code (referred to simply as "code" in the following) must be assigned to this event. This code can then be assigned to the various categories and serves as the basis for creating booking units. For PI events, the mobile impression specifications of the IVW must be observed:

"A mobile impression is a user action within a mobile site that leads or could lead to a call-up of an advertising medium. Each user action may only be counted once. User actions that do not lead to any potential advertising delivery may not be counted.

Prerequisites for assigning an MI to a site:.

Delivered content must bear (for mobile-enabled websites) the FQDN or (for apps) the app name of the site (or alias/redirect) or the assigned MEW or app name of the site.

User action:

An MI is triggered by an action performed by the user. This also includes: reload, opening an app, opening a browser.

No user action:

Calling up content through an automatic redirect (except redirects and alias)., automatic reload, calling up content when closing (also: background) a browser window or app, calling up content via robots/spiders and similar.

No Mobile Impression:

The scrolling within an already loaded content.

Non PI events.¶

Non PI events are user actions that are recorded as an event in the IOMb system but do not result in a mobile impression being counted. No page code may be assigned to this event. Examples of non PI events are.

• Events automatically captured by the IOMb Lib.
• Events defined by the provider that do not represent a mobile PI but are still to be measured as events, e.g. in order to better track the use of the app by the users.

Guidelines for assigning page codes.¶

For PI events, the page code must be included as a unique identifier of the displayed content. The page code is specified by the app provider.

When specifying the content codes, the INFOnline code guidelines must be followed:

• Length of the codes: A page code may contain a maximum of 255 characters.
• Number of codes: a maximum of 2000 codes may be used.
• Permitted characters: a-z, A-Z, 0-9; comma ","; hyphen "-"; underscore "_"; slash "/"

Events¶

The following tables list events that are or can be collected in the measurement. The circumstances under which an event can lead to a Page Impression are also explained below.

Events automatically measured by the IOMb library¶

The following table describes the events for which the INFOnline Measurement Library is automatically called up. The events are user actions that are collected for technical reasons but do not result in the counting of a mobile impression. No page code may be assigned to this event.

PI events¶

In the following, events are listed which typically lead to the triggering of a PI. The adoption of the schema is recommended. The events must be triggered manually. The procedure is described in the chapter Logging an event. There is no automatic collection. PI events must be assigned a page code. This page code can then be assigned to the different categories and is used as the basis for creating booking units.

NOTE: For PI events, the specifications for mobile impression of the IVW must be observed.

Non PI events¶

The following are events that typically do not result in a PI being counted. However, if there are circumstances where a Mobile PI should also be generated here, these events can be used to enable this. Before using these events to generate PIs, please clarify the respective circumstances directly with the IVW office. If these events are to lead to the counting of PIs, this must also be triggered manually. A page code must then be assigned to this event. This page code can then be assigned to the various categories and serves as the basis for creating booking units.

As soon as an event described under "events to be triggered manually" is triggered in the app, the IOMb library Android is to be called via logEvent. An instance of the corresponding IOLEvent subclass must be passed as parameter (see also IOMb Library Android functions).

The transmission of the non PI events to the INFOnline Measurement System is optional.

These events can be used by you to quantitatively determine the frequency of occurrence of these events (in the INFOnline evaluation systems). It should be noted here that capturing and transmitting the non PI events uses technical resources (CPU time, network traffic, battery) on the end device.

With regard to the use of technical resources on the end device, we ask you to decide when planning the implementation of the integration of the MeasurementLibs whether your app should transmit NonPI events to the INFOnline Measurement System.

Special case "ViewRefreshed" event¶

In the event that a view is refreshed (IOLViewEvent, type IOLViewEventType.Refreshed), note the following:

NOTE: The event may only be logged if the refresh of the data was triggered manually by the user. The event must not be logged in case of an automatic refresh.

TCF 2.0 Information / IO Consent String Notation¶

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 its use. Particularly with modern advertising mechanisms such as RTB/RTA (Real Time Bidding/Advertising), a highly complex chain of different service providers is created that are involved in the processing and enrichment of user data. It must be known at every point and at every time which tracking and targeting processes of a user are permitted - and which must be refrained from. To ensure technical security, the industry association IAB Europe has developed the "Transparency and Consent Framework". In September 2019, the supplemented version 2.0 was published. On 15.08.2020, the rollout of this took place.

In addition to the user, the TCF defines three other categories of actors: vendors, publishers and Consent Management Platforms (CMPs).

• Vendors are all service providers in the delivery chain who want to process data. They include, for example, website tracking systems, ad servers and adverification providers, demand and sell side platforms (DSPs and SSPs), and data management platforms (DMPs). Vendors must be registered with TCF and declare the purposes for which they want to process data. With this information, they can be viewed via the so-called Global Vendor List (GVL).

• Publishers provide content and are in direct contact with consumers.

• Consent Management Platforms (CMPs) are specialized service providers that operate the privacy centers and consent screens on web pages for publishers and advertisers, where they give users the opportunity to consent or object. As part of the TCF, they are responsible for providing the user's consent status to the delivery chain.

The TCF defines a standardized nomenclature for the communication between the different parties, the so-called signaling. For each vendor integrated by a publisher or advertiser on the pages, it is transmitted for the individual processing purposes whether the data processing is permitted and whether the user has made an explicit Opt-out.

In version 2.0, the TCF distinguishes between ten different purposes (Purposes) for the processing of tracking data. These are supplemented by a total of seven additional processing options and purposes that regulate specific use cases and their legal basis.

Table1: Overview of Purposes

*Table2: Overview of Purposes

INFOnline Consent String Notation¶

According to the INFOnline.de website at TCF2.0: INFOnline Consent String Notation ( at 1st mention explanation 'new generation of scalable central measuring procedures' in brackets)