Dynamische QR-codes hoeven niet elke scanner naar dezelfde URL te sturen. Voorwaardelijke routering — ook wel scan-routering of op regels gebaseerde omleidingen genoemd — laat je verschillende doelgroepen naar verschillende bestemmingen sturen met één gedrukte code. Als je ooit hebt gewenst dat je lunchflyer naar je menukaart kon linken, je avondpubliek naar een reserveringsformulier, en je internationale bezoekers naar een gelokaliseerde pagina, dat is precies wat deze functie mogelijk maakt.
Hier zie je hoe de meest bruikbare routeringsscenario's werken, wat je eerst moet instellen, en waar mensen veelal de mist in gaan.
Wat 'routering' in dynamische QR-context echt betekent
Wanneer een scanner een dynamische QR-code scant, wordt de doelURL van de code op een server opgeslagen — niet ingebakken in de code zelf. Die server-side omleiding is waar de routeringslogica leeft. In plaats van een eenvoudige omleiding ("alle scans → URL A"), voeg je voorwaardelijke regels toe:
- Als voorwaarde is vervuld → stuur naar URL A
- Anders → stuur naar URL B (de fallback)
De meeste platforms die dit ondersteunen (soms "multi-URL QR-codes" of "smart-redirect QR-codes" genoemd) laten je twee of drie regels stapelen. De fallback-URL is altijd verplicht. Het verschil tussen statisch en dynamisch gedrag begrijpen is fundamenteel — de volledige uitleg van statische versus dynamische QR-codes legt uit waarom de omleiding op een server leeft en waarom dat voor routering belangrijk is.
Scenario 1: Routering op basis van tijd van de dag
Gebruikscase: Een café drukt één QR-code op een tafelkaartje. Scanners 's ochtends zien het ontbijtmenu; 's middags het lunchmenu; 's avonds de drankkaart.
Zo stel je het in:
- Maak drie doel-URL's (of pagina-onderdelen) voor elke menuperiode.
- Voeg tijdregels in UTC toe — vergeet niet je lokale tijdzoneverschil in te kalkuleren.
- Stel het meest voorkomende geval als fallback in voor het geval een scanner buiten de gedefinieerde uren terechtkomt.
Waar het fout gaat: Teams vergeten dat scantijd standaard server-opgeslagen wordt in UTC. Een regel ingesteld voor "11:00–14:00" zonder tijdzone-instelling zal op het verkeerde moment afvuren voor scanners in jouw stad. Bevestig altijd de tijdzoneafhandeling van je platform voordat je afdrukt.
Andere praktische voorbeelden:
- Evenementenvenues die vóór 19:00 uur naar een voorprogramma linken, daarna naar merchandise na 21:00 uur
- Retailers die een flash-sale-landingspagina alleen tijdens gedefinieerde promotiefensters tonen
- Gyms die doordeweeks lesschema's sturen en in het weekend een weekendrooster
Scenario 2: Routering op land of taal
Gebruikscase: Een productdoos wordt naar 12 landen verzonden. Één QR-code routeert Engelstalige markten naar een Engelse ondersteuningspagina, Franstalige markten naar de Franse versie, en iedereen anders naar een taalselector.
Zo stel je het in:
- De routeringsengine detecteert het land van de scanner via IP-geolocatie.
- Wijs specifieke landcodes toe (VS, GB, CA → Engelse pagina; FR, BE, CH → Franse pagina; DE → Duitse pagina).
- Stel de taal-selecterpagina als globale fallback in.
Voorbehouden om intern vast te leggen:
- IP-geolocatie is op landniveau ongeveer 95–99% nauwkeurig, maar VPN-gebruikers zullen verkeerd routeren. Dit is voor de meeste use cases aanvaardbaar.
- Routeer niet op taalvoorkeur gedetecteerd uit de browser — QR-scan-verzoeken geven niet betrouwbaar Accept-Language-headers door via alle apps.
- Als je platform per doel-URL of per regel betaalt, groepeer landen samen in plaats van 40 individuele landen op te sommen.
Scenario 3: Routering op apparaattype
Gebruikscase: Een advertentie van een softwarebedrijf verschijnt in zowel een vakblad als een ontwikkelaarsnieuwsbrief. iOS-gebruikers gaan naar de App Store; Android-gebruikers naar Google Play; desktop-scanners (iemand die de advertentie fotografeert met hun laptopkamera) naar de web-app.
Zo stel je het in:
- Het platform leest de User-Agent-string uit het scan-verzoek.
- Routeer
iOS→ App Store-URL;Android→ Play Store-URL;Other/Desktop→ web-app.
Waarom dit belangrijk is: App Store-omleidingspagina's zijn beroemd om hun slechte auto-detectie van platform. Android-gebruikers naar een App Store-link sturen geeft een fout en doodt conversies. Apparaatrouting lost dit schoon op zonder dat je een aangepaste smart-banner-implementatie op je website nodig hebt.
Scenario 4: Regels combineren (routering met meerdere voorwaarden)
Sommige platforms laten je regels stapelen — bijvoorbeeld land EN apparaat. Een veelvoorkomende real-world-instelling:
| Prioriteit | Voorwaarde | Bestemming |
|---|---|---|
| 1 | Land = NL + Apparaat = iOS | NL App Store |
| 2 | Land = NL + Apparaat = Android | NL Play Store |
| 3 | Land = DE | Duitse landingspagina |
| 4 | Fallback | Globale landingspagina |
Regels worden van boven naar beneden geëvalueerd, dus volgorde is belangrijk. Plaats eerst de meest specifieke voorwaarden, brede geografische regels in het midden, en de fallback als laatste. Dit is makkelijk verkeerd in te delen — test altijd elke voorwaarde met een echt apparaat en, indien mogelijk, een VPN ingesteld op het relevante land voordat je afdrukt.
Wat je per route kunt volgen
Routering is maar half het verhaal. Elke doel-URL moet UTM-parameters bevatten zodat je prestaties per doelgroepsegment in je analytics-platform kunt scheiden. Een scan gerouteerd naar de Franse pagina moet ?utm_source=qr&utm_medium=print&utm_content=fr afvuren zodat je hem kunt onderscheiden van een generieke scan.
Voor een diepgaander kijkje naar welke statistieken je uit je QR-dashboard haalt, behandelt de gids naar QR-code-analytics die werkelijk beslissingen sturen scan-naar-conversie-tracking in detail.
Je kunt routeringslogboeken ook gebruiken om onverwachte verkeerspatronen op te sporen — als 40% van de scans op een UK-only-drukwerk de "niet-UK fallback" triggert, moet je geolocatie-instelling worden gecontroleerd voordat je spend opschroeft.
Platform-checklist voordat je je aan routering verbindt
Niet elk dynamisch QR-platform ondersteunt voorwaardelijke routering. Bevestig voordat je er een kiest:
- Regels op basis van tijd van de dag met tijdzoneselectie (niet alleen UTC)
- Routering op land-/reginiveau via geolocatie
- Apparaattype-detectie (minimaal iOS / Android / Other)
- Regelstapeling of ondersteuning van meerdere voorwaarden
- Scan-analytics per regel, niet alleen totaalaggregaten
- Fallback-URL is altijd verplicht en bewerkbaar
Als je huidige tool dit mist, Super QR Code Generator ondersteunt voorwaardelijke routering over tijd, land en apparaat met analytics per regel inbegrepen.
Kernpunten
- Routering stuurt verschillende scanners naar verschillende URL's vanaf één gedrukte QR-code, met behulp van server-side omleidingslogica.
- Routering op basis van tijd van de dag vereist correcte tijdzoneconfigureratie — UTC-standaardinstellingen zullen fout afvuren in de meeste markten.
- Landenroutering gebruikt IP-geolocatie, die betrouwbaar op landniveau werkt maar faalt voor VPN-gebruikers.
- Apparaatrouting is de schoonste oplossing voor app-download-campagnes die iOS- en Android-bestemmingen moeten scheiden.
- Voeg altijd UTM-parameters toe aan elke gerouteerde URL zodat downstream-analytics gesegmenteerd blijven.
- Test elke routeringsregel met een echt apparaat (en idealiter een VPN) voordat je op grote schaal afdrukt.