Implementierung iOS - Consentpflichtige Messung

1 Hinweise zum Apple Store - App Privacy Details

Wir möchten Sie erinnern, dass seit dem 8. Dezember 2020 für den Apple App Store Datenschutzangaben verpflichtend 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.

1.1 Welche Informationen müssen für die INFOnline ÖWA-Library angegeben werden?

Folgen Sie der Anleitung zum Update der App Privacy Details. Diese finden Sie unter folgendem Link:

Manage App Privacy Details – App Store Connect

1.2 Layer Datenerfassung

Frage: Erfassen Sie oder Ihre Drittanbieter Daten von dieser App?

Auszuwählende Antwort: Ja, wir erfassen Daten von dieser App

Auswahl Punkt Kennungen: Geräte-ID

Auswahl Punkt Nutzerdaten: Produktinteraktion Werbedaten

1.3 Layer Geräte-ID

Frage: Werden die von dieser App erfassten Geräte-IDs mit der Identität des Benutzers verknüpft?

Auszuwählende Antwort: Nein, die von dieser App erfassten Geräte-IDs werden nicht mit der Identität des Benutzers verknüpft.

Frage: Verwenden Sie oder Ihre Drittanbieter Geräte-IDs für Tracking-Zwecke?

Auszuwählende Antwort: Ja, wir verwenden Geräte-IDs für Tracking-Zwecke

1.4 Layer Produktinteraktion

Frage: Werden die von dieser App erfassten Daten zur Produktinteraktion mit der Identität des Benutzers verknüpft?

Auszuwählende Antwort: Nein, die von dieser App erfassten Produktinteraktion werden nicht mit der Identität des Benutzers verknüpft.

Frage: Verwenden Sie oder Drittpartner Daten zur Produktinteraktion für Tracking-Zwecke?

Auszuwählende Antwort: Ja, wir verwenden Produktinteraktion für Tracking-Zwecke

1.5 Layer Werbedaten

Frage: Werden die von dieser App erfassten Werbedaten mit der Identität des Benutzers verknüpft?

Auszuwählende Antwort: Nein, die von dieser App erfassten Werbedaten werden nicht mit der Identität des Benutzers verknüpft.

Frage: Verwenden Sie oder Ihre Drittpartner Werbedaten für Tracking-Zwecke?

Auszuwählende Antwort: Ja, wir verwenden Werbedaten für Tracking-Zwecke

1.6 Layer Gesamtübersicht

In diesem Layer sehen Sie nochmal den Überblick Ihrer Eingaben.

2 Informationen zum Apple Privacy Manifest

Ab dem 01. Mai 2024 ist es notwendig, als Third-Party-SDK Anbieter ein Privacy Manifest mitzuliefern. Zusätzlich zu den Privacy Nutrition Daten, welche seit ca. 2020 bereits angegeben werden müssen, müssen nun noch weitere Angaben getroffen werden.

Ein Privacy Manifest enthält alle Angaben zu Datenschutz-relevanten Themen, welche im Kontext der Veröffentlichung einer App im App Store relevant sind (und dort auch über die Privacy Nutrition Labels deklariert werden) sowie von Apple im Rahmen der App-Einreichung geprüft werden.

Damit die App-Entwickler einen ganzheitlichen Überblick über die Datenschutzinformationen der App inkl. der enthaltenen Frameworks/SDKs/Libraries von Dritten erhalten, sollen neben dem Manifest für die App auch die Manifeste der INFOnline Libraries iOS aufgeführt und eingelesen werden. Entwickler können sich für ihre App via Xcode einen sog. „Privacy Report“ generieren lassen, welcher alle Informationen aus allen Manifesten konsolidiert.
Diese müssen dann im Rahmen der Erstellung bzw. Konfiguration einer App in den App Store Metadaten, Abschnitt „App Datenschutz“, angegeben werden.

Zusätzlich zu den Informationen, welche Daten vom SDK erhoben werden, muss nun auch eine etwaige Nutzung der sog. „Required Reason APIs“ sowie der Grund für die Nutzung deklariert werden.
Darüber hinaus müssten auch die Tracking Domains angegeben werden, sofern die Funktion des SDKs unter „Tracking“ fällt.

(pseudonym / IOMp) Angaben des Privacy Manifests für die IOLib

Collected Data Types

Identifiers

DeviceID

  • used for Tracking
  • Purpose: Analytics

Usage Data

Product Interaction

  • used for Tracking
  • Purpose: Analytics

Advertising Data

  • used for Tracking
  • Purpose: Analytics

„Required Reason“ APIs (Apple iOS SDK APIs)

Die IOLib iOS nutzt nur eine deklarationspflichtige API zum Zwecke der Verarbeitung der Consent-Informationen gemäß TCF2.0:

API: User defaults APIs
Reason: CA92.1 : Read / write information accessible only by the app

Beispiel des Privacy Reports für die IOMp / pseudonyme Library

Der Privacy Report für die IOLib iOS sieht wie folgt aus:

(Zensus / IOMb) Angaben des Privacy Manifests für die IOMbLib

Collected Data Types

Identifiers

DeviceID

  • used for Tracking
  • Purpose: Analytics

Usage Data

Product Interaction

  • used for Tracking
  • Purpose: Analytics

Advertising Data

  • used for Tracking
  • Purpose: Analytics

„Required Reason“ APIs (Apple iOS SDK APIs)

Die IOMbLib iOS nutzt keine API dieser Art.

Beispiel des Privacy Reports für die IOMp / zensus Library

Der Privacy Report für die IOMbLib iOS sieht wie folgt aus:

3 Allgemeine Hinweise zur App-Messung

3.1 Wann muss die Library aufgerufen werden ?

Der Aufruf der Funktionen der IOLib innerhalb der App ist an bestimmte Events gebunden. Hierzu werden für die App-Anbieter seitens der ÖWA Vorgaben bzw. Empfehlungen formuliert, an welchen Stellen der App (bzw. bei welchen Nutzer-Aktionen) die ÖWA-Library aufgerufen werden soll und welche Informationen zu übermitteln sind.

3.2 Datenschutz

Die Nutzer einer App müssen darüber informiert werden, dass die App die Nutzeraktionen misst und an das Mess-System der INFOnline überträgt. Für diesen Zweck stellt INFOnline eine Datenschutzerklärung zur Verfügung. Bitte binden Sie diesen Text an entsprechender Stelle in die App ein.

Dem Nutzer der App muss eine Opt-out-Funktion gegeben werden. Die Implementierung dieser obliegt dem Entwickler der jeweiligen App. Nach Einbindung der Funktion können die Nutzer der App das Opt-out aktivieren und deaktivieren. Sofern das Opt-out aktiviert wird, wird kein Zählimpuls ausgelöst.

3.3 TCF 2.0

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.

Sobald TCF2.0 kompatible Consent Daten gemäß IAB TCF 2.0 Spezifikation identifiziert werden können, werden diese im Rahmen der automatischen Verarbeitung immer übermittelt. Ein im Rahmen der manuellen Verarbeitung definierter Consent String wird in diesem Fall ignoriert.

4 Hinweise zur IOLib iOS

Die consentpflichtige ÖWA-Library für iOS (im Folgenden auch „IOLib“ genannt) ist eine Software-Bibliothek, welche die Nutzung von iOS Apps erfasst, speichert und zum Zwecke der Validierung und Kontrolle an ein geeignetes Backend versendet. INFOnline stellt dieses Backend bereit.

4.1 Bereitstellung

Die IOLib iOS wird von INFOnline zum Download zur Verfügung gestellt. Die Zugangsdaten erhalten Sie per E-Mail.

Im Download Bereich befinden sich

  • die Release Notes als Textdatei
  • das Change Log als Textdatei
  • ein Verzeichnis INFOnlineLibrary: Die IOLib wird als Framework bereitgestellt und kann somit leicht in bereits existierende (ältere) iOS-Projekte integriert werden. Zu diesem Zweck kann das beiliegende Copy-Framework Script eingesetzt werden.
  • INFOnlineLibrary.xcframework: Die IOLib als XCFramework, um die Integration in moderne App-Projekte und die Entwicklung auf Apple Silicon Hardware zu unterstützen.
  • ein Verzeichnis ObjCSample: Ein Beispiel-Projekt auf Objective-C Basis, um die Integration der „Fat Binary“ zu demonstrieren.
  • ein Verzeichnis Swift Sample: Ein Beispiel-Projekt auf Swift 5 Basis, um die Integration des XCFramework zu demonstrieren.

4.2 Anforderungen

Die consentpflichtige ÖWA-Library für iOS unterstützt ausschließlich die Integration über die Entwicklungsumgebung Xcode unter macOS.

4.3 Entwicklungsumgebung

Um die Integration der IOLib iOS durchzuführen, sind folgende Voraussetzungen notwendig:

  • macOS 12.5 (Monterey) und höher
  • iOS SDK 16 und höher
  • Xcode 14 und höher
  • Objective-C oder Swift

iOS Apps, welche die IOLib iOS benutzen, müssen mind. mit iOS SDK 153 kompiliert werden. Deployment Target muss mind. auf 10.0 eingestellt werden.

4.4 Betriebssystem/Plattform

Die IOLib iOS unterstützt den Betrieb unter 32-Bit und 64-Bit Architekturen. Die IOLib iOS setzt für den Betrieb iOS 10.0 oder höher voraus.

4.5 Kompatibilität

Eine neue Version von Xcode bzw. des iOS-Betriebssystems macht evtl. ein Update der SZM-Library notwendig. Eine vollständige Aufwärtskompatibilität kann u.U. nicht gewährleistet werden.

5 Integration der ÖWA-Library iOS

Die Integration erfolgt in wenigen einfachen Schritten.

1. Im Finder: Den Ordner „INFOnlineLibrary“ in den Projekt-Ordner kopieren (oder per Drag’n’Drop ziehen)

Das Kopieren des „INFOnlineLibrary“ Ordners findet nur auf File Ebene statt. Weder der gesamte „INFOnlineLibrary“ Ordner noch das „INFOnlineLibrary.framework“ darf über Xcode dem Projekt hinzugefügt werden.

Ein manuelles Hinzufügen des „INFOnlineLibrary.framework“ als linked oder embedded Framework über das Xcode Interface ist nicht notwendig und kann gegebenenfalls zu Fehlern beim Code Signing oder der App Store Submission führen.

2. In Xcode: Build Settings

Den Pfad zum „INFOnlineLibrary“ Ordner zu den Framework Search Paths in den Build Settings hinzufügen.

In unserem Sample:

$(PROJECT_DIR)/../INFOnlineLibrary/$(PLATFORM_NAME)/
kopiert!

Bei den Other Linker Flags in den Build Settings muss die INFOnlineLibrary wie folgt angegeben werden:

3. In Xcode: Run Script Build Phase

Eine Run Script Phase zu den Build Phases hinzufügen:

In unserem Sample:

$(PROJECT_DIR)/../INFOnlineLibrary/copy-framework.sh
kopiert!

4. In Xcode: Linking des Frameworks AdSupport

Um eine korrekte und vollständige Messung zu gewährleisten, muss das o.g. Framework eingebunden werden.

Wenn Sie das Framework nicht einbinden, kann der erforderliche Identifier (Advertising Identifier / IDFA) nicht übermittelt werden.

Falls Sie in der Applikation keine Werbeplätze anbieten und aufgrund der Bestimmungen der Apple iTunes Connect Developer Guidelines eine Nutzung der Advertising Identifier nicht möglich ist, wenden Sie sich bitte an das ÖWA Customer Service Team per E-Mail an support@oewa.at.

Sie haben die technische Möglichkeit, anstelle der Advertising ID den Vendor Identifier (IDFV) zu nutzen. Hierzu entfernen Sie bitte das Linking des AdSupport-Frameworks. Als Konsequenz daraus erhebt die IOLib dann den Vendor Identifier (IDFV) anstelle des Advertising Identifier (IDFA).

Wir empfehlen Ihnen stets die Umsetzung mit Advertising Identifier (IDFA) gemäß Dokumentation.

5. In Xcode: Import der IOLib Header

Objective-C:

Import der IOLib Header im ApplicationDelegate und in den ViewControllern (alternativ im Prefix Header)

#import <INFOnlineLibrary/INFOnlineLibrary.h>
kopiert!

Es sollte immer der Umbrella Header benutzt werden und niemals einzelne Header aus dem Framework!

Swift:

Import des IOLib Frameworks im ApplicationDelegate und in den ViewControllern

import INFOnlineLibrary
kopiert!

Für die Verwendung der IOLib iOS in einem Swift-Projekt muss eine entsprechende Bridging-Header Datei in das Projekt eingefügt werden.

Beispiel für den Inhalt einer Bridging-Header Datei:

//
//  Use this file to import your target's public headers that you would like to expose to Swift.
//

import <INFOnlineLibrary/INFOnlineLibrary.h>
kopiert!

6. In Xcode: Initialisierung und Start einer Session der IOLib beim Application-Start:

Objective-C:

@implementation AppDelegate

- (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions {
    [self startSession];
 // Other code
    return YES;
}

- (void)startSession {
    // Initialisierung der IOLib; Session-Start
    // privacySetting LIN = Berechtigtes Interesse ist gegeben
    [[IOLSession defaultSessionFor:IOLSessionTypeOEWA] startSessionWithOfferIdentifier:@"" privacyType:IOLPrivacyTypeLIN];
}
kopiert!

Swift:

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey : Any]? = nil) -> Bool {
  self.startSession()
  // Other code
  return true
}

func startSession() {
  // Initialisierung der IOLib; Session-Start
  // privacySetting LIN = Berechtigtes Interesse ist gegeben
  IOLSession.defaultSession(for: .OEWA).start(withOfferIdentifier:"",  
  privacyType: .LIN)
}
kopiert!

7. In Xcode: Events können in den View Controllern der App geloggt werden, z.B. der Aufruf eines Views:

Objective-C:

// Tracking View Appeared
IOLViewEvent *event = [[IOLViewEvent alloc] initWithType:IOLViewEventTypeAppeared 
category:@"TestCategory" comment:nil];

[[IOLSession defaultSessionFor:IOLSessionTypeOEWA] logEvent:event];
kopiert!

Swift:

// Tracking View Appeared
let event = IOLViewEvent(type: .appeared, category: "TestCategory", comment: nil)
IOLSession.defaultSession(for: .OEWA).logEvent(event)
kopiert!

6 Consentpflichtige ÖWA-Library Funktionen

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

6.1 Aufruf der Default Session

Alle im Folgenden beschriebenen Funktionen der consentpflichtigen ÖWA-Library müssen auf dem Default Session Objekt aufgerufen werden. Dabei muss der SessionType als Parameter übergeben werden.

Parameter:

  • IOLSessionType (mandatory)
    Der Typ der zu verwendenden Session. Für die ÖWA-Messung muss IOLSessionTypeOEWA verwendet werden!

Beispiel:

Objective-C:

+(IOLSession*)defaultSessionFor:(IOLSessionType)sessionType;
IOLSession *session = [IOLSession defaultSessionFor:IOLSessionTypeOEWA];
kopiert!

Für die ÖWA-Messung muss als sessionType IOLSessionTypeOEWA übergeben werden.

Swift:

class func defaultSession(for sessionType: IOLSessionType) -> IOLSession
let session = IOLSession.defaultSession(for: .OEWA)
kopiert!

Für die ÖWA-Messung muss als sessionType .OEWA übergeben werden

6.2 Start einer Session

Die IOLib muss vor der Erfassung der Events gestartet werden. Dabei muss die Angebotskennung der App sowie die Datenschutz-Einstellung als Parameter übergeben werden.

Parameter:

  • Angebotskennung (mandatory)
    Eine eindeutige Kennung des Angebots der jeweiligen App. Die Angebotskennung wird von INFOnline pro App und pro Betriebssystem eindeutig vergeben.
  • Datenschutz-Einstellung (mandatory)
    Die Begründung, warum gemessen wird. Die möglichen Werte sind fest vorgegeben.

Beispiel (hier ist die Angebotskennung “iamtest” und die Datenschutz Einstellung „LIN“):

Objective-C:

- (void)startSessionWithOfferIdentifier:(NSString*)offerID privacyType:(IOLPrivacyType)privacyType;
[session startSessionWithOfferIdentifier:@„iamtest“ privacyType:IOLPrivacyTypeLIN];
kopiert!

Swift:

func start(withOfferIdentifier offerIdentifier: String, privacyType: IOLPrivacyType)
session.start(withOfferIdentifier: „iamtest“, privacyType: .LIN)
kopiert!

6.3 Logging eines Events

Die Messdaten werden mittels des Aufrufs logEvent erfasst. Dabei muss ein zuvor initialisiertes Event übergeben werden.

Objective-C:

- (void)logEvent:(IOLEvent*)event;
kopiert!

Swift:

func logEvent(_ event: IOLEvent)
kopiert!

Um ein Event zu erzeugen, muss ein Initializer der entsprechenden IOLEvent-Subklasse aufgerufen werden. Dabei können bis zu vier Parameter übergeben werden, drei davon sind optional.

Objective-C:

- (IOL_xy_Event*)initWithType:(IOL_xy_EventType)type;
- (IOL_xy_Event*)initWithType:(IOL_xy_EventType)type category:(nullable NSString*)category comment:(nullable NSString*)comment;
- (IOL_xy_Event*)initWithType:(IOL_xy_EventType)type category:(nullable NSString*)category comment:(nullable NSString*)comment parameter:(nullable NSDictionary*)parameter;
kopiert!

Swift:

public init(type: IOL_xy_EventType) -> IOL_xy_Event
public init(type: IOL_xy_EventType, category: String?, comment: String?) -> IOL_xy_Event
public init(type: IOL_xy_EventType, category: String?, comment: String?, parameter: [String: String]?) -> IOL_xy_Event
kopiert!

Die ersten beiden Aufrufe sind Convenience-Funktionen, welche intern die Letztgenannte aufrufen.

Die fehlenden Werte werden dann um nil bzw. Default-Werte ergänzt.

Einige der Events werden durch die IOLib automatisch erfasst. Weitere Details hierzu finden sich in Kapitel 6.6 (Automatisch durch die IOLib gemessene Events).

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)
    Der Contentpath wird im Parameter “category“ übermittelt. Dieser Contentpath wird vom Anbieter selbst festgelegt. Der Contentpath dient zur inhaltlichen Kennzeichnung des angezeigten Contents. Der Anbieter entscheidet anhand der im Kapitel 6.3 (Richtlinien zur Vergabe der Codes) beschriebenen Richtlinien, ob ein Event eine mobile PI im Sinne der ÖWA Richtlinien darstellt. Wenn ein Event unter die Definition einer mobilen PI fällt, ist zwingend ein Contentpath mitzugeben. Stellt ein Event keine mobile PI dar, soll nil übergeben werden. Die Länge dieses Feldes ist auf 255 Zeichen beschränkt.
  • Kommentar (optional)
    Kommentarfeld. Die Länge dieses Feldes ist nicht beschränkt. Übergabe dieses Wertes ist optional, ist er nicht definiert, soll nil übergeben werden.
  • Parameter (optional)
    Ein Dictionary 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, ist er nicht definiert, soll nil übergeben werden.

6.4 Verfügbare Events

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

  • IOLViewEvent
    • IOLViewEventTypeAppeared

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

IOLViewEvent / IOLViewEventTypeAppeared

Objective-C:

@implementation ViewController
- (void)viewDidAppear:(BOOL)animated {
   [super viewDidAppear:animated];
   IOLEvent *event = [IOLViewEvent initWithState:IOLViewEventTypeAppeared
                                     category:@”Home”
                                      comment:nil];
[[IOLSession defaultSessionFor:IOLSessionTypeOEWA] logEvent:event];    
   // Other Code ..
}
kopiert!

Swift:

class ViewController: UIViewController {
   override func viewDidAppear(_ animated: Bool) {
      super.viewDidAppear(animated)
      let event = IOLViewEvent(type: .appeared,
                        category: "Home"
                         comment: nil)
   IOLSession.defaultSession(for: .OEWA).logEvent(event)
      // Other Code ..
   }
}
kopiert!

Versand der Messdaten

- (void)sendLoggedEvents;
kopiert!

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. alternativ nochmals zu versenden, sobald eine Datenverbindung aufgebaut wurde.

Beispiel:

Objective-C:

@implementation ViewController
- (IBAction)send:(id)sender {
   [[IOLSession defaultSessionFor:IOLSessionTypeOEWA] sendLoggedEvents];
}
kopiert!

Swift:

class ViewController: UIViewController {
   @IBAction func send(sender: AnyObject) {
   IOLSession.defaultSession(for: .OEWA).sendLoggedEvents()
   }
}
kopiert!

Session beenden

- (void)terminateSession;
kopiert!

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 nicht mehr versendet.

Nur bei Opt-out durch den Nutzer verwenden!

Beispiel:

Objective-C:

@implementation ViewController
- (void)disableIOLSession {
   [[IOLSession defaultSessionFor:IOLSessionTypeOEWA] terminateSession];
}
kopiert!

Swift:

class ViewController: UIViewController {
   func disableIOLSession() {
   IOLSession.defaultSession(for: .OEWA).terminateSession()
   }
}
kopiert!

Die IOLib Session muss anschließend neu gestartet werden! Das Vorgehen ist in Kapitel 5.2 (Start einer Session) beschrieben.

6.5 Einbindung Opt-out Funktion

Den 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 consentpflichtige ÖWA-Library 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.

Wird die laufende Session explizit beendet, dann werden alle bis dahin erfassten, aber noch nicht versandten Messdaten verworfen.

Wird das Opt-out revidiert, dann sollte die MessLib wieder gestartet werden. Das Vorgehen ist in Kapitel Start einer Session beschrieben.

6.6 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 Session gestartet wird (vergl. Kapitel „Start einer Session“). Bitte übermitteln Sie in diesem Fall das Privacy-Setting „ACK“.

Beispiel:

Swift:

session.start(withOfferIdentifier: „iamtest“, privacyType: .ACK)
kopiert!

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

Objective-C:

@implementation AppDelegate
- (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions {
   [self startSession];
   // Other code
   return YES;
}
- (void)startSession {
  // Initialisierung der IOLib; Session-Start
  // privacySetting LIN = Berechtigtes Interesse ist gegeben
  [[IOLSession defaultSessionFor:IOLSessionTypeOEWA]
    startSessionWithOfferIdentifier:@""
    privacyType:IOLPrivacyTypeLIN];
  [[IOLSession defaultSessionFor:IOLSessionTypeOEWA] 
    setCustomConsent:@""]; // s. IO Consent String Notation
}  
kopiert!

Swift:

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey : Any]? = nil) -> Bool {
  self.startSession()
  // Other code
  return true
}
func startSession() {
  // Initialisierung der IOLib; Session-Start
  // privacySetting LIN = Berechtigtes Interesse ist gegeben
  IOLSession.defaultSession(for: .OEWA).start(withOfferIdentifier:"", 
  privacyType: .LIN)
  IOLSession.defaultSession(for: .OEWA).setCustomConsent("") // s. IO Consent String Notation
}  
kopiert!

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 consent aufgerufen werden. Diese retourniert den zur Übermittlung aktuell verwendeten IO Consent String.

Objective-C:

[IOLSession defaultSessionFor:IOLSessionTypeOEWA].consent;
kopiert!

Swift:

IOLSession.defaultSession(for: .OEWA).consent()
kopiert!

7 Vorgaben zum Aufruf der consentpflichtigen ÖWA-Library

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

Die Nutzer-Interaktion wird als Event bezeichnet.

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

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

7.1 Interpretation von Events als mobile PI

Die nachfolgend aufgeführten Vorgaben definieren, wie die consentpflichtige ÖWA-Library im Kontext der ÖWA Mobile Applications Messung zu verwenden ist.

Aus technischer Sicht wird zwischen 2 Typen von Events unterschieden:

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

Eine PageImpression 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 potenziellen Werbeauslieferung führen, dürfen nicht gezählt werden.

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.

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

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

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

Bei den PI-Events sind die Vorgaben zur PageImpression der ÖWA zu beachten.

  • 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 IOMb-Library iOS per logEvent aufzurufen. Hierbei ist eine Instanz der entsprechenden IOLEvent-Subklasse als Parameter zu übergeben (siehe dazu auch „IOMb-Library iOS Funktionen“).

8 Debug-Informationen

Zum Zweck der allgemeinen Fehleranalyse und insb. des Versands der Messdaten kann die IOLib in einen Debug-Modus versetzt werden. In diesem Debug-Modus erzeugt die IOLib Ausgaben im Logstrom (Konsole).

Objective-C:

- (BOOL)application:(UIApplication*)application 
didFinishLaunchingWithOptions:(nullable NSDictionary*)launchOptions {
   [IOLLogging setDebugLogLevel:IOLDebugLevelInfo];
   return YES;
}
kopiert!

Swift:

func application(_ application: UIApplication, didFinishLaunchingWithOptions 
launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) → Bool {
   IOLLogging.setDebugLogLevel(.info)
   return true
}
kopiert!

Art und Umfang der Logausgaben können über einen DebugLevel bestimmt werden.

Folgende Debug-Level sind definiert:

  • IOLDebugLevelOff
    Logausgabe: Deaktiviert (Default)
  • IOLDebugLevelError
    Logausgabe: nur Fehler
  • IOLDebugLevelWarning
    Logausgabe: Fehler und Warnungen
  • IOLDebugLevelInfo
    Logausgabe: Fehler, Warnungen und Infos
  • IOLDebugLevelTrace
    Logausgabe: Fehler, Warnungen, Infos, Events, Requests und Responses

9 TCF 2.0 in iOS

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.

Sobald TCF2.0 kompatible Consent Daten gemäß IAB TCF2.0 Spezifikation identifiziert werden können, werden diese im Rahmen der automatischen Verarbeitung immer übermittelt. Ein im Rahmen der manuellen Verarbeitung definierter Consent String wird in diesem Fall ignoriert.

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

Objective-C:

implementation AppDelegate
- (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions {
   [self startSession];
  // Other code
     return YES;
}
- (void)startSession {
  // Initialisierung der IOLib; Session-Start
  // privacySetting LIN = Berechtigtes Interesse ist gegeben
  [[IOLSession defaultSessionFor:IOLSessionTypeOEWA]
     startSessionWithOfferIdentifier:@""
     privacyType:IOLPrivacyTypeLIN];
  [[IOLSession defaultSessionFor:IOLSessionTypeOEWA] 
     setCustomConsent:@""]; // s. IO Consent String Notation
}
kopiert!

Swift:

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey : Any]? = nil) -> Bool {
   self.startSession()
   // Other code
     return true
}
func startSession() {
   // Initialisierung der IOLib; Session-Start
   // privacySetting LIN = Berechtigtes Interesse ist gegeben
      IOLSession.defaultSession(for: .OEWA).start(withOfferIdentifier:"", 
      privacyType: .LIN)
      IOLSession.defaultSession(for: .OEWA).setCustomConsent("") // s. IO Consent String Notation
}
kopiert!

Wie bereits erwähnt, priorisiert die IOLib die automatischen 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 consent aufgerufen werden. Diese retourniert den zur Übermittlung aktuell verwendeten IO Consent String.

Objective-C:

[IOLSession defaultSessionFor:IOLSessionTypeOEWA].consent;
kopiert!

Swift:

IOLSession.defaultSession(for: .OEWA).consent()
kopiert!

10 App Tracking Transparency Framework (ab iOS 14)

Mit Einführung von iOS14 wird der bisherige LAT (Limit Ad Tracking) Mechanismus durch das neue Framework „App Tracking Transparency“ (ATT) abgelöst. Die IOLib iOS unterstützt ATT ab Version 2.2.0 und respektiert die über die App einzuholende Einwilligung resp. Ablehnung der Nutzer ebenso wie die Einstellungen/Restriktionen im jeweiligen Endgerät.
Zur Erhebung des erforderlichen Identifier (Advertising Identifier / IDFA) müssen Apps, welche das iOS14 SDK oder höher nutzen, die notwendigen Schritte gemäß Apple iOS Developer Dokumentation auszuführen.

Im Wesentlichen sind dies die folgenden 2 Schritte:

1. In Xcode: Neuen Key in Info.plist einfügen

In der Information Property List des Projekts muss ein neuer Key „NSUserTrackingUsageDescription“ angelegt werden:

Dieser enthält einen Text (String) zur Erläuterung der Begründung für die Abfrage zum Tracking der Werbe-ID (IDFA) durch die jeweilige App.

2. In Xcode:

Direkt nach Start der App sollte die Authorisierungsanfrage ausgelöst werden, indem die Methode „requestTrackingAuthorization“ aufgerufen wird.

Objective-C:

#import <AppTrackingTransparency/AppTrackingTransparency.h>
...
-(BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(nullable NSDictionary*)launchOptions {
    [self requestIDFA];
    //start IOLSession
    return YES;
}

-(void)requestIDFA {
  [ATTrackingManager requestTrackingAuthorizationWithCompletionHandler:^(ATTrackingManagerAuthorizationStatus status) {
    // Tracking authorization completed
  }];
}
kopiert!

Swift:

import AppTrackingTransparency
...
func application(_ application: UIApplication, didfinishlaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) → Bool {
  requestIDFA()  
  //start IOLSession  return true 
}
private func requestIDFA()  { 
ATTrackingManager.requestTrackingAuthorization(completionHandler: { status in   
  // Tracking authorization completed 
  }) 
}
kopiert!

Wird diese Anfage zum ersten Mal gestellt, erscheint folgender Alert (Beispiel aus IOLibSample):

Der Text innerhalb des roten Rahmens entspricht exakt dem String, welcher in Schritt 1 in der Info.plist unter „NSUserTrackingUsageDescription“ definiert wurde.

Das iOS System persistiert die Wahl des Nutzer, daher erscheint dieser Alert exakt einmal. Wurde die Erlaubnis zur Abfrage in den System-Einstellungen des Gerätes global deaktiviert, dann wird der Alert nicht angezeigt.

Es ist ratsam, den App Nutzern vor Aufruf der ATT-Authorisierungsabfrage die Hintergründe dieser Abfrage ausführlicher zu erläutern. Dies könnte die Opt-in Quote deutlich erhöhen.