Panoramica
Snapp raccoglie le metriche al momento del redirect.
Non esistono crawler in background, nessun tracker lato client obbligatorio e nessuna pipeline di job differiti. Ogni visita viene catturata in modo sincrono quando un URL breve viene risolto.
Le metriche sono progettate per essere:
- leggere
- append-only
- scoped per organizzazione
- efficienti in query
- filtrabili per URL, data, UTM e organizzazione
Quando vengono registrate le metriche
Le metriche vengono registrate durante la risoluzione dello shortcode, immediatamente prima del redirect.
Una visita viene loggata quando:
- l’URL è attivo
- l’URL non è scaduto
- i controlli VirusTotal e watchlist hanno esito positivo
- l’eventuale protezione tramite segreto è soddisfatta
Se uno di questi controlli fallisce, non viene scritta alcuna metrica.
Visite interne vs esterne
Ogni riga di metrica memorizza entrambi:
metric.organizationId→ organizzazione del visitatoreurl.organizationId→ organizzazione proprietaria dell’URL
Questo consente la classificazione in:
visite interne Il visitatore appartiene alla stessa organizzazione del proprietario dell’URL.
visite esterne Il visitatore appartiene a un’organizzazione diversa oppure è anonimo.
Questa distinzione viene calcolata in fase di query, non memorizzata in modo ridondante.
Dati raccolti per visita
Ogni entry di metrica può includere:
- timestamp
- id URL
- id proprietario
- id organizzazione del visitatore (se autenticato)
- browser
- sistema operativo
- tipo di dispositivo
- lingua
- referrer
- paese / regione / città (quando disponibili)
- payload UTM (JSON)
Le metriche sono append-only. Non vengono mai mutate dopo l’inserimento.
Scope organizzativo
Tutte le query sulle metriche sono scoped da:
url.organizationId = active organization
Questo garantisce che:
- le organizzazioni non possano vedere le metriche altrui
- gli admin possano cambiare esplicitamente contesto organizzativo
- non avvengano aggregazioni cross-organizzazione in modo implicito
Metriche a livello di URL
Nella pagina di un singolo URL, le metriche vengono aggregate per giorno.
Il grafico mostra:
- visite interne
- visite esterne
- impilate per giorno
I giorni mancanti vengono riempiti lato client per preservare la continuità del grafico.
Il modello dati restituito alla UI è:
{
internal: { day: Date; visits: number }[]
external: { day: Date; visits: number }[]
}
L’aggregazione avviene in SQL usando il raggruppamento DATE(timestamp).
Metriche della dashboard
La dashboard dell’organizzazione aggrega le metriche su tutti gli URL nello scope.
Suddivisioni disponibili:
- visitatori per giorno (interni vs esterni)
- browser
- sistemi operativi
- dispositivi
- lingue
- referrer
- paesi
- regioni
- città
- organizzazioni dei visitatori
Tutte le query condividono gli stessi vincoli di base.
Gestione degli intervalli di date
Le metriche supportano intervalli di date arbitrari.
Default:
from: 7 giorni fato: oggi (fine giornata)
Gli intervalli possono essere controllati tramite:
- date picker
- preset (settimana, mese, sei mesi, anno)
Tutte le date vengono applicate lato server usando >= from e <= to.
Supporto UTM
Gli UTM vengono memorizzati come JSON strutturato:
{
"utm_source": { "key": "utm_source", "value": "twitter" },
"utm_campaign": { "key": "utm_campaign", "value": "launch" }
}
Questo consente:
- filtraggio per chiavi UTM
- filtraggio per coppia chiave/valore UTM
- individuare quali UTM esistono in un dataset
Scoperta delle chiavi UTM
Snapp analizza le metriche recenti per estrarre le chiavi UTM disponibili.
Questo evita il mantenimento di una tabella di indice separata e mantiene lo storage minimale.
Sono applicati limiti per prevenire scansioni non limitate.
Filtri UTM
Esistono due filtri indipendenti:
Filtro chiavi UTM Limita le metriche alle visite che contengono specifiche chiavi UTM.
Filtro valori UTM Limita le metriche a un valore specifico per una determinata chiave UTM.
I filtri vengono combinati a runtime usando operatori JSON.
Enforcement dei permessi
La visibilità delle metriche è controllata dal ruolo:
- gli utenti standard vedono solo le metriche degli URL di cui sono proprietari
- gli admin possono vedere le metriche di tutta l’organizzazione
- il contesto organizzativo deve essere selezionato esplicitamente
Questo è applicato in SQL tramite:
user.role === 'user'
? metric.ownerId = user.id
: no restriction
Non esiste fiducia lato client.
Caratteristiche di performance
- Gli insert delle metriche sono scritture a singola riga
- Le aggregazioni sono calcolate on-demand
- Le query usano indici raggruppati e scansioni limitate
- Nessuna join attraversa i confini organizzativi
- Non sono richiesti job in background
Il percorso di redirect resta veloce e deterministico.
Cosa non fanno le metriche
- Nessun cookie impostato dal redirect
- Nessun tracciamento cross-site
- Nessun fingerprinting
- Nessuno script di terze parti richiesto
- Nessuna mutazione delle metriche esistenti
Le metriche di Snapp sono osservative, non comportamentali.