Jak wykryć problem techniczny który zabija ruch na stronie

Wyobraź sobie że ruch na Twojej stronie spada o 30% przez trzy dni. Google Analytics pokazuje liczby. Nikt nie wie dlaczego. Developer mówi "u mnie działa". Strona się otwiera.

Problem jest — ale nikt go nie widzi, bo dane siedzą w pięciu różnych miejscach.

Dane są wszędzie. Wnioski — nigdzie.

Typowa strona firmowa generuje dane w co najmniej kilku miejscach:

• logi serwera (nginx, PHP) — błędy, timeouty, podejrzany ruch
• Sentry — wyjątki aplikacyjne
• Google Analytics — sesje, konwersje, współczynnik odrzuceń
• Google Search Console — kliknięcia z wyszukiwarki, błędy indeksowania
• Facebook Pixel — ruch z reklam

Każde z tych narzędzi mówi część prawdy. Żadne nie mówi jej w całości. Developer patrzy w logi. Marketer patrzy w Analytics. Nikt nie łączy kropek.

Logi serwera w praktyce ogląda się po fakcie — gdy klient zgłosi problem, gdy sprzedaż nagle spadnie, gdy ktoś napisze "coś nie działa". Do tego czasu błędy spokojnie się kumulują.

Co zbudowałem

Na Raspberry Pi mam skrypt który każdego dnia o ustalonej godzinie:

1. Pobiera logi z serwera — błędy, ostrzeżenia, podejrzane adresy IP
2. Pobiera dane z Google Analytics 4, Google Search Console i Facebook Pixel
3. Przekazuje wszystko do agenta AI

Agent analizuje dane razem — nie osobno. Szuka powiązań:

• Czy spadek odwiedzin pokrywa się w czasie z błędami na serwerze?
• Czy wzmożony ruch z konkretnego IP może być przyczyną spowolnienia?
• Czy błędy indeksowania w GSC tłumaczą gorsze wyniki w organicu?
• Czy konwersje z reklam spadły tego samego dnia co problemy techniczne?

Na tej podstawie generuje raport z wnioskami — nie samymi liczbami.

Co dostaję na końcu

Raport trafia do mnie mailem każdego ranka. Wygląda mniej więcej tak:

"Wczoraj odnotowano 23 błędy 500 między 14:00 a 16:00. W tym samym oknie czasowym sesje z Google Ads spadły o 41%. Możliwa przyczyna: przeciążenie serwera przy wzmożonym ruchu płatnym. Zalecenie: sprawdzić konfigurację cache i limity PHP-FPM."

Zamiast pięciu zakładek — jedna wiadomość z konkretem. Jeśli raport wykryje problem wymagający działania — zadanie trafia automatycznie do agenta który analizuje kod i szuka przyczyny.

Dlaczego to ważne dla właściciela strony

Błędy techniczne rzadko wyłączają stronę całkowicie. Częściej działają po cichu — spowalniają ją, psują ścieżki zakupowe, blokują indeksowanie. Ruch spada powoli. Nikt tego nie łączy z techniką.

Taki system nie zastępuje developera. Ale sprawia że developer dostaje gotową diagnozę zamiast pytania "coś nie działa, sprawdź".

Dla kogo to ma sens

• Masz stronę lub sklep który generuje ruch i przychód
• Nie masz kogoś kto codziennie przegląda logi i analitykę
• Chcesz wiedzieć o problemach zanim zauważą je klienci

Napisz do mnie — powiem Ci czy mogę zbudować coś podobnego dla Twojej strony.

Dla tych którzy chcą spróbować sami

Jeśli bawisz się AI i chcesz zbudować coś podobnego — mechanizm nie jest skomplikowany.

Rdzeń to agent LLM który dostaje ustrukturyzowane dane z kilku źródeł naraz. Kluczowe jest to żeby dane trafiały do niego w jednym wywołaniu — nie osobno. Tylko wtedy może szukać powiązań między nimi.

Do połączenia agenta z zewnętrznymi usługami (Analytics, GSC, serwer) używam MCP — Model Context Protocol. To otwarty standard który pozwala modelowi AI wywoływać narzędzia i pobierać dane ze świata zewnętrznego. Każde źródło danych to osobny serwer MCP. Agent sam decyduje kiedy i co pobrać.

Raspberry Pi jako host sprawdza się dobrze — tani, zawsze włączony, wystarczająco mocny do codziennych skryptów i wywołań API. Cron odpala zadanie raz dziennie. Reszta dzieje się sama.