Tijdgebonden QR-codes: hoe een geplande QR-code werkt

Een dynamische QR-code die van bestemming wisselt is niets nieuws; agencies gebruiken die truc voortdurend om een landingspagina te vervangen zonder een poster opnieuw te laten drukken. Een tijdgebonden QR-code gaat een stap verder: hij wisselt automatisch, volgens een tijdschema, zonder dat iemand het dashboard aanraakt. Scan om 8 uur 's ochtends dezelfde gedrukte code en je komt op het ontbijtmenu terecht. Scan hem om 19 uur en je komt op het dinermenu, een happy-hour-aanbieding, of een pagina met "we zijn gesloten, hier is de boekingslink voor morgen". De code zelf verandert nooit. De regelmotor erachter doet het werk.

Dit is een echt nuttige functie voor campagnes die van nature al een ritme hebben: restaurants met een dagdelen-menu, retailpromoties die alleen zin hebben tijdens openingstijden, evenementen waarbij de fase vóór, tijdens en na de show elk een eigen landingspagina verdienen. Het is ook een van de minder goed begrepen dynamische QR-functies, want de twee vragen die iedereen als eerste stelt, welke klok het tijdschema bepaalt en wat er gebeurt met iemand die buiten het tijdvak scant, krijgen zelden een eenduidig antwoord. Dit artikel behandelt beide, plus het cacheprobleem waardoor een correct ingesteld tijdschema er ineens kapot uitziet.

Hoe een tijdgebonden QR-code precies werkt

Een tijdgebonden QR-code (ook wel "slimme" of "geplande" QR-code genoemd) is gebouwd op hetzelfde fundament als elke dynamische QR-code: de gedrukte code bevat een korte, permanente redirect-URL, en de bestemming waar die naartoe wijst wordt op het moment van scannen opgezocht op de server, niet vastgebakken in de code zelf. Bekijk het verschil tussen dat model en een statische QR-code als je eerst de basis wilt begrijpen.

Tijdgebonden regels voegen een planningslaag toe boven op die opzoekactie. In plaats van één vaste bestemming houdt het platform een kleine, geordende lijst met tijdvakken bij, elk gekoppeld aan een eigen bestemming, plus één terugvalbestemming voor alles buiten die tijdvakken. Komt er een scan binnen, dan vergelijkt de server het actuele tijdstip met de ingestelde tijdvakken en geeft de bijbehorende URL terug. Bij de slimme-QR-implementaties van aanbieders als Uniqode, QR Code Chimp en Beaconstac gebeurt die beoordeling serverside op het moment van scannen, niet door een script naar de browser van de bezoeker te sturen dat clientside beslist. Dat onderscheid is om een praktische reden belangrijk: een serverside beslissing is direct en werkt op elk apparaat en in elke browser hetzelfde, terwijl een clientside redirect afhankelijk is van JavaScript dat daadwerkelijk draait voordat de gebruiker iets ziet, wat trager en minder betrouwbaar is op een wisselvallige mobiele verbinding.

De terugvalbestemming is bij geen enkele implementatie die de moeite waard is optioneel. Elke scan die buiten alle ingestelde tijdvakken valt, moet ergens naartoe kunnen, en "nergens naartoe" is een kapotte code. Een verstandige standaard is een algemene landingspagina, een bericht als "bekijk de openingstijden van vandaag", of gewoon dezelfde content die tijdens het dichtstbijzijnde actieve tijdvak zou gelden. Het maximale aantal regels verschilt per aanbieder (Uniqode staat bijvoorbeeld maximaal elf slimme regels per code toe), dus controleer die limiet eerst als een tijdschema meer dan een handvol aparte tijdvakken nodig heeft, voordat je de campagne eromheen ontwerpt.

Een terugkerend tijdschema instellen

De meeste echte campagnes hebben geen eenmalig tijdvak nodig, maar een terugkerend tijdschema. Het standaardpatroon is een wekelijks herhalend schema: kies de dagen (maandag tot en met vrijdag, alleen zaterdag en zondag, of elke dag) en stel vervolgens een begin- en eindtijd in per tijdvak. Een restaurant kan drie terugkerende tijdvakken op dezelfde code instellen: 07:00 tot 11:00 uur voor ontbijt, 11:00 tot 16:00 uur voor lunch en 16:00 tot 22:00 uur voor diner, elk wijzend naar een eigen menupagina. Dat is precies de use case die uitgebreider wordt behandeld in de gids over QR-menu's voor restaurants, en die is de moeite van het lezen waard naast dit artikel als de campagne in de horeca speelt.

Een bar met een happy hour op vrijdag zou één smaller terugkerend tijdvak instellen, bijvoorbeeld vrijdag van 17:00 tot 19:00 uur, dat naar de promotiepagina wijst, met de terugvalbestemming naar het gewone drankenmenu voor de rest van de week. Het mechanisme is in beide gevallen identiek: meer tijdvakken betekenen simpelweg meer regels om te onderhouden, en elke regel heeft een bestemming nodig die daadwerkelijk klaarstaat voordat het tijdvak begint. Een geplande regel die om 17:00 uur afgaat naar een pagina die pas om 17:05 uur live gaat, mist compleet zijn doel.

Welke klok bepaalt het tijdschema: die van jou of die van de scanner?

Dit is de vraag waar bijna elke uitleg over tijdgebonden QR-codes over struikelt, want het eerlijke antwoord is: dat hangt af van het platform, en het ligt niet vast in een standaard. Niets in de QR-codespecificatie of in HTTP schrijft voor welke klok een geplande redirect moet gebruiken. In de praktijk koppelen de slimme-QR-implementaties die voor dit artikel zijn bekeken (Uniqode, QR Code Chimp, QR Planet) elk tijdschema aan één vaste tijdzone die wordt gekozen bij het instellen van de regel, meestal de tijdzone van de locatie of de campagne, niet de tijdzone van het toestel waarmee toevallig wordt gescand. Dat is voor een fysieke locatie ook de enige logische opzet: een restaurant in Amsterdam wil dat het lunchtijdvak om 11:00 uur Amsterdamse tijd begint, ongeacht of de scanner een local is of een toerist wiens telefoon nog op de tijdzone van thuis staat.

Het is de moeite waard om hier twee dingen uit elkaar te houden, want documentatie van aanbieders haalt ze soms door elkaar. Welke bestemming een tijdschema serveert, wordt bepaald door de ingestelde tijdzone van de locatie. Hoe het tijdstempel van een scan achteraf in je analyticsdashboard wordt gelokaliseerd, is een ander mechanisme, vaak afgeleid van het IP-adres of de gerapporteerde locatie van het scannende toestel, en dat kan best een andere lokale tijd tonen dan de tijd die de redirect bepaalde. Als een rapport een scan op een vreemd tijdstip laat zien ten opzichte van het tijdschema, komt dat meestal door de lokalisatie in de analytics, niet doordat de planningsregel iets onverwachts doet.

Voor een klant met meerdere vestigingen (een keten met winkels in New York en Londen) reist één tijdgebonden regelsjabloon niet automatisch mee over tijdzones heen. De code van elke vestiging heeft een eigen tijdzone-instelling nodig, zodat "open om 9 uur" ook echt 9 uur lokale tijd betekent in elke markt, niet 9 uur in de tijdzone waarin de regel oorspronkelijk werd aangemaakt.

Waarom een tijdschema lijkt alsof het "niet is bijgewerkt": redirect-type en caching

Een correct ingestelde tijdgebonden regel kan voor een specifieke terugkerende bezoeker toch kapot lijken, en de oorzaak ligt bijna altijd bij caching, niet bij de regelmotor. Dat is de moeite waard om op HTTP-niveau te begrijpen, want het bepaalt hoe de redirect zelf gebouwd moet worden.

HTTP kent twee veelgebruikte redirect-statuscodes met wezenlijk verschillend cachegedrag als standaard. Een 301 Moved Permanently-response is, volgens RFC 9110, standaard heuristisch cachebaar, wat betekent dat een browser hem mag onthouden en bij een volgend bezoek de server niet opnieuw hoeft te raadplegen. Een 302 Found (en de strengere variant 307 Temporary Redirect) is standaard niet cachebaar; de browser wordt geacht bij elke scan opnieuw bij de server te controleren, tenzij de response dat via cache-control-headers expliciet anders aangeeft. Dat is een hard onderscheid uit de HTTP-specificatie, geen eigenaardigheid van een specifieke aanbieder.

Het praktische gevolg voor geplande content is direct: elke redirect waarvan de bestemming op een timer moet veranderen, hoort een 302/307-achtige response te gebruiken, nooit een 301. Als een code ooit is gebouwd of eventjes is ingesteld als permanente redirect, zullen sommige browsers die eerste bestemming lokaal cachen en bij herhaalbezoek uit de cache blijven serveren, zonder rekening te houden met het feit dat de serverside regel inmiddels naar een ander tijdvak is doorgeschoven. Dat is een fout die je heel makkelijk één keer maakt, en die vervolgens vervelend is om te debuggen, omdat de code voor elke nieuwe bezoeker gewoon correct werkt en alleen "vastzit" voor mensen die hem eerder al scanden.

Caching kan ook een laag onder de browser plaatsvinden. Captive portals van openbare wifi, proxy's op providerniveau en de eigen DNS-cache van een toestel kunnen elk een eerdere response vasthouden, los van wat de originele server doet, en dat is een van de redenen waarom een tijdschema dat perfect test op een thuisverbinding zich inconsistent kan gedragen op de gastenwifi van een locatie. Geen van dit alles kan een QR-platform volledig zelf beheersen; het is een reden om een live tijdschema vanaf meer dan één netwerk te testen voordat je erop vertrouwt voor een drukoplage, en het is ook waarom redirect-snelheid de moeite waard is om apart te begrijpen, aangezien dezelfde redirect-keten die het cachegedrag bepaalt ook bepaalt hoe snel de scan wordt afgehandeld.

Wat er gebeurt buiten het geplande tijdvak

Elk tijdvak-gebaseerd schema heeft een expliciet antwoord nodig op "buiten al het bovenstaande", en dat antwoord is de terugvalbestemming die is ingesteld bij het configureren van de regels, niet standaard een dode link of een foutpagina. Wat die terugvalbestemming daadwerkelijk moet zijn, is een contentbeslissing, geen technische: een restaurant kan scans buiten de openingstijden doorsturen naar een pagina met openingstijden en een boekingslink; een evenement kan scans van vóór de deuren opengaan doorsturen naar een aftelpagina of programma, en scans na afloop naar een terugblik met hoogtepunten of aanmelding voor het volgende evenement. Het punt van dit bewust instellen is dat een QR-code die eenmaal is gedrukt en in het veld staat, op een bord, een flyer, een wagenwrap, op elk uur van de dag wordt gescand, of de campagne op dat moment "live" is of niet, en elk van die scans is iemand die de gevraagde actie heeft uitgevoerd.

Zomertijd en andere randgevallen

Plannen op basis van kloktijd loopt twee keer per jaar tegen een echt technisch randgeval aan, in regio's die zomertijd hanteren. De IANA-tijdzonedatabase (ook wel de Olson-database genoemd), de referentiedataset die de meeste software gebruikt om tijdzoneverschillen te bepalen, documenteert dat bij de overgang naar zomertijd een lokale tijd ontstaat die nooit voorkomt (02:00 tot 03:00 uur bestaat simpelweg niet op de dag dat de klok vooruit springt), terwijl bij de overgang naar wintertijd een uur juist twee keer voorkomt. Een tijdvakgrens die toevallig binnen zo'n overgang valt, is een randgeval dat in tijdzonebewuste software in het algemeen goed gedocumenteerd is, al legt geen enkele documentatie van een slimme-QR-aanbieder precies uit hoe de eigen regelmotor daarmee omgaat. De veilige aanpak is pragmatisch in plaats van slim: vermijd het zetten van een tijdvakgrens in de kleine uurtjes rond een bekende zomertijd- of wintertijddatum, en controleer een tijdschema dat zo'n overgang overlapt de eerste keer handmatig, in plaats van ervan uit te gaan dat het platform dit stilzwijgend goed afhandelt.

Is een tijdgebonden tijdschema privacyvriendelijker dan een geotargete QR-code?

Het is een terechte vraag, want geotargete QR-codes lossen een vergelijkbaar klinkend probleem op (een andere bestemming serveren afhankelijk van de context), maar dan met een andere variabele. De twee zijn onder de privacywetgeving niet gelijkwaardig. Een geotargete regel moet weten waar het scannende toestel zich bevindt, wat betekent dat locatiegegevens worden verwerkt, en locatiegegevens die aan een individu gekoppeld zijn, zijn persoonsgegevens onder de AVG, met de gebruikelijke vereisten rond een rechtsgrond en meestal toestemming tot gevolg. Een tijdgebonden regel heeft niets van dat alles nodig. De enige input is de klok van de server zelf; er wordt niets over het scannende toestel, de locatie ervan of de gebruiker gelezen of opgeslagen om te bepalen welke bestemming wordt geserveerd. Dat maakt tijdgebonden planning de eenvoudigere optie vanuit privacyoogpunt, wanneer de logica van de campagne in tijd valt uit te drukken in plaats van in locatie, en dat is vaker het geval dan agencies aannemen: een lunchmenu hoeft niet te weten waar je bent, alleen hoe laat het is. Voor campagnes die elders daadwerkelijk ook toestemmingsgedreven verwerking van persoonsgegevens nodig hebben, zie het bredere overzicht in zijn QR-codes AVG-compliant.

Waar agencies dit daadwerkelijk voor gebruiken

Dagdelen in de horeca. De duidelijkste use case: één gedrukte tafelstandaard of raamsticker, drie of vier menu's verspreid over de dag, geen herdruk nodig als de keuken van gerecht wisselt. Volledig behandeld in de gids over QR-menu's voor restaurants.

Tijdelijke retailpromoties. Een happy hour, een korting die alleen tijdens de lunch geldt, een weekendactie: de code kan tijdens het tijdvak automatisch de promotie tonen en de rest van de tijd terugvallen op de standaardprijzen of het normale assortiment, zonder dat een medewerker eraan hoeft te denken iets om te zetten.

Content door de levenscyclus van een event. Dezelfde gedrukte badge, lanyard of bewegwijzering kan vóór het openen van de deuren naar een programma vooraf wijzen, tijdens het evenement naar een live agenda of wayfinding-pagina, en achteraf naar een bedankpagina of terugblik, wat het waard is om samen te plannen met het bredere draaiboek voor evenementen en beurzen.

Schermen en digital signage. Een QR-code die op een lus of een tv-scherm wordt getoond, moet toch al rekening houden met hoeveel tijd een kijker heeft om te scannen; daar een tijdschema bovenop leggen laat dezelfde code op het scherm andere content tonen voor een ochtendslot dan voor een avondslot, wat aansluit op de tips in de post over QR-codes op scherm en tv.

Bewegwijzering buiten openingstijden. Alles wat gedrukt en in het openbaar achtergelaten wordt (een sticker op een etalage, een wagenwrap, een buitenbord) wordt op elk uur gescand, of de zaak nu open is of niet; een terugvalbestemming die daar rekening mee houdt (openingstijden, contact, volgende opening) maakt van een scan buiten openingstijden een nuttige interactie in plaats van een doodlopend pad.

Veelgestelde vragen

Kan een QR-code automatisch wisselen per tijdstip van de dag?

Ja. De bestemming van een dynamische QR-code wordt op het moment van scannen op de server bepaald, waardoor een platform meerdere bestemmingen aan één code kan koppelen en daartussen kan wisselen op basis van een ingesteld tijdschema, zonder dat de gedrukte code zelf verandert.

Welke tijdzone gebruikt een geplande QR-code: die van de telefoon van de scanner of die van de locatie?

Bij de hier besproken slimme-QR-implementaties is elke regel gekoppeld aan een tijdzone die wordt gekozen bij het instellen van het tijdschema, meestal de eigen tijdzone van de locatie of campagne, niet die van het toestel waarmee toevallig wordt gescand. Dit is een keuze van de aanbieder, niet iets dat door de QR-standaard of door HTTP wordt voorgeschreven.

Moet een tijdgebonden QR-redirect een 301 of een 302 gebruiken?

Gebruik een 302- (of 307-)achtige redirect, geen 301. Volgens RFC 9110 is een 301 standaard heuristisch cachebaar, waardoor een browser de eerste bestemming die hij zag kan onthouden en hergebruiken, waardoor een latere geplande wijziging voor die bezoeker niet lijkt door te werken. Een 302/307 wordt standaard niet gecachet, dus de browser controleert bij elke scan opnieuw bij de server.

Wat gebeurt er als iemand een geplande QR-code buiten het actieve tijdvak scant?

Die persoon wordt doorgestuurd naar de terugvalbestemming (standaardbestemming) die is ingesteld bij het configureren van het tijdschema. Elk tijdvak-gebaseerd schema heeft er een nodig; zonder terugvalbestemming heeft een scan buiten het tijdvak geen vastgestelde bestemming.

Kun je een terugkerend weekschema instellen in plaats van één eenmalig tijdvak?

Ja, dit is het standaardpatroon voor echte campagnes. Kies de dagen waarop het van toepassing is (een deel van de week of elke dag) en een begin- en eindtijd, en het platform beoordeelt dat tijdvak elke keer opnieuw wanneer het terugkeert, zonder dat je het elke week opnieuw hoeft in te stellen.

Verstoort zomertijd een geplande QR-code?

Het kan rond de twee jaarlijkse overgangsdata voor een randgeval zorgen: bij de overgang naar zomertijd wordt een uur overgeslagen dat lokaal nooit voorkomt, en bij de overgang naar wintertijd komt een uur juist twee keer voor. Een tijdvakgrens die binnen zo'n overgang valt, is de eerste keer de moeite waard om handmatig te controleren, aangezien documentatie van aanbieders zelden precies uitlegt hoe hun planner dit oplost.

Voldoet tijdgebonden QR-planning aan de AVG?

Tijdgebonden planning roept niet dezelfde vragen op als een geotargete code. Een tijdgebonden regel leest alleen de klok van de server; er worden geen persoons- of locatiegegevens van het scannende toestel verwerkt om een bestemming te kiezen, waardoor het buiten de privacyoverwegingen valt die gelden voor locatiegebaseerde personalisatie.

Kan een QR-code buiten openingstijden een "gesloten"-melding tonen?

Ja, dat is gewoon de terugvalbestemming die zijn werk doet: in plaats van scans buiten openingstijden naar een menu- of promotiepagina te sturen, wijs je de terugvalbestemming naar een pagina met openingstijden en contactgegevens, of een bericht als "we zijn terug om [tijdstip]".

Wat is het verschil met een geotargete QR-code?

Beide serveren een andere bestemming vanuit dezelfde gedrukte code, maar op basis van andere input. Een geotargete regel leest de locatie van het scannende toestel; een tijdgebonden regel leest de klok van de server. Ze zijn te combineren (een tijdschema dat alleen op één locatie geldt), maar ze lossen verschillende problemen op en hebben andere privacy-implicaties.

De korte versie

Een tijdgebonden QR-code is een dynamische code met een planningslaag erbovenop: de server vergelijkt het huidige tijdstip met een set ingestelde tijdvakken en geeft de bijbehorende bestemming terug, met een terugvalbestemming voor alles daarbuiten. Het tijdschema draait op een tijdzone die is gekozen bij het instellen, niet op de klok van het toestel van de scanner, dus campagnes met meerdere locaties hebben per locatie een eigen tijdzone-instelling nodig, niet één regel die overal wordt gekopieerd. Bouw de redirect als 302/307, niet als 301, anders zorgt de eigen caching van de browser ervoor dat een correct bijgewerkt tijdschema voor terugkerende bezoekers vastzit. Stel een echte terugvalbestemming in, controleer elke tijdvakgrens die in de buurt van een zomertijdovergang valt, en test de live code vanaf meer dan één netwerk voordat hij naar de drukker gaat. Goed uitgevoerd is dit een van de weinige QR-functies die werk uit een campagne haalt in plaats van eraan toevoegt: het menu, de promotie of de bewegwijzering verandert zichzelf, op tijd, zonder dat iemand een dashboard hoeft aan te raken.