Skip to main content
Los monitores repiten un conjunto guardado de prompts según un calendario y puntúan las respuestas de IA resultantes para tu marca y sus competidores. Esta página es el contrato de la API: cómo configurar un monitor, qué significa cada cifra, cómo leer las fuentes que hay detrás y cómo exportar las respuestas subyacentes. Para ver los mismos datos en el panel, empieza por la guía del producto. Todas las claves, ids, marcas y prompts de esta página son ejemplos. Nada de esto es una credencial ni un monitor real.

Qué es un monitor

Un monitor es un conjunto de prompts con nombre en un mercado: una lista de prompts, los motores a los que se envían, los alias que significan «tu marca», opcionalmente tus dominios y algunos competidores, un país y un intervalo. Cada ejecución programada envía prompts × motores tareas asíncronas normales, y cada respuesta terminada se puntúa una vez y se conserva. La puntuación es deliberadamente acotada, y los datos no pueden responder más de lo que almacenan:
  • Registra si un alias de marca aparece en el texto de la respuesta y en qué offset de carácter; si la respuesta citó uno de tus dominios registrados; y cuáles de tus competidores configurados aparecieron en la misma respuesta.
  • No produce una puntuación de sentimiento ni una estimación de cuota de mercado. Una posición es un lugar entre las marcas que mencionan las respuestas, como en el ranking de un monitor de categoría (más abajo).

Los competidores se encuentran solos

No hace falta que listes competidores. Cuando termina la primera ejecución de un monitor, leemos sus respuestas recientes con un modelo de lenguaje y nos quedamos con las marcas que venden lo mismo que tú y aparecen en al menos dos respuestas, hasta 15. La lectura se repite cada 30 días, así que los rivales nuevos entran y los que dejan de nombrarse salen.
  • Los competidores encontrados llevan source: "auto". Los que añades tú llevan source: "user", y la lectura nunca los cambia ni los quita.
  • Cuando cambia la lista encontrada, las respuestas guardadas del monitor se vuelven a contar con ella, para que todas las marcas de un informe se midan sobre las mismas respuestas. competitorsReadAt en el monitor indica cuándo fue la última lectura.
  • Los nombres en alfabeto latino coinciden como palabras completas, así que «replicates» no cuenta como mención de la marca Replicate.

Separa los monitores con intención

Monitores distintos representan temas o mercados distintos, y son informes distintos: cada uno tiene su propia ventana, su propia definición de puntuación y su propio calendario. Dos hábitos compensan:
  • Un monitor por tema y mercado, para que la cohorte del informe siga siendo comparable. Mezclar «mejor CRM» y «cómo poner precio a un CRM» en un conjunto promedia dos intenciones distintas en una sola cifra.
  • Redacta los prompts como lo haría un comprador y nunca incluyas tu propia marca. Un prompt que contiene la marca siempre es una mención, así que informa 100 % para siempre y no mide nada. Los nombres de competidores están bien y suelen ser los prompts más útiles que puedes escribir.

Monitores de categoría: ordena las marcas de un mercado

Un monitor de marca sigue una marca. Un monitor de categoría sigue un mercado: nombras la categoría, agrupas sus preguntas por subárea y el informe ordena las marcas que mencionan los motores al responder. Establece "mode": "CATEGORY" al crear el monitor. mode es BRAND por defecto y no cambia durante toda la vida del monitor, porque decide qué significa cada fila almacenada.
El calendario, el coste, la ventana, los filtros, quality, las fuentes, las citas, los resultados y las respuestas funcionan igual que en un monitor de marca. Un monitor de categoría no tiene alerta, así que POST /v1/monitors/{id}/alerts/test devuelve 400.

Qué ordena el informe

GET /v1/monitors/{id}/analytics devuelve la vista de categoría. stats y previous contienen runs, named (respuestas que mencionan al menos una marca seguida) y namedRate; changes.namedRatePp es el cambio en puntos, y el objeto category contiene el ranking:
  • rank ordena las marcas por el número de respuestas que las mencionan: es un puesto entre las marcas que mencionan estas respuestas. Una marca que ninguna respuesta mencionó tiene rank: null.
  • El mentionRate de una marca se divide entre su propio sampleSize, las respuestas puntuadas mientras la marca estaba en la lista. Una marca que añades hoy se mide desde hoy.
  • shareOfVoice es 100 × menciones de esa marca / todas las menciones de marcas seguidas en la ventana, así que las cuotas de una ventana suman 100.
  • GET /v1/monitors añade leader (la marca más mencionada, con su tasa) a cada monitor de categoría. Sus recuentos mentioned y cited son siempre 0.
  • GET /v1/monitors/{id}/answers/{taskId} devuelve mode, un aliases vacío y las marcas seguidas como competitors.

Investiga los prompts a partir de la demanda de búsqueda

POST /v1/monitors/research acepta el cuerpo de la solicitud de Prompt Research, cuesta los mismos 12 créditos y devuelve el mismo resultado, enviado a nombre de tu cuenta. Lee la tarea en cola con GET /v1/async/task/{id}; el id está en data.task.id de la respuesta.
Usa monitorSet.prompts como prompts, el topic de cada prompt como su subárea en promptTopics y brands[].brand como competitors. El botón Ejecutar investigación del panel hace lo mismo y rellena el formulario; no se guarda nada hasta que creas el monitor.

Coste y calendario

Una ejecución encola una tarea por prompt y por motor, al precio en créditos publicado de cada motor. El calendario se repite hasta que pausas o eliminas el monitor, así que al crearlo estás eligiendo un coste recurrente:
Por ejemplo, 12 prompts en ChatGPT (2 créditos) y Gemini (1 crédito) son 24 tareas y 36 créditos por ejecución, unos 1.080 créditos al mes con un intervalo diario. Lee los precios actuales del endpoint de capabilities en lugar de fijarlos en el código. Conviene conocer dos propiedades del calendario antes de depender de él:
  • Una ejecución no es una ráfaga. Las tareas se admiten según lo permitan la concurrencia del plan y la cola, así que una ejecución que supera el límite de un plan gratuito llega a lo largo de varios minutos en lugar de descartarse. Consulta health.pending en un informe para ver una ejecución en curso.
  • La siguiente ventana es un momento, no una garantía. nextRunAt es cuándo vence la ejecución; un monitor pausado durante una semana se reanuda un intervalo después del momento en que se reactiva, sin lanzar las ejecuciones perdidas.
Encontrar tus competidores añade 100 créditos al mes por monitor, repartidos entre sus ejecuciones según el intervalo: unos 3 créditos por ejecución en un monitor diario y unos 23 en uno semanal. Se cobra cuando todas las tareas de una ejecución han entrado, así que una ejecución que tu saldo detuvo no paga nada por ello.

Endpoints

Todos usan la misma clave bearer que el resto de la API (consulta Autenticación). Un monitor de otra cuenta responde 404, no 403.

Crear un monitor

name, engines, prompts, aliases e intervalHours son obligatorios en un monitor de marca; un monitor de categoría recibe category en lugar de aliases. Cada lista acepta un array o una cadena separada por saltos de línea; las entradas se recortan, las líneas vacías se descartan y los duplicados se eliminan. country elige el mercado para el que responden los motores y no traduce los prompts. prompts × engines debe quedar en o por debajo del límite tasksPerRun de capabilities. Los motores son las superficies de prompt programables: CHATGPT, GEMINI, PERPLEXITY, GOOGLE, AIMODE, NAVER_AI_BRIEF, NAVER_AI_TAB y el alias obsoleto NAVER. GOOGLE_AIO y GOOGLE_AIMODE se aceptan y se guardan como GOOGLE y AIMODE. Las tareas de análisis como SOURCE_INFLUENCE no son superficies de prompt y no se pueden programar en un monitor. Una clave restringida a ciertos motores solo puede programar esos motores; cualquier otro es 403 KEY_SCOPE_DENIED. El límite de monitores por cuenta devuelve 409 MONITOR_LIMIT.

Ejecútalo y lee el informe

POST /v1/monitors/{id}/run hace que la siguiente ejecución venza de inmediato, y las tareas de respuesta aparecen en aproximadamente un minuto. Se cobra como una programada, y un reintento de la llamada mientras esa ventana sigue vencida no cobra dos veces. GET /v1/monitors/{id}/analytics es el contrato del que debe salir cada parte de tu informe. Su ventana es semiabierta y en UTC: since inclusivo, until exclusivo, y la eliges de una de estas dos formas: Dos filtros opcionales se aplican a todas las secciones a la vez: engine (id canónico o alias público) y prompt (texto exacto, hasta 2.000 caracteres). Las filas se indexan por el texto del prompt, así que un prompt que luego quites del monitor sigue siendo consultable. Todas las secciones comparten esa cohorte, y el intervalo anterior tiene exactamente la misma duración y los mismos filtros, así que la comparación es homogénea:

Qué significan las cifras

Lee esto antes de etiquetar un panel. Las definiciones son el contrato publicado, y GET /v1/monitors/capabilities las devuelve como metrics para que un cliente pueda mostrarlas junto a las cifras.
  • mentionRate de la ventana, de sus grupos por motor y de sus grupos por celda es 100 × respuestas con mención / respuestas puntuadas. Se pondera por respuestas, no es una media de las tasas por motor, así que un motor con mucho volumen no queda eclipsado por uno con poco. (La tasa propia de una marca tiene su propio denominador, explicado a continuación.)
  • citationRate tiene la misma forma para las respuestas que citaron uno de tus dominios registrados. Sin dominios registrados siempre es cero, porque el seguimiento de citas está desactivado.
  • La tasa de una marca se divide por su propio sampleSize, no por el total de la ventana. Para tu marca son todas las respuestas puntuadas; para un competidor, solo las respuestas puntuadas mientras estaba en el monitor. Si añades un competidor hoy, su primer informe cubre las respuestas que lo midieron: el historial anterior a su existencia no cuenta en su contra. Una marca sin respuestas válidas informa mentionRate: null, no 0 %, porque 0 % se leería como una desaparición real.
  • shareOfVoice en brands es 100 × menciones de esa marca / todas las menciones de marcas seguidas en la ventana, así que las cuotas de una ventana suman 100. Compara marcas dentro de las respuestas que tú recogiste para estos prompts; no es cuota de mercado ni un ranking de visibilidad. El shareOfVoice del endpoint de detalle heredado es la antigua vista de penetración de respuestas, en la que cada marca se cuenta sobre las respuestas recogidas y las cifras pueden sumar más de 100: no mezcles ambas en un mismo gráfico.
  • competitorOnly (y la lista opportunities) cuenta las respuestas que nombraron a un competidor configurado mientras tu marca estaba ausente. Es la brecha sobre la que puedes actuar.
  • Las tasas son anulables, no cero. Sin respuestas en la ventana, el valor es null; una tasa cero significa que hubo respuestas y ninguna coincidió.
  • Una observación completada sin respuesta cuenta como no mencionada. Permanece en el denominador, y quality.noAnswerObservations indica cuántas hubo. Una tarea fallida se excluye de todas las tasas y solo aparece en health: un motor averiado reduce la muestra en lugar de convertirse en silencio en una ausencia, y quality nunca la reconstruye como tal (historicalFailures siempre es null).
  • Las variaciones se ocultan cuando engañarían. changes y el mentionRateChangePp por celda son null, y quality.comparable es false, cuando un periodo no tiene respuestas (insufficient_periods), cuando hay filas puntuadas antes de que existiera el contexto de puntuación (legacy_scoring_unknown) o cuando la definición de puntuación cambió entre periodos (scoring_definitions_changed). Las filas históricas conservan las definiciones con que se puntuaron (quality.scoring), así que cambiar tus alias o competidores nunca reescribe el pasado. La única excepción es la lectura mensual de competidores descrita arriba.
  • El tamaño de muestra se publica. quality.lowSample es true por debajo de 30 respuestas puntuadas, quality.missingCells cuenta las celdas prompt × motor configuradas sin respuestas aún, y quality.partialDays indica los días UTC que la ventana corta a la mitad: el recuento menor de un día parcial es aritmética, no un descenso.
position en una fila puntuada es el offset de carácter de la primera coincidencia de alias dentro del texto de la respuesta: un indicador aproximado de prominencia, no un ranking. Es null cuando la marca no aparece, por eso 0 nunca tiene que significar «ausente».

De dónde salen las respuestas

GET /v1/monitors/{id}/sources responde a «qué páginas están ganando estos prompts», con la misma ventana y filtros que el informe y contando respuestas distintas en lugar de citas en bruto, así que una página citada tres veces en una respuesta cuenta una vez. Cada fila lleva citations y prompts (ambos recuentos de respuestas distintas), own para tus dominios registrados y un evidenceTaskId que puedes abrir con el endpoint de respuestas. Aquí no hay un recorte silencioso a los N primeros: cada dominio o página de la ventana es accesible siguiendo el cursor.

Citas a lo largo del tiempo

GET /v1/monitors/{id}/citations devuelve los datos de los gráficos de citas del panel: el total diario de citas de la ventana y una serie diaria para cada dominio y página principal. Solo lee resultados guardados, así que no gasta créditos. Aquí una cita es una página que aparece en una respuesta, así que la misma página dos veces en una respuesta cuenta una sola vez. /sources cuenta respuestas distintas, por lo que sus cifras pueden diferir. La cuota de una fuente es su citations dividido entre totals.citations. kind, q y offset solo acotan las listas; totals, days y types siempre cubren todas las fuentes de la ventana.

Exportar las filas puntuadas

GET /v1/monitors/{id}/results devuelve las filas en sí, para una carga en un data warehouse, una presentación semanal o una hoja de cálculo. La paginación es un keyset sobre (ranAt, id) con precisión de microsegundos, así que las filas que comparten marca de tiempo no se pueden saltar ni repetir. Para que la extracción sea repetible: envía since y until explícitos, mantenlos fijos y sigue nextCursor hasta que sea null. Cambiar la ventana entre páginas puede saltar o repetir filas. Trata el cursor como opaco: se devuelve y se reenvía, nunca se construye. Con format=csv la respuesta es text/csv (UTF-8 con BOM, para que Excel la abra correctamente) y el estado de paginación pasa a las cabeceras, porque un cuerpo CSV no tiene otro sitio donde ponerlo: Las columnas son ran_at, monitor, engine, prompt, mentioned, cited, position, competitors, task_id, más answer_text, sources, scoring_context cuando includeEvidence=true (sources y scoring_context como texto JSON dentro de sus celdas). Las celdas que podrían interpretarse como una fórmula se neutralizan antes de escribirse, así que el texto de terceros no puede convertirse en una fórmula en tu hoja.

Leer la respuesta detrás de una cifra

GET /v1/monitors/{id}/answers/{taskId} devuelve la evidencia conservada de una fila:
  • answerText: la respuesta tal como la dio el motor, en markdown cuando está disponible, como máximo 8.000 caracteres, cortada con puntos suspensivos si era más larga.
  • sources: las citas en el orden del motor, cada una con su etiqueta y su posición (empezando en 1) en esa lista.
  • aliases y competitors: contra qué se comparó esta fila, para que la mención pueda comprobarse en lugar de darse por buena.
  • scoringContext: la definición exacta usada, con un hash version, la hora de puntuación, answerPresent y evidenceTruncated cuando el texto anterior se cortó.
Las filas puntuadas antes de que se guardara el contexto de puntuación devuelven scoringKnown: false con los alias actuales del monitor y un evidenceTruncated null. answerText es null cuando el motor no devolvió texto de respuesta.

Errores en esta superficie

El sobre es el mismo que en el resto (consulta Errores); los códigos específicos de la monitorización son:

Un agente en el circuito

Una secuencia práctica para un agente o un script, usando solo los endpoints de esta página. Es ilustrativa: sustituye tu propia clave, id de monitor y ventana:
  1. GET /v1/monitors/capabilities: lee los motores, precios y límites antes de gastar nada.
  2. GET /v1/monitors: reutiliza un monitor existente para el tema y el mercado, o POST /v1/monitors para crear uno (opcionalmente llamando antes a POST /v1/monitors/suggest y editando los candidatos).
  3. POST /v1/monitors/{id}/run: si necesitas respuestas antes de la siguiente ventana programada.
  4. GET /v1/monitors/{id}/analytics?days=30&engine=CHATGPT: lee primero quality (comparable, lowSample, missingCells, partialDays) y después las cifras. Sondea hasta que health.pending se estabilice y quality.sampleSize deje de crecer.
  5. GET /v1/monitors/{id}/sources?days=30&groupBy=page: pagina con nextCursor para encontrar las páginas que ganan los prompts.
  6. GET /v1/monitors/{id}/answers/{taskId}: abre la respuesta detrás de la primera entrada de opportunities antes de decidir nada.
  7. GET /v1/monitors/{id}/results?since=...&until=...&includeEvidence=true&format=csv: exporta la misma ventana, siguiendo x-next-cursor hasta que esté vacío.
Las mismas operaciones se ofrecen a los agentes como herramientas MCP (get_monitor_capabilities, list_monitors, get_monitor, create_monitor, update_monitor, delete_monitor, run_monitor, get_monitor_analytics, get_monitor_sources, get_monitor_results, get_monitor_answer, suggest_monitor_prompts, get_monitor_alerts, test_monitor_alert). Las escrituras están anotadas como mutaciones, y create_monitor y run_monitor indican que consumen créditos antes de llamarse.

Límites

Consulta los precios y la referencia de motores antes de aumentar el volumen.