Un QR code, destinazioni diverse: regole di reindirizzamento e test A/B

Un QR code stampato ha un solo motivo, ma le persone che lo scansionano non sono un pubblico unico. Metà tiene un iPhone, metà un Android. Alcuni leggono il tedesco, altri l’italiano. Chi scansiona il poster del tuo bar alle 9 vuole la colazione; alle 21 vuole la carta dei cocktail. Le regole di reindirizzamento permettono a un solo codice di rispondere in modo diverso, deciso nel momento della scansione.

Come funziona la valutazione

Le regole sono un breve elenco ordinato. A ogni scansione vengono controllate dall’alto in basso e vince la prima che corrisponde: le successive non vengono nemmeno considerate. Se nessuna corrisponde, decide un’eventuale divisione A/B pesata. Se non c’è neanche quella, il visitatore va alla destinazione predefinita del codice.

Quell’ordine è tutto il modello mentale: una regola ampia messa sopra una specifica se la mangia. «Tutto il mobile → pagina dell’app» sopra «Android → Play Store» significa che la regola Play Store non scatta mai. Il caso specifico in alto, la regola generale in fondo.

Le tre condizioni

Dispositivo

Corrispondenza su sistema operativo (iOS, Android, Windows, macOS…) e/o tipo di dispositivo (mobile, tablet, desktop). L’uso ovvio è il download di app — per la sola divisione tra store esiste però un tipo di codice App Store dedicato, che instrada iOS e Android automaticamente senza regole.

La regola sul dispositivo diventa utile in modo più sottile: mandare le scansioni da desktop (qualcuno ha fotografato il codice e l’ha aperto dopo sul portatile) a una pagina completa e quelle da mobile a una leggera. Oppure i tablet a un menù pensato per schermi grandi.

Un dettaglio: una regola sul dispositivo senza sistema né tipo selezionati non corrisponde a nulla. Vuoto significa «nessun filtro», non «tutto».

Lingua

Corrispondenza sulla preferenza di lingua del browser, con codici a due lettere. Una scansione il cui browser chiede de-AT corrisponde a una regola per de. Per un prodotto multilingue è la regola più utile in assoluto: un codice sulla confezione e ogni cliente arriva su una documentazione che sa leggere.

La lingua non è la posizione. Riflette come è configurato il telefono, non dove si trova. Una turista ucraina a Roma ottiene la pagina in ucraino dal codice del museo: spesso esattamente ciò che vuoi, e molto diverso da quel che farebbe una regola per paese.

Ora

Corrispondenza su giorni della settimana e una fascia oraria. La fascia è semiaperta — 11 a 15 copre dalle 11:00 fino alle 15:00 escluse — così fasce consecutive si scrivono senza sovrapposizioni.

Le ore sono in UTC. È la trappola di tutta la funzione. Se il tuo bar è a Milano e vuoi il menù di pranzo dalle 11:00 alle 15:00 locali, d’estate configuri 09:00–13:00 UTC e d’inverno 10:00–14:00. L’ora legale sposterà la tua regola due volte l’anno in silenzio: un promemoria in calendario è giustificato. I giorni vanno da 0 per domenica a 6 per sabato, anch’essi in UTC: vicino a mezzanotte il giorno UTC non è il tuo giorno locale.

Test A/B

Invece di instradare per attributo puoi dividere il traffico per peso tra un massimo di dieci destinazioni. I pesi sono relativi, non percentuali: 3 e 1 manda circa tre quarti da un lato. Due destinazioni a 50 e 50 sono il semplice lancio della monetina.

Due limiti onesti da tenere presenti in fase di progetto:

• La divisione non è persistente. Ogni scansione è estratta in modo indipendente, quindi la stessa persona che scansiona due volte può vedere entrambe le varianti. Per un test sul titolo va bene; per qualsiasi flusso in cui chi torna deve ritrovare la stessa esperienza — un checkout, un modulo a metà — no.
• La misurazione tocca a te. Gli analytics delle scansioni dicono quante persone hanno scansionato in totale, non su quale variante sono finite. Dai a ogni variante i suoi parametri UTM o URL distinti e leggi la conversione nel tuo strumento.

Poiché il motivo stampato non cambia mai, il test si può fare anche lentamente: due settimane tutto sulla variante A, poi due settimane sulla B. Meno parti in movimento e nessun problema di persistenza; solo più lento e sensibile alla stagionalità.

A cosa si applicano le regole

Le regole vengono valutate per i codici URL e PDF, i due tipi in cui «la destinazione» è un link che può plausibilmente cambiare per visitatore. Un codice Wi-Fi o una vCard risolvono sulla propria pagina e non hanno nulla da instradare. Se serve un comportamento condizionale, costruisci il codice come tipo URL verso pagine che controlli.

I limiti sono abbastanza generosi da non pensarci: fino a 20 regole e 10 destinazioni A/B per codice. Le regole di reindirizzamento sono una funzione dei piani Pro e Business.

Ricette che si usano davvero

• Tavolino del ristorante: regole orarie per colazione, pranzo e cena, con la carta alla carta come predefinita fuori da quelle fasce. Un codice stampato per tutta la vita del tavolo.
• Confezione multilingue: regole di lingua per i mercati principali, inglese come predefinito. Istruzioni nella lingua del cliente senza stampare cinque etichette.
• Segnaletica di un evento: prima dell’apertura il programma, durante l’evento il calendario in tempo reale, la mattina dopo un modulo di feedback. Le regole orarie lo fanno senza che nessuno cambi i poster.
• Stand in fiera: desktop verso un whitepaper, mobile verso un modulo di contatto breve: in piedi nessuno compila un modulo lungo.
• Test del titolo su poster: due pagine con lo stesso peso, UTM diversi, si decide dopo due settimane.

Errori che costano scansioni

• Regola ampia sopra una regola specifica. Vince la prima corrispondenza; l’ordine è la logica.
• Dimenticare la destinazione predefinita. Serve tutti quelli che le tue regole non descrivono e deve sempre portare in un posto sensato.
• Ora locale invece di UTC. L’errore più comune, e fallisce in silenzio: il codice funziona, serve solo la cosa sbagliata per qualche ora.
• Regole non verificabili. Prova ogni ramo: cambia la lingua del telefono, scansiona da un browser desktop e, se c’è una regola oraria, aspetta la fascia o spostala temporaneamente su adesso.
• Testare senza metrica. Una divisione A/B senza UTM e senza obiettivo di conversione produce due numeri non confrontabili.

Ciò che qui le regole non possono fare, detto chiaro: non esiste targeting geografico. Le condizioni sono dispositivo, lingua del browser e ora — nessun paese, regione o città. La lingua è comunque l’approssimazione migliore, perché segue la persona e non la SIM.

Con Enqre imposti le regole nell’editor del codice. Vengono valutate nell’ordine in cui le hai aggiunte e il riordino per trascinamento non c’è ancora: aggiungi prima i casi specifici, oppure elimina e ricrea per cambiare l’ordine. Ogni scansione viene registrata qualunque ramo abbia preso.

Domande frequenti

Un QR code può portare a pagine diverse?

Sì, con un codice dinamico e le regole di reindirizzamento. La destinazione è decisa alla scansione in base al dispositivo, alla lingua del browser o all’ora: un solo motivo stampato serve più pubblici.

Posso targettizzare per paese o città?

In Enqre no. Le regole guardano solo dispositivo, lingua del browser e ora: la geolocalizzazione non esiste in nessuna parte del prodotto. Per la maggior parte dei casi la lingua del browser è un segnale migliore, perché segue il visitatore e non la rete.

Il test A/B ricorda quale variante è stata mostrata?

No. Ogni scansione è un’estrazione pesata indipendente, quindi una seconda scansione può finire sull’altra variante. Usalo per test di contenuto, non per percorsi in cui conta la coerenza tra visite.

Perché la mia regola oraria è scattata all’ora sbagliata?

Le ore sono in UTC. Converti dalla tua ora locale e ricorda che l’ora legale sposta lo scostamento due volte l’anno.

Quali tipi di codice supportano le regole?

URL e PDF. Gli altri tipi risolvono sulle proprie pagine e non hanno una destinazione alternativa.