QR-Code-Tracking ohne Cookies: First-Party-Daten für Agenturen

Jede Agentur, die die Ergebnisse einer QR-Kampagne präsentiert, muss sich früher oder später einer unbequemen Frage stellen: Wie viel von dieser Zuordnung können Sie tatsächlich verantworten? Über Jahre lautete die ehrliche Antwort „weniger, als das Dashboard suggeriert", weil die meiste digitale Attribution nach wie vor auf Third-Party-Cookies und Pixel von Werbenetzwerken beruht, und beide verlieren zunehmend an Wirkung. Ein QR-Scan hat dieses Problem nicht, nicht weil ScanKit besonders clever mit Datenschutz umgeht, sondern wegen dessen, was ein Scan strukturell ist: ein First-Party-Ereignis, das auf Ihrem eigenen Server protokolliert wird, ohne dass von vornherein irgendetwas seitenübergreifend abgeglichen werden müsste.

Das ist kein Workaround für eine vorübergehende Unannehmlichkeit. Es ist ein struktureller Vorteil, der jedes Jahr wertvoller wird, in dem der Rest des Tracking-Stacks unzuverlässiger wird. Im Folgenden: was tatsächlich mit Cookie- und Pixel-basierter Attribution passiert, warum ein QR-Scan von diesem Verfall verschont bleibt, und wie Sie Scan-Daten so in einen Report einbauen, dass ein Kunde ihm vertrauen kann, ohne dass Sie die Hälfte davon relativieren müssen.

Der Tracking-Stack, auf dem Agenturen ihr Reporting aufgebaut haben, bröckelt still und leise

Safari blockiert Third-Party- und seitenübergreifende Cookies standardmäßig vollständig, seit Safari 13.1 und iOS/iPadOS 13.4, bereits seit März 2020. Das ist keine neue Entwicklung: Agenturen, die Kampagnen für ein iPhone-lastiges Publikum ausspielen, leben seit sechs Jahren damit. Firefox zog mit Total Cookie Protection nach, das jedes Third-Party-Cookie in ein site-spezifisches „Glas" isoliert, sodass es nie domänenübergreifend abgeglichen werden kann, standardmäßig aktiv für alle Nutzer seit Firefox 103 im Juni 2022.

Bei Chrome liegt fast jeder falsch. Die Schlagzeile „Chrome killt Third-Party-Cookies" kursiert bereits seit 2019, doch Google verschob den Plan im April 2024, gab den Abschaffungs-Zeitplan im Juli 2024 dann komplett auf und strich im April 2025 sogar den eigenständigen „Wählen Sie Ihre Tracking-Präferenz"-Hinweis, den man als Ersatz vorgeschlagen hatte. Chrome lässt Third-Party-Cookies bis heute standardmäßig zu; der praktische Effekt von zwei Jahren Ankündigungen waren bestehende Browser-Datenschutzeinstellungen, kein neuer Blockmechanismus. Wenn ein Report oder ein Anbieter-Pitch behauptet, Chrome habe 2024 Cookies abgeschafft, ist das schlicht nicht das, was passiert ist, und es lohnt sich, das richtigzustellen, weil dabei unterschätzt wird, wie lange die tatsächliche Blockierung (Safari, Firefox) bereits still und leise in Kraft ist.

Dazu kommen Ad-Blocker. Umfragedaten von GWI beziffern die weltweite Nutzung von Ad-Blockern im zweiten Quartal 2025 auf 29,5 % der Internetnutzer, in den USA liegt der Wert mit 32,5 % näher an einem Drittel. Und die Plattformen, die früher schwache First-Party-Messung abgefedert haben, haben unumwunden zugegeben, dass mobile Datenschutzänderungen ihnen schaden: Metas eigener CFO bezeichnete die Auswirkung von Apples App Tracking Transparency auf den Umsatz 2022 im Earnings Call zum vierten Quartal 2021 als Gegenwind „in der Größenordnung von 10 Milliarden US-Dollar", eine Schätzung, die Meta über die eigene Messung abgegeben hat, keine Vermutung eines Dritten.

Das alles bedeutet nicht, dass digitale Attribution überall kaputt ist. Es bedeutet, dass der spezifische Mechanismus, auf den sich ein Großteil des Kampagnen-Reportings stützt, der seiten- oder app-übergreifende Identitätsabgleich, seit sechs Jahren schwächer wird und keine Anzeichen einer Umkehr zeigt. Ein QR-Scan hat auf diesem Mechanismus von Anfang an nie basiert.

Was einen QR-Scan strukturell anders macht

Marketingdaten werden üblicherweise in drei Kategorien eingeteilt. First-Party-Daten sind das, was Sie direkt aus Ihren eigenen Interaktionen mit jemandem erheben, ohne Vermittler. Third-Party-Daten werden von einem Unternehmen aggregiert, das nie eine direkte Beziehung zu der Person hatte, die sie beschreiben, genau die Kategorie, in die seitenübergreifende Cookies und Device-Graph-Abgleiche fallen. Zero-Party-Daten, ein Begriff, den die Forrester-Analystin Fatemeh Khatibloo 2018 geprägt hat, sind das, was Ihnen jemand bewusst und proaktiv mitteilt, eine geäußerte Präferenz oder ein ausdrückliches Opt-in.

Ein Scan eines dynamischen ScanKit-Codes ist konstruktionsbedingt First-Party. Es gibt kein Werbenetzwerk, das entscheidet, ob ein Pixel ausgelöst wird, kein Cookie, das eine seitenübergreifende Weiterleitungskette überstehen muss, und kein probabilistisches Modell, das eine mobile ID mit einer Desktop-Sitzung verknüpft, weil ein Drittel des Signals irgendwo vorgelagert blockiert wurde. Die Kamera des Telefons liest den Code, öffnet die URL, und Ihr eigener Weiterleitungsserver protokolliert die Anfrage. Das ist die gesamte Kette.

Was erfasst dieses serverseitige Protokoll konkret? Eine Standard-HTTP-Anfrage enthält einen Zeitstempel, den User-Agent-String (der Gerätetyp, Betriebssystem und Browser identifiziert), einen Referrer-Header, sofern vorhanden, und die IP-Adresse des Clients. Das ist für ein Reporting auf Kampagnenebene wirklich nützlich, aber man sollte genau sein, was die IP tatsächlich verrät: Geolocation-Datenbanken lösen IP-Adressen mit einer Genauigkeit von rund 99,8 % auf Länderebene auf, aber eine IP-basierte Standortbestimmung ist nicht, und kann nicht, präzise genug sein, um eine konkrete Adresse oder Einzelperson zu identifizieren. Anbieter-Genauigkeitswerte für feinere Auflösungen (Bundesstaat oder Region, in den USA rund 80 %; Stadt innerhalb von etwa 50 Kilometern, in rund zwei Dritteln der Fälle) machen das deutlich: Sie erhalten ein richtungsweisend nützliches Standortsignal, keinen Haushaltsabgleich. Wer ein belastbareres Identitätssignal als „jemand in dieser Stadt hat diesen Code gescannt" braucht, muss den Scan mit einem Formularausfüllen, einem Account-Login oder einer anderen expliziten Zero-Party-Aktion nachgelagert verknüpfen, statt das Protokoll selbst über seine Grenzen hinaus zu strapazieren.

Der andere strukturelle Punkt, den man klar benennen sollte, weil Anbieter das selten tun: Niemand im Bereich Identity Resolution (AppsFlyer, Adjust, mParticle und die anderen) veröffentlicht eine konkrete Prozentzahl für deterministische versus probabilistische Match-Raten, die man zitieren könnte. Was sie sagen, und was per Definition zutrifft, ist, dass deterministisches Matching (ein Identifikator, der eindeutig einer Handlung zugeordnet ist, genau das, was ein Scan eines eindeutigen dynamischen Codes ist) nicht denselben Schätzfehler trägt wie probabilistisches Matching (die Annahme, dass zwei verschiedene Geräte oder Sitzungen „wahrscheinlich" zur selben Person gehören). Ein QR-Scan eines Codes, den Sie selbst generiert haben und kontrollieren, ist von Anfang an deterministisch; es gibt keine modellierte Schätzung, der man misstrauen müsste.

Bricht der iOS-Datenschutz das QR-Code-Tracking wirklich?

Agenturen, denen ATT als Grund dafür genannt wurde, dass „mobiles Tracking nicht mehr funktioniert", sollten genau wissen, was es abdeckt. App Tracking Transparency regelt eine ganz bestimmte Sache: den Zugriff einer App auf den Werbe-Identifikator des Geräts (IDFA) und ihre Fähigkeit, die Daten dieser App mit Daten aus Apps und Websites anderer Unternehmen für Ad-Targeting oder Messung zu verknüpfen. Es handelt sich um eine App-Store- und SDK-Richtlinie, die innerhalb nativer Apps gilt. Ein QR-Scan, der eine normale Webseite in Safari oder Chrome öffnet, ist keine App, die IDFA-Zugriff anfragt, weshalb ATT dafür überhaupt nicht zuständig ist.

Mail Privacy Protection ist eine separate, engere Funktion: Sie verbirgt die IP-Adresse eines Mail-Nutzers und lädt externe Inhalte (einschließlich Tracking-Pixel) vorab, sodass ein Absender nicht erkennen kann, ob oder wann eine E-Mail geöffnet wurde. Sie gilt ausschließlich für Apple Mail. Ein QR-Code, der auf einem Flyer, Plakat oder Produkt aufgedruckt ist, ist kein E-Mail-Öffnungsereignis, weshalb MPP ihn ebenfalls nicht betrifft.

Die einzige Apple-Funktion, die tatsächlich mit einer QR-Weiterleitung interagieren kann, ist Link Tracking Protection, eingeführt mit iOS 17 und macOS Sonoma im Jahr 2023. Sie entfernt bekannte Tracking-Parameter aus der Query-String einer URL, bevor die Anfrage überhaupt über das Netzwerk gesendet wird, allerdings nur in drei spezifischen Bereichen: Nachrichten, Mail und Safari Privates Surfen. Sie zielt auf erkannte Tracking-Identifikatoren ab, die Art, die Werbenetzwerke einem Link für den seitenübergreifenden Klickabgleich anhängen, nicht auf den Pfad einer URL oder einen üblichen Kampagnen-Attributionsparameter. In der Praxis bedeutet das zweierlei dafür, wie Sie die Ziel-URL eines dynamischen Codes aufbauen. Erstens: Die überwiegende Mehrheit der QR-Scans, die über die Kamera eines Telefons direkt in einem normalen, nicht-privaten Browser-Tab geöffnet werden, befindet sich nie in einem Bereich, den LTP überhaupt berührt. Zweitens: Wenn Sie denselben getrackten Link zusätzlich per SMS oder E-Mail teilen, sollten Sie jeden Kampagnen-Identifikator im URL-Pfad oder Slug unterbringen statt in einem Query-Parameter, der einem bekannten Tracker ähnelt, dann läuft er unabhängig vom Bereich unverändert durch.

Brauchen QR-Weiterleitungsprotokolle einen Cookie-Consent-Banner?

Hier neigen viele Agenturen entweder zu übertriebener Vorsicht, die ihnen nützliche Daten kostet, oder zu zu wenig Vorsicht, die sie in ein Compliance-Problem bringt, weshalb Genauigkeit gefragt ist. Nach den ePrivacy-Regeln (und dem britischen Äquivalent, PECR) wird eine Einwilligungspflicht dadurch ausgelöst, dass Informationen auf dem Gerät eines Nutzers gespeichert oder von dort ausgelesen werden, der Mechanismus, den ein Cookie oder ein Tracking-Skript nutzt. Sowohl die Guidelines 2/2023 des Europäischen Datenschutzausschusses als auch die französische CNIL haben klargestellt, dass dieser Anwendungsbereich nicht auf wörtliche Cookies beschränkt ist; auch die Erfassung von IP-Adressen, die aus dem Auslesen der Endeinrichtung des Nutzers stammt (was ein Tracking-Pixel tut), kann darunterfallen. Die Aufsichtsbehörden haben keine pauschale Grenze gezogen, die serverseitiges IP-Logging als Kategorie generell ausnimmt, bauen Sie Ihre Compliance-Position also nicht auf „das ist doch nur ein Server-Log, also gilt ePrivacy nicht" auf.

Was jedoch trägt: Eine QR-Weiterleitung, die eine Anfrage protokolliert, um den Dienst zuverlässig zu betreiben und Missbrauch zu verhindern (die Ausnahme für „unbedingt erforderliche" Zwecke, die sowohl die ICO als auch die CNIL anerkennen, dieselbe Grundlage, die auch Betrugsprävention, Lastverteilung und einfache Authentifizierung abdeckt), braucht nicht denselben Opt-in-Consent-Banner wie ein Marketing-Cookie, das anschließend auf der Landingpage gesetzt wird. Der entscheidende Unterschied liegt darin, wofür das Logging dient: Den Betrieb der Weiterleitung sicherzustellen und das Scan-Volumen auf Kampagnenebene zu messen ist etwas anderes, als einen dauerhaften Identifikator zu setzen, um diesen Besucher später auf anderen Seiten erneut anzusprechen, was eindeutig eine einwilligungspflichtige Aktivität ist. Und unabhängig von der ePrivacy-Antwort bleibt die IP-Adresse in Ihrem Protokoll unter der DSGVO personenbezogene Daten, Sie brauchen also weiterhin eine Rechtsgrundlage (berechtigtes Interesse ist hierfür die übliche Wahl), eine festgelegte Aufbewahrungsfrist, und Sie sollten die protokollierten Felder auf das beschränken, was Sie tatsächlich nutzen. Unser DSGVO-Leitfaden geht tiefer auf die Einwilligungsgestaltung für die Landingpage selbst ein; der Punkt hier ist enger gefasst: Das Scan-Protokoll und das Landingpage-Cookie sind zwei unterschiedliche Compliance-Fragen, und sie zu vermischen ist der Grund, warum Agenturen entweder nützliches Reporting übermäßig blockieren oder eine echte Pflicht nicht ausreichend abdecken.

Aus Scans eine Attribution machen, der Ihr Kunde wirklich vertrauen kann

Der praktische Nutzen daraus ist ein Reporting-Workflow, der nicht die Einschränkungen braucht, die ein cookie-basierter Report hat. Beginnen Sie mit einem eindeutigen dynamischen Code pro Touchpoint, nicht einem Code, der über Plakat, Flyer und Direktmailing hinweg wiederverwendet wird, sodass ein Scan in dem Moment, in dem er passiert, einer bestimmten Platzierung zugeordnet werden kann; das ist dieselbe Disziplin, die hinter dem Tracken einer Print-Kampagne mit QR-Codes steckt. Jeder Scan ist dann ein First-Party-Ereignis, das Sie in Echtzeit dorthin schicken können, wo der Kunde bereits seine Single Source of Truth pflegt. Das gängige Muster ist ein Webhook: Ihr Weiterleitungsserver sendet die Ereignis-Payload in dem Moment, in dem sie entsteht, an eine URL, statt dass das CRM danach fragen muss. Die Custom-Events-API von HubSpot ist ein konkretes Beispiel für die empfangende Seite: Ein POST mit Ereignisname, einem ISO-8601-Zeitstempel, einem Properties-Objekt und einem Kontakt-Identifikator genügt, um einen Scan direkt mit dem Datensatz einer Person zu verknüpfen, ganz ohne seitenübergreifenden Abgleich.

Das heißt nicht, dass Sie UTM-Parameter oder GA4 über Bord werfen. Es heißt, dass Sie aufhören, sie als Ihre einzige Single Source of Truth zu behandeln. Speisen Sie Scans so in GA4 ein, wie wir es in unserem Google-Analytics-4-Leitfaden beschreiben, damit ein Scan als eigener Kanal erscheint, statt unter „Direkt" zu verschwinden, behandeln Sie aber das serverseitige Scan-Protokoll, das ohne Cookie-Abhängigkeit auskommt und keinen Ad-Blocker umgehen muss, als abgleichende Quelle, wenn beide voneinander abweichen. Beim Erstellen des Kundenreports gehen sowohl unser Leitfaden zu Scan-Kennzahlen als auch die Anleitung zum Kampagnen-ROI genau von dieser Art sauberem, deterministischem Ereignis als Eingabe aus; je weniger probabilistische Verknüpfungen in der Kette liegen, bevor die Zahl beim Kunden ankommt, desto einfacher wird dieses Gespräch.

Häufig gestellte Fragen

Setzt ein QR-Code Cookies?

Nein. Das Scannen eines QR-Codes öffnet eine URL; der Weiterleitungsserver kann die Anfrage (Zeitstempel, Gerätetyp, IP) protokollieren, ohne dabei überhaupt ein Cookie zu setzen oder auszulesen. Ein Cookie kommt erst ins Spiel, wenn die Landingpage selbst eines setzt, was eine separate Entscheidung ist, unabhängig vom Scan.

Welche Daten erfasst ein QR-Code-Scan?

Mindestens das, was eine Standard-HTTP-Anfrage mit sich bringt: einen Zeitstempel, den User-Agent-String (Gerät, Betriebssystem, Browser), einen Referrer-Header, sofern vorhanden, und die IP-Adresse des Clients. Die IP lässt sich zuverlässig auf Länderebene und ungefähr auf Stadt oder Region auflösen, nicht auf eine konkrete Person oder Adresse.

Wie genau ist QR-Code-Tracking im Vergleich zu Cookie-Tracking?

Kein namentlich bekannter Analytics-Anbieter veröffentlicht eine konkrete Prozentzahl für diesen Vergleich, seien Sie also skeptisch gegenüber jeder Zahl, die Ihnen begegnet. Qualitativ stimmt, dass ein Scan eines eindeutigen Codes, den Sie selbst kontrollieren, ein deterministisches Ereignis ist (genau dieser Code wurde genau zu diesem Zeitpunkt gescannt), während Cookie- und geräteübergreifende Attribution zunehmend auf probabilistischen Abgleich angewiesen ist, um die Lücken zu schließen, die Cookie-Blockierung und Ad-Blocker verursachen.

Warum wird pixelbasierte Werbeattribution immer unzuverlässiger?

Weil die Identitätssignale, auf die sie angewiesen ist, standardmäßig abgeschaltet werden. Safari blockiert Third-Party-Cookies seit 2020, Firefox seit 2022, und Apples App Tracking Transparency schränkt die app-übergreifende Weitergabe von Identifikatoren innerhalb von iOS-Apps ein. Metas eigener CFO bezifferte die Umsatzauswirkung von ATT im Jahr 2022 nach Metas eigener Schätzung auf rund 10 Milliarden US-Dollar.

Stört iOS Link Tracking Protection das QR-Code-Tracking?

Fast nie. Es entfernt nur bekannte Tracking-Parameter, und das auch nur in Nachrichten, Mail und Safari Privates Surfen. Ein normaler Scan, der über die Kamera des Telefons in einem regulären Browser-Tab geöffnet wird, findet in keinem dieser drei Bereiche statt.

Brauchen QR-Code-Weiterleitungen einen Cookie-Banner?

Das Protokollieren einer Anfrage allein zum Betrieb der Weiterleitung und zur Messung des Scan-Volumens kann sich in der Regel auf die von den Aufsichtsbehörden anerkannte Ausnahme für „unbedingt erforderliche" Zwecke stützen. Das anschließende Setzen eines Tracking- oder Retargeting-Cookies auf der Landingpage ist eine separate, einwilligungspflichtige Aktion. Die IP-Adresse bleibt in beiden Fällen personenbezogene Daten, für die eine DSGVO-Rechtsgrundlage und eine festgelegte Aufbewahrungsfrist erforderlich sind.

Was ist der Unterschied zwischen First-Party-, Zero-Party- und Third-Party-Daten?

First-Party-Daten stammen aus Ihren eigenen direkten Interaktionen mit jemandem. Zero-Party-Daten sind das, was Ihnen jemand bewusst mitteilt (eine geäußerte Präferenz, ein Opt-in). Third-Party-Daten werden von einem Unternehmen aggregiert, das keine direkte Beziehung zu der Person hat, die sie beschreiben. Ein Scan Ihres eigenen Codes ist per Definition First-Party.

Lassen sich QR-Scan-Daten in ein CRM oder eine CDP einspeisen?

Ja, typischerweise über einen Webhook: Der Weiterleitungsserver sendet das Scan-Ereignis in dem Moment, in dem es passiert, an das CRM oder die CDP. Plattformen mit einer Custom-Events-API, darunter HubSpot, akzeptieren einen Ereignisnamen, einen Zeitstempel, ein Properties-Objekt und einen Kontakt-Identifikator, was genügt, um einen Scan direkt mit dem Datensatz einer Person zu verknüpfen.

Braucht man noch UTM-Parameter, wenn man dynamische QR-Codes nutzt?

Ja, für das Reporting auf Kanalebene in GA4 und ähnlichen Tools. Es geht nicht darum, UTM-Tagging zu ersetzen; es geht darum, das serverseitige Scan-Protokoll als abgleichende Single Source of Truth zu behandeln, wenn cookie-abhängige Tools Scans unterrepräsentieren, die Ad-Blocker oder Browser-Datenschutzeinstellungen vor ihnen verborgen haben.

Kurz zusammengefasst

Third-Party-Cookies sind in Safari und Firefox bereits standardmäßig blockiert, Chrome hat das Gleiche nie konsequent umgesetzt, Ad-Blocker erreichen fast ein Drittel der Nutzer, und Plattformen wie Meta haben unumwunden gesagt, dass mobile Datenschutzänderungen sie messbaren Werbeumsatz kosten. Ein QR-Scan bleibt von diesem Verfall verschont, weil er von Anfang an nie auf seitenübergreifendem Identitätsabgleich basierte: Es ist ein First-Party-, deterministisches Ereignis, das Ihr eigener Server direkt protokolliert. iOS-Datenschutzfunktionen, die auf Apps und E-Mail abzielen, berühren einen normalen Scan nicht, und die Compliance-Frage zum Scan-Protokoll ist eine andere, und einfachere, als die Einwilligungsfrage zu einem Landingpage-Cookie. Verknüpfen Sie jeden eindeutigen dynamischen Code mit einem Webhook, der den Scan direkt in das CRM Ihres Kunden schickt, behalten Sie GA4 für die Ansicht auf Kanalebene, und nutzen Sie das deterministische Scan-Protokoll als die Zahl, die Sie verteidigen, wenn beide voneinander abweichen.