AI visibility tracking: видимость бренда в нейросетях

Что означает видимость в AI для B2B-компании

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

Это определение сразу отсекает формулировку, которую используют большинство вендоров и большинство внутренних презентаций. "Наша видимость в AI - 34%" не является утверждением о вашем бренде. Это утверждение о 34% какой-то выборки, и пока выборка не опубликована рядом с числом, у читателя нет способа его оценить.

Оно же отсекает и обратную ошибку. Если проверку не удалось выполнить или блок AI Overviews не появился - это недоступное наблюдение. Это не доказательство отсутствия бренда. Мы разводим эти два состояния по разным категориям данных с самой первой таблицы, потому что их смешивание портит все последующие сравнения периодов.

За этим есть исследовательский фон. Работа по GEO авторства Aggarwal и соавторов, принятая на KDD 2024, формализовала видимость в генеративных ответах как то, что можно определить и измерить, а не угадывать, и сообщила об улучшении метрик видимости до 40% в рамках их экспериментальной постановки (GEO: Generative Engine Optimization{rel="nofollow noopener noreferrer"}). Это академический результат в контролируемых условиях. Это не прогноз для вашего пайплайна, и мы никогда не подаём его клиенту как прогноз.

Упоминания бренда, рекомендации и цитирования сайта

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

• Упоминание. Название бренда появляется в ответе в любой роли, включая нейтральный алфавитный список подрядчиков или мимоходное упоминание в абзаце про рынок.
• Рекомендация. Модель прямо предлагает компанию как подходящую под заявленную задачу покупателя: "для производственного клиентского портала с интеграцией ERP рассмотрите X".
• Цитирование. Ответ ссылается на домен, который вы отслеживаете. Разделяйте собственные домены и сторонние страницы, которые о вас пишут, - они зарабатываются совершенно по-разному.

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

Мы регулярно видим этот паттерн на собственном контенте. Наша статья о подключении корпоративного сайта к CRM и ERP используется как источник для объясняющей части ответа, а дальше тот же ответ перечисляет трёх других подрядчиков как кандидатов на работу. Наша страница дала аргументацию; место в шорт-листе получил кто-то другой. Если отчёт показывает только "мы присутствовали", такой ответ выглядит победой. Это не победа. Это цитирование с упущенной рекомендацией, и исправляется оно совсем другой работой.

Какие решения покупателя должно поддерживать измерение

Метрика оправдывает своё место, только если меняет решение. В B2B реально значимы три решения, и каждое зафиксированное наблюдение должно соотноситься с одним из них.

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

Наше практическое правило: если метрика не может изменить маркетинговое или продажное действие, ей нет места в отчёте. Доля голоса по вопросам, которые никто не задаёт перед покупкой, - это украшение, а не KPI.

Какие метрики видимости в AI отслеживать

Пять метрик покрывают то, что реально нужно B2B-компании: коэффициент упоминания, коэффициент цитирования домена, коэффициент рекомендации, доля голоса в AI и точность описания. У каждой должен быть явный знаменатель, напечатанный рядом, и у каждой есть свой способ ввести вас в заблуждение, когда знаменатель скрыт.

Зафиксируем обозначения до первой формулы. Это рабочие определения данной статьи, а не отраслевой стандарт, - отраслевого стандарта сейчас не существует.

N = число валидных ответов в определённом срезе
M = число валидных ответов, содержащих бренд
C = число валидных ответов, цитирующих отслеживаемый домен
R = число валидных ответов с явной рекомендацией компании
S = число валидных ответов на вопросы о выборе подрядчика
T = суммарное число присутствий брендов из фиксированного конкурентного набора в срезе

"Срез" - это одна комбинация платформы, интерфейса, рынка, языка и периода. Агрегируйте по срезам только тогда, когда письменно решили, что срезы сопоставимы.

Коэффициент упоминания, цитирования и рекомендации

Три отношения, три разных знаменателя, и именно на третьем большинство отчётов ошибается.

Коэффициент рекомендации использует S, а не N, намеренно. Рекомендация - осмысленное событие только там, где покупатель спрашивал про подрядчика. Деление рекомендаций на все ответы, включая "что такое клиентский портал", даёт число, которое плывёт каждый раз, когда вы добавляете в реестр объясняющие вопросы.

Неудавшиеся проверки никогда не исчезают. Они исключаются из валидных ответов и отчитываются отдельной строкой качества данных. Срез с долей успешных проверок 96% и срез с 61% несопоставимы, как бы похоже ни выглядели их коэффициенты упоминания.

Для AI Overviews нужны три собственных знаменателя, потому что сам блок - переменная величина:

• Доля появления блока = запросы с блоком / успешно проверенные запросы
• Доля бренда внутри появившихся блоков = блоки с брендом / появившиеся блоки
• Присутствие бренда по всей выборке = запросы с блоком и брендом / успешно проверенные запросы

Если в срезе не появился ни один блок, вторая метрика не определена. Отчитаться о ней как о 0% - фактическая ошибка, которая уже стоила не одной команде бессмысленного квартала "восстановительных" работ.

Доля голоса в AI и точность описания

Доля голоса в AI (AI Share of Voice) сравнивает вас с фиксированным конкурентным набором и читается только тогда, когда этот набор заморожен и опубликован.

AI Share of Voice = M / T x 100%

Правила, которые делают число честным: каждый бренд считается один раз на ответ независимо от того, сколько раз он назван; ваш собственный бренд входит в конкурентный набор; при T = 0 метрика не определена, а не равна нулю. Изменение списка конкурентов в середине квартала меняет T и, следовательно, вашу долю голоса без каких-либо изменений на рынке.

Гипотетический пример (учебные числа, не данные исследования). Возьмём срез из 120 валидных ответов. Бренд появляется в 24 из них, значит коэффициент упоминания равен 24 / 120 = 20%. На тех же 120 ответах все бренды фиксированного конкурентного набора вместе дают 80 присутствий, считая один раз на бренд на ответ. Доля голоса в AI тогда равна 24 / 80 = 30%. Эти цифры иллюстрируют только арифметику и знаменатели. Это не бенчмарк, не целевой показатель и не результат какого-либо исследования.

Точность описания (Description Accuracy) - качественная метрика, и в контексте выбора подрядчика она может значить больше, чем частота. Оценивайте каждый брендовый ответ по короткой фиксированной шкале, например:

• Точное - услуги, рынки, отрасли и подтверждения опыта указаны верно.
• Частично точное - ядро верное, но с одной существенной ошибкой или пропуском.
• Неточное - не те услуги, не тот рынок, не та компания или выдуманные утверждения.

Неточное упоминание может быть хуже отсутствия упоминания. Если ответ описывает компанию, делающую ERP и B2B-платформы, как небольшую студию разработки сайтов, этот ответ активно вычёркивает вас из шорт-листа, в который вы иначе попали бы. Частотные метрики этого не видят. Оценённая выборка брендовых ответов - видит.

Почему видимость, трафик и выручку нужно мерить отдельно

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

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

Универсального бенчмарка "хорошей видимости" тоже не существует. Никто не скажет вам, какой коэффициент упоминания должен быть у B2B-софтверной компании сегмента mid-market на немецком рынке по вопросам сравнения решений, потому что сопоставимого публичного датасета нет. Единственные честные сравнения - с вашей собственной базовой линией и с вашим фиксированным конкурентным набором при неизменном протоколе.

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

Как построить репрезентативный набор вопросов покупателя

Реестр вопросов - это и есть измерительный инструмент. Если он слабый, все последующие числа декоративны, каким бы продвинутым ни был инструмент, который их произвёл.

Стройте реестр из того, что покупатели говорят на самом деле. Инструменты для работы с ключевыми словами здесь дополнение, а не источник, потому что люди формулируют запрос ассистенту иначе, чем набирают в поисковой строке. "разработка b2b портала компания" - это поисковый запрос. "Мы производим промышленную арматуру, а дилеры заказывают по почте, что нам строить?" - это промпт. Разделение одинаково в любой вертикали: "разработка сайтов недвижимости" - это запрос, а "наши агенты теряют объекты, потому что сайт не умеет фильтровать по районам" - это промпт.

Заморозьте реестр как базовую линию, версионируйте его и отмечайте любое изменение в отчёте. Держите общее межрыночное ядро, чтобы рынки оставались сопоставимыми, плюс локальное расширение под каждый рынок для вопросов, существующих только там.

Источники вопросов: продажи, CRM и поисковые данные

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

• Заметки со звонков и списки возражений. Точная фраза, которой клиент описал свою проблему, стоит больше десяти вариантов ключевых слов.
• Записи в CRM. Описания первого контакта, тексты RFP, квалификационные вопросы и причины проигранных сделок показывают, что покупатели сравнивали, когда выбрали кого-то другого.
• Поисковые данные. Запросы из Search Console и кандидаты из семантики, каждый - через простую проверку: сформулировал бы человек это так, обращаясь к ассистенту?
• Команды поддержки и внедрения. Вопросы, которые клиенты задают на третий месяц, часто предсказывают то, что следующий потенциальный клиент спросит на первой неделе.

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

Исследование проблемы, сравнение решений и выбор подрядчика

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

Стадия 1, исследование проблемы. "Как связать корпоративный сайт с CRM и ERP?" "Когда производителю нужен клиентский портал?" "Что ломается, когда дилерские заказы обрабатываются по почте?"

Стадия 2, сравнение решений. "Своя разработка или готовое решение для B2B-портала." "Какой подход к интеграции подходит для устаревшей ERP без современного API?" "Headless commerce или кастомный портал для дилерских заказов?"

Стадия 3, выбор подрядчика. "Как сравнивать подрядчиков по разработке B2B-порталов?" "Что компании среднего размера стоит спросить у вендора ПО до подписания?" "Есть ли у компании X опыт интеграции с нашей системой?"

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

Брендовые и небрендовые вопросы, варианты формулировок

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

Варианты формулировок значат больше, чем ожидают команды. Препринт о хрупкости к перефразированию в retrieval-augmented коммерческих рекомендациях сообщает, что результаты рекомендаций заметно менялись при перефразировании одного и того же запроса - в тех условиях, которые изучали авторы (Paraphrase Brittleness in Production Retrieval-Augmented Commercial Recommendation{rel="nofollow noopener noreferrer"}). Это препринт 2026 года авторов, аффилированных с Unusual, и мы ссылаемся на него узко: он поддерживает идею проверять несколько формулировок на вопрос и не обобщается на любую платформу или интерфейс.

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

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

Как проводить сопоставимые проверки на разных платформах и рынках

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

Правило, экономящее больше всего переделок: никогда не смешивайте результаты через API и результаты из пользовательского интерфейса в одну метрику. Это разные продукты с разным поведением поиска, разными настройками по умолчанию и разной доступностью. Всегда ведите их как отдельные срезы.

Проверяйте доступность интерфейсов и регионов до запуска, а не после первой аномалии. Рынок, где нужный режим недоступен, порождает поток неподдерживаемых условий, и если вы обнаружите это на шестой неделе, придётся выбросить недели с первой по пятую.

Фиксация интерфейса, языка, рынка, даты и контекста диалога

Логируйте каждое наблюдение одним и тем же набором полей, каждый раз. Ниже - минимум, который мы внедряем клиентам.

Храните сырой ответ, а не только разобранный вердикт. Когда на четвёртый месяц вы уточните определение "рекомендации", сырые ответы позволят пересчитать всю историю. Разобранные вердикты - нет.

Держите рынок, язык и локацию пользователя как три разных измерения. Проверка на немецком языке - не автоматически проверка немецкого рынка, а проверка, выполненная из одной локации, не является утверждением о покупателях в другом месте. Схлопывание этих трёх в одно "DE" - самая частая причина, по которой межрыночные отчёты перестают иметь смысл. Сильнее всего локация влияет на услуги, которые покупают локально: разработка сайта стоматологии в одном городе попадает в рекомендации, в соседнем - нет, и отчёт без поля локации назовёт это шумом.

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

Повторные проверки, варианты промптов и фиксированная базовая линия

Зафиксируйте число повторов на вопрос и держите его стабильным между периодами. Повторы снижают часть случайной вариации между прогонами. Они не делают вашу выборку репрезентативной для всей аудитории, и никакое количество повторов этого не сделает.

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

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

Любое изменение протокола получает датированную пометку в шапке отчёта. Одно осознанное изменение за период - дисциплина, которая делает следующее сравнение читаемым.

Отсутствующие AI Overviews, неудавшиеся проверки и неподдерживаемые условия

Три статуса, три разных смысла, и ни один из них не означает нулевую видимость.

• Блок отсутствует. Проверка прошла успешно, и блок AI Overviews по этому запросу не появился. Это валидное наблюдение о выдаче. Оно входит в знаменатель доли появления блока и не затрагивает метрику "доля бренда внутри блоков".
• Проверка не удалась. Ошибка сбора: таймаут, лимит запросов, сбой парсинга, проблема сессии. Это вообще не наблюдение. Оно исключается из валидных ответов и отражается в доле успешных проверок.
• Условие не поддерживается. Платформа, режим или региональная настройка недоступны на этом рынке или в этом интерфейсе. Это ограничение охвата. Отчитайтесь по срезу как о непокрытом и скажите это явно, а не оставляйте пустую ячейку, которую читатели прочтут как ноль.

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

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

Сравнение результатов на русском, немецком и английском

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

Заметки по немецкому рынку. Используйте термины, которыми пользуются покупатели: KI-Sichtbarkeit для видимости в AI, Nachvollziehbarkeit для прослеживаемости отчётности, Mittelstand для сегмента среднего бизнеса, qualifizierte Anfragen для квалифицированных обращений. Немецкие B2B-покупатели раньше задают более процедурные вопросы, и реестр должен это отражать.

Заметки по рынку США. Vendor evaluation, qualified leads, pipeline, buying committee. Вопросы о выборе подрядчика приходят раньше и формулируются прямее.

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

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

Как измерять AI-трафик в GA4 и Search Console

Измерение трафика переводит вас от выборочных ответов к наблюдаемым визитам, а это совершенно другая популяция с совершенно другими ограничениями. Мониторинг сказал, что модель ответила вам; аналитика говорит, что сделали реальные пользователи, минус всё, что браузер и приложение ассистента не передали дальше.

Google Analytics описывает канал AI Assistant в определениях группы каналов по умолчанию (Google Analytics: Default channel group{rel="nofollow noopener noreferrer"}). Трафик, приходящий из AI Overviews и AI Mode внутри Google Поиска, классифицируется как Organic Search, потому что это поисковый трафик, и в отчётах он ложится рядом с результатами SEO-продвижения сайта.

Со стороны Search Console Google указывает, что результаты AI-функций включены в общий отчёт по типу поиска "Веб" (Google Search Central: AI features and your website{rel="nofollow noopener noreferrer"}). Отдельного отчёта по трафику из AI Overviews не существует. Любой дашборд, утверждающий, что показывает точный объём кликов из AI Overviews отдельной строкой, показывает оценку, и её следует так и подписывать.

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

Канал AI Assistant и источники сессий

Проверяйте область метрики каждый раз, когда читаете число: пользователь, сессия или событие. График "сессии" и график "пользователи" одного и того же канала рассказывают разные истории, и отчёты, молча их смешивающие, встречаются часто.

Читайте источник и канал сессии вместе с группировкой каналов, а не доверяйте только метке канала. Группировки каналов - это классификации на основе правил, которые эволюционируют; исходные значения source и medium - то, что вы можете проверить и при необходимости переклассифицировать.

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

Соответствующая дисциплина: не приписывайте весь Direct-трафик и весь рост брендового поиска работе над видимостью в AI. И то и другое движется по многим причинам, включая офлайн-активность, мероприятия, PR и обычную сезонность. Если отчёту нужно причинное утверждение, ему нужен эксперимент, а не график каналов.

AI Overviews и границы отчётности по органическому поиску

Обозначьте границу по собственной документации Google и на этом остановитесь. Результаты AI-функций свёрнуты в отчёт по типу поиска "Веб"; показы и клики из этих функций считаются внутри него, а не выделяются в отдельную AI-поверхность.

Что можно наблюдать:

• Динамику на уровне посадочных страниц
• Тренды на уровне запросов внутри веб-отчёта
• Изменения показов и кликов на страницах, которые вы намеренно меняли
• Изменения позиций и покрытия по запросам из вашего реестра

Что наблюдать нельзя:

• Точный промпт пользователя за конкретным визитом
• Пришла ли конкретная сессия из клика в AI Overviews или по классической ссылке
• Прочитал ли пользователь AI-ответ о вас и вообще не кликнул

Позиция, которую мы занимаем с клиентами, намеренно узкая: отслеживать направление и паттерны посадочных страниц и отказываться выдумывать точность на уровне отдельного визита. Руководитель маркетинга, который говорит "мы не можем это разделить, вот что мы можем увидеть вместо этого", сохраняет доверие. Дашборд, который выдумывает разделение, теряет его при первой же проверке.

Посадочные страницы, ключевые события и потерянная атрибуция

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

Настройте как минимум эти ключевые события:

• Отправка формы, с идентификатором формы и контекстом страницы
• Скачивание документа, например презентации возможностей или технического брифа
• Бронирование встречи, включая сценарий планировщика, если он на другом домене
• Глубина просмотра страницы цен или моделей сотрудничества как сигнал намерения
• Действия раскрытия контактов, например клики по email или телефону

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

Пройдите чек-лист валидации данных до первого отчёта для руководства:

1. Совершите контрольный визит из интерфейса ассистента и найдите его в сыром потоке событий.
2. Отправьте контрольную форму и убедитесь, что ключевое событие срабатывает с ожидаемыми параметрами.
3. Подтвердите значения посадочной страницы, источника, канала и кампании, записанные в этой сессии.
4. Проверьте кросс-доменную непрерывность от начала до конца, включая любой внешний планировщик.
5. Проверьте поведение согласия на cookie для каждого рынка, по которому вы отчитываетесь.
6. Убедитесь, что запись в CRM, созданная контрольной отправкой, содержит поля источника привлечения.

Если хоть один шаг не проходит, исправьте до публикации чисел. Публикация сначала и исправление потом навсегда учит руководство не доверять дашборду.

Как связать взаимодействия с AI с B2B-лидами и сделками

Три класса свидетельств должны оставаться раздельными в CRM: наблюдаемый визит, зафиксированное ассистированное взаимодействие и самоотчёт клиента. Они различаются по силе, собираются по-разному, и их смешивание даёт число, которое невозможно защитить перед коммерческим директором.

Держите их раздельно - и отчёт станет читаемым: "обращения с наблюдаемым визитом из AI", "обращения с задокументированным AI-касанием со слов продаж", "обращения, где клиент сам сообщил про AI-ассистента". Смешайте - и получите "AI-лиды", которые никто не может проверить.

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

Передача доступных данных о привлечении в CRM

Передавайте только то, что действительно доступно, и передавайте в сыром виде.

Храните сырые значения и нормализуйте в слое отчётности, а не в момент сбора. Нормализация при сборе уничтожает возможность переклассифицировать данные позже, а правила классификации меняются всегда.

Обработайте офлайн-путь явно. Телефонные звонки, ответы по почте и рекомендации тоже требуют поля источника, и в этом поле нужен явный вариант "неизвестно", который продажам разрешено выбирать. Доля "неизвестно" в 30% - это информация. Вынужденная догадка - это шум, который выглядит как информация.

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

Наблюдаемые визиты, ассистированные взаимодействия и самоотчёты

Добавьте в форму обращения один хорошо сформулированный открытый вопрос: "Как вы впервые узнали о нас?" Относитесь к ответу как к свидетельству, а не как к доказательству.

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

Ассистированные взаимодействия - средний класс свидетельств: задокументированное AI-касание, упомянутое во время звонка и зафиксированное продажами. "Они сказали, что наше название всплыло, когда они спрашивали Gemini про подрядчиков по порталам" - это реальная точка данных, если она записана в структурированное поле с датой. Это не сессия, и ей нельзя появляться в графике сессий.

Дайте продажам способ зафиксировать это за две секунды. Обязательный выпадающий список на первом звонке - наблюдалось / со слов клиента / неизвестно - даёт больше пригодных данных, чем поле свободного текста, которое никто не заполняет.

Дедупликация на уровне аккаунта и длинные циклы продаж

Дедуплицируйте на трёх уровнях: лид, аккаунт и сделка. В B2B несколько участников закупочного комитета приходят по отдельности, часто с разницей в недели, часто через разные каналы, и каждый создаёт запись.

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

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

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

Атрибутированный пайплайн, выигранная выручка и границы причинности

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

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

Формулировка, которую мы рекомендуем для руководства, намеренно проста: "обращения, где AI-касание было наблюдено или сообщено", а не "лиды, сгенерированные AI". Первую фразу можно защитить на любой проверке. Вторую - нет, и в момент, когда финансовый директор её проверит, весь отчёт потеряет вес.

Когда действительно нужно причинное утверждение - например, для бюджетного решения, - нужен дизайн эксперимента: контролируемое изменение, группа сравнения или преднамеренно зафиксированное сравнение "до и после" при неизменности всего остального. Это отдельный проект от отчётности по атрибуции, и планировать его нужно отдельно.

Как выбрать инструмент мониторинга видимости в AI

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

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

Спросите отдельно, что происходит с неудавшимися проверками и отсутствующими AI Overviews внутри математики вендора. Если неудавшаяся проверка засчитывается как отсутствие упоминания, инструмент будет занижать вашу видимость каждый раз, когда деградирует его сбор данных, а вы прочтёте это как изменение рынка.

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

Ручной мониторинг, собственные вопросы покупателя и широкие индексы видимости

• Ручные проверки. Самый дешёвый старт, полный контроль условий, полный доступ к сырым ответам, плохая масштабируемость. Правильный выбор для пилота и для постоянной контрольной выборки.
• Мониторинг собственных вопросов. Автоматизирует ваш реестр по платформам и рынкам. Соответствует описанному здесь методу и даёт числа, которые можно защитить.
• Широкие индексы видимости. Полезны для рыночного контекста и движения конкурентов на уровне категории. Слабы для ваших конкретных решений о покупке, потому что базовый набор вопросов не ваш.

Для терминологии и понимания того, как устроена категория, разумно посмотреть на Ahrefs Brand Radar, Peec AI и SEOWORK, пока вы формируете требования. Мы называем их как примеры того, как описывается категория, - явно не как проверенных лидеров рынка и не как рейтинг, и мы не проводили сравнительную оценку их методологий.

Методы сбора, покрытие рынков и определения метрик

Ниже - чек-лист, который мы даём клиентам перед демо-звонками.

• Метод сбора. API или пользовательский интерфейс? Оба? Они отчитываются отдельно или смешиваются в одно число?
• Покрытие рынков и языков. Может ли вендор действительно воспроизвести рынок, на котором вы продаёте, включая региональные настройки, или только язык?
• Покрытие моделей и режимов. Какие платформы, какие модели, какие режимы и как быстро вендор адаптируется при изменении интерфейса?
• Знаменатели. Показаны ли в продукте N, доля успешных проверок и состав выборки - или только итоговый процент?
• Обработка неудавшихся проверок. Как ошибки, отсутствующие блоки и неподдерживаемые условия учитываются в математике?
• Политика повторов. Фиксированное число повторов на вопрос? Настраиваемое? Постоянное между периодами?
• Контроль конкурентного набора. Можно ли задать и заморозить собственный список конкурентов?

Вендор, который не может ответить на вопрос о знаменателях на демо, не ответит на него и в продакшене.

Сырые ответы, историчность, экспорт и интеграции

Доступ к сырым ответам - самое важное требование в списке. Без сохранённых сырых ответов вы ничего не пересчитаете, когда изменится ваше определение "рекомендации" или "цитирования", а оно изменится в первые два квартала.

• Хранение истории. Как долго хранится история и можно ли её пересчитать после изменения определений?
• Экспорт. CSV и доступ по API к наблюдениям, а не только к графикам.
• Интеграции. Могут ли данные попасть в ваш слой аналитики и отчётности CRM без ручного копирования?
• Права на данные. Если вы уходите от вендора, остаются ли у вас базовая линия и история?

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

Как читать отчёт и решать, что менять

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

Диагностика - это гипотезы для проверки, а не доказанные причины. Отчёт говорит, что было наблюдено; обсуждение после него решает, что пробовать дальше.

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

Дашборд для маркетинга и продаж

Блок шапки. Версия реестра, набор конкурентов, платформы и интерфейсы, число повторов на вопрос, отчётный период, доля успешных проверок по каждому срезу, записи журнала изменений за период.

Маркетинговый блок. Коэффициент упоминания, коэффициент цитирования домена с разделением на свои и сторонние домены, коэффициент рекомендации, доля голоса в AI, распределение точности описания. По каждому рынку и каждой платформе, без смешивания.

Блок трафика. Сессии канала AI Assistant, органические сессии на релевантных реестру посадочных страницах, таблица посадочных страниц, ключевые события и заметка о качестве данных с перечнем известных пробелов, например эффектов согласия на cookie или потери реферера.

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

От наблюдений к проверяемым гипотезам

Обратите внимание на третью строку. Рост упоминаний при неизменных визитах - не автоматически провал. Это может означать, что ответы теперь закрывают вопрос внутри ассистента. Это реальный результат с реальными ограничениями по измеримости, и честный отчёт так и говорит.

Как отличить изменения в бизнесе от изменений в измерении

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

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

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

Когда выборка сломана, переходите к статусу "недостаточно данных", а не отчитывайтесь уверенным числом. Это один непопулярный слайд и постоянный актив в виде доверия.

Как запустить пилот мониторинга за первый месяц

Цель первого месяца - рабочий процесс и точка сравнения, а не результаты по сделкам. Тот, кто обещает коммерческие результаты за четыре недели на B2B-цикле, описывает не ваш бизнес.

Назначьте ответственных в первый же день: интернет-маркетинг владеет реестром вопросов, продажи - квалификацией и полем ассистированного касания, ИТ-партнёр - потоком данных, интеграциями и валидацией. Шаги без владельца - это ровно те шаги, которые тихо не происходят.

Держите пилот достаточно маленьким, чтобы его реально закончить. Два рынка, две платформы, тридцать-пятьдесят вопросов и фиксированное число повторов лучше амбициозного плана, который встанет на третьей неделе. Определите, что означает "сделано", до старта. То же правило масштаба работает и для локального бизнеса: пилот для разработки сайта по ремонту техники идёт на одном городе и двадцати вопросах, дисциплина та же, меньше только объём.

Это пример плана. Реальные сроки зависят от готовности вашей аналитики, CRM и веб-форм, и третья неделя заметно расширяется, когда формы старше CRM.

Цели, реестр вопросов и базовая линия

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

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

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

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

Аналитика, интеграция с CRM и валидация данных

Третья неделя - инженерная. Передайте данные о привлечении в CRM, добавьте поле самоотчёта в форму обращения и внедрите правила дедупликации на уровне лида и аккаунта.

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

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

Документируйте известные пробелы вместо того, чтобы тихо заполнять их допущениями. "Реферер теряется для трафика из приложения ассистента на iOS в этой конфигурации" - полезная строка в отчёте. Молча подставленное значение - нет.

Первое ревью, ответственность и следующие эксперименты

Четвёртая неделя даёт первый отчёт, приоритизированный список гипотез и ровно одно осознанное изменение на следующий период. Сдержите желание поменять пять вещей сразу, потому что первый отчёт оказался неприятным.

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

Задайте горизонт коммерческой оценки в соответствии с реальным циклом продаж и зафиксируйте его письменно, чтобы никто не просил атрибуцию сделок на шестой неделе.

Спланируйте следующий эксперимент как проверяемое утверждение: "Добавление раздела с доказательствами технических интеграций на страницу клиентского портала повысит коэффициент рекомендации по Q-047 и Q-052 за следующие два цикла измерения". Это проверяемо. "Улучшить наш GEO" - нет.

Часто задаваемые вопросы

Можно ли измерять видимость в AI бесплатно?

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

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

Сколько нужно вопросов и повторных проверок?

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

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

Почему инструменты мониторинга расходятся в цифрах?

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

Расхождение между инструментами ожидаемо и не является доказательством того, что один из них сломан. Сопоставим только тренд внутри одного инструмента при фиксированном протоколе. Сравнение вашего числа из инструмента A с числом конкурента из инструмента B или с публичным индексом порождает разговор без защитимого вывода.

Можно ли идентифицировать каждый визит из AI Overviews?

Нет. Google включает результаты AI-функций в общий отчёт по типу поиска "Веб" в Search Console, поэтому отдельного отчёта по трафику AI Overviews, который можно было бы выделить, не существует (Google Search Central: AI features and your website{rel="nofollow noopener noreferrer"}). В GA4 трафик из AI Overviews и AI Mode попадает в Organic Search, а для платформ-ассистентов существует отдельный канал AI Assistant.

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

Что делать, если упоминания растут, а лидов больше не становится?

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

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

Что делать дальше

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

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

Webdelo строит B2B-платформы, интеграции ERP и CRM и high-load сервисы с 2006 года: более 200 реализованных проектов и команды, работающие с компаниями сегмента mid-market в США, Германии, России и СНГ. Мы официальный резидент Moldova IT Park. Мы не обещаем, что система измерения повысит вашу видимость, потому что измерение и рост - это разные проекты с разными рычагами.

Если вы сейчас настраиваете отслеживание видимости в AI или у вас уже есть числа, которым вы не до конца доверяете, мы готовы разобрать вашу текущую конфигурацию вместе с вами: реестр вопросов, настройку аналитики, поля CRM и то, что ваш отчёт может и чего не может законно утверждать. Запишитесь на рабочую сессию с нашей командой и принесите тот дашборд, который у вас есть.