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

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

Я решил разобрать эту жалобу на данных: взял 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‑брокер, пайплайн деплоя, безопасность. Эта часть больше ориентирована на маркетинговые и бизнес‑задачи: не про то, как это работает, а про то, какие выгоды это даёт бизнесу: позиции, трафик, конверсию, и главное — скорость и стоимость изменений.

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

Последние пару месяцев часто приходят знакомые бизнесмены и друзья-предприниматели из небольших предприятий. Общий посыл: «Финансовой подушки нет, реклама не работает, какие есть варианты продержаться на плаву, чтобы сохранить коллектив и компанию?»

Как правило, приходят, когда все уже плохо с очевидными, но (с моей точки зрения) заранее неэффективными идеями.

Давайте дадим больше рекламы! В текущей ситуации агрессивные способы продаж навевают тоску. Да и зарплату платить нечем.

Давайте сделаем холодный обзвон! А ресурсов внутренних у компании обычно нет. Да и сколько звонков в день сможет сделать без отрыва от основной работы сотрудник?

Разошлем email и обзвоним старых клиентов!
А вот тут есть, над чем поразмыслить.

В этой статье я опишу один из альтернативных вариантов - контекстную рекламу по сегментам Яндекс.Аудиторий в сравнении с email-рассылкой. 

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

В начале мая в инструменте Lighthouse от Google появилась новая категория проверок «Агентный просмотр».

Если загуглить «как посчитать вовлечённость», все источники говорят одно и то же. Реакции поделить на охват, умножить на сто. Это и есть ERR. Формулу повторяют десятки статей и любая нейросеть. Чего не делает почти никто, так это не объясняет, как потом эту цифру читать. А там начинается самое интересное, потому что у метрики есть пара неочевидных свойств, из‑за которых выводы на ровном месте получаются неверными.

В этой статье разберу JSON-LD для сайтов на Tilda: что именно размечать, как разделять общий код и код конкретной страницы, где проверять микроразметку и какие ошибки чаще всего появляются после правок сайта.

Материал не про то, как скопировать готовый JSON из генератора. Такой вариант годится только для самых простых страниц.

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

Часть этих данных относится ко всему сайту, часть - только к одной странице.

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

Для примеров возьму нейтральную нишу - учебный центр.

«Создание сайтов» — 145 758 показов в месяц по Wordstat. Похоже на огромный рынок: заходи и бери. Но я выгрузил все вложенные запросы и разобрал их по смыслу — и реального «хочу заказать сайт» там оказалось около 3%. Остальное — «сделать бесплатно/самому», серверы Minecraft и даже заказ пиццы. Показываю на цифрах, как большие частотности обманывают, какие две неочевидные ловушки прячутся в Wordstat и как читать его, чтобы не сливать бюджет на нерабочие запросы.

Есть привычная ошибка в техническом аудите больших сайтов: открыть краулер, поставить лимит побольше и просканировать всё.

На сайте в пару тысяч страниц это работает. На сайте с семизначным инвентарём URL — нет. Полный краул упирается в память, диск, сетевые таймауты, rate limit, JavaScript-рендеринг, дубли, параметры, бесконечные фасеты и в то, что через двое суток вы получаете таблицу на миллионы строк, которую всё равно придётся сегментировать с нуля.

Поэтому я начинаю не с краулера. Я начинаю с sitemap.

В статье показываю sitemap-first подход: как скачать sitemap graph, превратить URL в датасет, разобрать слаги на смысловые группы, сматчить паттерны со спросом, найти пустые посадочные, проверить рендеринг и потом подтвердить гипотезы через GSC, Яндекс.Вебмастер, Метрику и серверные логи.