Dati sui clic che puoi realmente interrogare.
Misuri attribuzione, drop-off del funnel e incremento incrementale. Elido archivia ogni clic in un archivio di analisi colonnare con accesso raw - nessun campionamento, nessun ritardo di aggregazione.
- Nessun campionamento dei clic in nessun tier - ogni evento archiviato
- DSN di analisi per workspace, in sola lettura, ruotabile
- Export pianificato S3 + BigQuery (Parquet di default)
- Eventi clic raw tramite webhook firehose / consumer Kafka
Come arrivano i dati sui clic
Clic → flusso di eventi → archivio di analisi, senza aggregazione nel mezzo.
La maggior parte degli accorciatori ti dà un contatore. Noi ti diamo una riga per clic, acquisita in meno di cinque secondi, interrogabile dal tuo client SQL. La pipeline è un topic compatibile con Kafka che un consumer drena nell'archivio di analisi - nessun servizio di aggregazione, nessun riepilogo giornaliero, nessuna nota 'campionato dopo 10K'.
- Step 1
Click
elido.me/x → 302Edge POP returns the destination + emits an event to our event stream.
- Step 2
Event stream
topic: clicks.<workspace>12 partitions, at-least-once delivery, 7-day topic retention.
- Step 3
Analytics store
<5s p99 ingest lagOur ingestion service 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.
DSN di analisi per workspace
Un DSN in sola lettura da incollare direttamente in Metabase.
I workspace Business ricevono un DSN di analisi per workspace, in sola lettura, con scope sulla tabella eventi tramite row-level security. Collegalo a Metabase, Hex, Apache Superset, Grafana o qualsiasi client SQL/BI compatibile. Il DSN è ruotabile dalle impostazioni workspace senza cambiare la tabella sottostante.
- Schema stabileVersionato in /docs/api-reference; guide migrazione in /changelog
- Row-level securityDSN con scope sulle righe di eventi del tuo workspace
- Compatibile con strumenti BIMetabase, Hex, Superset, Grafana, Looker - qualsiasi cosa parli SQL
- Query sub-secondoTabelle da 1B righe sotto 1s per aggregazioni tipiche group-by-country / hour
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 |
Geo che sopravvive all'export
Densità a livello paese su ogni clic - non un bucket hashato.
Ogni evento clic include paese ISO 3166-1 alpha-2, regione e città, risolti da un dataset geo-IP offline al momento dell'edge. L'IP stesso viene troncato a /24 (IPv4) o /48 (IPv6) prima della memorizzazione, così il geo persiste ma i dati personali no. Di seguito gli stessi dati nell'interfaccia che arrivano nel tuo warehouse - nessun tier di aggregazione nel mezzo.
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.
Export verso data warehouse
Parquet orario su S3, poi un trasferimento nativo nel tuo warehouse.
L'export pianificato invia gli eventi clic come Parquet nel tuo bucket S3 con cadenza oraria o giornaliera; il trasferimento nativo BigQuery o la tabella esterna Snowflake lo carica da lì. La prima esecuzione è un backfill completo fino alla tua finestra di retention; le esecuzioni successive aggiungono solo nuovi eventi con chiave sul timestamp. I fallimenti vengono ritentati; una notifica dead-letter parte se un batch non arriva entro 2 ore.
- Parquet (default) o JSON; un oggetto per bucket orario
- Filtra export per dominio, campagna o tag link
- Trasferimento nativo BigQuery + tabella esterna Snowflake
- Alert dead-letter su fallimento batch >2h
- Firehose Kafka per consegna sub-secondo (Business)
Cosa puoi fare
- Nessun campionamento dei clic in nessun tier - ogni evento archiviato
- DSN di analisi per workspace, in sola lettura, ruotabile
- Export pianificato S3 + BigQuery (Parquet di default)
- Eventi clic raw tramite webhook firehose / consumer Kafka
- Latenza di query sub-secondo su tabelle con 1B+ righe
- Attribuzione clic server-side con deduplicazione click-ID
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 compatibile con Kafka e scritti nell'archivio di analisi dal nostro servizio di ingestione. 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 eventi è 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 analisi è in genere inferiore a 5 secondi; il consumer 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 di analisi in sola lettura per workspace - collegalo direttamente a Metabase, Hex o Grafana
I workspace Business ottengono un DSN di analisi in sola lettura per workspace limitato alla loro tabella degli eventi. Punta Metabase, Hex, Apache Superset, Grafana o qualsiasi client SQL/BI compatibile 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 eventi è 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 di analisi è per i team il cui strumento di BI può connettersi direttamente tramite SQL standard 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 compatibile con Kafka 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 che utilizzerai
- Eventi clic raw
- Accesso SQL diretto
- 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 di analisi in sola lettura 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.
| Capacità | 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 di analisi 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 eventi 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 di analisi dà accesso ai dati di altri workspace?
No. Il DSN è limitato esclusivamente alla tabella degli eventi del tuo workspace, tramite un utente 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?
L'archivio di analisi 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.
Lista di lettura dell'analista
Breakdown per link, attribuzione conversioni, retention coorte.
Inoltro server-side a GA4, Meta CAPI, Mixpanel.
Spec OpenAPI 3.1, schema evento clic, SDK tipizzati in TS / Py / Go.
Event firmati con HMAC, policy di retry, firehose Kafka per alti volumi.
Configurazione DSN, schema, pattern di caricamento BigQuery + Snowflake.
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.