Kontakt zur INFOnline

Service Center im Überblick

Sie erreichen uns montags bis freitags zwischen 09:00 Uhr – 18:00 Uhr

Customer Service | e-Mail | 0228 / 41 0 29 77

Service Center IVW digital | e-Mail | 0800 / 58 91 788 

agof service center | e-Mail | 0800 / 41 0 29 77

MMC Service Center Webradio | e-Mail | 0800 / 41 0 29 29

Support

Code-Management bei hybriden Apps

Sie sind hier:

Messung hybrider Apps

INFOnline bietet mit der Messung von mobilen Applikationen auch die Möglichkeit an, hybride Apps zu messen. Die Definition der hybriden App nach IVW Richtlinien besagt, dass Apps, die einen nativen App-Teil haben, aber für ihren Content auch auf eine oder mehrere mobile enabled Website(s) zugreifen („hybride Apps“), werden bei der Zuordnung und Ausweisung im Kategoriensystem 2.0 (Kat 2.0) mit ihrer gesamten Nutzung einheitlich als App behandelt.
Das SZMnG-Messsystem setzt diese Richtlinie um, indem der im WebView einer hybriden App erzeugte Traffic einer mobile enabled Website (MEW) zur Laufzeit bei der Erzeugung der MessRequests nicht der Angebotskennung der MEW, sondern der Angebotskennung der App zugeordnet wird. MEW-Traffic, der nicht aus einer hybriden App, sondern über einen mobilen Standard-Browser erzeugt wird, wird nach wie vor regulär der MEW-Angebotskennung zugeordnet.

Die Umsetzung dieser Richtlinie hat Auswirkungen auf das Management der Codes, die den Inhalt des Contents klassifizieren und die im Code-Management nach Kategoriensystem KAT 2.0 zugeordnet werden müssen.

Sonderfall native App mit hybrider Messtechnologie: 

  • Hierbei handelt es sich um eine hybride App, deren Web-Content nicht von extern erreichbar ist.
  • Die eingangs zitierte Richtlinie der IVW nimmt Bezug auf mobile enabled Websites. Ein Merkmal von MEWs ist, dass sie unter einer eigenen öffentlich zugänglichen URL Content anbieten, der für die Browser mobiler Endgeräte optimiert ist.
  • In der Praxis gibt es eine Sonderform der hybriden App. Diese Apps haben einen nativen
  • App-Anteil und nutzen zusätzlich mobil optimierten Web-Content, der allerdings nicht eigenständig aus der MEW angeboten wird. Dieser Web-Content basiert auf der gleichen Technologie wie MEWs, ist jedoch ausserhalb der hybriden App nicht zu erreichen. Diese Art von Apps wird in der Folge als native App mit hybrider Messtechnologie bezeichnet. 
  • Das Code-Management für den Sonderfall der nativen App mit hybrider Messtechnologie wird in Kapitel 4 (Code-Management bei nativen Apps mit hybrider Messtechnologie) beschrieben.

Code-Management bei hybriden Apps

Ausgangslage

Hybride Apps setzen sich inhaltlich aus zwei Komponenten zusammen:

  • Komponente 1 bildet der native App-Rahmen
  • Komponente 2 bilden die Inhalte, die über den in die App integrierten WebView von einer mobile enabled Website (MEW) geladen werden

Folgende Voraussetzungen müssen für die Messung hybrider Apps gegeben sein:

  • Die App hat eine eigene Angebotskennung (in der Folge als AngebotskennungApp bezeichnet). Für Inhalte, die über den nativen App-Rahmen dargestellt werden, werden Codes vergeben. Diese Codes sind im SZM-System der AngebotskennungApp zugeordnet.
  • Die MEW ist mit dem SZM-Tag 2.0 (in der Variante iom.h für hybride Messung) vertaggt. Die MEW hat eine eigene Angebotskennung (in der Folge als AngebotskennungMEW bezeichnet). Die Inhalte der MEW werden durch Codes klassifiziert, die der AngebotskennungMEW zugeordnet sind.
  • Die Integration der hybriden App-Messung, wie sie in den Integration Guides der
    INFOnline zur App- und zur MEW- Messung beschrieben wird.

Zuordnung des MEW-Anteils der hybriden App-Nutzung zur App (technisch)

Nach den IVW- und AGOF-Vorgaben ist der Nutzungsanteil einer hybriden App, der im WebView durch Aufruf einer MEW entsteht, der App zuzuordnen. Die technische Umsetzung dieser Vorgabe ist im SZM-System wie folgt realisiert:

  • Messung des nativen App-Anteils: Alle Nutzungsvorgänge, die innerhalb des nativen
    App-Anteils gemessen werden, werden unter der AngebotskennungApp ans SZM-System gemeldet. Jene Nutzungsvorgänge, die eine mobile Impression darstellen, werden mit einem vom App-Anbieter festgelegten und im Kategoriensystem KAT 2.0 zuzuordnenden Code versehen.
  • Messung des MEW-Anteils: Wird innerhalb der App der WebView aufgerufen, um eine MEW darzustellen, sind die Abläufe in der Messung wie folgt:
    1. Die aufgerufene MEW-Webseite beinhaltet einen SZM-Tag 2.0 mit der AngebotskennungMEW
    2. Das über den SZM-Tag 2.0 aufgerufene Skript iom.h erkennt eigenständig, dass der Aufruf in einem WebView einer hybriden App stattfindet. Es schreibt automatisch die Angebotskennung für den Mess-Aufruf auf AngebotskennungApp um
    3. Gleichzeitig wird der Code, der den Inhalt klassifiziert, um einen Präfix ergänzt. Dieser lautet: ___hyb___AngebotskennungMEW___

 

Nachfolgende Tabelle stellt an einem Beispiel den ursprünglichen MEW-Request und den in der hybriden Messung dynamisch angepassten Aufruf einander gegenüber:

Wert

MEW-Request (integriert in MEW-Quelltext)

Dynamisch zur Laufzeit angepasster hybrid-App-Request

Angebotskennung („st:“)

AngebotskennungMEW

AngebotskennungApp

Code („cp:“)

Home1234

___hyb___AngebotskennungMEW___Home1234

Hinweis

Der Präfix der Kennzeichnung nimmt 20 Zeichen in Anspruch. Um die Eindeutigkeit der Code-Ableitungen unterhalb der App-Kennungen zu gewährleisten, darf der Code in der MEW nicht länger als 234 Zeichen sein. Sollten die MEW-Codes länger als 234 Zeichen sein, kann eine korrekte Synchronisation der Zuordnung nicht gewährleistet werden.

Code-Management

Die in 3.2 dargestellte dynamische Anpassung des Mess-Requests im MEW-Anteil der hybriden App hat zur Folge, dass unter der AngebotskennungApp Codes einlaufen, die dort nicht ihren Ursprung haben.

Code-Ableitungen

Der im Beispiel benannte MEW-Code Home1234 wurde in der MEW angelegt und unter der AngebotskennungMEW dem Kategoriensystem 2.0 zugeordnet.

Durch den Aufruf im Rahmen einer hybriden App ist unterhalb der AngebotskennungApp eine Ableitung des MEW-Codes ___hyb___AngebotskennungMEW___Home1234 in das SZM-System geliefert worden.

Zuordnung der abgeleiteten Codes im Code-Management nach KAT 2.0

Um die Zuordnung der abgeleiteten Codes unterhalb der AngebotskennungApp zu vereinfachen und dem Kunden den Aufwand der x-fachen Pflege der Zuordnung der abgeleiteten Codes zu ersparen (ein Code müsste sonst unterhalb der AngebotskennungMEW und unterhalb aller AngebotskennungApp, die die MEW im hybriden Anteil nutzen, manuell gepflegt werden), hat INFOnline eine automatische Synchronisation der Zuordungen im Code-Management nach Kategoriensystem KAT 2.0 eingerichtet.

Diese sorgt dafür, dass die Kategorienzuordnung des MEW-Code

im Beispiel Home1234 unter der AngebotskennungMEW

auf alle Ableitungen des Codes

___hyb___AngebotskennungMEW___Home1234 unterhalb aller AngebotskennungApp

übertragen werden.

Hinweis

Für den Kunden bedeutet dies, dass die Pflege der Kategorienzuordnung des Codes ausschließlich unter der AngebotskennungMEW erfolgt. Die Ableitungen des Codes sind unterhalb der AngebotskennungApp sichtbar, jedoch nicht editierbar.

Anpassung der Kategorie "App"

In den nachfolgenden Kategorien des Kategoriensystems KAT 2.0 werden die Kategorienzuordnungen eines Codes unverändert auf die Ableitungen des Codes übertragen.

 

  1. Format
  2. Sprache
  3. Erzeuger
  4. Homepage
  5. Auslieferung
  6. Paid Content / Service*
  7. Inhalt

 

Die Kategorie „6. App“ in den Ableitungen der Codes unterhalb der AngebotskennungApp wird im Rahmen der Synchronisation immer auf den Wert „App“ gesetzt.

Weitere Informationen

Diese Synchronisation findet täglich um 0:00 Uhr statt, sodass eine tagesaktuelle Zuordnung der abgeleiteten Codes analog der Zuordnung des MEW-Codes gewährleistet ist.

Deaktivierung der Synchronisation

Sollten Sie die beschriebene automatische Synchronisation der Code-Zuordnungen nicht wünschen, nehmen Sie bitte mit dem INFOnline Service & Support Kontakt auf.

Code-Management bei nativen Apps mit hybrider Messtechnologie

Ausgangslage

Native Apps mit hybrider Messtechnologie setzen sich analog zum Aufbau der hybriden Apps inhaltlich aus zwei Komponenten zusammen: Komponente 1 bildet der native App-Rahmen und Komponente 2 stellen die Inhalte dar, die über den in die App integrierten WebView geladen werden. Im Unterschied zu hybriden Apps ist die Quelle der Web-Inhalte nicht öffentlich, sondern ausschließlich aus der nativen App mit hybrider Messtechnologie erreichbar.

Folgende Voraussetzungen für die Messung von nativen Apps mit hybrider Messtechnologie müssen erfüllt sein:

  • Die App hat eine eigene Angebotskennung (in der Folge als AngebotskennungApp bezeichnet). Für Inhalte, die über den nativen App-Rahmen dargestellt werden, werden Codes vergeben. Diese Codes sind im SZM-System der AngebotskennungApp
  • Die über den WebView eingebundenen Web-Inhalte sind mit dem SZM-Tag 2.0 (in der Variante iom.h für hybride Messung) vertaggt. Im SZM-Tag 2.0 wird die Angebotskennung der App verwendet, welche die Inhalte nutzt (in der Folge als AngebotskennungWebInhalt bezeichnet). Die Web-Inhalte enthalten Codes, die zur Kategorisierung der Inhalte im Code-Management nach Kategoriensystem KAT 2.0 verwendet werden.

 

Zuordnung des MEW-Anteils der hybriden App-Nutzung zur App (technisch)

Nach den IVW- und AGOF- Vorgaben ist der Nutzungsanteil einer hybriden App, der im WebView durch den Aufruf einer MEW entsteht, der App zuzuordnen. Die technische Umsetzung dieser Vorgabe ist im SZM-System wie folgt realisiert:

  • Messung des nativen App-Anteils: Alle Nutzungsvorgänge, die innerhalb des nativen
    App-Anteils gemessen werden, werden unter der AngebotskennungApp ans SZM-System gemeldet. Jene Nutzungsvorgänge, die eine mobile Impression darstellen, werden mit einem vom App-Anbieter festgelegten und im Code-Management gem. Kategoriensystem KAT 2.0 zuzuordnenden Code versehen.

 

  • Messung des Anteils der Web-Inhalte: Wird innerhalb der App der WebView aufgerufen, um Web-Inhalte darzustellen, sind die Abläufe in der Messung wie folgt:
    1. Die aufgerufenen Web-Inhalte beinhalten einen SZM-Tag 2.0 mit der AngebotskennungWebInhalt
    2. Das über den Tag aufgerufene SZM 2.0 Tag Skript iom.h erkennt eigenständig, dass der Aufruf in einem WebView einer hybriden App stattfindet. Es schreibt automatisch die Angebotskennung für den Mess-Aufruf auf AngebotskennungApp um
    3. Gleichzeitig wird der Code, der den Inhalt klassifiziert, um einen Präfix ergänzt. Dieser lautet: ___hyb2___AngebotskennungWebInhalt___

 

Nachfolgende Tabelle stellt an einem Beispiel den ursprünglichen Web-Inhalt-Request und den in der hybriden Messung dynamisch angepassten Aufruf einander gegenüber:

Wert

Webview-Request (integriert in Quelltext des Web-Inhaltes)

Dynamisch zur Laufzeit angepasster hybrid-App-Request

Angebotskennung („st:“)

AngebotskennungWebInhalt

AngebotskennungApp

Code („cp:“)

Home1234

___hyb2___AngebotskennungWebInhalt___Home1234

Hinweis

Der Präfix der Kennzeichnung nimmt 21 Zeichen in Anspruch. Um die Eindeutigkeit der Code-Ableitungen unterhalb der App-Kennungen zu gewährleisten, darf der Code innerhalb des Web-Inhaltes nicht länger als 233 Zeichen sein. Sollten die Codes der Web-Inhalte länger als 233 Zeichen sein, werden sie vom System automatisch abgeschnitten. Dies hat zur Folge, dass zwei oder mehr Codes, die sich erst nach dem 233 Zeichen unterscheiden, im Mess-System zu einem Code zusammengefasst werden, so dass die Inhalte u.U. nicht korrekt im
Code-Management nach Kategoriensystem KAT 2.0 zugeordnet werden können.

Code-Management

Die unter 4.2 dargestellte dynamische Anpassung des Mess-Requests im Web-Anteil der nativen App mit hybrider Messtechnologie hat zur Folge, dass unter der AngebotskennungApp Codes einlaufen, die das Präfix ___hyb2___AngebotskennungWebInhalt___ tragen.

Diese sind analog zu den Codes aus dem nativen App-Rahmen im Code-Management des Kundencenters der INFOnline unter der AngebotskennungApp aufgeführt und können dort nach Kategoriensystem KAT 2.0 zugeordnet werden.

Zu beachten

Nutzen mehrere native Apps mit hybrider Messtechnologie dieselben nicht öffentlich erreichbaren Web-Inhalte, so muss die Zuordnung der daraus entstehenden Codes mit dem Präfix ___hyb2___AngebotskennungWebInhalt___ in jeder App separat erfolgen!

Beispiel:

Bieten Sie z.B. eine App für iOS und eine für Android an, welche dieselben Web-Inhalte über einen WebView einbinden, so müssen Sie die Code-Zuordnung der Codes, welche die
Web-Inhalte klassifizieren (erkennbar am genannten Präfix), sowohl in der Angebotskennung der iOS-App als auch in der Angebotskennung der Android-App im Code-Management nach Kategoriensystem KAT 2.0 zuordnen!