WebMCP metterà fine al modal newsletter & sconto? Ce lo auguriamo. Ne abbiamo registrato uno sul nostro sito per scoprirlo.

Clicchi su un link, la pagina inizia a caricarsi e un popup ci scivola sopra prima che tu abbia letto una sola frase. Dieci per cento di sconto, se consegni un indirizzo email a un’azienda su cui sei arrivato nove secondi fa. Lo chiudi. Più in basso, un secondo popup aspetta il momento in cui ti muoverai verso il pulsante indietro.

Quel popup non è un fallimento di design. Sta facendo esattamente ciò per cui è stato costruito, e funziona abbastanza bene da far sì che nessuno nel team marketing chieda di rimuoverlo.

Un indirizzo email è la chiave del programma di retention. Una volta che un brand ne ha uno, può far girare i flussi del ciclo di vita che stanno dietro a ogni piattaforma ecommerce: la serie di benvenuto che parte all’iscrizione, l’email di abbandono della navigazione che parte quando qualcuno guarda un prodotto e se ne va, la sequenza di abbandono del carrello e del checkout, i promemoria post acquisto e di riacquisto, la riattivazione per chiunque sia rimasto in silenzio. Nessuno di questi può partire senza l’indirizzo. Tutti sono innescati dal comportamento e continuano a rendere molto dopo che l’annuncio che ha portato la visita è stato pagato.

È questo che compra il dieci per cento. Lo sconto è il prezzo di acquisto di una linea di contatto permanente, ed è poca cosa accanto al clic a pagamento che ti ha consegnato. I flussi innescati rendono molto di più per destinatario di quanto renda una newsletter inviata a tutti, e la sequenza del carrello abbandonato è quella che rende di più in assoluto, quindi chi fa marketing e calcola il valore di un indirizzo non sta contando una email. Ne sta contando un flusso che dura anni.

Spiega anche il tempismo. Il popup parte all’arrivo, alla profondità di scroll, o al primo segnale che stai puntando verso il pulsante indietro, perché chi se ne va senza lasciare un indirizzo è irraggiungibile per sempre, mentre chi lo lascia è l’inizio di una sequenza. Un brand che raccoglie indirizzi dal tre per cento delle visite fa un ottimo affare al costo di infastidire il restante novantasette.

WebMCP non tocca nulla di tutto questo. Quello che cambia è il meccanismo. Una pagina può pubblicare la propria iscrizione come funzione, descrivere in linguaggio semplice che cosa fa, e lasciare che l’agente AI al servizio di chi visita la chiami quando chi visita chiede davvero l’offerta. L’indirizzo arriva lo stesso, lo sconto viene comunque inviato e nulla interrompe la lettura.

Per chi legge, quello è tutto il premio. La domanda è quanta parte se ne possa incassare oggi, e la risposta onesta è una fetta.

Come chi visita vive la rimozione del popup

Ecco la stessa offerta, raccolta in due modi. A sinistra c’è quello che riceve oggi chi visita. A destra c’è quello che riceve la stessa persona quando la pagina ha pubblicato la propria iscrizione come qualcosa che il suo assistente può eseguire.

Quello che mette davvero fine al popup è un cambio nel traffico

Qualcuno nel brand toglierebbe del tutto il popup. Resta perché interrompere le persone è l’unico metodo che raccoglie indirizzi email in modo affidabile, e il costo di quell’interruzione ricade su chi visita e non sul team che l’ha scelta. Tutti quelli che leggono ottengono un’esperienza peggiore perché una piccola percentuale consegni un indirizzo, e lo scambio ha retto per circa vent’anni perché nient’altro raccoglieva indirizzi altrettanto bene.

Lo scambio si rompe solo quando un secondo metodo inizia a raccogliere gli stessi indirizzi senza l’interruzione, e si rompe una visita alla volta.

Un popup funziona solo su un essere umano davanti a uno schermo. Quando è un assistente a leggere, non c’è schermo da coprire né esitazione su cui regolare il timer, quindi quella visita non produce alcun indirizzo per quanto bene sia stato tarato il popup.

La stessa visita può comunque produrre un indirizzo. Chi chiede lo sconto al proprio assistente ne consegna uno volentieri, con un nome attaccato, nel momento in cui lo voleva. Quell’indirizzo è più pulito, l’intenzione dietro è più forte e non è stata spesa alcuna buona disposizione per ottenerlo.

Un team marketing tiene il popup finché rende. Man mano che più visite arrivano tramite assistenti, il popup parte davanti a un pubblico che si restringe per un ritorno che si restringe, mentre il fastidio che provoca resta costante. Lo stesso calcolo che lo ha messo sulla pagina prima o poi lo toglie.

Niente di tutto questo arriva secondo un calendario controllato da una specifica. Arriva quando abbastanza persone leggono il web attraverso qualcosa che legge per loro conto, il che è una questione di traffico e non di standard, ed è misurabile nei tuoi log già oggi.

Vale la pena dire chiaramente che la destinazione è buona. Un web in cui l’offerta è disponibile per chiunque la chieda e invisibile per tutti gli altri è migliore per chi legge e non peggiore per il brand. È una combinazione rara, ed è la ragione per cui vale la pena costruirci sopra presto invece di aspettare che arrivi la diffusione.

L’obiezione di Apple è che un sito non dovrebbe mai sapere che alla guida c’è un agente

Due ingegneri di Apple hanno esposto l’obiezione di WebKit nel thread pubblico delle standards positions durante giugno 2026, e la posizione è stata risolta come contraria l'11 giugno. Danno sei motivazioni, e la prima riguarda che cosa sia un agente.

La posizione di WebKit sostiene che un agente che agisce per un utente è “di fatto una tecnologia assistiva: dovrebbe usare un sito come lo userebbe l’utente, e il sito non dovrebbe riservargli un trattamento diverso.” WebMCP fa l’opposto. Rende “alla guida c’è un agente” un fatto osservabile, e una volta che quello è indirizzabile a parte nulla mantiene le due superfici alla pari. Un sito può dare agli agenti capacità che nega alla propria interfaccia, oppure negarle agli agenti, cosa che loro descrivono come “il problema del blocco degli screen reader, ma applicato agli agenti AI.”

Mettono in dubbio anche la promessa di affidabilità. Un agente sceglie comunque un tool leggendone nome e descrizione, che la specifica stessa ammette essere ambigui e non verificabili, senza “alcuna garanzia che l’intento dichiarato di un tool WebMCP corrisponda al suo comportamento reale.” Uno schema tipizzato fissa la forma di un argomento e non il significato che l’agente deve dedurre, quindi nella loro lettura la fragilità si sposta dalla pagina alle descrizioni dei tool invece di sparire.

L’obiezione sulla privacy è più tagliente del solito. Un sito può chiedere più parametri di quelli che gli servono, e un agente collaborativo li riempie con cose che l’utente ha detto all’agente e non al sito. La specifica chiama questo, nel proprio testo, un percorso che va “dalla personalizzazione al fingerprinting.”

Fanno notare inoltre che le parti di cui avrebbe bisogno un revisore per giudicare tutto questo, tra cui l’analisi di sicurezza cross-origin e l’aggancio al consenso, sono ancora indicate come lavoro da fare, e che un gruppo il cui mandato riguarda il machine learning è la sede sbagliata per modifiche la cui casa vera sono l’HTML e la semantica dell’accessibilità.

Uno degli invarianti che dichiarano punta esattamente a ciò di cui parla questo articolo: “Alcuni utenti non useranno, o non potranno usare, gli agenti, quindi il risultato deve giovare a tutti gli utenti e non deve privilegiare chi ne ha uno.”

Mettilo accanto allo schema del codice qui sopra. Sopprimere il popup dipende dal fatto che la pagina venga a sapere che un agente ha agito, che è esattamente l’osservabilità che Apple sostiene non dovrebbe esistere. L’esperienza silenziosa descritta prima si compra con un segnale che un secondo motore ha detto che il web non dovrebbe esporre. Entrambe le cose possono essere vere, e chi costruisce su questo dovrebbe sapere che sta scegliendo una parte invece di prendere in mano uno strumento già definito.

Gli editor di Google hanno risposto nello stesso thread e hanno chiesto che cosa potrebbe soddisfare WebKit al di là della rimozione della API imperativa. La risposta è stata che non avrebbero risposto punto per punto, perché ogni domanda presuppone che l’approccio sia valido, e hanno proposto di ricominciare da capo: un nuovo community group, il problema definito prima di qualsiasi soluzione e un workshop attorno al TPAC di fine ottobre 2026.

Nessun iPhone può eseguirlo, Chrome per iPhone compreso

La posizione di Apple non è solo un voto in un thread sugli standard. Decide la funzionalità per ogni browser della piattaforma.

Ogni browser distribuito oggi su iOS renderizza con WebKit. Chrome per iPhone è il motore di Safari vestito con l’interfaccia di Google, e lo stesso vale per Edge, Firefox e tutti gli altri. Una funzionalità che WebKit rifiuta di implementare è quindi indisponibile su un iPhone qualunque sia l’icona del browser che si tocca.

Questo potrebbe cambiare, lentamente. La Competition and Markets Authority del Regno Unito ha giudicato l’obbligo di motore imposto da Apple una violazione del proprio regime di Strategic Market Status, con un piano di conformità atteso per giugno 2026 e modifiche previste in iOS 20 nell’autunno 2026, prima della piena conformità a gennaio 2027. Il Digital Markets Act dell’Unione Europea permette motori alternativi dal 2024. In pratica nessuno dei due ne ha prodotto uno: nessun produttore di browser ha distribuito un motore alternativo tramite l’App Store, e sia Google sia Mozilla hanno port che restano non rilasciati.

Per un brand ecommerce, quello è il numero che conta più di qualsiasi data di una specifica, perché il traffico da iPhone è una quota grande della maggior parte dei negozi e oggi nessuna parte di esso può raggiungere un tool registrato.

Provarlo richiede un browser Chromium, che è quello che la maggior parte degli agenti usa già

Gli agenti che fanno la lettura sono già sul motore giusto. Claude gira come estensione dentro Chrome, Gemini è integrato in Chrome, Copilot sta in Edge e Comet di Perplexity è un browser Chromium a sé. La navigazione agentica su desktop oggi è in netta prevalenza Chromium, quindi il motore è raramente l’ostacolo.

L’ostacolo che sfugge è che non tutti gli assistenti che leggono la tua pagina sono un browser. Chiedi a ChatGPT o a Claude in una finestra di chat di aprire una URL e il fetch di solito avviene su un server: il tuo HTML viene recuperato, nessun JavaScript viene eseguito e nessuna lista di tool viene mai costruita. Quell’assistente può leggere ogni parola della tua pagina e non avere comunque idea che vi sia stato registrato un tool. Solo un agente che opera dentro una vera pagina Chromium vede il tool, il che oggi significa qualcosa come Gemini in Chrome o un’estensione che implementa da sé la scoperta.

L’ostacolo è che la funzionalità è ancora dietro un cancello, e ci sono due modi per attraversarlo.

Il sito si iscrive all’origin trial di Chrome e serve il token. Questa è la strada che prende un negozio in produzione, ed è fatta di tre passi.

Registra l’origin su developer.chrome.com/origintrials/#/register_trial/4163014905550602241, che è il trial di WebMCP e va da Chrome 149 a Chrome 156. Inserisci l’origin che serve davvero le tue pagine, sottodominio compreso, perché un token emesso per example.com non copre www.example.com. Se il tuo dominio apex reindirizza a www, registra l’host www e salta la corrispondenza dei sottodomini, dato che un redirect non carica mai un documento e quindi non ha mai bisogno del token.

Servi il token che ti viene dato, come header di risposta oppure come meta tag nell’head di ogni pagina che registra un tool:

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

Emettilo solo quando ne hai uno. Un token vuoto o scaduto registra un errore in console a ogni caricamento di pagina, quindi rendi il tag condizionale invece di incollare un attributo vuoto e dimenticartene.

Edge gestisce un trial separato con la propria registrazione e il proprio token. Iscriversi a uno non serve a nulla per l’altro.

Oppure chi visita lo abilita da sé, lanciando Chrome con --enable-blink-features=WebMCP o attivando le funzionalità sperimentali della piattaforma web in chrome://flags. Quella è la strada di uno sviluppatore, non di un cliente.

Questa pagina prende la prima strada. Ogni pagina di questo sito serve un token dell’origin trial WebMCP, quindi chi arriva con Chrome da 149 a 156 ottiene document.modelContext senza dover attivare nulla, e il pannello qui sopra glielo dirà. Quel token scade il 17 novembre 2026, momento in cui il tool tace per chi visita normalmente finché il trial non viene esteso o la funzionalità non viene rilasciata, e il form continua a funzionare come ha sempre fatto. Chi usa Safari, qualsiasi browser su iPhone o un Chrome fuori da quell’intervallo di versioni vede il form e nient’altro.

I vecchi tutorial non funzioneranno, e per la maggior parte hanno la data sbagliata

WebMCP non è uno standard web finito. È una bozza, curata da ingegneri di Google e Microsoft, e le bozze cambiano mentre c’è già chi ci costruisce sopra. Questa è cambiata in un modo che rompe il codice.

Il nome che si chiama si è spostato. Era navigator.modelContext e ora è document.modelContext. Chrome ha accettato entrambi i nomi per un po’ avvisando gli sviluppatori in console, poi ha smesso di accettare il vecchio in Chrome 152, che è arrivato a tutti il 25 agosto 2026. Il codice scritto alla vecchia maniera non rallenta e non degrada. Si ferma.

Lo segnaliamo perché gli articoli in giro non concordano su quando sia successo. Diversi collocano il cambiamento ad agosto 2026. La storia del progetto stesso lo colloca a maggio, tre mesi prima:

Usa document.modelContext. Un tutorial che ricorre a navigator è stato scritto contro qualcosa che non esiste più, e una data presa da un post di blog vale meno della stessa data presa dalla storia dei commit del progetto.

Il supporto è Chromium e nient’altro. Chrome ha aperto un test pubblico a giugno 2026 che dura fino a Chrome 156. Edge gestisce il proprio da Edge 150 e Brave lo offre in via sperimentale, ed entrambi sono costruiti sul motore di Chrome. Apple si è opposta formalmente alla proposta l'11 giugno 2026. Mozilla non ha preso posizione e mantiene aperto un prototipo.

Un tool è una funzione più le parole che dicono a un assistente quando usarla

Un tool è un dizionario con un nome, una descrizione, uno schema di input JSON e una callback di esecuzione. Il nome accetta da 1 a 128 caratteri ASCII alfanumerici più underscore, trattino e punto. Il requisito del contesto sicuro copre tutta l’interfaccia, getTools ed executeTool compresi, e l’accesso è governato da una funzionalità della Permissions Policy chiamata tools la cui allowlist predefinita è 'self'.

La descrizione pesa più del nome. Un agente sceglie tra i tool leggendo le descrizioni, quindi una descrizione scritta per un changelog da sviluppatori perde contro una scritta per chi deve decidere.

Scrivere l’iscrizione come tool richiede circa trenta righe

Lo schema ha due metà. Registrare l’offerta come tool, e insegnare al modal a farsi da parte una volta che l’offerta è stata presa.

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

Il popup tace nel momento in cui il tool viene eseguito, ed è tutto il senso di fare tutto questo.

Il flag dura solo per quella visita, di proposito. Spegnere il popup in modo permanente, prima che qualcuno abbia cliccato il link di conferma, toglie l’iscrizione a chi non ha mai confermato l’indirizzo e non gli lascia alcun modo di iscriversi. Silenzia il popup per la visita dalla pagina. Rendilo permanente dal tuo server una volta che la conferma è stata cliccata.

annotations: { readOnlyHint: false } dice all’agente che la chiamata cambia qualcosa invece di leggere qualcosa. È già il valore predefinito, e scriverlo per esteso mette chi legge dopo di te a una riga da untrustedContentHint, che è l’annotazione che conta per qualsiasi tool che restituisca testo su cui un agente agirà.

Il signal è un segnale di annullamento che il browser passa a ogni tool che esegue. Passarlo dentro la richiesta significa che un agente che si arrende a metà strada non lascia un’iscrizione che si completa per qualcuno che ha smesso di chiedere.

Non c’è modo di chiedere alla pagina se un agente la sta guardando. La specifica offre getTools, executeTool e un evento toolchange, e nessuno dei tre risponde alla domanda. Il fatto che venga chiamato il tuo tool è l’unico segnale affidabile che ottieni. Scrivi lo stesso flag che il tuo popup già controlla, e smette di comparire per chi visita esattamente come smette dopo che qualcuno ha compilato il form.

La versione in funzione su questa pagina

Questo sito registra un solo tool, chiamato contact_wislr, ed è attivo da quando questo articolo è stato pubblicato. Il form di contatto di questo sito si apre con un clic invece di partire sull’intenzione di uscita, quindi qui il tool non elimina un’interruzione. Elimina la digitazione.

Tre decisioni in quella implementazione vale la pena copiarle.

Lo schema chiede più di quanto chieda il form. Il form è una singola textarea con un placeholder che ricorda di includere nome e email. Parecchi messaggi arrivano senza né l’uno né l’altra, e un messaggio senza indirizzo di risposta è un contatto a cui non si può rispondere. Il tool dichiara name, email e website come input nominati accanto al messaggio, così un agente che compila la chiamata ha un posto ovvio dove metterli.

Il valore restituito dà all’agente qualcosa su cui agire. La callback di esecuzione può risolversi in qualsiasi cosa, ed executeTool consegna all’agente una stringa, che l’agente legge. Quando un messaggio arriva senza indirizzo email, la nostra lo dice e chiede all’agente di procurarsene uno e inviare un secondo messaggio. Una conferma che dice solo “inviato” butta via l’unica occasione di correggere la chiamata mentre chi visita è ancora lì.

L’agente condivide il budget di invii del form. Il form permette tre messaggi per sessione di navigazione, contati in sessionStorage. Il tool legge e scrive lo stesso contatore, quindi un agente e una persona che lavorano sulla stessa pagina ne hanno tre in due invece di tre a testa. Questo ha richiesto una modifica al form, che leggeva il contatore una volta sola al caricamento della pagina e lo teneva in una variabile. Una copia in cache dà a ciascuna superficie il proprio budget e lascia che quella che scrive per ultima annulli l’altra, che è il tipo di bug che compare solo quando esiste una seconda superficie.

L’endpoint è lo stesso a cui il form già invia. I campi nominati vengono composti nel corpo del messaggio prima che la richiesta parta, quindi il gestore esistente non ha avuto bisogno di modifiche per leggerli, e il payload porta con sé un campo source così i messaggi inviati da agenti si possono contare a parte da quelli digitati senza analizzare la prosa.

Come vederlo in funzione

Questo sito serve il token del trial, quindi non c’è nulla da attivare. Apri una qualsiasi pagina di questo sito in Chrome da 149 a 156 e il pannello più su in questo articolo ti dirà se il tuo browser ha il tool, poi il pulsante sotto lo chiama davvero.

Per verificarlo tu stesso, chiedi al browser quali tool gli sono stati offerti:

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

Entrambi i nomi si risolvevano ancora in Chrome 151, che è l’ultima versione con l’alias. Da Chrome 152 in poi risponde solo document.modelContext.

Su un sito che non si è iscritto al trial, document.modelContext è undefined e nulla di tutto questo funziona. Lanciare Chrome con --enable-blink-features=WebMCP accende la API in locale, ed è così che ci si sviluppa contro prima che esista un token.

Vale la pena conoscere una differenza tra la specifica e l’implementazione prima che ti costi un pomeriggio. L’IDL tipizza il secondo argomento di executeTool come oggetto, e passare un oggetto fallisce con UnknownError: Failed to parse input arguments, che non dice quale argomento né perché. Chrome vuole gli argomenti serializzati:

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

getTools() risponde allo stesso modo. L’inputSchema di un tool restituito arriva come stringa JSON invece che come l’oggetto che era stato registrato, quindi chi lo rilegge deve prima farne il parsing.

Sulla stessa pagina ci sono cose più utili

L’iscrizione è il punto da cui partire perché l’endpoint, il flusso di consenso e l’email di conferma esistono già. È anche la cosa più piccola sulla pagina che valga la pena esporre.

Ogni interazione che chi visita completa a mano è una candidata, e quelle che richiedono più passaggi guadagnano di più a essere ridotte a una sola chiamata.

I tool di sola lettura sono il punto di partenza più sicuro. Impostare readOnlyHint: true su un tool di ricerca o di disponibilità dice all’agente che la chiamata non cambia nulla, e un errore costa una query sprecata invece di un record scritto nel tuo database.

Tutto ciò che sta dietro l’autenticazione resta dietro l’autenticazione. Un tool registrato gira nella pagina con la sessione che chi visita ha già, quindi get_order_status è protetto esattamente quanto la pagina dell’account da cui legge, e non di più.

Nulla di tutto questo cambia il motivo per cui il popup è stato costruito

Un tool parte solo dopo che qualcuno ha chiesto qualcosa. Ha detto al proprio assistente di ottenere lo sconto, e l’assistente ha trovato la funzione che lo fa. Quella persona avrebbe consegnato un indirizzo attraverso qualunque percorso le avessi dato.

Il popup è puntato sulla persona opposta. Qualcuno che non ha deciso nulla e sta per uscire, catturato da un timer o dal mouse che si muove verso il pulsante indietro. Si guadagna il proprio posto convertendo persone che non avrebbero convertito, ed è l’unica ragione per cui un team accetta di infastidire tutti gli altri per ottenerle.

Spegnere il popup per il traffico degli agenti quindi non costa nulla, perché quelle visite non sono mai state il suo bersaglio. Cancellarlo per tutti rinuncia agli indirizzi che era stato costruito per catturare, insieme agli anni di email che ne derivano.

I team marketing sono misurati su quanto in fretta cresce la lista e su quanto fatturato portano le email del ciclo di vita. WebMCP non muove nessuno dei due numeri. Dà a chi è disponibile un percorso più pulito e lascia intatto il motivo dell’interruzione.

Il supporto decide il resto. Solo Chromium, in test che finiscono a Chrome 156, con Apple contraria. Sostituire un form di iscrizione con un tool toglierebbe il percorso che usa quasi chiunque visiti in cambio di uno che funziona in una frazione di un solo browser.

Per ora è una via in più. Il popup parte meno spesso man mano che più visite arrivano tramite assistenti, e sparisce del tutto il giorno in cui raccogliere un indirizzo smette di ripagarsi. Nessuna specifica può anticipare quel giorno.

Un’iscrizione aperta è il modo in cui le persone vengono sepolte di posta

Un tool di iscrizione prende un indirizzo email che non può verificare e ci invia posta. Chiunque sia in grado di guidare un agente può puntarlo su qualsiasi casella. Il tuo form ha lo stesso buco, perché l’indirizzo dietro entrambi è una URL pubblica su cui uno script può inviare senza mai caricare la tua pagina.

L’attacco ha un nome. In una campagna di list bombing, l’indirizzo di una vittima viene inviato a centinaia o migliaia di siti nello stesso momento, una richiesta ciascuno. Ogni sito vede una singola iscrizione insignificante e da nessuna parte sembra esserci qualcosa che non va. La vittima riceve migliaia di email di conferma in un’ora, e l’alluvione di solito copre qualcos’altro che arriva nella stessa casella: un avviso di frode dalla banca, un reset della password, la ricevuta di un acquisto che qualcuno ha fatto con la sua carta. Ci rimette anche la tua reputazione di invio, ed è la parte più piccola di ciò che è successo.

Quella forma sconfigge la difesa a cui la maggior parte delle persone ricorre. Un rate limit conta le richieste, e una campagna che te ne manda esattamente una non gli lascia nulla da contare.

Quattro cose invece aiutano.

Metti una sfida davanti all’iscrizione, così un invio automatizzato deve superare qualcosa che una persona reale supera senza accorgersene.

Deduplica per indirizzo e tieni una lista di soppressione, così la stessa casella non può essere iscritta più e più volte e una seconda richiesta per un indirizzo con una conferma già in sospeso non invia proprio nulla.

Chiedi alle persone di confermare prima di aggiungerle a una lista, così una chiamata abusata non può produrre un’iscrizione. Un avvertimento che coglie molti di sorpresa: in Canada, secondo la legge antispam, una email di conferma vale come messaggio commerciale a sé stante, quindi inviarne una a un indirizzo che non ha mai chiesto nulla è la violazione invece che la protezione. I tribunali tedeschi si sono divisi sulla stessa questione. La conferma è l’impostazione predefinita giusta nella maggior parte dei posti e non è universale.

Registra la provenienza di ogni iscrizione nel momento in cui la riga viene scritta. Ricostruirla dopo un incidente significa tirare a indovinare su quali indirizzi fossero reali.

Dimostrare il consenso è più difficile quando a cliccare è stato il software

Un invio di form produce una traccia di ciò che chi visitava ha visto. La casella di spunta, l’etichetta accanto, il link alla privacy e la marca temporale stanno tutti dalla tua parte.

Una chiamata a un tool produce un indirizzo email dentro un argomento di funzione. Quello che a chi visitava è stato detto prima che l’agente agisse è successo in una conversazione a cui non hai accesso. Secondo il GDPR il consenso deve essere libero, specifico, informato e inequivocabile, e il titolare deve poterlo dimostrare in seguito. Un indirizzo che arriva tramite un agente non soddisfa nulla di tutto questo da solo.

Il double opt-in regge la maggior parte del peso anche qui, per la seconda volta. L’email di conferma va all’indirizzo stesso, e cliccarla produce un’azione con marca temporale compiuta dall’iscritto invece che da qualcosa che agisce per lui. Tieni le iscrizioni mediate da agenti distinguibili in archivio, così un audit può separarle dagli invii di form invece di trattare tutta la lista come un’unica provenienza.

Queste iscrizioni spariscono in silenzio, quindi costruisci prima il conteggio

Un agente che chiama un tool registrato esegue una callback dentro la pagina. Non c’è visualizzazione di pagina, non c’è evento di invio del form e spesso non c’è nemmeno una sessione nel senso in cui la intende uno strumento di analytics del browser. La conversione avviene e l’iscritto è reale, mentre il report non mostra nulla. Se imposti male questa parte il guasto è silenzioso: gli iscritti salgono, nessuna provenienza li spiega e non c’è nulla nell’interfaccia che sembri rotto.

È la stessa lacuna strutturale che nasconde i crawler AI e i referral AI dalle analytics del browser, che si presenta a un nuovo livello. Un crawler non esegue mai il JavaScript che lo segnalerebbe. Un agente esegue il JavaScript, ed esegue la parte che completa la conversione saltando ogni parte che l’avrebbe misurata.

La richiesta che arriva al tuo endpoint di iscrizione è l’unico posto in cui la conversione esiste in una forma che possiedi. Marcala lì, nei log di prima parte, e il canale diventa qualcosa di cui puoi stimare la dimensione per il trimestre successivo.

Quattro cose che impediscono che spariscano

Marca la provenienza sul server, nella stessa scrittura che crea l’iscritto. La pagina invia un campo di provenienza con la richiesta, e il server lo mette sulla riga accanto all’indirizzo e alla marca temporale. Ricostruirla dopo dal testo del messaggio è tirare a indovinare, e il referrer non ti salverà, perché gli agenti spesso non ne inviano affatto.

Segnala l’iscrizione prima della chiamata di rete invece che dentro il gestore di successo. Una chiamata abbandonata a metà, o che fallisce dopo che il server ha già fatto il lavoro, non raggiunge mai il ramo di successo. Segnalala in uscita e conti il tentativo, che è il numero che vuoi davvero.

Crea l’evento nel tuo strumento di analytics prima di rilasciare il tool. Gli eventi personalizzati vengono comunemente accettati e poi scartati da ogni report finché non esiste un obiettivo con un nome corrispondente, quindi un evento non registrato restituisce un codice di successo e non compare da nessuna parte. Il silenzio nella dashboard non è la prova che nulla sia partito, ed è il modo più facile in assoluto per passare una settimana a fare il debug di codice che funzionava dall’inizio.

Riconcilia una volta a settimana, di proposito. Conta le righe nei tuoi dati che portano la provenienza agente, poi confrontale con ciò che le tue analytics mostrano per gli stessi giorni. Due numeri che coincidono significano che il tubo è integro. Uno scarto è la dimensione del tuo punto cieco. Traffico da una parte e uno zero dall’altra significa che l’evento non arriva affatto, e ora lo sai in una settimana invece che a fine trimestre.

Che cosa farne questo trimestre

Registrare un tool richiede un pomeriggio. Parti dall’offerta per cui già interrompi le persone, perché l’endpoint, il flusso di consenso e l’email di conferma sono costruiti e funzionanti.

Tieni il form. Quasi tutti quelli che visitano lo useranno comunque, e resterà vero finché Apple manterrà la sua posizione.

Usa document.modelContext, e iscriviti al trial di Chrome se vuoi che a raggiungere il tool siano i visitatori normali e non gli sviluppatori con un flag attivo.

Aggiungi il campo di provenienza al tuo endpoint di iscrizione prima che il tool venga rilasciato. Farlo dopo significa che non potrai dire quali delle iscrizioni già presenti nel tuo database siano arrivate da un agente.

Leggi i risultati dal tuo server. Una proprietà di analytics non ti mostrerà affatto queste iscrizioni, e nulla al suo interno sembrerà rotto mentre restano non contate.

Il numero che vale la pena guardare non è nessuno dei precedenti. È la quota delle tue visite che arriva tramite un assistente, che decide quando tutto questo smette di essere un esperimento, e puoi misurarla dai tuoi log già oggi, che tu registri un tool oppure no.