Click data you can actually query.
Mierzysz atrybucję, porzucenia w lejku i przyrost. Elido zapisuje każde kliknięcie w ClickHouse z surowym dostępem — bez próbkowania i opóźnień w agregacji.
- 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
Co oznacza 'analytics-first' w modelu danych Elido
Analityka większości skracaczy linków to zagregowane sumy. Poniższe funkcje wyjaśniają, co zmienia się, gdy surowy strumień kliknięć jest podstawowym artefaktem, a nie podsumowaniem.
Każde kliknięcie przechowywane — bez adnotacji 'po N zdarzeniach stosujemy próbkowanie'
Zdarzenia kliknięć są pozyskiwane przez temat Redpanda Kafka i zapisywane do ClickHouse przez serwis click-ingester. Nie ma warstwy próbkowania. Link z 10 kliknięciami i link z 10 milionami kliknięć mają każde zdarzenie w tej samej tabeli — schemat się nie zmienia, żadna agregacja nie jest stosowana podczas pozyskiwania. Retencja wynosi 90 dni w planie Free, 12 miesięcy w Pro i 24 miesiące w Business. Po upływie okna retencji zdarzenia są trwale usuwane; liczba usuniętych zdarzeń jest logowana. Schemat ClickHouse jest publiczny — możesz zobaczyć dokładnie, jakie pola są przechowywane, co oznacza, że możesz zaplanować model danych w swoim magazynie danych przed rozpoczęciem eksportu. Opóźnienie zdarzeń od kliknięcia do dostępności w ClickHouse wynosi typowo poniżej 5 sekund; konsument Redpanda działa z automatycznym committem i rejestruje metryki opóźnienia, dzięki czemu możesz zobaczyć, czy pipeline nie pozostaje w tyle.
GA4 MP, Meta CAPI i Mixpanel po stronie serwera — deduplikowane względem kliknięcia
Piksele po stronie klienta pomijają znaczną część konwersji w zależności od penetracji adblockerów i ITP w iOS Safari. Przekazywanie po stronie serwera wysyła konwersję do GA4 Measurement Protocol, Meta Conversions API lub Mixpanel bezpośrednio z backendu Elido — bez konieczności używania JS po stronie klienta. Kluczem deduplikacji jest ID kliknięcia: gdy zdarzenie konwersji dotrze przez webhook Stripe lub Shopify, Elido dopasowuje je do źródłowego kliknięcia i rozsyła do wszystkich skonfigurowanych endpointów po stronie serwera. ID kliknięcia jest przekazywany jako parametr zapytania do docelowego URL w momencie kliknięcia; Twój flow zakupowy powinien go zachować aż do zdarzenia konwersji. Każde przekazane zdarzenie niesie oryginalne parametry UTM z kliknięcia, dzięki czemu atrybucja przeżywa cały lejek. Jest to przydatne do odzyskiwania konwersji pomijanych przez piksele po stronie klienta — nie zastępuje pełnego CDP, ale zamyka powszechną lukę w atrybucji ostatniego kliknięcia.
Własny read-only ClickHouse DSN per workspace — podłącz bezpośrednio do Metabase, Hex lub Grafana
Workspace'y Business otrzymują read-only ClickHouse DSN z zasięgiem ograniczonym do ich tabeli zdarzeń. Skieruj Metabase, Hex, Apache Superset, Grafana lub dowolny klient zgodny z ClickHouse na DSN i pisz SQL bezpośrednio na swoich danych zdarzeń kliknięć. DSN można rotować bez zmiany tabeli zdarzeń; łączy się z użytkownikiem read-only, który może tylko SELECT, nie INSERT ani DROP. Schemat ClickHouse jest stabilny i wersjonowany; zmiany schematu otrzymują przewodnik migracji w changelogu przed ich wprowadzeniem. Dla zespołów, które chcą łączyć zdarzenia kliknięć z własnymi danymi produktowymi — 'które linki przyciągnęły użytkowników, którzy następnie się aktywowali?' — wzorzec polega na kopiowaniu zdarzeń kliknięć do własnego magazynu danych przez zaplanowany eksport, a następnie łączeniu tam. ClickHouse DSN jest dla zespołów, których narzędzie BI może połączyć się bezpośrednio z ClickHouse i które nie potrzebują łączyć z zewnętrznymi tabelami.
Zaplanowane eksporty do S3, BigQuery i Snowflake
Zaplanowany eksport działa w konfigurowalnym rytmie (co godzinę, dziennie) i przesyła strumień zdarzeń kliknięć — lub podzbiór filtrowany według domeny, kampanii lub taga linku — do S3, BigQuery lub Snowflake. Eksport S3 domyślnie używa Parquet (dostępny JSON); BigQuery i Snowflake używają natywnych konektorów ze schematem tworzonym i aktualizowanym przez Elido. Eksporty przyrostowe są kluczowane na timestampie zdarzenia; pierwszy eksport to pełne uzupełnienie w ramach okna retencji; kolejne eksporty dołączają tylko nowe zdarzenia. Jeśli potrzebujesz odtworzyć dane od określonego timestampu, jednorazowy pełny eksport jest dostępny przez zgłoszenie do supportu. Błędy eksportu są logowane i ponawiane; powiadomienie dead-letter trafia na adres e-mail workspace, jeśli batch nie powiedzie się przez ponad 2 godziny.
Konsument Kafka w czasie rzeczywistym dla pipeline'ów zdarzeń, które nie mogą czekać na eksporty wsadowe
Workspace'y Business mogą konsumować zdarzenia kliknięć bezpośrednio z tematu Redpanda jako grupa konsumentów Kafka. Otrzymujesz ID grupy konsumentów, serwer bootstrap i certyfikat klienta — standardowa konfiguracja konsumenta Kafka. To właściwa ścieżka dla alertów w czasie rzeczywistym (wykrywanie skoków na linku, flagowanie anomalii geograficznych), dashboardów czasu rzeczywistego wymagających danych poniżej sekundy oraz pipeline'ów, gdzie rytm zaplanowanego eksportu jest zbyt wolny. Firehose dostarcza każde zdarzenie przynajmniej raz; Twój konsument jest odpowiedzialny za idempotentność przy odtwarzaniu. Retencja tematu wynosi 7 dni; jeśli konsument pozostanie w tyle o więcej niż 7 dni, zdarzenia zostaną utracone — ustaw monitoring opóźnienia konsumenta. To nie jest funkcja analityczna dla początkujących; wymaga kodu konsumenta Kafka i doświadczenia operacyjnego z grupami konsumentów. Jeśli zaplanowany eksport do BigQuery zapewnia to, czego potrzebujesz, zacznij od niego.
Stack you’ll touch
- Surowe zdarzenia kliknięć
- Bezpośredni dostęp do ClickHouse
- GA4 / Meta CAPI / Mixpanel
- Eksport do S3 + BigQuery
- DSN dla każdego workspace
- Webhook firehose
Co będziesz mierzyć
- Wskaźnik próbkowania
- 0% — każde kliknięcie zapisane
- Opóźnienie zapisu zdarzeń
- Poniżej 5 sekund
- Horyzont retencji
- Do 24 miesięcy
Zespoły analityczne korzystające z tego rozwiązania
Nazwy są tymczasowymi placeholderami — prawdziwe nazwy klientów pojawią się tutaj po opublikowaniu case studies.
“ClickHouse DSN pozwolił nam podłączyć Metabase bezpośrednio do danych zdarzeń kliknięć bez budowania ETL. Teraz odpowiadamy na pytanie 'która kampania przyciągnęła konwersję MQL-do-SQL?' z dashboardu Metabase bez dodatkowej infrastruktury.”
“Meta CAPI po stronie serwera przez Elido odzyskało atrybucję na około 25% konwersji, które nasz piksel po stronie klienta pomijał. Konfiguracja zajęła jeden sprint; poprawa dokładności atrybucji była natychmiastowa.”
“Konsumujemy firehose Kafka do własnego procesora strumieniowego. Opóźnienie zdarzeń poniżej 5 sekund oznacza, że nasze dashboardy wydajności linków w czasie rzeczywistym nie wprowadzają w błąd zespołu redakcyjnego podczas wydarzeń na żywo.”
Analityka Elido vs Bitly Analytics vs Heap
Bitly Analytics jest wystarczające do liczby kliknięć i podstawowego geo. Heap to pełna platforma analityki produktowej. Poniższe porównanie jest uczciwe co do tego, gdzie każda opcja jest właściwym narzędziem.
| Capability | Elido | Bitly Analytics | Heap |
|---|---|---|---|
| Próbkowanie danych kliknięć | 0% — każde zdarzenie przechowywane | Zagregowane; surowe zdarzenia niedostępne | Zależy od planu w bezpłatnym tierze |
| Bezpośredni dostęp SQL | Read-only ClickHouse DSN (Business) | Brak bezpośredniego dostępu do bazy danych | Heap Data Lake (eksport do magazynu danych) |
| Zaplanowany eksport do BigQuery/Snowflake | Tak, Business+ | Wyłącznie eksport CSV | Tak — kluczowa funkcja |
| Firehose Kafka w czasie rzeczywistym | Tak, Business+ | Niedostępne | Niedostępne |
| Przekazywanie konwersji po stronie serwera | GA4 MP, Meta CAPI, Mixpanel — deduplikowane | Niedostępne | Pozyskiwanie zdarzeń po stronie serwera (zdarzenia produktowe) |
| Śledzenie na poziomie użytkownika | Nie — wyłącznie na poziomie kliknięcia, bez tożsamości użytkownika | Nie | Tak — kluczowa funkcja |
| Lejek i retencja kohortowa | Kohorty kliknięć w Business | Nie | Pełny lejek i kohorty — dojrzałe |
| Retencja zdarzeń | Do 24 miesięcy surowych danych | Zagregowane liczniki; surowe dane niedostępne | Zależy od planu |
Pytania zespołów analitycznych
Jaki jest dokładny schemat ClickHouse dla zdarzeń kliknięć?
Schemat jest publiczny pod /docs/api-reference w sekcji 'Click events'. Kluczowe pola: 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. Pola nullable są nullable, nie pustymi ciągami. Zmiany schematu są ogłaszane w /changelog z przewodnikiem migracji.
Czy istnieje przewodnik konsumenta Kafka?
Tak — /docs/guides/kafka-firehose omawia serwer bootstrap, konfigurację grupy konsumentów, rotację certyfikatu klienta i przykładowy kod konsumenta w Go i Python. Temat jest jeden na workspace; liczba partycji jest stała i wynosi 12. Reset offsetu jest domyślnie ustawiony na earliest przy pierwszym dołączeniu grupy konsumentów. Jeśli budujesz na tej podstawie, zaplanuj czas na monitoring opóźnienia konsumenta — to tryb awarii, który dotyka zespołów, które go nie skonfigurują.
Czy mogę łączyć zdarzenia kliknięć z własną tabelą użytkowników?
W swoim magazynie danych, tak. Standardowy wzorzec to: eksportuj zdarzenia kliknięć do BigQuery lub Snowflake przez zaplanowany eksport, następnie łącz po parametrach UTM lub niestandardowym parametrze user_id, który dołączasz do swoich docelowych URL krótkich linków. Elido nie przechowuje tożsamości użytkownika w zdarzeniach kliknięć — click_id to losowy UUID per kliknięcie, niezwiązany z kontem użytkownika.
Jak działa deduplikacja konwersji po stronie serwera?
Gdy wysyłasz żądanie POST zdarzenia konwersji do endpointu konwersji Elido, podajesz click_id zwrócony w oryginalnej odpowiedzi na kliknięcie (jest przekazywany jako parametr zapytania do docelowego URL). Elido wyszukuje kliknięcie, sprawdza, czy nie zostało już zaatrybuowane, i rozsyła konwersję do GA4 MP, Meta CAPI lub Mixpanel z kontekstem UTM oryginalnego kliknięcia. Zduplikowane zgłoszenia z tym samym click_id są idempotentne — są potwierdzane, ale nie są zliczane podwójnie.
Co się dzieje, gdy mój konsument Kafka pozostaje w tyle?
Zdarzenia są przechowywane w temacie przez 7 dni. Jeśli zatwierdzony offset grupy konsumentów pozostanie w tyle o więcej niż 7 dni, starsze zdarzenia zostaną utracone przed odczytaniem przez konsumenta. Monitoruj opóźnienie konsumenta; ustaw alert przy 6-godzinnym opóźnieniu jako wczesne ostrzeżenie. Jeśli nie możesz odzyskać zdarzenia z firehose, zaplanowany eksport do S3/BigQuery pokrywa tę lukę — to dobra kopia zapasowa dla firehose.
Czy ClickHouse DSN daje dostęp do danych innych workspace'ów?
Nie. DSN jest ograniczony wyłącznie do tabeli zdarzeń Twojego workspace'u, przez read-only użytkownika ClickHouse z zastosowanym zabezpieczeniem na poziomie wierszy. Nie możesz widzieć zdarzeń innych workspace'ów. DSN można odwołać w ustawieniach workspace'u; rotuj go w tym samym rytmie co klucze API.
Czy istnieje minimalna wielkość próbki, zanim kohorty kliknięć mają sens?
ClickHouse wykonuje zapytanie kohortowe na dowolnym istniejącym zbiorze danych — nie jest wymuszane żadne minimum. Statystyczna miarodajność to Twoja ocena. Kohorta 50 kliknięć daje Ci liczbę, ale jest zaszumiona. Wyświetlamy surowe liczby i procenty; nie stosujemy wygładzania bayesowskiego ani przedziałów ufności do widoków kohortowych. Do formalnej analizy eksportuj dane i uruchom swój model w magazynie danych.
Czy mogę filtrować zaplanowany eksport do podzbioru linków?
Tak — filtry eksportu obsługują: konkretną domenę, konkretne ID kampanii, konkretny tag lub zakres dat. Filtrowany eksport jest nadal przyrostowy; kolejne uruchomienia dołączają tylko nowe zdarzenia pasujące do filtra. Jeśli dodasz nowy warunek filtru do istniejącego zadania eksportu, musisz albo utworzyć nowe zadanie, albo wykonać jednorazowy pełny ponowny eksport w celu uzupełnienia historii nowego filtra.
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.
Nie wiesz, która perspektywa pasuje?
Większość zespołów zaczyna od jednej, a potem rozszerza się na wszystkie cztery. Nasz zespół sprzedaży może omówić Twój konkretny stos w 20 minut.