Ta strona omawia typowe problemy napotykane podczas integracji TRACIO oraz ich rozwiązania. TRACIO to zarządzana usługa chmurowa, więc większość problemów występuje po stronie klienta (zablokowany skrypt, pliki cookie, funkcje prywatności przeglądarki), a nie po stronie infrastruktury.
Skrypt agenta lub żądanie identyfikacji nie ładuje się, albo konsola przeglądarki pokazuje błąd CORS wobec edge.tracio.ai.
1. Origin nie znajduje się na liście dozwolonych dla Twojego klucza
Każdy klucz publiczny można ograniczyć do zestawu dozwolonych origins. Jeśli origin Twojej witryny nie jest na liście dozwolonych, edge odrzuca żądanie (403). Dodaj swój origin w sekcji Request Filtering w panelu lub upewnij się, że używany klucz nie jest przypisany do origin innej witryny.
2. Blokada reklam lub CSP blokujące żądanie
Rozszerzenia prywatności (uBlock Origin, AdBlock) lub restrykcyjna Content-Security-Policy mogą blokować skrypt agenta lub jego żądanie sieciowe. SDK zgłasza to jako błąd blocked (zobacz Obsługa błędów). Aby utrudnić blokowanie, serwuj agenta z subdomeny first-party, korzystając z opcji scriptUrl / endpoint.
3. Nieprawidłowy endpoint / region
Upewnij się, że kierujesz żądania do właściwego endpointu. Gdy ustawisz region, SDK komunikuje się z edge.us.tracio.ai lub edge.eu.tracio.ai; bez ustawienia używa edge.tracio.ai.
Wskaźniki pewności dla powracających odwiedzających konsekwentnie utrzymują się poniżej 0.90.
1. Plik cookie nie jest utrwalany
Plik cookie _vid_t może nie być ustawiany poprawnie. Sprawdź w przeglądarce:
// In browser consoledocument.cookie.split(";").filter((c) => c.includes("_vid_t"))Jeśli plik cookie brakuje, zobacz sekcję Plik cookie nie jest utrwalany poniżej.
2. Nowy workspace
Zupełnie nowy workspace ma pustą bazę danych odwiedzających, więc wszyscy odwiedzający pojawiają się jako „nowi” z pewnością około 0.90. Po 24–48 godzinach powracający odwiedzający są rozpoznawani z wyższą pewnością.
3. Tryb incognito / przeglądanie prywatne
W trybie incognito pliki cookie i localStorage są czyszczone po zakończeniu sesji. TRACIO przełącza się wtedy na dopasowywanie wyłącznie na podstawie sygnałów, które ma niższą pewność (zazwyczaj 0.85–0.95).
4. Przeglądarki z agresywnym anty-fingerprintingiem
Brave, Firefox (tryb strict) oraz Safari (ITP) modyfikują lub blokują niektóre sygnały przeglądarki. Zmniejsza to zestaw sygnałów dostępnych do dopasowania. TRACIO wykrywa te przeglądarki i odpowiednio dostosowuje pewność.
Przeanalizuj identyfikację w panelu (Visitors / Events) lub zareaguj na dostarczenie
webhooka, który przenosi identification.confidence,
identification.incognito oraz werdykt bot dla każdego zdarzenia.
Prawdziwi odwiedzający (ludzie) są oznaczani jako boty.
1. Rozszerzenia przeglądarki modyfikujące właściwości navigatora
Niektóre rozszerzenia prywatności modyfikują navigator.userAgent, navigator.platform lub inne właściwości. Może to uruchomić detektor manipulacji, ale samo w sobie nie powinno uruchamiać wykrywania botów.
Sprawdź pole bot.type, aby zobaczyć, która klasa wykrycia się uruchomiła (pełny słownik znajdziesz w sekcji Typy botów):
| bot.type | Częsta przyczyna fałszywego wykrycia | Rozwiązanie |
|---|---|---|
automation | Narzędzie testowe zostawiło przeglądarkę w trybie automatyzacji | Wyłącz tryb automatyzacji poza przebiegami testów |
headless | VDI / zdalny pulpit renderujący bez prawdziwego GPU | Zobacz „Środowiska korporacyjne” poniżej |
extension | Aktywne jest rozszerzenie automatyzujące, proxy lub VPN | Sprawdź rozszerzenie |
other | Uruchomił się niespecyficzny wskaźnik automatyzacji | Klasę sprawdzisz w reasons (Business+) |
W planach Business i Enterprise tablica reasons w webhooku nazywa klasę obserwacji
stojącą za werdyktem — to najszybsza droga do zrozumienia fałszywego wykrycia. Zobacz
Kody przyczyn.
2. Środowiska korporacyjne z renderowaniem programowym
Środowiska Citrix, VDI i serwerów terminalowych renderują bez prawdziwego GPU, co
przypomina środowisko uruchomieniowe headless. Jeśli Twoi użytkownicy pracują w takich
środowiskach, zastosuj łagodniejszą politykę, gdy webhook pokazuje typ bota headless:
// `event` is the webhook delivery body (/docs/webhooks)if (event.bot?.result === "bot" && event.bot.type === "headless") { // VDI and remote-desktop users render without a real GPU and can trip the // headless classification — consider applying a softer policy for these.}3. Automatyczne testy w środowisku produkcyjnym
Jeśli Twój zespół QA uruchamia testy Selenium/Playwright na produkcji, zostaną one prawidłowo wykryte jako boty. Użyj osobnego klucza dla ruchu testowego.
Plik cookie _vid_t znika między wizytami, przez co każda wizyta jawi się jako „nowy” odwiedzający.
1. Witryna bez HTTPS
Plik cookie _vid_t używa flagi Secure i jest ustawiany wyłącznie przez HTTPS. Upewnij się, że Twoja witryna korzysta z HTTPS.
2. Ładowanie cross-site
TRACIO ustawia na pliku cookie SameSite=Lax. Jeśli agent jest ładowany w ściśle cross-site kontekście, plik cookie może zostać zablokowany. Serwowanie agenta z subdomeny first-party (przez scriptUrl / endpoint) utrzymuje go jako same-site.
3. Safari ITP
Intelligent Tracking Prevention (ITP) w Safari może ograniczać czas życia plików cookie ustawianych po stronie klienta. TRACIO dodatkowo wystawia _vid_t po stronie serwera za pomocą nagłówka Set-Cookie i odzwierciedla UID w localStorage, dzięki czemu tożsamość przetrwa nawet wtedy, gdy czas życia pliku cookie zostanie ograniczony.
4. Przeglądarka czyszcząca pliki cookie
Niektóre przeglądarki (Brave, Firefox Focus) czyszczą pliki cookie po zakończeniu sesji. Użytkownicy z agresywnymi ustawieniami prywatności zawsze będą się pojawiać jako nowi odwiedzający.
tracio.getResult() zwraca wynik zauważalnie dłużej niż na Twoich pozostałych
urządzeniach testowych i w innych sieciach.
1. Wolne połączenie sieciowe z edge
Sprawdź opóźnienie round-trip do Twojego regionalnego edge:
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" https://edge.tracio.ai/health2. Zbieranie trwa zbyt długo
Na mniej wydajnych urządzeniach zbieranie trwa dłużej. Każde sprawdzenie, które może być wolne, jest ograniczone własnym limitem czasu, więc zbieranie nigdy nie blokuje w nieskończoność — sprawdzenie, któremu skończy się czas, jest po prostu raportowane jako niedostępne, a identyfikacja przebiega dalej bez niego.
Identyfikacja kończy się powodzeniem, ale pewność jest niższa od oczekiwanej w konkretnej przeglądarce lub klasie urządzeń.
Nie każde sprawdzenie może wykonać się w każdym środowisku: restrykcyjna CSP, ograniczenia platformy i funkcje prywatności przeglądarki sprawiają, że część z nich jest niedostępna. Jest to oczekiwane i obsługiwane w sposób łagodny — pewność liczona jest z tego, co faktycznie udało się zebrać, dlatego utwardzone przeglądarki w pełni zasadnie identyfikują się z niższą pewnością niż standardowe.
Po Twojej stronie nie jest wymagane żadne działanie. Jeśli pewność jest stale niska dla
dużej części Twojego ruchu, skontaktuj się ze wsparciem, podając requestId —
diagnozuje się to na podstawie zapisu po stronie serwera, a nie z przeglądarki.
Jeśli napotkasz problem, który nie został tu omówiony:
debug: truerequestId dotkniętej identyfikacji