Чи покладе WebMCP край модальним вікнам розсилки & знижок? Сподіваємося, так. Ми зареєстрували таке вікно на своєму сайті, щоб дізнатися.

Ви натискаєте посилання, сторінка починає завантажуватися, і спливне вікно наїжджає на неї ще до того, як ви прочитали речення. Десять відсотків знижки, якщо віддасте адресу електронної пошти компанії, до якої потрапили дев’ять секунд тому. Ви його закриваєте. Десь нижче чекає друге, на той момент, коли ви поведете курсор до кнопки назад.

Це спливне вікно не є провалом дизайну. Воно робить рівно те, для чого його побудували, і працює достатньо добре, щоб ніхто в маркетинговій команді не наполягав на його видаленні.

Адреса електронної пошти це ключ до програми утримання. Щойно бренд її отримує, він може запускати ті ланцюжки життєвого циклу, що стоять за кожною платформою електронної комерції: вітальну серію, яка спрацьовує на підписку, лист про покинутий перегляд, що йде, коли хтось подивився товар і пішов, послідовність про покинутий кошик і покинуте оформлення замовлення, післяпродажні нагадування та нагадування про повторну покупку, повернення для всіх, хто затих. Жоден із них без адреси не стартує. Усі вони запускаються поведінкою і далі приносять гроші ще довго після того, як реклама, що привела відвідувача, вже оплачена.

Саме це купують десять відсотків. Знижка це ціна постійної лінії зв’язку, і вона дешева поруч із платним кліком, який вас привів. Тригерні ланцюжки заробляють на одного отримувача набагато більше, ніж масова розсилка, а послідовність про покинутий кошик заробляє найбільше з усіх, тож маркетолог, який рахує цінність адреси, рахує не один лист. Він рахує їхній потік, що триває роками.

Це також пояснює таймінг. Спливне вікно спрацьовує на вході, на глибині прокрутки або на першій ознаці того, що ви прямуєте до кнопки назад, бо відвідувач, який пішов, не залишивши адреси, недосяжний назавжди, а відвідувач, який її залишив, це початок послідовності. Бренд, який збирає адреси у трьох відсотків відвідувачів, купує чудову угоду ціною роздратування решти дев’яноста семи.

WebMCP нічого з цього не чіпає. Він змінює механізм. Сторінка може опублікувати свою підписку як функцію, описати звичайною мовою, що вона робить, і дозволити AI-агенту, який працює на відвідувача, викликати її тоді, коли відвідувач справді попросить пропозицію. Адреса все одно приходить, знижка все одно надсилається, і ніщо не перериває читання.

Для того, хто читає, у цьому й полягає весь виграш. Питання в тому, яку його частину можна отримати сьогодні, і чесна відповідь це лише скибка.

Як відвідувач переживає зникнення спливного вікна

Ось та сама пропозиція, зібрана двома способами. Ліворуч те, що відвідувач отримує сьогодні. Праворуч те, що та сама людина отримує, коли сторінка опублікувала свою підписку як дію, яку може виконати її асистент.

Спливному вікну кладе край зміна трафіку

Дехто в бренді залюбки прибрав би спливне вікно зовсім. Воно лишається, бо переривати людей це єдиний метод, який надійно збирає адреси електронної пошти, а ціну цього переривання платить відвідувач, а не команда, яка його обрала. Усі, хто читає, отримують гірший досвід заради того, щоб малий відсоток із них віддав адресу, і ця угода тримається близько двадцяти років, бо ніщо інше не збирало адреси так само добре.

Ця угода ламається лише тоді, коли другий метод починає збирати ті самі адреси без переривання, і ламається вона по одному візиту за раз.

Спливне вікно працює лише на людині, яка дивиться в екран. Коли читає асистент, немає екрана, який можна накрити, і немає вагання, під яке можна підлаштувати таймер, тож такий візит не дає жодних адрес, хоч би як добре було налаштоване вікно.

Той самий візит усе одно може дати адресу. Людина, яка просить у свого асистента знижку, віддає адресу добровільно, разом з іменем, у той момент, коли сама цього захотіла. Ця адреса чистіша, намір за нею сильніший, і на її отримання не витрачено ані краплі прихильності.

Маркетингова команда тримає спливне вікно доти, доки воно окупається. Що більше візитів приходить через асистентів, то меншій аудиторії спрацьовує вікно і то менша віддача, тоді як роздратування, яке воно спричиняє, лишається сталим. Той самий розрахунок, який поставив його на сторінку, зрештою його звідти й прибере.

Ніщо з цього не приходить за графіком, яким керує специфікація. Це приходить тоді, коли достатньо людей читають веб через щось, що читає замість них, а це питання трафіку, а не стандартів, і виміряти його у власних логах можна вже сьогодні.

Варто сказати прямо: пункт призначення хороший. Веб, у якому пропозиція доступна кожному, хто про неї просить, і невидима для всіх інших, кращий для читача і не гірший для бренду. Це рідке поєднання, і саме тому під це варто будувати рано, а не чекати, поки набереться охоплення.

Заперечення Apple полягає в тому, що сайт ніколи не має знати, що ним керує агент

Двоє інженерів Apple виклали заперечення WebKit у публічній гілці про позиції щодо стандартів у червні 2026 року, і 11 червня позицію було ухвалено як заперечення. Вони наводять шість причин, і перша стосується того, чим є агент.

Позиція WebKit полягає в тому, що агент, який діє від імені користувача, це “фактично допоміжна технологія: він має працювати із сайтом так, як працював би користувач, і сайт не повинен виокремлювати його для іншого поводження”. WebMCP робить протилежне. Він перетворює факт “керує агент” на спостережуваний, а щойно до цього можна звертатися окремо, ніщо не тримає обидві поверхні в паритеті. Сайт може дати агентам можливості, яких не дає власному інтерфейсу, або приховати їх від агентів, і це вони описують як “проблему блокування зчитувачів екрана, тільки застосовану до AI-агентів”.

Вони сумніваються і в обіцянці надійності. Агент усе одно обирає інструмент, читаючи його назву та опис, а специфікація сама визнає їх неоднозначними й такими, що не піддаються перевірці, бо “немає гарантії, що заявлений намір інструмента WebMCP збігається з його фактичною поведінкою”. Типізована схема фіксує форму аргументу, а не значення, яке агенту доводиться вгадувати, тож у їхньому прочитанні крихкість не зникає, а переїжджає зі сторінки в описи інструментів.

Заперечення щодо приватності гостріше за звичне. Сайт може просити більше параметрів, ніж йому потрібно, а послужливий агент заповнює їх тим, що користувач розповів агенту, а не сайту. Специфікація у власному тексті називає це конвеєром “від персоналізації до фінгерпринтингу”.

Вони також зазначають, що частини, потрібні рецензенту, щоб про все це судити, зокрема аналіз міждоменної безпеки та механізм згоди, досі позначені як робота, яку ще треба зробити, і що група, створена навколо машинного навчання, це неправильне місце для змін, справжня домівка яких це HTML і семантика доступності.

Один із заявлених ними інваріантів прямо вказує на тему цієї статті: “Частина користувачів не буде або не зможе користуватися агентами, тож результат має бути корисним усім користувачам і не повинен давати переваги тим, у кого агент є”.

Поставте це поруч із патерном у коді вище. Придушення спливного вікна залежить від того, що сторінка дізнається про дію агента, а це саме та спостережуваність, якої, за аргументами Apple, бути не повинно. Тихий досвід, описаний раніше, купується сигналом, який другий рушій вважає таким, що веб не має його розкривати. Обидві ці речі можуть бути правдою, і кожен, хто на цьому будує, має розуміти, що обирає сторону, а не бере готовий усталений інструмент.

Редактори з Google відповіли в тій самій гілці й запитали, що задовольнило б WebKit, окрім видалення імперативного API. У відповідь прозвучало, що вони не відповідатимуть по пунктах, бо кожне запитання припускає, що підхід сам по собі здоровий, і було запропоновано почати спочатку: нова community group, спершу визначення проблеми і лише потім рішення, та воркшоп навколо TPAC наприкінці жовтня 2026 року.

Жоден iPhone цього не запустить, включно з Chrome для iPhone

Позиція Apple це не лише голос у гілці про стандарти. Вона вирішує долю цієї можливості для кожного браузера на платформі.

Кожен браузер, що постачається на iOS сьогодні, рендерить через WebKit. Chrome для iPhone це рушій Safari, вдягнений в інтерфейс Google, і те саме стосується Edge, Firefox та решти. Тож можливість, яку WebKit відмовляється реалізувати, недоступна на iPhone, хоч би на яку іконку браузера хтось натиснув.

Це може змінитися, повільно. Британська Competition and Markets Authority визнала вимогу Apple щодо рушія порушенням режиму Strategic Market Status, план приведення у відповідність мав з’явитися в червні 2026 року, а зміни очікуються в iOS 20 восени 2026 року, перед повною відповідністю в січні 2027 року. Digital Markets Act ЄС дозволяє альтернативні рушії з 2024 року. На практиці жоден із цих актів рушія не дав: жоден виробник браузерів не випустив альтернативний рушій через App Store, а Google і Mozilla мають порти, які так і лишаються невипущеними.

Для бренду електронної комерції це число важить більше за будь-яку дату в специфікації, бо трафік з iPhone це велика частка більшості магазинів, і сьогодні жодна його частина до зареєстрованого інструмента не дістається.

Перевірка означає браузер на Chromium, а саме ним більшість агентів уже й користується

Агенти, які читають, уже сидять на потрібному рушії. Claude працює як розширення всередині Chrome, Gemini вбудований у Chrome, Copilot живе в Edge, а Comet від Perplexity це власний браузер на Chromium. Агентний перегляд на десктопі сьогодні переважно на Chromium, тож рушій рідко буває перешкодою.

Перешкода, яку люди пропускають, полягає в тому, що не кожен асистент, який читає вашу сторінку, взагалі є браузером. Попросіть ChatGPT чи Claude у вікні чату відкрити URL, і завантаження зазвичай відбувається на сервері: ваш HTML отримано, JavaScript не виконується, і перелік інструментів ніколи не будується. Такий асистент може прочитати кожне слово вашої сторінки і все одно не мати уявлення, що на ній зареєстровано інструмент. Інструмент бачить лише агент, який працює всередині справжньої сторінки на Chromium, а сьогодні це означає щось на кшталт Gemini у Chrome або розширення, що саме реалізує виявлення.

Перешкода в тому, що можливість досі за воротами, і крізь ці ворота є два шляхи.

Сайт реєструється в origin trial від Chrome і віддає токен. Це шлях для бойового магазину, і він складається з трьох кроків.

Зареєструйте походження за адресою developer.chrome.com/origintrials/#/register_trial/4163014905550602241, це і є тестування WebMCP, і воно триває з Chrome 149 до Chrome 156. Вкажіть те походження, яке справді віддає ваші сторінки, включно із субдоменом, бо токен, виданий для example.com, не покриває www.example.com. Якщо ваш кореневий домен перенаправляє на www, зареєструйте хост www і пропустіть збіг за субдоменами, оскільки перенаправлення ніколи не завантажує документ, а отже, ніколи не потребує токена.

Віддавайте токен, який вам видали, або заголовком відповіді, або метатегом у head кожної сторінки, що реєструє інструмент:

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

Виводьте його лише тоді, коли він у вас є. Порожній або прострочений токен пише помилку в консоль на кожному завантаженні сторінки, тож зробіть тег умовним, а не вставляйте порожній атрибут і забувайте про нього.

Edge проводить окреме тестування з власною реєстрацією і власним токеном. Реєстрація в одному нічого не дає для іншого.

Або відвідувач вмикає це сам, запустивши Chrome із --enable-blink-features=WebMCP чи увімкнувши експериментальні функції вебплатформи в chrome://flags. Це шлях розробника, а не покупця.

Ця сторінка йде першим шляхом. Кожна сторінка цього сайту віддає токен origin trial для WebMCP, тож відвідувач, який приходить у Chrome від 149 до 156, отримує document.modelContext без жодних перемикачів, і панель вище про це скаже. Цей токен спливає 17 листопада 2026 року, після чого інструмент затихає для звичайних відвідувачів, доки тестування не продовжать або можливість не випустять, а форма працює далі, як і завжди. Кожен, хто у Safari, у будь-якому браузері на iPhone або в Chrome поза цим діапазоном версій, бачить форму і більше нічого.

Старі туторіали не працюватимуть, і в більшості з них неправильна дата

WebMCP це не завершений вебстандарт. Це чернетка, яку редагують інженери Google і Microsoft, а чернетки змінюються тоді, коли на них уже щось будують. Ця змінилася так, що ламає код.

Назва, яку ви викликаєте, переїхала. Раніше це було navigator.modelContext, а тепер document.modelContext. Chrome якийсь час приймав обидві назви й попереджав розробників у консолі, а потім перестав приймати стару в Chrome 152, який дійшов до всіх 25 серпня 2026 року. Код, написаний по-старому, не сповільнюється і не деградує. Він зупиняється.

Ми звертаємо на це увагу, бо публікації розходяться щодо того, коли це сталося. Кілька з них відносять зміну до серпня 2026 року. Власна історія проєкту відносить її до травня, на три місяці раніше:

Використовуйте document.modelContext. Туторіал, який тягнеться до navigator, писали під те, чого вже не існує, а дата з допису в блозі варта менше за ту саму дату з власної історії комітів проєкту.

Підтримка це Chromium і нічого більше. Chrome відкрив публічне тестування в червні 2026 року, яке триває до Chrome 156. Edge проводить власне з Edge 150, а Brave має це експериментально, і обидва побудовані на рушії Chrome. Apple офіційно виступила проти пропозиції 11 червня 2026 року. Mozilla не стала на жоден бік і тримає відкритим прототип.

Інструмент це функція плюс слова, які кажуть асистенту, коли нею скористатися

Інструмент це словник із назвою, описом, вхідною схемою JSON і колбеком виконання. Назва приймає від 1 до 128 буквено-цифрових символів ASCII плюс підкреслення, дефіс і крапку. Вимога безпечного контексту поширюється на весь інтерфейс, включно з getTools і executeTool, а доступ регулює функція Permissions Policy під назвою tools, чий типовий список дозволів це 'self'.

Опис важить більше за назву. Агент обирає між інструментами, читаючи описи, тож опис, написаний для журналу змін розробника, програє тому, який написано для людини, що ухвалює рішення.

Щоб описати підписку як інструмент, потрібно близько тридцяти рядків

Патерн має дві половини. Зареєструйте пропозицію як інструмент і навчіть модальне вікно відступати, щойно пропозицію прийнято.

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.";
    }
  });
}

Спливне вікно затихає в ту саму мить, коли спрацьовує інструмент, і в цьому весь сенс усього цього.

Прапорець живе лише цей візит, і це навмисно. Вимкнути спливне вікно назавжди ще до того, як хтось натиснув посилання підтвердження, означає забрати підписку у відвідувача, чия адреса так і не була підтверджена, і не лишити йому жодного способу підписатися. Заглушіть вікно на час візиту зі сторінки. Зробіть це назавжди зі свого сервера, щойно натиснуто підтвердження.

annotations: { readOnlyHint: false } каже агенту, що виклик щось змінює, а не щось читає. Це вже й так типова поведінка, а виписаний рядок ставить наступного читача за один рядок від untrustedContentHint, і саме ця анотація важлива для будь-якого інструмента, що повертає текст, за яким агент діятиме.

signal це сигнал скасування, який браузер передає кожному інструменту, що запускає. Передача його в запит означає, що агент, який здався на півдорозі, не лишає підписку допрацьовувати за того, хто вже перестав про неї просити.

Немає способу запитати сторінку, чи спостерігає за нею агент. Специфікація пропонує getTools, executeTool і подію toolchange, і жоден із них на це питання не відповідає. Виклик вашого власного інструмента це єдиний надійний сигнал, який ви отримуєте. Записуйте той самий прапорець, який ваше спливне вікно вже перевіряє, і воно перестане спрацьовувати для цього відвідувача так само, як перестає після заповнення форми.

Версія, що працює на цій сторінці

Цей сайт реєструє один інструмент під назвою contact_wislr, і він працює з моменту публікації цієї статті. Контактна форма на цьому сайті відкривається за кліком, а не спрацьовує на намір піти, тож інструмент тут не прибирає переривання. Він прибирає набирання тексту.

Три рішення в цій реалізації варто скопіювати.

Схема просить більше, ніж форма. Форма це одне текстове поле з підказкою, яка нагадує вказати ім’я та пошту. Багато повідомлень приходить без того й без того, а повідомлення без адреси для відповіді це лід, на який неможливо відповісти. Інструмент оголошує name, email і website як іменовані входи поруч із повідомленням, тож агент, який заповнює виклик, має очевидне місце, куди їх покласти.

Повернуте значення дає агенту, на що спиратися. Колбек виконання може повернути будь-що, а executeTool віддає агенту рядок, який той читає. Коли повідомлення приходить без адреси електронної пошти, наш інструмент про це каже і просить агента її отримати й надіслати друге повідомлення. Підтвердження, яке каже лише “надіслано”, викидає єдиний шанс виправити виклик, поки відвідувач ще тут.

Агент ділить із формою бюджет відправлень. Форма дозволяє три повідомлення на сесію перегляду, і лічильник живе в sessionStorage. Інструмент читає й пише той самий лічильник, тож агент і відвідувач, які працюють з однією сторінкою, мають три на двох, а не по три кожен. Це потребувало зміни у формі, яка раніше читала лічильник один раз під час завантаження сторінки й тримала його у змінній. Кешована копія дає кожній поверхні власний бюджет і дозволяє тій, що записала останньою, відкотити іншу, а це той тип помилки, який виникає лише тоді, коли з’являється друга поверхня.

Ендпоїнт той самий, куди вже відправляє форма. Іменовані поля збираються в тіло повідомлення перед відправленням запиту, тож наявному обробнику не знадобилося змін, щоб їх прочитати, а корисне навантаження несе поле source, щоб повідомлення, надіслані агентом, можна було рахувати окремо від набраних вручну, не розбираючи текст.

Як побачити це в дії

Цей сайт віддає токен тестування, тож нічого вмикати не треба. Відкрийте будь-яку сторінку тут у Chrome від 149 до 156, і панель раніше в цій статті скаже вам, чи має ваш браузер інструмент, а кнопка під нею викличе його по-справжньому.

Щоб перевірити самостійно, запитайте браузер, які інструменти йому запропоновано:

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

У Chrome 151 ще працювали обидві назви, і це остання віха, де жив псевдонім. У Chrome 152 і новіших відповідає лише document.modelContext.

На сайті, який не зареєструвався в тестуванні, document.modelContext є undefined і нічого з цього не працює. Запуск Chrome із --enable-blink-features=WebMCP вмикає API локально, і саме так під нього розробляють, поки токена ще немає.

Одну розбіжність між специфікацією і реалізацією варто знати, перш ніж вона з’їсть у вас пів дня. IDL типізує другий аргумент executeTool як об’єкт, а передача об’єкта падає з UnknownError: Failed to parse input arguments, і це не каже, який саме аргумент і чому. Chrome хоче аргументи серіалізованими:

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

getTools() відповідає так само. inputSchema на поверненому інструменті приходить як рядок JSON, а не як зареєстрований об’єкт, тож усе, що його читає, спершу мусить його розібрати.

На тій самій сторінці лежать корисніші речі

Починати варто з підписки, бо ендпоїнт, потік згоди й лист підтвердження вже існують. Це також найменша річ на сторінці, яку варто відкривати.

Кандидатом є кожна взаємодія, яку відвідувач виконує руками, а найбільше виграють ті, що займають кілька кроків і зводяться до одного виклику.

Інструменти лише для читання це безпечніший початок. Встановлення readOnlyHint: true для інструмента пошуку або наявності каже агенту, що виклик нічого не змінює, і помилка коштує змарнованого запиту, а не запису, внесеного до вашої бази даних.

Усе, що за автентифікацією, за нею й лишається. Зареєстрований інструмент працює на сторінці з тією сесією, яку відвідувач уже має, тож get_order_status захищений рівно так само, як сторінка акаунта, з якої він читає, і не більше.

Ніщо тут не змінює причини, з якої спливне вікно збудували

Інструмент спрацьовує лише після того, як хтось про щось попросив. Людина сказала своєму асистенту отримати знижку, і асистент знайшов функцію, яка це робить. Ця людина віддала б адресу будь-яким шляхом, який ви їй дали б.

Спливне вікно націлене на протилежну людину. На того, хто нічого не вирішив і вже прямує до виходу, спійманого таймером або рухом миші до кнопки назад. Воно заслуговує своє місце тим, що конвертує людей, які конвертуватися не збиралися, і це єдина причина, чому команда погоджується дратувати всіх інших заради них.

Отже, вимкнення спливного вікна для агентного трафіку не коштує нічого, бо ці відвідувачі ніколи не були його ціллю. Видалення його для всіх віддає адреси, які воно було збудоване ловити, разом із роками листів, що з них живляться.

Маркетингові команди міряють тим, як швидко росте список і скільки виручки приносять листи життєвого циклу. WebMCP не рухає жодного з цих чисел. Він дає охочому відвідувачу чистіший шлях і лишає причину переривання недоторканою.

Решту вирішує підтримка. Лише Chromium, у тестуваннях, що завершуються на Chrome 156, і Apple проти. Замінити форму підписки інструментом означало б прибрати шлях, яким користується майже кожен відвідувач, в обмін на той, що працює в частині одного браузера.

Наразі це додатковий вхід. Спливне вікно спрацьовує тим рідше, чим більше візитів приходить через асистентів, і зникає повністю того дня, коли збирання адрес перестане окупатися. Жодна специфікація не наблизить цей день.

Відкрита підписка це те, як людей засипають поштою

Інструмент підписки приймає адресу електронної пошти, яку не може перевірити, і надсилає на неї листи. Хто вміє керувати агентом, може навести його на будь-яку скриньку. У вашій формі та сама діра, бо за обома стоїть публічний URL, на який скрипт може надсилати запити, жодного разу не завантаживши вашу сторінку.

У цієї атаки є назва. Під час list bombing адресу однієї жертви подають на сотні або тисячі сайтів одночасно, по одному запиту на кожен. Кожен сайт бачить одну нічим не примітну підписку, і ніде нічого не виглядає дивним. Жертва отримує тисячі листів підтвердження за годину, і цей потоп зазвичай прикриває щось інше, що приходить у ту саму скриньку: сповіщення про шахрайство від банку, скидання пароля, чек за покупку, яку хтось зробив її карткою. Ваша репутація відправника теж отримує удар, і це найменша частина того, що сталося.

Така форма перемагає той захист, до якого більшість береться першим. Обмеження частоти рахує запити, а прогін, що надсилає вам рівно один запит, не дає йому чого рахувати.

Чотири речі таки допомагають.

Поставте перед підпискою перевірку, щоб автоматизоване відправлення мусило пройти те, що справжня людина долає, навіть не помітивши.

Дедуплікуйте за адресою і ведіть список виключень, щоб ту саму скриньку не можна було підписувати знову й знову, а другий запит для адреси, підтвердження для якої вже очікує, не надсилав нічого взагалі.

Просіть людей підтвердити, перш ніж додавати їх до списку, щоб зловжитий виклик не міг створити підписку. Одне застереження, на якому люди спотикаються: за канадським антиспамовим законом лист підтвердження сам по собі вважається комерційним повідомленням, тож надсилання його на адресу, яка ні про що не просила, це і є порушення, а не захист. Німецькі суди розійшлися в тому самому питанні. Підтвердження це правильний варіант за замовчуванням у більшості місць, але не універсальний.

Записуйте, звідки прийшла кожна підписка, у той самий момент, коли створюється рядок. Розбиратися з цим після інциденту означає вгадувати, які адреси були справжніми.

Довести згоду важче, коли клікала програма

Відправлення форми створює запис про те, що бачив відвідувач. Чекбокс, підпис поруч із ним, посилання на приватність і часова мітка лежать на вашому боці.

Виклик інструмента створює адресу електронної пошти в аргументі функції. Те, що відвідувачу сказали до дії агента, відбулося в розмові, до якої ви не маєте доступу. За GDPR згода має бути вільною, конкретною, поінформованою та однозначною, а контролер має вміти продемонструвати її згодом. Адреса, що приходить через агента, сама по собі не задовольняє нічого з цього.

Подвійне підтвердження вдруге бере на себе більшу частину ваги. Лист підтвердження йде на саму адресу, а клік по ньому створює дію з часовою міткою від самого підписника, а не від того, хто діє замість нього. Тримайте підписки через агента відрізнюваними у сховищі, щоб аудит міг відділити їх від відправлень форми, а не вважав увесь список одним походженням.

Ці підписки зникають тихо, тож спершу вбудуйте підрахунок

Агент, який викликає зареєстрований інструмент, виконує колбек усередині сторінки. Немає ні перегляду сторінки, ні події відправлення форми, ані часто взагалі сесії в тому сенсі, який має на увазі браузерна аналітика. Конверсія відбувається, підписник справжній, а звіт не показує нічого. Налаштуйте це неправильно, і збій буде безшумним: підписників більшає, жодне джерело їх не пояснює, і в інтерфейсі немає нічого, що виглядало б зламаним.

Це та сама структурна прогалина, що ховає AI-краулерів і AI-переходи від браузерної аналітики, тільки на новому рівні. Краулер ніколи не виконує JavaScript, який про нього повідомив би. Агент JavaScript виконує, і виконує саме ту частину, що завершує конверсію, оминаючи кожну частину, яка б її виміряла.

Запит, що приходить на ваш ендпоїнт підписки, це єдине місце, де конверсія існує у формі, якою ви володієте. Позначте її там, у логах першої сторони, і канал стане тим, що ви зможете оцінити наступного кварталу.

Чотири речі, які не дають їм зникнути

Ставте джерело на сервері, тим самим записом, який створює підписника. Сторінка надсилає поле джерела разом із запитом, а сервер кладе його в рядок поруч з адресою та часовою міткою. Розбиратися з цим потім за формулюванням повідомлення це вгадування, а реферер вас не врятує, бо агенти часто не надсилають його взагалі.

Повідомляйте про підписку до мережевого виклику, а не всередині обробника успіху. Виклик, покинутий на півдорозі, або такий, що впав після того, як сервер уже зробив роботу, до гілки успіху ніколи не дістається. Повідомляйте на виході, і ви порахуєте спробу, а саме це число вам і потрібне.

Створіть подію у своєму аналітичному інструменті ще до випуску інструмента. Кастомні події зазвичай приймаються, а потім випадають з усіх звітів, доки не з’явиться ціль із відповідною назвою, тож незареєстрована подія повертає код успіху й ніде не показується. Тиша в дашборді це не доказ того, що нічого не спрацювало, і це найпростіший спосіб витратити тиждень на дебаг коду, який увесь цей час працював.

Звіряйте раз на тиждень, свідомо. Порахуйте у власних даних рядки з джерелом агента, а потім порівняйте це з тим, що показує ваша аналітика за ті самі дні. Два числа, що збігаються, означають, що труба ціла. Розрив це розмір вашої сліпої зони. Трафік з одного боку і нуль з іншого означають, що подія взагалі не доходить, і тепер ви знаєте це за тиждень, а не наприкінці кварталу.

Що з цим робити цього кварталу

Реєстрація одного інструмента займає пів дня. Почніть із тієї пропозиції, заради якої ви вже перериваєте людей, бо ендпоїнт, потік згоди й лист підтвердження вже побудовані й працюють.

Лишіть форму. Майже кожен відвідувач усе одно нею скористається, і це лишатиметься правдою доти, доки Apple тримає свою позицію.

Використовуйте document.modelContext і зареєструйтеся в тестуванні Chrome, якщо хочете, щоб до інструмента дісталися звичайні відвідувачі, а не розробники з увімкненим прапорцем.

Додайте поле джерела до свого ендпоїнта підписки до випуску інструмента. Зробити це потім означає, що ви не зможете сказати, які з підписок, уже наявних у вашій базі, прийшли від агента.

Читайте результати з власного сервера. Аналітичний ресурс не покаже вам цих підписок узагалі, і ніщо в ньому не виглядатиме зламаним, доки вони лишаються непорахованими.

Число, за яким варто стежити, це жодне з наведених вище. Це частка ваших візитів, що приходять через асистента, і саме вона вирішує, коли це перестане бути експериментом, а виміряти її з логів можна вже сьогодні, зареєструєте ви колись інструмент чи ні.