Czy WebMCP skończy z modalem newslettera & oferty rabatowej? Mamy taką nadzieję. Zarejestrowaliśmy narzędzie na naszej stronie, żeby to sprawdzić.

Klikasz link, strona zaczyna się ładować, a popup nasuwa się na nią, zanim przeczytasz zdanie. Dziesięć procent zniżki, jeśli oddasz adres e-mail firmie, u której jesteś od dziewięciu sekund. Zamykasz go. Gdzieś niżej czeka drugi, na moment, w którym ruszysz w stronę przycisku wstecz.

Ten popup nie jest błędem projektowym. Robi dokładnie to, do czego go zbudowano, i działa na tyle dobrze, że nikt w zespole marketingu nie walczy o jego usunięcie.

Adres e-mail jest kluczem do programu retencyjnego. Kiedy marka już go ma, może uruchomić przepływy cyklu życia, które stoją za każdą platformą ecommerce: serię powitalną odpalaną przy zapisie, mail po porzuceniu przeglądania wysyłany, gdy ktoś obejrzy produkt i wyjdzie, sekwencję po porzuceniu koszyka i checkoutu, przypomnienia posprzedażowe i o uzupełnieniu zapasu oraz odzyskiwanie każdego, kto ucichł. Żadne z nich nie ruszy bez adresu. Wszystkie odpalają się z zachowania i zarabiają długo po tym, jak reklama, która przyprowadziła odwiedzającego, została opłacona.

To właśnie kupuje dziesięć procent. Zniżka jest ceną zakupu stałej linii kontaktu i jest tania obok płatnego kliknięcia, które Cię dostarczyło. Przepływy wyzwalane zachowaniem zarabiają na odbiorcę dużo więcej niż newsletter rozsyłany do wszystkich, a sekwencja po porzuconym koszyku zarabia ze wszystkich najwięcej, więc marketer liczący wartość adresu nie liczy jednego maila. Liczy ich strumień, który płynie latami.

Tłumaczy to też moment. Popup odpala się na wejściu, na głębokości przewinięcia albo przy pierwszym znaku, że kierujesz się do przycisku wstecz, bo odwiedzający, który wychodzi bez oddania adresu, jest nieosiągalny na zawsze, a odwiedzający, który adres odda, jest początkiem sekwencji. Marka zbierająca adresy od trzech procent odwiedzających robi świetny interes kosztem zirytowania pozostałych dziewięćdziesięciu siedmiu.

WebMCP niczego z tego nie rusza. Zmienia mechanizm. Strona może opublikować swój zapis jako funkcję, opisać zwykłym językiem, co ona robi, i pozwolić agentowi AI pracującemu dla odwiedzającego wywołać ją wtedy, gdy odwiedzający faktycznie poprosi o ofertę. Adres dalej przychodzi, zniżka dalej idzie w świat, a czytanie nie zostaje przerwane.

Dla czytającego to cała nagroda. Pytanie brzmi, ile z niej da się odebrać dzisiaj, a uczciwa odpowiedź to: kawałek.

Jak odwiedzający odbiera usunięcie popupu

Oto ta sama oferta zebrana na dwa sposoby. Po lewej to, co odwiedzający dostaje dzisiaj. Po prawej to, co ta sama osoba dostaje, gdy strona opublikowała swój zapis jako coś, co jej asystent może wykonać.

Popup kończy tak naprawdę zmiana w ruchu

Część ludzi w marce zrezygnowałaby z popupu w całości. Zostaje, bo przerywanie ludziom to jedyna metoda, która niezawodnie zbiera adresy e-mail, a koszt tego przerwania spada na odwiedzającego, a nie na zespół, który je wybrał. Wszyscy czytający dostają gorsze doświadczenie po to, żeby mały procent z nich oddał adres, i ten układ trzyma się od jakichś dwudziestu lat, bo nic innego nie zbierało adresów równie dobrze.

Ten układ pęka dopiero wtedy, gdy druga metoda zaczyna zbierać te same adresy bez przerywania, i pęka po jednej wizycie naraz.

Popup działa wyłącznie na człowieka patrzącego w ekran. Gdy czyta asystent, nie ma ekranu do zasłonięcia ani wahania, pod które da się podpiąć licznik, więc taka wizyta nie daje żadnych adresów, choćby popup był dostrojony idealnie.

Ta sama wizyta wciąż może dać adres. Ktoś, kto prosi swojego asystenta o zniżkę, oddaje go dobrowolnie, z imieniem przy nim, w momencie, w którym sam tego chciał. Ten adres jest czystszy, intencja za nim mocniejsza, a na jego zdobycie nie wydano ani grama sympatii.

Zespół marketingu trzyma popup tak długo, jak długo on się opłaca. W miarę jak coraz więcej wizyt przychodzi przez asystentów, popup odpala się do kurczącej się widowni po kurczący się zwrot, a irytacja, którą wywołuje, zostaje ta sama. To samo wyliczenie, które postawiło go na stronie, w końcu go z niej zdejmie.

Nic z tego nie przychodzi w harmonogramie, którym rządzi specyfikacja. Przychodzi wtedy, gdy dość ludzi czyta sieć przez coś, co czyta w ich imieniu, a to pytanie o ruch, a nie o standardy, i da się je zmierzyć w Twoich własnych logach już dziś.

Warto powiedzieć wprost, że cel jest dobry. Sieć, w której oferta jest dostępna dla każdego, kto o nią poprosi, i niewidoczna dla każdego, kto nie poprosił, jest lepsza dla czytelnika i nie gorsza dla marki. To rzadkie połączenie i właśnie dlatego warto budować pod to wcześnie, zamiast czekać, aż przyjdzie zasięg.

Zarzut Apple brzmi tak: strona nigdy nie powinna wiedzieć, że prowadzi ją agent

Dwoje inżynierów Apple wyłożyło zarzut WebKit w publicznym wątku stanowisk standaryzacyjnych w czerwcu 2026 roku, a stanowisko rozstrzygnięto jako sprzeciw 11 czerwca. Podają sześć powodów, a pierwszy dotyczy tego, czym agent jest.

Stanowisko WebKit głosi, że agent działający dla użytkownika jest „w istocie technologią wspomagającą: powinien obsługiwać stronę tak, jak zrobiłby to użytkownik, a strona nie powinna wyróżniać go innym traktowaniem". WebMCP robi coś odwrotnego. Czyni z tego, że „prowadzi agent", fakt obserwowalny, a kiedy da się to zaadresować osobno, nic nie utrzymuje obu powierzchni w parytecie. Strona może dać agentom możliwości, których odmawia własnemu interfejsowi, albo odmówić ich agentom, co opisują jako „problem blokowania czytnika ekranu, tylko przyłożony do agentów AI".

Wątpią też w obietnicę niezawodności. Agent i tak wybiera narzędzie, czytając jego nazwę i opis, a sama specyfikacja przyznaje, że są one wieloznaczne i nieweryfikowalne, bo nie ma „żadnej gwarancji, że deklarowana intencja narzędzia WebMCP odpowiada jego faktycznemu zachowaniu". Typowany schemat przypina kształt argumentu, a nie znaczenie, którego agent musi się domyślić, więc w ich odczycie kruchość przenosi się ze strony do opisów narzędzi, zamiast znikać.

Zarzut o prywatność jest ostrzejszy niż zwykle. Strona może poprosić o więcej parametrów, niż potrzebuje, a usłużny agent wypełni je z rzeczy, które użytkownik powiedział agentowi, a nie stronie. Specyfikacja sama nazywa to we własnym tekście rurociągiem „od personalizacji do odcisku palca".

Zwracają też uwagę, że fragmenty potrzebne recenzentowi do oceny czegokolwiek z tego, w tym analiza bezpieczeństwa międzyźródłowego i punkt zaczepienia dla zgody, wciąż są oznaczone jako praca do wykonania, oraz że grupa powołana wokół uczenia maszynowego jest złym miejscem dla zmian, których prawdziwy dom to HTML i semantyka dostępności.

Jeden z podanych przez nich niezmienników trafia wprost w temat tego artykułu: „Część użytkowników nie będzie albo nie może korzystać z agentów, więc wynik musi służyć wszystkim użytkownikom i nie może uprzywilejowywać tych, którzy agenta mają".

Postaw to obok wzorca z kodu powyżej. Wyciszenie popupu zależy od tego, żeby strona dowiedziała się, że agent zadziałał, czyli dokładnie od obserwowalności, która zdaniem Apple istnieć nie powinna. Opisane wcześniej ciche doświadczenie jest kupione sygnałem, o którym drugi silnik powiedział, że sieć nie powinna go udostępniać. Obie te rzeczy mogą być prawdziwe, a każdy, kto na tym buduje, powinien wiedzieć, że wybiera stronę sporu, a nie sięga po rzecz ustaloną.

Redaktorzy z Google odpowiedzieli w tym samym wątku i zapytali, co zadowoliłoby WebKit poza usunięciem imperatywnego API. Odpowiedź brzmiała, że nie będą odpowiadać punkt po punkcie, bo każde pytanie zakłada, że podejście jest słuszne, i zaproponowali zaczęcie od nowa: nową grupę społecznościową, problem zdefiniowany przed jakimkolwiek rozwiązaniem oraz warsztat wokół TPAC pod koniec października 2026 roku.

Żaden iPhone tego nie uruchomi, łącznie z Chrome na iPhonie

Stanowisko Apple to nie tylko głos w wątku standaryzacyjnym. Ono rozstrzyga tę funkcję dla każdej przeglądarki na tej platformie.

Każda przeglądarka wydawana dziś na iOS renderuje na WebKicie. Chrome na iPhone to silnik Safari w interfejsie Google, a to samo dotyczy Edge, Firefoksa i reszty. Funkcja, której WebKit nie chce zaimplementować, jest więc na iPhonie niedostępna niezależnie od tego, w którą ikonę przeglądarki ktoś stuknie.

To może się zmienić, powoli. Brytyjski Competition and Markets Authority uznał wymóg silnika stawiany przez Apple za naruszenie swojego reżimu Strategic Market Status, z planem dostosowania na czerwiec 2026 roku i zmianami spodziewanymi w iOS 20 jesienią 2026 roku, przed pełną zgodnością w styczniu 2027 roku. Unijny Digital Markets Act dopuszcza alternatywne silniki od 2024 roku. W praktyce żaden z nich takiego silnika nie przyniósł: żaden producent przeglądarek nie wypuścił alternatywnego silnika przez App Store, a i Google, i Mozilla mają porty, które pozostają niewydane.

Dla marki ecommerce to liczba ważniejsza niż jakakolwiek data ze specyfikacji, bo ruch z iPhone’ów to duży udział w większości sklepów, a dziś żadna jego część nie sięgnie zarejestrowanego narzędzia.

Testowanie oznacza przeglądarkę na Chromium, czyli to, czego większość agentów już używa

Agenci, którzy czytają, siedzą już na właściwym silniku. Claude działa jako rozszerzenie wewnątrz Chrome, Gemini jest wbudowany w Chrome, Copilot siedzi w Edge, a Comet od Perplexity jest własną przeglądarką na Chromium. Przeglądanie agentowe na desktopie jest dziś w przeważającej mierze na Chromium, więc silnik rzadko bywa przeszkodą.

Przeszkoda, którą ludzie pomijają, jest taka, że nie każdy asystent czytający Twoją stronę jest w ogóle przeglądarką. Poproś ChatGPT albo Claude w oknie czatu o otwarcie adresu, a pobranie zwykle odbywa się na serwerze: Twój HTML zostaje pobrany, żaden JavaScript się nie wykonuje i lista narzędzi nigdy nie powstaje. Taki asystent może przeczytać każde słowo Twojej strony i dalej nie mieć pojęcia, że zarejestrowano na niej narzędzie. Narzędzie widzi wyłącznie agent działający wewnątrz prawdziwej strony w Chromium, co dziś oznacza coś w rodzaju Gemini w Chrome albo rozszerzenie, które samo implementuje odnajdywanie.

Przeszkodą jest to, że funkcja wciąż stoi za bramką, a przez tę bramkę prowadzą dwie drogi.

Strona zapisuje się do origin trial w Chrome i serwuje token. Tą drogą idzie sklep produkcyjny i ma ona trzy kroki.

Zarejestruj origin pod developer.chrome.com/origintrials/#/register_trial/4163014905550602241, czyli w próbie WebMCP, która biegnie od Chrome 149 do Chrome 156. Podaj origin faktycznie serwujący Twoje strony, razem z subdomeną, bo token wydany dla example.com nie obejmuje www.example.com. Jeśli Twoja domena główna przekierowuje na www, zarejestruj host www i pomiń dopasowanie subdomen, bo przekierowanie nigdy nie ładuje dokumentu, więc nigdy nie potrzebuje tokenu.

Serwuj token, który dostaniesz, jako nagłówek odpowiedzi albo jako znacznik meta w sekcji head każdej strony rejestrującej narzędzie:

<meta http-equiv="origin-trial" content="YOUR_TOKEN_HERE">

Emituj go tylko wtedy, gdy go masz. Pusty albo wygasły token zapisuje błąd w konsoli przy każdym załadowaniu strony, więc zrób ten znacznik warunkowym, zamiast wkleić pusty atrybut i o nim zapomnieć.

Edge prowadzi osobną próbę z własną rejestracją i własnym tokenem. Zapisanie się do jednej nie daje nic drugiej.

Albo odwiedzający włącza to sam, uruchamiając Chrome z --enable-blink-features=WebMCP albo włączając eksperymentalne funkcje platformy webowej w chrome://flags. To droga dewelopera, a nie klienta.

Ta strona idzie pierwszą drogą. Każda strona w tym serwisie serwuje token origin trial dla WebMCP, więc odwiedzający przychodzący w Chrome od 149 do 156 dostaje document.modelContext bez włączania czegokolwiek, a panel powyżej to potwierdzi. Ten token wygasa 17 listopada 2026 roku i wtedy narzędzie milknie dla zwykłych odwiedzających, dopóki próba nie zostanie przedłużona albo funkcja nie trafi do wydania, a formularz działa dalej tak jak zawsze. Każdy na Safari, na dowolnej przeglądarce na iPhonie albo na Chrome spoza tego zakresu wersji widzi formularz i nic więcej.

Stare poradniki nie zadziałają, a większość z nich ma złą datę

WebMCP nie jest skończonym standardem webowym. To projekt redagowany przez inżynierów z Google i Microsoftu, a projekty zmieniają się, gdy ludzie już na nich budują. Ten zmienił się w sposób, który psuje kod.

Nazwa, którą wywołujesz, się przeniosła. Kiedyś było to navigator.modelContext, a teraz jest document.modelContext. Chrome przez pewien czas przyjmował obie nazwy i ostrzegał deweloperów w konsoli, a potem przestał przyjmować starą w Chrome 152, który dotarł do wszystkich 25 sierpnia 2026 roku. Kod napisany po staremu nie zwalnia ani nie działa gorzej. On się zatrzymuje.

Sygnalizujemy to, bo opracowania nie zgadzają się co do tego, kiedy to się stało. Kilka umieszcza tę zmianę w sierpniu 2026 roku. Własna historia projektu umieszcza ją w maju, trzy miesiące wcześniej:

Używaj document.modelContext. Poradnik sięgający po navigator powstał wobec czegoś, co już nie istnieje, a data z wpisu na blogu jest warta mniej niż ta sama data z własnej historii commitów projektu.

Wsparcie to Chromium i nic poza tym. Chrome otworzył publiczny test w czerwcu 2026 roku, który biegnie do Chrome 156. Edge prowadzi własny od Edge 150, a Brave ma to eksperymentalnie, i obie te przeglądarki stoją na silniku Chrome. Apple formalnie sprzeciwiło się propozycji 11 czerwca 2026 roku. Mozilla nie zajęła strony i trzyma otwarty prototyp.

Narzędzie to funkcja plus słowa, które mówią asystentowi, kiedy jej użyć

Narzędzie to słownik z nazwą, opisem, schematem wejścia w JSON i callbackiem wykonującym. Nazwa przyjmuje od 1 do 128 znaków alfanumerycznych ASCII plus podkreślenie, łącznik i kropkę. Wymóg bezpiecznego kontekstu obejmuje cały interfejs, razem z getTools i executeTool, a dostępem rządzi funkcja Permissions Policy o nazwie tools, której domyślna lista dozwolonych to 'self'.

Opis waży więcej niż nazwa. Agent wybiera między narzędziami, czytając opisy, więc opis napisany pod changelog dla deweloperów przegra z opisem napisanym dla tego, kto podejmuje decyzję.

Napisanie zapisu jako narzędzia zajmuje jakieś trzydzieści linii

Wzorzec ma dwie połowy. Zarejestruj ofertę jako narzędzie i naucz modal odpuszczać, kiedy oferta zostanie przyjęta.

const modelContext = document.modelContext || navigator.modelContext;

if (modelContext) {
  modelContext.registerTool({
    name: "subscribe_to_offer",
    title: "Get the first-order discount code",
    description:
      "Starts a first-order discount signup by sending a confirmation email to an " +
      "address. The code arrives only after the address is confirmed. Call this when " +
      "the visitor asks for the discount or asks to join the mailing list.",
    inputSchema: {
      type: "object",
      properties: {
        email: {
          type: "string",
          format: "email",
          description: "The address the visitor wants the code sent to."
        }
      },
      required: ["email"]
    },
    annotations: { readOnlyHint: false },
    execute: async ({ email }, { signal }) => {
      const res = await fetch("/api/subscribe", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ email, source: "webmcp" }),
        signal
      });

      if (!res.ok) {
        return "The signup did not go through. The form near the foot of the page still works.";
      }

      // Silence the popup for the rest of this visit. Make it permanent from the
      // server when the confirmation link is clicked, never from here.
      try { sessionStorage.setItem("offer_asked", "1"); } catch (e) {}

      return "Confirmation email sent. The code arrives once the address is confirmed.";
    }
  });
}

Popup milknie w chwili, w której narzędzie zadziała, i o to w tym wszystkim chodzi.

Flaga trzyma tylko przez tę wizytę i jest to celowe. Wyłączenie popupu na stałe, zanim ktokolwiek kliknie link potwierdzający, zabiera zapis odwiedzającemu, którego adres nigdy nie został potwierdzony, i nie zostawia mu żadnej drogi do subskrypcji. Wycisz popup na czas wizyty ze strony. Zrób to trwałym ze swojego serwera, kiedy potwierdzenie zostanie kliknięte.

annotations: { readOnlyHint: false } mówi agentowi, że wywołanie coś zmienia, a nie coś odczytuje. To i tak jest już domyślne, a wypisanie tego stawia następnego czytelnika o jedną linię od untrustedContentHint, czyli od adnotacji, która ma znaczenie dla każdego narzędzia zwracającego tekst, na którym agent będzie działał.

signal to sygnał przerwania, który przeglądarka podaje każdemu uruchamianemu narzędziu. Przekazanie go do żądania sprawia, że agent rezygnujący w pół drogi nie zostawia zapisu domykającego się dla kogoś, kto przestał o niego prosić.

Nie da się zapytać strony, czy patrzy na nią agent. Specyfikacja oferuje getTools, executeTool i zdarzenie toolchange, a żadne z nich na to pytanie nie odpowiada. Wywołanie Twojego własnego narzędzia to jedyny pewny sygnał, jaki dostajesz. Zapisz tę samą flagę, którą Twój popup już sprawdza, a przestanie się on odpalać temu odwiedzającemu tak samo, jak przestaje po wypełnieniu formularza.

Wersja działająca na tej stronie

Ten serwis rejestruje jedno narzędzie o nazwie contact_wislr i działa ono od publikacji tego artykułu. Formularz kontaktowy w tym serwisie otwiera się po kliknięciu, a nie odpala na zamiarze wyjścia, więc narzędzie nie usuwa tu przerwania. Usuwa pisanie.

Trzy decyzje w tej implementacji warto skopiować.

Schemat prosi o więcej niż formularz. Formularz to jedno pole tekstowe z podpowiedzią przypominającą, żeby podać imię i e-mail. Sporo wiadomości przychodzi bez jednego i bez drugiego, a wiadomość bez adresu zwrotnego to lead, na którego nie da się odpowiedzieć. Narzędzie deklaruje name, email i website jako nazwane wejścia obok wiadomości, więc agent wypełniający wywołanie ma dla nich oczywiste miejsce.

Wartość zwracana daje agentowi coś, na czym może zadziałać. Callback wykonujący może rozwiązać się czymkolwiek, a executeTool podaje agentowi łańcuch znaków, który ten czyta. Kiedy wiadomość przychodzi bez adresu e-mail, nasza mówi o tym wprost i prosi agenta, żeby adres zdobył i wysłał drugą wiadomość. Potwierdzenie mówiące tylko „wysłano" wyrzuca jedyną szansę na naprawę wywołania, dopóki odwiedzający jeszcze tam jest.

Agent dzieli budżet wysyłek z formularzem. Formularz pozwala na trzy wiadomości na sesję przeglądania, liczone w sessionStorage. Narzędzie czyta i zapisuje ten sam licznik, więc agent i odwiedzający pracujący na tej samej stronie mają trzy na spółkę, a nie po trzy każde. Wymagało to zmiany w formularzu, który wcześniej odczytywał licznik raz przy ładowaniu strony i trzymał go w zmiennej. Kopia w pamięci daje każdej powierzchni własny budżet i pozwala tej, która zapisze ostatnia, cofnąć drugą, a to rodzaj błędu, który pojawia się dopiero wtedy, gdy istnieje druga powierzchnia.

Endpoint jest ten sam, na który formularz już wysyła. Nazwane pola są składane w treść wiadomości przed wyjściem żądania, więc istniejący handler nie wymagał żadnych zmian, żeby je odczytać, a ładunek niesie pole source, dzięki czemu wiadomości wysłane przez agenta da się liczyć osobno od wpisanych ręcznie, bez parsowania prozy.

Jak zobaczyć, że to działa

Ten serwis serwuje token próby, więc nic nie trzeba włączać. Otwórz tu dowolną stronę w Chrome od 149 do 156, a panel wcześniej w tym artykule powie Ci, czy Twoja przeglądarka ma to narzędzie, a przycisk pod nim wywoła je naprawdę.

Żeby sprawdzić to samodzielnie, zapytaj przeglądarkę, jakie narzędzia jej zaoferowano:

const mc = document.modelContext || navigator.modelContext;
const tools = await mc.getTools();
console.log(tools.map(t => t.name));
// ["contact_wislr"]

W Chrome 151 obie nazwy jeszcze się rozwiązywały, bo to alias w swoim ostatnim kamieniu milowym. W Chrome 152 i nowszych odpowiada wyłącznie document.modelContext.

W serwisie, który nie zapisał się do próby, document.modelContext jest niezdefiniowane i nic z tego się nie wykona. Uruchomienie Chrome z --enable-blink-features=WebMCP włącza to API lokalnie i tak właśnie pracuje się nad nim, zanim token istnieje.

Jedną różnicę między specyfikacją a implementacją warto poznać, zanim kosztuje Cię popołudnie. IDL typuje drugi argument executeTool jako obiekt, a przekazanie obiektu kończy się błędem UnknownError: Failed to parse input arguments, który nie mówi ani który argument, ani dlaczego. Chrome chce argumentów w postaci zserializowanej:

await mc.executeTool(tool, JSON.stringify({ message: "How do you measure AI referrals?" }));

getTools() odpowiada tak samo. inputSchema w zwróconym narzędziu przychodzi jako łańcuch JSON, a nie jako zarejestrowany obiekt, więc cokolwiek go odczytuje, musi najpierw sparsować.

Na tej samej stronie siedzą bardziej użyteczne rzeczy

Od zapisu warto zacząć, bo endpoint, ścieżka zgody i mail potwierdzający już istnieją. Jest to też najmniejsza rzecz na stronie warta udostępnienia.

Kandydatem jest każda interakcja, którą odwiedzający wykonuje ręcznie, a te na kilka kroków zyskują najwięcej na sprowadzeniu do jednego wywołania.

Narzędzia tylko do odczytu to bezpieczniejszy początek. Ustawienie readOnlyHint: true na narzędziu wyszukiwania albo dostępności mówi agentowi, że wywołanie niczego nie zmienia, a pomyłka kosztuje zmarnowane zapytanie, a nie rekord zapisany w Twojej bazie.

Cokolwiek stoi za uwierzytelnianiem, zostaje za uwierzytelnianiem. Zarejestrowane narzędzie działa w stronie z tą sesją, którą odwiedzający już ma, więc get_order_status jest chronione dokładnie tak samo jak strona konta, z której czyta, i ani trochę bardziej.

Nic z tego nie zmienia powodu, dla którego zbudowano popup

Narzędzie uruchamia się dopiero po tym, jak ktoś o coś poprosił. Powiedział swojemu asystentowi, żeby zdobył zniżkę, a asystent znalazł funkcję, która to robi. Ta osoba i tak oddałaby adres którąkolwiek drogą, jaką byś jej dał.

Popup celuje w osobę odwrotną. W kogoś, kto niczego nie postanowił i jest w drodze do wyjścia, złapanego przez licznik czasu albo przez ruch myszy w stronę przycisku wstecz. Zasługuje na swoje miejsce, konwertując ludzi, którzy konwertować nie zamierzali, i to jest jedyny powód, dla którego zespół godzi się irytować wszystkich pozostałych, żeby ich zdobyć.

Wyłączenie popupu dla ruchu agentowego nic więc nie kosztuje, bo ci odwiedzający nigdy nie byli jego celem. Skasowanie go dla wszystkich oddaje adresy, do których łapania go zbudowano, razem z latami maili, które z nich płyną.

Zespoły marketingu rozlicza się z tego, jak szybko rośnie lista i ile przychodu przynoszą maile cyklu życia. WebMCP nie rusza żadnej z tych liczb. Daje chętnemu odwiedzającemu czystszą drogę i zostawia powód przerwania nietknięty.

Resztę rozstrzyga wsparcie. Wyłącznie Chromium, w testach kończących się na Chrome 156, przy sprzeciwie Apple. Zastąpienie formularza zapisu narzędziem usunęłoby drogę, z której korzysta prawie każdy odwiedzający, w zamian za taką, która działa w ułamku jednej przeglądarki.

Na razie jest to dodatkowe wejście. Popup odpala się rzadziej, w miarę jak coraz więcej wizyt przychodzi przez asystentów, i znika zupełnie w dniu, w którym zbieranie adresu przestaje się opłacać. Żadna specyfikacja nie przybliży tego dnia.

Otwarty zapis to sposób, w jaki ludzi zasypuje poczta

Narzędzie zapisu przyjmuje adres e-mail, którego nie może sprawdzić, i wysyła na niego pocztę. Każdy, kto potrafi sterować agentem, może wycelować go w dowolną skrzynkę. Twój formularz ma tę samą dziurę, bo pod jednym i drugim stoi publiczny adres, na który skrypt może wysłać żądanie, nigdy nie ładując Twojej strony.

Ten atak ma nazwę. W przebiegu list bombingu adres jednej ofiary zostaje zgłoszony naraz do setek albo tysięcy serwisów, po jednym żądaniu do każdego. Każdy serwis widzi pojedynczy, niewyróżniający się zapis i nigdzie nic nie wygląda źle. Ofiara dostaje tysiące maili potwierdzających w ciągu godziny, a ten zalew zwykle przykrywa coś innego przychodzącego do tej samej skrzynki: alert o oszustwie z banku, reset hasła, potwierdzenie zakupu, który ktoś zrobił jej kartą. Twoja reputacja nadawcy też obrywa, a to najmniejsza część tego, co się stało.

Taki kształt pokonuje obronę, po którą sięga większość ludzi. Limit żądań liczy żądania, a przebieg, który wysyła Ci dokładnie jedno żądanie, nie daje mu czego liczyć.

Cztery rzeczy pomagają.

Postaw wyzwanie przed zapisem, żeby zautomatyzowane zgłoszenie musiało przejść coś, co prawdziwa osoba pokonuje, nawet tego nie zauważając.

Odsiewaj duplikaty po adresie i prowadź listę wykluczeń, żeby tej samej skrzynki nie dało się zapisywać w kółko, a drugie żądanie dla adresu z już oczekującym potwierdzeniem nie wysyłało zupełnie niczego.

Proś ludzi o potwierdzenie, zanim dodasz ich do listy, żeby nadużyte wywołanie nie mogło stworzyć subskrypcji. Jedno zastrzeżenie, na którym ludzie się przejeżdżają: w świetle kanadyjskiego prawa antyspamowego mail potwierdzający sam w sobie liczy się jako wiadomość handlowa, więc wysłanie go na adres, który o nic nie prosił, jest naruszeniem, a nie ochroną. Sądy niemieckie podzieliły się w tej samej sprawie. Potwierdzenie jest właściwym domyślnym rozwiązaniem w większości miejsc i nie jest rozwiązaniem uniwersalnym.

Zapisuj, skąd wziął się każdy zapis, w chwili tworzenia wiersza. Ustalanie tego po incydencie oznacza zgadywanie, które adresy były prawdziwe.

Wykazanie zgody jest trudniejsze, gdy klikało oprogramowanie

Wysłanie formularza tworzy zapis tego, co odwiedzający widział. Checkbox, etykieta obok niego, link do polityki prywatności i znacznik czasu siedzą po Twojej stronie.

Wywołanie narzędzia tworzy adres e-mail w argumencie funkcji. To, co powiedziano odwiedzającemu, zanim agent zadziałał, wydarzyło się w rozmowie, do której nie masz dostępu. Zgodnie z RODO zgoda musi być dobrowolna, konkretna, świadoma i jednoznaczna, a administrator musi umieć ją później wykazać. Adres przychodzący przez agenta sam z siebie nie spełnia żadnego z tych warunków.

Podwójne potwierdzenie niesie tu drugi raz większość ciężaru. Mail potwierdzający idzie na sam adres, a jego kliknięcie tworzy oznaczone czasem działanie subskrybenta, a nie czegoś działającego w jego imieniu. Trzymaj zapisy pośredniczone przez agenta w bazie tak, żeby dało się je rozróżnić, i żeby audyt mógł oddzielić je od wysyłek formularza, zamiast traktować całą listę jako jedno pochodzenie.

Te zapisy giną po cichu, więc najpierw zbuduj liczenie

Agent wywołujący zarejestrowane narzędzie wykonuje callback wewnątrz strony. Nie ma odsłony strony, nie ma zdarzenia wysłania formularza, a często nie ma w ogóle sesji w tym sensie, w jakim rozumie ją analityka przeglądarkowa. Konwersja się dzieje, subskrybent jest prawdziwy, a raport nie pokazuje niczego. Ustaw to źle, a awaria będzie cicha: subskrybentów przybywa, żadne źródło ich nie tłumaczy i nic w interfejsie nie wygląda na zepsute.

To ta sama luka strukturalna, która ukrywa przed analityką przeglądarkową crawlery AI i odesłania z AI, tyle że przychodząca na nowej warstwie. Crawler nigdy nie wykonuje JavaScriptu, który by go zgłosił. Agent JavaScript wykonuje i wykonuje tę część, która domyka konwersję, pomijając każdą część, która by ją zmierzyła.

Żądanie uderzające w Twój endpoint zapisu to jedyne miejsce, w którym konwersja istnieje w postaci należącej do Ciebie. Oznacz je tam, w logach własnych, a kanał stanie się czymś, czego rozmiar zmierzysz w następnym kwartale.

Cztery rzeczy, które nie pozwolą im zginąć

Stempluj źródło na serwerze, w tym samym zapisie, który tworzy subskrybenta. Strona wysyła z żądaniem pole źródła, a serwer kładzie je w wierszu obok adresu i znacznika czasu. Ustalanie tego później z brzmienia wiadomości to zgadywanie, a referrer Cię nie uratuje, bo agenci często nie wysyłają go wcale.

Zgłaszaj zapis przed wywołaniem sieciowym, a nie w obsłudze sukcesu. Wywołanie porzucone w pół drogi albo takie, które przepada po tym, jak serwer już wykonał robotę, nigdy nie dociera do gałęzi sukcesu. Zgłoś je na wyjściu, a policzysz próbę, czyli tę liczbę, o którą naprawdę Ci chodzi.

Utwórz zdarzenie w swoim narzędziu analitycznym, zanim wypuścisz narzędzie. Zdarzenia własne bywają powszechnie przyjmowane, a potem wyrzucane z każdego raportu, dopóki nie istnieje cel o pasującej nazwie, więc niezarejestrowane zdarzenie zwraca kod sukcesu i nie pokazuje się nigdzie. Cisza w panelu nie jest dowodem, że nic się nie odpaliło, i jest to najprostszy sposób na spędzenie tygodnia nad debugowaniem kodu, który przez cały czas działał.

Uzgadniaj raz w tygodniu, celowo. Policz w swoich danych wiersze niosące źródło agentowe, a potem porównaj to z tym, co Twoja analityka pokazuje za te same dni. Dwie zgadzające się liczby znaczą, że rura jest szczelna. Różnica to rozmiar Twojego martwego pola. Ruch po jednej stronie i zero po drugiej znaczy, że zdarzenie w ogóle nie dociera, a wiesz o tym po tygodniu, a nie na koniec kwartału.

Co z tym zrobić w tym kwartale

Zarejestrowanie jednego narzędzia zajmuje popołudnie. Zacznij od oferty, dla której już przerywasz ludziom, bo endpoint, ścieżka zgody i mail potwierdzający są zbudowane i działają.

Zostaw formularz. Prawie każdy odwiedzający dalej z niego skorzysta i pozostanie to prawdą tak długo, jak długo Apple trzyma swoje stanowisko.

Używaj document.modelContext i zapisz się do próby Chrome, jeśli chcesz, żeby do narzędzia sięgali zwykli odwiedzający, a nie deweloperzy z włączoną flagą.

Dodaj pole źródła do swojego endpointu zapisu, zanim narzędzie trafi na produkcję. Zrobienie tego później oznacza, że nie odróżnisz, które z zapisów już siedzących w Twojej bazie przyszły od agenta.

Odczytuj wyniki z własnego serwera. Usługa analityczna w ogóle nie pokaże Ci tych zapisów, a nic w niej nie wygląda na zepsute, kiedy pozostają niepoliczone.

Liczba warta obserwowania to żadna z powyższych. To udział Twoich wizyt przychodzących przez asystenta, który rozstrzyga, kiedy to przestaje być eksperymentem, a zmierzysz go ze swoich logów już dziś, niezależnie od tego, czy kiedykolwiek zarejestrujesz narzędzie.