Zeitgesteuerter QR-Code: So funktioniert der automatische Zeitplan

Ein dynamischer QR-Code, der sein Ziel wechselt, ist nichts Neues: Agenturen nutzen diesen Trick ständig, um eine Landingpage auszutauschen, ohne ein Plakat neu drucken zu müssen. Ein zeitgesteuerter QR-Code geht einen Schritt weiter: Er wechselt automatisch, nach einem festgelegten Zeitplan, ohne dass jemand im Dashboard etwas anfassen muss. Halten Sie Ihr Smartphone morgens um 8 Uhr an denselben gedruckten Code, landen Sie auf der Frühstückskarte. Scannen Sie ihn abends um 19 Uhr, landen Sie auf der Abendkarte, einem Happy-Hour-Angebot oder einer Seite mit dem Hinweis „Wir haben geschlossen, hier ist der Buchungslink für morgen". Der Code selbst bleibt immer derselbe. Die Regel-Engine dahinter erledigt die Arbeit.

Das ist ein wirklich nützliches Feature für Kampagnen, die ohnehin einem festen Rhythmus folgen: Restaurants mit tageszeitabhängigen Speisekarten, Handelsaktionen, die nur innerhalb der Öffnungszeiten Sinn ergeben, oder Events, bei denen die Phase vor der Veranstaltung, am Veranstaltungstag selbst und danach jeweils eine eigene Landingpage bekommen sollen. Gleichzeitig gehört die zeitgesteuerte Funktion zu den am häufigsten missverstandenen dynamischen QR-Features, weil die beiden Fragen, die zuerst gestellt werden, nach welcher Uhrzeit sich der Zeitplan richtet und was außerhalb des Zeitfensters passiert, selten eine klare Antwort bekommen. Dieser Beitrag beantwortet beide Fragen und geht zusätzlich auf das Caching-Problem ein, durch das ein korrekt eingerichteter Zeitplan fälschlicherweise defekt wirken kann.

Wie ein zeitgesteuerter QR-Code tatsächlich funktioniert

Ein zeitgesteuerter QR-Code (manchmal auch „intelligenter" oder „geplanter" QR-Code genannt) basiert auf demselben Prinzip wie jeder dynamische QR-Code: Der gedruckte Code enthält eine kurze, dauerhafte Weiterleitungs-URL, und das eigentliche Ziel wird erst beim Scan auf dem Server ermittelt, nicht fest im Code hinterlegt. Den Unterschied zu einem statischen QR-Code finden Sie dort, falls Sie zunächst die Grundlagen benötigen.

Zeitgesteuerte Regeln legen eine zusätzliche Zeitplan-Ebene über diesen Abruf. Statt eines einzigen festen Ziels verwaltet die Plattform eine kleine, geordnete Liste von Zeitfenstern, denen jeweils ein Ziel zugeordnet ist, plus ein Fallback-Ziel für alles außerhalb dieser Fenster. Trifft ein Scan ein, prüft der Server die aktuelle Uhrzeit gegen die konfigurierten Fenster und liefert die passende URL zurück. Bei den Smart-QR-Implementierungen von Anbietern wie Uniqode, QR Code Chimp und Beaconstac läuft diese Auswertung serverseitig zum Zeitpunkt des Scans ab, nicht über ein Skript, das an den Browser des Besuchers ausgeliefert wird und dort clientseitig entscheidet. Dieser Unterschied ist aus einem praktischen Grund wichtig: Eine serverseitige Entscheidung ist sofort da und funktioniert auf jedem Gerät und in jedem Browser gleich, während eine clientseitige Weiterleitung davon abhängt, dass JavaScript tatsächlich lädt, bevor der Nutzer überhaupt etwas sieht, was bei einer instabilen mobilen Verbindung langsamer und weniger zuverlässig ist.

Das Fallback-Ziel ist bei keiner Implementierung, die diesen Namen verdient, optional. Jeder Scan, der außerhalb aller konfigurierten Fenster landet, braucht ein Ziel, und „nirgendwohin" bedeutet ein defekter Code. Sinnvolle Standardwerte sind eine allgemeine Landingpage, ein Hinweis wie „heutige Öffnungszeiten ansehen" oder einfach derselbe Inhalt, der auch im nächstgelegenen aktiven Zeitfenster gelten würde. Wie viele Regeln möglich sind, hängt vom Anbieter ab (Uniqode etwa begrenzt einen einzelnen Code auf elf Smart-Regeln), weshalb es sich lohnt, das Limit zu prüfen, bevor eine Kampagne mit mehr als einer Handvoll unterschiedlicher Zeitfenster geplant wird.

Einen wiederkehrenden Zeitplan einrichten

Die meisten realen Kampagnen brauchen kein einmaliges Zeitfenster, sondern ein wiederkehrendes. Das Standardmuster ist ein sich wöchentlich wiederholender Zeitplan: Zunächst werden die Tage festgelegt (Montag bis Freitag, nur Samstag und Sonntag oder jeden Tag), anschließend eine Start- und Endzeit für jedes Fenster. Ein Restaurant könnte auf demselben Code drei wiederkehrende Fenster konfigurieren: 07:00 bis 11:00 Uhr für das Frühstück, 11:00 bis 16:00 Uhr für das Mittagessen und 16:00 bis 22:00 Uhr für das Abendessen, jeweils mit Verweis auf die passende Menüseite. Genau dieser Anwendungsfall wird ausführlicher im Leitfaden zum QR-Code für Speisekarten behandelt, der sich als ergänzende Lektüre lohnt, wenn es um eine Gastronomiekampagne geht.

Eine Bar, die freitags eine Happy Hour anbietet, würde ein einzelnes, enger gefasstes wiederkehrendes Fenster einrichten, etwa freitags von 17:00 bis 19:00 Uhr, mit Verweis auf die Aktionsseite, während das Fallback den Rest der Woche auf die reguläre Getränkekarte zeigt. Der Mechanismus bleibt dabei gleich: Mehr Fenster bedeuten lediglich mehr zu pflegende Regeln, und jede Regel braucht ein Ziel, das schon bereitsteht, bevor das Fenster öffnet. Eine Regel, die um 17:00 Uhr auf eine Seite verweist, die erst um 17:05 Uhr live geht, verfehlt ihren Zweck.

Nach welcher Uhr richtet sich der Zeitplan: Ihrer oder der des Scanners?

Das ist die Frage, an der fast jede Erklärung zeitgesteuerter QR-Codes scheitert, denn die ehrliche Antwort lautet: Es kommt auf die Plattform an, ein Standard schreibt hier nichts vor. Weder die QR-Code-Spezifikation noch HTTP legen fest, nach welcher Uhr sich eine zeitgesteuerte Weiterleitung richten soll. In der Praxis binden die für diesen Beitrag untersuchten Smart-QR-Implementierungen (Uniqode, QR Code Chimp, QR Planet) jeden Zeitplan an eine einzige, bei der Einrichtung der Regel festgelegte Zeitzone, in der Regel die Zeitzone des Standorts oder der Kampagne, nicht die Zeitzone des jeweils scannenden Geräts. Das ist auch die einzig sinnvolle Lösung für einen physischen Standort: Ein Restaurant in Amsterdam möchte, dass sein Mittagsfenster um 11:00 Uhr Amsterdamer Zeit beginnt, unabhängig davon, ob die scannende Person vor Ort wohnt oder ein Tourist ist, dessen Smartphone noch auf die Heimatzeitzone eingestellt ist.

An dieser Stelle lohnt es sich, zwei Dinge sauber zu trennen, da Anbieterdokumentationen sie mitunter vermischen. Welches Ziel ein Zeitplan ausliefert, bestimmt die konfigurierte Zeitzone des Standorts. Wie der Zeitstempel eines Scans anschließend im Analytics-Dashboard lokalisiert wird, ist ein anderer Mechanismus, meist abgeleitet aus der IP-Adresse oder dem gemeldeten Standort des scannenden Geräts, und kann durchaus eine andere Ortszeit anzeigen als jene, die über die Weiterleitung entschieden hat. Zeigt ein Bericht einen Scan zu einer im Vergleich zum Zeitplan ungewöhnlichen Uhrzeit an, liegt das in der Regel an der Lokalisierung in den Analysedaten und nicht an der Zeitplanregel.

Bei einem Kunden mit mehreren Standorten, etwa einer Kette mit Filialen in New York und London, lässt sich eine einzelne Zeitplan-Vorlage nicht automatisch über Zeitzonen hinweg übertragen. Jeder Standort-Code braucht eine eigene Zeitzoneneinstellung, damit „geöffnet ab 9 Uhr" in jedem Markt tatsächlich 9 Uhr Ortszeit bedeutet und nicht 9 Uhr in der Zeitzone, in der die Regel ursprünglich angelegt wurde.

Warum ein Zeitplan wie „nicht aktualisiert" wirkt: Weiterleitungstyp und Caching

Eine korrekt eingerichtete zeitgesteuerte Regel kann für einen einzelnen wiederkehrenden Besucher trotzdem defekt wirken, und die Ursache liegt so gut wie immer im Caching, nicht in der Regel-Engine. Das lohnt sich auf HTTP-Ebene zu verstehen, weil es beeinflusst, wie die Weiterleitung selbst aufgebaut sein sollte.

HTTP definiert zwei gängige Weiterleitungs-Statuscodes mit deutlich unterschiedlichem Cache-Verhalten. Eine 301 Moved Permanently-Antwort ist gemäß RFC 9110 standardmäßig heuristisch cachebar, das heißt, ein Browser darf sie sich merken und den Server bei einem späteren Besuch nicht erneut fragen. Eine 302 Found (und ihre strengere Variante 307 Temporary Redirect) ist standardmäßig nicht cachebar; der Browser soll bei jedem Aufruf erneut beim Server nachfragen, sofern die Antwort nicht ausdrücklich über Cache-Control-Header etwas anderes vorgibt. Das ist eine feste Vorgabe der HTTP-Spezifikation, keine Eigenheit einzelner Anbieter.

Die praktische Konsequenz für zeitgesteuerte Inhalte ist eindeutig: Jede Weiterleitung, deren Ziel sich nach einem Zeitplan ändern soll, sollte eine 302- oder 307-Antwort verwenden, niemals eine 301. Wurde ein Code jemals als dauerhafte Weiterleitung angelegt oder auch nur kurzzeitig so konfiguriert, speichern manche Browser dieses erste Ziel lokal und liefern es bei wiederholten Besuchen weiter aus dem Cache aus, obwohl die serverseitige Regel längst zu einem anderen Fenster gewechselt ist. Das ist ein Fehler, der leicht einmalig passiert und der sich hartnäckig hält, denn der Code funktioniert für jeden neuen Besucher korrekt und wirkt nur bei Personen „hängen geblieben", die ihn schon vorher gescannt haben.

Caching kann auch eine Ebene unterhalb des Browsers stattfinden. Captive-Portale in öffentlichen WLANs, Proxys auf Netzbetreiberebene und der eigene DNS-Cache eines Geräts können jeweils unabhängig vom Ursprungsserver an einer früheren Antwort festhalten, weshalb ein Zeitplan, der über die heimische Verbindung einwandfrei funktioniert, sich im Gäste-WLAN eines Standorts inkonsistent verhalten kann. Das lässt sich von einer QR-Plattform nicht vollständig kontrollieren, weshalb es sich lohnt, einen aktiven Zeitplan über mehr als ein Netzwerk zu testen, bevor er für einen Druckauftrag freigegeben wird. Aus demselben Grund lohnt sich auch ein eigener Blick auf die Geschwindigkeit der Weiterleitung, denn dieselbe Weiterleitungskette, die das Cache-Verhalten bestimmt, entscheidet auch darüber, wie schnell der Scan aufgelöst wird.

Was außerhalb des geplanten Zeitfensters passiert

Jeder fensterbasierte Zeitplan braucht eine explizite Antwort auf die Frage „außerhalb all dessen", und diese Antwort ist das bei der Einrichtung der Regeln festgelegte Fallback-Ziel, standardmäßig kein toter Link und keine Fehlerseite. Was dieses Fallback konkret sein sollte, ist eine inhaltliche und keine technische Entscheidung: Ein Restaurant könnte Scans außerhalb der Öffnungszeiten auf eine Seite mit Öffnungszeiten und Buchungslink leiten; ein Event könnte Scans vor Einlass auf einen Countdown oder eine Programmseite und Scans nach der Veranstaltung auf eine Highlight-Zusammenfassung oder die Anmeldung zur nächsten Veranstaltung leiten. Der Sinn einer bewussten Festlegung liegt darin, dass ein einmal gedruckter und im Feld belassener QR-Code, auf einem Schild, einem Flyer oder einer Fahrzeugfolierung, zu jeder Tages- und Nachtzeit gescannt wird, unabhängig davon, ob die Kampagne in diesem Moment gerade „live" ist, und jeder dieser Scans steht für eine Person, die genau die gewünschte Handlung ausgeführt hat.

Sommerzeit und andere Sonderfälle

Eine Zeitplanung nach Uhrzeit stößt in Regionen mit Sommerzeit zweimal im Jahr auf einen echten technischen Sonderfall. Die IANA-Zeitzonendatenbank (manchmal auch Olson-Datenbank genannt), der Referenzdatensatz, den die meiste Software zur Auflösung von Zeitzonen-Offsets nutzt, dokumentiert, dass die Umstellung auf Sommerzeit eine Ortszeit erzeugt, die schlicht nicht existiert (am Tag der Umstellung springt die Uhr etwa direkt von 02:00 auf 03:00 Uhr), während die Umstellung auf Winterzeit eine Stunde erzeugt, die doppelt vorkommt. Liegt eine Zeitfenstergrenze zufällig innerhalb einer dieser Umstellungen, handelt es sich um einen Sonderfall, der in zeitzonenbewusster Software allgemein gut dokumentiert ist, auch wenn keine Dokumentation eines Smart-QR-Anbieters genau erklärt, wie die eigene Regel-Engine damit umgeht. Der sichere Weg ist pragmatisch statt clever: Legen Sie Zeitfenstergrenzen nicht in die frühen Morgenstunden rund um ein bekanntes Umstellungsdatum, und prüfen Sie jeden Zeitplan, der eine solche Umstellung überschneidet, beim ersten Mal manuell, statt einfach anzunehmen, dass die Plattform das im Hintergrund korrekt behandelt hat.

Ist ein zeitgesteuerter Zeitplan datenschutzfreundlicher als ein geotargetierter?

Eine berechtigte Frage, denn geotargetierte QR-Codes lösen ein ähnlich klingendes Problem (je nach Kontext ein anderes Ziel ausliefern) über eine andere Variable. Datenschutzrechtlich sind die beiden nicht gleichzusetzen. Eine geotargetierte Regel muss wissen, wo sich das scannende Gerät befindet, was die Verarbeitung von Standortdaten bedeutet, und Standortdaten, die einer Person zugeordnet werden können, sind personenbezogene Daten im Sinne der DSGVO, mit den üblichen Anforderungen an eine Rechtsgrundlage und in der Regel an eine Einwilligung. Eine zeitgesteuerte Regel braucht nichts davon. Der einzige Input ist die eigene Uhr des Servers; nichts über das scannende Gerät, seinen Standort oder seine Nutzerin bzw. seinen Nutzer wird gelesen oder gespeichert, um das Ziel zu bestimmen. Das macht zeitgesteuerte Zeitpläne aus Datenschutzsicht zur einfacheren Option, immer dann, wenn sich die Logik einer Kampagne über die Zeit statt über den Standort abbilden lässt, was häufiger möglich ist, als Agenturen oft annehmen: Eine Mittagskarte muss nicht wissen, wo Sie sich befinden, sondern nur, wie spät es ist. Für Kampagnen, die an anderer Stelle tatsächlich auch eine einwilligungsbasierte Verarbeitung personenbezogener Daten benötigen, liefert Sind QR-Codes DSGVO-konform einen ausführlicheren Überblick.

Wo Agenturen das in der Praxis einsetzen

Tageszeitabhängige Gastronomie. Der klarste Anwendungsfall: ein einziger gedruckter Tischaufsteller oder Schaufensteraufkleber, drei oder vier Speisekarten über den Tag verteilt, kein Neudruck, wenn sich das Angebot der Küche ändert. Ausführlich beschrieben im Leitfaden zum QR-Code für Speisekarten.

Zeitlich begrenzte Handelsaktionen. Eine Happy Hour, ein Mittagsrabatt oder ein Wochenend-Sale: Der Code kann die Aktion automatisch während des Zeitfensters anzeigen und den Rest der Zeit zu regulären Preisen oder dem Standardkatalog zurückkehren, ohne dass jemand aus dem Team daran denken muss, etwas umzustellen.

Inhalte über den gesamten Event-Verlauf. Dasselbe gedruckte Badge, Lanyard oder Schild kann vor Einlass auf ein Vorab-Programm, während der Veranstaltung auf eine Live-Agenda oder Wegweiser-Seite und danach auf eine Dankesseite oder Zusammenfassung verweisen, was sich gut zusammen mit dem umfassenderen Leitfaden zu QR-Codes für Events und Messen planen lässt.

Bildschirm- und Digital-Signage. Ein QR-Code, der auf einem Endlos-Video oder einem Fernsehbildschirm eingeblendet wird, muss ohnehin schon berücksichtigen, wie viel Zeit Betrachtende zum Scannen haben; ein zusätzlicher Zeitplan sorgt dafür, dass derselbe Code auf dem Bildschirm morgens andere Inhalte zeigt als abends, was sich gut mit den Hinweisen im Beitrag zu QR-Codes auf Bildschirm und TV kombinieren lässt.

Beschilderung außerhalb der Öffnungszeiten. Alles, was gedruckt im öffentlichen Raum hängt (ein Aufkleber im Schaufenster, eine Fahrzeugfolierung, ein Außenschild), wird zu jeder Stunde gescannt, ob geöffnet ist oder nicht; ein Fallback-Ziel, das das berücksichtigt (Öffnungszeiten, Kontakt, nächste Öffnung), macht aus einem Scan außerhalb der Öffnungszeiten eine nützliche Interaktion statt einer Sackgasse.

Häufig gestellte Fragen

Kann sich ein QR-Code je nach Tageszeit ändern?

Ja. Das Ziel eines dynamischen QR-Codes wird beim Scan auf dem Server ermittelt. Eine Plattform kann daher mehrere Ziele mit einem Code verknüpfen und anhand eines konfigurierten Zeitplans zwischen ihnen wechseln, ohne dass sich am gedruckten Code selbst etwas ändert.

Nach welcher Zeitzone richtet sich ein zeitgesteuerter QR-Code: Smartphone oder Standort?

Bei den hier untersuchten Smart-QR-Implementierungen ist jede Regel an eine Zeitzone gebunden, die bei der Einrichtung des Zeitplans festgelegt wird, in der Regel die Zeitzone des Standorts oder der Kampagne, nicht die des jeweils scannenden Geräts. Das ist eine Design-Entscheidung der jeweiligen Anbieter, nicht durch den QR-Standard oder HTTP vorgeschrieben.

Sollte eine zeitgesteuerte QR-Weiterleitung einen 301- oder einen 302-Statuscode nutzen?

Verwenden Sie eine Weiterleitung vom Typ 302 (oder 307), keine 301. Gemäß RFC 9110 ist eine 301 standardmäßig heuristisch cachebar, sodass sich ein Browser das erste gesehene Ziel merken und wiederverwenden kann, wodurch eine spätere geplante Änderung für diesen Besucher scheinbar nicht greift. Eine 302/307 wird standardmäßig nicht gecacht, sodass der Browser bei jedem Scan erneut beim Server nachfragt.

Was passiert, wenn jemand einen zeitgesteuerten QR-Code außerhalb des aktiven Zeitfensters scannt?

Diese Person wird zum Fallback-Ziel weitergeleitet, das bei der Einrichtung des Zeitplans festgelegt wurde. Jeder fensterbasierte Zeitplan braucht ein solches Fallback; ohne es hat ein Scan außerhalb aller Fenster kein definiertes Ziel.

Lässt sich statt eines einmaligen Zeitfensters ein wiederkehrender wöchentlicher Zeitplan einrichten?

Ja, das ist das Standardmuster für reale Kampagnen. Wählen Sie die Tage aus, an denen der Zeitplan gelten soll (ein Teil der Woche oder täglich) sowie eine Start- und Endzeit, und die Plattform wertet dieses Fenster bei jeder Wiederholung neu aus, ohne dass es jede Woche neu eingerichtet werden muss.

Kann die Sommerzeitumstellung einen zeitgesteuerten QR-Code stören?

Sie kann rund um die beiden jährlichen Umstellungstermine einen Sonderfall erzeugen: Bei der Umstellung auf Sommerzeit entfällt lokal eine Stunde, bei der Umstellung auf Winterzeit kommt eine Stunde doppelt vor. Landet eine Zeitfenstergrenze innerhalb einer dieser Umstellungen, lohnt es sich, dies beim ersten Auftreten manuell zu prüfen, da Anbieterdokumentationen selten genau erklären, wie der jeweilige Scheduler damit umgeht.

Ist eine zeitgesteuerte QR-Code-Planung DSGVO-konform?

Sie wirft nicht dieselben Fragen auf wie ein geotargetierter Code. Eine zeitgesteuerte Regel liest nur die Uhr des Servers aus, es werden keine personenbezogenen Daten oder Standortdaten des scannenden Geräts verarbeitet, um ein Ziel zu bestimmen. Damit fällt sie nicht unter die datenschutzrechtlichen Überlegungen, die für standortbasierte Personalisierung gelten.

Kann ein QR-Code außerhalb der Öffnungszeiten „geschlossen" anzeigen?

Ja, das ist schlicht die Aufgabe des Fallback-Ziels: Statt Scans außerhalb der Öffnungszeiten auf eine Speisekarte oder Aktionsseite zu leiten, verweist das Fallback auf eine Seite mit Öffnungszeiten und Kontakt oder auf einen Hinweis wie „Wir sind ab [Uhrzeit] wieder da".

Worin unterscheidet sich das von einem geotargetierten QR-Code?

Beide liefern vom selben gedruckten Code aus ein unterschiedliches Ziel aus, jedoch anhand unterschiedlicher Eingaben. Eine geotargetierte Regel liest den Standort des scannenden Geräts aus, eine zeitgesteuerte Regel liest die Uhr des Servers aus. Beide lassen sich kombinieren (ein Zeitplan, der nur an einem bestimmten Standort gilt), lösen aber unterschiedliche Probleme und haben unterschiedliche datenschutzrechtliche Auswirkungen.

Kurz zusammengefasst

Ein zeitgesteuerter QR-Code ist ein dynamischer Code mit einer zusätzlichen Zeitplan-Ebene: Der Server prüft die aktuelle Uhrzeit gegen eine Reihe konfigurierter Zeitfenster und liefert das passende Ziel zurück, mit einem Fallback für alles außerhalb dieser Fenster. Der Zeitplan richtet sich nach der bei der Einrichtung festgelegten Zeitzone, nicht nach der Uhr des scannenden Geräts, weshalb Kampagnen mit mehreren Standorten eine Zeitzone pro Standort brauchen und nicht eine einzige, überall kopierte Regel. Bauen Sie die Weiterleitung als 302/307 auf, nicht als 301, sonst lässt das Caching des Browsers einen korrekt aktualisierten Zeitplan für wiederkehrende Besucher hängen wirken. Legen Sie ein echtes Fallback-Ziel fest, prüfen Sie jede Zeitfenstergrenze, die in die Nähe einer Sommerzeitumstellung fällt, und testen Sie den aktiven Code über mehr als ein Netzwerk, bevor er in den Druck geht. Richtig umgesetzt ist das eines der wenigen QR-Features, das einer Kampagne Arbeit abnimmt statt hinzuzufügen: Die Speisekarte, die Aktion oder die Beschilderung wechselt sich pünktlich von selbst, ohne dass jemand ein Dashboard anfasst.