Smart link spiegati: routing edge senza un servizio aggiuntivo

Abbiamo stampato 18.000 volantini per un lancio di prodotto DACH a marzo. Un unico short link sul retro, tre landing page regionali verso cui volevamo indirizzare le persone: /de per i visitatori tedeschi, /fr per la piccola fetta francese, /en per tutti gli altri. Il responsabile marketing ha posto l'ovvia domanda: stampiamo tre volantini o uno?

Se ne stampa uno. Il link si occupa del routing.

Uno "smart link" è un singolo short URL la cui destinazione viene calcolata al momento del redirect, non al momento della creazione del link. C'è uno slug. Ci sono diverse possibili destinazioni. La decisione avviene nello stesso handler che altrimenti emetterebbe un semplice 302 - nessun servizio separato da chiamare, nessuno shim JS su una landing page, nessun hop aggiuntivo. Questo articolo spiega come appare effettivamente sotto il cofano, le sei dimensioni su cui Elido fa il routing e i casi in cui dovresti usare uno strumento diverso.

Tre cose che uno smart link non è#

Le persone si avvicinano agli smart link da tre diverse esperienze precedenti, e i trade-off sono diversi in ciascuna.

Redirect semplice. Uno slug, una destinazione, zero logica. Il redirect handler esegue una ricerca in cache e scrive un 302. Non puoi batterlo sulla latenza; non puoi nemmeno renderlo condizionale. Questo è il piano base - qualsiasi cosa più elaborata ha un costo.

Smart link sull'edge. Uno slug, diverse possibili destinazioni, un piccolo passaggio di valutazione delle regole inserito tra la ricerca in cache e la risposta. Poiché la regola risiede nello stesso processo della ricerca in cache, il costo è sotto il millisecondo (0,3ms p50 / 1ms p95 nel caso di Elido). Il visitatore vede un singolo round trip HTTP. La cache del browser non viene avvelenata, perché le risposte 302 non sono memorizzabili nella cache per default secondo RFC 7234 §4.2.2 - un fatto che conta qui, perché il routing per richiesta ha senso solo se ogni richiesta può scegliere la propria destinazione.

Router A/B JavaScript su una landing page. Una pagina HTML neutra viene renderizzata, il JS esamina navigator.userAgent o un servizio geo-IP, poi fa window.location = '/foo'. Questa è la peggior opzione delle tre. Il visitatore vede un rendering HTML, poi un redirect, poi la pagina effettiva - almeno un round trip aggiuntivo, spesso due se la ricerca geo è di terze parti. L'indicizzazione SEO è confusa perché i crawler vedono la pagina neutra. I browser con blocco cookie e le estensioni privacy rompono la metà JS. Le note di rilascio di Intelligent Tracking Prevention 2.3 di Apple citano esattamente questo pattern: i link di tracciamento client-side tramite document referrer vengono limitati e la mitigazione richiede la partecipazione lato server. Se stai facendo il routing in JS oggi, stai già pagando il conto.

Il posto giusto per mettere una decisione di routing è lo stesso hop che sta già emettendo il redirect. Questo è ciò che fanno gli smart link edge.

Perché risiede sull'edge - il budget di latenza#

Il tier di redirect di Elido ha un budget di latenza fisso: p50 5ms, p95 15ms su un cache hit, escluso il TLS handshake. Quel numero non è aspirazionale - tutto ciò che ci spinge oltre viene eliminato. SQL sincrono sul hot path, compilazione regex per richiesta, I/O bloccante sull'evento di clic: tutto via, tutto spostato ai worker del cold path.

I due motivi per cui esiste quel budget:

1. Le reti mobile aggiungono la propria tassa. La guida "Reducing Network Latency" di Apple illustra come i ritardi delle reti cellulari si sommano alle catene di redirect. Ogni hop aggiuntivo aggiunge RTT che la rete del visitatore ha già gonfiato. Meno hop aggiungiamo, meno la loro rete li penalizza.
2. La prossimità all'edge è la vera leva. Il primer di Cloudflare sul routing edge lo inquadra allo stesso modo: la decisione più economica è quella presa nello stesso processo del writer della risposta, nel POP più vicino al visitatore. Non siamo gli unici a fare routing edge; ciò che è unico è incorporarlo nel URL shortener invece di chiederti di distribuire una funzione Workers / Lambda@Edge separata.

Se delegassimo la valutazione delle regole a un servizio downstream - diciamo, una ipotetica "rules-api" raggiungibile tramite HTTP - aggiungeremmo un round trip nella stessa regione ad ogni richiesta. In regione sono circa 5ms minimi (un hop nella stessa regione su una rete privata), e nel traffico cross-region la coda diventa brutta molto in fretta. Il p95 di 15ms non sopravvive al round trip. Quindi le regole degli smart link sono inline, nel binario edge, che valutano contro matcher compilati costruiti quando il link è stato caricato nella cache. L'intero motore delle regole è circa 400 righe di Go.

Quell'accoppiamento stretto è anche il motivo per cui possiamo fare modifiche alle regole in tempo reale: le modifiche alle regole si propagano tramite un canale pub/sub della cache in memoria (link:invalidate) a cui si iscrive ogni POP edge. L'LRU L1 si svuota entro un secondo dalla pubblicazione, la prossima richiesta si ripopola da L2 e la nuova regola è attiva. Ulteriori dettagli su questo di seguito.

Le sei dimensioni di routing#

Gli smart link di Elido corrispondono su sei cose. Ciascuna si mappa a uno specifico input che l'edge ha per richiesta.

Paese. Due lettere ISO 3166-1 alpha-2, derivate dall'IP del visitatore tramite geoip. Utile quando hai vetrine regionali e l'aumento di conversione per paese vale la complessità del routing. Il classico problema qui sono i viaggiatori - un tedesco in vacanza in Spagna raggiunge la destinazione spagnola se fai il routing solo sul paese. Se la preferenza linguistica conta più della posizione geografica, fai il routing su languages invece. Discutiamo il flusso geoip completo nel post sulla privacy delle analisi - l'IP viene troncato prima dell'archiviazione in modo che il lato GDPR rimanga pulito.

Dispositivo. mobile, tablet, desktop, analizzato dalla stringa User-Agent al momento della richiesta. Il caso d'uso per cui i marketer la usano: banner di installazione app che vanno all'App Store su iOS, al Play Store su Android e a una pagina marketing su desktop. Da tenere d'occhio: le stringhe User-Agent su iPad hanno avuto un percorso movimentato da quando iPadOS ha iniziato a presentare il UA di Safari desktop per default, e il nostro rilevamento tablet lo accommodate, ma non è al 100% su ogni versione del browser. Se la differenza tra il traffico tablet e desktop conta per te in termini di denaro, strumenta la destinazione e verifica.

OS. ios, android, macos, windows, linux. Stessa sorgente User-Agent del dispositivo, partizione più ristretta. Il caso del deep link: instrada i visitatori iOS a un Universal Link che l'app intercetta e ricade sull'App Store; instrada Android al Play Store con i dati di referral preservati. Questo è per cosa abbiamo costruito l'integrazione Apple App Site Association.

Lingua. Tag di lingua primaria dall'intestazione Accept-Language del visitatore. Codici ISO 639-1 come de, fr, pt. Il trabocchetto: Accept-Language è la preferenza del browser, che spesso non concorda con il geo IP. Un francese espatriato a Berlino ottiene country: DE, languages: ["fr", "en"] - se vuoi che raggiunga /fr, fai il routing sulla lingua; se vuoi che raggiunga il negozio tedesco perché stai testando A/B i prezzi localizzati, fai il routing sul paese. Sequenza le regole di conseguenza.

Ora del giorno e giorno della settimana. Finestra HH:MM in qualsiasi timezone IANA, più un bitmap days_of_week. Le offerte con finestra temporale - una landing page "happy hour" che va live alle 17:00 Europe/Berlin lun–ven e ricade sulla pagina normale fuori da quella finestra - sono l'adattamento naturale. La finestra time_start / time_end supporta il wraparound (22:00 → 02:00), che suona ovvio ma ci ha colti di sorpresa quando abbiamo portato il motore delle regole dal prototipo che non lo gestiva. Lo schema completo è nella guida agli smart link.

Host del referrer. La parte hostname dell'intestazione Referer, normalizzata. Utile per destinazioni partner-aware: i visitatori provenienti da partner.example ottengono una landing page co-branded; tutti gli altri ottengono quella predefinita. Meno utile di quanto fosse un tempo - i browser moderni rimuovono Referer in modo aggressivo quando la pagina di riferimento imposta Referrer-Policy: no-referrer o quando la navigazione attraversa contesti HTTPS in un modo che la policy non consente. Tratta le regole referrer come un segnale soft, mai come autenticazione.

Questo è tutto. Sei dimensioni coprono le decisioni di routing di marketing che abbiamo visto in tre anni di conversazioni con i clienti. Le omissioni deliberate sono l'identità dell'utente (non la conosciamo al momento del redirect), intestazioni HTTP arbitrarie (il rapporto costo-beneficio non c'è per i pochi team che l'hanno chiesto) e split randomizzati (usa invece la rotazione delle varianti, che è una funzionalità separata).

Semantica first-match; fallback sempre richiesto#

Le regole sono un array. L'edge le percorre in ordine. La prima regola il cui blocco match è completamente soddisfatto vince, e il suo destination_url è il target del redirect. Il destination_url di primo livello del link è il fallback incondizionato. Rifiutiamo di creare uno smart link senza uno - uno smart link non produce mai un 404, per design.

La forma minima valida:

{
  "destination_url": "https://acme.example/en",
  "targeting_rules": [
    {
      "match": { "countries": ["DE", "AT", "CH"] },
      "destination_url": "https://acme.example/de"
    },
    {
      "match": { "languages": ["fr"] },
      "destination_url": "https://acme.example/fr"
    }
  ]
}

I visitatori DACH raggiungono /de perché la regola 1 corrisponde per prima. Un francese espatriato a Berlino ha country=DE, quindi raggiunge anche lui /de - la regola 1 corrisponde prima che la regola 2 abbia possibilità. Se vuoi che il francese espatriato raggiunga /fr, scambia le regole in modo che la regola della lingua venga verificata prima. L'ordine nella dashboard è l'ordine che valutiamo.

Due implicazioni che vale la pena esplicitare:

• Le regole più ampie vanno per ultime. Una regola senza condizioni match corrisponde a tutto; se è prima, nessuna regola sottostante scatta mai. La dashboard valida questo e ti avverte, ma l'API non lo fa, quindi le regole costruite da script necessitano di un controllo di sanità.
• L'esclusione reciproca è a tuo carico. Se due regole corrispondono entrambe a un singolo visitatore, la prima vince silenziosamente. Nessun errore, nessun flag, nessuna metrica. Abbiamo considerato di emettere un avviso al momento del caricamento del link quando due regole sono rilevabili come sovrapposte, ed è nella roadmap per la prossima release minore. Per ora: leggi le tue regole dall'alto in basso e fidati dell'ordine.

Il costo: propagazione dell'invalidazione della cache#

Ogni decisione di routing ha una finestra di propagazione. Le regole degli smart link modificate nella dashboard si propagano attraverso le cache L1 in tutti e tre i POP Elido in circa 1 secondo nella happy path. Circa, perché:

• L'LRU L1 in ciascun POP mantiene i link con regole con un TTL di 60 secondi (l'architettura della cache è documentata qui). Il TTL è il limite superiore - anche senza una pubblicazione di invalidazione, una voce stale sparisce entro un minuto.
• La pubblicazione dell'invalidazione avviene tramite il pub/sub della cache in memoria. I POP UE e USA Est condividono un cluster di cache; l'Asia-Pacifico ha il suo. La propagazione cross-region è essenzialmente la latenza di replicazione della cache più l'elaborazione pub/sub del nostro subscriber, che è stata sotto 1 secondo p99 nelle nostre metriche nell'ultimo trimestre.
• Un POP che ha perso la propria sottoscrizione alla cache ricade sul TTL di 60 secondi. Allarmiamo sulla perdita di sottoscrizione; l'on-call ha 5 minuti di clic bufferizzati prima che il WAL si attivi.

Traduzione: per i flussi di marketing in cui 60 secondi di routing stale vanno bene, non devi pensarci. Per i flussi in cui la staleness conta - una rotazione di disclaimer legale, un split di coorte di fatturazione dove la destinazione sbagliata addebita la valuta errata - la mossa è status=disabled prima, poi riabilitare dopo un minuto, poi pubblicare la nuova regola. Abbiamo aggiunto un endpoint GET /v1/links/{id}/status in modo che una pipeline CI possa fare polling per il completamento della propagazione prima di attivare uno switch downstream.

Quando non usare uno smart link#

Tre casi in cui lo strumento giusto non è uno smart link.

Il rendering server-side della destinazione è migliore. Se la variante deve essere iniettata nella risposta HTML - diciamo, la localizzazione del prezzo che dipende dallo stato autenticato del visitatore, o una landing page che recupera un hero specifico per coorte dal tuo CMS - questo è un lavoro per il server della destinazione, non per il redirect. Il redirect sceglie dove inviare il visitatore; la destinazione sceglie cosa renderizzare. La logica di routing che risiede sull'edge non può vedere la tua sessione auth, e forzarla richiederebbe di far trapelare la sessione nel path di redirect (cosa che non faremo) o di proxizzare attraverso l'edge (cosa che non facciamo a causa del budget di latenza). Renderizza le varianti all'origine.

Test A/B statisticamente rigorosi. Gli smart link fanno il routing per richiesta, non per visitatore. Se un visitatore atterra due volte in cinque minuti dallo stesso dispositivo, potrebbe vedere due destinazioni diverse sotto una regola randomizzata, che è il comportamento giusto per "invia il 50% del traffico mobile ad A e il 50% a B" ma quello sbagliato per "misura se la variante A converte meglio della variante B in una finestra di 4 settimane". Per quest'ultimo, hai bisogno di un cookie di variante stabile e di uno strumento di sperimentazione che faccia le statistiche correttamente. PostHog, GrowthBook e LaunchDarkly lo fanno tutti. Noi no, e non lo faremo - gli strumenti sono un lavoro diverso. Usa la rotazione delle varianti con round_robin per il campionamento a bassa posta in gioco e usa una piattaforma di sperimentazione quando devi difendere il risultato.

Routing identity-aware. Gli smart link sono deliberatamente stateless. Valutano contro country | device | OS | language | time | referrer e nient'altro. Se hai bisogno di fare il routing in base al tier di un utente loggato, alle sue feature flag, o a qualsiasi cosa che richieda di cercare "chi è questa persona", il path di redirect è il layer sbagliato. Risolvi l'identità all'origine e servi la variante da lì. O, se hai davvero bisogno di una decisione al momento del redirect, conia short link per utente tramite l'API - ogni utente autenticato ottiene il proprio slug, la destinazione dello slug è corretta per quell'utente al momento della creazione, e non devi mai fare la risoluzione dell'identità sul hot path.

Cosa c'è dopo#

Se vuoi provare la struttura delle regole sui tuoi dati, la guida della documentazione illustra lo schema JSON e l'editor della dashboard. Il rule builder si trova sotto la pagina di modifica di qualsiasi link nella dashboard - Link → ⋯ → Targeting.

Due miglioramenti in arrivo nella prossima release minore: una gerarchia di fallback per languages (in modo che pt-BR degrade pulitamente a pt, poi a en, senza scrivere tre regole) e un passaggio di analisi statica al momento del salvataggio del link che segnala le regole sovrapposte in modo che la dashboard possa avvertire prima che la regola vada in produzione. Entrambi sono lavoro di implementazione, nessuna modifica allo schema che rompa la retrocompatibilità. Se hai una struttura di regole che non supportiamo e pensi che dovremmo, il canale di feedback è in fondo alla pagina della funzionalità smart link.

Correlato sul blog#

• Testa le landing page A/B con short link - senza uno strumento CRO
• Raggiungere p95 < 15ms per i redirect da FRA, ASH e SGP
• Deep link per app mobile senza un SDK
• URL shortener per i marketer: la matrice di confronto 2026