QR-Code-Retargeting: DSGVO-konformes Pixel-Tracking für Agenturen

Die meisten Ratgeber zu QR-Code-Retargeting hören bei „Facebook-Pixel auf der Landingpage einbauen" auf und erklären das Thema damit für erledigt. Manche gehen weiter und beschreiben das Ganze als cookieloses Marketing, was auf keiner der vier großen Werbeplattformen zutrifft. Keiner erwähnt, dass der häufigste Grund dafür, dass ein Scan die eigentlich vorgesehene Zielgruppe stillschweigend verfehlt, gar nicht der QR-Code selbst ist, sondern wie schnell der Besucher die Seite verlässt, auf die er weitergeleitet wird. Dies ist die Version, die alles abdeckt: was zwischen einem Scan und einer Werbezielgruppe tatsächlich passiert, warum die Behauptung „cookielos" falsch ist, was das Einwilligungsrecht wirklich verlangt, was Apples Datenschutzregeln einschränken und was nicht, und wie Sie das Pixel-plus-Server-Side-Setup aufbauen, das den Kontakt mit einem echten mobilen Browser übersteht.

Was QR-Code-Retargeting eigentlich ist

Ein QR-Code kann niemanden von sich aus retargeten. Er ist ein Link. Das Retargeting findet auf der Seite statt, auf die der Code weiterleitet, über denselben Ad-Tech-Mechanismus, der auch Retargeting nach einer Google-Suche oder einer Instagram-Story ermöglicht: Ein kleines Skript auf dieser Seite, meist Pixel oder Tag genannt, teilt einer Werbeplattform mit: „Dieser Browser war gerade hier."

Die Kette läuft in fünf Schritten ab. Die Kamera des Smartphones liest den Code und folgt der Weiterleitung. Die Weiterleitung löst sich auf, normalerweise als schnelle serverseitige 301- oder 302-Weiterleitung, zur Ziel-URL. Das HTML der Zielseite lädt, und das JavaScript des Tags wird heruntergeladen und ausgeführt, zum Beispiel Metas fbevents.js oder das Pixel-Skript von TikTok. Das Tag sendet ein Netzwerk-Beacon mit einer Kennung: einem Cookie-Wert, einer Klick-ID oder gehashten Kontaktdaten. Die Werbeplattform gleicht dieses Beacon mit einem bestehenden Profil ab und fügt den Browser oder die Person, nach eigenem Zeitplan statt sofort, einer Zielgruppe hinzu, die Sie mit einer künftigen Kampagne ansprechen können.

Nichts an dieser Kette ist QR-spezifisch. Was bei QR anders ist: Der Besucher kommt ohne Browserverlauf auf Ihrer Seite und ohne frühere Interaktion mit Ihrem Werbekonto an, sodass der erste Seitenaufruf nach dem Scan sehr oft auch die einzige Chance ist, das Tag auszulösen, bevor die schnellsten Besucher den Tab schließen. Allein diese Tatsache erklärt, warum die unten beschriebenen Fehlerquellen hier stärker ins Gewicht fallen als bei einem gewöhnlichen Website-Besuch.

Nein, es ist nicht cookielos

Mehrere Anbieterseiten für QR-Codes beschreiben pixelbasiertes Retargeting als „cookieloses Marketing". Es lohnt sich, hier präzise zu sein, denn das bestimmt sowohl, was Sie einem Kunden versprechen können, als auch, welche Einwilligung Sie einholen müssen. Prüft man die Dokumentation der einzelnen Plattformen, zeigt sich ein einheitliches Bild: Jede von ihnen nennt ein Cookie als Bestandteil des Zuordnungsmechanismus.

Metas Entwicklerdokumentation erklärt, dass sich das Pixel „auf Facebook-Cookies stützt, die es uns ermöglichen, Ihre Website-Besucher ihren jeweiligen Facebook-Konten zuzuordnen", und nennt zwei konkrete Cookies: _fbp, ein zufällig generiertes First-Party-ID-Cookie, das automatisch beim ersten Seitenaufruf angelegt wird, und _fbc, das die Anzeigenklick-Kennung aus einem fbclid-URL-Parameter speichert und nach 90 Tagen abläuft. Googles Support-Dokumentation beschreibt das Google-Ads-Tag als Speicher für „Cookies, die Informationen über die Interaktion sowie eine eindeutige Kennung für einen Nutzer oder den Anzeigenklick enthalten, der den Nutzer auf Ihre Website geführt hat", verknüpft mit der Klick-ID, die Ihre Anzeige erzeugt hat. Das Hilfe-Center von TikTok bestätigt, dass das TikTok-Pixel standardmäßig First-Party-Cookies verwendet, zusätzlich zu Third-Party-Cookies, sofern Sie diese nicht deaktivieren, „um Events mit Personen abzugleichen, die mit Ihren Inhalten auf TikTok interagieren". Das Insight Tag von LinkedIn setzt Cookies und außerhalb der EU, des EWR, Großbritanniens und Quebecs zusätzlich eine pseudonyme Kennung namens LinkedIn Ads ID, die LinkedIn ausdrücklich als „zusätzliches Signal zu den Cookies", nicht als deren Ersatz beschreibt.

Wörtlich genommen bestätigen damit vier verschiedene Plattformen in ihrer eigenen Dokumentation, dass Cookies zentral dafür sind, wie eine QR-gestützte Retargeting-Zielgruppe entsteht. Ein QR-Scan erreicht denselben cookie-basierten Stack wie jeder andere Website-Besuch; der Code ändert lediglich, wie der Besucher auf die Seite gelangt, die das Cookie setzt. Es als cookielos zu bezeichnen, ist keine Vereinfachung, sondern ein sachlicher Fehler, und einer mit Konsequenzen für den nächsten Abschnitt.

Das Einwilligungsproblem, das ein QR-Scan schafft

Da die Cookies real sind, gelten hier dieselben Einwilligungsregeln wie für jedes andere Tracking-Pixel, und ein QR-Scan macht das Timing enger, als die meisten Agenturen erwarten.

Nach der ePrivacy-Richtlinie erfordert das Speichern oder Auslesen von Informationen auf dem Gerät eines Nutzers eine vorherige Einwilligung, es sei denn, dies ist unbedingt erforderlich, um einen vom Nutzer ausdrücklich gewünschten Dienst zu erbringen. Ein Retargeting-Pixel fällt nicht darunter. Die Leitlinien 2/2023 des Europäischen Datenschutzausschusses (EDSA), im Oktober 2024 finalisiert, behandeln Tracking-Pixel direkt und kommen zu dem Schluss, dass das Platzieren eines Pixels auf einer Seite über den Caching-Mechanismus des Geräts als „Speicherung" gilt, und dass das anschließende „Nachhause-Telefonieren" des Pixels zur Werbeplattform ein separater Akt des „Zugriffs" ist, sodass ein Marketing-Pixel dieselbe vorherige Einwilligung benötigt wie ein Cookie, unabhängig davon, ob es tatsächlich eines verwendet. Das schließt die Lücke, auf die sich manche Anbieter berufen haben, indem sie argumentierten, ein 1x1-Tracking-Pixel unterscheide sich irgendwie von einem Cookie. Nach aktueller Leitlinie des EDSA ist das nicht der Fall.

Die eigene Definition der Einwilligung in der DSGVO, in Artikel 4 Nr. 11 und Artikel 7, verlangt, dass sie freiwillig, spezifisch, informiert und durch eine eindeutige bestätigende Handlung erteilt wird; Erwägungsgrund 32 schließt Schweigen, vorangekreuzte Kästchen oder das bloße Weitersurfen als gültige Einwilligung aus. Die französische Datenschutzbehörde CNIL wendet dies seit April 2021 konkret auf Marketing-Tags an: kein Lesen oder Schreiben auf dem Gerät eines Besuchers, bevor dieser zugestimmt hat.

Hier kommt die QR-spezifische Besonderheit ins Spiel. Ein Besucher, der auf ein Suchergebnis oder eine Anzeige klickt, hat Ihr Cookie-Banner meist schon einmal bei einem früheren Besuch passiert oder gelangt über einen Link, bei dem eine Consent-Management-Plattform Zeit hat zu laden, bevor irgendetwas ausgelöst wird. Ein QR-Scan landet dagegen oft kalt, direkt von einem physischen Objekt aus, auf einer einzigen dedizierten Seite mit genau einer Aufgabe: weiterleiten und tracken. Wenn Ihr Retargeting-Tag das Erste ist, was diese Seite tut, lösen Sie es bei jedem einzelnen Scan aus, bevor überhaupt eine Einwilligung vorliegt, und das ist ein eindeutiger Verstoß gegen Artikel 5 Absatz 3 der ePrivacy-Richtlinie, kein Grenzfall. Die Lösung ist technisch, nicht juristisch: Schalten Sie das Retargeting-Tag hinter Ihr Consent-Banner, etwa mit Google Consent Mode oder den eigenen Blockierregeln Ihrer CMP, sodass sich die QR-Landingpage genau wie jede andere First-Party-besuchte Seite verhält, statt wie eine Abkürzung am Banner vorbei.

Außerhalb der EU, Großbritanniens und des EWR kehrt sich die Logik um. Kaliforniens CCPA und CPRA arbeiten mit einem Opt-out-Modell: Ein Unternehmen darf Daten standardmäßig für kontextübergreifende verhaltensbasierte Werbung weitergeben, bis der Besucher sein Recht „Do Not Sell or Share My Personal Information" ausübt, entweder über einen entsprechenden Link oder ein automatisiertes Opt-out-Signal wie Global Privacy Control, das Unternehmen seit dem 1. Januar 2026 automatisch beachten müssen. In der Praxis bedeutet das, dass dieselbe QR-Landingpage zwei unterschiedliche Standardeinstellungen braucht, je nachdem, wo sich der Besucher beim Scannen befindet: gesperrt in Europa, offen mit beachtetem Opt-out-Signal in Kalifornien. Die meisten Consent-Management-Plattformen regeln das über Geolocation-Regeln; prüfen Sie vor dem Druckauftrag, ob Ihre das für beide Rechtsräume zuverlässig tut.

Einen umfassenderen Überblick darüber, was ein getrackter Scan erfasst und wie Sie durchgängig compliant bleiben, finden Sie unter Sind QR-Codes DSGVO-konform?

Was Apples Datenschutzregeln tatsächlich einschränken

Agenturen gehen häufig davon aus, dass Apples App Tracking Transparency (ATT) das ist, was zwischen einem QR-Scan und einer sauberen Retargeting-Zielgruppe steht. Meistens stimmt das nicht, und wer hier falsch liegt, repariert am Ende das falsche Problem.

ATT verlangt seit iOS 14.5 im April 2021, dass Apps um Erlaubnis bitten müssen, bevor sie Nutzer tracken oder die Werbekennung IDFA auslesen, und regelt das Verhalten nativer Apps. Apples eigene Entwickler-FAQ zieht die Grenze klar: ATT gilt für eine In-App-Webansicht nur, wenn sie „für die App-Funktionalität" genutzt wird, und ausdrücklich nicht, wenn die Webansicht „dem Nutzer die Navigation im offenen Web ermöglicht". Ein QR-Scan öffnet die Kamera des Smartphones und übergibt dann an den Standardbrowser oder eine Webansicht, die als reine Web-Navigation fungiert, was klar auf der anderen Seite dieser Grenze liegt. Es ist sehr unwahrscheinlich, dass ATT der Mechanismus ist, der Ihr QR-Retargeting-Pixel blockiert, denn es war von Anfang an nie dafür gedacht, diesen Weg zu regeln.

Die Regel, die tatsächlich zählt, ist Safaris Intelligent Tracking Prevention (ITP), und sie ist restriktiver, als den meisten Agenturen bewusst ist. ITP blockiert seit 2020 standardmäßig alle Third-Party-Cookies, ohne Ausnahme. Spezifischer für QR: Erkennt ITP eine „Link Decoration", also an eine URL angehängte Tracking-Parameter, was auf fast jede QR-Weiterleitung zutrifft, begrenzt es die Lebensdauer jedes von der eigenen JavaScript-Logik dieser Seite gesetzten Cookies auf 24 Stunden, statt des längeren Zeitfensters, das dasselbe Tag bei einem normalen Referral bekäme. Metas _fbc-Cookie hat laut Dokumentation eine Laufzeit von 90 Tagen; auf einer in Safari geöffneten QR-Landingpage kann ITPs Link-Decoration-Regel das auf einen Tag verkürzen. Das ist der reale, belegbare, technische Grund dafür, dass eine QR-Retargeting-Zielgruppe sich speziell bei iPhone-Traffic auf den Tag des Scans konzentriert und danach schnell ausdünnt, und es lohnt sich, das einem Kunden in diesen Begriffen zu erklären statt mit einem vagen Verweis auf „Apples Datenschutzsache".

Hinzu kommt, wo ein QR-Scan tatsächlich wahrscheinlich geöffnet wird: im eigenen In-App-Browser von Instagram oder TikTok, wenn der Besucher über eine Story oder einen geteilten Link statt über die native Kamera-App darauf getippt hat. Diese In-App-Browser führen üblicherweise ihren eigenen, separaten Cookie-Speicher statt den von Safari zu teilen, sodass ein Besucher, der von einem gedruckten Poster mit der nativen Kamera scannt und später einen verwandten Link innerhalb von Instagram anklickt, demselben Pixel wie zwei verschiedene, nicht zuordenbare Personen erscheinen kann. Das ist als technische Möglichkeit gut dokumentiert (der Sicherheitsforscher Felix Krause zeigte 2022, dass der In-App-Browser von Instagram trackingfähigen Code in die von ihm gerenderten Drittanbieterseiten einschleust), aber es gibt keine öffentlichen Daten dazu, was jede Plattform heute konkret damit macht. Betrachten Sie das daher als Grund, warum Ihre Zahlen bei über Social Media zugeführten Scans verrauschter ausfallen, nicht als konkret zu behauptenden Datenschutzverstoß.

Der wahre Grund, warum Scans in der Zielgruppe fehlen

Die gängigste technische Erklärung für die Untererfassung beim QR-Retargeting ist falsch: Es liegt nicht daran, dass eine schnelle Weiterleitung das Pixel irgendwie „überholt". Eine serverseitige 301- oder 302-Weiterleitung löst sich auf, bevor überhaupt HTML oder JavaScript ausgeführt wird, sodass die Geschwindigkeit der Weiterleitung gar nichts gibt, wogegen sie zu früh oder zu spät auslösen könnte. Das Pixel lebt auf der Zielseite, und das eigentliche Risikofenster öffnet sich in dem Moment, in dem diese Seite zu laden beginnt, und schließt sich, sobald der Besucher sie verlässt. Ein Besucher, der scannt, einen Blick auf eine langsam ladende Seite wirft und in weniger als einer Sekunde wieder abspringt, kann die Seite verlassen, bevor das Skript des Tags überhaupt fertig heruntergeladen ist.

Browserhersteller haben genau für dieses Problem eigene Werkzeuge entwickelt, weil es älter ist als QR-Codes und jede Seite betrifft, die ein Besucher schnell wieder verlassen könnte. Die sendBeacon()-API existiert, damit eine Seite eine kleine Analytics-Payload einreihen kann, die den Seitenwechsel übersteht, und die aktuelle Empfehlung der Browserhersteller (aus Chromes eigener technischer Dokumentation) rät dazu, sie über das visibilitychange-Ereignis auszulösen, also zu prüfen, ob die Seite ausgeblendet wurde, statt über unload oder beforeunload, die Chrome aktiv abschafft, weil sie „in vielen typischen Unload-Situationen nicht auslösen, unter anderem beim Schließen eines Tabs über den Tab-Umschalter auf Mobilgeräten". Eine unabhängige empirische Studie zur Zuverlässigkeit der Beacon-Zustellung ergab, dass rund 72 % der zum unload-Zeitpunkt gesendeten Beacons und knapp 93 % der früher, beim Laden der Seite, gesendeten Beacons tatsächlich ihr Ziel erreichten, wobei iOS Safari als der unzuverlässigste Fall für alles hervorstach, was bis zum Verlassen der Seite aufgeschoben wird. Nichts davon ist eine offizielle Plattformstatistik, aber es deckt sich mit dem, was Agenturen in der Praxis beobachten: Mobile Besucher mit langsamer Verbindung sind es, die das Retargeting stillschweigend verfehlt.

Die praktische Konsequenz für eine QR-Landingpage: Halten Sie sie schlank genug, um sicher innerhalb der ersten ein bis zwei Sekunden zu rendern und ihre Tags auszulösen, fügen Sie nichts hinzu, das das Tag hinter anderen Skripten verzögert, und prüfen Sie, falls Sie Google Tag Manager nutzen, dass jeder Trigger für einen Klick-Durchlauf oder ein Formular auf dieser Seite GTMs Option „Auf Tags warten" verwendet, statt einfach anzunehmen, das Tag habe schon ausgelöst. Nichts davon behebt eine langsame Verbindung, aber es beseitigt jede vermeidbare Verzögerung, die in Ihrer Kontrolle liegt.

Ein Pixel Schritt für Schritt zu einer QR-Landingpage hinzufügen

Der zuverlässige Weg dafür führt über Google Tag Manager statt über manuelle Anpassungen der Seite, weil Sie so an einer zentralen Stelle die Tags aller Plattformen verwalten und die Einwilligungssteuerung festlegen können.

Legen Sie unter tagmanager.google.com ein GTM-Konto und einen Web-Container an und installieren Sie die beiden Snippets, die GTM Ihnen gibt: das Hauptskript so weit oben wie möglich im <head> der Seite und den <noscript>-Fallback direkt nach dem öffnenden <body>-Tag. Fügen Sie für jede Plattform ihr Tag über die offizielle Vorlage aus GTMs Template-Galerie hinzu, statt rohen Anbieter-Code einzufügen: Meta veröffentlicht eine eigene Pixel-Vorlage (entwickelt und gepflegt auf GitHub unter der Organisation facebook), die ein Event-ID-Feld speziell zur Deduplizierung gegen serverseitige Events unterstützt, was relevant wird, sobald Sie zusätzlich eine Conversions API einbinden, dazu gleich mehr.

Grenzen Sie den Trigger eng ein. Da eine QR-Landingpage meist eine einzelne dedizierte URL ist und keine ganze Website, lösen Sie das Retargeting-Tag auf genau diesem Seitenpfad aus, nicht über GTMs Standard-Trigger „Alle Seiten". So bleiben Tag und Einwilligungssteuerung exakt auf die zugehörige Seite beschränkt, statt auf den Rest der Website überzugreifen. Veröffentlichen Sie über „Senden" und dann „Veröffentlichen und Version erstellen", nicht nur über „Version erstellen" allein, das speichert lediglich einen Entwurf; jede echte Veröffentlichung erzeugt eine Version, auf die Sie zurückrollen können, falls etwas nicht funktioniert.

Zielgruppengröße und Timing: was Sie einem Kunden sagen sollten

Agenturen bekommen vor jeder Kampagne zwei Fragen gestellt: Wie groß muss die Zielgruppe sein, und wie schnell können wir sie nutzen? Die ehrliche Antwort lautet: Das variiert je nach Plattform, und manche der offiziellen Zahlen sind weniger festgezurrt, als sie wirken.

Google Ads Customer Match benötigt mindestens 100 hochgeladene Datensätze. Die Remarketing-Segmente für Display, Suche und YouTube brauchen für seit dem 1. Februar 2024 erstellte oder aktualisierte Listen mindestens 100 aktive Besucher innerhalb der letzten 30 Tage, wobei Google auf einer separaten, offenbar nicht abgeglichenen Support-Seite weiterhin ein Minimum von 1.000 Cookies speziell für Suchremarketing-Listen nennt. Da Google diese Zahl bereits geändert hat, prüfen Sie das aktuelle Google-Ads-Interface, statt einem Kunden eine der beiden Angaben als fix zu nennen. TikToks Custom Audiences benötigen insgesamt 1.000 zugeordnete Nutzer, bevor eine Anzeigengruppe sie verwenden kann. LinkedIns Matched Audiences brauchen 300 zugeordnete Mitgliedskonten, bevor die Plattform die Zielgruppe als „Verifiziert" und nutzbar markiert. Meta veröffentlicht kein festes Minimum für eine Website-Custom-Audience; die eigene Empfehlung ist qualitativ und rät, vor der Aktivierung auf „mehrere hundert Personen" zu warten. Die Zahl „100", die Agenturen für Meta oft zitieren, stammt tatsächlich aus der separaten Mindestgröße der Quellzielgruppe für eine Lookalike Audience, nicht aus der Auslieferung von Custom Audiences, und die beiden werden in einem Kunden-Deck leicht verwechselt.

Beim Timing ist es ähnlich uneinheitlich. Google Ads beginnt Sekunden nach dem Auslösen eines Tags mit dem Abgleich von Besuchern, aber eine neu erstellte Liste kann 48 bis 72 Stunden brauchen, bis sie vollständig gefüllt ist. LinkedIn gibt unumwunden an, dass die Verarbeitung einer Matched Audience bis zu 48 Stunden dauern kann. Meta und TikTok veröffentlichen überhaupt keine offizielle Angabe zur Verarbeitungszeit; beide sagen lediglich, dass die Befüllung von Ihrem Traffic und davon abhängt, wann das Tag live gegangen ist, ohne rückwirkende Erfassung von Scans vor diesem Datum. Wenn Sie einem Kunden für Meta oder TikTok eine konkrete Zahl versprechen, versprechen Sie etwas, worauf sich keine der beiden Plattformen schriftlich festlegt.

Server-seitiges Tracking schließt die Lücke, die ein Pixel nicht schließen kann

Die Dokumentation jeder Plattform kommt zum selben Eingeständnis: Ein reines Browser-Pixel verliert Events durch Verbindungsprobleme, fehlgeschlagene Seitenladevorgänge, Ad-Blocker und genau das oben beschriebene ITP- und In-App-Browser-Verhalten, und eine serverseitige Verbindung holt einen erheblichen Teil davon zurück. Meta nennt das die Conversions API, die dieselben Events direkt von Ihrem Server an Meta sendet, dedupliziert gegen das Browser-Pixel über eine gemeinsame Event-ID, und beschreibt ihren Zweck als das „Teilen von Website-Events, die das Pixel aufgrund von Netzwerkverbindungsproblemen oder Fehlern beim Laden der Seite verlieren könnte". TikToks Events API verwendet fast identische Formulierungen: „Verbindungsprobleme und Inkonsistenzen zwischen Browsern können über das Pixel gemeldete Conversions beeinträchtigen", und empfiehlt, beide gemeinsam zu betreiben. Google Ads bietet Enhanced Conversions, das First-Party-Daten wie eine E-Mail-Adresse vor dem Versand hasht und mit Googles eigenen Daten angemeldeter Nutzer abgleicht, um Conversions zurückzugewinnen, die das cookie-basierte Tag allein verpassen würde. LinkedIns Conversions API sendet serverseitige Events, die die Abhängigkeit vom Cookie-Abgleich weitgehend reduzieren.

Speziell bei QR, wo der Traffic überwiegend mobil ist und überproportional auf Safaris ITP-Einschränkungen und In-App-Browser trifft, ist serverseitiges Tracking kein optionales Upgrade, sondern der Baustein, der dafür sorgt, dass die Zahlen, die ein Kunde sieht, ungefähr dem entsprechen, was tatsächlich passiert ist. Wenn Sie aus diesem Leitfaden nur eine Sache über das Basis-Pixel hinaus umsetzen, machen Sie es die Conversions API der jeweiligen Plattform oder ihr Äquivalent, parallel zum Pixel betrieben mit übereinstimmenden Event-IDs, damit die Plattform dedupliziert statt doppelt zählt.

Für die Attributionsfrage, die dieses ganze Setup beantworten soll, vergleichen Sie es mit einem UTM-basierten Ansatz in QR-Code-UTM-Parametern, und wo das typischerweise in großem Umfang eingesetzt wird, sehen Sie sich QR-Codes für Direktmailings und QR-Codes für Events und Messen an.

Häufig gestellte Fragen

Ist QR-Code-Retargeting cookielos?

Nein. Meta, Google Ads, TikTok und LinkedIn dokumentieren alle Cookies als Bestandteil davon, wie ihr Pixel oder Tag einen Besucher einer Zielgruppe zuordnet: Meta nennt konkret _fbp und _fbc, Google Ads verknüpft ein Cookie mit der Klick-ID, TikTok verwendet standardmäßig First- und Third-Party-Cookies, und LinkedIns pseudonyme Kennung wird als Ergänzung zu Cookies beschrieben, nicht als deren Ersatz. Ein QR-Scan erreicht denselben cookie-basierten Stack wie jeder andere Website-Besuch.

Brauche ich eine Einwilligung, um jemanden nach einem QR-Code-Scan zu retargeten?

Ja, in der EU, in Großbritannien und im EWR. Die Leitlinien des Europäischen Datenschutzausschusses aus dem Jahr 2024 behandeln ein Tracking-Pixel im Rahmen der Einwilligungspflicht der ePrivacy-Richtlinie genauso wie ein Cookie, weshalb es hinter einer aktiven Einwilligung liegen muss und nicht beim Laden der Seite auslösen darf. Außerhalb dieser Regionen räumen Regelungen wie CCPA/CPRA Besuchern stattdessen ein Widerspruchsrecht ein, unter anderem über ein automatisiertes Global-Privacy-Control-Signal, das Unternehmen beachten müssen.

Wie lange dauert es, bis ein QR-Scan in einer Retargeting-Zielgruppe erscheint?

Das hängt von der Plattform ab. LinkedIn gibt bis zu 48 Stunden an. Google Ads beginnt innerhalb von Sekunden mit dem Abgleich, aber eine neue Liste kann 48 bis 72 Stunden brauchen, bis sie vollständig gefüllt ist. Meta und TikTok veröffentlichen keine offizielle Verarbeitungszeit, sondern geben nur an, dass es vom Traffic-Volumen und davon abhängt, wann das Tag erstmals live war.

Wie groß muss eine Zielgruppe für Retargeting mindestens sein?

Google Ads Customer Match benötigt 100 Datensätze; die Segmente für Display, Suche und YouTube brauchen bei neueren Listen 100 aktive Nutzer in den letzten 30 Tagen (prüfen Sie die aktuelle Google-Ads-Dokumentation, da sich diese Zahl schon einmal geändert hat). TikTok verlangt 1.000 zugeordnete Nutzer. LinkedIn verlangt 300 für eine als „Verifiziert" markierte Zielgruppe. Meta setzt kein festes Minimum, sondern gibt nur die qualitative Empfehlung, auf mehrere hundert Personen zu warten.

Blockiert Apples App Tracking Transparency QR-Code-Retargeting?

Nicht direkt. ATT regelt das Tracking in nativen Apps und die Werbekennung IDFA, und Apples eigene Dokumentation schließt In-App-Webansichten aus, die der Navigation im offenen Web dienen, genau das, was ein QR-Scan typischerweise auslöst. Die Einschränkung, die tatsächlich zählt, ist Safaris Intelligent Tracking Prevention, das Third-Party-Cookies komplett blockiert und First-Party-Cookies, die per JavaScript gesetzt werden, auf 24 Stunden begrenzt, sobald es eine URL als mit Tracking-Parametern versehen erkennt, also genau die Form der meisten QR-Weiterleitungslinks.

Warum erfasst mein Retargeting-Pixel nicht alle meine QR-Scans?

Die wahrscheinlichste Ursache ist nicht der QR-Code oder die Weiterleitung, beide lösen sich auf, bevor überhaupt ein Tracking-Skript läuft. Entscheidend ist, wie schnell der Besucher die Zielseite verlässt, im Verhältnis dazu, wie lange das Skript des Tags zum Herunterladen, Ausführen und Auslösen braucht, kombiniert mit ITPs 24-Stunden-Cookie-Begrenzung für dekorierte URLs in Safari und dem separaten Cookie-Speicher vieler In-App-Browser. Halten Sie die Landingpage schlank, lösen Sie Tags früh aus, und ergänzen Sie serverseitiges Tracking, um das aufzufangen, was das Browser-Pixel verpasst.

Sollte ich ein Pixel, eine serverseitige Conversions API oder beides nutzen?

Beides, dedupliziert. Jede große Plattform dokumentiert dieselbe Begründung: Ein Browser-Pixel allein verliert Events durch Verbindungsprobleme, Ad-Blocker und Datenschutzeinschränkungen der Browser, und eine serverseitige Verbindung (Metas Conversions API, TikToks Events API, Googles Enhanced Conversions, LinkedIns Conversions API) gewinnt einen erheblichen Teil davon zurück, wenn sie parallel zum Pixel mit einer übereinstimmenden Event-Kennung läuft.

Kann ich QR-Code-Scanner auch auf TikTok oder LinkedIn retargeten, nicht nur auf Meta und Google?

Ja, über denselben zugrunde liegenden Mechanismus: ein Tag auf der Landingpage, auf dieselbe Weise über Google Tag Manager eingebunden und eingegrenzt, mit der jeweils eigenen Mindestzielgruppengröße und Verarbeitungszeit der Plattform.

Was ist der Unterschied zwischen QR-Code-Retargeting und QR-Code-Analytics?

Analytics zählt und beschreibt, was passiert ist: wie viele Scans, von wo, auf welchem Gerät. Retargeting macht aus denselben Besuchern eine Zielgruppe, die Sie auf einer anderen Plattform erneut bewerben können. Beides kann aus demselben Scan hervorgehen, aber Zweiteres funktioniert nur, wenn auf der Zielseite ein korrekt mit Einwilligung versehenes Retargeting-Tag vorhanden ist. Für die Analytics-Seite siehe QR-Code-Analytics: Welche Scan-Kennzahlen zählen.

Die Kurzfassung

QR-Code-Retargeting ist keine besondere oder cookielose Technik; es nutzt dieselben Pixel, dieselben Cookies und dieselben Einwilligungsregeln wie jedes andere Web-Retargeting, nur erreicht über einen Scan statt einen Klick. Schalten Sie das Tag in der EU und in Großbritannien hinter eine echte Einwilligung, respektieren Sie Opt-out-Signale in Kalifornien, und machen Sie sich weniger Gedanken über Apples App Tracking Transparency, das hier fast nie greift, sondern konzentrieren Sie sich auf Safaris Intelligent Tracking Prevention, das sehr wohl greift und Ihr Tracking-Cookie auf den meisten QR-Links still auf 24 Stunden begrenzt. Wenn die Zahlen weiterhin dünn wirken, schauen Sie sich an, wie schnell Ihre Landingpage ihr Tag im Verhältnis dazu auslöst, wie schnell mobile Besucher abspringen, nicht auf den QR-Code selbst, und schließen Sie die Lücke mit einer serverseitigen Conversions API oder Events API statt mit einem schwereren Pixel. Prüfen Sie das aktuelle Zielgruppenminimum und die Verarbeitungszeit jeder Plattform, bevor Sie einem Kunden eine Zahl nennen, denn mehrere davon ändern sich. Bauen Sie das einmal als eingegrenztes Google-Tag-Manager-Setup auf Ihren QR-Landingpages auf, und jede künftige Kampagne erbt es kostenlos.