Implemen­tierung App Android

1 Über diese Anleitung

Die vorliegende Anleitung dient dazu, alle notwendigen Informationen für die technische Integration und Nutzung der ÖWA-Library in Apps mit dem Betriebsystem Android zur Verfügung zu stellen. Die unterstützte App-Platform ist hier Android ab Version 5.0.

2 ÖWA-Library (Android)

Die ÖWA-Library für Android bereitgestellt durch INFOnline (im Folgenden auch „IOLib“ genannt) ist eine Software-Bibliothek, welche die Nutzung von Android Apps erfasst, speichert und zum Zwecke der Vailidierung und Kontrolle an das Mess-System sendet.

2.1 Bereitstellung

Die IOLib wird von der ÖWA zum Download zur Verfügung gestellt. Im Download befinden sich:

  • die Release Notes als Textdatei
  • das Change Log als Textdatei
  • die Android Library als binäre Distribution (.aar)
  • ein Android Studio Projekt „INFOnlineLibSample“: Eine Beispiel-App mit integrierter IOLib

2.2 Anforderungen

Die ÖWA-Library für Android unterstützt die Integration über die Entwicklungsumgebung „Android Studio“ unter Windows/macOS bzw. Linux.

2.2.1 Entwicklungsumgebung

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

  • Android SDK Release 24 und höher
  • Android Studio 3.0 und höher
  • Google Play Services 10 und höher

Android Apps, welche die IOLib benutzen, müssen min. mit Android 5.0 (API Level 20) kompiliert werden. Minimum SDK Version im Manifest ist somit 20.

Die IOLib kompiliert mit Android SDK r26. Android Apps, welche mit älteren Versionen des Android SDK kompiliert werden bei Verwendung von ProGuard womöglich mit folgender Warnung konfrontiert:

Warning: de.infonline.lib.IOLWebViewClientV24: can’t find referenced method ‚boolean shouldOverrideUrlLoading(android.webkit.WebView,android.webkit.WebResourceRequest)‘ in library class android.webkit.WebViewClient

Diese Warnung kann mit der ProGuard direktive ‚-dontwarn android.webkit.WebViewClient‘ ignoriert werden, da die fehlende Referenz erst mit Android SDK r24 hinzugefügt wurde.

2.2.2 Betriebssystem

Die IOLib setzt für den Betrieb Android 5.0 oder höher voraus.

2.2.3 Kompatibilität

Eine neue Version des Android Betriebssystems macht evtl. ein Update der Library notwendig.
Eine vollständige Aufwärtskompatibilität kann u.U. nicht gewährleistet werden.

2.3 Funktionsweise

2.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 IOLib aufgerufen werden soll und welche Informationen zu übermitteln sind.
Die Vorgaben zum Aufruf der IOLib innerhalb der App werden in Kapitel 4 (Vorgaben zum Aufruf der Library) beschrieben.

2.3.2 Übertragung der Messdaten

Der Versand der Daten selbst findet asynchron statt. Dadurch wird die Interaktion des Benutzers mit der App nicht verzögert oder blockiert.

3 Integration der ÖWA-Library Android

Dieses Kapitel beschreibt die technische Integration der ÖWA-Library in eine Android-Projektstruktur.

3.1 Thread-safe

Die IOLib ist vollständig Thread-safe implementiert.

3.2 IOLib Dateien

Die Ö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_x.x.x.aar“
    Die IOLib zur Erfassung der Nutzungsdaten einer Android-App als binäre Distribution
  • Verzeichnis „INFOnlineLibrarySample“
    Ein Beispiel-Projekt für Android Studio, welches den Einsatz der IOLib demonstriert

3.3 Integration der IOLib MessLibrary

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 <MyApp>/app/libs)

2. In Android Studio: build.gradle anpassen

  • Die Datei <MyApp>/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 API der Google Play Services Library   implementation 'com.google.android.gms:play-services-ads:11.8.0'

  //Die INFOnline Library verlinken
  implementation 'de.infonline.lib:infonlinelib_X.X.X@aar'
}
kopiert!

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 muss in der onCreate() Methode der Application initialisiert werden!

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); // Debug modePrivacy Setting on/off
   }
}
kopiert!

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
   }
kopiert!

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
}
kopiert!

4. In Android Studio: Code

  • IOLib kann explizit gestoppt und gestartet werden
IOLSession.getSessionForType(IOLSessionType.OEWA).startSession();
IOLSession.getSessionForType(IOLSessionType.OEWA).terminateSession();
kopiert!

Dies funktioniert nur, wenn die IOLSession in der onCreate() Methode der Application initialisiert wurde! Die Methode ist in Kapitel 3.3 / Pkt.3 beschrieben.

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 AppearedIOLSession.getSessionForType(IOLSessionType.OEWA)
  .logEvent(new IOLViewEvent(IOLViewEventType.appeared));
kopiert!

3.4 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 Google Mobile Ads API:

dependencies {
  implementation 'com.google.android.gms:play-services-ads:11.8.0'
}
kopiert!

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

Die Integration der Google Play Services Library muss auch für Apps erfolgen, welche nicht im Google Play Store veröffentlicht werden!

3.5 Parallel-Messung ÖWA und INFOnline (IVW, AGOF)

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

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

3. 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
}
kopiert!

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
  }
kopiert!

Zur Laufzeit dann die Initialisierung der Session für beide Mess-Systeme:

public void initIOLSession() {

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

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

4. In Android Studio: Code

  • IOLib für beide aktive Sessions explizit starten
IOLSession.getSessionForType(IOLSessionType.SZM).startSession();
IOLSession.getSessionForType(IOLSessionType.OEWA).startSession();
kopiert!

Dies funktioniert nur, wenn die IOLSession in der onCreate() Methode derApplication initialisiert wurde! Die Methode 1) ist in Kapitel 3.3 / Pkt.3 beschrieben.

5. In Android Studio: Jede Activity

  • Events werden über die IOLSession, jeweils in das selektierte Mess-System 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));
kopiert!

3.6 IOLib Funktionen

Die IOLib bietet die im Folgenden beschriebenen Funktionen:

3.6.1 Nutzung der IOLib im OEWA-Modus

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);
kopiert!

3.6.2 Initialisierung

initIOLSession(String offerIdentifier, boolean debugModeEnabled, IOLSessionPrivacySetting privacySetting)

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

Die IOLib muss vor der Erfassung der Events initalisiert werden. Dabei muss die Angebotskennung der App als Parameter übergeben werden.

Paremeter:

  • 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 ÖWA 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-Einstellung (mandatory)
    Angabe, auf welcher Rechtsgrundlage gemessen wird. Im Fall der ÖWA ist hier LIN zu verwenden.

Beispiel:

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

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

3.6.4 Instanzierung einer Event Klasse

IOLEvent(EventType eventType, String category, String comment, Map<String, String> 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

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 ..
   }
}
kopiert!

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

Parameter:

Beispiel:

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

3.6.6 Debug Modus

setDebugModeEnabled(boolean enable);

Die Messlib 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 mit IOLSession.initIOLSession(Context context, String offerIdentifier) initialisiert wurde.

Parameter:

  • boolean enable
    Mögliche Werte: true|false

Beispiel:

IOLSession.setDebugModeEnabled(true);
kopiert!

3.6.7 Session beenden

terminateSession()

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.

Nur bei Opt-Out durch den Nutzer verwenden!

Parameter:

Beispiel:

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

Session muss anschließend nicht neu initialisiert werden, sondern kann per startSession() jederzeit gestartet werden!

3.6.8 Session starten

startSession()

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

Parameter:

Beispiel:

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

3.6.9 Einbindung Opt-out Funktion

Die Implementierung obliegt dem Entwickler der jeweiligen App und sollte bei Aktivierung durch den Benutzer dazu führen, dass die ÖWA-Library entweder gar nicht initialisiert wird oder die laufende Session explizit beendet wird. Das Vorgehen ist in Kapitel 3.6.7 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 3.6.8 beschrieben.

3.7 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);
kopiert!

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

Bitte deaktivieren Sie den Debug-Modus vor der Veröffentlichung der App.

3.8 Android TV / Nexus Player

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

Soll die IOLib unter Android TV / Nexus Player zum Einsatz kommen, so sind alle Integrationsschritte gemäß Kapitel 3.3 durchzuführen. Die Methoden zur Steuerung der IOLib sind ebenfalls, gemäß Kapitel 3.6, analog zu verwenden.

3.9 Fire OS

Die IOLib 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 unter Fire OS 5 zum Einsatz kommen, so sind alle Integrationsschritte gemäß Kapitel 3.3 durchzuführen. Die Methoden zur Steuerung der IOLib sind ebenfalls, gemäß Kapitel 3.6, analog zu verwenden.

Die Messung von Second Screens in Verbindung mit einer Fire TV App und dem Amazon Fling SDK ist aktuell nicht gewährleistet

3.10 Advertising Identifier in der IOLib

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

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>
kopiert!

4 Vorgaben zum Aufruf der Library

4.1 Allgemeines

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

Die ÖWA-Library muss von der App bei Eintreten des Events explizit aufgerufen werden.

4.1.1 Interpretation von Events als gültige PI

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

PI-Events

Bei den PI-Events wird der Event dazu benutzt, analog zum stationären Web, eine PageImpression zu erzeugen. Diesem Event muss ein Contentpath (in der Folge als „CP“ bezeichnet) zugeordnet werden. Dieser CP kann anschließend den unterschiedlichen Kategorien zugeordent 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.

4.2 Richtlinien zur Vergabe des Contentpath

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

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

– Länge: Ein CP darf maximal 255 Zeichen enthalten

– Anzahl: Es dürfen maximal 15.000 unterschiedliche 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:

http://www.oewa.at/fileadmin/Documents/documents/implementierung/oewaInfo_kategoriensystem_v1_0_1.pdf