Zum Inhalt

Vorgaben zum Aufruf der IOMb Library

Die Erfassung der App-Nutzung durch den Benutzer erfolgt, indem die App die IOMb Library bei definierten Ereignissen, welche eine Nutzer-Interaktion kennzeichnen, aufruft.

Die Nutzer-Interaktion wird als Event bezeichnet.

Hinweis

Die IOMb Library muss von der App bei Eintreten des Events explizit aufgerufen werden.

Weiterhin misst die IOMb Lib bestimmte System- oder App-spezifische Werte automatisch. Zu diesem Zweck muss die Integration der IOMb Lib Android wie im Kapitel Integration der IOMB Lib Android beschrieben erfolgen.

Interpretation von Events als mobile PI

Die nachfolgend aufgeführten Vorgaben definieren, wie die INFOnline Measurement Library im Kontext der IOMb Mobile Applications Messung zu verwenden ist.

Aus technischer Sicht wird zwischen 2 Typen von Events unterschieden:

PI-Events

Bei den PI-Events wird der Event dazu benutzt, analog zum stationären Web, eine PageImpression zu erzeugen. Diesem Event muss ein Inhaltscode (in der Folge einfach als „Code“ bezeichnet) zugeordnet werden. Dieser Code kann anschließend den unterschiedlichen Kategorien zugeordnet werden und dient als Grundlage für die Bildung von Belegungseinheiten. Bei den PI-Events sind die Vorgaben zur Mobile Impression der IVW zu beachten:

„Eine Mobile Impression ist eine Nutzeraktion innerhalb eines mobilen Angebots, die zu einem Aufruf eines Werbemittels führt oder führen könnte. Jede Nutzeraktion darf nur einmal gezählt werden. Nutzeraktionen, die zu keiner potentiellen Werbeauslieferung führen, dürfen nicht gezählt werden.

Voraussetzungen für die Zuweisung einer MI zu einem Angebot:

Der ausgelieferte Inhalt muss (bei mobile enabled Websites) den FQDN bzw. (bei Apps) den App-Namen des Angebots (oder Alias/Redirect) oder den zugewiesenen MEW- oder App-Namen des Angebots tragen.

Nutzeraktion:

Eine MI wird ausgelöst durch eine vom Nutzer durchgeführte Aktion. Darunter fallen ebenfalls: Reload, Öffnen einer App, Öffnen eines Browsers.

Keine Nutzeraktion:

Aufruf eines Inhalts durch eine automatische Weiterleitung (außer Redirects und Alias)., automatischer Reload, das Aufrufen eines Inhaltes beim Schließen (auch: Background) eines Browserfensters oder einer App, das Aufrufen von Inhalten über Robots/Spider und Ähnliches.

Keine Mobile Impression:

Das Scrollen innerhalb eines bereits geladenen Inhalts.

Non-PI-Events

Non-PI-Events sind Nutzeraktionen, die als Event im IOMb System erfasst werden, jedoch nicht zur Zählung einer Mobile Impression führen. Diesem Event darf kein Code zugeordnet werden. Beispiele für Non-PI-Events sind

  • automatisch von der IOMb Lib erfasste Events
  • vom Anbieter festgelegte Events, welche keine mobile PI darstellen und dennoch als Events gemessen werden sollen, um z.B. die Nutzung der App durch die Nutzer besser nachvoll-ziehen zu können.

Richtlinien zur Vergabe der Codes

Bei den PI-Events ist der Code als eindeutige Kennzeichnung des angezeigten Inhalts mitzugeben. Der Code wird vom App-Anbieter spezifiziert.

Bei der Spezifikation der Inhalts-Codes sind die Code-Richtlinien der INFOnline zu beachten:

  • Länge der Codes: Ein Code darf maximal 255 Zeichen enthalten
  • Anzahl der Codes: es dürfen maximal 2000 Codes verwendet werden
  • Erlaubte Zeichen: a-z, A-Z, 0-9; Komma „,“; Bindestrich „-“; Unterstrich „_“; Slash „/“

Events

In den nachfolgenden Tabellen sind Events aufgeführt, welche in der Messung erhoben werden bzw. erhoben werden können. Unter welchen Umständen ein Event zu einer Page Impression führen kann, wird im folgenden ebenfalls erläutert.

Automatisch durch die IOMb-Library gemessene Events

Die nachfolgende Tabelle beschreibt die Events, bei denen die INFOnline Measurement Library automatisch aufgerufen wird. Bei den Events handelt es sich um Nutzeraktionen, welche aus technischen Gründen erhoben werden, jedoch nicht zur Zählung einer Mobile Impression führen. Diesem Event darf kein Code zugeordnet werden.

Event Klasse Event Type Event Bemerkung
IOLApplicationEvent Start, EnterBackground, EnterForeground, Crashed App-spezifische Event, z.B. Start der App, Beenden der App, Crash, etc. ResignActive: Eingehender Anruf, Push-Notification Alert, Timer Alarm, etc. EnterFore/Background: App geht in den Hintergrund Terminate: App wird beendet
IOLInternetConnectionEvent Established Lost SwitchedInterface Art der Konnektivität ändert sich Verbindung aufgebaut bzw. verloren Wechsel von Mobile auf Wifi bzw. umgekehrt
IOLWebViewEvent Init Hybrid-Messung wird aktiviert

PI-Events

Im Folgenden sind Events aufgeführt, welche typischerweise zur Auslösung einer PI führen. Die Übernahme des Schemas wird empfohlen. Die Events müssen manuell ausgelöst werden. Das Vorgehen ist im Kapitel Logging eines Events beschrieben. Eine automatische Erhebung erfolgt nicht. PI-Events muss ein Code zugeordnet werden. Dieser Code kann anschließend den unterschiedlichen Kategorien zugeordnet werden und dient als Grundlage für die Bildung von Belegungseinheiten.

Hinweis

Bei den PI-Events sind die Vorgaben zur Mobile Impression der IVW zu beachten.

Event Klasse Event Type Event Bemerkung
IOLDeviceOrientationEvent Changed Ausrichtung des Gerätes LandscapeLeft / LandscapeRight oder Portrait / Portrait UpsideDown
IOLGestureEvent Shake Gerät wird geschüttelt
IOLViewEvent Appeared
Refreshed
Ein View (aka „Page“) wurde angezeigt oder mit neuen Daten aktualisiert Beispiele:
Appeared: initialer Aufruf einer Seite Refreshed: Suchfilter o. Aktualisierung von Daten
IOLGameEvent Action
Started
Gaming-Events Aktion innerhalb eines Spiels Spiel gestartet
IOLAudioEvent Play
Pause
Stop
Next
Previous
Replay
SeekBack
SeekForward
Audio Playback Wiedergabe,
Pause,
Stop,
Nächster/vorheriger Titel,
Wiederholung
Vor/Zurückspulen,
IOLVideoEvent Play
Pause
Stop
Next
Previous
Replay
SeekBack
SeekForward
Video Playback Wiedergabe,
Pause,
Stop,
Nächster/vorheriger Titel,
Wiederholung,
Vor/Zurückspulen

Non-PI-Events

Im Folgenden sind Events aufgeführt, welche typischerweise nicht zur Zählung einer PI führen. Sollten jedoch im Einzelfall Umstände vorliegen, unter denen auch hier eine Mobile PI erzeugt werden soll, können diese Events benutzt werden, um dies zu ermöglichen. Bevor Sie diese Events zur Erzeugung von PIs benutzen, klären Sie den jeweiligen Sachverhalt bitte unmittelbar mit der IVW Geschäftsstelle ab. Sollen diese Events zur Zählung von PIs führen, muss das auch hier manuell ausgelöst werden. Diesem Event muss dann ein Code zugeordnet werden. Dieser Code kann anschließend den unterschiedlichen Kategorien zugeordnet werden und dient als Grundlage für die Bildung von Belegungseinheiten.

Event Klasse Event Type Event Bemerkung
IOLViewEvent Disappeared Ein View (aka „Page“) wurde verlassen Ein View (aka „Page“) wurde verlassen
IOLDocumentEvent Open Edit Close Dokument / Liste Bearbeitung Liste editiert Dokument gespeichert
IOLDataEvent Cancelled, Refresh, Succeeded, Failed Datenverbindung/ -verarbeitung Datenverbindung abgebrochen Daten wurden aktualisiert Daten wurden erfolgreich übertragen Daten wurden nicht übertragen
IOLDownloadEvent Cancelled, Start, Succeeded, Failed Download von Daten Download wurde initiiert Download wurde abgebrochen Download erfolgreich beendet Download fehlgeschlagen
IOLUploadEvent Cancelled, Start, Succeeded, Failed Upload von Daten Upload wurde initiiert Upload wurde abgebrochen Upload erfolgreich beendet Upload fehlgeschlagen
IOLLoginEvent Succeeded, Failed, Logout Login Login erfolgreich durchgeführt Login fehlgeschlagen Logout durchgeführt/Session beendet
IOLGameEvent Finished, Won, Lost, NewHighscore, NewAchievemen Gaming-Events Spiel beendet Spiel(runde) gewonnen Spiel(runde) verloren Neuer Highscore erreicht Neues Achievement erreicht
IOLHardwareButtonEvent Pushed Schalter oder Knopf am Gerät gedrückt Lautstärke über Schalterwippe am Gerät geändert Device gelocked (Power Taste betätigt) Druck auf Home-Button
IOLBackgroundTaskEvent Start, End Ein Hintergrundprozess wird gestartet bzw. beendet Download oder Upload größerer Dateien, welche evtl. im Hintergrund weiterlaufen sollen
IOLOpenAppEvent Maps, Other Eine andere App wird gestartet bzw. App wird über eine URL verlassen Maps: Apple Maps wird aufgerufen Other: Andere Apps bzw. URIs werden aufgerufen (Email, Phone, Websites, etc.)
IOLAdvertisementEvent Open, Close Werbung wird angezeigt oder ausgeblendet Werbe-Banner geöffnet bzw. geschlossen
IOLIAPEvent Started, Finished, Cancelled In-App-Käufe werden durchgeführt IAP Prozess wird iniitiert (Start) IAP Prozess wird beendet (Finished) IAP Prozess wird vorzeitig abgebrochen (Cancelled)
IOLPushEvent Received Push Notifications Eine Push Notification wird empfangen
IOLCustomEvent * Durch den Nutzer definierbar Ein CustomEvent kann einen frei definierbaren Status bzw. Aktion messen (Für zukünftige Nutzung vorgesehen).

Sobald in der App ein unter „manuell auszulösende Events“ beschriebenes Ereignis ausgelöst wird, ist die IOMb Library Android per logEvent aufzurufen. Hierbei ist eine Instanz der entsprechenden IOLEvent-Subklasse als Parameter zu übergeben (siehe dazu auch IOMb Library Android Funktionen).

Die Übermittlung der Non-PI-Events an das INFOnline Measurement System ist optional.

Hinweis

Die Non-PI-Events haben keinen Einfluss auf die Reichweitenermittlung Ihrer App.

Diese Events können von Ihnen zur quantitativen Ermittlung der Häufigkeit des Auftretens dieser Events (in den INFOnline Auswertesystemen) verwendet werden. Hierbei ist zu beachten, dass die Erfassung und Übermittlung der Non-PI-Events technische Ressourcen (CPU-Zeit, Netzwerkverkehr, Batterie) auf dem Endgerät verwendet.

Mit Hinblick auf die Inanspruchnahme der technischen Ressourcen auf dem Endgerät bitten wir Sie, in der Planung der Umsetzung der Integration der MessLibs zu entscheiden, ob Ihre App NonPI-Events an das INFOnline Measurement System übermitteln soll.

Sonderfall Event „ViewRefreshed“

Für den Fall, dass eine View aktualisiert wird (IOLViewEvent, Type IOLViewEventType.Refreshed), ist Folgendes zu beachten:

Hinweis

Das Event darf nur geloggt werden, wenn der Refresh der Daten manuell durch den Nutzer ausgelöst wurde. Bei einem automatischen Refresh darf das Event nicht geloggt werden.

Kurzbeschreibung TCF 2.0

Durch die europäische Datenschutzgrundverordnung (DSGVO) werden nahezu alle Profildaten, die über Cookies oder mobile Ad Identifier erhoben werden, als personenbezogen definiert. Wer auf seiner Webseite Besucherdaten erhebt, muss den User über dessen Verwendung informieren. Gerade bei modernen Advertising Mechanismen wie RTB/RTA (Real Time Bidding/Advertising) entsteht eine hochkomplexe Kette verschiedener Dienstleister, die in die Verarbeitung und Anreicherung von Userdaten involviert sind. Dabei muss an jeder Stelle und zu jedem Zeitpunkt bekannt sein, welche Tracking- und Targeting-Vorgänge eines Users erlaubt sind – und welche unterlassen werden müssen. Zur Gewährleistung der technischen Sicherstellung, hat der Branchenverband IAB Europe das „Transparency and Consent Framework“ entwickelt. Im September 2019 wurde die ergänzte Version 2.0 veröffentlicht. Am 15.08.2020 erfolgte der Rollout dieser.

Neben dem User definiert das TCF drei weitere Kategorien von Akteuren: Vendoren, Publisher und Consent Management-Plattformen (CMPs).

  • Vendoren sind alle Dienstleister der Auslieferungskette die Daten verarbeiten wollen. Da-runter fallen beispielsweise Websitetrackingsysteme, Adserver und Adverification-Anbieter, Demand- und Sell Side-Plattformen (DSPs und SSPs) sowie Data Management-Plattformen (DMPs). Vendoren müssen beim TCF registriert sein und erklären, zu welchen Zwecken sie Daten verarbeiten wollen. Mit dieser Information sind sie über die sogenannte Global Vendor List (GVL) einsehbar.

  • Publisher stellen Content bereit und stehen in direktem Kontakt mit den Konsumenten.

  • Consent Management-Plattformen (CMPs) sind Spezialdienstleister, die für Publisher und Werbetreibende die Privacy Center und Consent Screens auf den Webseiten betreiben und dort dem User Gelegenheit zur Zustimmung oder Widerspruch geben. Im Rahmen des TCF sind sie für das Bereitstellen des Consent-Status der User an die Auslieferungskette zuständig.

Für die Kommunikation zwischen den verschiedenen Parteien, das sogenannte Signalling, legt das TCF eine standardisierte Nomenklatur fest. Dabei wird für jeden, von einem Publisher oder Werbetreibenden auf den Seiten integrierten, Vendor zu den einzelnen Verarbeitungszwecken übertragen, ob die Datenverarbeitung erlaubt ist und ob der User ein explizites Opt-out vorgenommen hat.

In der Version 2.0 unterscheidet das TCF zehn unterschiedliche Zwecke (Purposes) für die Verarbeitung der Tracking-Daten. Diese werden ergänzt durch insgesamt sieben weitere Verarbeitungsmöglichkeiten und -zwecke, die spezielle Anwendungsfälle und deren Rechtsgrundlagen regeln.

Anwendung ID Verarbeitungszweck Rechtsgrundlage
Cookies setzen 01 Informationen auf einem Gerät speichern und/oder abrufen Zustimmung oder nicht verwendet
Technisches Targeting 02 Auswahl einfacher Anzeigen Zustimmung, berechtigtes Interesse oder nicht verwendet
Profile Targeting 03 Ein personalisiertes Anzeigen-Profil erstellen "
" 04 Personalisierte Anzeigen auswählen "
" 05 Ein personalisiertes Inhalts-Profil erstellen "
" 06 Personalisierte Inhalte auswählen "
Tracking und Marktforschung 07 Anzeigen-Leistung messen "
" 08 Inhalte-Leistung messen "
" 09 Marktforschung einsetzen, um Erkenntnisse über Zielgruppen zu gewinnen "
Produktentwicklung 10 Produkte entwickeln und verbessern "
Cookies setzen 01 Informationen auf einem Gerät speichern und/oder abrufen Zustimmung oder nicht verwendet
Technisches Targeting 02 Auswahl einfacher Anzeigen Zustimmung, berechtigtes Interesse oder nicht verwendet

Tabelle1: Übersicht der Purposes

Anwendung ID Verarbeitungszweck Rechtsgrundlage
Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation 01 Genaue Standortdaten verwenden Zustimmung oder nicht verwendet
" 02 Geräteeigenschaften zur Identifikation aktiv abfragen "

Tabelle2: Übersicht der Purposes

Gemäß Website INFOnline.de unter TCF2.0: INFOnline Consent String Notation


Letztes Update: May 10, 2023