Ein Deeplink-QR-Code öffnet einen bestimmten Bildschirm in einer App statt einer Website. Ob er funktioniert, entscheidet nicht der Code, sondern was passiert, wenn die scannende Person die App gar nicht hat.
Zwei Mechanismen, und nur einer scheitert würdevoll. Ein https-Link mit hinterlegter Zuordnung öffnet die App, wenn sie da ist, und sonst die Website. Ein eigenes Schema öffnet die App, wenn sie da ist, und sonst gar nichts — ohne Fehlermeldung.
Ein Code kann nichts erkennen. Er ist gedruckte Tinte. Alles, was nach „prüfen, ob die App installiert ist“ aussieht, passiert auf dem Telefon oder auf Ihrem Server, nie im Code.
Für den deutschen Markt kommt hinzu, dass die Rückfallseite selbst brauchbar sein sollte: Wer die App nicht installieren will — und das sind hierzulande auffallend viele — soll auf der Website erledigen können, weswegen er gescannt hat.
Vom Produkt in die Registrierung, in die Anleitung, in die Nachbestellung — ohne dass jemand durch ein Menü sucht.
Der Code auf dem Anschreiben führt in den Schritt, der als Nächstes dran ist, statt auf eine Startseite.
Mit Parametern im Link, die Ihre App auswertet. Denken Sie daran, dass diese Parameter öffentlich sind.
Eigene Schemata scheitern lautlos. Ohne installierte App passiert nichts Sichtbares. Der Nutzer denkt, der Code sei kaputt.
Die Zuordnungsdatei muss vor dem Druck live sein. Sie wird beim Installieren der App abgerufen. Wer sie nachreicht, erreicht damit die bereits installierte Basis nicht zuverlässig.
Nichts überlebt eine deinstallierte oder eingestellte App. Der gedruckte Code bleibt, die App nicht unbedingt. Ein https-Link fällt wenigstens auf die Website zurück.
Die Parameter sind öffentlich. Was im Link steht, liest jeder Scanner. Kein Platz für Gutscheincodes, die einmalig sein sollen.
Lange parametrisierte Links machen dichte Codes: mit dem Encoder dieser Seite gemessen ist eine Adresse mit 40 Zeichen 29 Module breit und eine mit 98 Zeichen 41 bei gleicher Fehlerkorrektur.