Historial de versiones

Una ronda enfocada de mejoras sobre la renovación v2.0, centrada en la puesta en marcha. La instalación de OrbiAds ahora está documentada para cada agente de IA importante — la vía sin terminal (Claude Desktop, claude.ai, Cowork) y la vía basada en archivos que comparten Codex, Cursor, Windsurf, Gemini CLI y Antigravity mediante la convención .agents/skills. Una corrección del manifiesto hace que la sincronización del marketplace de plugins de Claude sea fiable.

Sin cambios disruptivos — es una versión de mejora incremental. Si antes fallaba al añadir el marketplace de OrbiAds, ahora funciona a la primera.

Esta versión cierra el ciclo V1 y consolida la base para los próximos bloques de producto. Tres líneas de trabajo estructurales corrieron en paralelo: (1) la UI de administración se reconstruyó en torno a un menú central agrupado por caso de uso en lugar de por tecnología, con enlaces contextuales que siguen el flujo real de un AdOps; (2) el servidor MCP pasó a una arquitectura padre/hijo que reduce el catálogo público de 270 herramientas a 51 dispatchers coherentes; (3) las operaciones de larga duración (generación de blueprint de inventario, exportación CSV de auditoría, optimización de imágenes) se trasladaron a un servicio worker independiente para mantener ligero el backend principal.

El salto a v2.0 refleja el alcance del rediseño más que una única función destacada — cada acción cotidiana se vuelve más directa. Las páginas de auditoría ahora muestran un panel honesto de "endpoint en construcción" donde los datos aún no están conectados, en lugar de cifras inventadas: preferimos ser transparentes a fingir una demo. Consecuencia práctica de la limpieza: algunas URLs y endpoints heredados han desaparecido — consulta la nota de compatibilidad al final de esta versión.

Las redes publicitarias multi-tenant y las agencias nos lo dijeron claramente: necesitan auditar su red de GAM según estándares reconocidos (ISO 27001, IAB, NIST CSF) sin encadenar a mano decenas de peticiones. Esta versión introduce una Skill de auditoría que los agentes de IA pueden ejecutar de forma autónoma, además de una capa completa de administración de GAM (equipos, sitios, aplicaciones, etiquetas). En paralelo, el asistente de precios analiza el historial de rendimiento para sugerir precios mínimos óptimos, con una garantía estricta: nunca se almacenan datos del tenant, todo se calcula en directo.

Mantener la auditoría 100 % MCP/CLI, sin interfaz de panel, es deliberado. Una auditoría de cumplimiento es ante todo una lista de comprobación que ejecuta un agente inteligente, no un panel por el que desplazarse. El informe en markdown resultante se puede enviar por correo, versionar en Git e imprimir en una sola página A4 cuando hace falta para un comité de dirección.

Los editores y las redes publicitarias que venden de forma programática necesitaban estructurar su oferta comercial como un verdadero catálogo: formatos, precios mínimos, audiencias objetivo, condiciones de reserva. Esta versión introduce esa capa de negocio de extremo a extremo: modelado en backend, API REST, herramientas MCP y una interfaz de panel completa. En paralelo, el soporte nativo de deals programáticos (PMP vía REST, PG/PD vía SOAP) permite orquestar la negociación y el despliegue de acuerdos directos con compradores.

El puente ADCP (AdContext Protocol) es probablemente la pieza más estratégica de esta versión. Sienta las bases para que un agente comprador de IA, del lado del anunciante o de la agencia, pueda explorar el catálogo de productos del editor y luego negociar y desplegar un deal sin fricción humana. Es la capa que faltaba entre la infraestructura ad-tech y una automatización con IA realmente de extremo a extremo.

Durante mucho tiempo el servidor MCP fue la primera puerta de entrada para los agentes de IA. La CLI, por su parte, creció en paralelo para cubrir flujos automatizables: cron jobs, integraciones CI/CD, equipos que simplemente prefieren un terminal. Pero ambas superficies habían seguido caminos ligeramente distintos. Esta versión se compromete a unificarlas: cada operación MCP tiene su comando CLI espejo y cada comando CLI tiene su herramienta MCP equivalente. La matriz de paridad se verifica ahora automáticamente en cada build.

Esta versión fue también la ocasión para refactorizar tres servicios del backend en capas más modulares (informes de facturación, creación de line items, archivado de inventario). Un trabajo invisible para los usuarios, pero que acelera de forma notable la entrega de las próximas funciones. El repositorio público de código abierto se sincroniza automáticamente con cada push interno.

Los editores con mucha actividad programática querían simular el impacto de una nueva campaña sobre line items que ya se están sirviendo, lo que se conoce como contención mutua. Esta versión introduce get_prospective_delivery_forecast en modo multi-LI, además de desgloses de previsión (por día, dispositivo, geografía) y la ingesta de datos de tráfico reales. En paralelo, realizamos dos auditorías en vivo sobre una cuenta de producción: la primera ola sacó a la luz cuatro errores invisibles en entornos de prueba, la segunda otros cuatro. Todos corregidos, todos cubiertos por tests de regresión.

La auditoría de calidad de la fase 11 (38 correcciones sistemáticas frente al esquema WSDL oficial) parte de una observación sencilla: es mejor invertir en el rigor de las llamadas que en capas de recuperación de errores. Cuando se llama a GAM con exactamente los parámetros tipados correctos, los errores desaparecen de raíz en lugar de capturarse en tiempo de ejecución.

Antes de cada gran ampliación del producto, nos tomamos el tiempo de auditar a fondo las capas críticas: autenticación, facturación, pipeline de campañas, informes, frontend, servidor MCP. Esta versión consolida esos cimientos en seis ejes: seguridad reforzada a nivel del protocolo OAuth, reembolsos de créditos totalmente idempotentes, pipeline con puntos de control de progreso y recuperación ante incidentes, y 9 microrregresiones de UX corregidas en la interfaz. Es el último paso antes de la llegada del catálogo de productos, los Programmatic Deals y la suite de auditoría con IA.

Esta versión no incluye ninguna función espectacular, y ese es precisamente el punto. Cierra con limpieza la deuda acumulada durante dieciocho meses de entregas rápidas, para que las próximas grandes funciones se apoyen en una plataforma cuyas capas han sido inspeccionadas línea a línea. La comodidad de construir rápido nace del rigor de haber construido bien antes.

Una auditoría funcional de los informes reveló incoherencias entre la facturación mostrada (FAQ, CLI) y la realidad del backend. En paralelo, el análisis del esquema SOAP de GAM mostró que los campos de tracking nativos (thirdPartyImpressionTrackingUrls, thirdPartyClickTrackingUrl, trackingUrls de VAST) no se estaban aprovechando: inyectábamos todo en el HTML. La v1.8 corrige ambos ejes y añade una capa completa de auditoría/QA para el tracking y el archivado.

Es la primera versión en la que un agente de IA puede diagnosticar de forma autónoma un problema de tracking (macros ausentes, cachebuster inexistente, proveedor no detectado), corregirlo con update_creative y volver a verificarlo, todo en una sola conversación. La comprobación previa al archivado evita errores irreversibles.

La pregunta volvía una y otra vez en los comentarios de la beta: «¿Cómo consolido mi rendimiento de GAM sin salir de la interfaz?». El Reporting Hub responde a ella directamente. En paralelo, abordamos una deuda técnica en torno a la paginación: algunas redes de GAM superan los 500 line items y las herramientas de listado devolvían resultados truncados sin avisar. El parámetro fail_fast en las operaciones por lotes responde a una necesidad real de los equipos que quieren despliegues parciales sin tener que revertirlo todo.

Es también la versión en la que OrbiAds CLI v1.0 se publica oficialmente. Dos años construyendo infraestructura MCP y, al final, los primeros comentarios concretos nos mostraron que una parte de nuestros usuarios solo quería un terminal y un cron job.

Llevar el MCP de prototipo a producción fue el punto de inflexión de este ciclo. Durante meses, la infraestructura SOAP estaba ahí, pero la puerta de entrada para la IA seguía siendo experimental. Poner en producción el servidor MCP en orbiads.com/mcp, con autenticación OAuth2 limpia y sin ninguna clave de API que gestionar, cambió la naturaleza del producto. Inventory Explorer nació de una observación sencilla: antes de desplegar nada, los equipos de AdOps necesitan entender lo que ya tienen en GAM. El mapeo del inventario era un paso que faltaba.

La refactorización de SOAP en un paquete modular (patrón mixin) no es visible para los usuarios, pero redujo el tiempo medio de diagnóstico de un error de GAM de 45 minutos a menos de 10. Es el tipo de trabajo invisible que cambia la velocidad a largo plazo.

Antes de esta versión, desplegar una campaña nativa en GAM implicaba manejar una docena de pantallas: crear el order y los line items, subir los assets, configurar la segmentación, asociar las creatividades. Cada paso era manual y cada error exigía un rollback parcial. El pipeline de la v1.3 automatiza toda la secuencia a partir de un ZIP de creatividades. El seguimiento en tiempo real mediante SSE permite ver cómo se ejecuta cada paso, no solo un indicador de carga girando.

Elegir FastAPI BackgroundTasks en lugar de un orquestador externo (Celery, Cloud Tasks) resultó acertado para el tamaño actual del producto. Menos piezas móviles, menor superficie de ataque, menor latencia. Lo reevaluaremos si el volumen lo exige.

La v1.0 responde a una pregunta precisa: ¿se puede conectar un agente de IA a Google Ad Manager de forma segura, sin exponer claves de servicio y sin infraestructura que mantener del lado del usuario? La autenticación OAuth2 «on behalf of user», con refresh tokens almacenados en Cloud KMS, era el requisito previo innegociable. Sin ella, todo lo demás es solo una demo. El onboarding en 2 pasos (conexión de la cuenta + red de GAM) refleja esa prioridad: acortar el camino hasta la primera operación real.

Scale-to-zero en Cloud Run desde el primer día, no porque sea la solución más sencilla, sino porque pagar por instancias inactivas mientras el producto está en validación no tiene sentido. Esa restricción nos obligó a diseñar bien las conexiones desde el principio.