Media Intelligence APIs: cómo filtrar el ruido antes de que entre al pipeline
Media Intelligence APIs: cómo filtrar el ruido antes de que entre al pipeline
El problema no es la falta de datos. Es que la mayor parte de lo que devuelve una API de media intelligence no debería llegar nunca a tu sistema de almacenamiento. Menciones duplicadas, contenido sindicado de la misma fuente con variaciones mínimas, señales de dominios irrelevantes para el caso de uso: todo eso viaja por el pipeline, ocupa espacio, consume créditos y encarece el procesamiento posterior.
La lógica habitual es ingestar primero y filtrar después. Es un error costoso. Cuando el filtrado ocurre downstream —en la capa de transformación o en el análisis— ya has pagado el transporte, el almacenamiento y el cómputo de datos que nunca debieron entrar. La alternativa es aplicar criterios de relevancia en el momento de la llamada a la API, antes de que el dato cruce el umbral del pipeline.
Este post trata exactamente de eso: dónde colocar los filtros, qué parámetros usar y cómo estructurar la lógica para que el pipeline reciba señal limpia desde el origen.
El coste real del dato irrelevante
Un pipeline de media intelligence que no filtra en origen puede fácilmente ingestar entre un 40% y un 70% de datos que no contribuyen al análisis final. Este porcentaje no es teórico: emerge de la naturaleza del universo público de Internet, donde la misma información se replica en decenas de dominios en cuestión de minutos.
Cada registro innecesario tiene un coste compuesto:
- Almacenamiento: volumen bruto que crece sin aportar valor analítico.
- Latencia de procesamiento: más registros implican más tiempo en las fases de normalización y enriquecimiento.
- Coste de créditos API: en modelos pay-as-you-go, cada registro consumido tiene un precio directo.
- Deuda de limpieza: cuanto más tarde se filtra, más compleja es la deduplicación y la normalización retroactiva.
La arquitectura eficiente invierte este orden: filtrar primero, almacenar solo lo relevante.
Parámetros de filtrado disponibles en la llamada a la API
La mayoría de media intelligence APIs exponen parámetros que permiten acotar el conjunto de resultados antes de que el servidor serialice y envíe la respuesta. Usarlos correctamente es la primera línea de defensa.
Filtros temporales precisos. Los rangos from / to o equivalentes deben ajustarse al ciclo real del pipeline, no a ventanas genéricas. Un pipeline que corre cada 15 minutos no necesita solicitar datos de las últimas 24 horas. Solapar ventanas temporales por miedo a perder datos es la causa más común de duplicación masiva en ingestión.
Filtros por tipo de fuente. Muchas APIs permiten segmentar por categoría de medio: blogs, foros, medios de referencia, redes sociales, etc. Si tu caso de uso solo necesita señal de medios generalistas, incluir foros de nicho o agregadores de baja calidad solo añade ruido. Define la lista de tipos permitidos y aplícala en cada request.
Filtros por idioma y región. El parámetro de idioma es de los más subutilizados. Un análisis de reputación enfocado en el mercado hispanohablante no necesita procesar menciones en inglés, aunque la entidad monitorizada aparezca mencionada en ambos idiomas en el mismo artículo. Filtrar por idioma en la API reduce el volumen de forma inmediata.
Umbrales de relevancia por puntuación. Algunas APIs exponen métricas de relevancia o autoridad de la fuente. Establecer un umbral mínimo —aunque sea conservador al principio— elimina el rango de dominios de muy baja señal sin necesidad de lógica adicional en el pipeline.
Deduplicación antes del almacenamiento
El filtrado por parámetros no resuelve el problema de la sindicación. Un mismo contenido publicado en un dominio principal puede aparecer en decenas de dominios secundarios que lo republican con mínimas variaciones. Si el pipeline los trata como registros distintos, el análisis posterior estará sesgado.
La deduplicación eficaz en media intelligence opera en dos niveles:
Deduplicación por identificador canónico. Algunas APIs exponen un campo de URL canónica o un hash de contenido. Si el proveedor lo incluye, ese campo debe ser la clave de deduplicación primaria, no la URL de respuesta. La URL puede variar entre sindicaciones; el hash de contenido no.
Deduplicación por similitud de texto. Cuando no hay identificador canónico, una función de similitud ligera —Jaccard sobre n-gramas del titular, por ejemplo— aplicada antes de persistir el registro puede reducir duplicados residuales. No necesitas procesamiento pesado: el 80% de sindicaciones comparten titular prácticamente idéntico.
El momento correcto para ejecutar esta lógica es después de la llamada a la API pero antes de escribir en el almacenamiento. Es decir, en la capa de ingestión, no en la de transformación.
Estructurar el contrato de relevancia como configuración, no como código
El error arquitectónico más frecuente en pipelines de media intelligence es hardcodear los criterios de filtrado en la lógica de la aplicación. Cuando cambia el caso de uso —nueva entidad a monitorizar, nuevo mercado, nuevo idioma— hay que modificar código, desplegar y reiniciar.
La alternativa es tratar el contrato de relevancia como configuración externa:
# relevance_contract.yaml
sources:
allowed_types: ["news", "blog"]
min_authority_score: 30
languages: ["es", "pt"]
time_window_minutes: 15
dedup:
strategy: canonical_url
fallback: title_jaccard
threshold: 0.85
Con este modelo, cambiar el mercado objetivo o añadir un tipo de fuente es una modificación de configuración que no requiere tocar el pipeline. Además, el contrato queda documentado y versionado junto al resto de la infraestructura.
Herramientas como FeedScale exponen parámetros de filtrado suficientemente granulares para que este tipo de contrato de configuración sea viable sin lógica adicional en el cliente.
Validar la calidad del filtrado en cada ciclo
Filtrar en origen no significa filtrar a ciegas. El pipeline debe medir la tasa de rechazo —registros descartados frente a registros ingestados— y alertar cuando esa tasa cambia de forma inesperada.
Una tasa de rechazo que cae a cero puede indicar que un filtro dejó de aplicarse. Una tasa que sube al 95% puede indicar que el proveedor cambió el esquema de clasificación de fuentes y tus tipos permitidos ya no coinciden con los actuales.
Registra estas métricas por ciclo. No necesitas un sistema de observabilidad complejo: una tabla de auditoría con timestamp, registros recibidos, registros aceptados y motivo de rechazo mayoritario es suficiente para detectar anomalías antes de que afecten al análisis.
El pipeline que filtra en origen no solo es más barato. Es más predecible, más fácil de mantener y produce análisis con menos sesgo estructural. La inversión está en diseñar bien el contrato de relevancia una vez, no en limpiar datos mal ingestados cada semana.