Трафік від LLM: сліпа зона вашої аналітики. Ось чому.
Published: April 21, 2026
Ваш AI-канал зростає. Ваша аналітика не встигає.
ChatGPT, Gemini, Claude, Perplexity та інші LLM генерують більше трафіку, ніж ви думаєте. Обсяг не просто просочується, він прискорюється у темпі, що починає конкурувати з усталеними каналами. Деякі аналітики оцінюють, що AI-реферальний трафік може перевершити традиційні пошукові реферали до 2028 року. Ми вважаємо, що на деяких сайтах це вже відбувається.
Ця стаття пояснює чому, на основі практичного тестування на мобільних і десктопних пристроях, режимів налагодження браузерів, серверного логування запитів та інших технік для трьох провідних LLM-платформ: ChatGPT, Gemini та Claude.
Спочатку зрозумійте, де ваші користувачі
Перш ніж занурюватися у те, що і коли ламається, корисно зрозуміти масштаб проблеми за типом пристрою.
Мобільні пристрої, це домінуюча платформа для веб-трафіку. За даними Cloudflare Radar, який відстежує HTTP-запити у мережі, що обслуговує понад 20% усього глобального веб-трафіку, на мобільні пристрої припадає близько 50% усіх веб-запитів. Цю цифру найкраще вважати нижньою межею: мережа Cloudflare несе значний обсяг API-трафіку, B2B-сервісів та інструментарію для розробників, що значно зміщує баланс у бік десктопу. Споживчий веб-трафік працює значно вище на мобільних. У GA4-акаунтах, з якими ми працюємо щодня, на мобільні зазвичай припадає від 70% до 90% загальної кількості сеансів. Десктопний трафік реальний, але вторинний.
Мобільні, це саме те місце, де атрибуція LLM провалюється найповніше. Пристрій, який використовує більшість вашої аудиторії, це той самий пристрій, де вимірювання найбільш зламане.
Що ми тестували
Щоб зрозуміти точно, де ламається відстеження, ми провели практичні тести на мобільних і десктопних пристроях, використовуючи рідні застосунки та веб-браузери для ChatGPT, Gemini та Claude. Тестування проводилося на iPhone з останньою версією iOS, пристрої Android з останньою версією Android, Mac з останньою версією macOS і ПК Windows з останньою версією Windows.
Для кожного сценарію ми дивилися, чи присутні UTM-параметри, чи передається реферер на сайт призначення і чи зберігається ідентичність сеансу, коли користувач переходить з LLM-інтерфейсу у стандартний браузер.
Ось що ми виявили.
Результати одним поглядом
Рядок мобільного застосунку ChatGPT позначено як частково, бо хоча UTM і присутній, реалістична подорож користувача, тобто відкриття чогось у застосунку і подальша конверсія у браузері пристрою, означає, що UTM рідко переживає конверсію. За нашою оцінкою це відбувається приблизно у 10%, 20% випадків.
Усі рядки для браузера показані як відстежувані, але більшість мобільного використання LLM відбувається через рідні застосунки, а не браузер. Відстежувані сценарії у меншості. Рядки застосунків, де відстеження здебільшого не працює, це те, що насправді відчуває більшість вашої аудиторії.
Мобільні: де більшість трафіку і де ламається відстеження
Таблиця вище досить чітко розповідає історію. Для мобільних застосунків сигнал, придатний до відстеження, низький або відсутній. Але чому?
Відповідь, це веб-вʼю, і варто зрозуміти, що це насправді означає, перш ніж переходити до специфіки платформ.
Коли користувач натискає посилання в мобільному LLM-застосунку, чи то ChatGPT, Gemini чи Claude, посилання зазвичай відкривається в ізольованому внутрішньо-застосунковому браузері, який називається веб-вʼю. Це веб-вʼю не ділиться куками, даними сеансу чи ідентичністю з рідним браузером пристрою. Будь-який стан відстеження, встановлений усередині цього веб-вʼю, залишається там у пастці.
Практичний наслідок: коли користувач завершує перегляд всередині LLM-застосунку, а пізніше відкриває свій звичайний браузер пристрою, щоб продовжити дослідження чи конверсію, немає жодної безперервності. Немає спільної ідентичності. Немає передачі. Цей візит стає неатрибутованим прямим трафіком.
ChatGPT на мобільних найбільш придатний до відстеження з протестованих варіантів. Застосунок передає utm_source=chatgpt.com на вихідних посиланнях, і технічно шлях до атрибуції існує, але він залежить від послідовності подій, яка не дуже ймовірна. Щоб цей UTM зберігся аж до конверсії, користувач мав би натиснути посилання всередині ChatGPT, потрапити у внутрішньо-застосункове веб-вʼю, а потім явно натиснути “Open in Browser”, щоб передати сеанс рідному браузеру, перш ніж продовжувати. Зверніть увагу, що ця подорож зберігає сеанс лише на пристроях Android. На iOS навіть цей обхідний шлях розриває безперервність сеансу.
На практиці хтось знаходить вас у ChatGPT. Вони читають про вас, можливо, коротко переходять на ваш сайт і рухаються далі. Пізніше, можливо, через годину, можливо, через два дні, вони шукають вас у Google або просто вводять ваш URL безпосередньо, і саме тоді вони можуть почати процес конверсії. У цьому сеансі немає сліду взаємодії з ChatGPT, яка запустила все це. UTM зник. Реферер зник. GA4 реєструє це як прямий або органічний пошук, і ChatGPT не отримує жодного кредиту. І так, це вірно, навіть якщо у вас увімкнені функції відстеження, як-от Google Signals у вашій властивості GA4.
Gemini і Claude на мобільних не передають ані UTM-параметрів, ані реферера у жодному протестованому сценарії. Сеанси з цих платформ потрапляють як чистий прямий трафік. Немає сигналу, який повʼязував би їх з LLM, що їх згенерував.
Один нюанс, який варто відзначити: якщо користувач знаходить сайт і конвертується всередині веб-вʼю, у цьому ізольованому контексті існує внутрішня безперервність сеансу. Веб-вʼю зберігає власні куки між сеансами, тож подорож, завершена повністю всередині застосунку, теоретично піддається вимірюванню. Стандартні обмеження відстеження куками все ще діють, а те, як часто користувачі завершують повний цикл конверсії всередині веб-вʼю застосунку, саме по собі є відкритим питанням, яке варто дослідити.
Десктоп: краще, але все ще непослідовно
Десктоп пропонує сприятливіші умови для відстеження, ніж мобільні, але картина все ще фрагментована залежно від платформи та інтерфейсу.
На відміну від мобільних, десктопні LLM-застосунки не затримують посилання в ізольованих веб-вʼю. Вони передають вихідні посилання безпосередньо у браузер за замовчуванням користувача. Тож проблема ізоляції веб-вʼю не застосовується на десктопі. Що все ж застосовується, так це чи платформа взагалі передає UTM або реферер, і з цим результати неоднозначні.
ChatGPT на десктопі (рідний застосунок) передає utm_source=chatgpt.com на вихідних посиланнях, це найнадійніший десктопний сценарій з усіх протестованих платформ. ChatGPT у браузері передає реферер, але без UTM.
Gemini не має десктопного застосунку на Mac чи Windows. Все десктопне використання Gemini проходить через браузер. Gemini у браузері передає реферер, але без UTM, та сама історія, що й з браузерним ChatGPT.
Claude найслабший виконавець у всіх десктопних сценаріях. Рідний десктопний застосунок не передає ані UTM, ані реферера. Claude у браузері теж не передає жодного з них. Кожен сеанс від Claude на десктопі потрапляє як повністю неатрибутований прямий трафік незалежно від того, як користувач туди дістався.
Ускладнення: навіть добра атрибуція не завжди доходить до конверсії
Припустімо на мить, що відстеження працює. UTM заповнено, реферер присутній, сеанс піддається атрибуції. Ви можете подумати, що все гаразд.
Це не так.
Шлях від взаємодії з LLM до завершеної конверсії рідко обмежується одним сеансом. Користувач знаходить щось через ChatGPT на своєму телефоні вдень. Натискає посилання, потрапляє на сторінку, кілька хвилин переглядає. Іде без конверсії. Через два дні повертається на свій ноутбук, щоб довести справу до кінця. На цьому етапі оригінальний UTM міг вже закінчитися, пристрій може бути іншим, кук може не бути.
Закінчення терміну дії кук, кросдевайсні подорожі та багатосеансові шляхи, кожне з них незалежно ламає атрибуцію. Разом вони гарантують, що навіть та частка LLM-реферальних сеансів, які коректно позначаються на першому дотику, рідко отримуватиме кредит за подальшу конверсію.
Це не проблема, унікальна для LLM-трафіку. Але тут вона бʼє сильніше, бо LLM-орієнтоване відкриття зазвичай відбувається раніше у шляху розгляду, люди досліджують і вивчають, а не готові купувати. Проміжок між цим першим AI-впливовим візитом і подальшою конверсією довший, ніж типове вікно від платного кліку до конверсії, що погіршує кросдевайсну проблему.
Що це означає для ваших даних
Дамо цьому приблизні цифри. Мета не хибна точність: мета, це розумний діапазон, який допоможе вам зрозуміти масштаб того, що ви, ймовірно, пропускаєте.
Почніть з розподілу пристроїв. Cloudflare Radar оцінює глобальний мобільний веб-трафік приблизно у 50% від усіх HTTP-запитів, і ця цифра занижена для споживчих аудиторій, бо мережа Cloudflare несе важку суміш API та трафіку розробників. У GA4-акаунтах, з якими ми працюємо, мобільний трафік зазвичай становить від 70% до 90% сеансів. Ми використовуємо тут 70%, щоб бути консервативними.
Далі питання про те, як люди насправді використовують LLM на своїх телефонах. Не всі користуються рідним застосунком. Деякі отримують доступ до ChatGPT, Gemini чи Claude через мобільний браузер, а використання браузера значно краще піддається відстеженню. Два припущення окреслюють діапазон.
Базові припущення, що використовуються в обох випадках:
- Розподіл мобільний/десктоп: 70% мобільні, 30% десктоп
- Рівень виживання сигналу застосунку: 20% кліків у мобільному застосунку успішно передають придатний сигнал (наприклад, користувач Android натискає “Open in Browser” або конверсія відбувається всередині веб-вʼю)
- Вигорання конверсійного шляху: штраф 25% за втрату сигналу через кросдевайсні переходи та закінчення терміну дії кук
- Фактор Google AIO: частка AI-орієнтованого відкриття тепер відбувається через Google AI Overviews та AI Mode, які GA4 реєструє як стандартний органічний пошук без можливості їх відокремити
Діапазон
Наведені вище припущення це оцінки, не соромтеся підставляти числа, які краще відображають вашу аудиторію чи ваші припущення. Використайте інший розподіл мобільного трафіку, інше співвідношення застосунок до браузера, інший рівень вигорання. Модель не призначена бути точною. Вона призначена показати, що які б розумні числа ви не обрали, висновок той самий: відбувається суттєве недозвітування, і розрив достатньо великий, щоб мати значення.
З нашими припущеннями діапазон охоплює від приблизно 2,5x на оптимістичному кінці до 5x на більш песимістичному, і потенційно вищий, щойно врахувати LLM-впливові органічні сеанси Google, які неможливо відокремити за допомогою стандартної аналітики.
Якщо ваша панель показує, що 1,5% ваших сеансів походять від LLM, то, швидше за все, від 4% до 8% цих сеансів насправді прийшли від LLM, і ця цифра швидко зростає. Це цілий канал, що ховається у ваших звітах Прямий та Органічний.
Чи можна це виправити?
Частково. Повного рішення немає, але є суттєві покращення, доступні командам, готовим інвестувати у досконалішу аналітику та відстеження.
Серверне відстеження та логування запитів можуть фіксувати сигнали, які клієнтський JavaScript повністю пропускає. Інструменти фінгерпринтингу пристроїв можуть підтримувати імовірнісну ідентичність між контекстами веб-вʼю та браузера на одному пристрої, частково перекриваючи розрив ізоляції, який стандартне кукі-відстеження не може подолати. Жоден з підходів не дасть повного вимірювання, і жоден не розвʼязує кросдевайсну проблему без стану авторизованого користувача, щоб закріпити обидва сеанси разом.
Чесна відповідь: ви ніколи не отримаєте повного вимірювання. Архітектура мобільних операційних систем, політика реферерів LLM-платформ і природа багатосеансових кросдевайсних подорожей, усе це працює проти цього. Але це не найважливіше, що треба розуміти про цей канал.
Мета вимірювання, це не ідеальний підрахунок кожної конверсії: це спрямоване розуміння, достатньо хороше, щоб приймати рішення. Вам не потрібно атрибутувати кожну LLM-орієнтовану конверсію, щоб знати, що цей канал зростає, що ваша частка у ньому, це те, на що ви можете вплинути, і що відносні зміни, які ви робите у своїй стратегії AI-видимості, зʼявляться у ваших числах. Якщо ваш LLM-реферальний трафік подвоюється після реструктуризації контенту для кращого AI-цитування, цей рух значущий незалежно від того, чи можете ви привʼязати кожен продаж до конкретного чат-сеансу.
Ця стаття не є аргументом на користь відмови від вимірювання. Це аргумент проти того, щоб недосконале вимірювання ставало приводом для бездіяльності. Команди, які сприймають AI-видимість як серйозний канал зростання прямо зараз, не коли атрибуція стане чистішою, не коли GA4 наздожене, а саме зараз, це ті, хто вибудовує перевагу, яку буде важко наздогнати.
Методологія
Тестування проводилося на iPhone з останньою версією iOS, пристрої Android з останньою версією Android, Mac з останньою версією macOS і ПК Windows з останньою версією Windows. Linux не тестувався безпосередньо, але очікується, що він слідуватиме подібним патернам. Кожну LLM-платформу, ChatGPT, Gemini та Claude, тестували через її рідний застосунок (де доступний) і через браузер пристрою. Для кожного сценарію ми дивилися, чи заповнюються UTM-параметри, чи передається реферер на сайт призначення і чи зберігається ідентичність сеансу, коли навігація переходить з LLM-інтерфейсу у браузер пристрою за замовчуванням. Серверне логування використовувалося для доповнення клієнтських спостережень.
Це дослідження відображає поведінку платформ на момент тестування (12 квітня 2026 року). LLM-платформи часто оновлюють свої застосунки та вебінтерфейси, тож поведінка відстеження може змінюватися.
Підсумок
AI-канали не є майбутнім питанням. Вони активні зараз, зростають і формують рішення у великих масштабах. Проблема в тому, що інфраструктура, яку більшість команд використовує для вимірювання цих каналів, була побудована для світу, де клік давав надійний реферер і куку, що жила достатньо довго, щоб побачити конверсію.
LLM-трафік працює не так.
Ставтеся до показників свого AI-каналу як до значного недооцінення. Сеанси, які ви бачите, це ті, що випадково пережили кожен шар втрат відстеження. Ті, що не пережили, значно численніші, і серед них люди, які знайшли вас, на яких вплинуло те, що AI сказав про вас, і які конвертувалися, не залишивши сліду, за яким ви могли б простежити.
Поширені запитання
Чому мій GA4 майже не показує трафіку з Claude чи Gemini?
Тому що обидві платформи не передають ані UTM-параметрів, ані реферера у переважній більшості протестованих нами сценаріїв. На мобільних посилання відкриваються в ізольованих внутрішньо-застосункових веб-вʼю, які ніколи не зʼєднуються зі стандартним середовищем аналітики. На десктопі Claude не передає нічого ні в застосунку, ні в браузері. Gemini передає реферер у браузері, але без UTM. Без жодного з цих сигналів більшість такого трафіку потрапляє в GA4 як прямий або взагалі не враховується.
ChatGPT показує деякий трафік у моїх звітах. Чи означає це, що його відстежують точно?
Не зовсім. ChatGPT, найбільш придатний до відстеження з трьох протестованих нами платформ. Він додає utm_source=chatgpt.com у кількох сценаріях, і його десктопний застосунок робить це надійно. Але на мобільних шлях до атрибуції вузький і залежний від платформи. UTM може зберегтися, якщо користувач натисне “Open in Browser” у веб-вʼю, але це працює лише на Android. На iOS ця передача взагалі не зберігає сеанс. Ідентичність втрачається, коли користувач залишає веб-вʼю незалежно від того, як саме він виходить. Тож навіть у найкращому випадку потрібен користувач на Android, що використовує застосунок і явно натискає “Open in Browser” перед подальшою навігацією. Це невеликий зріз вашого фактичного мобільного трафіку ChatGPT. Цифри, які ви бачите у GA4, реальні, але вони відображають лише частку того, що насправді генерує ChatGPT.
Чи ця проблема впливає лише на мобільних користувачів?
На мобільних вона найсерйозніша, але й десктоп не чистий. Claude на десктопі не передає нічого у всіх протестованих сценаріях, ні у застосунку, ні у браузері. Gemini на десктопі передає реферер, але без UTM, що може класифікуватися правильно або ні залежно від налаштувань вашого GA4. Десктопний застосунок ChatGPT, це єдиний надійний виняток. Тож навіть якби ваша аудиторія була повністю десктопною, ви все одно пропускали б значну частку LLM-впливового трафіку.
Що таке веб-вʼю і чому воно створює проблеми відстеження?
Веб-вʼю, це внутрішньо-застосунковий браузер, який відкривається, коли ви натискаєте посилання всередині мобільного застосунку. Виглядає як браузер, але ізольований від справжнього браузера вашого пристрою. Він не ділиться куками, даними сеансу чи ідентичністю з Safari або Chrome. Тож будь-яке відстеження, що спрацьовує у веб-вʼю, залишається там у пастці. Коли користувач пізніше відкриває свій справжній браузер, щоб продовжити подорож, він виглядає як абсолютно новий відвідувач без жодної історії.
Якщо фінальна конверсія відбувається у веб-вʼю застосунку, чи відстежується вона?
Може відстежуватися, але не чисто. Конверсія має відбутися всередині веб-вʼю, щоб ланцюг атрибуції зберігся. Користувачеві не обовʼязково проводити всю свою подорож там, але цей фінальний крок, так. Заковика в тому, що iOS складає більшу частину мобільного трафіку для більшості аудиторій, а на iOS веб-вʼю підпорядковане обмеженням кук WebKit, включно з Intelligent Tracking Prevention. Ці обмеження можуть обмежувати або розривати безперервність, на яку ви покладаєтеся. Тож хоч цей сценарій теоретично піддається відстеженню, на практиці це найменш зламаний доступний варіант, а не надійний шлях.
Чи можу я виправити це серверним відстеженням?
Серверне відстеження допомагає, але не розвʼязує всього. Воно може фіксувати сигнали, які клієнтський JavaScript пропускає, включно з даними реферера, що ніколи не потрапляють у GA4. Інструменти фінгерпринтингу пристроїв також можуть допомогти, підтримуючи імовірнісну ідентичність між контекстами веб-вʼю та браузера на одному пристрої. Але жоден з підходів не розвʼязує кросдевайсну проблему, і жоден не дає повного вимірювання. Ви підійдете значно ближче до істини, але не дійдете до неї повністю.
Наскільки насправді недозвітується LLM-орієнтований конверсійний трафік?
На основі нашого аналізу, десь у діапазоні від 2,5x до 5x, залежно від вашої аудиторії та того, як вони використовують LLM-платформи. Консервативна оцінка (Випадок A) припускає, що половина мобільних користувачів отримує доступ до LLM через браузер, де відстеження здебільшого працює, що дає приблизно 2,5x недозвітування з урахуванням втрат на конверсійному шляху. Більш реалістична оцінка (Випадок B) припускає, що 80% мобільних користувачів користуються рідним застосунком, де відстеження по суті не працює, що дає від 4 до 5x недозвітування. Обидві оцінки, ймовірно, все ще консервативні, тому що зростаюча частка того, що GA4 класифікує як органічний пошук Google, насправді є LLM-впливовим трафіком, що приходить через AI Overviews та AI Mode, трафіком, який неможливо відокремити за допомогою стандартної аналітики.
Чи варто інвестувати більше в AI-видимість, якщо я не можу виміряти результати?
Так, можливо, навіть більше, а не менше. Той факт, що ви не можете виміряти повний вплив цього каналу, не означає, що впливу немає. Це означає, що ваші поточні інструменти недостатньо кваліфіковані, щоб його побачити. Сеанси, які все ж потрапляють у ваші звіти, вже демонструють значущу залученість. Ті, що не потрапляють, є на порядки численнішими. Ставитися до цього каналу як до неважливого, бо цифри здаються малими, це саме той неправильний висновок, якого треба уникати.