O WebMCP vai acabar com o modal de newsletter & de oferta de desconto? Esperamos que sim. Registramos um no nosso site para descobrir.

Você clica em um link, a página começa a carregar, e um popup desliza por cima dela antes de você ter lido uma frase. Dez por cento de desconto, se você entregar um endereço de e-mail a uma empresa à qual chegou nove segundos atrás. Você fecha. Em algum lugar mais abaixo, um segundo está esperando o momento em que você se mover na direção do botão de voltar.

Esse popup não é uma falha de design. Ele está fazendo exatamente o que foi construído para fazer, e funciona bem o bastante para que ninguém no time de marketing defenda tirá-lo.

Um endereço de e-mail é a chave do programa de retenção. Assim que uma marca tem um, ela pode rodar os fluxos de ciclo de vida que existem por trás de toda plataforma de ecommerce: a série de boas-vindas que dispara no cadastro, o e-mail de abandono de navegação que sai quando alguém vê um produto e vai embora, a sequência de abandono de carrinho e de checkout, os lembretes de pós-compra e de reposição, o resgate de quem ficou em silêncio. Nenhum deles pode começar sem o endereço. Todos são disparados por comportamento e continuam rendendo muito depois de o anúncio que trouxe o visitante já ter sido pago.

É isso que os dez por cento compram. O desconto é o preço de compra de uma linha permanente de contato, e é barato ao lado do clique pago que entregou você. Fluxos disparados rendem muito mais por destinatário do que uma newsletter de massa, e a sequência de carrinho abandonado rende mais do que todas, então um profissional de marketing que conta o valor de um endereço não está contando um e-mail. Está contando um fluxo deles que dura anos.

Isso também explica o momento. O popup dispara na chegada, na profundidade de rolagem ou ao primeiro sinal de que você está indo para o botão de voltar, porque um visitante que vai embora sem entregar um endereço fica inalcançável para sempre, enquanto um visitante que entrega um é o começo de uma sequência. Uma marca que coleta endereços de três por cento dos visitantes está fazendo um ótimo negócio pelo custo de irritar os outros noventa e sete.

O WebMCP não mexe em nada disso. O que ele muda é o mecanismo. Uma página pode publicar o seu cadastro como uma função, descrever em linguagem simples o que ela faz e deixar que o agente de IA que trabalha para o visitante a chame quando o visitante de fato pedir a oferta. O endereço continua chegando, o desconto continua sendo enviado, e nada interrompe a leitura.

Para quem está lendo, esse é o prêmio inteiro. A questão é quanto disso dá para colher hoje, e a resposta honesta é uma fatia.

Como o visitante vive a remoção do popup

Aqui está a mesma oferta, coletada de duas maneiras. À esquerda está o que um visitante recebe hoje. À direita está o que a mesma pessoa recebe quando a página publicou o seu cadastro como algo que o assistente dela consegue executar.

O que de fato acaba com o popup é uma mudança no tráfego

Algumas pessoas na marca abandonariam o popup por completo. Ele fica porque interromper as pessoas é o único método que coleta endereços de e-mail de forma confiável, e o custo dessa interrupção cai sobre o visitante e não sobre o time que a escolheu. Todo mundo que está lendo tem uma experiência pior para que uma pequena porcentagem entregue um endereço, e a troca se sustenta há cerca de vinte anos porque nada mais coletava endereços tão bem.

A troca só se rompe quando um segundo método começa a coletar os mesmos endereços sem a interrupção, e ela se rompe uma visita por vez.

Um popup só funciona com um humano olhando para uma tela. Quando um assistente faz a leitura, não há tela para cobrir nem hesitação contra a qual cronometrar, então aquela visita não produz endereço nenhum por melhor que o popup estivesse ajustado.

A mesma visita ainda pode produzir um endereço. Quem pede o desconto ao seu assistente entrega um de boa vontade, com um nome junto, no momento em que queria. Esse endereço é mais limpo, a intenção por trás dele é mais forte, e nenhuma boa vontade foi gasta para consegui-lo.

Um time de marketing mantém o popup enquanto ele pagar. À medida que mais visitas chegam por assistentes, o popup dispara para um público que encolhe com um retorno que encolhe, enquanto o incômodo que causa segue constante. O mesmo cálculo que o colocou na página acaba tirando-o dela.

Nada disso chega em um cronograma que uma especificação controla. Chega quando gente suficiente lê a web através de algo que lê em nome dela, o que é uma questão de tráfego e não uma questão de padrões, e é mensurável nos seus próprios logs hoje.

O que vale dizer claramente é que o destino é bom. Uma web em que a oferta está disponível para quem a pede e invisível para todos os outros é melhor para o leitor e não é pior para a marca. Essa é uma combinação rara, e é o motivo pelo qual vale construir para isso cedo em vez de esperar o alcance chegar.

A objeção da Apple é que um site nunca deveria saber que um agente está no comando

Dois engenheiros da Apple expuseram a objeção do WebKit no tópico público de standards-positions durante junho de 2026, e a posição foi resolvida como oposição em 11 de junho. Eles dão seis motivos, e o primeiro vai ao que um agente é.

A posição do WebKit sustenta que um agente agindo por um usuário é, “na prática, uma tecnologia assistiva: ele deveria operar um site como o usuário operaria, e o site não deveria destacá-lo para um tratamento diferente”. O WebMCP faz o oposto. Ele torna “um agente está no comando” um fato observável, e uma vez que isso seja endereçável em separado, nada mantém as duas superfícies em paridade. Um site pode dar aos agentes capacidades que nega à sua própria interface, ou negá-las aos agentes, o que eles descrevem como “o problema de bloquear leitores de tela, mas aplicado a agentes de IA”.

Eles duvidam da promessa de confiabilidade também. Um agente ainda escolhe uma ferramenta lendo o nome e a descrição dela, que a própria especificação admite serem ambíguos e não verificáveis, sem “nenhuma garantia de que a intenção declarada de uma ferramenta WebMCP corresponda ao seu comportamento real”. Um esquema tipado fixa o formato de um argumento e não o significado que o agente tem de inferir, então na leitura deles a fragilidade sai da página e entra nas descrições das ferramentas em vez de desaparecer.

A objeção de privacidade é mais afiada do que a de costume. Um site pode pedir mais parâmetros do que precisa, e um agente prestativo os preenche com coisas que o usuário contou ao agente e não ao site. A especificação chama isso de um pipeline de “personalização para fingerprinting” no seu próprio texto.

Eles também apontam que as partes de que um revisor precisaria para julgar qualquer disso, entre elas a análise de segurança cross-origin e o gancho de consentimento, ainda estão marcadas como trabalho a fazer, e que um grupo constituído em torno de machine learning é o lugar errado para mudanças cuja casa de verdade é o HTML e a semântica de acessibilidade.

Um dos invariantes que eles declaram aponta diretamente para o assunto deste artigo: “Alguns usuários não vão, ou não podem, usar agentes, então o resultado precisa beneficiar todos os usuários e não pode privilegiar quem tem um”.

Coloque isso ao lado do padrão no código acima. Suprimir o popup depende de a página descobrir que um agente agiu, que é exatamente a observabilidade que a Apple argumenta que não deveria existir. A experiência silenciosa descrita antes é comprada com um sinal que um segundo motor disse que a web não deveria expor. As duas coisas podem ser verdade, e quem construir sobre isso deveria saber que está escolhendo um lado e não pegando uma ferramenta assentada.

Os editores do Google responderam no mesmo tópico e perguntaram o que satisfaria o WebKit aquém de remover a API imperativa. A resposta foi que eles não responderiam ponto a ponto, porque cada pergunta pressupõe que a abordagem é sólida, e propuseram começar do zero: um novo community group, o problema definido antes de qualquer solução, e um workshop em torno do TPAC no fim de outubro de 2026.

Nenhum iPhone consegue rodar isto, incluindo o Chrome para iPhone

A posição da Apple não é só um voto em um tópico de padrões. Ela decide o recurso para todo navegador da plataforma.

Todo navegador que roda no iOS hoje renderiza com WebKit. O Chrome para iPhone é o motor do Safari vestindo a interface do Google, e o mesmo vale para o Edge, o Firefox e o resto. Um recurso que o WebKit se recusa a implementar fica, portanto, indisponível em um iPhone não importa em qual ícone de navegador a pessoa toque.

Isso pode mudar, devagar. A Competition and Markets Authority do Reino Unido classificou a exigência de motor da Apple como uma violação do seu regime de Strategic Market Status, com um plano de conformidade previsto para junho de 2026 e mudanças esperadas para chegar ao iOS 20 no outono de 2026, antes da conformidade plena em janeiro de 2027. O Digital Markets Act da União Europeia permite motores alternativos desde 2024. Na prática nenhum dos dois produziu um: nenhum fabricante de navegador lançou um motor alternativo pela App Store, e tanto o Google quanto a Mozilla têm ports que continuam sem publicação.

Para uma marca de ecommerce, esse é o número que importa mais do que qualquer data de especificação, porque o tráfego de iPhone é uma fatia grande da maioria das lojas e nada dele consegue alcançar uma ferramenta registrada hoje.

Testar isso exige um navegador Chromium, que é o que a maioria dos agentes já usa

Os agentes que fazem a leitura já estão no motor certo. O Claude roda como uma extensão dentro do Chrome, o Gemini é embutido no Chrome, o Copilot fica no Edge, e o Comet da Perplexity é um navegador Chromium próprio. A navegação agêntica no desktop é esmagadoramente Chromium hoje, então o motor raramente é o obstáculo.

O obstáculo que as pessoas não percebem é que nem todo assistente que lê a sua página é um navegador. Peça ao ChatGPT ou ao Claude em uma janela de chat para abrir uma URL e a busca costuma acontecer em um servidor: o seu HTML é recuperado, nenhum JavaScript roda, e nenhuma lista de ferramentas é montada. Esse assistente pode ler cada palavra da sua página e ainda assim não fazer ideia de que uma ferramenta foi registrada nela. Só um agente operando dentro de uma página Chromium de verdade vê a ferramenta, o que hoje significa algo como o Gemini no Chrome ou uma extensão que implementa a descoberta por conta própria.

O obstáculo é que o recurso ainda está trancado, e há dois jeitos de passar pela porta.

O site se inscreve no origin trial do Chrome e serve o token. Esse é o caminho que uma loja em produção toma, e são três passos.

Registre a origem em developer.chrome.com/origintrials/#/register_trial/4163014905550602241, que é o trial do WebMCP e vai do Chrome 149 ao Chrome 156. Informe a origem que de fato serve as suas páginas, incluindo o subdomínio, porque um token emitido para example.com não cobre www.example.com. Se o seu apex redireciona para o www, registre o host www e dispense a correspondência de subdomínios, já que um redirecionamento nunca carrega um documento e por isso nunca precisa do token.

Sirva o token que ele dá a você, seja como um cabeçalho de resposta, seja como uma meta tag no head de toda página que registra uma ferramenta:

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

Emita-o apenas quando você tiver um. Um token vazio ou vencido registra um erro no console a cada carregamento de página, então torne a tag condicional em vez de colar um atributo vazio e esquecer dele.

O Edge roda um trial separado com o próprio registro e o próprio token. Inscrever-se em um não faz nada pelo outro.

Ou o visitante habilita por conta própria, iniciando o Chrome com --enable-blink-features=WebMCP ou ligando os recursos experimentais da plataforma web em chrome://flags. Esse é o caminho de um desenvolvedor, não o de um cliente.

Esta página toma o primeiro caminho. Toda página deste site serve um token de origin trial do WebMCP, então um visitante que chega no Chrome 149 até o 156 recebe document.modelContext sem nada para ligar, e o painel acima vai dizer isso. Esse token expira em 17 de novembro de 2026, ponto em que a ferramenta fica muda para visitantes comuns até o trial ser estendido ou o recurso ser lançado, e o formulário segue como sempre seguiu. Quem estiver no Safari, em qualquer navegador em um iPhone, ou em um Chrome fora dessa faixa de versões vê o formulário e nada mais.

Tutoriais antigos não vão funcionar, e a maioria deles erra a data

O WebMCP não é um padrão web pronto. É um rascunho, editado por engenheiros do Google e da Microsoft, e rascunhos mudam enquanto as pessoas já estão construindo sobre eles. Este mudou de um jeito que quebra código.

O nome que você chama mudou de lugar. Ele era navigator.modelContext e agora é document.modelContext. O Chrome aceitou os dois nomes por um tempo e avisou os desenvolvedores no console, depois parou de aceitar o antigo no Chrome 152, que chegou a todo mundo em 25 de agosto de 2026. Código escrito do jeito antigo não fica lento nem degrada. Ele para.

Estamos sinalizando isso porque os textos publicados discordam sobre quando aconteceu. Vários colocam a mudança em agosto de 2026. O histórico do próprio projeto a coloca em maio, três meses antes:

Use document.modelContext. Um tutorial que recorre a navigator foi escrito contra algo que não existe mais, e uma data vinda de um post de blog vale menos do que a mesma data vinda do histórico de commits do próprio projeto.

O suporte é Chromium e nada além. O Chrome abriu um teste público em junho de 2026 que vai até o Chrome 156. O Edge roda o seu a partir do Edge 150 e o Brave tem isso em caráter experimental, e os dois são construídos sobre o motor do Chrome. A Apple se opôs formalmente à proposta em 11 de junho de 2026. A Mozilla não tomou lado e mantém um protótipo aberto.

Uma ferramenta é uma função mais as palavras que dizem a um assistente quando usá-la

Uma ferramenta é um dicionário com um nome, uma descrição, um esquema de entrada JSON e um callback de execução. O nome aceita de 1 a 128 caracteres ASCII alfanuméricos mais sublinhado, hífen e ponto. A exigência de contexto seguro cobre a interface inteira, getTools e executeTool incluídos, e o acesso é regido por um recurso de Permissions Policy chamado tools cuja allowlist padrão é 'self'.

A descrição pesa mais do que o nome. Um agente escolhe entre ferramentas lendo descrições, então uma descrição escrita para um changelog de desenvolvedor vai perder para uma escrita para a pessoa que está decidindo.

Escrever o cadastro como ferramenta leva umas trinta linhas

O padrão tem duas metades. Registre a oferta como uma ferramenta, e ensine o modal a se retirar assim que a oferta for aceita.

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

O popup fica em silêncio no momento em que a ferramenta roda, e esse é todo o objetivo de fazer qualquer coisa disso.

A flag só dura aquela visita, de propósito. Desligar o popup em definitivo, antes de alguém ter clicado no link de confirmação, tira o cadastro de um visitante cujo endereço nunca foi confirmado e o deixa sem nenhuma forma de se inscrever. Silencie o popup pela duração da visita a partir da página. Torne isso permanente a partir do seu servidor assim que a confirmação for clicada.

annotations: { readOnlyHint: false } diz ao agente que a chamada muda alguma coisa em vez de ler alguma coisa. Isso já é o padrão, e escrevê-lo deixa o próximo leitor a uma linha de untrustedContentHint, que é a anotação que importa para qualquer ferramenta que devolva texto sobre o qual um agente vai agir.

O signal é um AbortSignal que o navegador entrega a toda ferramenta que roda. Passá-lo para dentro da requisição significa que um agente que desiste no meio do caminho não deixa um cadastro se concluindo para alguém que parou de pedir.

Não há como perguntar à página se um agente está observando. A especificação oferece getTools, executeTool e um evento toolchange, e nenhum deles responde a pergunta. A sua própria ferramenta ser chamada é o único sinal confiável que você recebe. Escreva a mesma flag que o seu popup já consulta, e ele deixa de disparar para aquele visitante do mesmo jeito que deixa de disparar depois que alguém preenche o formulário.

A versão que roda nesta página

Este site registra uma ferramenta, chamada contact_wislr, e ela está no ar desde a publicação deste artigo. O formulário de contato deste site abre com um clique em vez de disparar por intenção de saída, então a ferramenta não remove uma interrupção aqui. Ela remove a digitação.

Três decisões dessa implementação valem ser copiadas.

O esquema pede mais do que o formulário. O formulário é um único textarea com um placeholder lembrando as pessoas de incluir o nome e o e-mail. Muitas mensagens chegam sem nenhum dos dois, e uma mensagem sem endereço de resposta é um lead que não dá para responder. A ferramenta declara name, email e website como entradas nomeadas ao lado da mensagem, então um agente que preenche a chamada tem onde colocá-los de forma óbvia.

O valor de retorno dá ao agente algo sobre o que agir. O callback de execução pode resolver para qualquer coisa, e o executeTool entrega ao agente uma string, que ele lê. Quando uma mensagem chega sem endereço de e-mail, a nossa diz isso e pede ao agente que colete um e envie uma segunda mensagem. Uma confirmação que só diz “enviado” joga fora a única chance de corrigir a chamada enquanto o visitante ainda está ali.

O agente divide o orçamento de envio do formulário. O formulário permite três mensagens por sessão de navegação, contadas no sessionStorage. A ferramenta lê e escreve o mesmo contador, então um agente e um visitante trabalhando na mesma página têm três entre os dois em vez de três cada. Isso exigiu uma mudança no formulário, que vinha lendo o contador uma vez no carregamento da página e o guardando em uma variável. Uma cópia em cache dá a cada superfície o seu próprio orçamento e deixa que a última a escrever desfaça a outra, que é o tipo de bug que só aparece quando uma segunda superfície existe.

O endpoint é o mesmo para o qual o formulário já posta. Os campos nomeados são compostos no corpo da mensagem antes de a requisição sair, então o handler existente não precisou de mudança nenhuma para lê-los, e o payload carrega um campo source para que mensagens enviadas por agentes possam ser contadas à parte das digitadas sem analisar prosa.

Como ver isso funcionando

Este site serve o token do trial, então não é preciso ligar nada. Abra qualquer página daqui no Chrome 149 até o 156 e o painel que aparece antes neste artigo vai dizer se o seu navegador tem a ferramenta, e depois o botão abaixo dele a chama de verdade.

Para conferir por conta própria, pergunte ao navegador quais ferramentas foram oferecidas a ele:

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

Os dois nomes ainda resolviam no Chrome 151, que é o apelido no seu último marco. No Chrome 152 e depois só document.modelContext responde.

Em um site que não se inscreveu no trial, document.modelContext é undefined e nada disso roda. Iniciar o Chrome com --enable-blink-features=WebMCP liga a API localmente, que é como desenvolver contra ela antes de um token existir.

Uma diferença entre a especificação e a implementação vale conhecer antes que ela lhe custe uma tarde. A IDL tipa o segundo argumento do executeTool como um objeto, e passar um objeto falha com UnknownError: Failed to parse input arguments, que não diz qual argumento nem por quê. O Chrome quer os argumentos serializados:

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

O getTools() responde do mesmo jeito. O inputSchema de uma ferramenta retornada chega como uma string JSON e não como o objeto que foi registrado, então qualquer coisa que o leia de volta precisa fazer o parse primeiro.

Coisas mais úteis estão paradas na mesma página

O cadastro é por onde começar porque o endpoint, o fluxo de consentimento e o e-mail de confirmação já existem. Ele também é a menor coisa da página que vale a pena expor.

Toda interação que um visitante conclui à mão é uma candidata, e as que levam vários passos ganham mais em ser reduzidas a uma única chamada.

Ferramentas somente de leitura são o lugar mais seguro para começar. Definir readOnlyHint: true em uma ferramenta de busca ou de disponibilidade diz ao agente que a chamada não muda nada, e um erro custa uma consulta desperdiçada em vez de um registro gravado no seu banco de dados.

Qualquer coisa atrás de autenticação continua atrás de autenticação. Uma ferramenta registrada roda na página com a sessão que o visitante já tem, então get_order_status está exatamente tão protegida quanto a página de conta de onde ela lê, e nada além disso.

Nada aqui muda o motivo pelo qual o popup foi construído

Uma ferramenta só roda depois que alguém pediu alguma coisa. A pessoa disse ao assistente para pegar o desconto, e o assistente achou a função que faz isso. Essa pessoa ia entregar um endereço por qualquer caminho que você desse a ela.

O popup mira a pessoa oposta. Alguém que não decidiu nada e está de saída, pego por um cronômetro ou pelo mouse indo na direção do botão de voltar. Ele ganha o seu lugar convertendo gente que não ia converter, e esse é o único motivo pelo qual um time aceita irritar todo o resto para conseguir essas pessoas.

Desligar o popup para o tráfego de agentes, portanto, não custa nada, porque esses visitantes nunca foram o alvo dele. Apagá-lo para todo mundo abre mão dos endereços que ele foi construído para pegar, junto com os anos de e-mail que saem deles.

Times de marketing são medidos pela velocidade com que a lista cresce e por quanta receita os e-mails de ciclo de vida trazem. O WebMCP não move nenhum dos dois números. Ele dá a um visitante disposto um caminho mais limpo e deixa intocado o motivo da interrupção.

O suporte decide o resto. Só Chromium, em testes que terminam no Chrome 156, com a Apple contra. Substituir um formulário de cadastro por uma ferramenta removeria o caminho que quase todo visitante usa em troca de um que funciona em uma fração de um navegador.

Por enquanto é um caminho a mais. O popup dispara com menos frequência conforme mais visitas chegam por assistentes, e ele some de vez no dia em que coletar um endereço deixar de se pagar. Nenhuma especificação pode antecipar esse dia.

Um cadastro aberto é como as pessoas ficam soterradas de e-mail

Uma ferramenta de cadastro recebe um endereço de e-mail que ela não consegue verificar e manda mensagem para ele. Qualquer pessoa capaz de dirigir um agente pode apontá-lo para qualquer caixa de entrada. O seu formulário tem o mesmo buraco, porque o endereço por trás dos dois é uma URL pública para a qual um script pode postar sem nunca carregar a sua página.

O ataque tem nome. Em uma rodada de list bombing, o endereço de uma vítima é submetido a centenas ou milhares de sites de uma vez, uma requisição para cada. Cada site vê um único cadastro nada notável e nada parece errado em lugar nenhum. A vítima recebe milhares de e-mails de confirmação em uma hora, e a enxurrada costuma ser cobertura para outra coisa chegando na mesma caixa de entrada: um alerta de fraude do banco, uma redefinição de senha, um recibo de uma compra que alguém fez com o cartão dela. A sua reputação de envio também toma um golpe, e essa é a menor parte do que aconteceu.

Esse formato derrota a defesa que a maioria das pessoas busca. Um rate limit conta requisições, e uma rodada que manda exatamente uma requisição não tem nada para ele contar.

Quatro coisas ajudam.

Ponha um desafio na frente do cadastro, para que uma submissão automatizada tenha de passar por algo que uma pessoa real vence sem perceber.

Deduplique por endereço e mantenha uma lista de supressão, para que a mesma caixa de entrada não possa ser cadastrada repetidas vezes e uma segunda requisição para um endereço com uma confirmação já pendente não envie nada.

Peça às pessoas que confirmem antes de você adicioná-las a uma lista, para que uma chamada abusada não consiga produzir uma inscrição. Uma ressalva pega as pessoas de surpresa: pela lei antispam do Canadá, um e-mail de confirmação conta como mensagem comercial por si só, então enviar um para um endereço que nunca pediu é a infração e não a proteção. Tribunais alemães se dividiram na mesma questão. A confirmação é o padrão certo na maioria dos lugares e não é universal.

Registre de onde veio cada cadastro no momento em que a linha é gravada. Descobrir isso depois de um incidente significa adivinhar quais endereços eram reais.

Provar consentimento é mais difícil quando quem clicou foi um software

Uma submissão de formulário produz um registro do que o visitante viu. A caixa de seleção, o rótulo ao lado dela, o link de privacidade e o carimbo de tempo ficam todos do seu lado.

Uma chamada de ferramenta produz um endereço de e-mail em um argumento de função. O que foi dito ao visitante antes de o agente agir aconteceu em uma conversa à qual você não tem acesso. Pelo GDPR, o consentimento precisa ser livre, específico, informado e inequívoco, e um controlador tem de conseguir demonstrá-lo depois. Um endereço que chega por um agente não satisfaz nada disso sozinho.

O double opt-in carrega a maior parte do peso aqui pela segunda vez. O e-mail de confirmação vai para o próprio endereço, e clicar nele produz uma ação com carimbo de tempo feita pelo assinante e não por algo agindo por ele. Mantenha os cadastros mediados por agentes distinguíveis no armazenamento, para que uma auditoria consiga separá-los das submissões de formulário em vez de tratar a lista inteira como uma só procedência.

Esses cadastros somem em silêncio, então construa a contagem antes

Um agente que chama uma ferramenta registrada executa um callback dentro da página. Não há visualização de página, não há evento de envio de formulário e com frequência não há sessão nenhuma no sentido em que uma ferramenta de analytics de navegador entende. A conversão acontece e o assinante é real, enquanto o relatório não mostra nada. Configure isso errado e a falha é silenciosa: os assinantes sobem, nenhuma fonte os explica, e não há nada na interface que pareça quebrado.

Essa é a mesma lacuna estrutural que esconde crawlers de IA e referências de IA do analytics de navegador, chegando em uma nova camada. Um crawler nunca roda o JavaScript que o reportaria. Um agente roda o JavaScript, e roda a parte que conclui a conversão enquanto pula toda parte que a teria medido.

A requisição que bate no seu endpoint de cadastro é o único lugar em que a conversão existe de uma forma que pertence a você. Marque-a ali, em logs de primeira parte, e o canal vira algo que você consegue dimensionar no próximo trimestre.

Quatro coisas que impedem que eles sumam

Carimbe a origem no servidor, na mesma gravação que cria o assinante. A página manda um campo de origem com a requisição, e o servidor o coloca na linha ao lado do endereço e do carimbo de tempo. Descobrir isso depois pela redação da mensagem é chute, e o referrer não vai salvar você, porque os agentes frequentemente não mandam nenhum.

Reporte o cadastro antes da chamada de rede em vez de dentro do handler de sucesso. Uma chamada abandonada no meio, ou que falha depois de o servidor já ter feito o trabalho, nunca chega ao ramo de sucesso. Reporte na saída e você conta a tentativa, que é o número que você de fato quer.

Crie o evento na sua ferramenta de analytics antes de publicar a ferramenta. Eventos personalizados costumam ser aceitos e depois descartados de todos os relatórios até que exista uma meta com nome correspondente, então um evento não registrado devolve um código de sucesso e não aparece em lugar nenhum. Silêncio no painel não é prova de que nada disparou, e é a maneira mais fácil de gastar uma semana depurando um código que estava funcionando o tempo todo.

Reconcilie uma vez por semana, de propósito. Conte as linhas dos seus próprios dados que carregam a origem de agente, e compare com o que o seu analytics mostra para os mesmos dias. Dois números que batem significam que o cano está intacto. Uma diferença é o tamanho do seu ponto cego. Tráfego de um lado e um zero do outro significa que o evento não está chegando, e agora você sabe disso em uma semana em vez de no fim do trimestre.

O que fazer a respeito neste trimestre

Registrar uma ferramenta leva uma tarde. Comece pela oferta pela qual você já interrompe as pessoas, porque o endpoint, o fluxo de consentimento e o e-mail de confirmação estão construídos e funcionando.

Mantenha o formulário. Quase todo mundo que visitar vai continuar usando, e isso segue verdadeiro enquanto a Apple mantiver a sua posição.

Use document.modelContext, e inscreva-se no trial do Chrome se você quiser que visitantes comuns alcancem a ferramenta em vez de desenvolvedores com uma flag ligada.

Adicione o campo de origem ao seu endpoint de cadastro antes de a ferramenta ir ao ar. Fazer isso depois significa que você não consegue dizer quais dos cadastros já no seu banco de dados vieram de um agente.

Leia os resultados no seu próprio servidor. Uma propriedade de analytics não vai lhe mostrar esses cadastros, e nada nela parece quebrado enquanto eles não são contados.

O número que vale acompanhar não é nenhum dos acima. É a fatia das suas visitas que chega por um assistente, que decide quando isso deixa de ser um experimento, e você consegue medir isso nos seus logs hoje, registre você uma ferramenta algum dia ou não.