# które widgety czatu ustawiają cookies, zanim ktoś kliknie

Siedem widgetów czatu zmierzonych przed jakąkolwiek interakcją: jakie cookies ustawiają, co zapisują w localStorage, na jak długo i z jakimi domenami gadają.

2026-10-19 · Kuba

Odwiedzający wchodzi na twoją stronę, czyta przez dziesięć sekund i wychodzi, nie dotykając czatu. Zmierzyliśmy, co siedem widgetów czatu zostawia po sobie w takiej sytuacji: cookies, localStorage, sessionStorage, IndexedDB i serwery, z którymi gadają. Spookat nie zostawia nic i gada z jednym serwerem, naszym CDN. Każdy konkurent, który wystartował, coś zapisał w przeglądarce odwiedzającego, a część z tego zostaje na ponad rok.

@video vs-cookies | Animacja: cookies i klucze w pamięci przeglądarki, które każdy widget czatu zapisuje przed kliknięciem; Spookat zostaje na 0.

## metoda w jednym akapicie

To samo laboratorium co w reszcie serii ([jak testujemy](/pl/blog/how-we-test-chat-widgets/)). Chrome 153, nowiutki profil przy każdym przebiegu, 7 przebiegów na widget, zmierzone 27 września 2026. Strona się ładuje i przez 25 sekund nikt niczego nie klika, nie przewija ani nie wpisuje. Potem czytamy każde cookie w przeglądarce i każdy wpis w localStorage, sessionStorage i IndexedDB w każdej ramce. Zapisujemy nazwy, domeny, czasy życia, flagi i rozmiary, nigdy wartości.

Cztery widgety odmawiają działania na domenie, której właściciel nie dopuścił (Crisp, Intercom, LiveChat i Chatwoot), a id, których mogliśmy użyć, należą do stron vendorów. Na naszej stronie testowej, zanim odmówiły, żaden z nich nic nie zapisał. Dla tych czterech załadowaliśmy więc stronę samego vendora, gdzie widget działa, i załadowaliśmy ją jeszcze raz z zablokowanym widgetem. Cookie albo klucz liczy się jako należący do widgetu tylko wtedy, gdy pojawia się w co najmniej połowie przebiegów z widgetem i w żadnym bez niego. To oddziela widget od analityki i cookies reklamowych vendora, których ich strony marketingowe ustawiają sporo.

Nie ruszaliśmy żadnego banera cookies na tych stronach: ani akceptuj, ani odrzuć, ani zamknij. Niektóre widgety mogą zachowywać się inaczej, gdy odwiedzający już wybrał, i to jest poza tym testem.

## wyniki

| widget | cookies przed kliknięciem | najdłużej trzymane | local i session storage | serwery, z którymi gada |
|---|---|---|---|---|
| Spookat | 0 | brak | brak | 1 (`cdn.spookat.com`) |
| Tawk.to | 3 na domenie strony | 180 dni | 2 klucze w localStorage, 1 w sessionStorage | 9 hostów na `tawk.to` |
| Tidio | 0 | brak | 1 klucz w localStorage (3 kb) | 2 hosty na `tidio.co` |
| Crisp | 1 na domenie strony | 182 dni | 4 klucze w localStorage | 3 hosty na `crisp.chat` |
| Intercom | 3 na domenie strony | 270 dni | 1 klucz w localStorage, 1 w sessionStorage | 4 hosty na `intercom.io` i `intercomcdn.com` |
| LiveChat | 2 na `accounts.livechatinc.com` (+1, które od razu wygasa) | 400 dni | 4 klucze w localStorage, 1 w sessionStorage, w jego iframe | 4 hosty na `livechatinc.com` |
| Chatwoot | 1 na domenie strony, 1 na `app.chatwoot.com` | 365 dni | 6 kluczy w localStorage (460 kb) w jego iframe | 3 hosty na `chatwoot.com`, CloudFront i S3 |

Nikt nie użył IndexedDB. Każdy wynik był taki sam we wszystkich 7 przebiegach każdego widgetu.

„Na domenie strony” znaczy, że własny skrypt widgetu zapisał cookie JavaScriptem, na domenie, na której akurat jest strona. Na twojej stronie to byłyby twoje cookies, ustawione przez cudzy kod.

## widget po widgecie

### spookat: nic

Launcher to jeden skrypt z `cdn.spookat.com`. Rysuje przycisk i na tym koniec. Nie ma kodu, który czyta albo zapisuje cookies, i przed kliknięciem nie wykonuje się żadne wywołanie storage.

Po kliknięciu dalej nic nie jest zapisywane. Ładuje się panel czatu, łączy się z `api.spookat.com` i pokazuje powitanie. Dopiero gdy odwiedzający wyśle pierwszą wiadomość, panel zapisuje jeden klucz w localStorage, żeby rozmowa przetrwała przeładowanie strony. To pierwszy raz, kiedy Spookat cokolwiek wkłada do przeglądarki: po tym, jak człowiek poprosił o czat i coś w nim napisał. Widget nigdy nie ustawia cookie, ani wtedy, ani później.

### tawk.to: trzy cookies i token

Tawk.to startuje wszędzie, więc to jego pełne liczby na zwykłej stronie. Przed jakimkolwiek kliknięciem ustawia trzy cookies na domenie samej strony:

- `twk_uuid_<property>`, trzymane 180 dni
- `TawkConnectionTime`, cookie sesyjne
- `twk_idm_key`, cookie sesyjne

Zapisuje dwa klucze w localStorage, w tym token na 464 bajty, i jeden klucz w sessionStorage z poprzednią stroną. Otwiera websocket do jednego z kilku numerowanych serwerów `tawk.to`. W naszych 7 przebiegach użył 7 różnych, dlatego w tabeli jest 9 hostów.

### tidio: jeden klucz, zero cookies

Tidio nie ustawił żadnych cookies. Zapisał jeden klucz w localStorage ze swoim stanem (około 3 kb) i otworzył websocket do `socket.tidio.co`. Jego własny widget jest na tidio.com ustawiony jako ukryty, więc nasza strona przed kliknięciem wołała udokumentowane `tidioChatApi.show()`, żeby pokazać launcher. To jedyna zmiana względem standardowej instalacji.

### crisp: sesja na pół roku

Na crisp.chat, przed jakimkolwiek kliknięciem, widget ustawia jedno cookie na domenie strony, `crisp-client/session/<website id>`, trzymane 182 dni. Zapisuje też cztery klucze w localStorage: tę samą sesję, jej wygaśnięcie oraz licznik wizyt i czas ostatniej wizyty dla swoich triggerów. Jego websocket idzie do `client.relay.crisp.chat`.

### intercom: id na dziewięć miesięcy

Na intercom.com widget ustawia trzy cookies na domenie strony:

- `intercom-id-<app>`, trzymane 270 dni
- `intercom-device-id-<app>`, trzymane 270 dni
- `intercom-session-<app>`, trzymane 7 dni

Do tego swój stan w localStorage (2,4 kb) i listę odtworzonych powiadomień w sessionStorage, co pasuje do wiadomości, którą intercom.com wypycha do nowych odwiedzających. Cichsza instalacja może tego ostatniego nie zapisywać.

### livechat: cookies stron trzecich, partycjonowane

Cookies LiveChata siedzą na domenie vendora, a nie strony, i ustawia je jego serwer: `__lc_cid` i `__lc_cst` na `accounts.livechatinc.com`, trzymane 400 dni, `HttpOnly`, `Secure`, `SameSite=None` i partycjonowane. Partycjonowane znaczy, że Chrome trzyma osobną kopię dla każdej strony, na której jest odwiedzający, więc to samo cookie nie pójdzie za nim z jednej strony na drugą. Trzecie, `__oauth_redirect_detector`, wygasa od razu po ustawieniu.

Jego iframe z `secure.livechatinc.com` zapisuje też cztery klucze w localStorage, w tym token autoryzacji i flagę „już tu był”, oraz jeden klucz w sessionStorage.

### chatwoot: 460 kb w localStorage

Na help center chatwoot.com (strona główna nie załadowała widgetu w naszych próbach) widget ustawił cookie `cw_conversation` na domenie strony, trzymane 365 dni, i cookie sesyjne na `app.chatwoot.com`. Jego iframe zapisał sześć kluczy w localStorage. Jeden z nich trzyma sześć najczęściej czytanych artykułów pomocy i ma 460 kb, czyli sporo cudzej treści zapisanej na urządzeniu twojego odwiedzającego na wszelki wypadek.

## czyje to cookie

Za „widget ustawia cookie” kryją się dwie różne rzeczy.

**Cookies na twojej domenie.** Tawk.to, Crisp, Intercom i Chatwoot zapisują swoje JavaScriptem, na domenie strony, na której działają. Dla przeglądarki to cookies pierwszej strony: twoje. Przeżywają blokowanie cookies stron trzecich, bo nie są stron trzecich, i lecą też z każdym requestem do twojego własnego serwera. Lista cookies odwiedzającego na twojej stronie pokaże `twk_uuid_…` albo `intercom-id-…` obok twojego własnego cookie sesji.

**Cookies na domenie vendora.** Cookies LiveChata mieszkają na `accounts.livechatinc.com`, a cookie sesji Chatwoota na `app.chatwoot.com`. Na twojej stronie to cookies stron trzecich. Chrome wciąż domyślnie je dopuszcza, ale te od LiveChata są partycjonowane, więc każda strona dostaje własny słoik i nie da się nimi połączyć odwiedzającego między stronami.

Przeglądarki nie traktują ich jednakowo. Intelligent Tracking Prevention w Safari ogranicza cookies zapisane JavaScriptem do 7 dni, więc na iPhonie 180-dniowe cookie Tawk.to i 270-dniowe Intercomu żyją najwyżej tydzień. Chrome ogranicza każde cookie do 400 dni, czyli dokładnie tyle, o ile prosi LiveChat.

## czwórka odrzuconych i tak zadzwoniła do domu

Na naszej stronie testowej, gdzie Crisp, Intercom, LiveChat i Chatwoot nie mogły działać, żaden nic nie zapisał. Zanim się poddały, odezwały się jednak do swoich serwerów: Intercom do trzech hostów (loader, jego CDN i API, które odpowiedziało 403), LiveChat do dwóch, Crisp do dwóch, w tym websocketem otwartym, zanim pokazał „Invalid website”, a Chatwoot do jednego. Jeśli usuniesz domenę z allowlisty vendora, a snippet zostawisz na stronie, twoi odwiedzający dalej wysyłają te requesty.

## serwery, z którymi gadają twoi odwiedzający

Każdy request niesie adres IP odwiedzającego, user agenta jego przeglądarki i najczęściej adres strony, na której jest. Tak działa sieć, a to znaczy, że każdy serwer, z którym gada widget, dowiaduje się, że ten odwiedzający był na tej stronie w tej chwili, niezależnie od tego, czy kiedykolwiek napisze.

Przed jakąkolwiek interakcją, na stronie, na której mógł wystartować:

- Spookat: 1 host, `cdn.spookat.com`. Jest nasz, a przed nim stoi Cloudflare, jak przed każdym naszym hostem; Cloudflare jest na liście podprocesorów na naszej stronie o prywatności. Nigdy nie zapisujemy IP.
- Tawk.to: 9 hostów w sumie w naszych przebiegach, po jednym naraz dla websocketu.
- Tidio, Crisp: 2 i 3 hosty.
- Intercom, LiveChat, Chatwoot: od 3 do 4 hostów, w tym websockety, które zostają otwarte tak długo jak karta.

Websocket otwarty przed kliknięciem to żywe połączenie z vendorem przez całą wizytę. Dzięki niemu widget może pokazać „jesteśmy online” albo wypchnąć wiadomość, i jednocześnie to stały sygnał, że ktoś jest na stronie.

## co to znaczy dla twojego banera cookies

Nie jesteśmy prawnikami i to nie jest porada prawna. Oto część, która jest zwykłym faktem.

Unijny przepis, z którego wzięły się banery zgody, art. 5 ust. 3 dyrektywy ePrivacy, nie dotyczy konkretnie cookies. Obejmuje przechowywanie informacji na urządzeniu odwiedzającego albo dostęp do informacji już tam zapisanych. localStorage i sessionStorage to takie samo przechowywanie na urządzeniu jak cookies. Wyjątek w przepisie dotyczy przechowywania, które jest ściśle niezbędne do świadczenia usługi, o którą odwiedzający wyraźnie poprosił.

Odwiedzający, który nie dotknął czatu, o niego nie prosił. Kiedy więc widget zapisuje mu id w przeglądarce przy ładowaniu strony, musisz zdecydować, czy to się mieści w wyjątku, co trudno obronić przy kimś, kto nigdy nie pisze, czy widget powinien trafić za twój baner zgody. Większość widgetów z tego testu stawia cię przed tym pytaniem. Widget, który przed kliknięciem nic nie zapisuje, nie stawia.

Schowanie widgetu za banerem ma swój koszt. Narzędzia do zgód potrafią wstrzymać skrypt, dopóki odwiedzający nie zaakceptuje, i większość to zrobi. Wtedy ktoś, kto odrzuci baner albo go po prostu zignoruje, nie dostaje czatu w ogóle, często ten sam ktoś, kto miał pytanie przed zakupem. Wybierasz więc między banerem, który zasłania czat, a czatem, który działa tylko dla tych, co kliknęli „akceptuj wszystko”.

Drugie wyjście to widget, który nic nie zapisuje, dopóki odwiedzający o to nie poprosi. Wtedy pytanie o przechowywanie w ogóle nie pojawia się przy ładowaniu strony, a później dotyczy tylko ludzi, którzy otworzyli czat i coś w nim napisali, czyli dokładnie tych, którzy o usługę poprosili.

O co zapytać vendora i swojego prawnika:

- Co widget zapisuje przed jakąkolwiek interakcją i na jak długo?
- Czy może poczekać, aż odwiedzający kliknie, i czy czekanie coś psuje?
- Które jego serwery dostają request przed kliknięciem i w jakim są kraju?
- Czy jest ustawienie, które wyłącza przechowywanie przed interakcją, i co jeszcze wtedy się wyłącza?

## czego chcielibyśmy od każdego widgetu

- Nic zapisanego w przeglądarce odwiedzającego, zanim dotknie czatu.
- Żadnego połączenia trzymanego przed kliknięciem. Przycisk nie potrzebuje websocketu.
- Jeden serwer, a nie garść, i vendor, który potrafi powiedzieć, gdzie on stoi.
- Po rozpoczęciu rozmowy jeden klucz na rozmowę, a nie id, które ma rozpoznawać odwiedzającego przez następny rok.
- Lista cookies, którą da się opisać jedną linijką w polityce prywatności.

Taką poprzeczkę postawiliśmy Spookatowi, a tabela wyżej pokazuje, jak wygląda widget, który ją przeskakuje.

## jak sprawdzić swój widget

1. Otwórz swoją stronę w oknie prywatnym, żeby nic jeszcze nie było zapisane.
2. Otwórz DevTools, przejdź do Application i zobacz Cookies, Local storage, Session storage i IndexedDB dla swojej domeny i każdej ramki z listy.
3. Nie dotykaj strony przez 25 sekund, potem odśwież widok Application. Wszystko nowe przyszło od czegoś na stronie. Zablokuj skrypt widgetu w zakładce Network i powtórz, a zobaczysz, co z tego jest widgetu.

Nasze surowe dane są w [/research/cookies-2026-09.json](/research/cookies-2026-09.json): każdy przebieg, każde cookie z domeną, czasem życia i flagami, każdy klucz storage z rozmiarem, a dla stron vendorów nazwy, które zniknęły po zablokowaniu widgetu. Skrypty są w [laboratorium widgetów](/research/widget-lab/). Bajtowa strona tych samych przebiegów jest w [ważeniu](/pl/blog/chat-widget-weigh-in/).

## czemu nasz nic nie zapisuje

Nie dlatego, że kazał nam prawnik. Launcher ma przed kliknięciem jedną robotę: być przyciskiem. Przycisk nie potrzebuje id w przeglądarce odwiedzającego, połączenia z naszym serwerem ani sposobu, żeby rozpoznać go jutro. Spookat nie robi więc niczego z tych rzeczy, dopóki ktoś nie napisze w czacie, a potem trzyma dokładnie jeden klucz, rozmowę, żeby czat przetrwał przeładowanie. Zero cookies, przed i po.

[Dodaj czat, który nie zostawia śladu, dopóki ktoś go nie użyje](/pl/pricing/): 14 dni, bez karty.

---
source: https://spookat.com/pl/blog/chat-widget-cookies/