Як правильно обирати запити для моніторингу AI-видимості

Запити для моніторингу AI-видимості не можна збирати навмання. Інакше навіть хороший інструмент покаже шум: десь модель згадала бренд, десь ні, але ці відповіді не пояснять структуру попиту або конкурентний розрив.

Головне завдання - підібрати промпти для ChatGPT-моніторингу за реальними сценаріями вибору. Нижче пояснюємо, як скласти список запитів для AI-пошуку, перевіряти рекомендації ChatGPT і не змішувати корисну семантику для GEO з шумовими фразами.

Дві типові помилки на старті

З того, що найчастіше зустрічається, коли команда вперше формує список:

Брендові запити. Перевіряють «що таке [назва бренду]», «послуги [назва бренду]», «відгуки про [бренд]». ChatGPT, очікувано, видає інформацію про бренд. Звіт виглядає «зеленим», але не показує нічого корисного — користувачі такі запити майже не ставлять перед вибором підрядника.
Занадто загальні питання. «Що таке маркетинг», «як працює реклама», «навіщо CRM». Моделі дають довідкову відповідь без брендів. У такій картині неможливо побачити конкурентний розрив.

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

Kozak відсіює шумові запити й залишає пул із реальним наміром вибору

Починайте з сценаріїв попиту, а не зі списку фраз

Перед тим як писати конкретні формулювання, корисно описати ситуації, у яких людина взагалі звертається до AI по рекомендацію. Тобто питання не «які ключі ми хочемо моніторити», а «коли користувач реально ставить запит моделі».

Три основні групи сценаріїв:

Тип сценарію	Що шукає користувач	Приклади
Категорійний	Тип бізнесу, продукту чи послуги	«агенція контекстної реклами в Києві», «CRM для малого бізнесу», «клініка лазерної хірургії»
Порівняльний	Різницю між варіантами	«HubSpot vs Salesforce», «що краще: Pixel чи Samsung», «iHerb або Rozetka»
Проблемно-орієнтований	Шлях вирішення задачі	«як автоматизувати облік клієнтів», «як зменшити вартість заявки», «як підготуватися до операції на коліні»

Окремо існує четверта група — уточнюючі запити, які звужують категорію за бюджетом, регіоном, аудиторією, форматом («CRM до $20 у місяць», «стоматолог дитячий Львів», «контекстолог для B2B SaaS»). Їх додаємо до базової трійки.

Принцип: спочатку JTBD, потім фрази

JTBD (Jobs To Be Done) добре працює для AI-моніторингу. Замість «зберемо ключі через інструмент» — фіксуємо роботи, які виконує користувач, і тільки потім перекладаємо їх у запити.

Приклад для CRM-сервісу:

Jobs: «обрати CRM, який підійде команді з 8 продажів», «зрозуміти, чи можна перейти зі Sheets без болю», «знайти CRM, який зʼєднується з [інструмент]», «зрозуміти, скільки реально коштує впровадження».
Запити: «CRM для команди продажів до 10 людей», «як перейти з Excel/Google Sheets на CRM», «CRM з інтеграцією з Telegram», «скільки коштує впровадження CRM в Україні».

Запити, зібрані від робіт користувача, майже завжди дають релевантніший зріз, ніж запити з keyword-планерів.

Kozak перетворює JTBD, контекст і роботи користувача на запити для моніторингу

Скільки запитів брати на старті

Реалістичний орієнтир для першої ітерації — 40–80 запитів. Менше — мала вибірка, неможливо побачити повторюваність. Більше — без автоматизації важко тримати якість і потрібно більше часу на аналіз.

Розмір ніші	Рекомендована стартова база
Локальний бізнес, 1 категорія	30–40 запитів
Середня агенція / SaaS, 2–4 напрями	60–80 запитів
Великий бренд із кількома категоріями	100–150 запитів, але з групуванням по сегментах

Для другої ітерації базу зазвичай розширюють у 1.5–2 рази, прибравши те, що показало себе як шум.

Фреймворк 4х4 для першого пулу

Якщо немає часу заглиблюватися в JTBD, на старті виручає проста сітка:

4 категорійні запити;
4 порівняльні запити;
4 проблемно-орієнтовані запити;
4 уточнюючі запити під ключові сегменти/продукти.

Підсумок — 16 запитів. Цього достатньо, щоб після першого прогону через ChatGPT, Gemini, Claude і Perplexity побачити:

де бренд зʼявляється стабільно;
у яких темах домінують конкуренти;
які джерела повторюються між моделями;
які сторінки сайту AI підтягує найчастіше.

Після першої ітерації розширюємо сітку до 6х6 або 8х8 — додаючи варіації мови (наприклад, англомовні запити), регіони і сегменти.

Звідки брати ідеї запитів

Не з голови. Робочі джерела ідей:

Джерело	Що з нього беремо
Google Search Console	Запити, за якими сайт уже отримує покази — особливо ті, де високий impressions, але низький CTR
Дзвінки sales-команди	Як клієнти реально формулюють свої задачі — це майже завжди не keyword-фрази
Support-тікети	Уточнюючі запити, які формуються вже після вибору, — частина з них релевантна для проблемно-орієнтованого пулу
Reddit, Quora, профільні форуми	Жива мова, реальні запитання, контекст «за і проти»
AnswerThePublic, AlsoAsked	Структуровані варіанти запитань навколо однієї теми
Reddit threads + Google «People Also Ask»	Перевірка, як питання звучать у реальних діалогах
Конкурентний контент	Заголовки сторінок порівнянь і FAQ-розділи у конкурентів
Підказки самого ChatGPT/Gemini	Запит «які питання люди ставлять перед вибором X» — далі фільтруємо вручну

Поєднання 3–4 джерел дає достатньо матеріалу, щоб не «вигадувати» запити.

Kozak збирає ідеї запитів із GSC, sales, support і форумів в один prompt pool

Як виглядає шумовий запит

Не кожне формулювання корисне для моніторингу. Шумовий запит зазвичай має такі ознаки:

немає явного наміру вибору («що таке маркетинг»);
незрозуміло, чому в ньому має зʼявитися бренд;
модель відповідає пояснювально, без рекомендацій;
запит не привʼязаний до тем, у яких бізнес реально конкурує за попит;
занадто широкий («бізнес в Україні», «технології»).

Інформаційні запити не варто прибирати повністю — вони корисні як другий шар і показують, де у вас провисає пояснювальний контент. Але як основа моніторингу вони не працюють.

Як адаптувати запити під різні моделі

ChatGPT, Gemini, Claude і Perplexity дають різні відповіді на той самий запит. Це нормально — у них різна логіка цитування, різний доступ до вебу і різна тренувальна база. Кілька правил:

Однакове базове формулювання для всіх моделей. Без цього неможливо порівнювати.
Фіксація дати і режиму (з вебпошуком/без). Це частина первинного запису.
Локалізація мови. Український бренд — запити українською; для глобального продукту — окремий англомовний пул.
Локалізація контексту. «Стоматолог» і «стоматолог Київ» — це різні запити з різною конкурентною картиною.
Не редагувати на ходу. Якщо в Gemini не зʼявляється згадка — це дані, а не привід «переписати запит, щоб вийшло». Запит правимо лише з нової ітерації.

Як часто переглядати пул запитів

Моніторинг — не «налаштував і забув». Реалістичний ритм:

Раз на місяць — перегляд базової бази: прибираємо шум, додаємо нові формулювання.
Раз на квартал — повний перегляд: додаємо/видаляємо сценарії, перевіряємо актуальність сегментів, оновлюємо референтну групу конкурентів.
Реактивно — після запуску нового продукту, виходу на нову географію, появи сильного конкурента, великого оновлення моделей.

Між цими точками базу краще не чіпати — інакше неможливо порівнювати зрізи між собою.

Як перевести список запитів у робочу систему

Хороший пул сам по собі ще не дає користі. Він стає корисним, коли далі є чітка послідовність:

Прогнати запити через 3–4 моделі і зафіксувати базову лінію.
Зібрати картину: де бренд зʼявляється, де провал, хто стоїть поруч.
Розкласти джерела по чотирьох категоріях (власні, редакційні, каталоги, конкурентні).
Винести гіпотези для SEO, контенту, PR.
Через 4–6 тижнів — повторити зріз і подивитися на зміну частки голосу.

Якщо база зібрана грамотно, звіт перестає бути списком відповідей і стає робочою картою ринку.

Kozak проводить запит через baseline, sources, hypotheses і повторний запуск

Часті запитання

Скільки разів запускати один і той самий запит? Реалістичний мінімум — 2–3 рази на одну модель у різні дні. Моделі стохастичні, один зріз може давати випадкову картину.

Чи можна моніторити запитами «з повним контекстом» (довгі промпти)? Можна як окремий пул для дослідження, але не як основний. Користувачі рідко формулюють довгі промпти — основна частина запитів коротка.

Чи треба перекладати запити для англомовних моделей? Якщо ваша аудиторія україномовна, основа — українська. Англійський пул має сенс, якщо ви працюєте на закордонні ринки або хочете порівняти, як модель поводиться на іншій мові.

Що робити, якщо запит дає різні відповіді у двох моделях? Записати обидві, не обирати «правильну». Розбіжність — теж дані: показує, що бренд має різну видимість у різних AI-системах.

Чи варто додавати конкурентні запити («чим X гірше за Y»)? Так, але обережно — модель може відповісти ухильно. Кращий формат — нейтральні порівняння («що обрати X чи Y для…»).

Що ще почитати

Як ми робимо це у VYDAI

Підбір запитів — це той момент, де моніторинг або працює, або одразу перетворюється на шум. Тому в VYDAI ми зробили окремий етап онбордингу для базового пулу: вʼ нього зашиті типи сценаріїв (категорійні, порівняльні, проблемні, уточнюючі), і система пропонує варіанти на основі вашої ніші і конкурентів. Далі запити автоматично прогоняються через ChatGPT, Gemini, Claude і Perplexity з фіксацією дати, моделі і режиму — щоб зрізи можна було чесно порівнювати між собою.

Якщо хочете подивитися, як це працює на вашій категорії, можна створити акаунт або подивитися демо. Які запити брати у фінальну базу, вирішуєте ви; ми поруч і покажемо, де є шум, а де реальний попит.