有什么可以帮您?

请简要说明,我们会通过电子邮件回复。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
前往首页

Szczegóły techniczne

Protokół, kody błędów, dostępność i stan każdej obietnicy.

Ta strona jest dla tych, którzy chcą wiedzieć dokładnie. Wszystko tutaj jest zmierzone albo odczytane z kodu źródłowego — nic nie jest szacowane.

Jak ładuje się widget

Dwa etapy. Najpierw mały loader, który rysuje przycisk i nic więcej. Sam czat jest dociągany dopiero wtedy, gdy zadziała jeden z pięciu wyzwalaczy — przeglądarka ma wolną chwilę (najpóźniej po trzech sekundach), mysz lub palec na przycisku, polecenie ze strony, sygnał frustracji z MousePlayera albo impuls push, np. z Waszego service workera.

Jest ku temu powód: większość odwiedzających nigdy nie otwiera czatu. Dla nich nie powinien on wstrzymywać ładowania strony; to, które wyzwalacze obowiązują, ustawiacie w tagu script.

Dla porównania, również zmierzone i we wszystkich trzech przypadkach spakowane brotli: loader Crispa waży 2 876 B, Intercomu 3 161 B. Z 3 069 B jesteśmy pomiędzy nimi, a nie o rzędy wielkości niżej. Kto twierdzi inaczej, nie mierzył.

Nie przeszkadza Waszej stronie

Widget żyje w zamkniętym shadow DOM. Wasze style go nie dosięgną, jego style nie dosięgną Waszej strony — nawet jeśli ustawicie * { box-sizing: border-box } albo używacie frameworku CSS, który wszystko przedefiniowuje.

Działa pod ścisłą Content Security Policy bez ani jednego komunikatu w konsoli: żadnego eval, żadnej czcionki z sieci, żadnego piksela śledzącego. Style ustawia przez konstruowalne arkusze stylów, których style-src nie obejmuje. Przycisk, okno czatu, przewodniki po produkcie i konsola agenta na Waszej stronie nie potrzebują więc unsafe-inline — zmierzone przy style-src 'self', a nawet przy style-src 'none': zero naruszeń, pełne style. Zmierzone w aktualnym Chromium; starsze przeglądarki bez konstruowalnych arkuszy stylów (np. Safari przed 16.4) używają zastępczego elementu <style>, który ścisła polityka blokuje.

Zero zapytań do obcych serwerów. Wszystko pochodzi z reactive.chat albo, przy własnej domenie, z Waszego adresu; obrazy takie jak logo i awatary — z adresów, które sami podajecie.

Protokół

Połączenie działa przez WebSocket; gdy sieć nie przepuszcza WebSocketu, przez zwykłe zapytania HTTPS (server-sent events albo long polling). Protokół jest wersjonowany i zna 31 kodów błędów, z tego 26 dla widgetu, a pozostałe dla panelu agenta i wyszukiwarki na stronie — każdy z ustaloną reakcją klienta (powtórzyć od razu, powtórzyć po odczekaniu, powtórzyć po ponownym połączeniu, nie powtarzać), niektóre dodatkowo z kodem zamknięcia. Błąd spoza listy jest traktowany jak przejściowy błąd serwera: ponowna próba po odczekaniu, a po pięciu próbach wiadomość uchodzi za niedostarczoną i można ją wysłać ponownie — bez nieskończonej pętli.

Ponowne łączenie z rosnącym odstępem. Gdy połączenie padnie, wiadomości trafiają do bufora i wychodzą, gdy tylko wróci. Każda wiadomość ma identyfikator; serwer rozpoznaje powtórzenia i nie zapisuje ich dwa razy.

Dostępność

Zbudowane zgodnie z WCAG 2.2 AA:

Kontrast jest przeliczany

Podajecie kolor. Tło przyjmuje dokładnie ten kolor. Tekst na nim jest przesuwany tak długo, aż osiągnie stosunek 4,5:1 — wymóg WCAG dla zwykłego tekstu.

Zmierzone na 178 kolorach w dwóch motywach i trzech parach, czyli 1 068 punktów pomiarowych: ani jeden poniżej 4,5:1, najgorsza wartość 4,50:1.

To jest różnica wobec innych dostawców: tam widget da się ustawić tak, że nikt go już nie przeczyta.

Dane osobowe

Maskowanie odbywa się w dwóch miejscach — w przeglądarce odwiedzającego, zanim cokolwiek opuści jego komputer, i jeszcze raz na serwerze, zanim cokolwiek zostanie zapisane. Rozpoznawane są numery kart (z kontrolą Luhna), IBAN-y, adresy e-mail, numery telefonów, numery podatkowe i numery dowodów osobistych. Numery zamówień i klientów pozostają nietknięte.

Dwa miejsca, bo jedno nie wystarcza: to w przeglądarce da się wyłączyć, to na serwerze widzi tylko to, co dotrze.

Reguły

To, kiedy widget się odzywa, jest zapisane w deklaratywnej liście reguł — a nie w warunku w kodzie. Sześć reguł jest domyślnych (dłuższy pobyt na stronie, kliknięcie ze złości, błąd JavaScriptu, utknięcie w formularzu, zamiar zakupu, opuszczanie procesu zamówienia); kliknięcie ze złości, utknięcie w formularzu i zamiar zakupu widget rozpoznaje tylko razem z MousePlayerem. Własne można dodać w koncie. W planie Free działa jedna aktywna zaczepka na projekt.

Różnica jest praktyczna: zmiana reguły to zmiana ustawienia w koncie, a nie wdrożenie.

Integracje

Webhooki i Slack są gotowe. Dla ponad 30 kolejnych usług połączenie jest przygotowane; większość sprawdzono na symulowanych usługach, ale jeszcze nigdy nie działała z prawdziwą usługą, i strona integracji w koncie tak je oznacza.

API serwera (REST i MCP) odczytuje rozmowy, wiadomości, projekty, odwiedzających, zdarzenia i reguły, zapisuje wiadomości i zdarzenia oraz rejestruje webhooki. Lista odwiedzających i MCP mogą być wyłączone dla projektu.

Każda integracja działa przez kolejkę z bezpiecznikiem: gdy usługa trzeciej strony się zawiesi, po kilku nieudanych próbach jest na jakiś czas pomijana. Wiadomość na czacie nigdy przez to nie czeka — to najważniejsza reguła w tej warstwie.

Czego jeszcze nie ma

Żeby nikt nie odkrył tego dopiero przy wdrażaniu:

Więcej w dokumentacji

Jak współpracują widżet, serwer i połączenie: Architektura i przebieg. Nawiązywanie połączenia, tryb awaryjny HTTP i ponowne łączenie: Transport. Wszystkie rozdziały: dokumentacja.

最后更新: