Date de click pe care chiar le poți interoga.
Măsori atribuirea, abandonurile din funnel și creșterea incrementală. Elido stochează fiecare click într-o stocare de analiză columnară, cu acces la date brute - fără eșantionare, fără întârziere de agregare.
- Fără eșantionare de clickuri pe niciun plan - fiecare eveniment stocat
- DSN de analiză per workspace, doar-citire, rotativ
- Export programat S3 + BigQuery (Parquet implicit)
- Evenimente brute de click prin firehose webhook / consumator Kafka
Cum ajung datele de click
Click → flux de evenimente → stocare de analiză, fără agregare la mijloc.
Majoritatea shortener-elor îți oferă un contor. Noi îți oferim un rând per click, ingerat în mai puțin de cinci secunde, interogabil din propriul tău client SQL. Pipeline-ul este un singur binar care scrie într-un singur topic compatibil Kafka, pe care un singur consumator îl golește în stocarea de analiză - fără serviciu de agregare, fără rezumate zilnice, fără notă de subsol „eșantionat după 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 de analiză per workspace
Un DSN doar-citire pe care îl poți lipi direct în Metabase.
Workspace-urile Business primesc un DSN de analiză doar-citire per workspace, limitat la tabelul lor de evenimente prin securitate la nivel de rând. Conectează-l în Metabase, Hex, Apache Superset, Grafana sau orice client SQL/BI compatibil. DSN-ul este rotativ din setările workspace-ului, fără să schimbi tabelul de bază.
- Schemă stabilăVersionată la /docs/api-reference; ghiduri de migrare în /changelog
- Securitate la nivel de rândDSN limitat exclusiv la rândurile de evenimente ale workspace-ului tău
- Compatibil cu instrumente de BIMetabase, Hex, Superset, Grafana, Looker - orice vorbește SQL
- Interogări sub-secundăTabele cu 1 miliard de rânduri sub 1s, pentru agregări tipice group-by-country / oră
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 |
Geografie care supraviețuiește exportului
Densitate la nivel de țară pe fiecare click - nu un bucket hash-uit.
Fiecare eveniment de click include țara ISO 3166-1 alpha-2, regiunea și orașul, rezolvate dintr-un set de date geo-IP offline la momentul edge. IP-ul în sine este trunchiat la /24 (IPv4) sau /48 (IPv6) înainte de stocare, astfel încât datele geo persistă, dar PII nu. Mai jos sunt aceleași date din interfață care ajung în warehouse-ul tău - fără niciun nivel de agregare la mijloc.
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 către warehouse
Parquet orar către S3, apoi un transfer nativ în warehouse-ul tău.
Exportul programat trimite evenimentele de click ca Parquet către bucket-ul tău S3, la o cadență orară sau zilnică; BigQuery Transfer nativ sau tabelul extern Snowflake le încarcă de acolo. Prima rulare este un backfill complet până la fereastra ta de retenție; rulările ulterioare adaugă doar evenimente noi, indexate pe marca temporală a evenimentului. Eșecurile se reîncearcă; o notificare dead-letter se declanșează dacă un lot nu poate ajunge în termen de 2 ore.
- Parquet (implicit) sau JSON; un obiect per bucket-oră
- Filtrează exportul după domeniu, campanie sau etichetă de link
- BigQuery Transfer nativ + tabel extern Snowflake
- Alertă dead-letter la eșec de lot de peste 2 ore
- Firehose Kafka pentru livrare sub-secundă (Business)
Ce poți face
- Fără eșantionare de clickuri pe niciun plan - fiecare eveniment stocat
- DSN de analiză per workspace, doar-citire, rotativ
- Export programat S3 + BigQuery (Parquet implicit)
- Evenimente brute de click prin firehose webhook / consumator Kafka
- Latență de interogare sub-secundă pe tabele cu peste 1 miliard de rânduri
- Atribuire de click server-side, cu deduplicare pe click-ID
Ce înseamnă „analytics-first” în modelul de date al Elido
Majoritatea analizelor de shortener sunt totaluri agregate. Funcționalitățile de mai jos explică ce se schimbă atunci când fluxul brut de clickuri este artefactul principal, nu un rezumat.
Fiecare click stocat - fără notă de subsol „după N evenimente eșantionăm”
Evenimentele de click sunt ingerate printr-un topic compatibil Kafka și scrise în stocarea de analiză de serviciul nostru de ingestie. Nu există niciun nivel de eșantionare. Un link cu 10 clickuri și un link cu 10 milioane de clickuri au ambele fiecare eveniment în același tabel - schema nu se schimbă, nicio agregare nu se aplică la momentul ingestiei. Retenția este de 90 de zile pe Free, 12 luni pe Pro și 24 de luni pe Business. După fereastra de retenție, evenimentele sunt șterse definitiv; numărul de evenimente șterse este înregistrat. Schema evenimentelor este publică - poți vedea exact ce câmpuri sunt stocate, ceea ce înseamnă că îți poți planifica modelul de date în warehouse-ul tău înainte să începi să exporți. Întârzierea evenimentelor de la click până la disponibilitatea în analiză este de obicei sub 5 secunde; consumatorul rulează cu auto-commit și înregistrează metrici de întârziere, astfel încât poți vedea dacă pipeline-ul rămâne în urmă.
GA4 MP, Meta CAPI și Mixpanel server-side - deduplicate față de click
Pixelii client-side pierd o parte semnificativă din conversii, în funcție de penetrarea ad-blockerelor și de iOS Safari ITP. Redirecționarea server-side trimite conversia către GA4 Measurement Protocol, Meta Conversions API sau Mixpanel direct din backend-ul Elido - fără JS client-side necesar. Cheia de deduplicare este ID-ul de click: când un eveniment de conversie sosește prin webhook Stripe sau Shopify, Elido îl potrivește cu clickul de origine și îl distribuie către toate endpoint-urile server-side configurate. ID-ul de click este transmis ca parametru query către URL-ul de destinație la momentul clickului; fluxul tău de checkout ar trebui să îl păstreze până la evenimentul de conversie. Fiecare eveniment redirecționat poartă parametrii UTM originali din click, astfel încât atribuirea supraviețuiește întregului funnel. Acest lucru este util pentru recuperarea conversiilor pe care pixelii client-side le pierd - nu este un înlocuitor pentru un CDP complet, dar închide decalajul obișnuit de atribuire last-click.
DSN de analiză doar-citire per workspace - conectezi direct în Metabase, Hex sau Grafana
Workspace-urile Business primesc un DSN de analiză doar-citire per workspace, limitat la tabelul lor de evenimente. Îndrepți Metabase, Hex, Apache Superset, Grafana sau orice client SQL/BI compatibil către DSN și scrii SQL direct pe datele tale de evenimente de click. DSN-ul este rotativ fără să schimbi tabelul de evenimente; se conectează la un utilizator doar-citire care poate doar SELECT, nu INSERT sau DROP. Schema evenimentelor este stabilă și versionată; modificările de schemă primesc un ghid de migrare în changelog înainte de a intra în vigoare. Pentru echipele care vor să combine evenimentele de click cu propriile lor date de produs - „ce linkuri au adus utilizatori care apoi s-au activat?” - tiparul este să copiezi evenimentele de click în propriul tău warehouse prin export programat, apoi să le combini acolo. DSN-ul de analiză este pentru echipele al căror instrument de BI se poate conecta direct prin SQL standard și care nu au nevoie să combine cu tabele externe.
Exporturi programate către S3, BigQuery și Snowflake
Exportul programat rulează la o cadență configurabilă (orar, zilnic) și trimite fluxul de evenimente de click - sau un subset filtrat după domeniu, campanie sau etichetă de link - către S3, BigQuery sau Snowflake. Exportul S3 folosește implicit Parquet (JSON disponibil); BigQuery și Snowflake folosesc conectorii nativi, cu o schemă pe care Elido o creează și o menține actuală. Exporturile incrementale sunt indexate pe marca temporală a evenimentului; primul export este un backfill complet până la fereastra ta de retenție; exporturile ulterioare adaugă doar evenimente noi. Dacă ai nevoie să reiei de la o marcă temporală specifică, un export complet unic este disponibil printr-o cerere de suport. Eșecurile de export sunt înregistrate și reîncercate; o notificare dead-letter ajunge la emailul workspace-ului, dacă un lot eșuează mai mult de 2 ore.
Consumator Kafka în timp real pentru pipeline-uri de evenimente care nu pot aștepta exporturile în loturi
Workspace-urile Business pot consuma evenimente de click direct dintr-un topic compatibil Kafka, ca grup de consumatori Kafka. Primești un ID de grup de consumatori, un server bootstrap și un certificat de client - configurare standard de consumator Kafka. Aceasta este calea potrivită pentru alertare în timp real (detectarea vârfurilor pe un link, semnalarea anomaliilor geografice), dashboard-uri în timp real care au nevoie de date sub-secundă și pipeline-uri unde cadența exportului programat este prea lentă. Firehose-ul livrează fiecare eveniment cel puțin o dată; consumatorul tău este responsabil pentru idempotență la reluare. Retenția topicului este de 7 zile; dacă consumatorul tău rămâne în urmă mai mult de 7 zile, evenimentele se pierd - configurează monitorizare pentru întârzierea consumatorului. Aceasta nu este o funcționalitate de analiză pentru începători; necesită cod de consumator Kafka și experiență operațională cu grupuri de consumatori. Dacă exportul programat către BigQuery îți oferă ce ai nevoie, începe de acolo.
Stack-ul cu care vei lucra
- Evenimente brute de click
- Acces SQL direct
- GA4 / Meta CAPI / Mixpanel
- Export S3 + BigQuery
- DSN per workspace
- Firehose webhook
Ce vei măsura
- Rata de eșantionare
- 0% - fiecare click stocat
- Întârzierea ingestiei de evenimente
- Sub 5 secunde
- Orizontul de retenție
- Până la 24 de luni
Echipe de analiză care rulează pe această platformă
Numele sunt deocamdată substituenți - numele reale ale clienților vor apărea aici pe măsură ce studiile de caz sunt publicate.
“DSN-ul de analiză doar-citire ne-a permis să conectăm Metabase direct la datele de evenimente de click, fără să construim un ETL. Acum răspundem la „ce campanie a condus conversia MQL-to-SQL?” dintr-un dashboard Metabase, fără infrastructură suplimentară.”
“Meta CAPI server-side prin Elido a recuperat atribuirea pentru aproximativ 25% din conversiile pe care pixelul nostru client-side le pierdea. Configurarea a fost un sprint; îmbunătățirea acurateței atribuirii a fost imediată.”
“Consumăm firehose-ul Kafka în propriul nostru procesor de stream. O întârziere de sub 5 secunde per eveniment înseamnă că dashboard-urile noastre de performanță a linkurilor, în timp real, nu mint echipa editorială în timpul evenimentelor live.”
Analiza Elido vs Bitly Analytics vs Heap
Bitly Analytics este adecvat pentru numărătoarea de clickuri și geo de bază. Heap este o platformă completă de analiză de produs. Comparația de mai jos este onestă despre unde fiecare opțiune este instrumentul potrivit.
| Capabilitate | Elido | Bitly Analytics | Heap |
|---|---|---|---|
| Eșantionarea datelor de click | 0% - fiecare eveniment stocat | Agregat; evenimentele brute nu sunt accesibile | Dependent de plan, pe nivelul gratuit |
| Acces SQL direct | DSN de analiză doar-citire (Business) | Fără acces direct la BD | Heap Data Lake (export către warehouse) |
| Export programat către BigQuery/Snowflake | Da, Business+ | Doar export CSV | Da - funcționalitate de bază |
| Firehose Kafka în timp real | Da, Business+ | Indisponibil | Indisponibil |
| Redirecționare server-side a conversiilor | GA4 MP, Meta CAPI, Mixpanel - deduplicate | Indisponibil | Ingestie de evenimente server-side (evenimente de produs) |
| Urmărire la nivel de utilizator | Nu - doar la nivel de click, fără identitate de utilizator | Nu | Da - funcționalitate de bază |
| Retenție de funnel + cohortă | Cohorte de click pe Business | Nu | Funnel + cohortă complete - matur |
| Retenția evenimentelor | Până la 24 de luni, brute | Contoare agregate; brute indisponibile | Variază în funcție de plan |
Întrebări din partea echipelor de analiză
Care este schema exactă a evenimentelor de click?
Schema este publică la /docs/api-reference, sub „Click events”. Câmpuri cheie: click_id (UUID), link_id, workspace_id, occurred_at (marcă temporală UTC), country_iso2, region, city, device_type (mobil/tabletă/desktop), os, browser, referrer_domain, utm_source, utm_medium, utm_campaign, utm_term, utm_content. Câmpurile care pot fi null sunt null, nu șiruri goale. Modificările de schemă sunt anunțate în /changelog, cu un ghid de migrare.
Există un ghid de consumator Kafka?
Da - /docs/guides/kafka-firehose acoperă serverul bootstrap, configurarea grupului de consumatori, rotirea certificatului de client și cod exemplu de consumator în Go și Python. Există câte un topic per workspace; numărul de partiții este fixat la 12. Resetarea offset-ului este implicit „earliest” la prima alăturare a grupului de consumatori. Dacă construiești pe baza acestui lucru, alocă timp pentru monitorizarea întârzierii consumatorului - acesta este modul de eșec care afectează echipele care nu îl configurează.
Pot combina evenimentele de click cu propriul meu tabel de utilizatori?
În warehouse-ul tău, da. Tiparul standard este: exporți evenimentele de click către BigQuery sau Snowflake prin export programat, apoi combini pe baza parametrilor UTM sau a unui parametru user_id personalizat, pe care îl adaugi destinațiilor linkurilor tale scurte. Elido nu stochează identitate de utilizator în evenimentele de click - click_id este un UUID aleatoriu per click, nelegat de un cont de utilizator.
Cum funcționează deduplicarea conversiilor server-side?
Când trimiți un POST cu un eveniment de conversie către endpoint-ul de conversii al Elido, incluzi click_id-ul returnat în răspunsul original al clickului (este transmis ca parametru query către URL-ul de destinație). Elido caută clickul, verifică dacă nu a fost deja atribuit și distribuie conversia către GA4 MP, Meta CAPI sau Mixpanel, cu contextul UTM al clickului original. Trimiterile duplicate cu același click_id sunt idempotente - sunt confirmate, dar nu numărate de două ori.
Ce se întâmplă dacă consumatorul meu Kafka rămâne în urmă?
Evenimentele sunt păstrate în topic timp de 7 zile. Dacă offset-ul confirmat al grupului tău de consumatori rămâne în urmă mai mult de 7 zile, evenimentele mai vechi se vor pierde înainte ca consumatorul tău să le citească. Monitorizează întârzierea consumatorului; configurează o alertă la o întârziere de 6 ore, ca avertisment timpuriu. Dacă rămâi în urmă pe un eveniment nerecuperabil, exportul programat către S3/BigQuery acoperă golul - este un backup bun pentru firehose.
DSN-ul de analiză oferă acces la datele altor workspace-uri?
Nu. DSN-ul este limitat exclusiv la tabelul de evenimente al workspace-ului tău, printr-un utilizator doar-citire cu securitate la nivel de rând aplicată. Nu poți vedea evenimentele altor workspace-uri. DSN-ul poate fi revocat din setările workspace-ului; rotește-l la aceeași cadență ca și cheile API.
Există o dimensiune minimă de eșantion înainte ca cohortele de click să fie relevante?
Stocarea de analiză rulează interogarea de cohortă la orice dimensiune de date există - nu se impune niciun minim. Relevanța statistică este decizia ta. O cohortă de 50 de clickuri îți oferă un număr, dar este zgomotos. Afișăm numărători și procente brute; nu aplicăm netezire bayesiană sau intervale de încredere vizualizărilor de cohortă. Pentru analiză formală, exportă și rulează-ți modelul în warehouse-ul tău.
Pot filtra exportul programat la un subset de linkuri?
Da - filtrele de export suportă: domeniu specific, ID de campanie specific, etichetă specifică sau un interval de date. Un export filtrat este tot incremental; rulările ulterioare adaugă doar evenimente noi care se potrivesc filtrului. Dacă adaugi o nouă condiție de filtrare la un job de export existent, va trebui fie să creezi un job nou, fie să faci un re-export complet unic, pentru a completa istoricul noului filtru.
Lista de lectură pentru analiști
Defalcare per link, atribuire de conversie, retenție de cohortă.
Redirecționare server-side către GA4, Meta CAPI, Mixpanel.
Specificație OpenAPI 3.1, schema evenimentelor de click, SDK-uri tipate în TS / Py / Go.
Evenimente semnate HMAC, politică de reîncercare, firehose Kafka pentru volum mare.
Configurare DSN, schemă, tipare de încărcare BigQuery + Snowflake.
Nu ești sigur ce unghi ți se potrivește?
Majoritatea echipelor încep dintr-un singur unghi și cresc spre toate cele patru. Echipa noastră de vânzări poate trece prin stack-ul tău specific în 20 de minute.