Media Intelligence APIs: cómo modelar cobertura geográfica sin que el pipeline pierda señal local
Media Intelligence APIs: cómo modelar cobertura geográfica sin que el pipeline pierda señal local
Hay un error que cometen incluso equipos con pipelines maduros: configuran las consultas de media intelligence a nivel global y después se preguntan por qué el modelo de análisis no detecta tendencias regionales con suficiente antelación. La respuesta casi siempre es la misma: el problema no está en el modelo, está en cómo se construyó la consulta geográfica desde el principio.
Cuando un pipeline trata el universo de fuentes públicas como una masa indiferenciada, la señal local se diluye. Un tema que acapara el debate en medios regionales de tres comunidades autónomas —o de tres estados de un país federal— puede representar menos del 0,3 % del volumen global. El algoritmo lo ignora. El analista lo descubre tres días tarde. El cliente pregunta por qué no se anticipó.
Este post explica cómo estructurar la dimensión geográfica en las llamadas a media intelligence APIs para que la señal local tenga el peso que merece, sin duplicar costes ni complejidad operativa.
Por qué la granularidad geográfica no es un filtro, es una dimensión del modelo
El error conceptual más frecuente es tratar la geografía como un parámetro de filtrado: "dame menciones de España" o "dame menciones de LATAM". Ese enfoque aplana la realidad. Convierte en homogénea una distribución de fuentes que en la práctica es extremadamente heterogénea.
La granularidad geográfica correcta no filtra, estratifica. En lugar de una sola consulta que devuelve todo lo que ocurre en una región, se construyen capas:
- Capa nacional: fuentes de alcance estatal, generalmente mayor volumen pero menor especificidad temática.
- Capa regional: medios y fuentes públicas de ámbito sub-nacional. Captan tendencias emergentes antes de que lleguen al ecosistema nacional.
- Capa local o de nicho: foros, publicaciones especializadas, agregadores sectoriales. Volumen bajo, densidad de señal alta.
Cada capa se procesa con pesos distintos en el modelo de análisis. Una mención en una fuente local de alto engagement sectorial puede valer más que cien menciones en un medio generalista de alcance nacional.
Cómo traducir esa estratificación a llamadas API reales
Una media intelligence API bien diseñada expone parámetros para acotar el origen geográfico de las fuentes, no solo el idioma del texto. Son conceptos distintos: una fuente en español puede estar alojada en México, en Argentina o en España, y eso importa para el análisis de tendencias locales.
Un esquema de consulta que funciona en producción:
GET /v1/mentions?
query=cambio+climatico
&source_country=MX,AR,CL
&language=es
&date_from=2026-08-01
&date_to=2026-08-27
&page_size=500
&sort=relevance
Aquí source_country acota la geografía de origen de la fuente, no el contenido. language filtra el idioma del texto procesado. Si usas solo language=es, recibes señal mezclada de decenas de países sin posibilidad de desagregarla después en el modelo.
La recomendación operativa: lanza consultas paralelas por capa geográfica, no una sola consulta con múltiples países en el mismo parámetro. Así puedes asignar cuotas de consumo distintas por capa y aplicar lógica de priorización en la cola de procesamiento.
El problema del volumen asimétrico entre capas
Cuando estratificas por geografía, aparece un problema de ingeniería que pocos anticipan: el volumen entre capas puede diferir en dos órdenes de magnitud. Una consulta nacional puede devolver 50 000 menciones en 24 horas; la misma consulta a nivel regional devuelve 800.
Si tu pipeline procesa todo a la misma velocidad, la capa local nunca recibe atención suficiente. La solución es diseñar colas de prioridad separadas, no una única cola FIFO:
Cola A (nacional) → worker pool grande, latencia tolerable alta (hasta 5 min)
Cola B (regional) → worker pool mediano, latencia objetivo < 2 min
Cola C (local) → worker pool pequeño pero dedicado, latencia objetivo < 30 s
La capa local tiene prioridad de latencia más baja porque es donde emerge la señal antes de escalar. Si llegas tarde ahí, pierdes la ventaja analítica completa.
Este diseño también facilita el control de costes en modelos pay-as-you-go: puedes pausar la cola nacional durante ventanas de bajo interés sin detener el monitoreo regional, que suele ser más barato y más denso en señal útil.
Normalización geográfica: el paso que nadie documenta
Los metadatos geográficos que devuelven las APIs no siempre son homogéneos. Una fuente puede venir etiquetada como "country": "ES", otra como "region": "Cataluña", otra con solo coordenadas o sin campo geográfico alguno. Antes de que ese dato entre al modelo de análisis, necesita normalización.
El esquema mínimo recomendado para el campo geográfico normalizado en tu pipeline:
{
"geo": {
"country_code": "ES",
"country_name": "Spain",
"region": "Cataluña",
"city": null,
"confidence": 0.91,
"source": "api_metadata"
}
}
Cuando source_country no viene en los metadatos de la API, el campo confidence debe marcarse bajo y el pipeline debe derivarlo por heurística (dominio TLD, idioma, timezone del servidor). No mezcles datos de alta y baja confianza geográfica en el mismo bucket de análisis o contaminas el resultado.
En FeedScale los metadatos de origen vienen ya estructurados, lo que reduce la complejidad de esta capa de normalización, pero el diseño del esquema en tu sistema de destino sigue siendo responsabilidad del equipo de datos.
Señales de alerta: cuándo tu modelo geográfico está roto
Tres síntomas que indican que la dimensión geográfica de tu pipeline de media intelligence no funciona como debería:
Desfase temporal sistemático: detectas tendencias regionales con más de 48 horas de retraso respecto a cuando empezaron a moverse en fuentes locales. Síntoma de que la capa local no tiene prioridad de latencia.
Concentración excesiva en fuentes nacionales: más del 85 % de las menciones procesadas provienen de cinco o seis fuentes de gran alcance. Indica que la estratificación no está funcionando o que los pesos del modelo favorecen volumen sobre densidad de señal.
Colapso del pipeline ante eventos locales inesperados: un suceso regional genera un pico de volumen en la capa local y satura la cola porque no hay separación de workers. La señal llega tarde o se pierde por timeout.
Estos tres síntomas son diagnosticables con métricas de pipeline estándar: latencia por cola, distribución de fuentes por tier y tasa de error por segmento geográfico. Si no estás midiendo esas métricas de forma desagregada, no puedes detectar el problema hasta que ya ha costado algo.
Antes de escalar, audita la estructura geográfica
Escalar un pipeline que tiene mal diseñada la dimensión geográfica solo amplifica el problema. Más volumen, más señal local perdida, más coste para llegar al mismo resultado.
El momento correcto para revisar la arquitectura geográfica es antes de añadir nuevas regiones al scope del monitoreo, no después. Una auditoría de tres horas sobre la distribución de fuentes por tier, los tiempos de procesamiento por cola y los pesos del modelo puede evitar meses de ajustes reactivos en producción.
La geografía no es un parámetro secundario de la consulta. Es una dimensión estructural del análisis. Trátala como tal desde el diseño.