Agent AI do monitoringu konkurencji ma sens tylko wtedy, gdy raportuje zmiany, a nie stan. Zestawienie „konkurent X ma 14 pozycji w cenniku i 38 wpisów na blogu” nikogo nie interesuje już przy drugim wydaniu. Wartość pojawia się dopiero wtedy, gdy agent mówi: „od zeszłego tygodnia X podniósł cenę planu Pro o 15% i otworzył trzy rekrutacje na stanowiska sprzedażowe w Niemczech”. Cała trudność techniczna leży więc nie w samym pobieraniu stron, tylko w tym, żeby odróżnić zmianę istotną od szumu.
Poniżej opisujemy, jak taki agent wygląda w praktyce: co warto śledzić, jak często, jak wykrywać różnice i jak zbudować raport, który ktoś w zespole faktycznie otworzy w poniedziałek rano.
Co monitorować, a co pominąć
Pierwszy błąd przy projektowaniu agenta to chęć śledzenia wszystkiego. Pełny crawl dziesięciu serwisów co tydzień generuje setki drobnych różnic: zmienione daty w stopce, rotujące banery, nowe identyfikatory sesji w adresach. Model językowy dostaje wtedy tonę materiału i zaczyna „znajdować” trendy tam, gdzie ich nie ma.
Lepiej zacząć od krótkiej listy pytań biznesowych i do każdego dobrać konkretne adresy. Przykładowo:
- czy konkurent zmienia ceny lub strukturę planów (strona cennika, porównanie pakietów),
- czy wchodzi w nowy segment (strony produktowe, landing pages kampanii),
- o czym pisze i na jakie frazy celuje (blog, sekcja poradników),
- gdzie inwestuje ludzi (oferty pracy).
Pomijamy natomiast regulaminy (chyba że branża jest regulowana), strony „o nas”, galerie i podstrony techniczne. One zmieniają się rzadko, a jeśli już, to zwykle bez znaczenia dla decyzji marketingowych.
Źródła: strony, cenniki, blogi, oferty pracy
Każde źródło wymaga trochę innego podejścia. Cennik to najcenniejszy i najbardziej kapryśny element: często renderowany przez JavaScript, z przełącznikiem miesięcznie/rocznie i cenami zależnymi od waluty. Tu warto użyć przeglądarki bezgłowej i wyciągać same liczby oraz nazwy planów do ustrukturyzowanego JSON, zamiast porównywać cały HTML.
Blog najłatwiej śledzić przez RSS albo mapę witryny (sitemap.xml). Nowe adresy i daty lastmod mówią więcej niż pobieranie każdej strony. Dopiero dla nowych wpisów agent ściąga treść i streszcza ją w dwóch zdaniach, z naciskiem na frazę główną i kąt tematu.
Oferty pracy są niedocenianym sygnałem. Pięć nowych ogłoszeń dla specjalistów od SEO międzynarodowego mówi o planach konkurenta więcej niż jego komunikaty prasowe. Wiele firm publikuje oferty w systemach ATS, które mają publiczne endpointy JSON, co oszczędza parsowania HTML. Podobną logikę opisaliśmy w materiale o researchu konkurencji z pomocą agenta AI, gdzie oferty pracy okazały się najszybszym zwiastunem nowej linii produktowej.
Przy każdym źródle obowiązuje ta sama zasada: szanujemy plik robots.txt i nie obciążamy cudzego serwera. Google dokładnie opisuje, jak działają reguły w dokumentacji robots.txt w Search Central, a te same zasady warto przyjąć dla własnego bota.
Harmonogram i częstotliwość sprawdzania
Częstotliwość powinna wynikać z tempa, w jakim dane źródło się zmienia, a nie z tego, ile da się technicznie zrobić. Rozsądny punkt wyjścia wygląda tak:
| Źródło | Częstotliwość | Uzasadnienie |
|---|---|---|
| Cennik | codziennie | zmiana ceny bywa krótką promocją, łatwo ją przegapić |
| Blog (RSS, sitemap) | codziennie | tanie zapytanie, jeden plik |
| Strony produktowe | raz w tygodniu | zmiany są rzadkie i większe |
| Oferty pracy | 2–3 razy w tygodniu | ogłoszenia żyją kilka tygodni |
Ważne rozróżnienie: częstotliwość sprawdzania to nie częstotliwość raportowania. Agent może zbierać dane codziennie, ale raport wysyłać raz w tygodniu, z agregacją. Wyjątkiem są zdarzenia pilne, jak obniżka ceny o więcej niż 20%, które mogą iść od razu osobnym alertem. Logika progów jest tu bardzo podobna do tej, którą stosujemy przy alertach o awarii SEO i progach monitoringu.
Wykrywanie zmian zamiast pobierania całości
Agent, który za każdym razem wysyła do modelu cały HTML strony, jest drogi i niedokładny. Dużo lepiej działa trzystopniowy schemat:
- Ekstrakcja: z pobranej strony wyciągamy tylko istotny fragment (selektor CSS głównej treści, tabela cen, lista ofert) i zapisujemy go jako czysty tekst lub JSON.
- Porównanie: liczymy hash nowej wersji i porównujemy z poprzednią. Jeśli hash jest identyczny, kończymy bez udziału modelu. Jeśli się różni, generujemy diff, na przykład biblioteką difflib w Pythonie.
- Interpretacja: dopiero sam diff (kilka linii, nie cała strona) trafia do modelu z pytaniem, co ta zmiana oznacza biznesowo.
Taki układ redukuje liczbę wywołań modelu o rząd wielkości, bo w typowym tygodniu większość monitorowanych stron po prostu się nie zmienia. Daje też ślad audytowy: zawsze można wrócić do zapisanej wersji i sprawdzić, czy agent dobrze zinterpretował różnicę.
Filtrowanie szumu i progi istotności
Nawet po ekstrakcji zostaje szum: zmieniony rok w stopce, nowa kolejność opinii klientów, poprawiona literówka. Filtrujemy go na dwóch poziomach.
Pierwszy poziom jest regułowy i nie kosztuje nic. Przed porównaniem usuwamy daty, liczniki, tokeny w adresach i elementy, o których wiemy, że rotują. Ignorujemy też zmiany poniżej progu, na przykład diff krótszy niż 30 znaków na stronie produktowej.
Drugi poziom to ocena modelu. Każdej zmianie, która przeszła filtr, agent nadaje ocenę istotności w skali 1–5 według prostych kryteriów: czy dotyczy ceny, oferty, grupy docelowej lub pozycjonowania. Do raportu trafiają tylko oceny 3 i wyższe, reszta ląduje w logu. Warto pamiętać, że model chętnie dopisuje interpretacje „na wyrost”, dlatego w prompcie wymagamy cytatu z diffu jako uzasadnienia każdej oceny. O tym, gdzie generowanie przez AI zaczyna szkodzić zamiast pomagać, pisaliśmy w tekście kiedy nie warto pisać z AI.
Format raportu, który ktoś przeczyta
Raport monitoringu przegrywa zwykle nie przez złe dane, tylko przez długość. Sprawdza się stały, krótki szablon:
- Trzy najważniejsze zmiany tygodnia, każda w jednym zdaniu z linkiem do źródła i datą wykrycia.
- Tabela zmian cen: konkurent, plan, stara cena, nowa cena, różnica procentowa.
- Nowe treści: tytuł, przypuszczalna fraza główna, jedno zdanie o kącie tematu.
- Rekrutacje: liczba nowych ofert per konkurent z podziałem na działy.
- „Bez zmian”: jedna linijka z listą konkurentów, u których nic się nie wydarzyło.
Ostatni punkt jest ważniejszy, niż wygląda. Informacja „u czterech z dziesięciu konkurentów nic się nie zmieniło” buduje zaufanie do agenta i pokazuje, że monitoring działa, a nie milczy z powodu awarii. Raport najlepiej wysyłać tam, gdzie zespół i tak pracuje (Slack, e-mail, kanał w Teams), a nie do osobnego panelu, do którego nikt nie zagląda. W praktyce podobny układ opisaliśmy w case study monitoringu cen konkurencji.
Koszty i limity przy dziesięciu konkurentach
Przyjmijmy realistyczny scenariusz: dziesięciu konkurentów, po około 8 monitorowanych adresów na każdego, czyli 80 stron. Codzienne sprawdzanie cenników i blogów plus cotygodniowe strony produktowe daje mniej więcej 1500–2000 pobrań miesięcznie. Sama infrastruktura (serwer z przeglądarką bezgłową, harmonogram cron lub prosta kolejka) to koszt rzędu kilkudziesięciu złotych miesięcznie.
Koszt modelu zależy przede wszystkim od tego, czy stosujemy porównanie przed interpretacją. Przy wysyłaniu tylko diffów do modelu trafia zwykle kilkadziesiąt krótkich zapytań tygodniowo plus jedno dłuższe, składające raport. Bez tego kroku zużycie tokenów rośnie kilkudziesięciokrotnie, a jakość wniosków spada.
Osobną kwestią są limity po stronie monitorowanych serwisów. Część z nich stosuje ochronę przed botami, która zwraca stronę z weryfikacją zamiast treści. Agent musi to rozpoznawać i oznaczać jako „brak danych”, a nie jako zmianę. Inaczej pierwszego dnia po wdrożeniu ochrony raport ogłosi, że konkurent usunął cały cennik.
FAQ
Czy do monitoringu konkurencji wystarczy gotowe narzędzie zamiast własnego agenta?
Do śledzenia pozycji i widoczności w wyszukiwarce tak, narzędzia SEO robią to dobrze. Własny agent opłaca się, gdy chcesz łączyć sygnały spoza SEO, jak cenniki, oferty pracy i zmiany na stronach produktowych, w jednym raporcie z interpretacją.
Jak często agent powinien wysyłać raport?
Najczęściej raz w tygodniu, z danymi zbieranymi codziennie. Natychmiastowe alerty warto zostawić dla zdarzeń przekraczających próg, na przykład dużej zmiany ceny.
Czy monitorowanie stron konkurencji jest legalne?
Pobieranie publicznie dostępnych stron w rozsądnym tempie i z poszanowaniem robots.txt jest standardową praktyką. Ostrożność trzeba zachować przy danych osobowych i przy obchodzeniu zabezpieczeń, a regulamin konkretnego serwisu może nakładać dodatkowe ograniczenia.
Dlaczego nie wysyłać całej strony do modelu językowego?
Bo to drogie i mniej dokładne. Model dostaje dużo nieistotnego tekstu i łatwiej mu o nadinterpretację. Porównanie wersji i przekazanie samego diffu daje tańsze i bardziej wiarygodne wnioski.
Co zrobić, gdy strona konkurenta blokuje bota?
Oznaczyć wynik jako brak danych i nie traktować go jako zmiany. Jeśli blokada się utrzymuje, warto ograniczyć częstotliwość dla tego źródła albo przejść na kanały pośrednie, jak RSS czy mapa witryny.