← Оберіть кут, який підходить вашій команді

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

Що означає «пріоритет аналітики» в моделі даних Elido

Більшість сервісів скорочення посилань надають агреговані дані. Нижче пояснюється, що змінюється, коли сирий потік кліків є основним артефактом, а не просто підсумковим звітом.

Без семплювання

Кожен клік зберігається — без приміток про «вибірку після N подій»

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

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

GA4 MP, Meta CAPI та Mixpanel на стороні сервера — дедупліковано відносно кліку

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

Власна BI

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

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

Експорт у сховище даних

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

Запланований експорт запускається з налаштованою періодичністю (щогодини, щодня) і передає потік подій кліків — або вибірку, відфільтровану за доменом, кампанією або тегом посилання — в S3, BigQuery або Snowflake. Експорт в S3 за замовчуванням використовує Parquet (доступний також JSON); BigQuery та Snowflake використовують нативні конектори зі схемою, яку Elido створює та оновлює. Інкрементальний експорт базується на мітці часу події; перший експорт — це повне заповнення за весь період зберігання; наступні експорти додають лише нові події. Якщо потрібно повторно отримати дані з певної мітки часу, доступний разовий повний експорт через запит у підтримку. Помилки експорту логуються і повторюються; якщо батч не вдається відправити більше 2 годин, на email воркспейсу надходить сповіщення.

Kafka firehose

Kafka-конс'юмер у реальному часі для пайплайнів, які не можуть чекати батч-експорту

Воркспейси плану Business можуть споживати події кліків безпосередньо з топіка Redpanda як група конс'юмерів Kafka. Ви отримуєте ID групи конс'юмерів, bootstrap-сервер і клієнтський сертифікат — стандартна конфігурація Kafka. Це правильний шлях для сповіщень у реальному часі (виявлення сплесків на посиланні, прапорці гео-аномалій), дашбордів реального часу та пайплайнів, де періодичність запланованого експорту є занадто низькою. Firehose доставляє кожну подію принаймні один раз (at-least-once); ваш конс'юмер відповідає за ідемпотентність при повторному читанні. Термін зберігання в топіку становить 7 днів; якщо ваш конс'юмер відстане більше ніж на 7 днів, події будуть втрачені — налаштуйте моніторинг лагу. Це функція не для новачків; вона вимагає написання коду конс'юмера та операційного досвіду роботи з Kafka. Якщо запланований експорт у BigQuery задовольняє ваші потреби, почніть з нього.

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, Гельсінкі

Lead Data Engineer

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

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

Analytics Engineer

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

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

Senior Data Engineer

Аналітика Elido vs Bitly Analytics vs 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 timestamp), country_iso2, region, city, device_type (mobile/tablet/desktop), os, browser, referrer_domain, utm_source, utm_medium, utm_campaign, utm_term, utm_content. Поля, що можуть бути порожніми, мають значення null, а не порожні рядки. Зміни схеми анонсуються в /changelog з гайдом по міграції.

Чи є посібник з використання Kafka-конс'юмера?

Так — /docs/guides/kafka-firehose описує налаштування bootstrap-сервера, групи конс'юмерів, ротацію клієнтських сертифікатів та приклади коду конс'юмера на Go та Python. Топік надається один на воркспейс; кількість партицій фіксована — 12. Скидання офсету за замовчуванням встановлено на найдавніше (earliest) при першому приєднанні групи. Якщо ви будуєте систему на цьому, закладіть час на моніторинг лагу конс'юмера — це основна точка відмови для команд, які його не налаштували.

Чи можу я об'єднати події кліків із власною таблицею користувачів?

У вашому сховищі даних — так. Стандартний паттерн такий: експортуйте події кліків у BigQuery або Snowflake через запланований експорт, а потім робіть join за UTM-параметрами або кастомним параметром user_id, який ви додаєте до посилань Elido. Elido не зберігає ідентичність користувача в подіях кліків — click_id це випадковий UUID для кожного кліку, не прив'язаний до облікового запису користувача.

Як працює дедуплікація серверних конверсій?

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

Що станеться, якщо мій Kafka-конс'юмер відстане?

Події зберігаються в топіку протягом 7 днів. Якщо зафіксований офсет вашої групи конс'юмерів відстане більше ніж на 7 днів, старіші події будуть втрачені до того, як конс'юмер їх прочитає. Моніторте лаг конс'юмера; налаштуйте сповіщення при лагу в 6 годин як раннє попередження. Якщо ви втратили дані, які неможливо відновити з топіка, запланований експорт в S3/BigQuery покриє цю прогалину — це хороший бекап для firehose.

Чи дає ClickHouse DSN доступ до даних інших воркспейсів?

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

Чи є мінімальний розмір вибірки, після якого когорти кліків стають значущими?

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

Чи можу я відфільтрувати запланований експорт для певної групи посилань?

Так — фільтри експорту підтримують: конкретний домен, ID конкретної кампанії, конкретний тег або діапазон дат. Відфільтрований експорт залишається інкрементальним; наступні запуски додають лише нові події, що відповідають фільтру. Якщо ви додасте нову умову фільтра до існуючого завдання експорту, вам потрібно буде або створити нове завдання, або зробити разовий повний ре-експорт для заповнення історії за новим фільтром.