كيف يمكننا المساعدة؟

يرجى توضيح الموضوع بإيجاز، وسنرد بالبريد الإلكتروني.

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.

آخر تحديث: