Dynamiska QR-koder behöver inte skicka alla skanningar till samma URL. Villkorlig routning — även kallad scan-routning eller regelbaserad omdirigering — låter dig peka olika målgrupper mot olika destinationer med en enda tryckt kod. Om du någonsin önskat att din lunchflygare kunde omdirigera till din meny, din kväällspublik till ett bokningsformulär och dina internationella besökare till en lokaliserad sida, är det exakt vad den här funktionen möjliggör.
Här är hur de mest användbara routningscenarierna fungerar, vad du måste ställa in först och var människor ofta gör misstag.
Vad "Routning" egentligen betyder i ett dynamiskt QR-sammanhang
När en skanner träffar en dynamisk QR-kod lagras kodens mål-URL på en server — inte inbakad i själva koden. Den server-sidiga omdirigeringen är där routningslogiken finns. Istället för en enkel omdirigering ("alla skanningar → URL A") lägger du till villkorliga regler:
- Om villkoret är uppfyllt → skicka till URL A
- Annars → skicka till URL B (reservfallet)
De flesta plattformar som stödjer detta (ibland kallas "multi-URL QR-koder" eller "smarta omdirigerings-QR-koder") låter dig skikta två eller tre regler. Reserv-URL:en är alltid obligatorisk. Förståelsen för skillnaden mellan statisk och dynamisk funktion är grundläggande här — den kompletta förklaringen av statiska vs dynamiska QR-koder förklarar varför omdirigeringen finns på en server och varför det spelar roll för routning.
Scenario 1: Tidsbaserad routning
Användningsfall: Ett kafé skriver ut en QR-kod på ett bordstält. Morgonskanningar visar frukostmenyn; eftermiddagsskanningar visar lunchmenyn; kväällsskanningar visar dryckeslistan.
Hur du ställer in det:
- Skapa tre mål-URL:er (eller webbsidssektioner) för varje menytid.
- Lägg till tidsregler i UTC — kom ihåg att räkna in din lokala tidszonförskjutning.
- Ställ in det vanligaste användningsfallet som reserv om en skanning träffar utanför definierade timmar.
Där det går fel: Team glömmer att skanningsstid registreras på servern i UTC som standard. En regel inställd på "11:00–14:00" utan tidszoninställning aktiveras vid fel timmar för skanningar i din stad. Bekräfta alltid hur din plattform hanterar tidszoner innan du skriver ut.
Andra praktiska exempel:
- Evenemangsplatser som routar till ett förshow-program före 19:00, sedan aftershow-merch efter 21:00
- Återförsäljare som visar en flashsale-landningssida endast under definierade kampanjfönster
- Gymmen som skickar klassscheman på vardagar och en helgschema på lördagar/söndagar
Scenario 2: Land- eller språkbaserad routning
Användningsfall: En produktlåda skickas till 12 länder. En QR-kod routar engelsktalande marknader till en engelsk supportssida, fransktalande marknader till den franska versionen och alla andra till en språkväljare.
Hur du ställer in det:
- Routningsmotorn detekterar scannerens land via IP-geoplacering.
- Mappa specifika landskoder (US, GB, CA → engelsk sida; FR, BE, CH → fransk sida; DE → tysk sida).
- Ställ in språkväljarsidan som global reserv.
Varningar att dokumentera internt:
- IP-geoplacering är korrekt på landsnivå cirka 95–99% av tiden, men VPN-användare routas felaktigt. Detta är acceptabelt för de flesta användningsfall.
- Routra inte efter språkpreferens som upptäckts från webbläsaren — QR-scanningsförfrågningar skickar inte tillförlitligt Accept-Language-headers genom alla appar.
- Om din plattform tar betalt per mål-URL eller per regel, gruppera länder tillsammans istället för att lista 40 enskilda länder.
Scenario 3: Enhetstypsbaserad routning
Användningsfall: En mjukvaruföretags tryckta annons körs i både en branidtidskrift och ett utvecklarnewsletter. iOS-användare går till App Store-listningen; Android-användare går till Google Play; skrivbordsskanningar (någon som fotograferar annonsen på sin laptopkamera) går till webbappen.
Hur du ställer in det:
- Plattformen läser User-Agent-strängen från skanningsförfrågan.
- Routra
iOS→ App Store-URL;Android→ Play Store-URL;Other/Desktop→ webbapp.
Varför det spelar roll: App Store-omdirigeringssidor är notoriskt dåliga på att automatdetektera plattform. Att skicka Android-användare till en App Store-länk producerar ett fel och dödar konverteringar. Enhetsroutning löser detta rent utan att kräva en anpassad smart-banner-implementering på din webbplats.
Scenario 4: Kombinera regler (multi-villkor-routning)
Vissa plattformar låter dig stapla regler — till exempel land OCH enhet. En vanlig verklig setup:
| Prioritet | Villkor | Destination |
|---|---|---|
| 1 | Land = SE + Enhet = iOS | Svensk App Store |
| 2 | Land = SE + Enhet = Android | Svensk Play Store |
| 3 | Land = DE | Tysk landningssida |
| 4 | Reserv | Global landningssida |
Regler utvärderas uppifrån och ned, så ordningen spelar roll. Lägg de mest specifika villkoren först, breda geografiska regler i mitten och reservfallet sist. Det är lätt att sortera fel — testa alltid varje villkor med en verklig enhet och, om möjligt, en VPN inställd på det relevanta landet innan du skriver ut.
Vad du kan spåra per rutt
Routning är bara halva bilden. Varje mål-URL bör innehålla UTM-parametrar så att du kan separera prestanda efter målgruppssegment i din analytiksplattform. En skanning routad till den franska sidan bör skicka ?utm_source=qr&utm_medium=tryckt&utm_content=sv så att du kan särskilja den från en generisk skanning.
För en djupare titt på vilka mätvärden du bör hämta från din QR-instrumentpanel, guiden till QR-kodanalys som faktiskt driver beslut täcker spårning från skanning till konvertering i detalj.
Du kan också använda routningsloggar för att identifiera oväntade trafikmönster — om 40% av skannningarna på en endast UK-tryck aktiverar "icke-UK-reserv", behöver din geoplaceringssetup kontrolleras innan du skalningsutgifter.
Plattformschecklista innan du är engagerad i routning
Inte alla dynamiska QR-plattformar stödjer villkorlig routning. Innan du väljer en, bekräfta:
- Tidsbaserade regler med tidszonval (inte bara UTC)
- Land-/regionsnivå geoplaceringsroutning
- Enhetstypsdetektering (iOS / Android / Other minimum)
- Regelstackning eller multi-villkors-stöd
- Per-regel-skanningsanalytik, inte bara totaler
- Reserv-URL är alltid obligatorisk och redigerbar
Om ditt nuvarande verktyg saknar dessa funktioner, (/sv/) stödjer villkorlig routning över tid, land och enhet med per-regel-analytik inkluderat.
Viktiga takeaways
- Routning skickar olika skanningar till olika URL:er från en enda tryckt QR-kod, med server-sid omdirigerings logik.
- Tidsbaserad routning kräver korrekt tidszonkonfiguration — UTC-standardvärden kommer att missfungera på de flesta marknader.
- Landbaserad routning använder IP-geoplacering, som är tillförlitlig på landsnivå men misslyckas för VPN-användare.
- Enhetsroutning är det renaste lösningen för appnedladdningskampanjer som måste separera iOS och Android-destinationer.
- Lägg alltid UTM-parametrar till varje routad URL så att nedströmanalytik förblir segmenterad.
- Testa varje routningsregel med en verklig enhet (och helst en VPN) innan du skriver ut i stor skala.