Données de clics que vous pouvez vraiment interroger.
Vous mesurez l'attribution, l'abandon du tunnel et l'impact incrémental. Elido stocke chaque clic dans un entrepôt d'analytique en colonnes avec un accès brut - pas d'échantillonnage, pas de délai d'agrégation.
- Pas d'échantillonnage des clics à aucun niveau - chaque événement stocké
- Export des clics vers votre bucket S3 (NDJSON gzip)
- Export programmé S3 + BigQuery (Parquet par défaut)
- Événements de clics bruts via firehose de webhooks / consommateur Kafka
Comment les données de clics arrivent
Clic → flux d'événements → entrepôt d'analytique, sans agrégation intermédiaire.
La plupart des raccourcisseurs vous donnent un compteur. Nous vous donnons une ligne par clic, ingérée en moins de cinq secondes, interrogeable depuis votre propre client SQL. Le pipeline est un seul topic compatible Kafka qu'un seul consommateur déverse dans l'entrepôt d'analytique - pas de service d'agrégation, pas de résumés quotidiens, pas de note « échantillonné après 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.
Export analytique et API
Les événements de clic dans votre bucket ; un DSN en lecture seule direct est prévu.
Les workspaces Business peuvent exporter les événements de clic en gzip NDJSON vers leur propre bucket S3, selon un calendrier ou à la demande, puis les charger dans l'entrepôt lu par Metabase, Hex, Apache Superset, Grafana ou Looker. Les agrégats sont aussi disponibles via l'API REST d'analytique. Un DSN d'analytique direct en lecture seule est prévu mais pas encore disponible.
- Schéma stableVersionné dans /docs/api-reference ; guides de migration dans /changelog
- Stockage à vousFichiers gzip NDJSON écrits dans votre bucket S3, limités à votre workspace
- Compatible BIChargez-les dans l'entrepôt derrière Metabase, Hex, Superset, Grafana, Looker
- API d'analytiqueAgrégats par pays, appareil, référent et période 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;Géographie qui survit à l'export
Densité au niveau du pays sur chaque clic - pas un bucket haché.
Chaque événement de clic inclut le pays, la région et la ville (ISO 3166-1 alpha-2), résolus à partir d'un jeu de données geo-IP hors ligne. L'adresse IP du visiteur est conservée avec l'événement de clic : traitez donc ces données comme des données personnelles au sens du RGPD. Ci-dessous, les mêmes données dans l'interface que celles qui arrivent dans votre entrepôt - sans couche d'agrégation intermédiaire.
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 vers l'entrepôt
Parquet horaire vers S3, puis transfert natif vers votre entrepôt.
L'export programmé pousse les événements de clics en Parquet vers votre bucket S3 toutes les heures ou par jour ; BigQuery Transfer natif ou table externe Snowflake le charge depuis là. La première exécution est un backfill complet jusqu'à votre fenêtre de rétention ; les exécutions suivantes n'ajoutent que les nouveaux événements indexés sur l'horodatage. Les échecs font l'objet de relances ; une notification de file morte est déclenchée si un lot ne peut pas aboutir en 2 heures.
- Parquet (défaut) ou JSON ; un objet par bucket d'heure
- Filtrez l'export par domaine, campagne ou tag de lien
- BigQuery Transfer natif + table externe Snowflake
- Alerte file morte en cas d'échec de lot >2h
- Firehose Kafka pour livraison en sous-seconde (Business)
Ce que vous pouvez faire
- Pas d'échantillonnage des clics à aucun niveau - chaque événement stocké
- Export des clics vers votre bucket S3 (NDJSON gzip)
- Export programmé S3 + BigQuery (Parquet par défaut)
- Événements de clics bruts via firehose de webhooks / consommateur Kafka
- Latence de requête inférieure à la seconde sur des tables de plus d'1 milliard de lignes
- Attribution de clics server-side avec déduplication des click-IDs
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 compatible Kafka et écrits dans l'entrepôt d'analytique par notre service d'ingestion. 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 d'événement 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 l'analytique est généralement inférieur à 5 secondes ; le consommateur 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.
Export des clics S3 - à charger dans l'entrepôt derrière Metabase, Hex ou Grafana
Les espaces de travail Business peuvent exporter les événements de clic en NDJSON gzip vers leur propre bucket S3, selon un calendrier ou à la demande. Chargez les fichiers dans l'entrepôt derrière Metabase, Hex, Apache Superset, Grafana ou tout client SQL/BI compatible et écrivez-y du SQL sur vos données de clic. Les agrégats sont aussi disponibles via l'API REST d'analytique. Pour les équipes qui veulent joindre les événements de clic à leurs propres données produit - « quels liens ont amené des utilisateurs qui se sont ensuite activés ? » - copiez l'export dans votre entrepôt et faites la jointure là-bas. Un DSN d'analytique en lecture seule direct, pour qu'un outil BI se connecte sans job d'export, est prévu et pas encore disponible.
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 compatible Kafka 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 que vous utiliserez
- Événements de clics bruts
- Accès SQL direct
- GA4 / Meta CAPI / Mixpanel
- Export S3 + BigQuery
- Export des clics S3 (NDJSON gzip)
- 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
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.
Questions des équipes Analytics
Quel est le schéma d'événement 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.
L'export des clics inclut-il les données d'autres espaces de travail ?
Non. Les exports ne contiennent que les événements de votre espace de travail et sont écrits dans votre propre bucket S3. Un DSN d'analytique en lecture seule direct est prévu et pas encore disponible ; à sa sortie, il sera limité à votre espace de travail.
Y a-t-il un échantillon minimum avant que les cohortes de clics ne soient significatives ?
L'entrepôt d'analytique 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.
Lecture recommandée pour les analystes
Détail par lien, attribution des conversions, rétention de cohorte.
Transfert server-side vers GA4, Meta CAPI, Mixpanel.
Spec OpenAPI 3.1, schéma d'événement de clic, SDKs typés en TS / Py / Go.
Événements signés HMAC, politique de relance, firehose Kafka pour gros volumes.
Mise en place de l'export, schéma, modèles de chargement BigQuery + Snowflake.
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.