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

Для 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 страну, регион и город, определённые из офлайн-набора данных geo-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

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

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

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

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

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

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

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

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

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

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

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

Kafka firehose

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

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

Стек, с которым вы будете работать

Сырые 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, Хельсинки

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

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

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

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

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

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

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

Аналитика Elido против Bitly Analytics и 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), 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 поможет закрыть пробел.

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

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

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

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

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

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