Веб-аналитика *

Недавно мы с коллегой поспорили, какую статью на Хабре считать успешной. Я смотрел на охват и дочтения, а он вспоминал публикации, которые собирали сотни комментариев или неделями пополняли избранное. Стало очевидно, что под «успехом» мы понимаем принципиально разные вещи. Для одного это десятки тысяч просмотров, для другого — актуальность прикладной инструкции, а для третьего — горячая дискуссия, которая продолжается даже когда статья уходит из топа. 

Главный подвох открытой статистики Хабра в том, что ее легко трактовать слишком буквально. Высокий охват принято считать признаком сильной темы, длинную ветку комментариев воспринимают как доказательство резонанса, а добавления в закладки называют гарантией практической пользы. Однако эти реакции не складываются автоматически: статью могут сохранить после быстрого просмотра и не прочитать до конца. Подробный разбор читатель может внимательно изучить и оставить без единого комментария. Спорный тезис, напротив, иногда собирает сотни сообщений при вполне среднем охвате.

Чтобы понять, как эти сценарии соотносятся между собой, я разобрал почти триста публикаций блога МТС, вышедших с января по 11 июня 2026 года. Сопоставил охват, дочтения, доскроллы, сохранения, оценки и комментарии, а затем посмотрел, как реакции менялись в зависимости от темы и конструкции материала.

Выясним, что мне удалось узнать.

Полгода назад я закрывал технический долг по производительности на клиентском проекте. Обычная история: интернет‑магазин, мобильный Performance в PageSpeed — 29, владелец каждую неделю спрашивает, когда будет зелёная зона. Мы сделали всё, что делают в таких случаях. Перегнали изображения в WebP и AVIF, вынесли критический CSS в инлайн, убрали три подключения Google Fonts на self‑host, порезали неиспользуемый JavaScript, настроили кэширование на уровне Nginx, подключили CDN. Работы на два месяца.

Мобильный Performance стал 31.

Я открыл трейс в DevTools, развернул Main thread и минут пять просто смотрел. Больше половины длинных задач на главном потоке не имели никакого отношения к сайту. Это был чат.

Дальше начинается то, ради чего написана статья. Я задал себе вопрос, который до этого не задавал ни разу за десять лет работы: а сколько вообще стоит чат на сайте? Не в рублях в месяц — в миллисекундах. И обнаружил, что честного ответа нет ни у кого. Вендоры публикуют вес загрузочного скрипта, обычно 8–15 КБ, и это правда ровно настолько, насколько правдива фраза «билет на самолёт стоит 40 долларов» без учёта багажа, сборов и трансфера. Lighthouse показывает общий счёт по странице и не выставляет его отдельным подрядчикам. Владелец сайта видит красную цифру и не знает, чья она.

Поэтому я посчитал сам. Ниже — метод, который позволяет это сделать воспроизводимо, что из него получилось, и как в итоге выглядит архитектура виджета, который не съедает главный поток.

Стандартная модель атрибуции молча предполагает, что от касания до конверсии проходят часы или дни. У застройщика между кликом по объявлению и подписанием договора — месяцы: просмотры, расчёт ипотеки, семейный совет, ожидание продажи старого жилья. Квартира стоит 6–8 миллионов, на эмоции за вечер её не берут. В этот зазор проваливается вся привычная перформанс-аналитика: окно атрибуции короче цикла, конверсия-деньги живёт в CRM за пределами рекламного кабинета, и сделок за месяц так мало, что любая статистика по отдельному объявлению — шум.

Ниже — инженерный разбор, как под такие условия проектируется сквозная аналитика: какая нужна модель данных, где ломается last-click, как поднять оффлайн-конверсии из CRM обратно в рекламу и что вообще измерять, пока сделок две-три в месяц и обучать модель не на чем. Цифры по спросу в тексте — из нашего аудита рынка квартир по Башкортостану за 24 месяца; сразу оговорюсь, что конкретные доли верны для Уфы, а переносится между регионами только механика, не проценты.

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

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

Мастер отчётов в Директе отдаёт один срез за запрос. Хочешь сравнить расход по площадкам — строишь один отчёт; нужна понедельная динамика стоимости лида — строишь второй; смотришь, какая кампания просела — третий. Между несколькими клиентскими логинами добавьте ещё перелогины. Картина всего аккаунта в этой схеме существует только в голове аналитика, и каждое утро её приходится пересобирать заново.

Мне это мешало достаточно, чтобы потратить вечер и вытащить данные напрямую из Reports API в Google-таблицу: один лист — весь аккаунт по неделям, рядом разрезы по площадкам и по каждой кампании, плюс подневное скользящее окно. Обновляется само через Apps Script. Ниже разберу, как это устроено под капотом, где у конструкции стенки (их хватает) и почему свои боевые дашборды я в итоге всё равно унёс в DataLens. Таблица — пустой шаблон, отдаю по ссылке в конце, можно скопировать и распотрошить.

Адресат — те, кто сам копается в Директе и аналитике. Написали такой инструмент — будет с чем сверить решения; только думаете — сэкономите вечер на граблях.

Кампания с недельным бюджетом 10 000 ₽ в нише, где заявка стоит около 5 000, не обучится никогда — и автостратегия тут ни при чём. Ей просто не на чем учиться: за неделю она не наберёт даже двух заявок, а без набранных заявок look-alike нечем строить закономерность. Это школьная арифметика, и желание заказчика на неё не влияет.

Я веду Яндекс Директ в недвижимости, и почти любой спор «автостратегии всё сливают» против «ручное управление умерло» у меня на глазах сводится к одному инженерному вопросу: наберёт ли алгоритм достаточно размеченных данных, чтобы обучиться в этих конкретных условиях. Стоит посмотреть на автостратегию как на классификатор, которому нужна минимальная обучающая выборка положительных примеров за единицу времени, — и половина мифов вокруг неё отваливается сама.

Дальше — как этот классификатор устроен под капотом (упрощённо, детали Яндекс не раскрывает), почему ему нужен объём, где вместо него честнее ручные ставки и как «удобная» цель тихо ломает всю оптимизацию. В конце — таблица по шести типовым сценариям недвижки. Если у вас поток в сотни конверсий в неделю, большая часть проблем ниже вас не касается: там автостратегии просто работают, и это нормально.

«Реклама не работает» — фраза, которую я слышу от застройщиков чаще любой другой. За ней почти всегда стоит одно: бюджет откручивается, заявки капают, а сделок мало. И первая реакция предсказуемая — добавить денег или сменить подрядчика.

Я решил разобрать эту жалобу на данных: взял 24 месяца помесячной статистики Яндекс Вордстата по Башкортостану и Уфе плюс срез по 109 активным жилым комплексам Уфы. Ниже — что реально видно в этих цифрах, три механизма, из-за которых кампания «буксует», и отдельно то, ради чего эту статью стоит дочитать аналитику: где данные Wordstat нельзя читать в лоб и как я на этом сам мог бы ошибиться.

Адресат — те, кто сам собирает семантику и настраивает кампании в нише недвижимости. Бизнес-рамку («как это влияет на ваши продажи») я убрал — она на сайте. Здесь разговор про методологию: как режется спрос, какие доли из этого можно считать, а какие нельзя.

Google начал разворачивать в Search Console отчётность по своим AI-поверхностям: трафик и показы стало видно с учётом AI Overviews и AI Mode. До этого AI-клики были размазаны внутри общего веб-отчёта, и понять, сколько дал именно ИИ-ответ, было нельзя. Я полез смотреть и довольно быстро уткнулся в потолок.

Оказалось, что Search Console показывает только AI-поверхности самого Google. Ни ChatGPT, ни Perplexity, ни Claude, ни Алиса в него не попадают в принципе — они не Google. Если вы, как и я, хотите видеть весь AI-трафик, а не только гугловский, придётся идти в логи сервера. Ниже — что именно даёт новый отчёт, где у него слепые зоны и как я закрываю их парсером логов.

Ищешь термос — получаешь праймер для ногтей, ищешь одноразовые вилки — держи мотоцикл. Собрали коллекцию самых абсурдных ответов поисковых систем ecom площадок из реальных запросов пользователей и разложили их по шести типам: у безумия, как выяснилось, есть система.

Самый частый запрос, который я слышу от собственников и маркетологов, звучит так: «настройте нам кабинет правильно, и реклама поедет». За ним стоит молчаливое допущение, что эффективность контекста живёт где-то внутри Директа — в ставках, корректировках, наборе целей, выборе автостратегии. Допущение удобное: чинить кабинет понятно как. Но рычаг эффективности чаще лежит в другом месте.

Я пять лет проработал в коммерческом отделе Яндекса, в команде по работе с рекламодателями: моей задачей было повышать отдачу от размещения у крупных клиентов региона. Через эту работу прошли сотни рекламных кабинетов в разных нишах и с очень разными бюджетами. На такой выборке закономерность видна особенно ясно, и ниже я разберу, где реально лежит рычаг эффективности, почему его так часто ищут в настройках и что для этого приходится связывать с CRM.

Разбор для коллег, которые ведут контекст и аналитику руками. Кейсов с конкретными цифрами здесь не будет: материал про подход и насмотренность, метрики клиентов я выдумывать не стану.

Недавно в отраслевой рассылке SEOFOMO мелькнула цифра — ChatGPT в режиме поиска повторяет около 34% своих query fan-out. То есть когда вы задаёте разные вопросы, модель под капотом раскладывает их на под-запросы к поиску — и примерно треть этих под-запросов повторяется от промпта к промпту. Есть устойчивое ядро, которое крутится постоянно.

Я работаю с видимостью брендов в нейросетях и сразу подумал: если ядро под-запросов стабильно, то и цитируемость источников не может быть равномерным шумом. Она должна расслаиваться — стабильное ядро сайтов, которые попадают в ответ почти всегда, и длинный хвост тех, кого система вспоминает через раз. Гипотезу можно проверить руками. Ниже — как я это сделал: замкнутый список из 16 брендов, шесть нейросетей, 591 обезличенный ответ и немного Python.

В Telegram Ads легко собрать медиаплан, который внушительно выглядит в таблице: сотни каналов, несколько аудиторных сегментов и десятки гипотез. Сложнее понять, где заканчивается тематическое совпадение и начинается бесполезный трафик.

В кампании эксперта по Amazon мы протестировали больше 200 площадок. Основную часть результата дали единицы. В статье разбираю, как мы делили аудиторию, отсеивали каналы и почему низкая цена подписчика на небольшом объёме ещё не делает площадку рабочей.

Известный в Linux-сообществе автор технической литературы Роб Кеннеди опубликовал историю создания Linux.org — одного из первых веб-сайтов, посвящённых Linux, — а также рассказал о его недавнем возрождении.

Я закинул бюджет в Telegram-рекламу своего pet-проекта — новостного бота — и за сутки получил +232 подписчика. Дашборд загорелся зелёным: «активация 81%». Палец уже тянулся к кнопке «пополнить баланс».

Хорошо, что не долил. Потому что когда я посмотрел, что эти 232 человека реально делают, оказалось: живое действие — осознанный тап 👍 или клик по ссылке — сделал ровно один. Остальные 231 — мёртвые души: 35% заблокировали бота в первый же день, а 218 из 232 зарегистрировались в один и тот же час.

Но самое неприятное — врала не только реклама. Врала моя собственная метрика: «активация 81%» считала автоматические просмотры, которые бот пишет сам себе в онбординге. Я радовался цифре, которую проще всего накрутить.

В посте — как я поймал накрутку собственными метриками за один вечер, почему «цена за подписчика» это ловушка, какую единственную цифру нельзя подделать по построению, и как отличить живой трафик от ботофермы тремя простыми SQL-запросами. С реальными числами из прода: Habr — 28% живых, органика — 19%, платная реклама — 0.4%.

Веб-аналитика живёт за дашбордами и HTTP-API: чтобы узнать, откуда пришёл трафик за неделю, человек лезет в интерфейс Метрики, а программа — собирает запрос к Reporting API и держит в голове namespace полей, лимиты и форматы ответа. LLM-агент (Claude, модель в Cursor, любой другой) по умолчанию не умеет ни того, ни другого.

Мостом между агентом и внешней системой служит MCP — Model Context Protocol. Разбираю, как устроен MCP-сервер для Яндекс.Метрики: как уложить отчёты в небольшой набор инструментов, как авторизоваться в Yandex ID без клиентского секрета (это оказалось самым неочевидным) и на какие грабли Reporting API я наступил по дороге.

Понадобилось дать ИИ-ассистентам (Claude Code, Cursor) доступ к данным своего сервиса — мониторы, события, аптайм, — чтобы вопрос «что сейчас в сбое?» можно было задать прямо в чате, а не идти кликать по вкладкам дашборда. Стандартный путь для этого — MCP (Model Context Protocol): сервер декларирует инструменты, и любой MCP-клиент их находит и вызывает.

Официальные примеры и SDK предлагают поднимать отдельный MCP-сервис — с транспортной машинерией, сессиями и SSE-стримингом. Я сделал иначе: один HTTP-хендлер внутри существующего Go-монолита, около 200 строк, без единой новой зависимости. Вечер работы, включая тесты curl-ом.

В статье разбираю: какой минимум JSON-RPC-методов реально требует спека для tools-only сервера (initialize, tools/list, tools/call — и почти всё), почему stateless-режим без Mcp-Session-Id легален по спецификации и что он даёт бесплатно, зачем хранить id запроса как json.RawMessage, как описывать инструменты, чтобы LLM вызывала их правильно, и какие грабли ждут при подключении Claude Code и Cursor. Весь код — из работающего продакшена, сокращён до сути.

В прошлых статьях я уже подробно разобрал базовую инфраструктуру Matomo: как развернуть систему на собственном сервере LAMP, рассчитать нагрузку, выстроить правильную архитектуру сайтов, measurable и Roll-Up аналитики внутри Matomo. Но вся эта серверная часть — только фундамент. 

И сегодня мы наконец переходим к самому важному слою Matomo — tracking-коду и архитектуре отслеживания пользовательских действий.

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

Цена компрометации веб-ресурсов выросла. Если раньше взлом сайта часто ограничивался банальным дефейсом или кражей маркетинговой базы данных, то сегодня веб-приложение — это полноценные ворота вглубь корпоративного периметра, способные остановить ключевые бизнес-процессы, парализовать цепочки поставок или полностью скомпрометировать процесс создания программного обеспечения.

В этой статье рассказываем про ключевые тренды и прогнозы, связанные с киберугрозами веб-приложений.

У меня есть сайт на Next.js. Часть страниц индексируется почти сразу. Часть застряла в статусе «Обнаружено, не проиндексировано» уже две недели. Самое неприятное в том что все страницы технически одинаковые. Тот же фреймворк, тот же сервер, тот же sitemap.

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

Это третья, финальная часть серии про сайты под управлением ИИ. В первой разбирали, что такое нейросайт и сколько он стоит; во второй — внутреннее устройство: MCP‑брокер, пайплайн деплоя, безопасность. Эта часть больше ориентирована на маркетинговые и бизнес‑задачи: не про то, как это работает, а про то, какие выгоды это даёт бизнесу: позиции, трафик, конверсию, и главное — скорость и стоимость изменений.

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