← Escolha a perspectiva ideal para o seu time

For analytics-first teams

Click data you can actually query.

Medes atribuição, quebras no funil e lift incremental. O Elido armazena todos os cliques no ClickHouse com acesso raw — sem amostragem, sem lag de agregação.

Start free Falar com vendas

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

Clicks · last 7 days

elido.me/launch

24h granularity · 38,620 total+18.4% wk/wk

Amostragem de cliques

<5s

Latência de ingestão de eventos

24 meses

Retenção no Business

ClickHouse DSN

Acesso SQL direto

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 → 302
Edge 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 lag
click-ingester drains the topic into the per-workspace events table.
Step 4
Your tools
DSN · BigQuery · Kafka
Read-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 schema
Versioned in /docs/api-reference; migration guides in /changelog
Row-level security
DSN scoped to your workspace's event rows only
BI-tool compatible
Metabase, Hex, Superset, Grafana, Looker — anything that speaks ClickHouse
Sub-second queries
1B-row tables under 1s for typical group-by-country / hour aggregations

Read about analytics →

ClickHouse · query editor

read-only DSN

clickhouse://ws_8a2f:****@ch-eu-central-1.elido.app:9440/events

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;

Result · 5 rowsscanned 1.2M rows · 0.18s

country	clicks	distribution
DE	18,429
FR	12,184
ES	9,847
IT	8,213
PL	7,062

Connected · ClickHouse 24.xeu-central-1

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.

Clicks by country · last 7 days

24 countries · ISO 3166-1 alpha-2

18.4k

12.2k

9.8k

8.2k

7.1k

6.5k

5.9k

4.9k

4.0k

3.7k

3.2k

2.8k

2.5k

2.2k

1.9k

1.7k

1.5k

1.3k

1.1k

982

794

612

481

348

Cooler Hotter5-bucket log scale · max 18,429

See per-link analytics →ClickHouse schema → docs

ClickHouse

events table · per workspace

Source of truth. 0% sampling, 24-month retention on Business.

Step 1

S3 · Parquet

s3://your-bucket/elido/clicks/

Hourly buckets, snappy-compressed Parquet (or JSON if you prefer).

Step 2

BigQuery / Snowflake / Redshift

native transfer · external table

Native BigQuery Transfer service or Snowflake external table loads from S3.

Step 3

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

O que 'analytics em primeiro lugar' significa no modelo de dados do Elido

A maioria dos analytics de encurtadores são totais agregados. As funcionalidades abaixo explicam o que muda quando o fluxo bruto de cliques é o artefato primário, não um resumo.

Sem amostragem

Cada clique armazenado — sem asterisco de 'após N eventos fazemos amostragem'

Os eventos de clique são ingeridos via um tópico Kafka do Redpanda e escritos no ClickHouse pelo serviço click-ingester. Não há camada de amostragem. Um link com 10 cliques e um link com 10 milhões de cliques têm todos os eventos na mesma tabela — o schema não muda, nenhuma agregação é aplicada no momento da ingestão. A retenção é de 90 dias no Free, 12 meses no Pro e 24 meses no Business. Após a janela de retenção, os eventos são excluídos definitivamente; a contagem de eventos excluídos é registrada. O schema do ClickHouse é público — você pode ver exatamente quais campos são armazenados, o que significa que pode planejar seu modelo de dados no seu data warehouse antes de começar a exportar. A latência de eventos do clique até a disponibilidade no ClickHouse é tipicamente inferior a 5 segundos; o consumidor Redpanda roda com auto-commit e registra métricas de lag para que você possa ver se o pipeline está atrasando.

Atribuição server-side

GA4 MP, Meta CAPI e Mixpanel server-side — deduplicados contra o clique

Pixels client-side perdem uma fração significativa das conversões dependendo da penetração de bloqueadores de anúncios e ITP do iOS Safari. O encaminhamento server-side envia a conversão para GA4 Measurement Protocol, Meta Conversions API ou Mixpanel diretamente do backend do Elido — sem JS client-side necessário. A chave de deduplicação é o click ID: quando um evento de conversão chega via webhook do Stripe ou Shopify, o Elido o vincula ao clique de origem e o distribui para todos os endpoints server-side configurados. O click ID é passado como parâmetro de query para a URL de destino no momento do clique; seu fluxo de checkout deve preservá-lo até o evento de conversão. Cada evento encaminhado carrega os parâmetros UTM originais do clique para que a atribuição sobreviva ao funil completo. Isso é útil para recuperar conversões que pixels client-side perdem — não substitui um CDP completo, mas fecha a lacuna de atribuição por último clique mais comum.

BYO BI

ClickHouse DSN somente leitura por workspace — conecte diretamente ao Metabase, Hex ou Grafana

Workspaces Business recebem um ClickHouse DSN somente leitura por workspace com escopo para sua tabela de eventos. Aponte o Metabase, Hex, Apache Superset, Grafana ou qualquer cliente compatível com ClickHouse para o DSN e escreva SQL diretamente contra seus dados de eventos de clique. O DSN é rotacionável sem alterar a tabela de eventos; ele se conecta a um usuário somente leitura que pode apenas fazer SELECT, não INSERT ou DROP. O schema do ClickHouse é estável e versionado; mudanças de schema recebem um guia de migração no changelog antes de serem aplicadas. Para equipes que querem juntar eventos de clique com seus próprios dados de produto — 'quais links levaram usuários que foram ativar?' — o padrão é copiar eventos de clique para seu próprio data warehouse via exportação agendada e fazer o join lá. O ClickHouse DSN é para equipes cuja ferramenta de BI pode se conectar diretamente ao ClickHouse e que não precisam fazer join com tabelas externas.

Exportação para data warehouse

Exportações agendadas para S3, BigQuery e Snowflake

A exportação agendada roda em uma cadência configurável (por hora, diária) e envia o fluxo de eventos de clique — ou um subconjunto filtrado por domínio, campanha ou tag de link — para S3, BigQuery ou Snowflake. A exportação S3 usa Parquet por padrão (JSON disponível); BigQuery e Snowflake usam os conectores nativos com um schema que o Elido cria e mantém atualizado. Exportações incrementais são indexadas pelo timestamp do evento; a primeira exportação é um backfill completo até a sua janela de retenção; exportações subsequentes acrescentam apenas novos eventos. Se você precisar fazer um replay a partir de um timestamp específico, uma exportação completa avulsa está disponível via chamado de suporte. Falhas de exportação são registradas e repetidas; uma notificação de dead-letter vai para o e-mail do workspace se um lote falhar por mais de 2 horas.

Firehose Kafka

Consumidor Kafka em tempo real para pipelines de eventos que não podem esperar exportações em lote

Workspaces Business podem consumir eventos de clique diretamente de um tópico Redpanda como um grupo consumidor Kafka. Você recebe um ID de grupo consumidor, um bootstrap server e um certificado de cliente — configuração padrão de consumidor Kafka. Este é o caminho certo para alertas em tempo real (detecção de spike em um link, sinalizações de anomalia geográfica), dashboards em tempo real que precisam de dados com sub-segundo de latência, e pipelines onde a cadência de exportação agendada é muito lenta. O firehose entrega cada evento pelo menos uma vez; seu consumidor é responsável pela idempotência em replay. A retenção do tópico é de 7 dias; se o seu consumidor ficar mais de 7 dias atrasado, os eventos serão perdidos — configure monitoramento no lag do consumidor. Este não é um recurso de analytics para iniciantes; requer código de consumidor Kafka e experiência operacional com grupos consumidores. Se a exportação agendada para BigQuery atende ao que você precisa, comece por lá.

Stack you’ll touch

Eventos de clique raw
Acesso direto ClickHouse
GA4 / Meta CAPI / Mixpanel
Exportação S3 + BigQuery
DSN por workspace
Firehose de webhooks

O que vais medir

Taxa de amostragem: 0% — todos os cliques armazenados
Lag de ingestão de eventos: Menos de 5 segundos
Horizonte de retenção: Até 24 meses

Equipes de analytics que usam isso

Os nomes são marcadores por enquanto — nomes reais de clientes aparecem aqui conforme os estudos de caso são publicados.

“O ClickHouse DSN nos permitiu conectar o Metabase diretamente aos dados de eventos de clique sem construir um ETL. Agora respondemos 'qual campanha gerou conversão de MQL para SQL?' a partir de um dashboard do Metabase sem infraestrutura adicional.”

Equipe de engenharia de dados, SaaS B2B, Helsinque

Lead de Engenharia de Dados

“O Meta CAPI server-side via Elido recuperou a atribuição de aproximadamente 25% das conversões que nosso pixel client-side estava perdendo. A configuração levou uma sprint; a melhora na precisão de atribuição foi imediata.”

Equipe de analytics de growth, e-commerce, Paris

Analytics Engineer

“Consumimos o firehose Kafka em nosso próprio stream processor. Latência de evento de menos de 5 segundos significa que nossos dashboards de desempenho de links em tempo real não mentem para a equipe editorial durante eventos ao vivo.”

Equipe de infraestrutura de dados, empresa de mídia, Copenhague

Senior Data Engineer

Analytics do Elido vs Bitly Analytics vs Heap

O Bitly Analytics é adequado para contagem de cliques e geo básico. O Heap é uma plataforma completa de analytics de produto. A comparação abaixo é honesta sobre onde cada opção é a ferramenta certa.

Capability	Elido	Bitly Analytics	Heap
Amostragem de dados de clique	0% — cada evento armazenado	Agregado; eventos brutos não acessíveis	Depende do plano no tier gratuito
Acesso SQL direto	ClickHouse DSN somente leitura (Business)	Sem acesso direto ao BD	Heap Data Lake (exportação para data warehouse)
Exportação agendada para BigQuery/Snowflake	Sim, Business+	Somente exportação CSV	Sim — funcionalidade central
Firehose Kafka em tempo real	Sim, Business+	Não disponível	Não disponível
Encaminhamento de conversão server-side	GA4 MP, Meta CAPI, Mixpanel — deduplicados	Não disponível	Ingestão de eventos server-side (eventos de produto)
Rastreamento no nível do usuário	Não — somente nível de clique, sem identidade de usuário	Não	Sim — funcionalidade central
Funil + retenção de coorte	Coortes de cliques no Business	Não	Funil completo + coorte — maduro
Retenção de eventos	Até 24 meses brutos	Contadores agregados; brutos não disponíveis	Varia por plano

Perguntas de equipes de analytics

Qual é o schema exato do ClickHouse para eventos de clique?

O schema é público em /docs/api-reference sob 'Click events'. Campos principais: 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. Campos nullable são nullable, não strings vazias. Mudanças de schema são anunciadas em /changelog com um guia de migração.

Existe um guia para consumidor Kafka?

Sim — /docs/guides/kafka-firehose cobre bootstrap server, configuração de grupo consumidor, rotação de certificado de cliente e exemplo de código consumidor em Go e Python. O tópico é um por workspace; a contagem de partições é fixa em 12. O reset de offset é earliest por padrão na primeira entrada do grupo consumidor. Se você estiver desenvolvendo sobre isso, reserve tempo para monitoramento de lag do consumidor — esse é o modo de falha que acomete equipes que não o configuram.

Posso fazer join de eventos de clique com minha própria tabela de usuários?

No seu data warehouse, sim. O padrão é: exportar eventos de clique para BigQuery ou Snowflake via exportação agendada, depois fazer join nos parâmetros UTM ou em um parâmetro user_id personalizado que você anexa aos destinos dos seus links encurtados. O Elido não armazena identidade de usuário em eventos de clique — o click_id é um UUID aleatório por clique, não vinculado a uma conta de usuário.

Como funciona a deduplicação de conversão server-side?

Quando você faz POST de um evento de conversão para o endpoint de conversão do Elido, você inclui o click_id que foi retornado na resposta de clique original (ele é passado como parâmetro de query para a URL de destino). O Elido busca o clique, verifica se ele ainda não foi atribuído e distribui a conversão para GA4 MP, Meta CAPI ou Mixpanel com o contexto UTM do clique original. Submissões duplicadas com o mesmo click_id são idempotentes — são reconhecidas, mas não contadas em duplicidade.

O que acontece se meu consumidor Kafka ficar atrasado?

Os eventos são retidos no tópico por 7 dias. Se o offset confirmado do seu grupo consumidor ficar mais de 7 dias atrasado, eventos mais antigos serão perdidos antes que o consumidor os leia. Monitore o lag do consumidor; configure um alerta com 6 horas de lag como aviso antecipado. Se você ficar atrasado em um evento não recuperável, a exportação agendada para S3/BigQuery cobre a lacuna — é um bom backup para o firehose.

O ClickHouse DSN dá acesso aos dados de outros workspaces?

Não. O DSN tem escopo apenas para a tabela de eventos do seu workspace, via um usuário ClickHouse somente leitura com segurança em nível de linha aplicada. Você não pode ver eventos de outros workspaces. O DSN é revogável nas configurações do workspace; rotacione-o na mesma cadência das chaves API.

Existe um tamanho mínimo de amostra antes de as coortes de cliques serem significativas?

O ClickHouse executa a query de coorte com qualquer tamanho de dados existente — não há mínimo imposto. A significância estatística é julgamento seu. Uma coorte de 50 cliques dá um número, mas é ruidoso. Exibimos contagens brutas e porcentagens; não aplicamos suavização Bayesiana ou intervalos de confiança às visualizações de coorte. Para análise formal, exporte e execute seu modelo no seu data warehouse.

Posso filtrar a exportação agendada para um subconjunto de links?

Sim — os filtros de exportação suportam: domínio específico, ID de campanha específico, tag específica ou intervalo de datas. Uma exportação filtrada ainda é incremental; execuções subsequentes acrescentam apenas novos eventos que correspondem ao filtro. Se você adicionar uma nova condição de filtro a um job de exportação existente, precisará criar um novo job ou fazer uma re-exportação completa avulsa para recuperar o histórico do novo filtro.