Attributionsberichte: App- und webübergreifende Messungen

Letzte Updates

Wie im Designvorschlag für die Attribution Reporting API beschrieben, ermöglicht die API die Attribution der folgenden Triggerpfade auf einem einzelnen Android-Gerät:

  • App-to-app::Der Nutzer sieht sich eine Anzeige in einer App an und führt dann entweder in dieser App oder in einer anderen installierten App eine Conversion aus.
  • App-to-web::Der Nutzer sieht eine Anzeige in einer App und führt dann in einem mobilen Browser oder einem In-App-Browser eine Conversion aus.
  • Web-to-app::Der Nutzer sieht eine Anzeige in einem mobilen Browser oder einem In-App-Browser und führt dann in einer App eine Conversion aus.
  • Web-to-web::Der Nutzer sieht eine Anzeige in einem mobilen Browser oder einem App-Browser und führt dann entweder im selben Browser oder in einem anderen Browser auf demselben Gerät eine Conversion aus.

Als Webinhalte werden hier Webinhalte definiert, die in einer App angezeigt werden. Webinhalte können im Kontext einer mobilen Browser-App oder als eingebettete Websites in Apps angezeigt werden, die keine Browser sind.

Die vorherigen Triggerpfade entsprechen den folgenden Anforderungen:

  • Für Anbieter von Anzeigentechnologien: Aktualisierungen von API-Aufrufen und Berichten, um App-zu-Web-Pfade zu aktivieren
  • Für Apps und Browser: Möglichkeit, die Registrierung von Web-Attributionsquellen und Webtriggern an Android weiterzuleiten

In diesem Dokument wird erläutert, wie die Attribution Reporting API um Triggerpfade vom Typ „App-zu-Web“, „Web-zu-App“ und „Web-zu-Web“ erweitert wird. Außerdem werden die Änderungen beschrieben, die Werbetechnologien und Apps vornehmen müssen, um die Anforderungen für die Unterstützung dieser Triggerpfade zu erfüllen.

Zugriff auf Attribution Reporting APIs erhalten

Anzeigentechnologie-Plattformen müssen sich registrieren, um auf die Attribution Reporting APIs zugreifen zu können. Weitere Informationen finden Sie unter Privacy Sandbox-Konto registrieren.

Sobald die Registrierung abgeschlossen ist, verwirft die API die Registrierung, wenn ein Registrierungsanruf für ein nicht registriertes Gerät empfangen wird.

Bei der Registrierung sollten Anbieter von Anzeigentechnologien darauf achten, alle Server-URLs anzugeben, die sie in Apps und im Web verwenden könnten, um Attributionsquellen und ‑trigger zu registrieren. Es werden mehrere Serverregistrierungs-URLs unterstützt, aber nur eine Berichtsquelle. Dieser Berichtsorigin wird aus der Domain einer der URLs der Serverregistrierung abgeleitet.

Änderungen für Anzeigentechnologien

In diesem Abschnitt werden die Änderungen für AdTechs beschrieben, die die Attribution Reporting API verwenden.

Änderungen bei Registrierung und Attribution

Beim Registrieren einer Attributionsquelle geben Anbieter von Anzeigentechnologien ein Zielfeld an, das der Name des App-Pakets ist, in dem das Triggerereignis auftritt. Um Messungen von App zu Web zu ermöglichen, planen wir die Unterstützung eines App-Zielfelds (App-Paketname) und eines Web-Zielfelds (eTLD+1).

Beim Registrieren von Web-Attributionsquellen oder ‑triggern unterstützt die API keine Weiterleitungen, da jede App, die Webinhalte hostet, ein eigenes Berechtigungsmodell haben kann. Jede App ist dafür verantwortlich, Weiterleitungen zu folgen (sofern unterstützt) und die Webkontext-APIs für jeden Weiterleitungs-Hop aufzurufen.

Darüber hinaus können Anbieter von Anzeigentechnologien mit dieser Integration appspezifische Attributionslogik auf Web-Attributionsquellen anwenden. So können Sie beispielsweise jetzt Attributionsfenster nach der Installation für eine Web-Attributionsquelle angeben.

App- und Webberichte erhalten

Mit der Attribution Reporting API für Android können Berichte sowohl für App- als auch für Web-Conversions gesendet werden. Wenn Werbetreibende Triggerdaten und Schlüsselwerte für die Aggregation nicht für Web- und App-Oberflächen abgleichen möchten, können sie zwischen einer Web- und einer App-Conversion unterscheiden:

  • Für Berichte auf Ereignisebene wird ein Zielfeld unterstützt, das angibt, ob der Trigger im Web (Ziel ist eine eTLD+1) oder in einer App (Ziel ist ein App-Paketname) ausgelöst wurde.
  • Bei aggregierbaren Berichten wird das Ziel in Klartext gesendet.

Auswirkungen der Web-zu-Web-Analyse

Apps können festlegen, wann die Registrierung an die Attribution Reporting API übergeben wird. Dabei sind einige Aspekte zu beachten:

  • Ist die Attribution Reporting API auf diesem Gerät verfügbar? Wir stellen Apps ein neues Signal zur Verfügung, das angibt, ob die Attribution Reporting API auf diesem Gerät verfügbar ist. Weitere Informationen dazu, wie Apps die Registrierung an die Attribution Reporting API weitergeben können, finden Sie im Abschnitt zu App-Änderungen.
  • Welcher Teil der Attributionsquellen und ‑trigger sollte an die API übergeben werden? Diese Entscheidung wird von der jeweiligen App oder der AdTech-Lösung getroffen, sofern die App eine Auswahl zulässt. Wenn die App eine eigene Analyselösung hat, kann diese stattdessen verwendet werden. Wenn Sie alle Quellen- und Triggerregistrierungen an die Android Attribution Reporting API übergeben, können Sie die genaueste Attribution für Apps und das Web erzielen.

Das folgende Beispiel zeigt, wie Browser-Apps mit der Attribution Reporting API zusammenarbeiten können, um genaue Messungen zu ermöglichen, wenn der Nutzer sowohl in einer Browser-App als auch in einer App ohne Browser auf eine Anzeige klickt:

Beispiele für Nutzerklicks und Conversions über einen Zeitraum von drei Tagen
Beispiel für die Registrierung von Quelle und Trigger in einem Browser und einer App
  • Am ersten Tag klickt der Nutzer in der Browser-App auf eine Anzeige.
    • Die Browser-App kann ihre eigene Analyselösung verwenden oder die Registrierung des Webanzeigenklicks an die Attribution Reporting API weitergeben.
  • Am Tag 2 klickt der Nutzer auf eine Anzeige in einer App, die nicht in einem Browser ausgeführt wird.
    • Der Klick wird in der API als Attributionsquelle registriert. Die Browser-App kann diesen Klick nicht sehen, da das Ereignis in einer anderen App stattgefunden hat.
  • Am dritten Tag führt der Nutzer eine Conversion in der Browser-App durch.
    • Wenn die Browser-App sowohl den Klick als auch die Conversion mit ihrer eigenen Analyselösung erfasst und diese Informationen an die Attribution Reporting API weitergibt, ist es unwahrscheinlich, dass eine Anzeigentechnologie Conversion-Berichte über Analyselösungen hinweg deduplizieren kann. Außerdem kann ein AdTech sowohl die Ratenbegrenzungen für Browser-Apps als auch die Ratenbegrenzungen für die Attribution Reporting API verbrauchen. Wir empfehlen daher, dass Apps alle Anzeigenereignisse und Conversions übergeben, die in der API registriert werden sollen, wenn die API verfügbar ist.

Attributionsquelle und Trigger über WebView registrieren

Wenn die App Webinhalte über WebView und nicht über eine Android-Anzeige anzeigt, kann sie für die Zulassungsliste für registerWebSource() beantragen und den Top-Level-Ursprung der Website angeben, der der Attributionsquelle und nicht dem Namen des App-Pakets zugeordnet werden soll.

Ähnlich wie Browser unterstützt WebView registerWebTrigger() für Triggerregistrierungen, wodurch der Trigger mit dem Ursprung der obersten Ebene verknüpft wird. WebView unterstützt nicht die Registrierung eines App-Triggers. Wenden Sie sich an uns, wenn Sie einen Anwendungsfall dafür haben. Eine vollständige Liste der von WebView unterstützten Kombinationen finden Sie unter Registrierung von Attributionsquelle und Trigger über WebView.

Im Gegensatz zu Browsern unterstützt WebView die Registrierung beim Betriebssystem nur im Attribution-Reporting-Eligible-Header, wenn die Attribution Reporting API von Android verfügbar ist. Wenn die Attribution Reporting API von Android nicht verfügbar ist, setzt WebView keinen Attribution-Reporting-Eligible-Header und es werden keine Registrierungen vorgenommen.

So registrieren Sie eine Attributionsquelle / einen Attributionstrigger über das Betriebssystem:

  • Anbieter von Anzeigentechnologien sollten auf Quellenregistrierungen mit dem Attribution-Reporting-Register-OS-Source-Header antworten. Dadurch wird ein sekundärer API-Aufruf von der WebView an registerSource() oder registerWebSource() initiiert.
  • Anbieter von Anzeigentechnologien können auch mit dem Attribution-Reporting-Register-OS-Trigger-Header auf Triggerregistrierungen reagieren, wodurch ein sekundärer API-Aufruf von der WebView an registerWebTrigger() oder registerTrigger() initiiert wird.

Wenn die Antwort die vorherigen Header nicht enthält oder auch die Attribution-Reporting-Register-Source-/Attribution-Reporting-Register-Trigger-Header enthält, obwohl das Web nicht unterstützt wird, schlägt die gesamte Registrierung fehl.

Weitere Informationen dazu, ob registerSource() / registerWebSource() und registerTrigger() / registerWebTrigger() in WebView verwendet werden und wie sich dieses Verhalten ändern lässt, finden Sie unter Registrierung von Attributionsquellen und Triggern über WebView.

Berichte zur Übergangsphase

Die Attribution Reporting API unterstützt eine optionale Funktion namens Übergangsberichte zur Fehlerbehebung. Damit können Werbetreibende mehr Informationen zu Attributionsberichten erhalten, wenn eine Anzeigen-ID verfügbar ist. Es gibt zwei Arten von Berichten zur Fehlerbehebung: attribution-success und verbose. Diese Berichte werden für die App- und Web-Attribution unterstützt. Beide Berichtstypen enthalten dieselben Informationen. Der einzige Unterschied besteht in den Berechtigungen, die beim Senden von Berichten zur Fehlerbehebung erforderlich sind.

Bei der Web-zu-Web-Attribution innerhalb einer einzelnen App (z. B. innerhalb derselben Browser-App) sind Berichte zum Attributionserfolg und ausführliche Berichte nur verfügbar, wenn Drittanbieter-Cookies verfügbar sind. Sie basieren nicht auf der Verfügbarkeit der Anzeigen-ID.

Für die App-zu-Web-, Web-zu-App- und Web-zu-Web-App-übergreifende Attribution sind Berichte zum Attributionserfolg und ausführliche Berichte verfügbar, wenn die Anzeigen-ID auf App-Seite verfügbar ist und die Anzeigentechnologie dieselbe (richtige) Anzeigen-ID auf Web-Seite übergeben kann.

In einem späteren Beispiel für App-zu-Web-Kampagnen befindet sich die Quelle in einer Publisher-App, der Trigger jedoch auf der Website eines Werbetreibenden in einer Browser-App.

Damit ein Bericht zur Fehlerbehebung bei der Attribution für App-zu-Web-Conversions aktiviert werden kann, müssen die folgenden Bedingungen erfüllt sein:

  • Der Nutzer darf die Personalisierung nicht über die Werbe-ID deaktiviert haben.
  • Die Publisher-App muss AdID-Berechtigungen deklariert haben
  • Die Anzeigentechnologie muss den AdID-Wert bei der Triggerregistrierung (aus einem Webkontext) übergeben.

So aktivieren Sie ausführliche Debugging-Berichte für App-zu-Web-Aufrufe:

  • Detaillierte Quellberichte hängen nur von den Berechtigungen auf Publisher-Seite ab. Damit ausführliche Berichte zur Quelle gesendet werden können, darf der Nutzer die Personalisierung von Anzeigen-IDs nicht deaktiviert haben und die Publisher-App muss Berechtigungen für Anzeigen-IDs deklariert haben.
  • Detailberichte zu Triggern hängen nur von den Berechtigungen der Triggerseite (in diesem Beispiel „Web“) ab. Drittanbieter-Cookies müssen im Browser verfügbar sein, damit ausführliche Berichte gesendet werden können.
  • In ausführlichen Berichten zu Triggern, die optional eine source_debug_key enthalten können, wird die source_debug_key eingefügt, wenn die Anzeigen-ID für die Publisher-App verfügbar ist.

Hinweis: In allen Fällen muss die Anzeigentechnologie weiterhin aktiviert werden, um ausführliche Debugging-Berichte über das Dictionary-Feld debug_reporting in den Headern für die Registrierung von Quellen und Triggern zu erhalten.

Änderungen für Apps

Wir unterstützen die Attribution auf App- und Weboberflächen. Dazu können Apps die Registrierung von Web-Attributionsquellen und -triggern über eine neue Reihe von Web-Kontext-API-Aufrufen an die Attribution Reporting API auf Android übergeben.

Nachdem Sie die Registrierungsschritte in den folgenden Abschnitten ausgeführt haben, werden App- und Web-Attributionsquellen und -trigger auf dem Gerät gespeichert. Die Attribution Reporting API kann dann eine nach Quelle priorisierte Attribution nach dem letzten Touch auf App- und Weboberflächen vornehmen.

Im Privacy Sandbox-Vorschlag für das Web finden Sie ein Beispiel dafür, wie Browser in die Attribution Reporting API von Android eingebunden werden können, um App- und Web-übergreifende Analysen zu ermöglichen. Im Vorschlag fügt der Browser die folgenden Anfrageheader hinzu:

  • Attribution-Reporting-Eligible sendet, ob die Attribution auf Betriebssystemebene unterstützt wird. In diesem Fall gibt der Header an, ob die Attribution Reporting API von Android verfügbar ist.
  • Falls verfügbar, können Anzeigentechnologien optional mit Attribution-Reporting-Register-OS-Source antworten. Dadurch wird ein sekundärer API-Aufruf von der Browser-App an registerWebSource() initiiert.
  • Anbieter von Anzeigentechnologien können auch über den Attribution-Reporting-Register-OS-Trigger-Header auf Triggerregistrierungen reagieren, wodurch ein sekundärer API-Aufruf von der Browser-App an registerWebTrigger() initiiert wird.

Attributionsquelle registrieren

Bei der Registrierung einer Attributionsquelle können Apps registerWebSource() aufrufen. Dabei werden die folgenden Parameter erwartet:

  • URIs der Attributionsquelle: Die Plattform sendet eine Anfrage an jeden URI in dieser Liste, um Metadaten abzurufen, die mit der Attributionsquelle verknüpft sind.

    Jeder URI muss mit einem booleschen Debug-Flag versehen sein, um anzugeben, ob die von den Technikern bereitgestellten Debug-Schlüssel in den Bericht aufgenommen werden sollen.
  • Eingabeereignis: Entweder ein InputEvent-Objekt (für ein Klickereignis) oder null (für ein Aufrufereignis)
  • Herkunft der Quelle: Ursprung, auf dem die Quelle aufgerufen wurde (Website des Publishers).
  • OS-Ziel: Der Name eines App-Pakets, bei dem das Triggerereignis auftritt.
  • Webziel: Eine eTLD+1, unter der das Triggerereignis auftritt.
  • Überprüftes Ziel: Betriebssystem- oder Web-Ziel-URI-Intent, der für die Navigation nach Nutzerklick verwendet wird.

Wenn die API eine Anfrage an den URI der Attributionsquelle sendet, sollte die Anzeigentechnologie mit den Metadaten der Attributionsquelle in einem HTTP-Header, Attribution-Reporting-Register-Source, antworten. Dieser Header verwendet dieselben Felder wie die Registrierung von App-zu-App-Attributionsquellen, mit einigen Änderungen:

  • Die API prüft die von der Anzeigentechnologie angegebenen Ziele mit den von der App angegebenen Zielen. Wenn sich die Ziele unterscheiden, verwirft die API die Registrierung der Attributionsquelle.

    Apps müssen Webziele validieren, bevor die Webkontext-API aufgerufen wird. Bei Klicks sollten Apps prüfen, ob das angegebene Ziel mit dem Ziel übereinstimmt, zu dem der Nutzer weitergeleitet wird.
  • Die API ignoriert alle Weiterleitungs-URIs, die in Attribution-Reporting-Redirects angegeben sind. Apps sollten Weiterleitungen selbst folgen und für jede Weiterleitung registerWebSource() aufrufen, damit sie nach Bedarf ihre eigenen Berechtigungsrichtlinien anwenden können.

Apps müssen auf einer Zulassungsliste stehen, um registerWebSource() anrufen zu können. Füllen Sie dieses Formular aus, um auf die Zulassungsliste gesetzt zu werden. Mit der Zulassungsliste sollen Datenschutzaspekte beim Aufbau von Vertrauen für den Webkontext minimiert werden.

Registrierung (Conversion) auslösen

Bei der Triggerregistrierung können Apps registerWebTrigger() aufrufen. Für diesen Aufruf sind die folgenden Parameter erforderlich:

  • Trigger-URIs: Die Plattform sendet eine Anfrage an jeden URI in dieser Liste, um die mit dem Trigger verknüpften Metadaten abzurufen.
  • Ziel-Ursprung: Ursprung, an dem der Trigger ausgelöst wurde (Website des Werbetreibenden)

Attribution source and trigger registration from WebView

Standardmäßig verwendet WebView registerSource() und registerWebTrigger(). Dadurch werden Quellen mit der App und Trigger mit dem Ursprung der WebView auf oberster Ebene verknüpft, wenn der Trigger ausgelöst wird.

Wenn für eine App ein anderes Verhalten erforderlich ist (z. B. für Apps, die Webinhalte in einer WebView hosten), muss die setAttributionRegistrationBehavior-Methode der androidx.webkit.WebViewSettingsCompat-Klasse verwendet werden. Mit dieser Methode wird angegeben, ob WebView registerWebSource() oder registerSource() und registerWebTrigger() oder registerTrigger() aufrufen soll.

Folgende Optionen sind für setAttributionRegistrationBehavior verfügbar:

Wert Beschreibung Anwendungsbeispiel
APP_SOURCE_AND_WEB_TRIGGER (Standard) Ermöglicht es Apps, App-Quellen (mit dem App-Paketnamen verknüpfte Quellen) und Webtrigger (mit der eTLD+1 verknüpfte Trigger) über WebView zu registrieren. Apps, die WebView zum Ausliefern von Anzeigen statt zum Websurfen verwenden
WEB_SOURCE_AND_WEB_TRIGGER Ermöglicht es Apps, Webquellen und Webtrigger über WebView zu registrieren.
Hinweis: Apps, die diese Option verwenden, müssen sich für die Zulassungsliste bewerben, um registerWebSource() verwenden zu können.		 WebView-basierte Browser-Apps, bei denen Anzeigenimpressionen und Conversions sowohl auf Websites in WebView als auch in der App selbst erfolgen können.
APP_SOURCE_AND_APP_TRIGGER Ermöglicht Apps, App-Quellen und App-Trigger über WebView zu registrieren. WebView-basierte Apps, bei denen Anzeigenimpressionen und Conversions immer der App und nicht der eTLD+1 der WebView zugeordnet werden sollten.
DEAKTIVIERT Deaktiviert die Registrierung von Quellen und Triggern über WebView.
 Der anfängliche Netzwerkaufruf an die Attributionsquelle oder die Trigger-URIs kann weiterhin erfolgen, aber alle Antworten werden verworfen und es wird nichts auf dem Gerät gespeichert.

Datenschutz- und Sicherheitsaspekte

In diesem Abschnitt werden Datenschutz- und Sicherheitsaspekte für Apps erläutert, die die Attribution Reporting API verwenden.

Auswirkungen auf datenschutzfreundliche Mechanismen, die auf Berichte angewendet werden

Wie im Hauptdesignvorschlag beschrieben, wendet die API datenschutzfreundliche Ratenlimits auf Berichte an. Einige Limits werden auf Quell- und Ziel-Apps aufgeteilt. Wenn eine Web-Attributionsquelle oder ein Web-Trigger registriert wird, wird das Ratenlimit nach der Quell- oder Zielwebsite und nicht nach der App aufgeteilt.

Wenn die App separate Ratenlimits hat, kann ein Angreifer zusätzlich zu den API-Ratenlimits auch appspezifische Ratenlimits verbrauchen. Um dies zu vermeiden, sollten Entwickler dafür sorgen, dass eine bestimmte Attributionsquelle nicht sowohl in der Analyselösung der App als auch in der Android Attribution Reporting API registriert ist.

Vertrauen für Webkontext aufbauen

Bei API-Aufrufen im Webkontext vertraut die API der App, dass sie die Quell- und Zieladressen erkennt und angibt. Dies kann zu potenziellen Datenschutz- und Sicherheitsproblemen führen:

  • Ein Angreifer kann behaupten, Websites zu hosten, die ihm gehören, um Geschwindigkeitsbeschränkungen für die Menge an Informationen zu umgehen, die eine Quelle übertragen kann.
  • Mehrere Angreifer können sich zusammenschließen, um separate Attributionsquellen zu registrieren und die gleiche Quellwebsite zu beanspruchen. Dies kann dazu führen, dass die Quellwebsite die Preislimits der Anzeigentechnologieplattform erreicht und die tatsächliche Quellwebsite keine legitimen Attributionsquellen registrieren kann.

Um dies zu vermeiden, beschränken wir die Aufrufe von registerWebSource() auf Browser oder Apps, die bestätigen, dass die bei der Registrierung verwendete Quellwebsite der tatsächlichen Website entspricht, die dem Nutzer angezeigt wird. Füllen Sie das Anmeldeformular für Web-zu-App-Attributionsberichte aus, um auf die Zulassungsliste für registerWebSource() gesetzt zu werden.

Jede App kann registerWebTrigger() aufrufen, da die Datenschutz- und Sicherheitsaspekte auf der Triggerseite ohne Kollusion auf Quellseite nicht gelten.

Nutzersteuerung

Apps können weiterhin Nutzereinstellungen oder Berechtigungsrichtlinien unterstützen, sofern sie bei der Registrierung definiert werden können. Wenn Apps beispielsweise Berechtigungen auf Website- oder Nutzerebene zulassen, sollte die App diese prüfen und entscheiden, ob die Webkontext-APIs aufgerufen werden sollen.

Außerdem unterstützen wir einen neuen API-Aufruf von Apps, um alle Attributionsquellen, Trigger und ausstehenden Berichte zu löschen, die für diese App auf dem Gerät gespeichert sind. Wenn Nutzer beispielsweise in Apps ihren Browserverlauf löschen können, können sie die API aufrufen, um Attributionsquellen, Trigger und ausstehende Berichte zu löschen, die für diese App auf dem Gerät des Nutzers gespeichert sind.

Zukünftige Überlegungen und offene Fragen

Die Interoperabilität zwischen Apps und Web für die Attribution Reporting API ist noch in Arbeit. Wir möchten von der Community Feedback zu einigen Ideen einholen:

  1. Wie verwenden Sie auf einem Gerät mit Privacy Sandbox-Unterstützung Browser-Messlösungen mit der Android Attribution Reporting API? Möchten Sie lieber alles an Android weitergeben?
  2. Gibt es Bedenken, dass für jede Attributionsquelle und jeden Trigger möglicherweise zwei Pings gesendet werden, einer vom Browser oder der App und einer von der Attribution Reporting API?
  3. Wie können wir das Debuggen in verschiedenen APIs für Sie einfacher machen?
  4. Der Vorschlag enthält keine Bestätigung, dass App- und Webziele miteinander verknüpft sind. In Zukunft können wir diese Ziele möglicherweise validieren, indem wir Verknüpfungen mithilfe von Digital Asset Links prüfen. Würde das einen Ihrer Anwendungsfälle beeinträchtigen? Ist es sinnvoll, Digital Asset Links für diese Überprüfung zu verwenden?
  5. Wenn Sie eine Attributionsquelle registrieren, müssen Sie ein Ziel angeben. Im Fall von Web-zu-App-Conversions können Sie einen App-Link angeben. Welche Formate verwenden Sie, um diesen App-Link anzugeben?
  6. Wenn Sie eine App-zu-Web-Attributionsquelle registrieren, muss dieses Quellereignis über die Android Attribution Reporting API in der App registriert werden. Wenn ein Nutzer beispielsweise auf eine Anzeige klickt und die Anzeige in einem Browser oder auf dem benutzerdefinierten Tab eines Browsers geöffnet wird, sollte dieser Klick (Querereignis) von der App und nicht im Browserkontext erfasst werden. Wenden Sie sich an uns, wenn Sie Bedenken haben oder es andere Anwendungsfälle gibt, die nicht in die Kategorien fallen, die in diesem Artikel zu unterstützten Abläufen beschrieben werden.