SnappSnapp
  • Per iniziare
  • Installazione
  • Configurazione
  • Styling
  • Introduzione
  • URL Personalizzati
  • Autenticazione
  • Architettura Multi-Dominio
  • Gestione dei Team
  • Integrazioni di Terze Parti
  • Metriche e Analytics
  • Riferimento API
  • English
  • Italiano
  • Per iniziare
  • Installazione
  • Configurazione
  • Styling
  • Introduzione
  • URL Personalizzati
  • Autenticazione
  • Architettura Multi-Dominio
  • Gestione dei Team
  • Integrazioni di Terze Parti
  • Metriche e Analytics
  • Riferimento API
  • English
  • Italiano
  • Feature

    • Introduzione
    • URL Personalizzati
    • Autenticazione
    • Architettura Multi-Dominio
    • Gestione dei Team
    • Integrazioni di Terze Parti
    • Metriche e Analytics
    • Riferimento API

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 visitatore
  • url.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 fa
  • to: 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.

Prev
Integrazioni di Terze Parti
Next
Riferimento API