Click data you can actually query.
Sie messen Attribution, Funnel-Drop-offs und Incremental Lift. Elido speichert jeden Klick in ClickHouse mit direktem Zugriff — ohne Sampling, ohne Aggregations-Lag.
- 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
Was 'Analytics-first' im Datenmodell von Elido bedeutet
Die meisten Shortener-Analytics sind aggregierte Summen. Die folgenden Funktionen erklären, was sich ändert, wenn der rohe Click-Stream das primäre Artefakt ist, nicht eine Zusammenfassung.
Jeder Click wird gespeichert – keine 'Sampling ab N Events'-Fußnote
Click-Events werden über ein Redpanda Kafka-Topic aufgenommen und vom click-ingester-Dienst in ClickHouse geschrieben. Es gibt keine Sampling-Ebene. Ein Link mit 10 Clicks und ein Link mit 10 Millionen Clicks haben beide jedes Event in derselben Tabelle – das Schema ändert sich nicht, beim Ingest wird keine Aggregation angewendet. Die Aufbewahrungsfrist beträgt 90 Tage bei Free, 12 Monate bei Pro und 24 Monate bei Business. Nach Ablauf des Aufbewahrungsfensters werden Events endgültig gelöscht; die Anzahl der gelöschten Events wird protokolliert. Das ClickHouse-Schema ist öffentlich – Sie können genau sehen, welche Felder gespeichert werden, was bedeutet, dass Sie Ihr Datenmodell in Ihrem Warehouse planen können, bevor Sie mit dem Export beginnen. Die Event-Verzögerung vom Click bis zur Verfügbarkeit in ClickHouse liegt normalerweise unter 5 Sekunden; der Redpanda-Consumer läuft mit Auto-Commit und protokolliert Verzögerungsmetriken, damit Sie sehen können, ob die Pipeline zurückfällt.
GA4 MP, Meta CAPI und Mixpanel serverseitig – dedupliziert gegen den Click
Clientseitige Pixel verpassen einen erheblichen Teil der Conversions, abhängig von der Adblocker-Durchdringung und iOS Safari ITP. Serverseitiges Forwarding sendet die Conversion direkt vom Elido-Backend an GA4 Measurement Protocol, Meta Conversions API oder Mixpanel – kein clientseitiges JS erforderlich. Der Deduplizierungsschlüssel ist die Click-ID: Wenn ein Conversion-Event über einen Stripe- oder Shopify-Webhook eingeht, ordnet Elido es dem ursprünglichen Click zu und verteilt es an alle konfigurierten serverseitigen Endpunkte. Die Click-ID wird zum Zeitpunkt des Clicks als Query-Parameter an die Ziel-URL übergeben; Ihr Checkout-Flow sollte diese bis zum Conversion-Event beibehalten. Jedes weitergeleitete Event trägt die ursprünglichen UTM-Parameter vom Click, sodass die Attribution über den gesamten Funnel erhalten bleibt. Dies ist nützlich, um Conversions wiederherzustellen, die clientseitige Pixel verpassen – es ist kein Ersatz für eine vollständige CDP, aber es schließt die häufige Last-Click-Attributionslücke.
Lesezugriff auf ClickHouse DSN pro Workspace – direkt in Metabase, Hex oder Grafana einbinden
Business-Workspaces erhalten einen pro Workspace schreibgeschützten ClickHouse DSN, der auf ihre Event-Tabelle beschränkt ist. Verbinden Sie Metabase, Hex, Apache Superset, Grafana oder einen anderen ClickHouse-kompatiblen Client mit dem DSN und schreiben Sie SQL direkt gegen Ihre Click-Event-Daten. Der DSN ist rotierbar, ohne die Event-Tabelle zu ändern; er verbindet sich mit einem schreibgeschützten Benutzer, der nur SELECT, aber nicht INSERT oder DROP ausführen kann. Das ClickHouse-Schema ist stabil und versioniert; Schemaänderungen erhalten vor ihrer Einführung einen Migrationsleitfaden im Changelog. Für Teams, die Click-Events mit ihren eigenen Produktdaten zusammenführen möchten – 'welche Links führten zu Nutzern, die später aktiviert haben?' – ist das Muster, Click-Events über einen geplanten Export in das eigene Warehouse zu kopieren und dort zusammenzuführen. Der ClickHouse DSN ist für Teams gedacht, deren BI-Tool sich direkt mit ClickHouse verbinden kann und die keine Verknüpfung mit externen Tabellen benötigen.
Geplante Exporte nach S3, BigQuery und Snowflake
Der geplante Export läuft in einem konfigurierbaren Rhythmus (stündlich, täglich) und überträgt den Click-Event-Stream – oder eine Teilmenge, gefiltert nach Domain, Kampagne oder Link-Tag – an S3, BigQuery oder Snowflake. Der S3-Export verwendet standardmäßig Parquet (JSON verfügbar); BigQuery und Snowflake nutzen die nativen Konnektoren mit einem Schema, das Elido erstellt und aktuell hält. Inkrementelle Exporte basieren auf dem Event-Zeitstempel; der erste Export ist ein vollständiger Backfill für Ihr Aufbewahrungsfenster; nachfolgende Exporte hängen nur neue Events an. Wenn Sie von einem bestimmten Zeitstempel aus wiederholen müssen, ist ein einmaliger vollständiger Export über eine Support-Anfrage verfügbar. Exportfehler werden protokolliert und wiederholt; eine Dead-Letter-Benachrichtigung geht an die Workspace-E-Mail, wenn ein Batch länger als 2 Stunden fehlschlägt.
Echtzeit-Kafka-Consumer für Event-Pipelines, die nicht auf Batch-Exporte warten können
Business-Workspaces können Click-Events direkt aus einem Redpanda-Topic als Kafka-Consumer-Gruppe konsumieren. Sie erhalten eine Consumer-Gruppen-ID, einen Bootstrap-Server und ein Client-Zertifikat – Standard-Kafka-Consumer-Konfiguration. Dies ist der richtige Weg für Echtzeit-Alerting (Spitzenerkennung auf einem Link, Flagging von Geo-Anomalien), Echtzeit-Dashboards, die Sub-Sekunden-Daten benötigen, und Pipelines, bei denen der geplante Export-Rhythmus zu langsam ist. Die Firehose liefert jedes Event mindestens einmal (at-least-once); Ihr Consumer ist für die Idempotenz beim Replay verantwortlich. Die Aufbewahrungsfrist des Topics beträgt 7 Tage; wenn Ihr Consumer mehr als 7 Tage zurückfällt, gehen Events verloren – richten Sie ein Monitoring für den Consumer-Lag ein. Dies ist kein Feature für Analytics-Anfänger; es erfordert Kafka-Consumer-Code und betriebliche Erfahrung mit Consumer-Gruppen. Wenn der geplante Export nach BigQuery ausreicht, beginnen Sie dort.
Stack you’ll touch
- Rohe Click-Events
- Direkter ClickHouse-Zugriff
- GA4 / Meta CAPI / Mixpanel
- S3 + BigQuery Export
- Per-Workspace DSN
- Webhook Firehose
Was Sie messen werden
- Sampling-Rate
- 0% — jeder Klick gespeichert
- Event-Lag
- Unter 5 Sekunden
- Retention-Horizont
- Bis zu 24 Monate
Analytics-Teams, die darauf setzen
Namen sind vorerst Platzhalter – echte Kundennamen erscheinen hier, sobald Fallstudien veröffentlicht werden.
“Dank des ClickHouse DSN konnten wir Metabase direkt mit den Click-Event-Daten verbinden, ohne ein ETL aufzubauen. Jetzt beantworten wir die Frage 'Welche Kampagne hat die MQL-zu-SQL-Konversion vorangetrieben?' direkt aus einem Metabase-Dashboard ohne zusätzliche Infrastruktur.”
“Serverseitiges Meta CAPI über Elido hat die Attribution für etwa 25 % der Conversions wiederhergestellt, die unser clientseitiges Pixel verpasst hat. Die Einrichtung dauerte einen Sprint; die Verbesserung der Attributionsgenauigkeit war sofort spürbar.”
“Wir speisen die Kafka-Firehose in unseren eigenen Stream-Prozessor ein. Eine Event-Verzögerung von weniger als 5 Sekunden bedeutet, dass unsere Echtzeit-Dashboards zur Link-Performance das Redaktionsteam während Live-Events nicht anlügen.”
Elido Analytics vs. Bitly Analytics vs. Heap
Bitly Analytics ist ausreichend für Click-Zahlen und grundlegendes Geo-Tracking. Heap ist eine vollständige Produkt-Analytics-Plattform. Der folgende Vergleich zeigt ehrlich auf, wo welche Option das richtige Werkzeug ist.
| Capability | Elido | Bitly Analytics | Heap |
|---|---|---|---|
| Click-Daten-Sampling | 0 % – jedes Event wird gespeichert | Aggregiert; Roh-Events nicht zugänglich | Abhängig vom Plan im Free-Tarif |
| Direkter SQL-Zugriff | Schreibgeschützter ClickHouse DSN (Business) | Kein direkter Datenbankzugriff | Heap Data Lake (Warehouse-Export) |
| Geplanter Export nach BigQuery/Snowflake | Ja, Business+ | Nur CSV-Export | Ja – Kernfunktion |
| Echtzeit-Kafka-Firehose | Ja, Business+ | Nicht verfügbar | Nicht verfügbar |
| Serverseitiges Conversion-Forwarding | GA4 MP, Meta CAPI, Mixpanel – dedupliziert | Nicht verfügbar | Serverseitiges Event-Ingest (Produkt-Events) |
| Tracking auf Nutzerebene | Nein – nur auf Click-Ebene, keine Nutzeridentität | Nein | Ja – Kernfunktion |
| Funnel + Kohorten-Retention | Click-Kohorten bei Business | Nein | Vollständiger Funnel + Kohorte – ausgereift |
| Event-Aufbewahrung | Bis zu 24 Monate (Rohdaten) | Aggregierte Zähler; Rohdaten nicht verfügbar | Variiert je nach Plan |
Fragen des Analytics-Teams
Wie sieht das genaue ClickHouse-Schema für Click-Events aus?
Das Schema ist unter /docs/api-reference unter 'Click events' öffentlich einsehbar. Wichtige Felder: click_id (UUID), link_id, workspace_id, occurred_at (UTC-Zeitstempel), country_iso2, region, city, device_type (Mobile/Tablet/Desktop), os, browser, referrer_domain, utm_source, utm_medium, utm_campaign, utm_term, utm_content. Nullbare Felder sind null, keine leeren Strings. Schemaänderungen werden unter /changelog mit einem Migrationsleitfaden angekündigt.
Gibt es einen Leitfaden für Kafka-Consumer?
Ja – /docs/guides/kafka-firehose behandelt Bootstrap-Server, Einrichtung von Consumer-Gruppen, Rotation von Client-Zertifikaten und Beispielcode für Consumer in Go und Python. Es gibt ein Topic pro Workspace; die Partitionsanzahl ist fest auf 12 eingestellt. Der Offset-Reset ist beim ersten Beitritt einer Consumer-Gruppe standardmäßig auf 'earliest' gesetzt. Wenn Sie darauf aufbauen, planen Sie Zeit für das Monitoring des Consumer-Lags ein – das ist der Fehlermodus, der Teams ohne entsprechendes Setup trifft.
Kann ich Click-Events mit meiner eigenen Nutzertabelle verknüpfen?
In Ihrem Warehouse, ja. Das Standardmuster ist: Exportieren Sie Click-Events über einen geplanten Export nach BigQuery oder Snowflake und verknüpfen Sie sie dann über die UTM-Parameter oder einen benutzerdefinierten user_id-Parameter, den Sie an Ihre Kurzlink-Ziele anhängen. Elido speichert keine Nutzeridentität in Click-Events – die click_id ist eine zufällige UUID pro Click, die nicht mit einem Nutzerkonto verknüpft ist.
Wie funktioniert die serverseitige Conversion-Deduplizierung?
Wenn Sie ein Conversion-Event an den Conversion-Endpunkt von Elido senden (POST), geben Sie die click_id an, die in der ursprünglichen Click-Antwort zurückgegeben wurde (sie wird als Query-Parameter an die Ziel-URL übergeben). Elido sucht den Click, prüft, ob er noch nicht attribuiert wurde, und leitet die Conversion mit dem UTM-Kontext des ursprünglichen Clicks an GA4 MP, Meta CAPI oder Mixpanel weiter. Doppelte Einsendungen mit derselben click_id sind idempotent – sie werden bestätigt, aber nicht doppelt gezählt.
Was passiert, wenn mein Kafka-Consumer zurückfällt?
Events werden 7 Tage lang im Topic aufbewahrt. Wenn der bestätigte Offset Ihrer Consumer-Gruppe mehr als 7 Tage zurückfällt, gehen ältere Events verloren, bevor Ihr Consumer sie liest. Überwachen Sie den Consumer-Lag; richten Sie einen Alarm bei einem Rückstand von 6 Stunden als Frühwarnung ein. Wenn Sie bei einem nicht wiederherstellbaren Event zurückfallen, deckt der geplante Export nach S3/BigQuery die Lücke ab – er ist ein gutes Backup für die Firehose.
Gewährt der ClickHouse DSN Zugriff auf die Daten anderer Workspaces?
Nein. Der DSN ist nur auf die Event-Tabelle Ihres Workspaces beschränkt, über einen schreibgeschützten ClickHouse-Benutzer mit angewendeter Sicherheit auf Zeilenebene. Sie können die Events anderer Workspaces nicht sehen. Der DSN ist in den Workspace-Einstellungen widerrufbar; rotieren Sie ihn im gleichen Rhythmus wie API-Keys.
Gibt es eine Mindeststichprobengröße, bevor Click-Kohorten aussagekräftig sind?
ClickHouse führt die Kohortenabfrage bei jeder vorhandenen Datengröße aus – es wird kein Minimum erzwungen. Die statistische Aussagekraft liegt in Ihrem Ermessen. Eine Kohorte von 50 Clicks liefert Ihnen eine Zahl, aber sie ist mit Rauschen behaftet. Wir zeigen absolute Zahlen und Prozentsätze an; wir wenden keine Bayes'sche Glättung oder Konfidenzintervalle auf Kohortenansichten an. Für formale Analysen exportieren Sie die Daten und führen Ihr Modell in Ihrem Warehouse aus.
Kann ich den geplanten Export auf eine Teilmenge von Links filtern?
Ja – Exportfilter unterstützen: bestimmte Domain, spezifische Kampagnen-ID, spezifisches Tag oder einen Datumsbereich. Ein gefilterter Export ist weiterhin inkrementell; nachfolgende Durchläufe hängen nur neue Events an, die dem Filter entsprechen. Wenn Sie eine neue Filterbedingung zu einem bestehenden Exportauftrag hinzufügen, müssen Sie entweder einen neuen Auftrag erstellen oder einen einmaligen vollständigen Re-Export durchführen, um den Verlauf des neuen Filters nachzufüllen.
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.
Nicht sicher, welcher Winkel passt?
Die meisten Teams beginnen als eins und wachsen in alle vier hinein. Unser Vertriebsteam kann in 20 Minuten Ihren spezifischen Stack durchgehen.