I QR code dinamici non devono inviare ogni lettore allo stesso URL. Il routing condizionale — detto anche instradamento scansione o redirect basato su regole — ti permette di indirizzare audience diverse verso destinazioni diverse utilizzando un unico codice stampato. Se hai mai desiderato che il volantino di pranzo potesse reindirizzare verso il tuo menu, la folla serale verso un modulo di prenotazione e i tuoi visitatori internazionali verso una pagina localizzata, questa è esattamente la funzionalità che lo rende possibile.
Ecco come funzionano gli scenari di routing più utili, cosa configurare per primo e dove le persone commettono errori comuni.
Cosa Significa "Routing" nel Contesto dei QR Code Dinamici
Quando uno scanner legge un QR code dinamico, l'URL di destinazione del codice è memorizzato su un server — non è inciso nel codice stesso. È in quel redirect lato server che risiede la logica di routing. Invece di un redirect semplice ("tutte le scansioni → URL A"), aggiungi regole condizionali:
- Se la condizione è soddisfatta → invia a URL A
- Altrimenti → invia a URL B (il fallback)
La maggior parte delle piattaforme che supportano questa funzione (talvolta chiamate "QR code multi-URL" o "QR code smart redirect") ti permette di stratificare due o tre regole. L'URL di fallback è sempre obbligatorio. Comprendere la differenza tra il comportamento statico e dinamico è fondamentale qui — la spiegazione completa dei QR code statici vs dinamici spiega perché il redirect risiede su un server e perché questo è importante per il routing.
Scenario 1: Routing in Base all'Orario del Giorno
Caso d'uso: Un caffè stampa un QR code su un cartello da tavolo. I lettori mattutini vedono il menu colazione; i lettori pomeridiani vedono il menu pranzo; i lettori serali vedono la lista delle bevande.
Come configurarlo:
- Crea tre URL di destinazione (o sezioni di pagina) per ogni fascia oraria.
- Aggiungi regole orarie in UTC — ricordati di tenere conto dell'offset del fuso orario locale.
- Imposta il caso d'uso più comune come fallback nel caso uno scanner colpisca fuori dagli orari definiti.
Dove va storto: I team dimenticano che il tempo di scansione è registrato dal server in UTC per impostazione predefinita. Una regola impostata per "11:00–14:00" senza un'impostazione di fuso orario si attiva agli orari sbagliati per i lettori nella tua città. Conferma sempre come la tua piattaforma gestisce i fusi orari prima di stampare.
Altri esempi pratici:
- Sedi eventi che reindirizzano verso un programma pre-spettacolo prima delle 19:00, poi verso il merchandise post-spettacolo dopo le 21:00
- Rivenditori che mostrano una pagina di landing con saldi lampo solo durante finestre promozionali definite
- Palestre che inviano gli orari delle lezioni nei giorni feriali e un orario modificato nel fine settimana
Scenario 2: Routing per Paese o Lingua
Caso d'uso: Una scatola di prodotto viene spedita in 12 paesi. Un QR code reindirizza i mercati anglofoni verso una pagina di supporto in inglese, i mercati francofoni verso la versione francese e tutti gli altri verso un selettore di lingua.
Come configurarlo:
- Il motore di routing rileva il paese dello scanner tramite geolocalizzazione IP.
- Mappa codici paese specifici (US, GB, CA → pagina inglese; FR, BE, CH → pagina francese; DE → pagina tedesca).
- Imposta la pagina del selettore di lingua come fallback globale.
Avvertenze da documentare internamente:
- La geolocalizzazione IP è accurata a livello di paese circa il 95–99% delle volte, ma gli utenti VPN verranno instradadati male. Questo è accettabile per la maggior parte dei casi d'uso.
- Non instradare in base alle preferenze di lingua rilevate dal browser — le richieste di scansione QR non passano affidabilmente header Accept-Language attraverso tutte le app.
- Se la tua piattaforma addebita per URL di destinazione o per regola, raggruppa i paesi insieme piuttosto che elencare 40 paesi individuali.
Scenario 3: Routing per Tipo di Dispositivo
Caso d'uso: L'annuncio stampa di un'azienda di software esce sia su una rivista specializzata che su una newsletter per sviluppatori. Gli utenti iOS vanno al listing dell'App Store; gli utenti Android vanno a Google Play; i lettori desktop (qualcuno che fotografa l'annuncio con la fotocamera del portatile) vanno all'app web.
Come configurarlo:
- La piattaforma legge la stringa User-Agent dalla richiesta di scansione.
- Instrada
iOS→ URL App Store;Android→ URL Play Store;Other/Desktop→ app web.
Perché questo è importante: Le pagine di reindirizzamento dell'App Store sono notoriamente cattive nel rilevamento automatico della piattaforma. Inviare utenti Android a un link dell'App Store produce un errore e uccide le conversioni. Il routing del dispositivo risolve questo in modo pulito senza richiedere un'implementazione personalizzata di smart banner sul tuo sito web.
Scenario 4: Combinare Regole (Routing Multi-Condizione)
Alcune piattaforme ti permettono di stratificare regole — ad esempio, paese E dispositivo. Una configurazione comune nel mondo reale:
| Priorità | Condizione | Destinazione |
|---|---|---|
| 1 | Paese = US + Dispositivo = iOS | US App Store |
| 2 | Paese = US + Dispositivo = Android | US Play Store |
| 3 | Paese = DE | Pagina di landing tedesca |
| 4 | Fallback | Pagina di landing globale |
Le regole vengono valutate dall'alto verso il basso, quindi l'ordine è importante. Metti le condizioni più specifiche per prime, le regole geografiche ampie nel mezzo e il fallback per ultimo. È facile sbagliare la sequenza — testa sempre ogni condizione con un dispositivo reale e, se possibile, con una VPN impostata sul paese rilevante prima di andare in stampa.
Cosa Puoi Tracciare Per Ogni Route
Il routing è solo metà della storia. Ogni URL di destinazione dovrebbe portare parametri UTM in modo da poter separare le prestazioni per segmento di audience nel tuo strumento di analytics. Una scansione instaurata verso la pagina francese dovrebbe attivare ?utm_source=qr&utm_medium=print&utm_content=fr in modo da poterla distinguere da una scansione generica.
Per uno sguardo più approfondito a quali metriche estrarre dalla tua dashboard QR, la guida alle analytics dei QR code che guidano davvero le decisioni copre il tracciamento da scansione a conversione nel dettaglio.
Puoi anche usare i registri di routing per identificare modelli di traffico inaspettati — se il 40% delle scansioni su un'esecuzione stampata solo nel Regno Unito sta attivando il "fallback non-UK", la configurazione della geolocalizzazione ha bisogno di un controllo prima di scalare le spese.
Checklist della Piattaforma Prima di Impegnarti nel Routing
Non ogni piattaforma QR dinamica supporta il routing condizionale. Prima di sceglierne una, conferma:
- Regole in base all'orario del giorno con selezione del fuso orario (non solo UTC)
- Routing geolocalizzazione a livello di paese/regione
- Rilevamento del tipo di dispositivo (iOS / Android / Altro minimo)
- Supporto per stratificazione di regole o multi-condizione
- Analytics per regola, non solo totali aggregati
- L'URL di fallback è sempre obbligatorio e modificabile
Se il tuo strumento attuale manca di questi, il Super QR Code Generator supporta il routing condizionale su tempo, paese e dispositivo con analytics per regola incluse.
Punti Chiave da Ricordare
- Il routing invia scanner diversi a URL diversi da un singolo QR code stampato, utilizzando la logica di redirect lato server.
- Il routing in base all'orario del giorno richiede una corretta configurazione del fuso orario — i default UTC si attiveranno negli orari sbagliati nella maggior parte dei mercati.
- Il routing per paese utilizza la geolocalizzazione IP, che è affidabile a livello di paese ma non funziona per gli utenti VPN.
- Il routing del dispositivo è la soluzione più pulita per le campagne di download di app che devono separare le destinazioni iOS e Android.
- Aggiungi sempre parametri UTM a ogni URL instaurato in modo che l'analytics a valle rimanga segmentata.
- Testa ogni regola di routing con un dispositivo reale (e idealmente una VPN) prima di stampare su larga scala.
