QR-Code öffnet App nicht? Universal Links, App Links und Deep Linking richtig einrichten

Kann ein QR-Code eine App direkt öffnen? Universal Links, App Links und warum die meisten Scans trotzdem im Browser landen

Eine Agentur betreut eine Treuepunkte-Kampagne für einen Handelskunden. Die App ist bereits auf dem Smartphone des Kunden installiert, die Punkte liegen dort schon bereit, und der QR-Code auf dem Kassenbon soll die App direkt auf dem Bildschirm "Punkte sammeln" öffnen. Stattdessen öffnet das Telefon Safari oder Chrome, zeigt eine schlichte Webseite, und der eigentliche Sinn der Kampagne, die Interaktion innerhalb der App zu halten, die der Kunde extra hat entwickeln lassen, verpufft mit einem einzigen Scan. Das ist kein defekter QR-Code. Es ist eine Diskrepanz zwischen dem, was ein QR-Code tatsächlich tut (eine URL kodieren), und dem, was das "Öffnen einer App" voraussetzt (eine Kette aus Vertrauensmechanismen und Auflösungslogik auf Betriebssystemebene, in die ein Kamerascan nicht automatisch eingebunden ist). Dieser Artikel erklärt den Mechanismus im Detail: was Universal Links und App Links sind, warum sie nicht garantiert auslösen, nur weil jemand gescannt statt getippt hat, was Deferred Deep Linking für Menschen bringt, die die App noch nicht installiert haben, und die konkrete Liste der Dinge, die die Kette unterbrechen können, damit eine Agentur ein "warum landet das im Browser"-Ticket diagnostizieren und beheben kann, statt zu raten. Das ist ein anderes Problem als das Weiterleiten von Neuinstallationen zum richtigen App-Store, das in ein QR-Code für beide App-Stores behandelt wird; hier geht es um Menschen, die die App bereits installiert haben, oder darum, den Store-Besuch nahtlos mit dem ersten Bildschirm der App zu verknüpfen.

Was "Deep Linking" tatsächlich bedeutet, und die drei dahinterstehenden Mechanismen

Ein Deep Link ist eine URL, die den Nutzer nicht auf einen generischen Startbildschirm, sondern direkt zu einem bestimmten Inhalt innerhalb einer App führt: eine Produktseite, ein Punktestand, ein Eventticket. Drei Mechanismen ermöglichen das, und sie sind nicht austauschbar.

Universal Links (iOS)

Universal Links sind ganz normale https://-URLs. Es gibt kein spezielles Schema; der Trick ist eine kleine JSON-Datei, die apple-app-site-association-Datei (AASA), gehostet unter /.well-known/apple-app-site-association auf der Zieldomain, kombiniert mit einer in der App selbst hinterlegten Berechtigung (Entitlement). Apple beschreibt es selbst so: "Ihre App übernimmt eine Entitlement... und Ihr Webserver übernimmt eine einzige JSON-Datei." Da nur der Domaininhaber diese Datei veröffentlichen kann, kann keine andere App vorgeben, Links für eine Domain zu verarbeiten, die sie nicht kontrolliert, genau das war die Schwachstelle, die Universal Links schließen sollten.

Seit iOS 14 rufen Geräte die AASA-Datei nicht mehr bei jeder Prüfung direkt von Ihrem Server ab. Sie holen sie über ein von Apple verwaltetes Content Delivery Network, wobei ein separater "Alternate Mode" für interne Domains oder Entwicklungsdomains zur Verfügung steht, die diesen Cache umgehen sollen. Dieses Detail ist praktisch relevant: Eine neu hochgeladene AASA-Datei greift nicht zwangsläufig sofort, weil das CDN erst nachziehen muss.

iOS merkt sich außerdem die vorherige Entscheidung eines Nutzers. Wenn jemand zuvor gewählt hat, den Inhalt einer Domain in Safari statt in der zugehörigen App anzuzeigen (durch langes Drücken eines Links oder durch Verlassen der App), neigt das System dazu, diese Wahl für dieselbe Domain zu wiederholen, bis der Nutzer die App bewusst erneut aufruft, typischerweise durch erneutes Tippen auf ein Smart App Banner.

Smart App Banner, ein verwandter, aber eigenständiger Mechanismus

Ein Smart App Banner ist die Leiste, die oben in Safari erscheint, deklariert über ein einziges Meta-Tag im Head der Seite (apple-itunes-app). Ist die App installiert, öffnet ein Tippen auf das Banner sie direkt; ist sie es nicht, führt es zum App-Store-Eintrag. Es löst nur aus, wenn Safari selbst die getaggte Seite rendert und eine Person mit dem Banner interagiert, nicht innerhalb eines In-App-Browsers wie ihn etwa Instagram oder TikTok öffnen, und nicht automatisch beim Scannen. Es ist ein verwandtes, aber eigenständiges Puzzleteil und sollte nicht mit einer echten Universal-Link-Auflösung verwechselt werden.

Android App Links (verifiziert)

Das Android-Pendant heißt App Links, und das entscheidende Wort ist "verifiziert". Ein Intent-Filter in der App deklariert android:autoVerify="true", was (ab Android 6.0 / API 23) dazu führt, dass Android bei der Installation prüft, ob die App tatsächlich autorisiert ist, Links für die in diesem Filter genannten Hosts zu verarbeiten. Diese Prüfung funktioniert, indem eine Digital-Asset-Links-Datei unter https://ihredomain.com/.well-known/assetlinks.json abgerufen wird, ein Manifest, das "öffentlich erklärt, welche Apps berechtigt sind, Links für Ihre Domain zu verarbeiten". Erst wenn diese Datei korrekt aufgelöst wird, behandelt Android die App als verifizierten Handler für diese Domain, statt dem Nutzer einen Auswahldialog anzuzeigen oder einfach einen Browser zu öffnen.

Benutzerdefinierte URL-Schemata: die ältere, schwächere Option

Bevor es Universal Links und App Links gab, registrierten Apps ihr eigenes Schema, etwa myapp://. Der Schema-Ansatz hat zwei strukturelle Probleme, die keine der beiden Plattformen je vollständig gelöst hat. Erstens gibt es keine verlässliche Möglichkeit, im Voraus zu erkennen, ob die Ziel-App installiert ist. Ist sie es nicht, führt das Tippen auf den Link zu nichts (seit iOS 9.2 eine stille Sackgasse, ohne eingebauten Rückfallmechanismus zu einer Website oder einem Store-Eintrag). Zweitens konnte historisch jede App jedes beliebige Schema registrieren, sodass zwei unterschiedliche Apps dasselbe beanspruchen konnten, ohne jeden Eigentumsnachweis, genau die Mehrdeutigkeit, die Universal Links und App Links beseitigen sollten, indem sie den Link stattdessen an eine verifizierte Webdomain koppeln. Benutzerdefinierte Schemata tauchen in manchen Attributions-SDKs noch als Fallback-Ebene auf, sind aber 2026 nicht der Mechanismus, auf den sich eine Agentur primär verlassen sollte.

Warum sich ein QR-Scan nicht wie ein normales Tippen verhält

Das ist der Punkt, an dem Agenturen häufig stolpern, und er verdient Präzision statt eines Schulterzuckens. Universal Links und App Links sind darauf ausgelegt, zu aktivieren, wenn das Betriebssystem selbst ein Tippen auf einen qualifizierten HTTPS-Link auflöst. Ein QR-Scan durchläuft diesen Pfad nicht automatisch. Was passiert, hängt davon ab, welche App den Scan durchgeführt hat und was sie mit der decodierten URL gemacht hat.

In einem Entwickler-Forum stellte jemand genau die Frage, die sich eine Agentur vor einer Kampagne stellen sollte: Öffnet ein QR-Code, der einen Universal Link kodiert, die App tatsächlich, wenn er mit der Kamera-App gescannt wird? Die eigene Antwort nach eigenen Tests war, dass es für die eigene App und Domain funktionierte, aber weder Apple noch eine andere offizielle Quelle bestätigte den zugrunde liegenden Mechanismus. Das ist der ehrliche Stand dieser Funktion: gut belegt in der Praxis, aber keine dokumentierte Garantie von Apple oder Google. Drei Variablen entscheiden in den meisten berichteten Fällen über das Ergebnis.

Welche App den Scan durchgeführt hat. Die native Kamera-App unter iOS und der native Scanner unter Android (oft über Google Lens) übergeben eine decodierte HTTPS-URL in der Regel genauso an das Betriebssystem, wie es ein angetippter Link auch tun würde, weshalb Universal Links und App Links darüber häufig korrekt auflösen. Bei einer App eines Drittanbieters ist das nicht garantiert; manche öffnen die URL in ihrem eigenen In-App-Browser oder einer Webview, statt sie an das System zu übergeben, und eine Webview hat nicht dieselben Link-Auflösungsrechte wie ein echtes Tippen auf Betriebssystemebene.

Welcher Browser als Standard eingestellt ist. Deep-Link-Anbieter dokumentieren als bekanntes, teils ungelöstes Problem, dass bestimmte Fallback-Verhalten unter iOS nur in Safari zuverlässig funktionieren und in Chrome oder anderen Drittanbieter-Browsern auf demselben Gerät versagen. Ist der Standardbrowser einer Person nicht Safari, kann ein Link, der bei einem Nutzer korrekt auflöst, bei einem anderen auf identischer Hardware stillschweigend auf einer einfachen Webseite landen.

Angetippt versus eingefügt oder eingetippt. Deep-Linking-Plattformen warnen ausdrücklich davor, Links zu testen, indem man sie in Notizen einfügt oder direkt in die Adresszeile eines Browsers eintippt, weil das Betriebssystem das bewusst nicht als denselben Vertrauenskontext behandelt wie ein Tippen, und die App entsprechend nicht öffnet. Ein QR-Scan liegt in den meisten Fällen näher an einem Tippen als an einem Einfügen, aber die genaue interne Behandlung ist nicht veröffentlicht, weshalb das Testen auf echten Geräten mit dem tatsächlichen Scanner, den die Kampagne erwartet (native Kamera, nicht eine QR-Reader-App), hier wichtiger ist als bei den meisten anderen Funktionen.

Das praktische Fazit: Korrekt konfigurierte AASA- und assetlinks.json-Dateien sind notwendig, aber nicht ausreichend. Eine Agentur, die ein "warum öffnet das nicht die App"-Ticket bekommt, sollte zunächst fragen, mit welcher App der Kunde gescannt hat und welcher Browser als Standard eingestellt ist, bevor sie annimmt, das technische Setup der Kampagne sei defekt.

Deferred Deep Linking: Menschen weiterleiten, die die App noch nicht haben

Universal Links und App Links helfen nur, wenn die App bereits installiert ist. Ein separates Problem, für das es keine native Betriebssystemlösung gibt, ist es, jemanden ohne die App zur Installation zu bewegen und ihn dann genau auf den Inhalt zu bringen, für den er gescannt hat, statt auf einen generischen Startbildschirm. Diese Lücke nennt man Deferred Deep Linking, und um sie zu schließen, braucht es entweder ein Attributions-SDK eines Drittanbieters (Branch, AppsFlyer und Adjust sind die gängigen Namen) oder eine eigene, gleichwertige Lösung.

Der Mechanismus, den diese SDKs nutzen, ist eine Form des probabilistischen Abgleichs, manchmal auch Device Snapshotting genannt. In dem Moment, in dem jemand auf den vom QR-Code abgeleiteten Link klickt, erstellt der Server des Anbieters einen "Browser-Snapshot": Signale wie IP-Adresse, Betriebssystem, Betriebssystemversion, Gerätemodell und Bildschirmgröße, mit Zeitstempel versehen. Nach Abschluss der App-Store-Installation und dem ersten Öffnen der App erstellt das SDK einen "Geräte-Snapshot" derselben Art von Signalen und versucht, ihn mit einem kürzlichen Browser-Snapshot desselben Geräts abzugleichen. Branch, einer der größeren Anbieter in diesem Bereich, beschreibt, hunderte Millionen solcher Snapshots als Grundlage für den Abgleich zu nutzen. Das ist ein vernünftiger technischer Ansatz für ein wirklich schwieriges Problem, aber er ist probabilistisch, nicht deterministisch. Er kann sich nicht auf eine gemeinsame Kennung berufen wie ein Login; er schließt aus einer Reihe gewöhnlicher Signale auf "wahrscheinlich dasselbe Gerät".

Diese Schlussfolgerung liegt nahe an einer Richtlinie, die eine Agentur kennen sollte, bevor sie eine Kampagne darauf aufbaut. Apples App Store Review Guidelines untersagen es, Daten von einem Gerät gezielt abzuleiten, um es zu identifizieren, in den Guidelines als Fingerprinting bezeichnet, unabhängig davon, ob der Nutzer im Rahmen von App Tracking Transparency das Tracking erlaubt hat. Unabhängige akademische Forschung hat reale Belege dafür gefunden, dass Apps gemeinsame, aus Fingerprinting abgeleitete Kennungen berechnen, gerade um ATT-Beschränkungen zu umgehen, was mit ein Grund ist, warum die Regel in ihrer heutigen, expliziten Form existiert. Das bedeutet nicht, dass Deferred Deep Linking über ein seriöses SDK gegen die Regeln verstößt; etablierte Anbieter gestalten ihren Abgleich so, dass er innerhalb von Apples Richtlinien bleibt, und vermeiden es in der Regel, einen deterministischen Abgleich zu behaupten. Es bedeutet aber, dass eine Agentur die vom Anbieter angegebene Trefferquote als Best-Effort-Schätzung und nicht als Garantie behandeln sollte und einen dokumentierten Grund (in der Datenschutzerklärung und im AVV des Kunden) für den Einsatz eines Drittanbieter-Attributions-SDKs überhaupt braucht, besonders bei Kampagnen, die sich an Nutzer in der EU richten. Das umfassendere Bild zu Einwilligung und Datenerhebung, das ein Scan auslösen kann, findet sich in sind QR-Codes DSGVO-konform.

Wo die Kette tatsächlich reißt

Die meisten "die App hat sich nicht geöffnet"-Meldungen lassen sich auf eine kurze Liste von Ursachen zurückführen, ungefähr in absteigender Reihenfolge, wie häufig Agenturen in der Praxis darauf stoßen.

• Die Verifizierung wurde unter Android nie abgeschlossen. Die Datei assetlinks.json fehlt, ist fehlerhaft formatiert oder liegt am falschen Pfad, oder der Intent-Filter hat autoVerify="true" nie deklariert. Android weicht dabei still auf das Öffnen eines Browsers aus, statt einen Fehler anzuzeigen, weshalb das eine ganze Kampagne lang unbemerkt bleiben kann.
• Die AASA-Datei wird über eine Weiterleitung ausgeliefert. Apples Tooling weist ausdrücklich darauf hin, dass HTTP-Weiterleitungen bei der AASA-Antwort nicht unterstützt werden; die Datei muss direkt, mit dem korrekten Content-Type, als gültiges JSON, ohne Dateiendung, exakt unter /.well-known/apple-app-site-association ausgeliefert werden.
• Verzögerte CDN-Verbreitung unter iOS. Da Geräte die AASA-Datei seit iOS 14 über Apples CDN und nicht direkt von Ihrem Server abrufen, greift eine gerade korrigierte Datei nicht überall sofort; eine Meldung "habe es repariert, funktioniert trotzdem nicht" eine Stunde später kann schlicht daran liegen, dass der Cache erst nachzieht.
• Die frühere Browser-Entscheidung des Nutzers wirkt nach. Wenn jemand zuvor entschieden hat, eine Domain weiterhin in Safari anzuzeigen, kann iOS diese Wahl bei späteren Besuchen beibehalten, bis der Nutzer die App ausdrücklich erneut aufruft.
• Der QR-Code verweist auf eine generische Kürzungsdomain, nicht auf die eigene Domain des Kunden. Universal Links und App Links werden pro Domain verifiziert. Liegt die kodierte URL auf einer Drittanbieter-Kurzlink-Domain ohne eigene AASA- oder assetlinks.json-Datei und ohne Bezug zur App des Kunden, gibt es für keines der beiden Betriebssysteme etwas zu verifizieren, und der Besuch wird jedes Mal als gewöhnliche Web-Anfrage aufgelöst, unabhängig davon, wie gut die eigene Domain des Kunden konfiguriert ist.
• Der Standardbrowser ist nicht Safari, oder der Scan stammt von einer Drittanbieter-Scanner-App. Wie oben beschrieben: Das verändert, in welchem Vertrauenskontext das Tippen landet, und sollte ausgeschlossen werden, bevor man einen Konfigurationsfehler vermutet.

Einen QR-Code so einrichten, dass Deep Linking die beste Chance hat

Keiner der oben beschriebenen Mechanismen steckt im QR-Code selbst. Ein QR-Code kodiert immer nur eine URL; jedes hier beschriebene Verhalten kommt von dem, was hinter dieser URL liegt, und davon, wie die App konfiguriert ist. Das hat zwei praktische Konsequenzen dafür, wie eine Agentur die Kampagne aufbauen sollte.

Den Code auf eine Domain richten, die der Kunde tatsächlich besitzt und kontrolliert, idealerweise dieselbe Domain, für die die AASA- und assetlinks.json-Dateien der App bereits konfiguriert sind, statt auf eine generische Kürzungsdomain. Das ist der mit Abstand häufigste Grund, warum Deep Linking bei einer ansonsten korrekt konfigurierten App still versagt: Der QR-Code hat keinem der beiden Betriebssysteme je eine Domain gegeben, die es verifizieren konnte.

Einen dynamischen QR-Code verwenden, damit sich die Ziel-URL korrigieren lässt, ohne neu drucken zu müssen, falls sich die Verifizierung nach dem Druck als falsch konfiguriert herausstellt, näher beschrieben in dynamische vs. statische QR-Codes. Einen Tippfehler in der assetlinks.json zu entdecken, nachdem zehntausend Kassenbons gedruckt sind, ist ein deutlich kleineres Problem, wenn die Lösung eine Weiterleitungsänderung statt eines Neudrucks ist.

Ehrlich abwägen, ob die Kampagne überhaupt Deferred Deep Linking braucht. Geht es lediglich darum, einen neuen Nutzer zum richtigen App-Store-Eintrag zu bringen, ist eine einfache geräteseitige Weiterleitung (Auslesen des User-Agent-Headers und Weiterleitung von iOS zum App Store, von Android zu Google Play) einfacher, birgt kein Fingerprinting-Risiko und ist der Ansatz, der in ein QR-Code für beide App-Stores beschrieben wird. Ein vollständiges Deferred-Deep-Linking-SDK lohnt sich nur, wenn die Kampagne wirklich davon abhängt, eine brandneue Installation direkt auf einen bestimmten Inhalt zu bringen (ein konkretes Treueangebot, eine bestimmte Eventseite) statt nur auf den Startbildschirm der App, denn nur in diesem Szenario bringt der zusätzliche Aufwand, die Kosten und das Datenschutzrisiko tatsächlich einen Mehrwert.

Mit dem echten Scan-Pfad testen, den die Kampagne in der Praxis erleben wird, also der nativen Kamera-App auf einem physischen Gerät, nicht einer QR-Reader-App am Schreibtisch und nicht einem eingefügten Link. Angesichts dessen, wie stark dieser Mechanismus davon abhängt, welche App den Scan durchführt, riskiert ein Test mit irgendetwas anderem, ein Setup zu bestätigen, das für einen relevanten Teil der echten Kunden versagt.

Wo das in echten Kampagnen auftaucht

Treuepunkte-Anmeldung über Handelsverpackungen. Ein QR-Code auf einer Verpackung leitet einen bestehenden Kunden direkt in den Treuepunkte-Bereich einer App, die er bereits hat, und einen Erstnutzer stattdessen zum Store-Eintrag und anschließend zur Anmeldung.

Event-Badges und Stand-QR-Codes. Ein Teilnehmer, der die Event-App bereits installiert hat, wird direkt zu seinem Sitzungsplan oder der Seite eines bestimmten Sponsorenstands geleitet statt zu einer generischen Event-Website, während ein Erstteilnehmer zunächst im Store landet.

Restaurant-Treueprogramme auf Kassenbons. Ein auf einem Kassenbon gedruckter QR-Code führt einen bestehenden App-Nutzer direkt zu einem Bestätigungsbildschirm für gesammelte Punkte zu diesem Besuch, was nur funktioniert, wenn der QR-Code des Kassenbons auf dieselbe verifizierte Domain verweist, der die Deep-Linking-Konfiguration der App bereits vertraut.

Außenwerbe-Promocodes. Ein Plakat- oder Verkehrsmittel-QR-Code, der Menschen auf einen bestimmten Promotion-Bildschirm innerhalb einer App bringen soll, ist am stärksten auf Deferred Deep Linking angewiesen, da das Publikum größtenteils aus Menschen besteht, die der App zum ersten Mal über eine öffentliche, nicht direkt zuordenbare Platzierung begegnen, genau der Fall, für den Drittanbieter-Attributions-SDKs wie Branch und AppsFlyer gebaut sind.

Häufig gestellte Fragen

Kann ein QR-Code eine App direkt öffnen statt eines Browsers?

Ja, wenn die App bereits installiert ist und die Zieldomain korrekt konfiguriert ist, mit einer apple-app-site-association-Datei (iOS) oder einer verifizierten assetlinks.json-Datei (Android). Der QR-Code selbst enthält keine Logik; er kodiert nur eine URL, und alles, was darüber entscheidet, ob diese URL die App oder einen Browser öffnet, wird von der Konfiguration auf Betriebssystemebene dahinter bestimmt, und, weniger vorhersehbar, davon, welche Scanner-App und welchen Browser die Person verwendet hat.

Warum hat sich mein QR-Code im Browser geöffnet, obwohl die App installiert und Universal Links eingerichtet sind?

Die häufigsten Ursachen sind: Der Scan stammte von einer Drittanbieter-Scanner-App oder einem In-App-Browser statt der nativen Kamera-App, der Standardbrowser der Person ist nicht Safari, die Ziel-URL lag auf einer generischen Kürzungsdomain statt der eigenen verifizierten Domain des Kunden, oder iOS befolgt weiterhin eine frühere "immer in Safari öffnen"-Entscheidung für diese Domain. Korrekt konfigurierte Verifizierungsdateien sind notwendig, aber für sich genommen nicht ausreichend.

Was ist der Unterschied zwischen einem Universal Link und einem Deep Link?

Ein Deep Link ist das allgemeine Konzept: eine URL, die einen bestimmten Inhalt innerhalb einer App öffnet statt deren Startbildschirm. Ein Universal Link ist Apples spezifische, verifizierte Umsetzung dieses Konzepts für iOS, mit gewöhnlichen HTTPS-URLs plus einer apple-app-site-association-Datei. Das Android-Pendant heißt App Link. Benutzerdefinierte URL-Schemata sind eine ältere, nicht verifizierte Art, dieselbe grundlegende Idee umzusetzen, mit schwächeren Garantien.

Brauche ich einen Dienst wie Branch oder AppsFlyer, damit QR-Code-Deep-Linking funktioniert?

Nicht, wenn alle Scannenden die App bereits installiert haben und die eigene Domain korrekt mit Universal Links und App Links konfiguriert ist; die nativen Betriebssystemmechanismen decken diesen Fall ohne Drittanbieter-SDK ab. Ein dediziertes Attributions-SDK lohnt sich speziell für Deferred Deep Linking, also das Weiterleiten einer brandneuen Installation direkt zu einem bestimmten Inhalt statt zum Startbildschirm der App, wofür es kein natives Betriebssystem-Äquivalent gibt.

Verfolgt Deferred Deep Linking Menschen ohne Einwilligung?

Die Abgleichstechniken dieser SDKs sind probabilistisch (basierend auf Signalen wie IP-Adresse, Gerätemodell und Betriebssystemversion, nicht auf einer gemeinsamen Login-Kennung), und Apples App-Store-Richtlinien untersagen ausdrücklich, solche Signale zur Identifizierung eines Geräts als Fingerprinting zu nutzen, unabhängig vom Status der App-Tracking-Transparency-Erlaubnis. Seriöse Anbieter gestalten ihren Abgleich so, dass er innerhalb dieser Richtlinie bleibt, aber eine Agentur, die ein solches SDK einsetzt, sollte die rechtliche Grundlage dafür in der Datenschutzerklärung des Kunden dokumentieren, insbesondere bei einem EU-Publikum, statt es automatisch als einwilligungsfrei zu behandeln.

Können Android- und iOS-QR-Deep-Links dieselbe URL verwenden?

Ja. Beide Plattformen prüfen dieselbe Zieldomain unabhängig voneinander, iOS über die apple-app-site-association-Datei, Android über assetlinks.json, sodass ein einziger QR-Code und eine einzige Ziel-URL auf beiden Plattformen korrektes Deep-Linking-Verhalten auslösen können, solange beide Verifizierungsdateien korrekt auf dieser Domain gehostet werden.

Warum funktioniert derselbe QR-Code bei manchen Kunden und bei anderen nicht?

Weil das Ergebnis von Variablen abhängt, die spezifisch für das Telefon jedes einzelnen Kunden sind, nicht nur von der Konfiguration der Kampagne: welche App zum Scannen verwendet wurde, welcher Browser als Standard eingestellt ist, ob zuvor entschieden wurde, diese Domain in einem Browser statt in der App anzuzeigen, und ob sich die Link-Verifizierung des Betriebssystems auf dem jeweiligen Gerät schon verbreitet hat. Zwei Personen, die denselben Code am selben Tag scannen, können unterschiedliche Ergebnisse erhalten.

Wie teste ich, ob mein QR-Code die App korrekt öffnet?

Auf einem physischen Gerät mit der nativen Kamera-App testen, da das dem Verhalten der meisten echten Kunden am nächsten kommt, statt mit einem Desktop-QR-Reader oder einem eingefügten Link, den Betriebssysteme bewusst anders behandeln als ein Tippen. Sowohl auf einem Gerät testen, auf dem die App bereits installiert ist, als auch auf einem, auf dem sie es nicht ist, und das Ergebnis sowohl mit Safari als Standardbrowser als auch ohne unter iOS prüfen.

Die Kurzfassung

Ein QR-Code kodiert immer nur eine URL; ob diese URL eine App direkt öffnet oder im Browser landet, entscheiden Verifizierungsdateien (apple-app-site-association unter iOS, assetlinks.json unter Android) auf der Zieldomain, ob das Betriebssystem den Scan als echtes Tippen behandelt, und, für Menschen, die die App noch nicht haben, ob im Hintergrund ein Deferred-Deep-Linking-SDK einen probabilistischen Abgleich vornimmt. Den QR-Code auf eine Domain richten, die der Kunde tatsächlich kontrolliert, nicht auf eine generische Kürzungsdomain, einen dynamischen QR-Code verwenden, damit sich eine falsch konfigurierte Verifizierungsdatei ohne Neudruck korrigieren lässt, und mit der echten Kamera-App auf einem echten Gerät testen, bevor der Druckauftrag verschickt wird. Geht es nur darum, neue Nutzer zum richtigen App-Store zu bringen, reicht die einfachere geräteseitige Weiterleitung aus ein QR-Code für beide App-Stores völlig aus, ganz ohne die zusätzliche Komplexität von Deferred Deep Linking.