Werbe-Attribution nach iOS: Was noch messbar ist

Ein ehrlicher Measurement-Stack nach iOS: consented First-Party-Daten, Plattform-Modeling, Server-Events, Store-Orders und Incrementality.

Rene Dallmann·Gründer von nod. und Mesper·Aktualisiert 2026-09-22

Werbe-Attribution nach iOS funktioniert nicht mit einem magischen Tracking-Fix. Sie braucht mehrere sauber getrennte Evidence-Klassen: consented First-Party-Events, serverseitige Conversion-Records, Platform Claims und kontrollierte Tests. Beobachtete Journeys bleiben wertvoll. Lücken müssen sichtbar bleiben, statt mit erfundenem Determinismus gefüllt zu werden.

Was sich durch ATT verändert hat

Apple verlangt seit iOS 14.5 eine Erlaubnis, bevor Apps Aktivitäten über Apps und Websites anderer Unternehmen für Advertising oder Measurement tracken. Die Apple-Dokumentation zu App Tracking Transparency beschreibt genau diese Grenze.

Das betrifft vor allem plattformübergreifende Identität. Es bedeutet nicht, dass ein Shop keine eigenen consented Events oder Orders mehr messen darf. Es bedeutet auch nicht, dass Server-Side Tracking jede verlorene Identität zurückholt.

Die vier Evidence-Klassen

Klasse	Beispiel	So solltest du sie behandeln
Observed	consented Ad-Klick, Landing, Checkout, Order-Join	Für Journey-Attribution nutzbar
Verified	vertraglich belastbarer Exposure- oder Conversion-Join	Nur mit klarer Quelle und Join-Regel
Modeled	Plattform-Modellierung oder probabilistische Schätzung	Separat labeln, nicht als beobachtet ausgeben
Aggregate	Spend, Impressions, Search Demand	Für Trends, nicht für User-Journeys

Die Kategorien dürfen im Dashboard nebeneinanderstehen. Sie dürfen nicht still zu einer angeblich vollständigen Journey verschmolzen werden.

Der belastbare Measurement-Stack

CMP und Consent korrekt implementieren. Tracking startet erst nach der passenden Entscheidung.
First-Party-Events auf der eigenen Domain erfassen. Landing, aktive Interaktion und Conversion-Meilensteine bekommen stabile Event-IDs.
Click IDs und UTMs erhalten. Redirects, Link-Shortener und Checkout dürfen sie nicht verlieren.
Browser- und Server-Events deduplizieren. Eine Order bleibt eine Order.
Orders aus Shopify oder dem CRM übernehmen. Das Backend besitzt den Commercial Record.
Unattributed sichtbar lassen. Coverage ist eine Qualitätsmetrik, kein Fehler, der durch Umverteilung verschwinden muss.
Große Budgetfragen testen. Geo-Holdouts oder andere Incrementality-Designs prüfen Kausalität.

Shopify stellt über seine Customer Privacy API den Consent-Status für Pixels, Audiences und Checkout bereit. Diese Signale gehören in die technische Grundlage, nicht nur ins Banner-Design.

Was Server-Side Tracking kann

Events zuverlässiger zustellen.
Orders und Refunds direkt aus dem Backend übernehmen.
Browser- und Server-Events über IDs deduplizieren.
Plattformen bessere First-Party-Signale für ihre Optimierung geben.

Was Server-Side Tracking nicht kann

fehlenden Consent ersetzen;
eine nicht beobachtete Journey rekonstruieren;
View-Through-Kausalität beweisen;
Plattformen zu einem gemeinsamen Attribution-Modell zwingen;
schlechte Campaign-Naming- und UTM-Disziplin reparieren.

Die KPIs nach iOS

Steuere nicht alles über eine einzige Plattformzahl. Nutze:

MER für den blended Business-Read;
observed ROAS oder aMER für kanalübergreifende Journeys;
Platform ROAS für Bidding und Delivery innerhalb der Plattform;
CM3 für Profit;
Coverage und Unattributed Share für die Messqualität;
Incrementality für strategische Budgetverschiebungen.

Wo nod. sitzt

nod. trennt beobachtete First-Party-Evidence, verifizierte Provider-Evidence, Platform Claims und Search Demand. Fehlt ein belastbarer View-Feed, bleibt die Journey clicks-only, statt Views zu erfinden. Der technische Ablauf steht in How nod. attribution works, der Produkt-Read auf nod. Performance.