Я 18 лет пишу код и устал от веб‑аналитики. Поэтому сделал свою — plsx.ru

Я больше 18 лет пишу код. Работал с разными продуктами: лендинги, SaaS, внутренние системы, high‑load истории. И каждое новое приложение упиралось в один и тот же вопрос: “как мы будем понимать, что делают пользователи?”

Типичный ответ много лет был один и тот же:

- ставим Google Analytics / GA4; - добавляем Яндекс.Метрику; - живём с этим.

Со временем у меня накопилось несколько проблем:

- данные частично режутся блокировщиками трекеров; - схемы событий живут своей жизнью, от проекта к проекту всё разное; - объяснить любому адекватному человеку, почему именно так считает GA4, бывает сложно даже разработчику; - сырые данные или недоступны, или доступны, но работать с ними больно.

В какой‑то момент я понял, что мне не хватает инженерной аналитики: прозрачной, предсказуемой, с контролем над данными. Не “магического сервиса”, а нормального инструмента.

Так я начал делать свой продукт — plsx.ru.

Если коротко: plsx.ru — это своя система веб‑аналитики на ClickHouse с realtime‑отчётами и нормальным API.

Она собирает события с сайта или приложения, складывает их в понятную структуру, строит по ним:

- обзорные метрики (сколько людей, сколько событий, динамика), - realtime‑активность (что происходит прямо сейчас), - отчёты по событиям (какие действия делают пользователи), - отчёты по страницам (какие URL живые, какие “мертвые”), - отчёты по технологиям (браузеры, ОС, устройства, языки и часовые пояса).

И главное — всё это работает на сырых данных, которые можно в любой момент посмотреть и проверить.

Когда я начинал, вариантов было два:

1. Написать очередной “лёгкий трекер”, который складывает JSON “куда‑нибудь”. 2. Собрать систему, которую я сам не буду стыдиться через пару лет.

Я выбрал второй путь.

Вся аналитика живёт в ClickHouse:

- отдельная таблица событий, - отдельная таблица сессий, - отдельная таблица пользователей.

Каждое событие — это полноценная запись: тип события, пользователь/устройство, страница, реферер, UTM, язык, часовой пояс, данные о браузере, гео, согласия (GDPR) и так далее.

Это позволяет:

- быстро строить любые разрезы; - не бояться большого объёма событий; - всегда иметь возможность “спуститься” от графика к конкретным строкам.

Сбор данных — это один HTTP‑эндпоинт. Я сознательно назвал его нейтрально:

Не `/track`, не `/analytics`, не `/collect`. Такие маршруты давно в списках блокировщиков, а мне нужна честная статистика, а не борьба с фильтрами браузеров.

Клиент отправляет:

- ключ проекта (apiKey), - идентификатор устройства, - массив событий (до 100 за один запрос) — `page_view`, `click`, `signup`, `purchase` и любые свои.

Дальше сервер:

- валидирует структуру (если что‑то критично не так — это ошибка, а не “ну ладно, запишем”); - проверяет ключ проекта и лимиты (чтобы никто не мог забить API мусором); - нормализует данные о странице и браузере; - при необходимости достраивает гео по IP; - сохраняет события в ClickHouse и обновляет realtime‑счётчики в Redis.

Я делал интерфейс не как “витрину для инвесторов”, а как рабочий инструмент.

Первая страница — это обзорная панель:

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

Это быстрый способ понять, жив ли проект и как он себя чувствует.

Второй важный раздел — real‑time:

- количество событий за последние минуты и час; - активные устройства и сессии; - лента последних событий с информацией о страницах и технологиях; - география и языки активных пользователей.

Это удобно, когда вы выкатываете релиз и хотите видеть, что происходит “здесь и сейчас”, а не “через сутки”.

Отдельные разделы показывают:

- как распределяются типы событий (что пользователи делают чаще всего), - какие страницы реально живые, а какие никто не видит, - с каких устройств, браузеров и ОС к вам приходят люди.

Это уже больше про продуктовые решения: где узкие места, где что‑то не работает, на какие связки “страница + событие” смотреть в первую очередь.

Хотя plsx.ru — не “сервис кибербезопасности”, на этом уровне детализации становится проще замечать странные штуки:

- всплески однотипных событий с одного устройства или API‑ключа, - нетипичную географию, - аномально высокую частоту запросов, - попытки ломиться с неверными ключами.

Часть таких вещей отсекается за счёт лимитов и валидации, часть фиксируется в отдельном журнале. Это помогает не только защищать систему, но и понимать, когда вокруг вашего проекта происходит что‑то необычное.

Я честно не пытаюсь сделать сервис “для всех”. Сейчас plsx.ru прежде всего для:

- разработчиков, которые устали от чёрных ящиков и хотят видеть нормальные данные; - техлидов и CTO, которым важно контролировать, как именно считается аналитика; - проектов, где уже есть трафик и хочется смотреть на него не как на “количество визитов”, а как на реальные действия людей.

Если вы хотите “поставить пиксель и забыть” — на рынке полно решений. Если хотите понимать, что происходит в продукте на уровне событий и сессий — возможно, вам будет интересно.

Это мой первый публичный текст про plsx.ru. До этого проект жил в режиме “делаю для себя и пары своих проектов”. Сейчас я хочу вывести его из этого режима: получить живую обратную связь, ранних пользователей, партнёров и просто людей, которым интересна такая инженерная аналитика.

Если вам откликается идея прозрачной, предсказуемой и честной веб‑аналитики, заходите на https://plsx.ru, пишите, задавайте вопросы. Готов обсуждать архитектуру, кейсы использования и всё, что связано с темой.

Я не считаю plsx.ru “завершённым продуктом навсегда”. Это живой инженерный проект, который я развиваю и буду развивать дальше. Но уже сейчас он решает одну конкретную задачу: наконец‑то даёт возможность смотреть на поведение пользователей так, как привык смотреть разработчик — через нормальные данные, а не через магию чужой чёрной коробки.

📎 Спасибо, что дочитали