Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Pytanie „ile mamy ruchu z AI” słyszę teraz na każdym spotkaniu statusowym i za każdym razem muszę zacząć od doprecyzowania, bo pod tym hasłem klienci mają na myśli trzy różne rzeczy. Jedna z nich mierzy się prosto, druga z grubsza, a trzeciej nie da się zmierzyć wcale.
Sam przez ostatni rok kilka razy przebudowywałem sposób, w jaki to raportuję. Nie dlatego, że zmieniły się narzędzia — narzędzia zmieniły się mało. Zmieniło się to, ile z tych liczb jestem gotowy obronić przed kimś, kto zapyta, jak dokładnie zostały policzone.
Poniżej opisuję konfigurację, której używam na kontach klientów w styczniu 2026 roku, razem z jej dziurami. Dziury są ważniejsze od konfiguracji, bo to one decydują, co wolno napisać w raporcie.
Zanim cokolwiek ustawię w analityce, rozdzielam trzy mechanizmy, bo każdy zostawia inny ślad.
W GA4 taki ruch nie trafia sam do żadnej sensownej szufladki. Domyślnie wpada do wejść z odesłania i miesza się z portalami, forami oraz agregatorami. Trzeba go wydzielić samemu.
Robię to własną grupą kanałów opartą na wyrażeniu regularnym na źródle sesji. Google opisało tę drogę oficjalnie w sierpniu 2025 roku i od tej pory mam wygodny argument w rozmowach, w których ktoś twierdzi, że „platforma powinna to robić za nas”. Nie robi — instrukcja mówi wprost, żeby zbudować to ręcznie.
Dwie rzeczy warto wiedzieć przed startem. Kolejność kanałów ma znaczenie, bo pierwsza pasująca reguła wygrywa, więc nowy kanał wstawiam na początek listy. Standardowa usługa dopuszcza dwie własne grupy kanałów, więc nie ma sensu zakładać osobnej grupy pod każdy pomysł raportowy.
Sam regex jest banalny, ale wymaga pielęgnacji. Asystenci zmieniają domeny i dokładają subdomeny, a każda taka zmiana cicho wypada z reguły. Mam w kalendarzu przegląd raz na kwartał: wchodzę w listę źródeł sesji posortowaną po liczbie sesji i szukam nazw, które powinny wpaść do kanału, a wpadły obok.
To ograniczenie, którego nie obejdzie żadna konfiguracja, i mówię o nim, zanim pokażę pierwszą liczbę.
Wejście zostaje przypisane do asystenta tylko wtedy, gdy przeglądarka przekaże nagłówek z adresem strony odsyłającej. Nie przekaże go w kilku bardzo częstych sytuacjach: przy korzystaniu z aplikacji na komputer albo z aplikacji mobilnej, przy otwarciu odnośnika w wewnętrznej przeglądarce aplikacji, przy skopiowaniu adresu i wklejeniu go w nowej karcie, a także gdy sama usługa świadomie tej informacji nie przekazuje.
Takie wejścia wpadają do ruchu bezpośredniego i nie da się ich odzyskać. Parametrów pomiarowych nie dołożysz do odnośnika, którego nie kontrolujesz.
Wniosek jest niewygodny, ale prosty: liczba, którą widzisz, jest dolnym oszacowaniem, nie pomiarem. Ile brakuje, nie wiem i nikt uczciwie nie powie. W raportach opisuję więc ten kanał jako „co najmniej tyle”, a dla kierunku patrzę dodatkowo na dynamikę ruchu bezpośredniego i wejść z zapytań o samą nazwę firmy.
Przy generatywnych odpowiedziach w wyszukiwarce sytuacja jest odwrotna niż w GA4: dane są zbierane, ale nie da się ich oddzielić.
Od czerwca 2025 roku kliknięcia, wyświetlenia i pozycje z AI Mode są wliczane do raportu skuteczności, w typie „Wyszukiwanie w sieci” — Google potwierdziło to w dokumentacji. Nie ma jednak filtra ani wymiaru, który pozwoliłby zobaczyć te dane osobno. Podobnie z AI Overviews: jeśli ten sam adres pojawia się i w podsumowaniu, i w niebieskich linkach, liczy się to jako jedno wyświetlenie.
Wynikają z tego trzy rzeczy. Nie da się zrobić zestawienia „ile ruchu daje nam AI Overviews”; jeśli jakieś narzędzie pokazuje taką wartość, to pochodzi ona z jego własnych sprawdzeń stron wyników, a nie z danych udostępnianych przez Google. Spadek kliknięć przy stabilnych wyświetleniach i pozycji jest najbliższym sygnałem, jaki mam — ale poszlakowym i czytelnym tylko dla wąskich grup zapytań. I wreszcie porównania rok do roku stały się mniej wiarygodne, bo zmienił się skład danych, nie tylko wynik.
Logi to jedyne miejsce, gdzie widzę drugą stronę układanki — nie ludzi, którzy przyszli z odpowiedzi, a maszyny, które przyszły po materiał do odpowiedzi.
Rozdzielam w nich dwie sytuacje. Roboty trenujące modele pobierają treść na zapas i ich obecność nie mówi nic o widoczności w odpowiedziach. Roboty pobierające stronę na potrzeby wyszukiwania w danym asystencie są ciekawsze: ich wizyty korelują z tym, że treść bierze udział w składaniu odpowiedzi. OpenAI używa do tego osobnego robota wyszukiwania od końca 2024 roku i to rozdzielenie bardzo tu pomaga.
Wyciągam z logów kilka konkretów: które adresy są pobierane najczęściej, czy roboty nie krążą po parametrach zamiast po treści, jaki dostają kod odpowiedzi. Bardzo często wychodzą tu banalne problemy — sekcja bloga zwracająca błąd dla części adresów albo limit po stronie zapory, który obcina połowę żądań.
Nazwę robota da się jednak podszyć. Jeśli liczby mają iść do raportu, weryfikuję je po adresach IP zgodnie z listami dostawców, a nie po samym nagłówku. Bez tego łatwo zaraportować jako aktywność modeli zwykły skan bezpieczeństwa.
Największą pułapką nie jest tu technika, a proporcje.
Na większości kont, które prowadzę, ruch z asystentów to nadal mały odsetek całości. Zrobienie z niego osobnej strony raportu z pięcioma wykresami buduje w głowie klienta obraz, którego dane nie potwierdzają. Robię odwrotnie: jedna tabela, wartości bezwzględne obok udziału w całości i zdanie o tym, czego w niej brakuje.
Patrzę przy tym nie na sam wolumen, a na jakość: czy te sesje wchodzą głębiej, czy realizują cele, czy trafiają na strony ofertowe. Z mojego doświadczenia to ruch mniejszy, ale lepiej przygotowany niż średnia z wyszukiwarki — i jest to mocniejszy argument za dalszą pracą nad treścią niż sam wzrost liczby wejść.
Dokładam do tego przegląd ręczny. Raz w miesiącu zadaję kilku asystentom ten sam zestaw pytań, na które klient powinien być odpowiedzią, i zapisuję, czy marka się pojawia i z jakiego źródła. To nie pomiar i nazywam to wprost przeglądem jakościowym, ale tylko to pokazuje, jak firma jest opisywana, a nie czy ktoś kliknął.
Na koniec lista rzeczy, których dziś zmierzyć nie umiem — warto ją mieć wypisaną.
Nie zmierzę wyświetlenia bez kliknięcia. Jeśli asystent streścił stronę i użytkownik dostał odpowiedź, nie wchodząc, w danych nie ma po tym śladu — a to prawdopodobnie najczęstszy scenariusz. Nie zmierzę też wpływu takiej odpowiedzi na późniejszą decyzję: ktoś czyta rekomendację w poniedziałek, a w czwartek wpisuje nazwę firmy w wyszukiwarkę i zostaje policzony jako wejście z zapytania o markę.
Nie mam też pełnej listy interfejsów, o których mowa — asystenci wbudowani w przeglądarki i systemy pojawiają się szybciej, niż da się aktualizować definicje kanałów.
Dlatego traktuję ten obszar jako obserwowany, nie rozliczany. Opisana konfiguracja daje spójny szereg czasowy i pozwala zauważyć zmianę trendu — w tym cała jej wartość. Budowanie na tych liczbach celów rozliczeniowych albo prognoz sprzedaży uważam za przedwczesne i wolę powiedzieć to wprost, niż tłumaczyć się z tego po pół roku.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |