← Выберите ракурс, который подходит вашей команде

For analytics-first teams

Click data you can actually query.

Вы измеряете атрибуцию, drop-off в воронке и инкрементальный lift. Elido хранит каждый клик в ClickHouse с прямым доступом — без сэмплинга и задержки агрегации.

Start free Связаться с отделом продаж

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

Сэмплирование кликов

<5с

Задержка приема событий

24 месяца

Хранение данных на тарифе Business

ClickHouse DSN

Прямой SQL-доступ

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

Что означает 'analytics-first' в модели данных Elido

Большинство аналитик в сервисах сокращения ссылок — это агрегированные итоги. Представленные ниже функции объясняют, что меняется, когда первичным артефактом является поток необработанных кликов, а не сводка.

Без сэмплирования

Храним каждый клик — никаких примечаний о сэмплировании после N событий

События кликов поступают через топик Redpanda Kafka и записываются в ClickHouse сервисом click-ingester. Сэмплирование отсутствует. Для ссылки с 10 кликами и ссылки с 10 миллионами кликов все события хранятся в одной таблице — схема не меняется, агрегация при приеме не применяется. Срок хранения: 90 дней на Free, 12 месяцев на Pro и 24 месяца на Business. После истечения срока события безвозвратно удаляются; количество удаленных событий логируется. Схема ClickHouse открыта — вы видите, какие именно поля хранятся, и можете планировать модель данных в своем хранилище до начала экспорта. Задержка от клика до доступности в ClickHouse обычно составляет менее 5 секунд; потребитель Redpanda работает с авто-коммитом и логирует метрики задержки, чтобы вы могли видеть, не отстает ли пайплайн.

Серверная атрибуция

Серверная передача в GA4 MP, Meta CAPI и Mixpanel — дедупликация по клику

Клиентские пиксели теряют значительную часть конверсий из-за блокировщиков рекламы и ITP в iOS Safari. Серверная передача отправляет данные о конверсиях в GA4 Measurement Protocol, Meta CAPI или Mixpanel напрямую из бэкенда Elido — без JS на стороне клиента. Ключом дедупликации является ID клика: когда событие конверсии поступает через вебхук Stripe или Shopify, Elido сопоставляет его с исходным кликом и рассылает по всем настроенным серверным эндпоинтам. ID клика передается как параметр запроса в URL назначения в момент клика; ваш процесс оформления заказа должен сохранить его до события конверсии. Каждое пересылаемое событие содержит исходные UTM-параметры клика, поэтому атрибуция сохраняется во всей воронке. Это полезно для восстановления конверсий, которые теряют клиентские пиксели — это не замена полноценной CDP, но это закрывает типичный разрыв в атрибуции по последнему клику.

Собственная BI-система

Read-only ClickHouse DSN для каждого воркспейса — подключайтесь напрямую к Metabase, Hex или Grafana

Воркспейсы тарифа Business получают read-only ClickHouse DSN, ограниченный их таблицей событий. Подключите Metabase, Hex, Apache Superset, Grafana или любой клиент, совместимый с ClickHouse, и пишите SQL-запросы напрямую к данным кликов. DSN можно ротировать без изменения таблицы событий; он подключается к пользователю с правами только на SELECT, но не INSERT или DROP. Схема ClickHouse стабильна и версионируется; изменения схемы сопровождаются руководством по миграции в ченджлоге. Для команд, которые хотят объединить события кликов с собственными данными продукта — 'какие ссылки привели пользователей, которые в итоге активировались?' — стандартный паттерн заключается в копировании событий в свое хранилище через запланированный экспорт. ClickHouse DSN предназначен для тех, чьи BI-инструменты могут подключаться к ClickHouse напрямую и кому не нужно объединение с внешними таблицами.

Экспорт в хранилище данных

Запланированный экспорт в S3, BigQuery и Snowflake

Запланированный экспорт выполняется с заданной периодичностью (ежечасно, ежедневно) и передает поток событий кликов — или подмножество, отфильтрованное по домену, кампании или тегу — в S3, BigQuery или Snowflake. Экспорт в S3 по умолчанию использует Parquet (доступен JSON); BigQuery и Snowflake используют нативные коннекторы со схемой, которую Elido создает и поддерживает. Инкрементальный экспорт привязан к временной метке события; первый экспорт — это полный бэкфилл за период хранения; последующие добавляют только новые события. Если нужно переиграть данные с определенного момента, доступен разовый полный экспорт через запрос в поддержку. Ошибки экспорта логируются, выполняются повторные попытки; если пакет не удается отправить более 2 часов, на почту воркспейса приходит уведомление.

Kafka firehose

Kafka firehose в реальном времени для пайплайнов, которым не подходит пакетный экспорт

Воркспейсы тарифа Business могут получать события кликов напрямую из топика Redpanda как группа потребителей Kafka. Вы получаете ID группы потребителей, адрес bootstrap-сервера и сертификат клиента — стандартная конфигурация потребителя Kafka. Это правильный путь для алертинга в реальном времени (обнаружение всплесков, аномалий гео), дашбордов реального времени, требующих субсекундных данных, и пайплайнов, где задержка запланированного экспорта слишком велика. Firehose доставляет каждое событие как минимум один раз (at-least-once); ваш потребитель отвечает за идемпотентность при повторном воспроизведении. Срок хранения в топике — 7 дней; если ваш потребитель отстанет более чем на 7 дней, события будут потеряны — настройте мониторинг задержки. Это функция для продвинутой аналитики, требующая написания кода потребителя и опыта работы с Kafka.

Stack you’ll touch

Сырые click-события
Прямой доступ ClickHouse
GA4 / Meta CAPI / Mixpanel
Экспорт в S3 + BigQuery
Per-workspace DSN
Webhook firehose

Что вы будете измерять

Sampling rate: 0% — каждый клик сохранён
Задержка приёма событий: Менее 5 секунд
Горизонт хранения: До 24 месяцев

Команды аналитики, использующие это

Имена пока являются заглушками — реальные кейсы будут опубликованы здесь позже.

“ClickHouse DSN позволил нам подключить Metabase напрямую к данным о кликах без построения ETL. Теперь мы получаем ответ на вопрос 'какая кампания привела к конверсии из MQL в SQL?' прямо в дашборде Metabase без лишней инфраструктуры.”

Команда дата-инженерии, B2B SaaS, Хельсинки

Ведущий дата-инженер

“Серверная передача в Meta CAPI через Elido позволила восстановить атрибуцию примерно для 25% конверсий, которые терял наш клиентский пиксель. Настройка заняла один спринт; точность атрибуции выросла мгновенно.”

Команда аналитики роста, e-commerce, Париж

Инженер по аналитике

“Мы используем Kafka firehose в нашем собственном потоковом процессоре. Задержка событий менее 5 секунд означает, что наши дашборды производительности ссылок в реальном времени не лгут редакции во время прямых эфиров.”

Команда инфраструктуры данных, медиа-компания, Копенгаген

Старший дата-инженер

Аналитика Elido против Bitly Analytics и Heap

Bitly Analytics подходит для подсчета кликов и базового гео. Heap — это полноценная платформа продуктовой аналитики. Сравнение ниже честно описывает, где каждый вариант является подходящим инструментом.

Capability	Elido	Bitly Analytics	Heap
Сэмплирование данных о кликах	0% — каждое событие сохраняется	Агрегированные данные; сырые события недоступны	Зависит от тарифного плана на бесплатном уровне
Прямой SQL-доступ	Read-only ClickHouse DSN (Business)	Нет прямого доступа к БД	Heap Data Lake (экспорт в хранилище)
Запланированный экспорт в BigQuery/Snowflake	Да, Business+	Только экспорт в CSV	Да — основная функция
Kafka firehose в реальном времени	Да, Business+	Недоступно	Недоступно
Серверная передача конверсий	GA4 MP, Meta CAPI, Mixpanel — с дедупликацией	Недоступно	Серверный прием событий (продуктовые события)
Отслеживание на уровне пользователя	Нет — только уровень кликов, без идентификации пользователя	Нет	Да — основная функция
Воронки и когортное удержание	Когорты кликов на тарифе Business	Нет	Полные воронки и когорты — зрелое решение
Хранение событий	До 24 месяцев (сырые данные)	Агрегированные счетчики; сырые данные недоступны	Зависит от плана

Вопросы команд аналитики

Какова точная схема ClickHouse для событий кликов?

Схема открыта в /docs/api-reference в разделе 'Click events'. Основные поля: click_id (UUID), link_id, workspace_id, occurred_at (временная метка UTC), country_iso2, region, city, device_type (mobile/tablet/desktop), os, browser, referrer_domain, utm_source, utm_medium, utm_campaign, utm_term, utm_content. Поля, допускающие null, содержат null, а не пустые строки. Изменения схемы анонсируются в /changelog с руководством по миграции.

Есть ли руководство по потребителю Kafka?

Да — /docs/guides/kafka-firehose содержит информацию о bootstrap-сервере, настройке группы потребителей, ротации сертификатов и примеры кода на Go и Python. Топик создается по одному на воркспейс; количество партиций фиксировано — 12. Сброс смещения (offset reset) по умолчанию установлен на 'earliest' при первом присоединении группы потребителей. Если вы строите систему на этой основе, заложите время на мониторинг задержки (lag) — это основной вид сбоев, с которым сталкиваются команды.

Могу ли я объединить события кликов с моей таблицей пользователей?

В вашем хранилище данных — да. Стандартный паттерн: экспорт событий кликов в BigQuery или Snowflake через запланированный экспорт, затем объединение по UTM-параметрам или кастомному параметру user_id, который вы добавляете к ссылкам назначения. Elido не хранит личность пользователя в событиях кликов — click_id является случайным UUID для каждого клика, не привязанным к аккаунту.

Как работает дедупликация конверсий на стороне сервера?

Когда вы отправляете событие конверсии через POST в эндпоинт Elido, вы включаете click_id, который был возвращен в исходном ответе на клик (он передается как параметр запроса в URL назначения). Elido находит клик, проверяет, не был ли он уже атрибутирован, и рассылает конверсию в GA4 MP, Meta CAPI или Mixpanel с исходным UTM-контекстом клика. Повторные отправки с тем же click_id идемпотентны — они подтверждаются, но не учитываются дважды.

Что произойдет, если мой потребитель Kafka отстанет?

События хранятся в топике в течение 7 дней. Если зафиксированное смещение вашей группы потребителей отстанет более чем на 7 дней, старые события будут потеряны до того, как ваш потребитель их прочитает. Настройте мониторинг задержки; установите алерт на отставание в 6 часов. Если вы упустите данные, запланированный экспорт в S3/BigQuery поможет закрыть пробел.

Дает ли ClickHouse DSN доступ к данным других воркспейсов?

Нет. DSN ограничен только таблицей событий вашего воркспейса через read-only пользователя ClickHouse с применением RLS (row-level security). Вы не можете видеть события других воркспейсов. DSN можно отозвать в настройках; ротируйте его с той же периодичностью, что и API-ключи.

Существует ли минимум размера выборки, чтобы когорты кликов стали значимыми?

ClickHouse выполняет запрос когорт на любом объеме данных. Статистическая значимость остается на ваше усмотрение. Когорта из 50 кликов дает цифру, но она может быть зашумлена. Мы показываем абсолютные значения и проценты; мы не применяем байесовское сглаживание или доверительные интервалы. Для формального анализа экспортируйте данные и запускайте свою модель в хранилище.

Могу ли я фильтровать запланированный экспорт для подмножества ссылок?

Да — фильтры экспорта поддерживают: конкретный домен, ID кампании, конкретный тег или диапазон дат. Отфильтрованный экспорт остается инкрементальным; последующие запуски добавляют только новые события, соответствующие фильтру. Если вы добавите новое условие фильтрации к существующей задаче, вам потребуется либо создать новую задачу, либо выполнить разовый полный переэкспорт для заполнения истории.