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

Для analytics-first команд

Дані по кліках які можна реально запитати.

Ви вимірюєте атрибуцію, drop-off у воронці та інкрементальний lift. Elido зберігає кожен клік у колонковому аналітичному сховищі з прямим доступом - без семплінгу й затримки агрегації.

Почати безкоштовно Зв'язатися з відділом продажів

Жодного сампліювання кліків на жодному тарифі - кожна подія зберігається
Аналітичний DSN для кожного воркспейсу, read-only, з ротацією
Запланований S3 + BigQuery-експорт (Parquet за замовчуванням)
Сирі події кліків через вебхук-файрхоз / Kafka-consumer

Clicks · last 7 days

elido.me/launch

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

Семплювання кліків

<5с

Затримка інджесту подій

24 місяці

Термін зберігання на Business

Аналітичний DSN

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

Як надходять дані по кліках

Клік → потік подій → аналітичне сховище, без агрегації посередині.

Більшість скорочувачів дають вам лічильник. Ми даємо рядок на клік, що надходить менш ніж за п'ять секунд і доступний для запиту з вашого SQL-клієнта. Пайплайн - один Kafka-сумісний топік, який один consumer дренує в аналітичне сховище - без служби агрегації, без щоденних підсумків, без виноски «сампліровано після 10K».

Step 1
Click
elido.me/x → 302
Edge 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 lag
Our ingestion service 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.

Аналітичний DSN для кожного воркспейсу

Read-only DSN, який можна прямо вставити в Metabase.

Робочі простори Business отримують read-only аналітичний DSN для кожного воркспейсу, прив'язаний до їхньої таблиці подій через row-level security. Підключайте до Metabase, Hex, Apache Superset, Grafana або будь-якого сумісного SQL/BI-клієнта. DSN доступний для ротації з налаштувань робочого простору без зміни базової таблиці.

Стабільна схема
Версіонована в /docs/api-reference; посібники з міграції в /changelog
Row-level security
DSN прив'язаний лише до рядків подій вашого робочого простору
Сумісність з BI-інструментами
Metabase, Hex, Superset, Grafana, Looker - будь-що, що розуміє SQL
Запити менше секунди
Таблиці на 1B рядків - менше 1с для типових агрегацій за країною / годиною

Читати про аналітику →

SQL · query editor

read-only DSN

analytics://ws_8a2f:****@dsn.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 · analytics storeEU region

Географія, що виживає при експорті

Щільність на рівні країни для кожного кліку - не хешований бакет.

Кожна подія кліку включає ISO 3166-1 alpha-2 країну, регіон та місто, розраховані з офлайн гео-IP датасету на рівні межі. Сама IP-адреса усікається до /24 (IPv4) або /48 (IPv6) перед збереженням - тому гео зберігається, але PII - ні. Нижче ті самі дані в UI, що потрапляють у ваш склад - без проміжного рівня агрегації.

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

Переглянути аналітику на посилання →Схема подій → документи

Analytics store

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

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

Щогодинний Parquet до S3, потім нативне перенесення до вашого сховища.

Запланований експорт надсилає події кліків у вигляді Parquet до вашого S3-бакету щогодини або щодня; нативний BigQuery Transfer або зовнішня таблиця Snowflake завантажує звідти. Перший запуск - повне завантаження до вашого вікна утримання; наступні запуски додають лише нові події з ключем за міткою часу. Збої повторюються; якщо пакет не вдається доставити протягом 2 годин - надходить сповіщення dead-letter.

Parquet (за замовчуванням) або JSON; один об'єкт на годинний бакет
Фільтрування експорту за доменом, кампанією або тегом посилання
Нативний BigQuery Transfer + зовнішня таблиця Snowflake
Dead-letter-сповіщення при збої пакету >2 год
Kafka-файрхоз для доставки менше секунди (Business)

Що ви можете зробити

Жодного сампліювання кліків на жодному тарифі - кожна подія зберігається
Аналітичний DSN для кожного воркспейсу, read-only, з ротацією
Запланований S3 + BigQuery-експорт (Parquet за замовчуванням)
Сирі події кліків через вебхук-файрхоз / Kafka-consumer
Затримка запиту менше секунди на таблицях з 1B+ рядків
Серверна атрибуція кліків із дедуплікацією click-ID

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

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

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

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

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

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

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 аналітичний DSN для кожного воркспейсу - підключайтеся прямо до Metabase, Hex або Grafana

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

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

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

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

Kafka firehose

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

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

Стек, з яким ви будете працювати

Сирі click-події
Прямий доступ через SQL
GA4 / Meta CAPI / Mixpanel
Експорт у S3 + BigQuery
Per-workspace DSN
Webhook firehose

Що ви вимірюватимете

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

Аналітичні команди, що працюють на цьому

Імена поки що є плейсхолдерами - реальні назви клієнтів з'являться тут після публікації кейс-стаді.

“Аналітичний 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 - це повноцінна платформа продуктової аналітики. Порівняння нижче чесно показує, де кожен інструмент є найкращим вибором.

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

Питання аналітичних команд

Яка точна схема подій для подій кліків?

Схема відкрита за адресою /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.

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

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

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

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

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

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