Чотири хвилини на створення сервісного облікового запису. Шістнадцять місяців історії Search Console, дозаповнені при першій синхронізації. Дві секунди для домену, який уже верифіковано та має надані права. І два місяці — цифра, яка спричиняє більше звернень у підтримку, ніж інші три разом узяті, оскільки це стандартне вікно зберігання даних GA4 за замовчуванням, і майже ніхто не знає, що це варто перевірити перед підключенням.
Саме налаштування коротке: одні облікові дані в Налаштування → Облікові записи Google, дві кнопки підключення в Управлінні доменами, і після цього ви здебільшого забуваєте, що ця сторінка взагалі існує. Але цифра «два місяці» заслуговує на повне пояснення, оскільки саме вона пояснює, чому одні домени показують велику, корисну історію Analytics з першого дня, а інші показують майже нічого протягом тижнів — і це не помилка платформи, коли таке трапляється.
Одні облікові дані, надані один раз
Ви завантажуєте ключ сервісного облікового запису Google — файл JSON, а не персональний логін. Ідентичність робота, а не токен OAuth людини, який спливає або ламається, коли хтось змінює пароль. Google Cloud видає його один раз, і він продовжує працювати, поки ви його не видалите — саме тому платформа синхронізується о 3 ночі без жодного входу в систему.
Створення такого ключа займає близько тих же чотирьох хвилин, якщо ви робите це вперше: новий або наявний проєкт, IAM і адміністрування → Сервісні облікові записи → Створити, завантажити ключ. Дозвіл важливіший, ніж здається з випадаючого списку — надайте роль Переглядач для властивості Search Console та властивості Analytics, не вище. Я бачив, як команди надавали роль Редактора, бо це верхній варіант, а через півроку ніхто не міг пояснити, чому обліковий запис робота має права на запис у налаштуваннях GA4. Лише для читання — правильний вибір; платформа ніколи не змінює ваші налаштування.
Один ключ охоплює кожен домен у межах цього проєкту Google Cloud. Якщо ви агенція, що керує десятком клієнтських сайтів, це аргумент на користь окремого сервісного облікового запису на кожного клієнта, а не одного для всіх — завершення роботи з клієнтом стає простим видаленням ключа, а не аудитом того, які домени тихенько ділили облікові дані з кимось, хто щойно пішов.
Search Console: швидко, коли швидко, дратівливо, коли ні
- Відкрийте Підключити для домену. Search Console і Analytics отримують кожен свою картку, а Analytics має ярлик «так само, як Search Console», оскільки один ключ зазвичай охоплює обидва.
- Уже верифіковано, а ваш сервісний обліковий запис має доступ? Миттєво — перевірка прав, готово приблизно за дві секунди.
- Ще не верифіковано: автоматична верифікація через DNS, якщо ви надасте ключ API вашого реєстратора (Cloudflare, Route 53 та кілька інших), або ручний TXT-запис, який ви додаєте самостійно.
Саме ручний шлях змушує людей нервувати. Поширення дійсно варіюється — дев'яносто секунд один раз, чотири години інший, залежно від TTL і кешування резолвера. Платформа опитує сама, тож додайте запис і йдіть у своїх справах. Якщо минув день без верифікації, це рідко проблема поширення — швидше за все, помилка у значенні або запис потрапив не в ту зону (кореневий домен замість піддомену, або навпаки). Виконайте `dig TXT` для того, що дійсно опубліковано, перш ніж звинувачувати Google.
Шлях із ключем API пропускає все це, записуючи запис за вас, але це означає надання стороннього доступу на запис до вашого DNS — і якщо цей DNS обслуговує продакшн-трафік, я не думаю, що вагання тут нерозумні. Ручний шлях коштує кількох хвилин на початку і купує вам можливість більше ніколи про це не думати.
Analytics і розрив зі зберіганням даних, про який ніхто не попереджає
Analytics підключається шляхом виявлення, а не верифікації — платформа шукає наявну властивість GA4 на домені й підключається, якщо ваш сервісний обліковий запис має доступ, оскільки права GA4 уже контролюються на боці Google. Вона може створити властивість, якщо жодної не існує, але дозволяйте це лише для дійсно нових сайтів. Якщо ви мігрували з Universal Analytics або маєте властивість із роками історії, підключайтеся саме до неї явно. Свіжа властивість із трьома днями даних — набагато гірша відправна точка, ніж дев'ятирічна із закладеними сезонними патернами, і цикл оптимізації спирається на цю історію більше, ніж передбачає процес підключення.
Ось розрив, на якому люди спотикаються: Search Console дозаповнює до шістнадцяти місяців даних запитів при першій синхронізації, оскільки Google зберігає стільки історії на своєму боці незалежно від того, коли ви підключилися. У GA4 немає еквівалентної гарантії — його дозаповнення обмежене тим, яке налаштування зберігання даних встановлено для властивості, а це налаштування за замовчуванням становить два місяці, якщо хтось у вашій організації його не змінив. Тож домен може показати шістнадцять місяців показів і кліків одразу після підключення, і два місяці сеансів — того самого дня, з того самого процесу налаштування. Це не збій синхронізації. Це стандартне налаштування зберігання Google, яке робить саме те, для чого налаштоване, і виправлення — якщо ви хочете отримувати більше двох місяців надалі — полягає у зміні вікна зберігання безпосередньо в налаштуваннях властивості GA4, а не на боці цієї платформи. Варто перевірити це до підключення, а не після того, як розгубитеся через невідповідність.
Спільні властивості і що відбувається далі
Ще одна тонкість Analytics: якщо ваша організація використовує одну властивість GA4, яка збирає дані для п'яти сайтів — часто трапляється, коли хтось налаштував відстеження роками тому і ніхто його не розділив, — підключення все одно працює нормально, але кожен запит за лаштунками фільтрується за іменем хоста. Не прапорець, не те, що можна випадково вимкнути. Саме тому панель завжди показує цифри саме цього домену і ніколи — сукупний підсумок усієї властивості.
Щойно обидва підключення налагоджено, синхронізація виконується щодня за розкладом, який ви контролюєте (див. розділ про розклади), і аналітика магазину автоматично поєднується з усім, що побудовано на платформі. Рядок домену показує статус «очікує», «частково» або «активно» — «частково» означає, що одне з двох підключень активне, а інше ні, і це сигнал перевірити, яка картка червона, замість того щоб довіряти сукупному статусу.
Де саме все ламається
Майже кожне звернення, яке я бачив, потрапляє в одну з трьох категорій, жодна з яких не є екзотичною. Перша: ключ сервісного облікового запису дійсний, але прив'язаний не до того проєкту Google Cloud, тож перевірка прав повертається порожньою, хоча сам ключ завантажується без проблем. Друга: ніхто насправді не додав електронну адресу сервісного облікового запису — щось на кшталт [email protected] — як переглядач у Search Console або в налаштуваннях доступу самого GA4; завантаження ключа на платформу не надає йому жодних прав з боку Google. Третій сценарій, найпідступніший: домен повторно підключають під новим сервісним обліковим записом після видалення старого, але розклад ще тиждень тихенько дає збій на застарілих облікових даних, поки хтось не помітить, що цифри перестали оновлюватися.
Жодне з цього не є помилками платформи — це звичайна ціна того, що робот потребує дозволів на двох окремих продуктах Google, і власна модель Google не робить це очевидним. Заплануйте п'ятнадцять хвилин на перший домен, а не дві хвилини, які обіцяє процес. Кожен наступний домен буде швидким, оскільки і облікові дані, і накопичений досвід переносяться далі.
