Click data you can actually query.
Vous mesurez l'attribution, l'abandon du tunnel et l'impact incrémental. Elido stocke chaque clic dans ClickHouse avec un accès brut — pas d'échantillonnage, pas de délai d'agrégation.
- 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
Ce que 'analytics-first' signifie dans le modèle de données d'Elido
La plupart des outils d'analyse de réducteurs de liens sont des totaux agrégés. Les fonctionnalités ci-dessous expliquent ce qui change lorsque le flux de clics bruts est l'artéfact principal, et non un simple résumé.
Chaque clic est stocké — pas de note de bas de page 'échantillonnage après N événements'
Les événements de clics sont ingérés via un topic Redpanda Kafka et écrits dans ClickHouse par le service click-ingester. Il n'y a pas de couche d'échantillonnage. Un lien avec 10 clics et un lien avec 10 millions de clics ont tous deux chaque événement dans la même table — le schéma ne change pas, aucune agrégation n'est appliquée au moment de l'ingestion. La rétention est de 90 jours en version Free, 12 mois en Pro et 24 mois en Business. Après la période de rétention, les événements sont supprimés définitivement ; le nombre d'événements supprimés est consigné. Le schéma ClickHouse est public — vous pouvez voir exactement quels champs sont stockés, ce qui signifie que vous pouvez planifier votre modèle de données dans votre warehouse avant de commencer l'exportation. Le délai entre le clic et la disponibilité dans ClickHouse est généralement inférieur à 5 secondes ; le consommateur Redpanda fonctionne avec auto-commit et enregistre les métriques de latence pour que vous puissiez voir si le pipeline prend du retard.
GA4 MP, Meta CAPI et Mixpanel côté serveur — dédupliqués par rapport au clic
Les pixels côté client manquent une fraction significative des conversions en fonction de la pénétration des bloqueurs de publicité et de l'ITP de Safari sur iOS. Le transfert côté serveur envoie la conversion à GA4 Measurement Protocol, Meta Conversions API ou Mixpanel directement depuis le backend d'Elido — aucun JS côté client n'est requis. La clé de déduplication est l'ID du clic : lorsqu'un événement de conversion arrive via un webhook Stripe ou Shopify, Elido le fait correspondre au clic d'origine et le diffuse vers tous les points de terminaison côté serveur configurés. L'ID du clic est transmis en tant que paramètre de requête à l'URL de destination au moment du clic ; votre flux de paiement doit le conserver jusqu'à l'événement de conversion. Chaque événement transféré porte les paramètres UTM d'origine du clic afin que l'attribution survive à l'ensemble du tunnel. Ceci est utile pour récupérer les conversions que les pixels côté client manquent — ce n'est pas un remplacement pour une CDP complète, mais cela comble l'écart courant d'attribution au dernier clic.
DSN ClickHouse en lecture seule par espace de travail — connectez directement Metabase, Hex ou Grafana
Les espaces de travail Business bénéficient d'un DSN ClickHouse en lecture seule par espace de travail, limité à leur table d'événements. Connectez Metabase, Hex, Apache Superset, Grafana ou tout client compatible ClickHouse au DSN et écrivez du SQL directement sur vos données d'événements de clics. Le DSN est renouvelable sans changer la table d'événements ; il se connecte à un utilisateur en lecture seule qui peut uniquement effectuer des SELECT, pas des INSERT ou des DROP. Le schéma ClickHouse est stable et versionné ; les modifications de schéma font l'objet d'un guide de migration dans le journal des modifications avant d'être appliquées. Pour les équipes qui souhaitent fusionner les événements de clics avec leurs propres données produit — 'quels liens ont généré les utilisateurs qui ont fini par s'activer ?' — le modèle consiste à copier les événements de clics vers votre propre warehouse via un export planifié, puis à effectuer la jointure à cet endroit. Le DSN ClickHouse est destiné aux équipes dont l'outil BI peut se connecter directement à ClickHouse et qui n'ont pas besoin de jointure avec des tables externes.
Exports planifiés vers S3, BigQuery et Snowflake
L'exportation planifiée s'exécute à une cadence configurable (horaire, quotidienne) et pousse le flux d'événements de clics — ou un sous-ensemble filtré par domaine, campagne ou tag de lien — vers S3, BigQuery ou Snowflake. L'exportation S3 utilise Parquet par défaut (JSON disponible) ; BigQuery et Snowflake utilisent les connecteurs natifs avec un schéma qu'Elido crée et maintient à jour. Les exportations incrémentielles sont basées sur l'horodatage de l'événement ; la première exportation est un remplissage historique complet jusqu'à votre fenêtre de rétention ; les exportations suivantes ajoutent uniquement les nouveaux événements. Si vous devez rejouer à partir d'un horodatage spécifique, une exportation complète ponctuelle est disponible via une demande d'assistance. Les échecs d'exportation sont consignés et réessayés ; une notification d'erreur est envoyée à l'e-mail de l'espace de travail si un lot échoue pendant plus de 2 heures.
Consommateur Kafka en temps réel pour les pipelines d'événements qui ne peuvent pas attendre les exports par lots
Les espaces de travail Business peuvent consommer les événements de clics directement depuis un topic Redpanda en tant que groupe de consommateurs Kafka. Vous recevez un ID de groupe de consommateurs, un serveur bootstrap et un certificat client — une configuration standard de consommateur Kafka. C'est la solution idéale pour les alertes en temps réel (détection de pics sur un lien, signalement d'anomalies géographiques), les tableaux de bord en temps réel nécessitant des données à la seconde près et les pipelines où la cadence d'exportation planifiée est trop lente. Le flux délivre chaque événement au moins une fois ; votre consommateur est responsable de l'idempotence lors des rejeux. La rétention des topics est de 7 jours ; si votre consommateur prend plus de 7 jours de retard, les événements sont perdus — configurez une surveillance du retard des consommateurs. Ce n'est pas une fonctionnalité d'analyse pour débutants ; elle nécessite du code de consommateur Kafka et une expérience opérationnelle des groupes de consommateurs. Si l'exportation planifiée vers BigQuery vous suffit, commencez par là.
Stack you’ll touch
- Événements de clics bruts
- Accès direct ClickHouse
- GA4 / Meta CAPI / Mixpanel
- Export S3 + BigQuery
- DSN par espace de travail
- Flux de webhooks
Ce que vous mesurerez
- Taux d'échantillonnage
- 0% — chaque clic stocké
- Délai d'ingestion des événements
- Moins de 5 secondes
- Horizon de rétention
- Jusqu'à 24 mois
Les équipes Analytics qui l'utilisent
Les noms sont des espaces réservés pour le moment — les vrais noms de clients apparaîtront ici au fur et à mesure de la publication des études de cas.
“Le DSN ClickHouse nous a permis de brancher Metabase directement sur les données d'événements de clics sans construire d'ETL. Nous répondons désormais à la question 'quelle campagne a généré la conversion MQL vers SQL ?' depuis un tableau de bord Metabase sans infrastructure supplémentaire.”
“Meta CAPI côté serveur via Elido a permis de récupérer l'attribution sur environ 25 % des conversions que notre pixel côté client manquait. La mise en place a duré un sprint ; l'amélioration de la précision de l'attribution a été immédiate.”
“Nous consommons le flux Kafka dans notre propre processeur de flux. Un délai d'événement inférieur à 5 secondes signifie que nos tableaux de bord de performance des liens en temps réel ne mentent pas à l'équipe éditoriale lors des événements en direct.”
Analyses Elido vs Bitly Analytics vs Heap
Bitly Analytics est adéquat pour le comptage des clics et la géolocalisation de base. Heap est une plateforme complète d'analyse de produit. La comparaison ci-dessous est honnête quant aux situations où chaque option est le bon outil.
| Capability | Elido | Bitly Analytics | Heap |
|---|---|---|---|
| Échantillonnage des données de clics | 0 % — chaque événement est stocké | Agrégé ; événements bruts inaccessibles | Dépend du forfait pour l'offre gratuite |
| Accès SQL direct | DSN ClickHouse en lecture seule (Business) | Pas d'accès direct à la base de données | Heap Data Lake (export warehouse) |
| Export planifié vers BigQuery/Snowflake | Oui, Business+ | Export CSV uniquement | Oui — fonctionnalité de base |
| Flux Kafka temps réel | Oui, Business+ | Non disponible | Non disponible |
| Transfert de conversion côté serveur | GA4 MP, Meta CAPI, Mixpanel — dédupliqués | Non disponible | Ingestion d'événements côté serveur (événements produit) |
| Suivi au niveau de l'utilisateur | Non — niveau clic uniquement, pas d'identité utilisateur | Non | Oui — fonctionnalité de base |
| Entonnoir + rétention de cohorte | Cohortes de clics en Business | Non | Entonnoir complet + cohorte — mature |
| Rétention des événements | Jusqu'à 24 mois (brut) | Compteurs agrégés ; brut non disponible | Varie selon le forfait |
Questions des équipes Analytics
Quel est le schéma ClickHouse exact pour les événements de clics ?
Le schéma est public sur /docs/api-reference sous 'Click events'. Champs clés : click_id (UUID), link_id, workspace_id, occurred_at (horodatage UTC), country_iso2, region, city, device_type (mobile/tablette/ordinateur), os, browser, referrer_domain, utm_source, utm_medium, utm_campaign, utm_term, utm_content. Les champs nuls sont 'null' et non des chaînes vides. Les modifications de schéma sont annoncées dans /changelog avec un guide de migration.
Existe-t-il un guide du consommateur Kafka ?
Oui — /docs/guides/kafka-firehose couvre le serveur bootstrap, la configuration du groupe de consommateurs, la rotation des certificats clients et un exemple de code de consommateur en Go et Python. Le topic est unique par espace de travail ; le nombre de partitions est fixé à 12. La réinitialisation de l'offset est 'earliest' par défaut lors de la première adhésion au groupe de consommateurs. Si vous construisez sur cette base, prévoyez du temps pour la surveillance du retard des consommateurs (lag) — c'est le mode de défaillance qui piège les équipes qui ne le configurent pas.
Puis-je joindre les événements de clics avec ma propre table d'utilisateurs ?
Dans votre warehouse, oui. Le modèle standard est : exportez les événements de clics vers BigQuery ou Snowflake via l'exportation planifiée, puis effectuez la jointure sur les paramètres UTM ou un paramètre user_id personnalisé que vous ajoutez à vos destinations de liens courts. Elido ne stocke pas l'identité de l'utilisateur dans les événements de clics — le click_id est un UUID aléatoire par clic, non lié à un compte utilisateur.
Comment fonctionne la déduplication des conversions côté serveur ?
Lorsque vous envoyez par POST un événement de conversion au point de terminaison de conversion d'Elido, vous incluez le click_id qui a été renvoyé dans la réponse au clic d'origine (il est transmis comme paramètre de requête à l'URL de destination). Elido recherche le clic, vérifie qu'il n'a pas déjà été attribué et diffuse la conversion vers GA4 MP, Meta CAPI ou Mixpanel avec le contexte UTM du clic d'origine. Les soumissions en double avec le même click_id sont idempotentes — elles sont acquittées mais pas comptées deux fois.
Que se passe-t-il si mon consommateur Kafka prend du retard ?
Les événements sont conservés dans le topic pendant 7 jours. Si l'offset validé de votre groupe de consommateurs prend plus de 7 jours de retard, les anciens événements seront perdus avant que votre consommateur ne les lise. Surveillez le retard du consommateur (lag) ; configurez une alerte à 6 heures de retard comme avertissement précoce. Si vous prenez du retard sur un événement non récupérable, l'exportation planifiée vers S3/BigQuery couvre l'écart — c'est une bonne solution de secours pour le flux.
Le DSN ClickHouse donne-t-il accès aux données d'autres espaces de travail ?
Non. Le DSN est limité uniquement à la table d'événements de votre espace de travail, via un utilisateur ClickHouse en lecture seule avec une sécurité au niveau des lignes appliquée. Vous ne pouvez pas voir les événements des autres espaces de travail. Le DSN est révocable depuis les paramètres de l'espace de travail ; renouvelez-le à la même fréquence que les clés API.
Y a-t-il un échantillon minimum avant que les cohortes de clics ne soient significatives ?
ClickHouse exécute la requête de cohorte quelle que soit la taille des données existantes — aucun minimum n'est imposé. La pertinence statistique est de votre ressort. Une cohorte de 50 clics vous donne un chiffre, mais il est bruité. Nous affichons les comptes bruts et les pourcentages ; nous n'appliquons pas de lissage bayésien ni d'intervalles de confiance aux vues de cohorte. Pour une analyse formelle, exportez et exécutez votre modèle dans votre warehouse.
Puis-je filtrer l'exportation planifiée sur un sous-ensemble de liens ?
Oui — les filtres d'exportation prennent en charge : un domaine spécifique, un ID de campagne spécifique, un tag spécifique ou une plage de dates. Une exportation filtrée est toujours incrémentielle ; les exécutions suivantes ajoutent uniquement les nouveaux événements correspondant au filtre. Si vous ajoutez une nouvelle condition de filtrage à une tâche d'exportation existante, vous devrez soit créer une nouvelle tâche, soit effectuer une réexportation complète ponctuelle pour remplir l'historique du nouveau filtre.
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.
Pas sûr de l'angle qui convient ?
La plupart des équipes commencent par un et évoluent vers les quatre. Notre équipe commerciale peut examiner votre pile spécifique en 20 minutes.