In-App Programmatic Advertising: So kaufen DSPs Mobile-App-Inventar ein

Die meisten Media Buyer starten im Open Web. Das Denkmodell, das damit einhergeht – eine Seiten-URL, ein Cookie, ein Referrer, eine Domain, die man auf eine Whitelist setzen kann –, funktioniert dort gut genug. Dann schaltet derselbe Einkäufer Mobile-App-Inventar frei, und die Hälfte dieser Signale verschwindet stillschweigend. Es gibt keine URL. Es gibt kein Third-Party-Cookie. Das Domain-Feld ist leer, und stattdessen kommt eine Bundle-ID an, die wie eine Kette rückwärts geschriebener Wörter aussieht.

Das ist keine kleinere Version des Web-Einkaufs. In-App-Inventar läuft über eine andere Supply Chain, trägt andere Identifier, nutzt Werbeformate, die es im Web nie gab, und wird über eine andere Datei verifiziert. Eine DSP, die eine App-Impression wie eine Web-Impression behandelt, kauft das Falsche, interpretiert ihre eigenen Reports falsch und gibt Geld für Platzierungen aus, die sie nicht sehen kann.

Dieser Leitfaden erklärt, wie In-App-Programmatic-Advertising tatsächlich funktioniert: was ein App-Bid-Request enthält, wie die SDK- und Mediation-Ebene zwischen einem Publisher und Ihrer Plattform sitzt, welche Formate eine DSP unterstützen muss, wie sich Identität und Messung verändert haben, seit die mobilen Plattformen den Datenschutz verschärft haben, und was ein Plattformbetreiber konfigurieren sollte, bevor er App-Traffic in großem Umfang einkauft.

Was ist In-App-Programmatic-Advertising?

In-App-Programmatic-Advertising ist der automatisierte Einkauf von Werbeplatzierungen innerhalb mobiler Anwendungen – Games, News-Apps, Utility-Apps, Streaming-Apps – über Echtzeitauktionen statt über direkte Insertion Orders. Die Mechanik ist dieselbe Auktionsmechanik wie überall sonst im Programmatic-Bereich: Eine Platzierung wird verfügbar, ein Bid-Request beschreibt sie, angebundene Einkäufer antworten mit einem Preis, und das höchste zulässige Gebot gewinnt die Impression.

Was sich ändert, ist die Umgebung. Eine mobile App ist kein Browser. Sie hat keinen gemeinsamen Cookie-Speicher, keine Adressleiste und kein Document Object Model, das eine Anzeige auslesen könnte. Alles, was die Anzeige benötigt – Rendering, Messung, Klick-Handling –, muss durch Code bereitgestellt werden, den der Publisher in die App selbst kompiliert hat. Deshalb ist das Software Development Kit (SDK) das prägende Merkmal dieses Kanals.

Die zugrunde liegende Auktion folgt weiterhin demselben Ablauf, den wir in unserem Leitfaden dazu beschreiben, wie Real-Time Bidding funktioniert. Wenn Sie eine OpenRTB-Auktion im Web verstehen, verstehen Sie bereits neunzig Prozent der In-App-Auktion. Um den restlichen Teil geht es in diesem Beitrag.

Wie sich ein In-App-Bid-Request von einem Web-Request unterscheidet

In OpenRTB beschreibt ein Bid-Request sein Inventar entweder mit einem site-Objekt oder mit einem app-Objekt. Er sollte niemals beide enthalten. Genau diese eine Verzweigung teilt Ihrem Bidder mit, in welcher Welt er einkauft, und fast jeder praktische Unterschied ergibt sich daraus.

Das app-Objekt identifiziert die Anwendung über die Bundle-ID – den Paketnamen unter Android bzw. die numerische App-Store-ID unter iOS – sowie über eine Store-URL, einen App-Namen und einen Publisher-Block. Statt einer Seiten-URL und eines Referrers muss Ihre Targeting- und Blocking-Logik mit dem Bundle arbeiten. Statt eines Cookies wird das Gerät über eine zurücksetzbare Werbe-ID im Device-Objekt identifiziert – sofern der Nutzer dies erlaubt hat.

Zwei Felder verdienen auf der Buy-Side besondere Aufmerksamkeit. Das erste ist device.lmt, das Limit-Ad-Tracking-Flag: Ist es gesetzt, hat der Nutzer personalisierter Werbung widersprochen, und jedes an dieses Gerät geknüpfte Audience-Segment sollte ignoriert und nicht stillschweigend weiterverwendet werden. Das zweite ist app.bundle, denn ein fehlerhaftes oder nicht passendes Bundle ist das häufigste Anzeichen für falsch deklarierten App-Traffic.

Die In-App-Supply-Chain: SDK, Mediation und Exchange

Im Web kann ein Publisher einen Demand-Partner hinzufügen, indem er ein Tag einfügt. In einer App bedeutete das Hinzufügen von Demand lange Zeit, ein weiteres SDK zu integrieren und eine neue App-Version durch das Store-Review zu bringen. Dieser Aufwand hat den gesamten Kanal geprägt und ist der Grund, warum sich eine Zwischenebene – die Mediation – als Standard etabliert hat.

Eine Mediation-Plattform sitzt als ein einziges SDK in der App und verwaltet dahinter alle angebundenen Demand-Quellen. Frühe Mediation-Lösungen arbeiteten mit einem nach Rang sortierten Wasserfall und riefen Netzwerke nacheinander anhand ihres historischen Durchschnittspreises auf. Moderne Setups nutzen stattdessen In-App-Bidding, bei dem alle angebundenen Quellen gleichzeitig auf dieselbe Impression bieten – derselbe strukturelle Wandel, den wir in unserem Vergleich Header Bidding vs. Wasserfall beschreiben.

Aus Sicht Ihrer DSP ist die praktische Folge die Distanz. Zwischen der App und Ihrem Bidder können eine Mediation-Plattform, eine Supply-Side-Platform und ein oder mehrere Reseller liegen, die jeweils einen Anteil einbehalten und unterwegs Signale hinzufügen oder verlieren können. Diese Kette zu verkürzen und zu prüfen, ist der eigentliche Zweck der Supply Path Optimization, und im App-Umfeld ist das wichtiger als im Web, weil die Kette in der Regel länger ist.

Die Supply Chain bestimmt auch, was Sie durchsetzen können. Eine direkte SSP-Anbindung ermöglicht es Ihnen, einen sauberen Feed auf Bundle-Ebene auszuhandeln und jemanden dafür in die Verantwortung zu nehmen. Ein Reseller-Feed aus vierter Hand bietet selten eines von beidem. Unsere Checkliste dazu, wie Sie SSPs an Ihre DSP anbinden, gilt hier uneingeschränkt, mit einer Ergänzung: Fragen Sie gezielt nach, ob es sich bei dem Feed um direkten App-Supply oder um aggregierten Supply handelt.

In-App-Werbeformate, die eine DSP unterstützen muss

App-Inventar ist in einer Weise formatgetrieben, wie es Web-Display nicht ist. Insbesondere Games monetarisieren über Vollbild- und belohnungsbasierte Platzierungen, und eine Plattform, die nur Banner ausliefert, wird vom Großteil des wertvollen Supplys ausgeschlossen, bevor das Bieten überhaupt beginnt.

• Banner. Kleine, feste Platzierungen, die am oberen oder unteren Bildschirmrand verankert sind. Geringe Kosten, hohes Volumen und Rendering über den MRAID-Container statt über einen einfachen iframe.
• Interstitial. Ein Vollbildformat, das an einer natürlichen Unterbrechung angezeigt wird, etwa zwischen zwei Spiellevels oder nach einem Artikel. Höhere Aufmerksamkeit, höherer Preis und strengere Anforderungen an die Creatives.
• Rewarded Video. Der Nutzer entscheidet sich aktiv dafür, ein Video anzusehen, und erhält dafür In-App-Währung oder ein zusätzliches Leben. Die Completion Rates sind hoch, weil der Tausch explizit ist, und das Format wird von Gaming-Supply dominiert.
• Native. Eine Anzeige, die im eigenen Layout und Stil der App dargestellt wird und aus separaten Assets für Titel, Bild und Call-to-Action zusammengesetzt ist statt aus einem festen Creative.
• Playable. Eine kurze interaktive Demo, meist für App-Install-Kampagnen eingesetzt und als in sich geschlossenes interaktives Creative ausgeliefert.

Zwei technische Standards tragen den Großteil davon. MRAID definiert, wie ein Rich-Media-Creative mit dem Host-SDK kommuniziert – wie es sich erweitert, schließt oder einen Click-Through öffnet. VAST definiert, wie ein Video-Creative und seine Tracking-Events beschrieben werden. Eine DSP, die App-Inventar einkauft, benötigt beides sowie die Native-Asset-Struktur – andernfalls wird ein großer Teil der Antworten schlicht als inkompatibel verworfen.

Die Formatunterstützung verändert auch, wie Sie Performance interpretieren. Ein abgeschlossenes Rewarded Video ist nicht mit einem Banner-View vergleichbar, und wer beides zu einem Mischwert zusammenfasst, verschleiert, welches Format tatsächlich funktioniert. Win Rate, CPM und Conversion-Reporting nach Format aufzuschlüsseln, ist die Mindestgranularität für ein sinnvolles Reporting bei App-Kampagnen.

Identität und Messung innerhalb von Apps

Apps haben nie Third-Party-Cookies genutzt. Sie nutzten eine von der Plattform vergebene Werbe-ID: die IDFA unter iOS und die Google Advertising ID unter Android. Beide können vom Nutzer zurückgesetzt werden, und beide gelten gerätebezogen statt browserbezogen, was App-Targeting historisch eher stabiler als Web-Targeting machte – nicht weniger stabil.

Das hat sich mit App Tracking Transparency geändert. Seit iOS 14.5 muss eine App den Nutzer um Erlaubnis fragen, bevor sie für App-übergreifendes Tracking auf die IDFA zugreift, und ohne diese Erlaubnis ist die ID nicht verfügbar. Android hat sich mit einer eigenen Opt-out-Möglichkeit und der Privacy Sandbox in eine ähnliche Richtung bewegt. Das Ergebnis ist ein großes Volumen an App-Traffic, das auf Geräteebene tatsächlich anonym ist.

Die Messung hat sich durch plattformbetriebene Attributions-Frameworks angepasst – Apples SKAdNetwork und dessen Nachfolger AdAttributionKit –, die Install-Conversions aggregiert und verzögert melden, statt einen Klick-zu-Install-Pfad auf Nutzerebene offenzulegen. Für Einkäufer bedeutet das: Performance-Daten zu App-Installs kommen später und gröber an als Web-Conversion-Daten, und das Kampagnen-Pacing muss diese Verzögerung verkraften.

Die praktische Antwort lautet nicht, der fehlenden ID hinterherzujagen. Sie lautet, sich auf die Signale zu stützen, die erhalten bleiben: das Bundle, die Platzierung, das Format, die Geografie, die Tageszeit und Ihre eigenen First-Party-Conversion-Daten. Kontextuelle Optimierung und Optimierung auf Inventarebene leisten im App-Umfeld heute den Großteil der Arbeit – ein Grund, warum es wichtig ist, die Bidding-Logik selbst zu besitzen: Sie können diese Signale selbst gewichten, statt das starre Modell eines Anbieters hinnehmen zu müssen.

App-Supply verifizieren: app-ads.txt und Bundle-Hygiene

App-Inventar hat ein spezifisches Betrugsmuster: die Falschdeklaration von Bundle-IDs. Eine minderwertige oder gar nicht existierende App gibt sich als beliebte App aus, und ein Einkäufer, der diese beliebte App targetiert, zahlt einen Aufpreis für eine Impression, die nie dort stattgefunden hat, wo sie angeblich stattfand. Da der Einkäufer keine URL öffnen und sich die Seite ansehen kann, ist die Täuschung manuell schwerer zu erkennen als im Web.

Die Antwort der Branche ist app-ads.txt. Der Entwickler veröffentlicht eine Datei mit autorisierten Verkäufern auf der Domain, die im Store-Eintrag der App angegeben ist, und jeder Einkäufer kann diese Datei abrufen und bestätigen, dass der Verkäufer, der die Impression anbietet, tatsächlich zum Verkauf berechtigt ist. Die Funktionsweise sowie die sellers.json-Datei, die die Kette in der Gegenrichtung vervollständigt, behandeln wir in unserem Beitrag zu ads.txt, app-ads.txt und sellers.json.

Über die Datei hinaus decken einige Prüfungen den Großteil des Rests ab. Stellen Sie sicher, dass das Bundle im jeweiligen App Store tatsächlich auffindbar ist. Gleichen Sie den deklarierten App-Namen mit dem Bundle ab. Achten Sie darauf, ob ein einzelnes Bundle bei einer unplausibel breiten Streuung nicht zusammenhängender Verkäufer auftaucht. Und behandeln Sie Requests mit fehlendem oder fehlerhaftem Bundle als nicht kaufbar statt als generischen Mobile-Traffic.

Was Sie konfigurieren sollten, bevor Sie App-Traffic in großem Umfang einkaufen

App-Supply freizuschalten ist eine Konfigurationsaufgabe, kein Schalter. Die folgende Liste gibt die Reihenfolge wieder, die erfahrungsgemäß die wenigsten Überraschungen verursacht.

1. Trennen Sie App- und Web-Kampagnen. Unterschiedliche Formate, unterschiedliche Identifier, unterschiedliche Benchmarks. Wer sie vermischt, macht beide unlesbar.
2. Aktivieren Sie die Formate, die Sie tatsächlich ausliefern können. Prüfen Sie die Unterstützung von MRAID, VAST und Native-Assets durchgängig, bevor Sie auf diese Platzierungen bieten – nicht danach.
3. Aktivieren Sie die app-ads.txt-Verifizierung. Machen Sie sie zur Bedingung für das Bieten, nicht zu einem Report nach Kampagnenende.
4. Starten Sie mit einer Bundle-Allowlist. Kaufen Sie zunächst eine bekannte Auswahl an Apps ein, lernen Sie, was performt, und erweitern Sie dann. Offenes Targeting über den gesamten App-Supply ist der teuerste Weg, eine Blocklist zu erarbeiten.
5. Setzen Sie Frequency Caps pro Gerät, nicht pro Cookie. Die Frequenzlogik in Apps basiert auf der Werbe-ID und muss sauber funktionieren, auch wenn diese ID fehlt.
6. Geben Sie Install-Kampagnen ein längeres Messfenster. Aggregierte Attribution meldet verspätet; wer einen ersten Kampagnentag anhand von Daten desselben Tages bewertet, zieht falsche Schlüsse.
7. Reporten Sie nach Bundle und nach Supply Path. Das Bundle zeigt Ihnen, was Sie gekauft haben; der Pfad zeigt Ihnen, was Sie dafür bezahlt haben.

Jeder Punkt auf dieser Liste ist einfacher, wenn die Plattform Ihnen gehört. Bei einem gemieteten Seat sind Formatunterstützung, Verifizierungsregeln und Bidding-Logik das, was der Anbieter freizugeben beschlossen hat. Auf einer eigenen Plattform sind es Einstellungen, die Sie selbst steuern – und gerade beim App-Einkauf entscheiden diese Stellschrauben darüber, ob sich das Budget auszahlt.

Bereit, App-Inventar über Ihre eigene DSP einzukaufen?

AdTech Europe liefert die Demand-Side-Platform-Technologie für Agenturen, Werbenetzwerke und Media-Buying-Teams, die ihre Infrastruktur lieber selbst besitzen, als Zugang zur Infrastruktur anderer zu mieten. Jeder Plan umfasst unbegrenzte QPS-Skalierung, White-Label-Branding und Zugang zu über 1.000 SSP-Integrationen für Web, App und neue Kanäle – App-Supply ist also fester Bestandteil der Plattform und kein Zusatz, den Sie separat verhandeln müssen.

Stand September 2026 kostet die White Label DSP $500 pro Monat ohne Einrichtungsgebühr bei monatlicher Kündbarkeit und wird innerhalb von 24 Stunden bereitgestellt. Eine DSP License kostet einmalig $25,000, eine DSP Acquisition mit vollständigem Eigentum am Quellcode einmalig $50,000 – beide sind in fünf Monatsraten zahlbar und werden innerhalb von fünf bis sieben Werktagen bereitgestellt. Aktuelle Details finden Sie jederzeit auf der Preisseite.

Wenn Sie planen, App-Inventar in Ihren Einkaufsmix aufzunehmen, und Formate, Supply-Verifizierung und Bidder-Konfiguration anhand Ihrer eigenen Kampagnen durchgehen möchten, können Sie ein Programmatic-Strategiegespräch vereinbaren – mit unserem Team.

FAQs

Was ist In-App-Programmatic-Advertising?

In-App-Programmatic-Advertising ist der automatisierte Einkauf von Werbeplatzierungen innerhalb mobiler Anwendungen über Echtzeitauktionen. Die Auktionsmechanik entspricht dem übrigen Programmatic-Bereich, doch das Inventar wird über eine App-Bundle-ID statt über eine Seiten-URL beschrieben, und die Anzeige wird von einem SDK innerhalb der App statt von einem Browser gerendert.

Wie unterscheidet sich ein In-App-Bid-Request von einem Web-Bid-Request?

Ein In-App-Request enthält ein OpenRTB-app-Objekt statt eines site-Objekts. Das bedeutet eine Bundle-ID und eine Store-URL anstelle von Domain und Seiten-URL, eine Werbe-ID des Geräts anstelle eines Cookies sowie Formatsignale für Interstitial-, Rewarded- oder Playable-Formate, die im Open Web nicht verwendet werden.

Was ist app-ads.txt und warum ist es für den App-Einkauf wichtig?

App-ads.txt ist eine Datei auf der Website des App-Entwicklers, in der die Verkäufer aufgeführt sind, die zum Verkauf des Inventars dieser App berechtigt sind. Einkäufer nutzen sie, um zu bestätigen, dass der Anbieter einer App-Impression tatsächlich zum Verkauf berechtigt ist – das ist der wichtigste Schutz gegen die Falschdeklaration von Bundle-IDs.

Kann man nach App Tracking Transparency in Apps noch Zielgruppen targetieren?

Audience-Targeting auf Geräteebene funktioniert nur, wenn der Nutzer seine Erlaubnis erteilt hat und die Werbe-ID im Request enthalten ist. Für den übrigen App-Traffic stützt sich das Targeting auf kontextuelle Signale und Signale auf Inventarebene wie Bundle, Platzierung, Format, Geografie und Tageszeit sowie auf Ihre eigenen First-Party-Conversion-Daten.

Warum benötigt eine DSP für App-Inventar MRAID- und VAST-Unterstützung?

MRAID definiert, wie ein Rich-Media-Creative mit dem SDK des Publishers interagiert, und VAST definiert, wie Video-Creatives und ihre Tracking-Events beschrieben werden. Ohne beides wird ein großer Teil der App-Platzierungen Ihr Creative ablehnen oder verwerfen, sodass diese Bid-Responses nie zu ausgelieferten Impressions werden.

Was ist Mediation in der Mobile-App-Werbung?

Mediation ist eine Ebene innerhalb der App, die mehrere Demand-Quellen über ein einziges SDK verwaltet und dem Publisher erspart, jeden Partner einzeln zu integrieren. Ältere Mediation-Lösungen arbeiteten mit einem nach Rang sortierten Wasserfall; modernes In-App-Bidding lässt alle angebundenen Quellen gleichzeitig auf dieselbe Impression bieten.

Brauchen Sie eine eigene DSP, um In-App-Inventar einzukaufen?

Nein, aber Eigentum verändert, was Sie steuern können. Auf einer eigenen Plattform legen Sie Formatunterstützung, Regeln zur Supply-Verifizierung, Bundle-Allowlists und Bidding-Logik selbst fest, statt mit der Konfiguration zu arbeiten, die ein gemieteter Seat freigibt.