GA4 не може показати точний органічний запит, який привів окремого користувача, оскільки Google не передає його в реферері. Проте SEO-команда не залишається без даних. Запити й покази слід брати з Google Search Console, поведінку та ключові події — з GA4, а зіставляти набори даних на рівні цільової сторінки й періоду. Таке зіставлення допомагає ухвалювати рішення, але не є атрибуцією запиту конкретній сесії.
Нижче наведено відтворювану схему без обіцянки «розкрити» невідомі ключові слова. Вона відділяє спостережувані дані Google від розрахунків і показує межу між фактом та оцінкою.
Розділяйте три рівні даних до аналізу ключів
| Рівень | Що відомо | Як позначати висновок |
|---|---|---|
| Спостереження | Search Console зафіксував запит, покази, кліки, CTR і позицію у вибраному зрізі; GA4 окремо зафіксував поведінку на цільовій сторінці. | Дані Google |
| Зіставлення | Попит за запитами й органічний результат змінювалися разом для однієї сторінки та періоду. | Агрегований зв’язок, не атрибуція сесії |
| Модель | Алгоритм оцінив імовірний запит сесії за кількома сигналами. | Прогноз із зазначеною впевненістю |
Це головне правило статті. Воно запобігає типовій помилці у звітах: корисний зв’язок на рівні сторінки не можна подавати як розкритий Google запит окремого відвідування.
Що означає (not provided) у Google Analytics?
Позначка (not provided) означає, що Analytics розпізнав органічний перехід, але не отримав пошукову фразу. Зазвичай це не помилка налаштування GA4. Запит не надходить на сайт як звичайний параметр переходу, тому зміна фільтра, каналу чи звіту не відновить значення, якого не було у вихідній події.
Не плутайте (not provided) із (not set). Друга позначка означає, що Analytics не зміг заповнити конкретний вимір у рядку звіту. Причина залежить від виміру, тегів, згоди користувача та області звіту. Це відсутнє класифікаційне значення, а не зашифрований органічний запит.
Отже, запитання «який запит спричинив цю сесію?» часто не має перевірюваної відповіді. Краще поставити два окремі запитання: «за якими запитами Google показував сторінку та приводив кліки?» і «що робили органічні відвідувачі після входу на цю сторінку?»
Які дані дають Search Console і GA4?
| Запитання | Джерело | Допустимий висновок | Недопустимий висновок |
|---|---|---|---|
| За якими запитами сторінка отримала покази та кліки? | Search Console | Запити, кліки, покази, CTR і середня позиція у вибраному зрізі | Вибраний запит спричинив конкретну сесію |
| Які цільові сторінки отримали органічні сесії та ключові події? | GA4 | Поведінка й результат за сторінкою, каналом і підтримуваними вимірами | Прихований запит, який спричинив окрему подію |
| Чи збіглися зміни попиту й результату сторінки? | GSC + GA4 | Агрегований зв’язок за датою і цільовою сторінкою | Причинність або точна атрибуція ключового слова |
| Які запити Google приховав? | Жоден звіт | Можна оцінити різницю між підсумком і видимими рядками | Текст прихованих запитів |
Офіційний зв’язок Search Console із GA4 додає два звіти. Google Organic Search Queries показує запити з метриками Search Console, але їх не можна довільно поєднувати з вимірами Analytics. Google Organic Search Traffic пов’язує цільові сторінки із сумісними метриками двох систем. Це корисне обмеження: інтерфейс не вдає, що знає запит кожної сесії.
Урахуйте операційні обмеження до пошуку помилки. Дані Search Console можуть надходити із затримкою до 48 годин, пов’язаний звіт охоплює щонайбільше 16 місяців, а колекція Search Console за замовчуванням не опублікована в GA4. Для створення зв’язку потрібні роль Editor у GA4 та підтверджене право власника ресурсу Search Console.
Чому кліки GSC не дорівнюють сесіям GA4?
Не слід очікувати однакових підсумків. Search Console вимірює дію в результатах Google, а Analytics — події після завантаження сайту. Людина може натиснути кілька разів; сторінка може не завантажитися; тег може бути заблокований; налаштування згоди можуть змінити збір даних. Системи також по-різному обробляють час та ідентичність.
Search Console не показує кожен рядок запиту. Google пояснює, що анонімізовані запити вилучаються заради приватності, хоча їхні кліки можуть залишатися в загальних підсумках. Таблиці також зберігають найважливіші рядки, а не всі можливі. Тому сума вкладки Queries може бути меншою за показник на графіку — це не доказ помилки експорту.
Ілюстративний приклад: графік показує 1 000 кліків, а видимі рядки запитів разом дають 860. Різниця становить 140 кліків, або 14% підсумку. Це наш розрахунок на умовних даних. Він вимірює невідображену частку, але не розкриває 140 невідомих фраз.
Як аналізувати приховані запити за цільовими сторінками?
- Зафіксуйте один період. Використовуйте однакові дати й не додавайте останні неповні дні, доки дані Search Console оновлюються.
- Оберіть один тип пошуку. Не змішуйте Web, Image, Video та News без окремого обґрунтування: поведінка й набір сторінок відрізняються.
- Експортуйте GSC у розрізі query × page. Для великих ресурсів використовуйте експорт даних Search Console і задокументуйте обмеження API.
- Отримайте цільові сторінки GA4 для Organic Search. Зберігайте сесії, залучені сесії, ключові події та дохід лише тоді, коли ці метрики коректно налаштовані.
- Нормалізуйте URL. Протокол, домен, кінцева риска й параметри мають підпорядковуватися одному правилу. Не об’єднуйте різні canonical URL лише через схожий шлях.
- Зіставте рядки за цільовою сторінкою і періодом. Додавайте країну чи пристрій лише тоді, коли виміри сумісні, а вибірка залишається корисною.
- Спочатку ухвалюйте рішення на рівні сторінки. Якщо покази групи запитів зростають, а події сторінки — ні, перевірте інтент, перший екран і шлях до дії. Не приписуйте подію одному запиту без доказу.
GSC Workspace об’єднує запити, сторінки та звіти GA4 в одному робочому просторі, але зберігає межі джерел. GSC є джерелом показників пошуку, GA4 — поведінки на сайті.
Як перетворити зіставлення на SEO-рішення?
Починайте з рішення щодо цільової сторінки, а не зі спроби розподілити кожну конверсію між фразами. Сторінка має спостережуваний набір запитів і спостережуваний результат органічного трафіку. Цього достатньо для багатьох корисних дій.
- Багато показів, мало кліків. Порівняйте інтент із title та сніпетом, а потім перевірте сторінку в CTR Lens.
- Кліки зростають, а ключові події — ні. Перевірте відповідність групи запитів пропозиції, мобільний перший екран і роботу події.
- Одна сторінка приваблює кілька інтентів. Згрупуйте запити й вирішіть, чи потрібен новий блок, окрема сторінка або вилучення нерелевантної теми.
- Один запит веде на різні сторінки. Перевірте країну, пристрій і дату, перш ніж діагностувати канібалізацію.
- Підсумок кліків помітно перевищує суму запитів. Зафіксуйте прогалину як обмеження звіту, а не заповнюйте її вигаданими ключами.
Для великого експорту скористайтеся докладним матеріалом про Search Console API та пагінацію. Google радить вивантажувати дані за днями й попереджає, що групування за page і query може відкидати частину даних. Це обмеження потрібно зберігати в журналі аналізу.
Коли потрібні API або BigQuery?
Інтерфейсу достатньо для швидкої перевірки однієї сторінки чи малого ресурсу. Search Analytics API потрібен для повторюваного експорту, більшої кількості рядків, сталих фільтрів і власної перевірки якості. Google описує пагінацію та обмеження Search Analytics API. API так само не відкриває анонімізовані запити.
Великим сайтам може знадобитися bulk export у BigQuery. За документацією Google, bulk export усуває денне обмеження рядків, але зберігає фільтрацію приватності. BigQuery дає повнішу спостережувану таблицю, а не спосіб обійти захист користувачів.
Імовірнісна модель доречна лише тоді, коли бізнес свідомо приймає оцінку. Модель повинна мати опис ознак, перевірочну вибірку, рівень невизначеності та чітке маркування результату. Поле «прогнозований запит» не можна змішувати зі спостережуваним query із Search Console.
Чого цей процес не робить?
Процес не розшифровує Secure Search, не обходить обмеження Google і не відновлює персональні дані. Він також не доводить, що зміна запитів спричинила зміну конверсій. На результат сторінки можуть вплинути сезонність, реклама, редизайн, ціна, наявність товару або помилка вимірювання.
Ще одне обмеження — деталізація. Кожен доданий вимір зменшує кількість рядків і може посилити вплив фільтрації приватності. Починайте з page × date, а потім додавайте лише один корисний зріз. Якщо даних мало, об’єднуйте періоди або ухвалюйте рішення на рівні тематичної групи.
Що робити далі?
Спочатку зв’яжіть Search Console із GA4 і перевірте офіційні звіти. Потім експортуйте query × page та цільові сторінки Organic Search за один період, нормалізуйте URL і створіть таблицю рішень. Для повторюваного аналізу використовуйте GSC Workspace; якщо потрібен файл для власної моделі, почніть з експорту GSC. Зберігайте спостережувані показники й оцінки в різних стовпцях.