Click data you can actually query.
Mides atribución, caídas en el embudo e incremento marginal. Elido almacena cada clic en ClickHouse con acceso directo — sin muestreo ni retrasos por agregación.
- 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
Qué significa 'analytics-first' en el modelo de datos de Elido
La mayoría de las analíticas de acortadores son totales agregados. Las características a continuación explican qué cambia cuando el flujo de clics sin procesar es el artefacto primario, no un resumen.
Cada clic almacenado — sin la nota al pie de 'muestreamos después de N eventos'
Los eventos de clic se ingieren a través de un tema de Redpanda Kafka y son escritos en ClickHouse por el servicio click-ingester. No hay capa de muestreo. Un enlace con 10 clics y un enlace con 10 millones de clics tienen cada evento en la misma tabla — el esquema no cambia, no se aplica agregación en el momento de la ingesta. La retención es de 90 días en Free, 12 meses en Pro y 24 meses en Business. Después de la ventana de retención, los eventos se eliminan permanentemente; el recuento de eventos eliminados se registra. El esquema de ClickHouse es público — puedes ver exactamente qué campos se almacenan, lo que significa que puedes planificar tu modelo de datos en tu almacén antes de comenzar a exportar. El retraso del evento desde el clic hasta la disponibilidad en ClickHouse es normalmente inferior a 5 segundos; el consumidor de Redpanda se ejecuta con auto-commit y registra métricas de retraso para que puedas ver si la tubería se queda atrás.
GA4 MP, Meta CAPI y Mixpanel server-side — deduplicados contra el clic
Los píxeles del lado del cliente pierden una fracción significativa de las conversiones dependiendo de la penetración de los bloqueadores de anuncios y el ITP de Safari en iOS. El reenvío desde el servidor envía la conversión a GA4 Measurement Protocol, Meta Conversions API o Mixpanel directamente desde el backend de Elido — sin necesidad de JS en el cliente. La clave de deduplicación es el ID de clic: cuando llega un evento de conversión a través de un webhook de Stripe o Shopify, Elido lo asocia con el clic de origen y lo distribuye a todos los endpoints configurados en el servidor. El ID de clic se pasa como un parámetro de consulta a la URL de destino en el momento del clic; tu flujo de pago debe preservarlo hasta el evento de conversión. Cada evento reenviado lleva los parámetros UTM originales del clic para que la atribución sobreviva a todo el embudo. Esto es útil para recuperar conversiones que los píxeles del cliente pierden — no es un reemplazo para un CDP completo, pero cierra la brecha común de atribución del último clic.
DSN de ClickHouse de solo lectura por espacio de trabajo — conéctalo directamente a Metabase, Hex o Grafana
Los espacios de trabajo Business obtienen un DSN de ClickHouse de solo lectura por espacio de trabajo limitado a su tabla de eventos. Apunta Metabase, Hex, Apache Superset, Grafana o cualquier cliente compatible con ClickHouse al DSN y escribe SQL directamente contra tus datos de eventos de clic. El DSN es rotable sin cambiar la tabla de eventos; se conecta a un usuario de solo lectura que solo puede realizar SELECT, no INSERT ni DROP. El esquema de ClickHouse es estable y versionado; los cambios de esquema reciben una guía de migración en el registro de cambios antes de implementarse. Para los equipos que desean unir los eventos de clic con sus propios datos de producto — '¿qué enlaces impulsaron a los usuarios que luego se activaron?' — el patrón consiste en copiar los eventos de clic a tu propio almacén mediante una exportación programada y luego realizar la unión allí. El DSN de ClickHouse es para equipos cuya herramienta de BI puede conectarse a ClickHouse directamente y que no necesitan unirse con tablas externas.
Exportaciones programadas a S3, BigQuery y Snowflake
La exportación programada se ejecuta con una cadencia configurable (horaria, diaria) y envía el flujo de eventos de clic — o un subconjunto filtrado por dominio, campaña o etiqueta de enlace — a S3, BigQuery o Snowflake. La exportación a S3 utiliza Parquet por defecto (JSON disponible); BigQuery y Snowflake utilizan los conectores nativos con un esquema que Elido crea y mantiene actualizado. Las exportaciones incrementales se basan en la marca de tiempo del evento; la primera exportación es un llenado histórico completo hasta tu ventana de retención; las exportaciones posteriores solo añaden nuevos eventos. Si necesitas reproducir desde una marca de tiempo específica, hay una exportación completa única disponible a través de una solicitud de soporte. Los fallos de exportación se registran y se reintentan; se envía una notificación de error al correo electrónico del espacio de trabajo si un lote falla durante más de 2 horas.
Consumidor de Kafka en tiempo real para tuberías de eventos que no pueden esperar a las exportaciones por lotes
Los espacios de trabajo Business pueden consumir eventos de clic directamente desde un tema de Redpanda como un grupo de consumidores de Kafka. Obtienes un ID de grupo de consumidores, un servidor de bootstrap y un certificado de cliente — configuración estándar de consumidor de Kafka. Este es el camino correcto para alertas en tiempo real (detección de picos en un enlace, señalización de anomalías geográficas), paneles en tiempo real que necesitan datos en subsegundos y tuberías donde la cadencia de exportación programada es demasiado lenta. El firehose entrega cada evento al menos una vez; tu consumidor es responsable de la idempotencia en la reproducción. La retención del tema es de 7 días; si tu consumidor se retrasa más de 7 días, los eventos se pierden — configura el monitoreo del retraso del consumidor. Esta no es una función de analítica para principiantes; requiere código de consumidor de Kafka y experiencia operativa con grupos de consumidores. Si la exportación programada a BigQuery te da lo que necesitas, empieza por ahí.
Stack you’ll touch
- Eventos de clics brutos
- Acceso directo a ClickHouse
- GA4 / Meta CAPI / Mixpanel
- Exportación a S3 + BigQuery
- DSN por espacio de trabajo
- Transmisión de webhooks
Lo que medirás
- Tasa de muestreo
- 0% — cada clic almacenado
- Retraso en ingesta de eventos
- Menos de 5 segundos
- Horizonte de retención
- Hasta 24 meses
Equipos de analítica que funcionan con esto
Los nombres son marcadores de posición por ahora — los nombres de clientes reales aparecerán aquí a medida que se publiquen los casos de estudio.
“El DSN de ClickHouse nos permitió conectar Metabase directamente a los datos de eventos de clic sin construir un ETL. Ahora respondemos '¿qué campaña impulsó la conversión de MQL a SQL?' desde un panel de Metabase sin infraestructura adicional.”
“Meta CAPI server-side a través de Elido recuperó la atribución en aproximadamente el 25% de las conversiones que nuestro píxel del lado del cliente estaba perdiendo. La configuración fue de un sprint; la mejora en la precisión de la atribución fue inmediata.”
“Consumimos el firehose de Kafka en nuestro propio procesador de flujos. Un retraso de eventos inferior a 5 segundos significa que nuestros paneles de rendimiento de enlaces en tiempo real no mienten al equipo editorial durante eventos en vivo.”
Analíticas de Elido vs Analíticas de Bitly vs Heap
Bitly Analytics es adecuado para recuentos de clics y geografía básica. Heap es una plataforma completa de analítica de producto. La siguiente comparación es honesta sobre dónde cada opción es la herramienta adecuada.
| Capability | Elido | Bitly Analytics | Heap |
|---|---|---|---|
| Muestreo de datos de clic | 0% — cada evento almacenado | Agregado; eventos sin procesar no accesibles | Depende del plan en el nivel gratuito |
| Acceso directo SQL | DSN de ClickHouse de solo lectura (Business) | Sin acceso directo a la DB | Heap Data Lake (exportación a almacén) |
| Exportación programada a BigQuery/Snowflake | Sí, Business+ | Solo exportación CSV | Sí — característica principal |
| Kafka firehose en tiempo real | Sí, Business+ | No disponible | No disponible |
| Reenvío de conversión server-side | GA4 MP, Meta CAPI, Mixpanel — deduplicado | No disponible | Ingesta de eventos server-side (eventos de producto) |
| Seguimiento a nivel de usuario | No — solo a nivel de clic, sin identidad de usuario | No | Sí — característica principal |
| Embudo + retención de cohortes | Cohortes de clics en Business | No | Embudo completo + cohorte — maduro |
| Retención de eventos | Hasta 24 meses sin procesar | Contadores agregados; sin procesar no disponibles | Varía según el plan |
Preguntas del equipo de analítica
¿Cuál es el esquema exacto de ClickHouse para los eventos de clic?
El esquema es público en /docs/api-reference bajo 'Click events'. Campos clave: click_id (UUID), link_id, workspace_id, occurred_at (marca de tiempo UTC), country_iso2, region, city, device_type (móvil/tableta/escritorio), os, browser, referrer_domain, utm_source, utm_medium, utm_campaign, utm_term, utm_content. Los campos que pueden ser nulos son nulos, no cadenas vacías. Los cambios de esquema se anuncian en /changelog con una guía de migración.
¿Existe una guía para el consumidor de Kafka?
Sí — /docs/guides/kafka-firehose cubre el servidor de bootstrap, la configuración del grupo de consumidores, la rotación de certificados de cliente y código de ejemplo de consumidor en Go y Python. El tema es uno por espacio de trabajo; el recuento de particiones es fijo en 12. El reinicio del offset es el más antiguo por defecto en la primera unión al grupo de consumidores. Si estás construyendo sobre esto, presupuesta tiempo para el monitoreo del retraso del consumidor — ese es el modo de fallo que afecta a los equipos que no lo configuran.
¿Puedo unir los eventos de clic con mi propia tabla de usuarios?
En tu almacén de datos, sí. El patrón estándar es: exportar eventos de clic a BigQuery o Snowflake mediante exportación programada, luego unir por los parámetros UTM o un parámetro user_id personalizado que añadas a tus destinos de enlaces cortos. Elido no almacena la identidad del usuario en los eventos de clic — el click_id es un UUID aleatorio por clic, no vinculado a una cuenta de usuario.
¿Cómo funciona la deduplicación de conversiones server-side?
Cuando envías un evento de conversión al endpoint de conversión de Elido, incluyes el click_id que se devolvió en la respuesta del clic original (se pasa como un parámetro de consulta a la URL de destino). Elido busca el clic, verifica que no haya sido ya atribuido y distribuye la conversión a GA4 MP, Meta CAPI o Mixpanel con el contexto UTM del clic original. Los envíos duplicados con el mismo click_id son idempotentes — se confirman pero no se cuentan dos veces.
¿Qué pasa si mi consumidor de Kafka se retrasa?
Los eventos se retienen en el tema durante 7 días. Si el offset comprometido de tu grupo de consumidores se retrasa más de 7 días, los eventos más antiguos se perderán antes de que tu consumidor los lea. Monitorea el retraso del consumidor; configura una alerta a las 6 horas de retraso como advertencia temprana. Si te retrasas en un evento no recuperable, la exportación programada a S3/BigQuery cubre el hueco — es un buen respaldo para el firehose.
¿El DSN de ClickHouse da acceso a los datos de otros espacios de trabajo?
No. El DSN está limitado únicamente a la tabla de eventos de tu espacio de trabajo, a través de un usuario de ClickHouse de solo lectura con seguridad a nivel de fila aplicada. No puedes ver los eventos de otros espacios de trabajo. El DSN es revocable desde la configuración del espacio de trabajo; rótalo con la misma cadencia que las claves API.
¿Hay un tamaño mínimo de muestra antes de que las cohortes de clics sean significativas?
ClickHouse ejecuta la consulta de cohortes con cualquier tamaño de datos existente — no se impone un mínimo. La significancia estadística es tu criterio. Una cohorte de 50 clics te da un número, pero tiene ruido. Mostramos recuentos brutos y porcentajes; no aplicamos suavizado bayesiano ni intervalos de confianza a las vistas de cohortes. Para un análisis formal, exporta y ejecuta tu modelo en tu almacén de datos.
¿Puedo filtrar la exportación programada a un subconjunto de enlaces?
Sí — los filtros de exportación admiten: dominio específico, ID de campaña específico, etiqueta específica o un rango de fechas. Una exportación filtrada sigue siendo incremental; las ejecuciones posteriores añaden solo los nuevos eventos que coinciden con el filtro. Si añades una nueva condición de filtro a un trabajo de exportación existente, deberás crear un nuevo trabajo o realizar una exportación completa única para rellenar el historial del nuevo filtro.
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.
¿No estás seguro de qué enfoque se adapta?
La mayoría de los equipos comienzan como uno y crecen hasta abarcar los cuatro. Nuestro equipo de ventas puede revisar tu stack específico en 20 minutos.