Implementierung Android - Consentpflichtige Messung

1 Advertising Identifier in der IOLib

Zur Ermittlung aller Kennzahlen der consentpflichtigen ÖWA-Messung benötigt die IOLib Android die Advertising ID (AD_ID). Mithilfe dieser ID wird eine angebotsübergreifende Messung gewährleistet.

1.1 Android 13: Permission benötigt

Alle Apps mit targetSDKVersion 33 (Android 13) und höher müssen die Permission für die AD_ID aktiv im Manifest deklarieren, um den Advertising Identifier aus den Google Play Services abrufen zu dürfen.

Ist diese (Install-)Permission nicht vorhanden, wird eine genullte AD_ID übergeben.

Steht die AD_ID der IOLib nicht zur Verfügung, kann zwar in einem Fallback auf weitere Identifier zurückgegriffen werden, diese sind aber deutlich ungenauer und können nicht zur angebotsübergreifenden Messung genutzt werden.

Daher wird von uns zwingend empfohlen, die Permission für die AD_ID wie folgt zu aktivieren:

<manifest ...>
  <!-- Required only if your app targets Android 13 or higher. -->
  <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

  <application ...>
    ...
  </application>
</manifest>

2 Datenschutzangaben in der Google Play Console - Data Privacy / Datensicherheit

Wir möchten Sie erinnern, dass ab April 2022 für Ihre Android Apps die Datenschutzangaben in der Google Play Console in der Data Safety / Datensicherheit anzugeben sind. Dies gilt sowohl für neue Apps und App-Updates. Im Folgenden finden Sie sämtliche Informationen, welche in diesem Zusammenhang bereits für Sie zur Verfügung stehen.

Angaben gelten nur für die consentpflichtige ÖWA- Library!

Folgende Angaben sind nur Empfehlungen die für unsere Messlibrary getroffen werden können. Diese Angaben gelten nicht für Ihre gesamte App, hier müssen sie je nach Abhängigkeiten die erforderlichen zusätzlichen Angaben treffen. Unsere Empfehlung ist das absolute Minimum, was in Hinsicht auf unsere Library getroffen werden muss!

2.1 Welche Informationen müssen für die consentpflichtige ÖWA-Library angegeben werden?

Im folgendem Link finden sie Informationen zu den Angaben der Datensicherheit: Informationen für den Abschnitt zur Datensicherheit von Google Play angeben

Den Einrichtungsassistenten zur Einrichtung der Datensicherheit ist in der Google Play Console unter Richtlinie > App-Inhalte > Datensicherheit zu finden. Hier wiederum starten sie den Einrichtungsassistenten mit dem Klick auf Starten

Schritt 1: in der Google Play Console unter App-Inhalte

Schritt 2: unter App-Inhalte bei Datensicherheit den Assistenen Starten

2.2 Datensicherheit und Sicherheit

Schritt 3: Datenerhebung und Sicherheit:

2.3 Datentypen

Schritt 4: Datentypen

Schritt 5: Der Datentyp App-Aktivität

Schritt 6: Der Datentyp Geräte-ID oder andere persönliche Kennungen

2.4 Datenschutz und Umgang mit Datenerhebung

Schritt 7: Für die zuvor angegebenen Datentypen müssen sie noch weitere Fragen beantworten. Für beide zuvor ausgewählten Datentypen, beantworten sie die Fragen über Starten –>

Schritt 8: Fragen zu Aufgerufenen Seiten und Tippaktivitäten

Schritt 9: Falls sie eine z.B. durch eine TCF 2.0 konforme CMP eine Nutzerzustimmung einholen, können sie die Frage wie folgt beantworten:

Entscheiden Sie sich jedoch für das berechtigte Interesse, oder dagegen eine Nutzerzustimmung einzuholen, müssen Sie wie folgt antworten:

Geräte-ID oder andere persönliche Kennungen

Schritt 10: Fragen zu Geräte-ID oder andere persönliche Kennungen

Haben sie die Fragen zu den Datentypen unter Datennutzung und Umgang mit Daten abgeschossen, können sie fortfahren.

Schritt 11: Fragen zu beiden Datentypen erfolgreich beantwortet

2.5 Zusammenfassung / Vorschau der Datensicherheit:

Wenn sie den Assistenten erfolgreich abgeschlossen haben, sieht die Zusammenfassung wie folgt aus:

3 Integration der ÖWA-Library

Um die Consententscheidung des Nutzers für die Österreichische Webanalyse (ÖWA) zu übermitteln, muss die consentpflichtige ÖWA- Library Android 2.4.0 oder höher genutzt werden.

3.1 Thread-safe

Die IOLib für Android ist vollständig Thread-safe implementiert.

3.2 IOLib Dateien

Die consentpflichtige ÖWA-Library für Android umfasst folgende Dateien/Verzeichnisse

• RELEASE_NOTES.txt
  Diese Datei enthält Informationen zum Release der IOLib.
• CHANGELOG.txt
  Diese Datei enthält eine Historie der Änderungen der einzelnen Releases der IOLib.
• Datei „infonlinelib_2.4.0.aar“
  Die IOLibrary zur Erfassung der Nutzungsdaten einer Android-App als binäre Distribution
• Verzeichnis „INFOnlineLibrarySample“
  Ein Beispiel-Projekt für Android Studio, welches den Einsatz der IOLibrary für Android demonstriert.

3.3 Integration der IOLib

Im Folgenden wird die Integration der IOLib in ein Android App Projekt beschrieben.

1. In Android Studio: Integration der AAR Datei

Die Datei „infonlinelib_X.X.X.aar“ in das zu messende Projekt kopieren (z.b. nach /app/libs)

2. In Android Studio: build.gradle anpassen

Die Datei /app/build.gradle anpassen:

// Das Verzeichnis, in dem sich infonlinelib_X.X.X.aar befindet, muss als repository angegeben werden 
repositories{ 

              flatDir{ 
                   dirs 'libs'
                        }
 } 

dependencies { 

     // INFOnline Library benötigt die Mobile Ads-Identifier API der Google Play Services Library implementation  
        'com.google.android.gms:play-services-ads-identifier:181.08.10'
implementation 'com.google.android.gms:play-services-base:18.1.0'
 

    // Die INFONline Library verlinken
 implementation 'de.infonline.lib:infonlinelib_X.X.X@aar'

}

3. In Android Studio: Initialisierung der IOLib

• Neue Klasse erstellen und von Application ableiten oder bestehende Klasse verwenden
• IOLib initialisieren (im Folgenden beschrieben)

Die IOLib bietet zur Initialisierung zwei verschiedene Möglichkeiten an:

1) Die Initialisierung der App mit implizitem Session-Start:

import de.infonline.lib.IOLSession;
import de.infonline.lib.IOLSessionType;
import de.infonline.lib.IOLSessionPrivacySetting;
import android.app.Application;

public class SampleApplication extends Application {

  @Override
  public void onCreate() {
    super.onCreate();
    IOLSession.getSessionForType(IOLSessionType.OEWA) // Session Type OEWA
        .initIOLSession(this, // Application Context
                        "OfferIdentifier", // Offer Identifier
                         BuildConfig.DEBUG, // Debug mode on/off
                         IOLSessionPrivacySetting.LIN); // Privacy Setting
}

ALTERNATIV kann die Lib auch in 2 Schritten initialisiert und die Session gestartet werden :

2) Die reine Initialisierung der IOLib:

import de.infonline.lib.IOLSession;
import android.app.Application;

public class SampleApplication extends Application {

 @Override
  public void onCreate() {
       super.onCreate();
       IOLSession.init(this) // Application Context
 }
 ```

Zur Laufzeit dann die Initialisierung der Session:

public void initIOLSession() {
	IOLSession.getSessionForType(IOLSessionType.OEWA) // Session Type OEWA
          .initIOLSession("OfferIdentifier", // Offer Identifier
                           BuildConfig.DEBUG, // Debug mode on/off
                           IOLSessionPrivacySetting.LIN); // Privacy Setting

} 

4. In Android Studio: Code

• IOLib kann explizit gestoppt und gestartet werden

5. In Android Studio: Jede Activity

• Events werden über die IOLSession geloggt.
• Events können in den Activities der App geloggt werden, z.B. den Aufruf eines ViewAppeared

// Tracking View Appeared
 IOLSession.getSessionForType(IOLSessionType.OEWA)
           .logEvent(new IOLViewEvent(IOLViewEventType.appeared));

4 TCF 2.0 bei Android

Die ÖWA hat als nachgelagerter Datenverarbeiter der INFOnline GmbH, auch Downstream Vendoren genannt, keine Zugriffsmöglichkeit auf die Consent Entscheidung eines Users im TCF 2.0 Framework.

Hieraus ergibt sich für die INFOnline GmbH die Notwendigkeit, die Consent Entscheidung des Users aus dem TCF 2.0 Framework im Messskript über die TCF 2.0 API abzufragen und an das Messsystem zu übermitteln.

Zu diesem Zweck interpretiert die IOLib die Consent-Informationen, welche gemäß IAB TCF2.0 Spezifikation in dem dafür vorgesehenen Speicher persistiert wurden und überführt diese im Rahmen einer automatischen Verarbeitung in die INFOnline eigene Consent String Notation.

Für den Fall, dass ein eigenes Framework genutzt, oder aus anderen Gründen keine automatische Ermittlung des TCF 2.0 Consents erfolgt, kann der Publisher über die Nutzung der manuellen Verarbeitung einen Consent String übermitteln.

Die technischen Details zur Integration der manuellen Verarbeitung unter 2.0 Manuelle Verarbeitung aufgeführt.

4.1 Manuelle Verarbeitung

Die manuelle Verarbeitung der TCF Consent Daten werden mittels der Methode setCustomConsent durchgeführt. Dabei muss ein zuvor gemäß IO Consent String Notation gebildeter Consent String übergeben werden.

IOLSession session = IOLSession.getSessionForType(IOLSessionType.OEWA);
// Set custom consent:
session.setCustomConsent("");  // s. IO Consent String Notation

Wie bereits erwähnt, priorisiert die IOLib die automatische Verarbeitung höher als die manuelle Verarbeitung. Ist das Ergebnis der automatischen Verarbeitung ein valider IO Consent String, wird dieser immer übermittelt und der manuelle ignoriert.

Um zur Laufzeit überprüfen zu können, welcher Consent String zur Übermittlung verwendet wird, kann die Methode getConsent aufgerufen werden. Diese retourniert den zur Übermittlung aktuell verwendeten IO Consent String.

Beispiel:

IOLSession session = IOLSession.getSessionForType(IOLSessionType.OEWA);
session.getConsent();

5 Parallel-Messung ÖWA-Messung und INFOnline Messung

Die IOLib Android unterstützt den parallelen Betrieb von Sessions unterschiedlicher MessSysteme. Im Folgenden soll gezeigt werden, wie die Messung für beide Systeme gleichzeitig betrieben werden kann.

Bitte beachten Sie, dass die hier beschriebene Implementierung der Library nur dann erforderlich ist, wenn Sie auch Mitglied bei der „Österreichische Webanalyse“ (ÖWA) sind und im Rahmen dessen eine parallele Messung veranlassen möchten.

Es ist hier zwingend notwendig, dass Ihnen eine Kennung der INFOnline sowie eine Kennung der ÖWA (im Format: „at_x_beispiel“) vorliegen.

Voraussetzung ist eine Integration der IOLib Android. Die Punkte 3-5 sind dabei wie folgt auszuführen:

5.1 In Android Studio: Initialisierung der IOLib

Die IOLib bietet zur Initialisierung zwei verschiedene Möglichkeiten an:

1) Die Initialisierung der App mit implizitem Session-Start:

import de.infonline.lib.IOLSession;
import de.infonline.lib.IOLSessionType;
import de.infonline.lib.IOLSessionPrivacySetting;
import android.app.Application;

public class SampleApplication extends Application {

   @Override
   public void onCreate() {
      super.onCreate();
      IOLSession.getSessionForType(IOLSessionType.SZM) // Session Type SZM
                .initIOLSession(this, // Application Context
                               "OfferIdentifier-SZM", // Offer Identifier SZM
                               BuildConfig.DEBUG, // Debug mode on/off
                              IOLSessionPrivacySetting.LIN); // Privacy Setting

       IOLSession.getSessionForType(IOLSessionType.OEWA) // Session Type ÖWA
                 .initIOLSession(this, // Application Context
                                 "OfferIdentifier-OEWA", // Offer Identifier ÖWA
                                 BuildConfig.DEBUG, // Debug mode on/off
                                 IOLSessionPrivacySetting.LIN); // Privacy Setting
    }

ALTERNATIV kann die Lib auch in 2 Schritten initialisiert werden:

2) Die reine Initialisierung der IOLib:

import de.infonline.lib.IOLSession;
import android.app.Application;

public class SampleApplication extends Application {


   @Override
   public void onCreate() {
                     super.onCreate();
                     IOLSession.init(this) // Application Context
}

Zur Laufzeit dann die Initialisierung der Session für beide Messsysteme:

In Android Studio: Code

• IOLib für beide aktive Sessions explizit starten

IOLSession.getSessionForType(IOLSessionType.SZM).startSession();
IOLSession.getSessionForType(IOLSessionType.OEWA).startSession(); 

In Android Studio: Jede Activity

• Events werden über die IOLSession geloggt.
• Events können in den Activities der App geloggt werden, z.B. den Aufruf eines ViewAppeared

  // Tracking View Appeared
      IOLSession.getSessionForType(IOLSessionType.SZM)
          .logEvent(new IOLViewEvent(IOLViewEventType.appeared));

      IOLSession.getSessionForType(IOLSessionType.OEWA)
        .logEvent(new IOLViewEvent(IOLViewEventType.appeared));

6 IOLib Funktionen

Die IOLib für Android bietet die im Folgenden beschriebenen Funktionen:

6.1 Nutzung der IOLib im INFOnline-Modus (SZM)

IOLSession getSessionForType(IOLSessionType iolSessionType)

Funktionen der IOLib müssen auf einer konkreten IOLSession aufgerufen werden. Dazu übergibt man den entsprechenden IOLSessionType.

Parameter:

• IOLSessionType (mandatory)
  Der gewünschte IOLSessionType.

Beispiel:

IOLSession iolSession = IOLSession.getSessionForType(IOLSessionType.OEWA);

6.2 Initialisierung

initIOLSession(String offerIdentifier, boolean debugModeEnabled, IOLSessionPrivacySetting privacySetting)
initIOLSession(Context context, String offerIdentifier, boolean debugModeEnabled, IOLSessionPrivacySetting privacySetting)

Parameter:

• Application Context (optional)
  Der Application Context der Android App muss hier übergeben werden, falls nicht bereits über IOLSession.init(Context context) geschehen.
• Angebotskennung (mandatory)
  Die eindeutige Kennung des Angebots der jeweiligen App. Die Angebotskennung wird von der INFOnline pro App und pro Betriebssystem eindeutig vergeben.
• debugModeEnabled (optional)
  Wenn der Debug Modus aktiviert ist, loggt die MessLibrary unter dem logcat tag „INFOnline“. Es wird empfohlen, hier den Wert „BuildConfig.DEBUG“ zu übergeben.
  Default ist false, falls kein Wert übergeben wird.
• Datenschutz-Einstellungen (mandatory)
  Die Begründung, warum gemessen wird. Die möglichen Werte sind fest vorgegeben.

Beispiel:

IOLSession.getSessionForType(IOLSessionType.OEWA) 
          .initIOLSession(this, // Application Context 
                          "OfferIdentifier", // Offer Identifier 
                           BuildConfig.DEBUG); // Debug mode 
                           IOLSessionPrivacySetting.LIN); // Privacy Setting LIN

Logging eines Events

Die Messdaten werden mittels des Aufrufs logEvent erfasst. Dabei wird eine Instanz der zu messenden Event Klasse übergeben.

logEvent(IOLEvent event)

Parameter:

• Event (mandatory)
  Das zu erfassende Event.

Einige der Events werden durch die IOLib automatisch erfasst.

Weitere Details: Automatisch durch die SZM-Library gemessene Events.

Instanzierung einer Event Klasse

IOLEvent(EventType eventType, String category, String comment, Map params)

Parameter:

• EventType (mandatory)
  Das zu erfassende Event. Die einzelnen Events können verschiedene Zustände einnehmen. So kann ein Download z.B. gestartet, durch den User abgebrochen, erfolgreich durchgeführt oder fehlerhaft beendet worden sein.
  Bei einigen Events entfällt der type Parameter, da für diese Events nur ein gültiger Type definiert ist. Beim IOLCustomEvent wird statt eines type der frei definierbare String Parameter name benötigt.
• Category (mandatory): Contentpath
  Der Contentpath wird im Parameter “category“ übermittelt. Dieser Code wird vom Anbieter selbst festgelegt. Der Code dient zur inhaltlichen Kennzeichnung des angezeigten Content.
  Der Anbieter entscheidet anhand der im folgenden Kapitel beschriebenen Richtlinien, ob ein Event eine gültige PI im Sinne der ÖWA-Richtlinien darstellt. Wenn ein Event unter die Definition einer gültigen PI fällt, ist zwingend ein Contentpath mitzugeben. Stellt ein Event keine gültige PI dar, soll nil übergeben werden. Die Länge dieses Feldes ist auf 255 Zeichen beschränkt.
• Comment (optional): Kommentar
  Kommentarfeld. Die Länge dieses Feldes ist nicht beschränkt.
  Übergabe dieses Wertes ist optional, ist er nicht definiert, soll er nicht übergeben werden.
• params (optional): Parameter
  Eine Hash Map mit frei bestimmbaren Zusatzinformationen zu dem Event. Key und Value müssen vom Typ String sein, die maximale Länge ist jeweils auf 255 Zeichen beschränkt.Übergabe dieses Wertes ist optional.

Verfügbare Events

Die IOLib stellt folgende von „IOLEvent“ abgeleitete Event-Klassen mit den zugehörigen Types zur Verfügung:
IOLViewEvent

• IOLViewEventType.Appeared

Weitere Details zu den messbaren Events und der dazugehörigen States sind in Kapitel 4.3 (Events) beschrieben.

Beispiele:

IOLEventType.ViewAppeared

public class SampleActivity extends Activity { 

   @Override 
   protected void onResume() { 
         super.onResume(); 
         IOLEvent event = new IOLViewEvent(
           IOLViewEvent.IOLViewEventType.Appeared, 
             "category", 
             "comment"); 
          IOLSession.getSessionForType(IOLSessionType.OEWA).logEvent(event); 
         // Other Code .. 
    } 
}

6.3 Versand der Messdaten

sendLoggedEvents()

Die IOLib steuert den Versand der Messdaten selbständig und völlig transparent für den Enduser. Um den Versand der Daten zu forcieren, kann sendLoggedEvents aufgerufen werden. Die IOLib versucht dann, die Messdaten sofort bzw. nochmals zu versenden, sobald eine Datenverbindung aufgebaut wurde.

Beispiel:

IOLSession.getSessionForType(IOLSessionType.OEWA).sendLoggedEvents();

6.4 Debug Modus

setDebugModeEnabled(boolean enable);

Die IOLib kann in einen Debug-Modus versetzt werden. Hier werden diverse Ausgaben im Logstrom erzeugt (Fehler, Warnungen, Infos, Events und Requests).

Default-Wert ist false, wenn die MessLibrary IOLib mit IOLSession.initIOLSession(Context context, String offerIdentifier) initialisiert wurde.

Parameter:

• boolean enable
  Mögliche Werte: true|false

Beispiel:

IOLSession.setDebugModeEnabled(true);

6.5 Session beenden

Die aktive Session der IOLib kann explizit beendet werden. Dies ermöglicht ein Opt-out während der App-Laufzeit. Die bis dahin erfassten Daten werden verworfen und auch nicht mehr versendet.

Beispiel:

IOLSession.getSessionForType(IOLSessionType.OEWA).terminateSession();

6.6 Session starten

startSession()

Wurde die aktive Session der IOLib explizit beendet, kann diese jederzeit per startSession() erneut gestartet werden. Eine Neuinitialisierung ist nicht notwendig.

Beispiel:

IOLSession.getSessionForType(IOLSessionType.OEWA).startSession();

6.7 Einbindung Opt-out Funktion

Dem Nutzer einer App muss eine Opt-out Funktion gegeben werden. Die Implementierung obliegt dem Entwickler der jeweiligen App und sollte bei Aktivierung durch den Benutzer dazu führen, dass die IOLib entweder gar nicht initialisiert wird oder die laufende Session explizit beendet wird. Das Vorgehen ist in Kapitel Session beenden beschrieben.

Nach Einbindung der Funktion können die Nutzer der App das Opt-out aktivieren und deaktivieren. Sofern Opt-out aktiviert wird, wird kein Zählimpuls ausgelöst.

6.8 Einbindung Opt-in Funktion

Nach dem Start der App kann die Einwilligung des Nutzers zur Teilnahme an der Messung eingeholt werden. Die Implementierung obliegt dem Entwickler der jeweiligen App und soll nach der Zustimmung des Nutzers dazu führen, dass die Library initialisiert wird (vergl. Kapitel „Initialisierung“).

Bitte übermitteln Sie in diesem Fall das Privacy-Setting „ACK“.

Beispiel:

IOLSession.getSessionForType(IOLSessionType.OEWA) 
          .initIOLSession(this, // Application Context 
                          "OfferIdentifier", // Offer Identifier 
                           BuildConfig.DEBUG); // Debug mode 
                           IOLSessionPrivacySetting.ACK); // Privacy Setting ACK

6.9 TCF 2.0 Manuelle Verarbeitung

Die manuelle Verarbeitung der TCF Consent Daten werden mittels der Methode setCustomConsent durchgeführt. Dabei muss ein zuvor gemäß IO Consent String Notation gebildeter Consent String übergeben werden.

Beispiel:

IOLSession session = IOLSession.getSessionForType(IOLSessionType.OEWA);
// Set custom consent:
session.setCustomConsent(""); // s. IO Consent String Notation

Wie bereits erwähnt, priorisiert die IOLib die automatische Verarbeitung höher als die manuelle Verarbeitung. Ist das Ergebnis der automatischen Verarbeitung ein valider IO Consent String, wird dieser immer übermittelt und der manuelle ignoriert.

Um zur Laufzeit überprüfen zu können, welcher Consent String zur Übermittlung verwendet wird, kann die Methode getConsent aufgerufen werden. Diese retourniert den zur Übermittlung aktuell verwendeten IO Consent String.

Beispiel:

IOLSession session = IOLSession.getSessionForType(IOLSessionType.OEWA);
session.getConsent();

7 Integration der Google Play Services Library

Ab August 2014 muss gemäß den Bestimmungen der Google Play Developer Program Policies in Bezug auf Audience Measurement der AdvertisingIdentifier zum Einsatz kommen:

https://play.google.com/about/monetization-ads/ads/ad-id/

Um den AdvertisingIdentifier zu erfassen, muss die Google Play Services Bibliothek in das Projekt eingebunden werden, jedoch nur die AdsIdentifier und Base API:

dependencies {
    implementation 'com.google.android.gms:play-services-ads-identifier:181.08.10'
    implementation 'com.google.android.gms:play-services-base:18.1.0'
}

Der AdvertisingIdentifier kann jedoch nur auf Geräten ausgelesen werden, die Google Play installiert haben.

Google stellt eine ausführliche Anleitung bereit, die Schritt für Schritt beschreibt, wie man die Bibliothek in das jeweilige Projekt integriert:

http://developer.android.com/google/play-services/setup.html

8 AndroidX

Die IOLib Android nutzt Pakete aus dem neuen AndroidX Namespace, was eine Migration Ihrer App von den veralteten Support Libraries zu AndroidX nötig macht. Ab Version 3.2 bietet Android Studio dazu die Möglichkeit einer automatischen Migration, welche über Refactor -> Migrate to AndroidX gestartet wird.

Anschließend können die benötigten AndroidX Bibliotheken eingebunden werden.

IOLib Android benötigt zur Verarbeitung der TCF2.0 Consent Informationen Zugriff auf die SharedPreferences:

dependencies {
implementation 'androidx.preference:preference:1.1.1'
}

Weitere Infos und detaillierte Erläuterungen zur AndroidX Migration finden Sie hier: https://developer.android.com/jetpack/androidx/migrate

9 Vorgaben zum Aufruf der IOLib

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

Die Nutzer-Interaktion wird als Event bezeichnet.

Weiterhin misst die IOLib bestimmte System- oder App-spezifische Werte automatisch. Zu diesem Zweck muss die Integration der IOLib Android exakt wie im Kapitel „Integration des IOLib Android Frameworks“ beschrieben erfolgen.

9.1 Interpretation von Events als mobile PI

Die nachfolgend aufgeführten Vorgaben definieren, wie die IOLib im Kontext der consentpflichtigen Mobile Applications Messung zu verwenden ist.

Aus technischer Sicht wird zwischen 2 Typen von Events unterschieden:

9.2 PI-Events

Bei den PI-Events wird der Event dazu benutzt, analog zur Web-Messung, eine PageImpression zu erzeugen. Diesem Event muss ein Contentpath (in der Folge einfach als „CP“ bezeichnet) zugeordnet werden. Dieser CP 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 Page Impression der ÖWA zu beachten.

Voraussetzungen für die Zuweisung einer PI 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 PI 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 PageImpression:

Das Scrollen innerhalb eines bereits geladenen Inhalts.

9.3 Richtlinien zur Vergabe der Codes

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

Bei der Spezifikation des Contentpaths sind die CP-Richtlinien der ÖWA zu beachten:

• Länge: Ein CP darf maximal 255 Zeichen enthalten
• Anzahl: Es dürfen maximal 15.000 CPs verwendet werden
• Erlaubte Zeichen: a-z, A-Z, 0-9; Komma „,“; Bindestrich „-“; Unterstrich „_“; Slash „/“

Eine ausführliche Liste gültiger ÖWA-Kategorien (Contentpath) finden Sie unter:

ÖWA-Kategoriensystem

9.4 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.

9.5 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 Contentpath zugeordnet werden. Dieser Contentpath kann anschließend den unterschiedlichen Kategorien zugeordnet werden und dient als Grundlage für die Bildung von Belegungseinheiten.

• Event Klasse: IOLViewEvent
• Event Type: Appeared
• Event: Ein View (aka „Page“) wurde angezeigt oder mit neuen Daten aktualisiert
• Bemerkung: Beispiele:
  Appeared: initialer Aufruf einer Seite

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

10 Android TV / Nexus Player

Die IOLib Android ist vollständig geeignet für die Messung einer Android App auf der Plattform “Android TV / Nexus Player”, da diese technisch auf dem gleichen Betriebssystem basiert wie andere Android Geräte.

Soll die IOLib Android unter Android TV / Nexus Player zum Einsatz kommen, so sind alle Integrationsschritte gemäß Kapitel „Integration der IOLib Android“ durchzuführen. Die Methoden zur Steuerung der IOLib sind ebenfalls, gemäß Kapitel „Integration der Google Play Services Library„, analog zu verwenden.

Auch die Hybrid-Messung gemäß Kapitel „Hybrid-Messung“ kann wie beschrieben eingesetzt werden.

11 Fire OS

Die IOLib Android ist grundsätzlich geeignet zur Messung einer Android App auf dem Betriebssystem „Fire OS 5“. Diese Kompatibilität bezieht sich auf die Veröffentlichung einer nativen Android App unter Fire OS 5, nicht auf HTML5/WebApps.

Soll die IOLib Android unter Fire OS 5 zum Einsatz kommen, so sind alle Integrationsschritte gemäß Kapitel „Integration der ÖWA-Library “ durchzuführen. Die Methoden zur Steuerung der IOLib sind ebenfalls, gemäß Kapitel „Integration der Google Play Services Library“, analog zu verwenden.

Auch die Hybrid-Messung gemäß Kapitel „Hybrid-Messung“ kann wie beschrieben eingesetzt werden.

12 Debug-Informationen

Zum Zweck der allgemeinen Fehleranalyse und insbesondere des Versands der Messdaten kann die Library in einen Debug-Modus versetzt werden. In diesem Debug-Modus erzeugt die Library diverse Ausgaben im Logstrom (Konsole): Fehler, Warnungen, Infos, Events und Requests.

Diese Ausgaben können dann in der Konsole komfortabel gefiltert werden.

Um die IOLib in den DebugModus zu versetzen, wir die Methode setDebugModeEnabled aufgerufen:

IOLSession.setDebugModeEnabled(true);

Per default ist der Debug-Modus deaktiviert, es sei denn, der Debug-Modus wurde bei der Initialisierung explizit aktiviert. Das Vorgehen ist in Kapitel 6.2 (Initialisierung) beschrieben.