Cómo crear un prompt tracker propio para medir tu visibilidad en ChatGPT, Gemini y Claude

Desde los años 2000, cualquier SEO que se precie empieza la mañana igual: abre su herramienta de rank tracking de referencia y revisa qué posiciones se han movido durante la noche. Café, dashboard, primera lectura del día. Ese ritual llevaba dos décadas prácticamente intacto, hasta que la irrupción de la IA generativa en los hábitos de búsqueda de los usuarios lo puso patas arriba. Ahora la pregunta ya no es solo «¿en qué posición salgo en Google?», sino «¿me menciona ChatGPT cuando alguien le pregunta por mi sector?». Y para responder a eso con algo de rigor hace falta una herramienta nueva: el prompt tracker.

Resumen rápido, si vas con prisa:

• Construí mi propio prompt tracker con n8n y Supabase para medir si ChatGPT, Gemini y Claude mencionan a workINcompany, un coworking de Sevilla, cuando responden preguntas de su sector.
• Los LLMs no son deterministas: hay que repetir cada prompt varias veces en la misma sesión y medir el porcentaje de menciones, no la posición.
• Usé tres tipos de prompt (termómetro, semilla, control) y separé las categorías de intención, porque no comparten competidores entre sí.
• Consulté por API, no replicando la interfaz real de usuario, con calibración manual periódica para no perder de vista la diferencia entre ambas vías.
• Por el camino: errores silenciosos, límites de tokens agotados y hasta una cuenta sin saldo. Ningún obstáculo de estos aparece en la documentación de venta de ninguna herramienta comercial.

Cuando empecé a mirar en serio qué había disponible para medir esto, di con el artículo de Natzir Turrado Herramientas para medir visibilidad en la IA: lo que no te cuentan los prompt trackers. Su tesis es incómoda pero difícil de rebatir: la mayoría de estas herramientas comerciales prometen medir algo que, tal y como está planteado, es imposible medir con precisión. Inspirada por ese artículo, y viendo que ninguna herramienta comercial de prompt tracking me iba a dar una visión objetiva y general de mi visibilidad en IA (cada una mide a su manera, con su propia caja negra), me planteé el desafío de construir yo misma un prompt tracker. Consciente de sus limitaciones desde el principio, pero segura de que en el proceso aprendería mucho sobre cómo nos dan los LLMs sus resultados, que era al final lo que de verdad me interesaba.

Este post documenta ese proceso completo: cómo se diseña un prompt tracker desde cero, qué decisiones metodológicas hay detrás de cada pieza, y todos los obstáculos técnicos reales que me encontré montándolo con n8n y Supabase sobre un negocio real: workINcompany, el primer coworking de Sevilla y Andalucía (abierto en 2011), en pleno centro de la ciudad, pensado para autónomos, freelancers y pequeñas empresas que necesitan un puesto de trabajo, una sala de reuniones o una oficina virtual sin montar oficina propia. Lo uso como sujeto de pruebas real, no como ejemplo de laboratorio. No es un resumen bonito. Incluyo los errores, los callejones sin salida y las veces que tuve que rehacer algo desde cero.

Si buscas cómo crear un prompt tracker porque quieres entender el problema en profundidad, no solo activar una funcionalidad de pago, este post es para ti.

Qué es un prompt tracker y por qué no es un rank tracker con otro nombre

Un prompt tracker es un sistema que lanza preguntas predefinidas contra modelos de lenguaje (ChatGPT, Gemini, Claude, Perplexity...) y registra si tu marca aparece mencionada, con qué frecuencia y junto a qué competidores. La tentación, viniendo del mundo SEO, es tratarlo como un rank tracker adaptado a IA. Es un error que condiciona mal todo el diseño posterior.

Un buscador tradicional, para la misma consulta y las mismas condiciones, devuelve resultados prácticamente idénticos si lo consultas dos veces seguidas. Un LLM no. Puedes lanzar el mismo prompt dos veces, en el mismo minuto, y recibir listas de marcas distintas, en orden distinto, con menciones que aparecen en una respuesta y desaparecen en la siguiente. Esto no es un fallo del sistema que estás midiendo, es una propiedad estructural de cómo generan texto los modelos. Cualquier prompt tracker que no lo tenga en cuenta desde el diseño está produciendo una métrica de fantasía.

Antes de tocar una sola línea de código, conviene entender de dónde sale cada decisión de arquitectura. Es lo que explico a continuación.

Los fundamentos: qué hace que un prompt tracker sea metodológicamente sólido

La falta de determinismo obliga a repetir, y a repetir bien

Si un mismo prompt puede dar respuestas distintas en el mismo instante, una sola ejecución no vale nada como dato. Hacen falta repeticiones. Pero no cualquier repetición sirve: tienen que lanzarse juntas, en la misma sesión y franja horaria, no una al día repartidas durante un mes. Si las repartes en el tiempo no estás midiendo 30 repeticiones del mismo estado del sistema, estás midiendo 30 estados distintos (el modelo puede actualizarse, los resultados de búsqueda web que recupera pueden cambiar), y mezclas variables que interesa mantener separadas.

La posición no es la métrica que importa

Es tentador fijarte en si tu marca sale primera o segunda, igual que en un ranking de Google. Con LLMs esto es poco fiable: el orden de las marcas citadas varía enormemente entre repeticiones idénticas del mismo prompt, así que no aporta información estable. La métrica que sí aguanta la naturaleza estadística del fenómeno es mucho menos vistosa: el porcentaje de repeticiones en las que tu marca aparece mencionada, sobre el total de ejecuciones válidas. La posición se puede seguir registrando como dato cualitativo, pero etiquetada explícitamente como de baja confianza.

Grounded vs. no grounded: saber si el modelo buscó de verdad

Un LLM responde de dos formas muy distintas: tirando de lo que aprendió en su entrenamiento (conocimiento paramétrico, potencialmente desactualizado) o haciendo una búsqueda web real en el momento de responder. Un prompt tracker serio registra explícitamente cuál de las dos ocurrió en cada ejecución, no solo el texto de la respuesta:

Tres tipos de prompt, tres funciones distintas

Comparar cómo responde cada tipo de prompt es en sí mismo un hallazgo: una marca puede dominar los prompts termómetro y fallar en los semilla, señal de que su fuerza SEO no se está traduciendo en cómo la gente formula sus necesidades reales delante de un asistente de IA.

Categorías de intención independientes

Un mismo negocio puede resolver necesidades de compra completamente distintas, cada una con su propio conjunto de competidores reales. En el caso de workINcompany encontré tres categorías con competidores que no se solapan en absoluto: coworking físico, domiciliación fiscal y alquiler de salas para eventos. Medirlo todo como un único mercado homogéneo produce comparaciones sin sentido.

Por qué consultar por API no es lo mismo que preguntarle a tu ChatGPT de siempre

Aquí conviene pararse, porque es una de las partes que menos se entiende de un prompt tracker automatizado. Cuando abres ChatGPT, Gemini o Claude en tu navegador y escribes una pregunta, no estás hablando con «el modelo» a pelo. Estás hablando con una capa completa alrededor del modelo: la interfaz añade sus propias instrucciones de sistema, puede tener memoria de conversaciones anteriores asociada a tu cuenta, decide con su propio criterio cuándo lanzar una búsqueda web, y en el caso de ChatGPT, decide qué fuentes citar y cuántas. Cuando llamas al mismo modelo por API, buena parte de esa capa desaparece: tú controlas el prompt de sistema y parámetros como la temperatura, y en muchos casos ni siquiera hay búsqueda web real salvo que actives explícitamente esa herramienta (con el coste extra que conlleva).

La consecuencia práctica: mismo modelo, mismo prompt, resultado distinto según por dónde entres. Es algo que herramientas especializadas en monitorización de IA como Otterly.AI han documentado de forma sistemática: la API de ChatGPT no siempre dispara búsqueda web aunque la interfaz sí lo haría para la misma pregunta, y cuando cita fuentes por API, el número y la selección no coinciden con lo que vería un usuario real.

Y aquí llega el dilema que hay que resolver antes de automatizar nada: si quieres un sistema que se ejecute solo, sin que alguien esté copiando y pegando preguntas cada mañana, ¿tienes que usar la API sí o sí? La respuesta corta es que técnicamente no, pero en la práctica casi siempre sí.

Existe una alternativa: automatizar un navegador (con herramientas tipo Playwright o Puppeteer) para que abra literalmente la interfaz web, escriba el prompt como lo escribiría una persona, y lea la respuesta tal cual se renderiza en pantalla. Esto replicaría de verdad lo que ve un usuario, y algunas herramientas de GEO más sofisticadas lo hacen. Descarté esta vía para mi prompt tracker por tres motivos concretos:

Decidí quedarme con la API para la parte automatizada, y reservar la interfaz real, en incógnito y sin historial, para calibraciones manuales periódicas como control de calidad. Es la solución de compromiso: automatización barata y escalable por un lado, control de calidad manual por otro, sabiendo en todo momento qué mide cada vía y por qué no son intercambiables.

Antes de montar nada: la investigación previa

Un prompt tracker sin una investigación de buyer persona real detrás es un generador de keywords disfrazado de herramienta de IA. Antes de escribir un solo prompt semilla, hice una investigación de comprador bastante más profunda de lo habitual, triangulando varias fuentes independientes:

• Entrevistas reales publicadas en el blog del propio negocio (voz de cliente literal, no inferida)
• El directorio público de empresas colaboradoras del servicio de domiciliación
• 100 reseñas reales de Google Business Profile, scrapeadas con Apify para superar el límite de 5 reseñas de muestra que da la API de Google Places
• Marketplaces y agregadores del sector (algunos confirmaron segmentos de comprador que no estaban en el radar inicial, como el alquiler de espacio para eventos y producciones)

De ahí salieron cinco segmentos de comprador reales, cada uno confirmado por al menos dos fuentes independientes, y de ahí salieron los prompts semilla. Sin ese trabajo previo, cualquier prompt tracker mide keywords inventadas, no necesidades reales.

También construí un baseline técnico completo antes de tocar nada (autoridad de dominio, tráfico, distribución de keywords, y sobre todo, qué fuentes citan hoy a la marca cuando la IA responde sobre ella). Un dato que me pareció especialmente revelador: el propio dominio de workINcompany ocupaba solo el tercer puesto como fuente citada sobre sí mismo, por detrás de dos agregadores de terceros. Ese es exactamente el tipo de hallazgo que un prompt tracker bien diseñado tiene que poder detectar.

La arquitectura técnica: n8n + Supabase

Con los fundamentos claros, la implementación se apoya en tres piezas.

Base de datos (Supabase), con tres tablas separadas por una razón deliberada: los prompts cambian poco una vez diseñados, los competidores se van descubriendo con el tiempo y crecen de forma independiente, y las ejecuciones son el único dato que se multiplica semana a semana. Mezclarlo todo en una tabla habría dificultado el análisis.

Orquestación (n8n), con un flujo sencillo en cuatro pasos:

1. Trigger programado que lanza la ronda de prompts
2. Envío de cada prompt contra las tres plataformas (ChatGPT, Gemini, Claude)
3. Extracción de datos estructurados de cada respuesta con un modelo económico
4. Inserción de esos datos en Supabase

Modelos económicos para el tracking automatizado (mini/flash/haiku en vez de los modelos flagship), siguiendo la misma práctica que herramientas comerciales como SISTRIX documentan abiertamente, combinado con la calibración manual periódica en interfaz real que mencionaba antes.

Los obstáculos reales (esto es lo que nadie cuenta)

Aquí es donde un post sobre cómo crear un prompt tracker se diferencia de una página de producto. Estos son los problemas reales que me encontré, en orden:

Ninguno de estos problemas aparece en la documentación de venta de ninguna herramienta comercial de prompt tracking. Aparecen cuando lo construyes tú.

Qué dicen los primeros datos (con mucha cautela)

Todo lo anterior es metodología. Esto es lo que salió al aplicarla sobre workINcompany, en 144 ejecuciones repartidas entre tres motores, tres tipos de prompt y tres categorías de intención.

Antes que nada, la advertencia que pesa más que cualquier número de aquí abajo: esto es una única tanda de ejecuciones, en una sola sesión. Es una fotografía, no una tendencia. Antes de tomar ninguna decisión de negocio con esto hace falta repetir la ronda semana a semana y comprobar si estos porcentajes se sostienen o si son solo el estado puntual de los modelos ese día concreto. Es la misma lógica que exige la falta de determinismo explicada más arriba: una ejecución no es un dato, es una muestra.

Gemini es, en esta tanda, el motor donde workINcompany aparece con más frecuencia, casi el doble que en Claude. Pero antes de leerlo como «a Claude le cuesta más vernos», hay un matiz importante: Claude también es el motor que menos veces activó la búsqueda web real. Y aquí llega el dato más claro de toda la tanda:

Cuando el modelo no sale a buscar en la web, la mención de workINcompany fue cero. Ninguna de las 15 ejecuciones sin búsqueda real mencionó la marca. Esto confirma algo que ya se apuntaba en el apartado de fundamentos: los modelos no tienen «memoria» propia de workINcompany, su visibilidad depende por completo de que el motor decida salir a buscar en ese momento. Ningún contenido evergreen va a cambiar esto si el modelo no busca.

Hay una caída de casi 30 puntos entre el prompt termómetro (la keyword pura, «coworking sevilla») y el prompt semilla (la necesidad en lenguaje natural). El posicionamiento SEO de workINcompany en esas keywords no se está traduciendo igual cuando alguien formula su necesidad real con sus propias palabras. Es justo el tipo de hallazgo que este enfoque está pensado para sacar a la luz, y que un rank tracker normal nunca vería.

El punto débil es evidente: eventos. En la keyword «alquiler sala eventos sevilla centro» no hubo ni una sola mención en 9 ejecuciones. El coworking físico, en cambio, es donde la marca domina con más margen, coherente con que sea su línea de negocio histórica y más consolidada en SEO.

Un último dato, cuando la marca sí aparece mencionada: de las 83 menciones totales, 47 la colocan en primer lugar (56,6%), 20 en segundo (24,1%), y el resto reparte posiciones del tercer al quinto puesto. Es decir, cuando workINcompany aparece, casi siempre aparece bien. El problema no es la posición cuando aparece, es la frecuencia con la que aparece en unos escenarios y en otros no.

Una nota de calidad de dato, honesta: el mismo competidor apareció registrado dos veces con nombres distintos («Thinking Company» y «THINKING COMPANY COWORKING»), lo que significa que hace falta normalizar nombres de marca en el pipeline de extracción antes de fiarme del todo del ranking de competidores. También el 57,6% de las ejecuciones no llevaban fuentes citadas pese a estar grounded en su mayoría, algo coherente con lo que documenta Otterly.AI sobre la API de ChatGPT.

Y aquí sí puedo comparar API con interfaz real, porque hice la calibración manual que mencionaba antes: tres prompts (uno de coworking físico repetido con dos redacciones distintas, y uno de domiciliación) lanzados contra ChatGPT, Gemini y Claude desde cuentas sin historial, en incógnito, copiando la respuesta tal cual la vería un usuario cualquiera.

8 de las 9 comprobaciones manuales mencionan workINcompany (88,9%), y en las 8 en que aparece, lo hace siempre en primer lugar. Es un porcentaje muy parecido al que dan en la API los prompts termómetro y control para las mismas categorías (66,7% y 88,9%), lo que da bastante confianza en esa parte de los datos automatizados.

El hallazgo interesante está en la excepción: en la comprobación manual, ChatGPT es el único de los tres motores que no menciona workINcompany al preguntar por domiciliación de empresa, mientras que Gemini y Claude sí la incluyen en primer lugar. Es exactamente el tipo de divergencia entre API e interfaz que se explicaba más arriba: mismo motor, canal distinto, resultado distinto. Con solo tres prompts comprobados a mano es una muestra mínima como para sacar conclusiones firmes, pero confirma que la calibración manual periódica no es un trámite de checklist: es la única forma de detectar este tipo de discrepancias, y toca ampliarla y repetirla con la misma disciplina que las rondas de la API.

Prompt tracker propio vs. herramienta comercial: ventajas e inconvenientes reales

Con qué me quedo de todo esto

Ninguna herramienta de medición de visibilidad en IA, comercial o propia, va a darte una fotografía perfecta de la realidad. Los propios modelos no responden lo mismo dos veces seguidas, la diferencia entre lo que ve una API y lo que ve un usuario real es constatable, y cualquier sistema que se precie tiene que asumir esa imperfección como punto de partida, no como algo que esconder detrás de un dashboard bonito.

Lo que cambia cuando te construyes el tracker tú misma, en vez de contratar algo ya hecho, es el nivel de control. Decides qué categorías de intención tienen sentido para tu negocio concreto. Decides hasta dónde llega tu investigación de comprador. Decides qué nivel de detalle guardas de cada fallo. Una herramienta comercial te entrega una cifra. Construir la tuya te obliga a entender, obstáculo a obstáculo, qué hay detrás de esa cifra.

Y esa comprensión, más que la cifra en sí, es lo que convierte un prompt tracker en algo útil de verdad para tomar decisiones, en vez de en un número bonito sin contexto.

¿Te estás planteando montar tu propio prompt tracker o prefieres entender antes qué hay detrás de las herramientas del mercado? Escríbeme, es exactamente el tipo de problema que me gusta desmenuzar.