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
- Esportazione dei clic nel vostro bucket S3 (NDJSON gzip)
- 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
S3 export · Analytics APIScheduled or on-demand S3 export (gzip NDJSON), or the analytics REST API. A direct read-only DSN is planned.
Esportazione analytics e API
Eventi di clic nel tuo bucket; un DSN diretto in sola lettura è previsto.
I workspace Business possono esportare gli eventi di clic come gzip NDJSON nel proprio bucket S3, in modo pianificato o su richiesta, e caricarli nel data warehouse da cui leggono Metabase, Hex, Apache Superset, Grafana o Looker. Gli aggregati sono disponibili anche tramite l'API REST di analytics. Un DSN di analytics diretto in sola lettura è previsto e non ancora disponibile.
- Schema stabileVersionato in /docs/api-reference; guide alla migrazione in /changelog
- Archiviazione tuaFile gzip NDJSON nel tuo bucket S3, limitati al tuo workspace
- Compatibile con BICaricali nel warehouse dietro Metabase, Hex, Superset, Grafana, Looker
- API analyticsAggregati per paese, dispositivo, referrer e tempo via REST
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;Geo che sopravvive all'export
Densità a livello paese su ogni clic - non un bucket hashato.
Ogni evento di clic include paese, regione e città ISO 3166-1 alpha-2, risolti da un dataset geo-IP offline. L'indirizzo IP del visitatore viene conservato con l'evento di clic, quindi trattate i dati come personali ai sensi del GDPR. Sotto, gli stessi dati nell'interfaccia che arrivano nel vostro warehouse, senza livello di aggregazione in 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
- Esportazione dei clic nel vostro bucket S3 (NDJSON gzip)
- 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.
Esportazione dei clic su S3 - da caricare nel warehouse dietro Metabase, Hex o Grafana
I workspace Business possono esportare gli eventi di clic come NDJSON gzip nel proprio bucket S3, a pianificazione o su richiesta. Caricate i file nel warehouse dietro Metabase, Hex, Apache Superset, Grafana o qualsiasi client SQL/BI compatibile e scrivete lì SQL sui vostri dati di clic. Gli aggregati sono disponibili anche tramite l'API REST di analytics. Per i team che vogliono unire gli eventi di clic ai propri dati di prodotto - 'quali link hanno portato utenti che poi si sono attivati?' - copiate l'esportazione nel vostro warehouse e fate la join lì. Un DSN di analytics in sola lettura diretto, perché uno strumento BI si colleghi senza job di esportazione, è pianificato e non ancora disponibile.
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
- Esportazione dei clic su S3 (NDJSON gzip)
- 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
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.
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.
L'esportazione dei clic include i dati di altri workspace?
No. Le esportazioni contengono solo gli eventi del vostro workspace e vengono scritte nel vostro bucket S3. Un DSN di analytics in sola lettura diretto è pianificato e non ancora disponibile; quando uscirà, sarà limitato al vostro workspace.
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 dell'esportazione, 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.