API oficial o scraping del navegador: de dónde salen los datos

Toda herramienta de visibilidad en IA tiene que sacar sus respuestas de alguna parte. Antes de que un panel pueda decirte que Gemini te nombró al responder sobre software de nóminas en alemán, algo tiene que hacerle esa pregunta a Gemini de verdad y leer lo que vuelve. Solo hay dos maneras de conseguirlo, y casi ningún comprador pregunta cuál de las dos está pagando.

No es una curiosidad técnica. El método de recogida decide qué significan tus datos, cuán estables son con el tiempo y si la puntuación que miras describe el sistema con el que habla tu cliente o un pariente cercano de ese sistema.

Dos puertas al mismo modelo

La API oficial

Todos los grandes proveedores de modelos exponen una interfaz programática. Envías una petición con una pregunta dentro, nombras un modelo y recibes texto de vuelta. Es la misma tubería que usan los desarrolladores para construir aplicaciones sobre ChatGPT, Claude, Gemini o Perplexity. Una herramienta que recoge así empuja tu conjunto de preguntas por esa tubería según un calendario y guarda las respuestas.

El navegador

El otro camino consiste en manejar el producto de consumo igual que lo haría una persona. Abrir un navegador, entrar en una cuenta, escribir la pregunta en la caja de chat, esperar a que la respuesta termine de aparecer y raspar el texto de la página. En la práctica esto significa automatización de navegadores sin interfaz, a menudo enrutada por proxies residenciales para que el tráfico no parezca automático, y a veces con retrasos artificiales entre pulsaciones para sobrevivir a la detección de bots.

Los dos métodos terminan en un bloque de texto que menciona tu marca o no la menciona. Ahí se acaba el parecido.

Por qué las dos puertas no devuelven la misma respuesta

La interfaz de chat de consumo no es una piel fina sobre la API. Es un producto, y los productos tienen opiniones. Entre la caja donde escribes y el modelo que contesta se interponen varias capas:

• Un prompt de sistema que nunca ves. El producto de chat viene con sus propias instrucciones sobre tono, seguridad, formato y cuándo buscar en la web. La API, por defecto, no carga con esas instrucciones. Los mismos pesos del modelo, otras órdenes.
• Una recuperación que puede dispararse o no. La aplicación de consumo puede decidir por su cuenta salir a buscar en la web en vivo antes de responder. Una llamada a la API contesta con lo que el modelo absorbió durante el entrenamiento salvo que actives explícitamente una herramienta de búsqueda. Esta sola diferencia puede cambiar a una marca de ausente a presente, porque una empresa joven a la que los datos de entrenamiento apenas conocen sí puede encontrarse mediante una búsqueda en vivo.
• Memoria y personalización. Una cuenta con sesión iniciada acumula contexto: conversaciones anteriores, preferencias declaradas, instrucciones personalizadas. La llamada a la API es un desconocido cada vez.
• Enrutado. Los productos de consumo deciden cada vez más por ti qué modelo atiende una petición, y cambian esa lógica sin avisar a nadie. La API te obliga a nombrar un modelo.

El efecto neto es que la misma pregunta, hecha por las dos puertas la misma tarde, puede devolver dos listas distintas de proveedores recomendados. Ninguna está equivocada. Son respuestas a preguntas ligeramente distintas.

En qué acierta cada método

La API es reproducible. Sabes a qué modelo consultaste, puedes volver a consultarlo con los mismos parámetros y, si la respuesta cambia, puedes sospechar razonablemente que cambió la web y no el aparato de medida. Está versionada, así que un proveedor puede decirte exactamente qué se preguntó y a quién. Escala sin pelearse con nadie, y es lo que el proveedor construyó para el acceso programático, lo que significa que nadie está fingiendo ser un ser humano para conseguirlo.

El navegador está más cerca de la experiencia vivida. Si quieres saber qué ve tu comprador de carne y hueso, en la superficie que usa de verdad, con el interruptor de búsqueda en el estado en el que venga hoy por defecto, el navegador es lo único que te lo enseña. Es un argumento real y merece tomarse en serio.

En qué falla cada método

La debilidad honesta de la API es que es un sustituto. No es literalmente la pantalla que mira tu cliente. Si una herramienta consulta a un modelo sin la recuperación activada y te informa de que eres invisible, te ha dicho algo cierto sobre lo que el modelo sabe y algo incompleto sobre lo que habría contestado la aplicación de consumo. Un proveedor que no aclara esto te está dejando sacar la conclusión equivocada.

Las debilidades del scraping de navegador son más numerosas y se comentan menos:

• Se rompe. Un cambio de maquetación del lado del proveedor puede corromper el análisis del texto sin hacer ruido. El fallo peligroso no es el escandaloso, ese en el que la herramienta no devuelve nada. Es el silencioso, ese en el que sigue devolviendo algo y ese algo ya es falso.
• Es adversarial. Los proveedores detectan y bloquean la automatización de forma activa, y sus condiciones de servicio suelen prohibirla. Construir un producto de datos sobre un método de recogida que la otra parte intenta cerrar es un modelo de negocio frágil, y la fragilidad te la pasan a ti.
• Cuesta reproducirlo. Qué cuenta, con qué plan, con qué memoria, desde qué red, con qué funciones activadas para esa cuenta esta semana. Cambia cualquiera de esas cosas y habrás cambiado el experimento.
• La propia cuenta va derivando. Lanza tus preguntas durante meses desde la misma cuenta con sesión iniciada y la cuenta acumula historial. La herramienta pasa entonces a medir lo que le cuentan a un usuario muy raro, uno que no hace más que preguntas de investigación competitiva.

El compromiso que nadie quiere decir en voz alta

Aquí no hay respuesta correcta, solo una elección entre fidelidad a la superficie de consumo y reproducibilidad de la medición. Puedes estar cerca de lo que ve el usuario, o puedes tener la certeza de que un cambio en tu puntuación significa un cambio en el mundo y no un cambio en tu raspador. Optimizar las dos cosas a la vez es marketing, no ingeniería.

A lo que tienes derecho no es a un método perfecto. Es a un método declarado. Un proveedor que no quiere contarte cómo recoge sus datos te está pidiendo que confíes en un número cuya procedencia considera un secreto, y es una petición extraña que hacerle a alguien que compra un producto de medición.

Qué preguntar antes de comprar

• ¿Consultáis las API oficiales o automatizáis la interfaz web? Una respuesta vaga aquí ya es una respuesta.
• Si son API: ¿está activada la búsqueda web o la recuperación durante la consulta, y puedo ver ese ajuste?
• Si son API: ¿qué versión del modelo, y me avisáis cuando cambia por debajo?
• Si es navegador: ¿desde qué clase de cuenta, y qué le pasa a mi histórico cuando cambie la interfaz?
• En cualquier caso: ¿cuántas veces lanzáis cada pregunta antes de informar de un resultado? Una ejecución suelta de un sistema probabilístico es una anécdota.
• ¿Puedo ver el texto en bruto de la respuesta que hay detrás de cada mención que afirmáis, o solo la puntuación agregada?

Nuestro método, dicho sin rodeos

PSentry recoge a través de las API oficiales de las cuatro plataformas que cubre: ChatGPT, Claude, Gemini y Perplexity. Es una declaración de método, no una proclama de superioridad. Elegimos la reproducibilidad por delante de la fidelidad a la interfaz de consumo, porque una respuesta raspada arrastra una varianza que no sabemos separar de la señal que intentamos medir, y porque una comparación entre idiomas y mercados solo merece la pena si el aparato es el mismo en todos ellos.

El coste de esa elección es real y no lo vamos a esconder: estamos midiendo lo que los modelos dicen por la puerta que los proveedores construyeron para las máquinas, no por la puerta que cruza tu cliente. Los análisis se lanzan según calendario, dos veces al mes, y puedes leer las respuestas que hay debajo en vez de fiarte de la puntuación. Si una herramienta no te enseña el texto, la puntuación es un rumor.

Preguntas Frecuentes

¿El scraping de navegador es ilegal?

La legalidad y las condiciones de servicio son cuestiones distintas, y no somos abogados. Lo que no admite discusión es que los grandes proveedores prohíben en sus condiciones el acceso automatizado a sus interfaces de consumo e invierten en detectarlo. Eso es un riesgo de negocio metido dentro de tu canal de datos, y deberías saber si está ahí.

Si las API contestan con datos de entrenamiento, ¿no las vuelve eso inservibles para medir visibilidad?

No, pero las convierte en otra lente. Lo que un modelo dice sin buscar te cuenta qué ha interiorizado sobre tu marca, que es la señal más lenta y más duradera. Un resultado de búsqueda en vivo puede cambiar mañana. Las dos cosas merecen conocerse, y una herramienta debería decirte cuál te está enseñando.

¿Puede una herramienta hacer las dos cosas?

En principio. En la práctica tendrías entonces dos conjuntos de datos que se contradicen, y alguien tiene que decidir cuál se convierte en la puntuación del panel. Pregunta cómo se hace esa reconciliación, porque ahí es donde se esconden los supuestos interesantes.

¿Cómo pillaría a un proveedor que cambió su método de recogida sin decirlo?

Busca una discontinuidad en tu propio histórico: un salto en la puntuación que no encaja con nada que hicieras ni con nada que pasara en tu mercado. Después pide las respuestas en bruto a un lado y a otro del escalón. Si no pueden dártelas, ya has aprendido algo.

¿El método de recogida importa más en unos negocios que en otros?

Importa sobre todo si vendes en varios idiomas. Las diferencias entre mercados suelen ser sutiles, y un método de recogida ruidoso o que va derivando las ahoga. Si solo miras un idioma, puedes tolerar más ruido, porque la señal que buscas es más gruesa.