Smart link. One link, many destinations.
Instrada per dispositivo, geo, lingua, ora del giorno. Le regole vengono valutate al POP edge — la prima corrispondenza vince, fallback alla destinazione predefinita. Non costa nulla in più di un normale reindirizzamento con cache hit.
- First-match rule engine at the edge
- Sub-millisecond rule evaluation
- A/B variants with z-test confidence
- Time-windowed campaigns in UTC
How it works
The redirect path, end to end
Smart-link rules are evaluated inside the same edge process that answers the redirect — there is no separate rules service to call. A cache-hit redirect with rules is indistinguishable from a plain one in latency.
- Step 1
User clicks
elido.me/xFrom email, QR, social, anywhere.
- Step 2
Nearest edge POP
Frankfurt · 4 msAnycast routes to Hetzner FRA / OVH SGP / Hetzner ASH.
- Step 3
Rule eval
L1 cache · 0.2 msFirst-match wins, no origin round-trip.
- Step 4
302 → destination
elido.me/x → /de/preiseClick event fired async to Redpanda.
Rule builder
Rules that read like English
Every rule combines up to six dimensions — geo, device, OS, language, referrer, and time — joined with AND. Drag to reorder; first match wins. The fallback is always required, so a rule set never produces a 404.
- CountryISO 3166-1 alpha-2 lists, e.g. DE, AT, CH
- Device & OSiOS, Android, Windows, macOS, Linux
- LanguageAccept-Language with BCP-47 fallbacks
- Time windowUTC range with day-of-week filter
- ReferrerExact or wildcard host match
- 1ifCountry: DE, AT, CHANDDevice: Mobile/de/preise⋮⋮
- 2ifCountry: FR, BEANDLanguage: fr-*/fr/tarifs⋮⋮
- 3ifOS: iOSApp Store · apps.apple.com/...⋮⋮
- 4ifTime: Mon–Fri 09–17 UTCANDReferrer: newsletter.*/promo/q2⋮⋮
- else/en/pricing— fallback (required)
Real-world routing
Same short link. Different landing per visitor.
The two patterns we see most: device-fork to native app stores with a desktop fallback, and country-fork for localised pricing pages. Both compose with A/B splits on the fallback path.
Country routing in production
An EU SaaS routing brand.app/pricing by visitor country. The fallback (everyone else) lands on the English page.
- DE · Germany/de/preise
- FR · France/fr/tarifs
- ES · Spain/es/precios
- IT · Italy/it/prezzi
- PL · Poland/pl/cennik
- NL · Netherlands/nl/prijzen
- SE · Sweden/sv/priser
- UA · Ukraine/uk/tsiny
- — · Everyone else/en/pricing
A/B testing
Split traffic. Watch confidence climb.
Up to 5 variants per link with weighted or round-robin splits. Each variant tracks its own click time-series. The dashboard surfaces a two-proportion z-test as a directional indicator — we don’t hide the math.
- Weighted (sums to 100) or round-robin
- Per-variant click time-series
- Z-test confidence over a configurable sample floor
- Winner-picks-all locks the link to the leading variant
- Composes with rules — A/B applies to the fallback path
What you can do
- Corrispondenza per paese ISO e fuso orario IANA
- Targeting mobile / tablet / desktop
- Finestre temporali con filtri per giorno della settimana
- Regex User-Agent per utenti esperti
- Limite di clic per link (max_clicks)
- Varianti A/B con ponderazione o round-robin
Cosa fa effettivamente l'engine delle regole degli smart link
Il geo-routing e il targeting per dispositivo sono la base. I dettagli qui sotto spiegano i casi limite che mandano in crisi le implementazioni standard.
La prima corrispondenza vince, valutata all'edge POP — nessun round-trip verso l'origine
Le regole sono memorizzate in Redis (L2 cache) e valutate dal servizio edge-redirect su ogni richiesta, all'interno dello stesso processo che esegue il redirect — non c'è un engine di regole separato da chiamare. La valutazione delle regole aggiunge meno di 1ms a un redirect con hit in cache. L'ordine di valutazione è quello impostato nella dashboard o nell'API; trascina per riordinare, o usa il campo order nell'API. La semantica 'first-match' significa che le regole più specifiche vanno messe per prime (es. 'mobile + Italia + lunedì mattina → pagina promo') e le regole generiche per ultime. Se nessuna regola corrisponde, viene servita la destinazione di fallback — il fallback è obbligatorio, non può essere vuoto. Le modifiche alle regole si propagano da api-core a Redis in meno di 30 secondi; il TTL della cache LRU edge per i link con regole è di 60 secondi, quindi la finestra di propagazione completa è inferiore a 90 secondi.
Sei dimensioni: geo, dispositivo, OS, lingua, referrer e ora
Ogni regola può combinare fino a sei dimensioni in una singola condizione. Geo: lista di codici paese ISO 3166-1 alpha-2 (uno o più paesi). Tipo di dispositivo: mobile, tablet, desktop — derivato dallo User-Agent. OS: iOS, Android, Windows, macOS, Linux — anch'esso dallo User-Agent. Lingua: corrispondenza dell'header Accept-Language (tag lingua BCP 47; 'fr' corrisponde a 'fr-FR', 'fr-CA', ecc.). Dominio referrer: corrispondenza esatta o wildcard con il dominio dell'header Referer (utile per instradare traffico social vs email vs diretto). Ora: finestra temporale UTC con filtro opzionale per giorno della settimana (es. 'Lun–Ven 09:00–17:00 UTC'). La regex dello User-Agent è disponibile per gli utenti esperti che devono colpire una versione specifica del browser o un crawler; non è esposta nella dashboard per impostazione predefinita, solo tramite API. Più dimensioni in una singola regola sono in AND; un link può avere fino a 5 regole (Pro) o illimitate (Business).
Split A/B pesati con confidenza z-test — fino a 5 varianti per link
Un link può avere fino a 5 varianti di destinazione. I flussi di traffico si dividono per peso (configurabile per variante; la somma dei pesi deve essere 100) o round-robin. Ogni variante traccia la propria serie temporale di clic in modo da poter vedere se l'effetto è coerente nelle diverse ore del giorno. Il modello di confidenza è uno z-test a due proporzioni a livello di clic: la dashboard mostra 'la variante A è in testa con una confidenza del X%' una volta che entrambe le varianti superano un campione minimo (default 200 clic ciascuna, configurabile fino a 1.000). Riportiamo la confidenza grezza dello z-test; non applichiamo correzioni per test sequenziali. Le varianti A/B e le regole degli smart link possono coesistere sullo stesso link: le regole vengono valutate per prime e lo split A/B si applica solo al percorso di fallback. Così puoi instradare gli utenti iOS incondizionatamente mentre testi due destinazioni A/B per tutti gli altri. Il pulsante winner-picks-all blocca il link sulla variante vincente ed elimina le altre — operazione irreversibile.
Regole con finestra temporale per campagne stagionali e basate su eventi
Le regole temporali permettono di impostare una regola che si attiva e disattiva secondo un programma senza intervento manuale. L'uso tipico: una regola per una pagina promozionale attiva dal Black Friday 00:00 UTC fino al Cyber Monday 23:59 UTC, per poi tornare automaticamente alla destinazione evergreen. Le regole sono valutate in UTC; se la tua campagna è sensibile al fuso orario, converti in UTC al momento della configurazione. Le regole pianificate sono valutate come le regole statiche — all'edge, senza round-trip all'origine. La dashboard mostra una vista timeline delle regole pianificate in modo che le finestre sovrapposte siano visibili. Caso limite: se due regole con finestra temporale si sovrappongono ed entrambe corrispondono, vince quella con l'indice d'ordine più basso (first-match). Non c'è rilevamento dei conflitti — la revisione delle regole sovrapposte è responsabilità tua.
La destinazione di fallback è obbligatoria — nessun errore 404 quando le regole non corrispondono
Ogni smart link deve avere una destinazione di fallback. Non esiste l'opzione 'mostra una pagina di errore se nessuna regola corrisponde' — il fallback è la rete di sicurezza. Il fallback può essere qualsiasi URL; viene utilizzato anche come destinazione canonica per Google Bot e altri crawler (le regole degli smart link non vengono applicate agli User-Agent dei crawler noti per evitare confusione nell'indicizzazione). Oltre al fallback primario, la scadenza a livello di link (expires_at) e il limite di clic (max_clicks) hanno ciascuno il proprio URL di destinazione scaduto configurabile — separato dal fallback delle regole. Quindi un link può avere: fino a 5 regole di routing, un fallback per nessuna corrispondenza di regola, una destinazione per post-data di scadenza e una destinazione per post-limite di clic. Questi si compongono in modo pulito; i casi limite sono documentati nelle guide.
Team che utilizzano gli smart link in produzione
I nomi sono segnaposto per ora — i nomi reali dei clienti verranno inseriti man mano che i casi studio vengono pubblicati.
“Abbiamo ritirato un servizio di redirect in Node.js che ci costava 40ms di round-trip. Gli smart link su Elido valutano le regole all'edge; il redirect è veloce quanto un normale link breve. Il servizio di regole era composto da 600 righe di codice che non dobbiamo più mantenere.”
“Le regole con finestra temporale per i contenuti stagionali ci permettono di impostare le campagne in anticipo. Prima era un cambio manuale del redirect alle 2 del mattino. Ora è una regola pianificata e un promemoria sul calendario per controllare il risultato.”
“La visualizzazione della confidenza A/B nella dashboard ha posto fine alla discussione 'è statisticamente significativo?' nel nostro standup. Guardiamo il numero dello z-test, concordiamo una soglia e andiamo avanti.”
Smart link di Elido vs Bitly geo + Rebrandly geo
Sia Bitly che Rebrandly offrono il geo-routing. Le differenze risiedono nella profondità delle regole, nella latenza di valutazione e nella capacità A/B.
| Feature | Elido | Bitly | Rebrandly |
|---|---|---|---|
| Dimensioni delle regole | Geo, dispositivo, OS, lingua, referrer, ora | Geo + dispositivo (limitato) | Geo + dispositivo |
| Varianti A/B per link | Fino a 5 — pesate + confidenza z-test | Non disponibile | Non disponibile |
| Regole valutate all'edge | Sì — nessun round-trip all'origine | Redirect serviti dall'edge; la valutazione delle regole varia | Varia in base al piano |
| Tempo di propagazione delle regole | Meno di 90 secondi | Non documentato | Non documentato |
| Regole pianificate / con finestra temporale | Sì — finestra UTC, filtro giorno della settimana | Non disponibile | Non disponibile |
| Max regole per link | 5 su Pro, illimitate su Business | Geo: 1 per link | Varia in base al piano |
| Destinazione di fallback | Obbligatoria, configurabile | Destinazione predefinita | Destinazione predefinita |
| Limite di clic | Sì — per link, per variante | Non disponibile | Non disponibile |
Domande sugli smart link
Quanto velocemente si propagano le modifiche alle regole?
api-core invia le modifiche alle regole a Redis entro 30 secondi dal salvataggio. Il servizio edge-redirect ha una cache LRU interna al processo con un TTL di 60 secondi per i link con regole. Propagazione completa: meno di 90 secondi nel peggiore dei casi. Se hai bisogno di una propagazione più rapida (es. cutover di un evento dal vivo), l'API ha un endpoint di cache-bust che forza l'invalidazione immediata di Redis — l'edge LRU fallirà e recupererà da Redis in pochi secondi.
Cosa succede se due regole corrispondono alla stessa richiesta?
La prima corrispondenza vince — viene applicata la regola con l'indice d'ordine più basso. Non c'è rilevamento di conflitti o fusione. È tua responsabilità ordinare le regole correttamente e evitare finestre temporali o liste di paesi sovrapposti. Lo strumento di anteprima delle regole nella dashboard ti permette di simulare una richiesta di test contro il set di regole corrente per verificare quale regola scatta.
Le regole si applicano a Google Bot e ad altri crawler?
No. I pattern User-Agent dei crawler noti sono esclusi dalla valutazione delle regole; i crawler ricevono sempre la destinazione di fallback. Questo è intenzionale — non vuoi che il routing dei tuoi smart link influenzi il comportamento di indicizzazione o serva ai crawler contenuti specifici per regione involontariamente. La lista di esclusione dei crawler è la stessa utilizzata dall'edge per classificare il traffico organico rispetto a quello dei bot negli analytics.
Come viene calcolata la confidenza dello z-test?
Z-test a due proporzioni a livello di clic. L'ipotesi nulla è che entrambe le varianti abbiano lo stesso tasso di clic. La confidenza è 1 - p-value, espressa in percentuale. Non applichiamo la correzione di Bonferroni per varianti multiple; l'esecuzione di più di 2 varianti aumenta il tasso di falsi positivi. Per esperimenti formali, esporta il flusso di clic grezzi e avvia il test di significatività nel tuo warehouse. Mostriamo il numero nella dashboard come indicatore direzionale, non come una conclusione causale.
Posso impostare una regola che instrada solo su un referrer specifico?
Sì — la corrispondenza del dominio referrer è una delle sei dimensioni della regola. Puoi far corrispondere un dominio esatto (es. 'newsletter.example.com') o una wildcard ('*.example.com'). Viene utilizzato l'header Referer; lo stripping del referrer HTTPS significa che non otterrai sempre un referrer da siti HTTPS esterni. Per i link condivisi via email (dove il Referer è tipicamente assente), le regole del referrer sono meno affidabili delle regole geo o dispositivo.
Posso usare gli smart link nel piano gratuito?
No. Gli smart link sono una funzionalità Pro e Business. I link del piano gratuito vanno a una singola destinazione senza regole di routing. Puoi visualizzare in anteprima l'interfaccia delle regole nel piano gratuito, ma le regole non vengono valutate all'edge finché non effettui l'upgrade.
Esistono analytics per variante?
Sì. Ogni variante in uno split A/B ha la propria serie temporale di clic visibile nella vista analytics del link. Le suddivisioni per geo, dispositivo e referrer sono aggregate a livello di link, non per variante — le suddivisioni dimensionali per variante sono nella roadmap per il piano Business.
Qual è la differenza tra uno smart link e uno split A/B di campagna?
L'A/B dello smart link è per link: dividi il traffico su diverse destinazioni per lo stesso URL breve. L'A/B di campagna è a livello di campagna: esegui due varianti di link brevi (slug diversi) che puntano alla stessa destinazione e usi gli analytics della campagna per confrontare quale slug ha ottenuto più clic. Casi d'uso diversi: l'A/B a livello di link serve per testare la destinazione; l'A/B di campagna serve per testare la creatività e lo slug.
Keep reading
Universal Links + App Links — il livello di routing specifico per dispositivi mobili che lavora insieme alle regole degli smart link.
A/B a livello di campagna, template UTM e esportazioni pianificate — il workflow delle campagne costruito sopra gli smart link.
Dati sui clic, suddivisione per geo/dispositivo e viste di coorte — l'aspetto reale del traffico degli smart link in ClickHouse.
Come i team di prodotto usano gli smart link per il routing dei feature-flag, l'onboarding e la condivisione in-app.
Pronto a provarlo?
Inizia con il piano gratuito, effettua l'upgrade quando hai bisogno di un dominio personalizzato.