¿Acabará WebMCP con el modal de newsletter y descuento? Eso esperamos. Hemos registrado uno en nuestro sitio para averiguarlo.

Haces clic en un enlace, la página empieza a cargar y un popup se desliza por encima antes de que hayas leído una frase. Un diez por ciento de descuento, si le entregas una dirección de email a una empresa a la que llegaste hace nueve segundos. Lo cierras. Más abajo, un segundo espera el momento en que te muevas hacia el botón de atrás.

Ese popup no es un fallo de diseño. Está haciendo exactamente lo que fue construido para hacer, y funciona lo bastante bien como para que nadie del equipo de marketing esté defendiendo quitarlo.

Una dirección de email es la llave del programa de retención. En cuanto una marca tiene una, puede ejecutar los flujos de ciclo de vida que hay detrás de cualquier plataforma de ecommerce: la serie de bienvenida que se dispara con el alta, el email de abandono de navegación que sale cuando alguien mira un producto y se va, la secuencia de abandono de carrito y de checkout, los recordatorios posteriores a la compra y de reposición, y la recuperación de quien lleva tiempo callado. Ninguno de ellos puede arrancar sin la dirección. Todos se disparan por comportamiento y siguen produciendo mucho después de que el anuncio que trajo al visitante ya esté pagado.

Eso es lo que compra ese diez por ciento. El descuento es el precio de compra de una línea de contacto permanente, y sale barato al lado del clic de pago que te trajo. Los flujos disparados ganan mucho más por destinatario que una newsletter enviada a todos, y la secuencia de carrito abandonado es la que más gana de todas, así que un responsable de marketing que cuenta el valor de una dirección no está contando un email. Está contando un chorro de ellos que corre durante años.

También explica el momento elegido. El popup se dispara al llegar, a cierta profundidad de scroll, o a la primera señal de que te diriges al botón de atrás, porque un visitante que se va sin entregar una dirección es inalcanzable para siempre, mientras que un visitante que entrega una es el comienzo de una secuencia. Una marca que recoge direcciones del tres por ciento de sus visitantes está haciendo un negocio estupendo a cambio de molestar al noventa y siete restante.

WebMCP no toca nada de eso. Lo que cambia es el mecanismo. Una página puede publicar su alta como una función, describir en lenguaje llano lo que hace, y dejar que el agente de IA que trabaja para el visitante la llame cuando el visitante pida realmente la oferta. La dirección sigue llegando, el descuento se sigue enviando, y nada interrumpe la lectura.

Para quien lee, ese es el premio entero. La pregunta es cuánto de él se puede cobrar hoy, y la respuesta honesta es una porción.

Cómo vive el visitante la desaparición del popup

Aquí está la misma oferta, recogida de dos maneras. A la izquierda, lo que recibe un visitante hoy. A la derecha, lo que recibe esa misma persona cuando la página ha publicado su alta como algo que su asistente puede ejecutar.

Lo que acaba de verdad con el popup es un cambio en el tráfico

Hay gente dentro de la marca que quitaría el popup sin pensarlo. Se queda porque interrumpir a la gente es el único método que recoge direcciones de email de manera fiable, y el coste de esa interrupción cae sobre el visitante y no sobre el equipo que la eligió. Todo el que lee se lleva una experiencia peor para que un pequeño porcentaje entregue una dirección, y el trato se ha mantenido durante unos veinte años porque ninguna otra cosa recogía direcciones igual de bien.

El trato solo se rompe cuando un segundo método empieza a recoger las mismas direcciones sin la interrupción, y se rompe visita a visita.

Un popup solo funciona con un humano mirando una pantalla. Cuando quien lee es un asistente, no hay pantalla que tapar ni duda contra la que cronometrar, así que esa visita no produce ninguna dirección por muy bien afinado que estuviera el popup.

Esa misma visita todavía puede producir una dirección. Quien le pide el descuento a su asistente entrega una de buena gana, con un nombre asociado, en el momento en que la quería. Esa dirección es más limpia, la intención que hay detrás es más fuerte, y no se gastó nada de buena voluntad para conseguirla.

Un equipo de marketing conserva el popup mientras siga pagando. A medida que llegan más visitas a través de asistentes, el popup se dispara ante un público que se encoge por un retorno que se encoge, mientras la molestia que causa se mantiene constante. El mismo cálculo que lo puso en la página acaba quitándolo.

Nada de eso llega en un calendario que controle una especificación. Llega cuando bastante gente lee la web a través de algo que lee en su nombre, lo que es una cuestión de tráfico y no una cuestión de estándares, y hoy se puede medir en tus propios logs.

Lo que conviene decir sin rodeos es que el destino es bueno. Una web donde la oferta está disponible para quien la pida, e invisible para todos los que no, es mejor para quien lee y no es peor para la marca. Esa es una combinación rara, y es la razón por la que vale la pena construir contra esto pronto en lugar de esperar a que llegue el alcance.

La objeción de Apple es que un sitio nunca debería saber que quien conduce es un agente

Dos ingenieros de Apple expusieron la objeción de WebKit en el hilo público de posiciones sobre estándares durante junio de 2026, y la posición se resolvió como oposición el 11 de junio. Dan seis razones, y la primera va al fondo de qué es un agente.

La posición de WebKit sostiene que un agente que actúa para un usuario es “en efecto, tecnología asistiva: debería operar un sitio como lo haría el usuario, y el sitio no debería señalarlo para darle un trato distinto”. WebMCP hace lo contrario. Convierte “hay un agente conduciendo” en un hecho observable, y en cuanto eso es direccionable por separado, nada mantiene las dos superficies a la par. Un sitio puede dar a los agentes capacidades que le niega a su propia interfaz, o negárselas a los agentes, lo que describen como “el problema del bloqueo de lectores de pantalla, pero aplicado a los agentes de IA”.

También dudan de la promesa de fiabilidad. Un agente sigue eligiendo una herramienta leyendo su nombre y su descripción, que la propia especificación admite que son ambiguos e inverificables, sin “ninguna garantía de que la intención declarada de una herramienta WebMCP coincida con su comportamiento real”. Un esquema tipado fija la forma de un argumento y no el significado que el agente tiene que inferir, así que en su lectura la fragilidad se muda de la página a las descripciones de las herramientas en lugar de desaparecer.

La objeción de privacidad es más afilada que la habitual. Un sitio puede pedir más parámetros de los que necesita, y un agente servicial los rellena con cosas que el usuario le contó al agente y no al sitio. La especificación llama a eso una tubería de “personalización a huella digital” en su propio texto.

Señalan además que las partes que un revisor necesitaría para juzgar cualquiera de estas cosas, entre ellas el análisis de seguridad entre orígenes y el punto de enganche del consentimiento, siguen marcadas como trabajo pendiente, y que un grupo constituido en torno al machine learning es el foro equivocado para cambios cuyo hogar real son el HTML y la semántica de accesibilidad.

Uno de sus invariantes declarados apunta directamente a lo que trata este artículo: “Algunos usuarios no querrán, o no podrán, usar agentes, así que el resultado debe beneficiar a todos los usuarios y no debe privilegiar a quienes tienen uno”.

Ponlo al lado del patrón del código de arriba. Silenciar el popup depende de que la página se entere de que actuó un agente, que es exactamente la observabilidad que Apple sostiene que no debería existir. La experiencia tranquila descrita antes se compra con una señal que un segundo motor ha dicho que la web no debería exponer. Las dos cosas pueden ser verdad, y quien construya sobre esto debería saber que está eligiendo un bando y no recogiendo una herramienta asentada.

Los editores de Google respondieron en el mismo hilo y preguntaron qué satisfaría a WebKit sin llegar a eliminar la API imperativa. La respuesta fue que no iban a contestar punto por punto, porque cada pregunta da por buena la solidez del enfoque, y propusieron empezar de cero: un grupo comunitario nuevo, el problema definido antes que cualquier solución, y un taller alrededor de TPAC a finales de octubre de 2026.

Ningún iPhone puede ejecutar esto, ni siquiera Chrome para iPhone

La posición de Apple no es solo un voto en un hilo de estándares. Decide la función para todos los navegadores de la plataforma.

Todos los navegadores que se distribuyen hoy en iOS renderizan con WebKit. Chrome para iPhone es el motor de Safari vestido con la interfaz de Google, y lo mismo vale para Edge, Firefox y el resto. Una función que WebKit se niega a implementar queda por tanto no disponible en un iPhone sin importar qué icono de navegador toque alguien.

Eso puede cambiar, despacio. La Competition and Markets Authority del Reino Unido dictaminó que el requisito de motor de Apple incumple su régimen de Strategic Market Status, con un plan de cumplimiento previsto para junio de 2026 y cambios que se espera que aterricen en iOS 20 en otoño de 2026, antes del cumplimiento completo en enero de 2027. La Digital Markets Act de la Unión Europea permite motores alternativos desde 2024. En la práctica ninguna de las dos ha producido uno: ningún fabricante de navegadores ha distribuido un motor alternativo a través de la App Store, y tanto Google como Mozilla tienen ports que siguen sin publicarse.

Para una marca de ecommerce, ese es el número que importa más que cualquier fecha de una especificación, porque el tráfico de iPhone es una parte grande de casi cualquier tienda y hoy nada de él puede alcanzar una herramienta registrada.

Probarlo exige un navegador Chromium, que es lo que ya usan casi todos los agentes

Los agentes que hacen la lectura ya están en el motor adecuado. Claude corre como extensión dentro de Chrome, Gemini viene integrado en Chrome, Copilot vive en Edge, y Comet de Perplexity es un navegador Chromium propio. La navegación agéntica en escritorio es hoy abrumadoramente Chromium, así que el motor rara vez es el obstáculo.

El obstáculo que a la gente se le escapa es que no todos los asistentes que leen tu página son un navegador. Pídele a ChatGPT o a Claude en una ventana de chat que abran una URL y la descarga suele ocurrir en un servidor: tu HTML se recupera, no se ejecuta JavaScript, y nunca se construye ninguna lista de herramientas. Ese asistente puede leer cada palabra de tu página y aun así no tener ni idea de que había una herramienta registrada en ella. Solo un agente que opere dentro de una página Chromium real ve la herramienta, lo que hoy significa algo como Gemini en Chrome o una extensión que implemente ella misma el descubrimiento.

El obstáculo es que la función sigue detrás de una puerta, y hay dos maneras de cruzarla.

El sitio se inscribe en el origin trial de Chrome y sirve el token. Esta es la ruta que toma una tienda en producción, y son tres pasos.

Registra el origen en developer.chrome.com/origintrials/#/register_trial/4163014905550602241, que es la prueba de WebMCP y va desde Chrome 149 hasta Chrome 156. Introduce el origen que sirve realmente tus páginas, subdominio incluido, porque un token emitido para example.com no cubre www.example.com. Si tu dominio raíz redirige a www, registra el host www y sáltate la coincidencia de subdominios, ya que una redirección nunca carga un documento y por tanto nunca necesita el token.

Sirve el token que te dé, ya sea como cabecera de respuesta o como etiqueta meta en la cabecera de cada página que registre una herramienta:

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

Emítelo solo cuando tengas uno. Un token vacío o caducado registra un error de consola en cada carga de página, así que haz la etiqueta condicional en lugar de pegar un atributo vacío y olvidarte.

Edge corre una prueba aparte con su propio registro y su propio token. Inscribirse en una no hace nada por la otra.

O el visitante lo activa por su cuenta, lanzando Chrome con --enable-blink-features=WebMCP o activando las funciones experimentales de la plataforma web en chrome://flags. Esa es la ruta de un desarrollador, no la de un cliente.

Esta página toma la primera ruta. Todas las páginas de este sitio sirven un token del origin trial de WebMCP, así que un visitante que llegue con Chrome 149 a 156 obtiene document.modelContext sin nada que activar, y el panel de arriba se lo dirá. Ese token caduca el 17 de noviembre de 2026, momento en el que la herramienta se queda callada para los visitantes corrientes hasta que la prueba se extienda o la función se publique, y el formulario sigue como siempre. Quien esté en Safari, en cualquier navegador de un iPhone, o en un Chrome fuera de ese rango de versiones ve el formulario y nada más.

Los tutoriales antiguos no funcionarán, y la mayoría tiene la fecha mal

WebMCP no es un estándar web terminado. Es un borrador, editado por ingenieros de Google y de Microsoft, y los borradores cambian mientras la gente ya está construyendo sobre ellos. Este cambió de una manera que rompe código.

El nombre al que llamas se movió. Antes era navigator.modelContext y ahora es document.modelContext. Chrome aceptó los dos nombres durante un tiempo y avisó a los desarrolladores por consola, y luego dejó de aceptar el viejo en Chrome 152, que llegó a todo el mundo el 25 de agosto de 2026. El código escrito a la manera antigua no se ralentiza ni se degrada. Se para.

Lo señalamos porque los artículos publicados no se ponen de acuerdo sobre cuándo pasó. Varios sitúan el cambio en agosto de 2026. El propio historial del proyecto lo sitúa en mayo, tres meses antes:

Usa document.modelContext. Un tutorial que eche mano de navigator se escribió contra algo que ya no existe, y una fecha sacada de una entrada de blog vale menos que esa misma fecha sacada del historial de commits del proyecto.

El soporte es Chromium y nada más. Chrome abrió una prueba pública en junio de 2026 que corre hasta Chrome 156. Edge corre la suya desde Edge 150 y Brave lo tiene de forma experimental, y ambos están construidos sobre el motor de Chrome. Apple se opuso formalmente a la propuesta el 11 de junio de 2026. Mozilla no ha tomado partido y mantiene un prototipo abierto.

Una herramienta es una función más las palabras que le dicen a un asistente cuándo usarla

Una herramienta es un diccionario con un nombre, una descripción, un esquema de entrada JSON y un callback de ejecución. El nombre admite de 1 a 128 caracteres alfanuméricos ASCII más guion bajo, guion y punto. El requisito de contexto seguro cubre toda la interfaz, getTools y executeTool incluidos, y el acceso lo gobierna una función de Permissions Policy llamada tools cuya lista de permitidos por defecto es 'self'.

La descripción pesa más que el nombre. Un agente elige entre herramientas leyendo descripciones, así que una descripción escrita para un changelog de desarrollo perderá frente a una escrita para la persona que decide.

Escribir el alta como herramienta lleva unas treinta líneas

El patrón tiene dos mitades. Registrar la oferta como herramienta, y enseñar al modal a retirarse en cuanto la oferta se haya aceptado.

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

El popup se calla en el momento en que la herramienta se ejecuta, y ese es todo el sentido de hacer nada de esto.

La marca solo dura esa visita, a propósito. Apagar el popup de forma permanente, antes de que nadie haya hecho clic en el enlace de confirmación, le quita el alta a un visitante cuya dirección nunca se confirmó y lo deja sin ninguna manera de suscribirse. Silencia el popup para la visita desde la página. Hazlo permanente desde tu servidor en cuanto se pulse la confirmación.

annotations: { readOnlyHint: false } le dice al agente que la llamada cambia algo en lugar de leer algo. Eso ya es el valor por defecto, y escribirlo deja a quien lea después a una línea de untrustedContentHint, que es la anotación que importa para cualquier herramienta que devuelva texto sobre el que un agente vaya a actuar.

El signal es una señal de aborto que el navegador entrega a cada herramienta que ejecuta. Pasarla a la petición hace que un agente que se rinde a medias no deje un alta completándose para alguien que dejó de pedirla.

No hay manera de preguntarle a la página si un agente la está mirando. La especificación ofrece getTools, executeTool y un evento toolchange, y ninguno de ellos responde a esa pregunta. Que llamen a tu propia herramienta es la única señal fiable que obtienes. Escribe la misma marca que tu popup ya comprueba, y dejará de dispararse para ese visitante igual que deja de hacerlo después de que alguien rellene el formulario.

La versión que corre en esta página

Este sitio registra una herramienta, llamada contact_wislr, y está viva desde que se publicó este artículo. El formulario de contacto de este sitio se abre con un clic en lugar de dispararse por intención de salida, así que aquí la herramienta no elimina una interrupción. Elimina el tecleo.

Tres decisiones de esa implementación merecen copiarse.

El esquema pide más de lo que pide el formulario. El formulario es un único textarea con un placeholder que recuerda a la gente que incluya su nombre y su email. Llegan muchos mensajes sin ninguno de los dos, y un mensaje sin dirección de respuesta es un lead que no se puede contestar. La herramienta declara name, email y website como entradas con nombre junto al mensaje, así que un agente que rellene la llamada tiene un sitio obvio donde ponerlos.

El valor de retorno le da al agente algo sobre lo que actuar. El callback de ejecución puede resolver a cualquier cosa, y executeTool le entrega al agente una cadena, que este lee. Cuando llega un mensaje sin dirección de email, la nuestra lo dice y le pide al agente que consiga una y envíe un segundo mensaje. Una confirmación que solo dice “enviado” desperdicia la única oportunidad de arreglar la llamada mientras el visitante sigue ahí.

El agente comparte el presupuesto de envíos del formulario. El formulario permite tres mensajes por sesión de navegación, contados en sessionStorage. La herramienta lee y escribe el mismo contador, así que un agente y un visitante trabajando la misma página tienen tres entre los dos y no tres cada uno. Eso exigió un cambio en el formulario, que leía el contador una sola vez al cargar la página y lo guardaba en una variable. Una copia en caché le da a cada superficie su propio presupuesto y deja que la que escriba la última deshaga a la otra, que es la clase de bug que solo aparece cuando existe una segunda superficie.

El endpoint es el mismo al que ya envía el formulario. Los campos con nombre se componen dentro del cuerpo del mensaje antes de que salga la petición, así que el handler existente no necesitó cambios para leerlos, y la carga útil lleva un campo source para que los mensajes enviados por agentes se puedan contar aparte de los tecleados sin analizar prosa.

Cómo verla funcionando

Este sitio sirve el token de la prueba, así que no hay que activar nada. Abre cualquier página de aquí con Chrome 149 a 156 y el panel de más arriba de este artículo te dirá si tu navegador tiene la herramienta, y luego el botón que hay debajo la llama de verdad.

Para comprobarlo tú mismo, pregúntale al navegador qué herramientas le han ofrecido:

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

Los dos nombres seguían resolviéndose en Chrome 151, que es el alias en su último hito. En Chrome 152 y posteriores solo responde document.modelContext.

En un sitio que no se ha inscrito en la prueba, document.modelContext es undefined y nada de esto se ejecuta. Lanzar Chrome con --enable-blink-features=WebMCP activa la API en local, que es la manera de desarrollar contra ella antes de tener un token.

Vale la pena conocer una diferencia entre la especificación y la implementación antes de que te cueste una tarde. La IDL tipa el segundo argumento de executeTool como un objeto, y pasar un objeto falla con UnknownError: Failed to parse input arguments, que no dice qué argumento ni por qué. Chrome quiere los argumentos serializados:

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

getTools() responde de la misma manera. El inputSchema de una herramienta devuelta llega como cadena JSON en lugar del objeto que se registró, así que cualquier cosa que lo lea de vuelta tiene que parsearlo primero.

Hay cosas más útiles sentadas en la misma página

El alta es por donde empezar porque el endpoint, el flujo de consentimiento y el email de confirmación ya existen. También es lo más pequeño de la página que merece la pena exponer.

Cada interacción que un visitante completa a mano es candidata, y las que llevan varios pasos son las que más ganan al reducirse a una sola llamada.

Las herramientas de solo lectura son el punto de partida más seguro. Poner readOnlyHint: true en una herramienta de búsqueda o de disponibilidad le dice al agente que la llamada no cambia nada, y un error cuesta una consulta desperdiciada en lugar de un registro escrito en tu base de datos.

Todo lo que está detrás de autenticación se queda detrás de autenticación. Una herramienta registrada corre en la página con la sesión que el visitante ya tenga, así que get_order_status está exactamente igual de protegida que la página de cuenta de la que lee, y no más.

Nada de esto cambia por qué se construyó el popup

Una herramienta solo se ejecuta después de que alguien haya pedido algo. Le dijo a su asistente que consiguiera el descuento, y el asistente encontró la función que lo hace. Esa persona iba a entregar una dirección por la vía que le dieras.

El popup apunta a la persona contraria. Alguien que no ha decidido nada y va de salida, pillado por un temporizador o por el ratón moviéndose hacia el botón de atrás. Se gana su sitio convirtiendo a gente que no iba a convertir, y esa es la única razón por la que un equipo acepta molestar a todos los demás para conseguirla.

Apagar el popup para el tráfico de agentes no cuesta por tanto nada, porque esos visitantes nunca fueron su objetivo. Borrarlo para todos renuncia a las direcciones que fue construido para cazar, junto con los años de email que salen de ellas.

A los equipos de marketing se les mide por lo rápido que crece la lista y por cuánto ingresan los emails de ciclo de vida. WebMCP no mueve ninguno de los dos números. Le da a un visitante dispuesto un camino más limpio y deja intacta la razón de la interrupción.

El soporte decide el resto. Solo Chromium, en pruebas que terminan en Chrome 156, con Apple en contra. Reemplazar un formulario de alta por una herramienta eliminaría el camino que usa casi todo visitante a cambio de uno que funciona en una fracción de un solo navegador.

Por ahora es una vía de entrada adicional. El popup se dispara menos a medida que llegan más visitas a través de asistentes, y desaparece del todo el día en que recoger una dirección deje de pagarse sola. Ninguna especificación puede adelantar ese día.

Un alta abierta es como la gente acaba enterrada en correo

Una herramienta de alta acepta una dirección de email que no puede comprobar y le envía correo. Cualquiera capaz de dirigir a un agente puede apuntarlo a cualquier buzón. Tu formulario tiene el mismo agujero, porque la dirección que hay detrás de ambos es una URL pública a la que un script puede enviar peticiones sin llegar a cargar tu página.

El ataque tiene nombre. En una campaña de list bombing, la dirección de una víctima se envía a cientos o miles de sitios a la vez, una petición a cada uno. Cada sitio ve un alta única y nada llama la atención en ninguna parte. La víctima recibe miles de emails de confirmación en una hora, y la avalancha suele ser tapadera de otra cosa que llega al mismo buzón: una alerta de fraude de su banco, un restablecimiento de contraseña, el recibo de una compra que alguien ha hecho con su tarjeta. Tu reputación de envío también se lleva un golpe, y esa es la parte más pequeña de lo que ha pasado.

Esa forma derrota la defensa a la que casi todo el mundo echa mano. Una limitación de tasa cuenta peticiones, y una campaña que te manda exactamente una petición no le deja nada que contar.

Cuatro cosas sí ayudan.

Pon un desafío delante del alta, para que un envío automatizado tenga que superar algo que una persona real pasa sin enterarse.

Deduplica por dirección y mantén una lista de supresión, para que el mismo buzón no pueda darse de alta una y otra vez y para que una segunda petición sobre una dirección con una confirmación ya pendiente no envíe nada en absoluto.

Pide a la gente que confirme antes de añadirla a una lista, para que una llamada abusiva no pueda producir una suscripción. Una salvedad que pilla a mucha gente: bajo la ley antispam de Canadá, un email de confirmación cuenta como mensaje comercial por derecho propio, así que enviarlo a una dirección que nunca lo pidió es la infracción y no la protección. Los tribunales alemanes se han dividido sobre la misma cuestión. La confirmación es el valor por defecto correcto en casi todas partes y no es universal.

Registra de dónde vino cada alta en el mismo momento en que se escribe la fila. Deducirlo después de un incidente significa adivinar qué direcciones eran reales.

Demostrar el consentimiento es más difícil cuando quien hizo clic fue un software

Un envío de formulario produce un registro de lo que el visitante vio. La casilla, la etiqueta que hay al lado, el enlace de privacidad y la marca de tiempo están todos en tu lado.

Una llamada a una herramienta produce una dirección de email en un argumento de función. Lo que se le dijo al visitante antes de que el agente actuara pasó en una conversación a la que no tienes acceso. Bajo el RGPD, el consentimiento tiene que ser libre, específico, informado e inequívoco, y el responsable tiene que poder demostrarlo después. Una dirección que llega a través de un agente no satisface nada de eso por sí sola.

El doble opt-in carga con casi todo el peso aquí por segunda vez. El email de confirmación va a la propia dirección, y pulsarlo produce una acción con marca de tiempo de la persona suscriptora y no de algo que actúa por ella. Mantén las altas mediadas por agentes distinguibles en el almacenamiento para que una auditoría pueda separarlas de los envíos de formulario en lugar de tratar la lista entera como una sola procedencia.

Estas altas desaparecen en silencio, así que monta primero el conteo

Un agente que llama a una herramienta registrada ejecuta un callback dentro de la página. No hay vista de página, ni evento de envío de formulario, y con frecuencia ninguna sesión en el sentido que le da una herramienta de analítica de navegador. La conversión ocurre y la persona suscriptora es real, mientras el informe no muestra nada. Monta esto mal y el fallo es silencioso: las suscripciones suben, ninguna fuente las explica, y no hay nada en la interfaz que parezca roto.

Es el mismo hueco estructural que esconde los crawlers de IA y las referencias de IA de las analíticas de navegador, apareciendo en una capa nueva. Un crawler nunca ejecuta el JavaScript que lo reportaría. Un agente ejecuta el JavaScript, y ejecuta la parte que completa la conversión mientras se salta cada parte que la habría medido.

La petición que llega a tu endpoint de alta es el único sitio donde la conversión existe en una forma que te pertenece. Etiquétala ahí, en logs propios, y el canal pasa a ser algo cuyo tamaño puedes estimar el trimestre que viene.

Cuatro cosas que evitan que desaparezcan

Estampa el origen en el servidor, en la misma escritura que crea la suscripción. La página envía un campo de origen con la petición, y el servidor lo pone en la fila junto a la dirección y la marca de tiempo. Deducirlo después a partir de la redacción del mensaje es adivinar, y el referrer no te va a salvar, porque los agentes con frecuencia no envían ninguno.

Reporta el alta antes de la llamada de red y no dentro del handler de éxito. Una llamada que se abandona a medias, o que falla después de que el servidor ya haya hecho el trabajo, nunca llega a la rama de éxito. Repórtala a la salida y cuentas el intento, que es el número que realmente quieres.

Crea el evento en tu herramienta de analítica antes de publicar la herramienta. Los eventos personalizados se aceptan a menudo y luego se caen de todos los informes hasta que existe un objetivo con un nombre que coincida, así que un evento no registrado devuelve un código de éxito y no aparece en ninguna parte. El silencio en el panel no es prueba de que no se disparara nada, y es la manera más fácil que hay de gastar una semana depurando código que llevaba todo el rato funcionando.

Reconcilia una vez por semana, a propósito. Cuenta las filas de tus propios datos que llevan el origen de agente, y compara eso con lo que muestra tu analítica para los mismos días. Dos números que coinciden significan que la tubería está intacta. Un hueco es del tamaño de tu punto ciego. Tráfico en un lado y un cero en el otro significa que el evento no está llegando en absoluto, y ahora lo sabes en una semana en lugar de al final del trimestre.

Qué hacer al respecto este trimestre

Registrar una herramienta lleva una tarde. Empieza por la oferta por la que ya interrumpes a la gente, porque el endpoint, el flujo de consentimiento y el email de confirmación están construidos y funcionando.

Conserva el formulario. Casi todo el que visite lo seguirá usando, y eso se mantiene mientras Apple sostenga su posición.

Usa document.modelContext, e inscríbete en la prueba de Chrome si quieres que los visitantes corrientes alcancen la herramienta y no solo los desarrolladores con un flag activado.

Añade el campo de origen a tu endpoint de alta antes de publicar la herramienta. Hacerlo después significa que no podrás saber cuáles de las altas que ya tienes en la base de datos vinieron de un agente.

Lee los resultados en tu propio servidor. Una propiedad de analítica no te mostrará estas altas en absoluto, y nada dentro de ella parece roto mientras se quedan sin contar.

El número que merece vigilancia no es ninguno de los anteriores. Es la proporción de tus visitas que llega a través de un asistente, que es lo que decide cuándo esto deja de ser un experimento, y hoy puedes medirlo desde tus logs registres o no una herramienta alguna vez.