Click data you can actually query.
Misuri attribuzione, drop-off del funnel e incremento incrementale. Elido archivia ogni clic in ClickHouse con accesso raw — nessun campionamento, nessun ritardo di aggregazione.
- No click sampling at any tier — every event stored
- Per-workspace ClickHouse DSN, read-only, rotatable
- Scheduled S3 + BigQuery export (Parquet by default)
- Raw click events via webhook firehose / Kafka consumer
How click data lands
Click → Redpanda → ClickHouse, with no aggregation in the middle.
Most shorteners give you a counter. We give you a row per click, ingested in under five seconds, queryable from your own SQL client. The pipeline is one binary writing to one Kafka topic that one consumer drains into ClickHouse — no aggregation service, no daily summaries, no ‘sampled after 10K’ footnote.
- Step 1
Click
elido.me/x → 302Edge POP returns the destination + emits an event to Redpanda.
- Step 2
Redpanda
topic: clicks.<workspace>12 partitions, at-least-once delivery, 7-day topic retention.
- Step 3
ClickHouse
<5s p99 ingest lagclick-ingester drains the topic into the per-workspace events table.
- Step 4
Your tools
DSN · BigQuery · KafkaRead-only DSN, scheduled Parquet export, or direct firehose consumer.
Per-workspace ClickHouse DSN
A read-only DSN you can paste straight into Metabase.
Business workspaces get a per-workspace, read-only ClickHouse DSN scoped to their event table via row-level security. Plug it into Metabase, Hex, Apache Superset, Grafana, or any ClickHouse-compatible client. The DSN is rotatable from workspace settings without changing the underlying table.
- Stable schemaVersioned in /docs/api-reference; migration guides in /changelog
- Row-level securityDSN scoped to your workspace's event rows only
- BI-tool compatibleMetabase, Hex, Superset, Grafana, Looker — anything that speaks ClickHouse
- Sub-second queries1B-row tables under 1s for typical group-by-country / hour aggregations
SELECT country, COUNT(*) AS clicks
FROM events
WHERE link_id = 'lnk_8a2fc1...'
AND occurred_at >= now() - INTERVAL 7 DAY
GROUP BY country
ORDER BY clicks DESC
LIMIT 5;| country | clicks | distribution |
|---|---|---|
| DE | 18,429 | |
| FR | 12,184 | |
| ES | 9,847 | |
| IT | 8,213 | |
| PL | 7,062 |
Geography that survives the export
Country-level density on every click — not a hashed bucket.
Every click event includes ISO 3166-1 alpha-2 country, region, and city, resolved from MaxMind GeoIP at edge time. The IP itself is truncated to /24 (IPv4) or /48 (IPv6) before storage, so geo persists but PII does not. Below is the same data in the UI that lands in your warehouse — no aggregation tier in between.
Source of truth. 0% sampling, 24-month retention on Business.
Hourly buckets, snappy-compressed Parquet (or JSON if you prefer).
Native BigQuery Transfer service or Snowflake external table loads from S3.
Warehouse export
Hourly Parquet to S3, then a native transfer into your warehouse.
The scheduled export pushes click events as Parquet to your S3 bucket on an hourly or daily cadence; native BigQuery Transfer or Snowflake external table loads it from there. The first run is a full backfill to your retention window; subsequent runs append only new events keyed on the event timestamp. Failures retry; a dead-letter notification fires if a batch can’t land within 2 hours.
- Parquet (default) or JSON; one object per hour-bucket
- Filter export by domain, campaign, or link tag
- Native BigQuery Transfer + Snowflake external table
- Dead-letter alert on >2h batch failure
- Kafka firehose for sub-second delivery (Business)
What you can do
- No click sampling at any tier — every event stored
- Per-workspace ClickHouse DSN, read-only, rotatable
- Scheduled S3 + BigQuery export (Parquet by default)
- Raw click events via webhook firehose / Kafka consumer
- Sub-second query latency on 1B+ row tables
- Server-side click attribution with click-ID dedupe
Cosa significa 'analytics-first' nel modello dati di Elido
La maggior parte delle analisi degli abbreviatori sono totali aggregati. Le funzionalità seguenti spiegano cosa cambia quando il flusso di clic grezzi è l'artefatto principale, non un riepilogo.
Ogni clic memorizzato — nessuna nota a piè di pagina 'campionamento dopo N eventi'
Gli eventi di clic vengono acquisiti tramite un topic Redpanda Kafka e scritti su ClickHouse dal servizio click-ingester. Non esiste un livello di campionamento. Un link con 10 clic e un link con 10 milioni di clic hanno entrambi ogni singolo evento nella stessa tabella — lo schema non cambia, non viene applicata alcuna aggregazione al momento dell'acquisizione. La conservazione è di 90 giorni su Free, 12 mesi su Pro e 24 mesi su Business. Dopo la finestra di conservazione, gli eventi vengono eliminati definitivamente; il conteggio degli eventi eliminati viene registrato. Lo schema ClickHouse è pubblico — puoi vedere esattamente quali campi sono memorizzati, il che significa che puoi pianificare il tuo modello dati nel tuo data warehouse prima di iniziare l'esportazione. Il ritardo degli eventi dal clic alla disponibilità in ClickHouse è in genere inferiore a 5 secondi; il consumer Redpanda viene eseguito con auto-commit e registra le metriche di ritardo (lag) per consentirti di vedere se la pipeline è in ritardo.
GA4 MP, Meta CAPI e Mixpanel server-side — deduplicati rispetto al clic
I pixel lato client perdono una frazione significativa di conversioni a seconda della penetrazione degli adblocker e di iOS Safari ITP. L'inoltro server-side invia la conversione a GA4 Measurement Protocol, Meta Conversions API o Mixpanel direttamente dal backend di Elido — non è richiesto JavaScript lato client. La chiave di deduplicazione è l'ID del clic: quando un evento di conversione arriva tramite webhook Stripe o Shopify, Elido lo associa al clic di origine e lo distribuisce a tutti gli endpoint server-side configurati. L'ID del clic viene passato come parametro di query all'URL di destinazione al momento del clic; il tuo flusso di checkout dovrebbe conservarlo fino all'evento di conversione. Ogni evento inoltrato riporta i parametri UTM originali dal clic, in modo che l'attribuzione sopravviva all'intero funnel. Questo è utile per recuperare le conversioni che i pixel lato client perdono — non sostituisce una CDP completa, ma colma il comune divario di attribuzione last-click.
DSN ClickHouse in sola lettura per workspace — collegalo direttamente a Metabase, Hex o Grafana
I workspace Business ottengono un DSN ClickHouse in sola lettura per workspace limitato alla loro tabella degli eventi. Punta Metabase, Hex, Apache Superset, Grafana o qualsiasi client compatibile con ClickHouse al DSN e scrivi SQL direttamente sui tuoi dati degli eventi di clic. Il DSN è ruotabile senza modificare la tabella degli eventi; si connette a un utente in sola lettura che può solo eseguire SELECT, non INSERT o DROP. Lo schema ClickHouse è stabile e versionato; le modifiche allo schema ricevono una guida alla migrazione nel changelog prima di essere implementate. Per i team che desiderano unire gli eventi di clic con i propri dati di prodotto — 'quali link hanno portato gli utenti che hanno poi attivato?' — il modello standard consiste nel copiare gli eventi di clic nel proprio warehouse tramite esportazione pianificata, quindi eseguire il join lì. Il DSN ClickHouse è per i team il cui strumento di BI può connettersi direttamente a ClickHouse e che non hanno bisogno di unirsi a tabelle esterne.
Esportazioni pianificate su S3, BigQuery e Snowflake
L'esportazione pianificata viene eseguita con una cadenza configurabile (oraria, giornaliera) e invia il flusso degli eventi di clic — o un sottoinsieme filtrato per dominio, campagna o tag del link — a S3, BigQuery o Snowflake. L'esportazione su S3 utilizza Parquet per impostazione predefinita (JSON disponibile); BigQuery e Snowflake utilizzano i connettori nativi con uno schema che Elido crea e mantiene aggiornato. Le esportazioni incrementali sono basate sul timestamp dell'evento; la prima esportazione è un backfill completo fino alla tua finestra di conservazione; le esportazioni successive aggiungono solo nuovi eventi. Se hai bisogno di riprodurre i dati da un timestamp specifico, è disponibile un'esportazione completa una tantum tramite richiesta di supporto. Gli errori di esportazione vengono registrati e riprovati; una notifica di errore viene inviata all'e-mail del workspace se un batch fallisce per più di 2 ore.
Consumer Kafka in tempo reale per pipeline di eventi che non possono attendere le esportazioni batch
I workspace Business possono consumare eventi di clic direttamente da un topic Redpanda come gruppo di consumer Kafka. Riceverai un ID gruppo consumer, un server bootstrap e un certificato client — configurazione standard per consumer Kafka. Questo è il percorso giusto per gli avvisi in tempo reale (rilevamento di picchi su un link, segnalazione di anomalie geografiche), dashboard in tempo reale che necessitano di dati con latenza inferiore al secondo e pipeline in cui la cadenza di esportazione pianificata è troppo lenta. Il firehose fornisce ogni evento 'at-least-once'; il tuo consumer è responsabile dell'idempotenza durante la riproduzione. La conservazione del topic è di 7 giorni; se il tuo consumer rimane indietro di più di 7 giorni, gli eventi andranno persi — imposta il monitoraggio sul ritardo del consumer (lag). Questa non è una funzionalità di analisi per principianti; richiede codice per il consumer Kafka ed esperienza operativa con i gruppi di consumer. Se l'esportazione pianificata su BigQuery è sufficiente per le tue esigenze, inizia da lì.
Stack you’ll touch
- Eventi clic raw
- Accesso diretto ClickHouse
- GA4 / Meta CAPI / Mixpanel
- Export S3 + BigQuery
- DSN per workspace
- Firehose webhook
Cosa misurerai
- Tasso di campionamento
- 0% — ogni clic archiviato
- Ritardo di ingestione eventi
- Sotto 5 secondi
- Orizzonte di retention
- Fino a 24 mesi
Team di analisi che utilizzano questa soluzione
I nomi sono segnaposto per ora — i nomi reali dei clienti verranno inseriti man mano che verranno pubblicati i casi studio.
“Il DSN ClickHouse ci ha permesso di collegare Metabase direttamente ai dati degli eventi di clic senza creare un ETL. Ora rispondiamo alla domanda 'quale campagna ha guidato la conversione da MQL a SQL?' da una dashboard Metabase senza infrastruttura aggiuntiva.”
“Meta CAPI server-side tramite Elido ha recuperato l'attribuzione su circa il 25% delle conversioni che il nostro pixel lato client stava perdendo. La configurazione ha richiesto uno sprint; il miglioramento della precisione dell'attribuzione è stato immediato.”
“Consumiamo il firehose di Kafka nel nostro processore di streaming. Il ritardo dell'evento inferiore a 5 secondi significa che le nostre dashboard sulle prestazioni dei link in tempo reale non mentono al team editoriale durante gli eventi dal vivo.”
Analisi Elido vs Bitly Analytics vs Heap
Bitly Analytics è adeguato per il conteggio dei clic e la geografia di base. Heap è una piattaforma completa di analisi del prodotto. Il confronto seguente mostra onestamente dove ogni opzione rappresenta lo strumento giusto.
| Capability | Elido | Bitly Analytics | Heap |
|---|---|---|---|
| Campionamento dei dati dei clic | 0% — ogni evento memorizzato | Aggregati; eventi grezzi non accessibili | Dipende dal piano sul livello gratuito |
| Accesso SQL diretto | DSN ClickHouse in sola lettura (Business) | Nessun accesso diretto al database | Heap Data Lake (esportazione warehouse) |
| Esportazione pianificata su BigQuery/Snowflake | Sì, Business+ | Solo esportazione CSV | Sì — funzionalità principale |
| Kafka firehose in tempo reale | Sì, Business+ | Non disponibile | Non disponibile |
| Inoltro delle conversioni server-side | GA4 MP, Meta CAPI, Mixpanel — deduplicati | Non disponibile | Ingestione eventi server-side (eventi di prodotto) |
| Tracciamento a livello di utente | No — solo a livello di clic, nessuna identità utente | No | Sì — funzionalità principale |
| Funnel + conservazione di coorte | Coorti di clic su Business | No | Funnel completo + coorte — maturo |
| Conservazione degli eventi | Fino a 24 mesi grezzi | Contatori aggregati; grezzi non disponibili | Varia in base al piano |
Domande del team di analisi
Qual è lo schema ClickHouse esatto per gli eventi di clic?
Lo schema è pubblico su /docs/api-reference alla voce 'Eventi clic'. Campi chiave: click_id (UUID), link_id, workspace_id, occurred_at (timestamp UTC), country_iso2, region, city, device_type (mobile/tablet/desktop), os, browser, referrer_domain, utm_source, utm_medium, utm_campaign, utm_term, utm_content. I campi nullable sono nullable, non stringhe vuote. Le modifiche allo schema sono annunciate nel /changelog con una guida alla migrazione.
Esiste una guida per il consumer Kafka?
Sì — /docs/guides/kafka-firehose copre il server bootstrap, la configurazione del gruppo consumer, la rotazione dei certificati client ed esempi di codice consumer in Go e Python. Il topic è uno per workspace; il numero di partizioni è fisso a 12. Il reset dell'offset è 'earliest' per impostazione predefinita al primo inserimento nel gruppo consumer. Se stai costruendo su questa funzionalità, pianifica del tempo per il monitoraggio del ritardo del consumer (lag) — questa è la causa di errore più comune per i team che non lo configurano.
Posso unire gli eventi di clic con la mia tabella utenti?
Nel tuo warehouse, sì. Il modello standard è: esporta gli eventi di clic su BigQuery o Snowflake tramite esportazione pianificata, quindi esegui il join sui parametri UTM o su un parametro personalizzato user_id che aggiungi alle destinazioni dei tuoi link brevi. Elido non memorizza l'identità dell'utente negli eventi di clic — il click_id è un UUID casuale per ogni clic, non legato a un account utente.
Come funziona la deduplicazione delle conversioni server-side?
Quando invii una richiesta POST a un endpoint di conversione di Elido, includi il click_id che è stato restituito nella risposta al clic originale (viene passato come parametro di query all'URL di destinazione). Elido cerca il clic, verifica che non sia già stato attribuito e distribuisce la conversione a GA4 MP, Meta CAPI o Mixpanel con il contesto UTM del clic originale. Gli invii duplicati con lo stesso click_id sono idempotenti — vengono confermati ma non contati due volte.
Cosa succede se il mio consumer Kafka rimane indietro?
Gli eventi vengono conservati nel topic per 7 giorni. Se l'offset confermato (committed) del tuo gruppo consumer rimane indietro di oltre 7 giorni, gli eventi più vecchi andranno persi prima che il tuo consumer possa leggerli. Monitora il ritardo del consumer; imposta un avviso a 6 ore di ritardo come allarme preventivo. Se rimani indietro su un evento non recuperabile, l'esportazione pianificata su S3/BigQuery copre il vuoto — è un ottimo backup per il firehose.
Il DSN ClickHouse dà accesso ai dati di altri workspace?
No. Il DSN è limitato esclusivamente alla tabella degli eventi del tuo workspace, tramite un utente ClickHouse in sola lettura con sicurezza a livello di riga applicata. Non puoi vedere gli eventi di altri workspace. Il DSN è revocabile dalle impostazioni del workspace; ruotalo con la stessa frequenza delle chiavi API.
Esiste un numero minimo di campioni prima che le coorti di clic siano significative?
ClickHouse esegue la query di coorte su qualsiasi dimensione di dati esistente — non viene applicato alcun minimo. La significatività statistica è a tua discrezione. Una coorte di 50 clic fornisce un dato, ma è soggetta a rumore. Mostriamo conteggi grezzi e percentuali; non applichiamo lo smoothing bayesiano o intervalli di confidenza alle visualizzazioni delle coorti. Per un'analisi formale, esporta i dati ed esegui il tuo modello nel tuo warehouse.
Posso filtrare l'esportazione pianificata a un sottoinsieme di link?
Sì — i filtri di esportazione supportano: dominio specifico, ID campagna specifico, tag specifico o un intervallo di date. Un'esportazione filtrata è comunque incrementale; le esecuzioni successive aggiungono solo nuovi eventi che corrispondono al filtro. Se aggiungi una nuova condizione di filtro a un lavoro di esportazione esistente, dovrai creare un nuovo lavoro o eseguire un'esportazione completa una tantum per riempire lo storico del nuovo filtro.
Analyst’s reading list
Per-link breakdown, conversion attribution, cohort retention.
Server-side forwarding to GA4, Meta CAPI, Mixpanel.
OpenAPI 3.1 spec, click event schema, typed SDKs in TS / Py / Go.
HMAC-signed events, retry policy, Kafka firehose for high volume.
DSN setup, schema, BigQuery + Snowflake load patterns.
Non sei sicuro quale angolazione si adatti?
La maggior parte dei team inizia come uno e si sviluppa in tutti e quattro. Il nostro team di vendita può esaminare il tuo stack specifico in 20 minuti.