Cronologia delle versioni

Un ciclo mirato di miglioramenti sopra il refresh v2.0, incentrato sull'avvio. L'installazione di OrbiAds è ora documentata per ogni agente IA principale — la via senza terminale (Claude Desktop, claude.ai, Cowork) e la via basata su file condivisa da Codex, Cursor, Windsurf, Gemini CLI e Antigravity tramite la convenzione .agents/skills. Una correzione del manifest rende affidabile la sincronizzazione del marketplace di plugin Claude.

Nessuna modifica incompatibile — è una versione di miglioramento incrementale. Se in precedenza l'aggiunta del marketplace OrbiAds falliva, ora funziona al primo tentativo.

Questa release chiude il ciclo V1 e consolida le fondamenta per i prossimi mattoni di prodotto. Tre filoni strutturali sono proceduti in parallelo: (1) la UI di amministrazione è stata ricostruita attorno a un menu centrale raggruppato per caso d'uso anziché per tecnologia, con link contestuali che seguono il flusso reale di un AdOps; (2) il server MCP è passato a un'architettura padre/figlio che porta il catalogo pubblico da 270 strumenti a 51 dispatcher coerenti; (3) le operazioni di lunga durata (generazione del blueprint dell'inventario, esportazione CSV dell'audit, ottimizzazione delle immagini) sono state spostate su un servizio worker indipendente per mantenere snello il backend principale.

Il passaggio a v2.0 riflette la portata del rifacimento più che una singola funzione di punta — ogni azione quotidiana diventa più diretta. Le pagine di audit ora mostrano un pannello onesto "endpoint in costruzione" dove i dati non sono ancora collegati, invece di cifre inventate: meglio essere trasparenti che fingere una demo. Conseguenza pratica della pulizia: alcuni URL ed endpoint legacy sono spariti — vedi la nota di compatibilità in fondo a questa release.

Le reti pubblicitarie multi-tenant e le agenzie ce lo hanno detto chiaramente: devono sottoporre a audit la propria rete GAM rispetto a standard riconosciuti (ISO 27001, IAB, NIST CSF) senza mettere insieme a mano decine di richieste. Questa release introduce una Skill di audit che gli agenti IA possono eseguire in autonomia, oltre a un livello completo di amministrazione GAM (team, siti, applicazioni, etichette). In parallelo, l'assistente di pricing analizza lo storico delle performance per suggerire floor price ottimali, con una garanzia rigorosa: nessun dato del tenant viene mai memorizzato, tutto viene calcolato in tempo reale.

Mantenere l'audit 100% MCP/CLI, senza interfaccia dashboard, è una scelta deliberata. Un audit di conformità è innanzitutto una checklist eseguita da un agente intelligente, non una dashboard da scorrere. Il report markdown risultante può essere inviato via email, versionato in Git e stampato su una singola pagina A4 quando serve per un comitato direttivo.

Publisher e reti pubblicitarie che vendono in modo programmatico avevano bisogno di strutturare la propria offerta commerciale come un vero catalogo: formati, floor price, audience target, condizioni di prenotazione. Questa release introduce questo livello di business end-to-end: modellazione backend, API REST, strumenti MCP e un'interfaccia dashboard completa. In parallelo, il supporto nativo ai deal programmatici (PMP via REST, PG/PD via SOAP) consente di orchestrare la negoziazione e il deployment di accordi diretti con i buyer.

Il bridge ADCP (AdContext Protocol) è probabilmente il tassello più strategico di questa release. Pone le basi perché un agente buyer IA — lato inserzionista o agenzia — possa consultare il catalogo prodotti del publisher, quindi negoziare e distribuire un deal senza attriti umani. È il livello mancante tra l'infrastruttura ad-tech e un'automazione IA davvero end-to-end.

Per molto tempo il server MCP è stato il primo punto di accesso per gli agenti IA. La CLI, invece, è cresciuta in parallelo per coprire i flussi scriptabili: cron job, integrazioni CI/CD, team che semplicemente preferiscono un terminale. Ma le due superfici avevano seguito percorsi leggermente diversi. Questa release si impegna a unificarle: ogni operazione MCP ha il suo comando CLI speculare, ogni comando CLI ha il corrispondente strumento MCP. La matrice di parità viene ora verificata automaticamente a ogni build.

Questa release è stata anche l'occasione per rifattorizzare tre servizi backend in livelli più modulari (report di fatturazione, creazione dei line item, archiviazione dell'inventario). Un lavoro invisibile per gli utenti, ma che accelera sensibilmente la consegna delle prossime funzionalità. Il repository open source pubblico viene sincronizzato automaticamente a ogni push interno.

I publisher molto attivi nel programmatic volevano simulare l'impatto di una nuova campagna sui line item già in erogazione, la cosiddetta contesa reciproca. Questa release introduce get_prospective_delivery_forecast in modalità multi-LI, oltre a suddivisioni delle previsioni (per giorno, dispositivo, area geografica) e all'acquisizione di dati di traffico reali. In parallelo abbiamo condotto due audit live su un account di produzione: la prima ondata ha fatto emergere quattro bug invisibili negli ambienti di test, la seconda altri quattro. Tutti corretti, tutti coperti da test di regressione.

L'audit di qualità della fase 11 (38 correzioni sistematiche rispetto allo schema WSDL ufficiale) parte da un'osservazione semplice: è meglio investire nel rigore delle chiamate che in livelli di recupero degli errori. Quando si chiama GAM con esattamente i parametri tipizzati corretti, i bug scompaiono alla radice invece di essere intercettati a runtime.

Prima di ogni grande espansione del prodotto, ci prendiamo il tempo di sottoporre ad audit approfondito i livelli critici: autenticazione, fatturazione, pipeline delle campagne, reporting, frontend, server MCP. Questa release consolida queste fondamenta su sei assi: sicurezza rafforzata a livello di protocollo OAuth, rimborsi di crediti completamente idempotenti, pipeline con checkpoint di avanzamento e ripristino degli incidenti, e 9 micro-regressioni UX corrette nell'interfaccia. È l'ultimo passo prima dell'arrivo del Catalogo prodotti, dei Programmatic Deals e della suite di audit IA.

Questa release non introduce una funzionalità spettacolare — ed è proprio questo il punto. Chiude in modo pulito il debito accumulato in diciotto mesi di consegne rapide, così che le prossime grandi funzionalità poggino su una piattaforma i cui livelli sono stati ispezionati riga per riga. La comodità di costruire in fretta nasce dal rigore di aver costruito bene prima.

Un audit funzionale del reporting ha rivelato incongruenze tra la fatturazione mostrata (FAQ, CLI) e la realtà del backend. In parallelo, l'analisi dello schema SOAP di GAM ha mostrato che i campi di tracking nativi (thirdPartyImpressionTrackingUrls, thirdPartyClickTrackingUrl, trackingUrls VAST) non venivano sfruttati: iniettavamo tutto nell'HTML. La v1.8 corregge entrambi gli assi e aggiunge un livello completo di audit/QA per il tracking e l'archiviazione.

È la prima release in cui un agente IA può diagnosticare in autonomia un problema di tracking (macro mancanti, cachebuster assente, vendor non rilevato), correggerlo tramite update_creative e riverificarlo — il tutto in una sola conversazione. Il controllo pre-archiviazione previene errori irreversibili.

La domanda tornava di continuo nei feedback della beta: «Come consolido le performance di GAM senza uscire dall'interfaccia?». Il Reporting Hub risponde direttamente a questa esigenza. In parallelo, abbiamo affrontato un debito tecnico legato alla paginazione: alcune reti GAM superano i 500 line item e gli strumenti di elenco restituivano risultati troncati senza avvisare. Il parametro fail_fast sulle operazioni batch risponde a un'esigenza reale dei team che vogliono deployment parziali senza dover annullare tutto.

È anche la release in cui OrbiAds CLI v1.0 viene rilasciata ufficialmente. Due anni a costruire infrastruttura MCP e, alla fine, i primi feedback concreti ci hanno mostrato che una parte dei nostri utenti voleva semplicemente un terminale e un cron job.

Portare l'MCP da prototipo a produzione è stato il punto di svolta di questo ciclo. Per mesi l'infrastruttura SOAP c'era, ma il punto di accesso per l'IA restava sperimentale. Mettere in produzione il server MCP su orbiads.com/mcp, con un'autenticazione OAuth2 pulita e nessuna chiave API da gestire, ha cambiato la natura del prodotto. Inventory Explorer è nato da un'osservazione semplice: prima di distribuire qualsiasi cosa, i team AdOps devono capire che cosa hanno già in GAM. La mappatura dell'inventario era un passaggio mancante.

Il refactoring di SOAP in un pacchetto modulare (pattern mixin) non è visibile agli utenti, ma ha ridotto il tempo medio di diagnosi di un bug GAM da 45 minuti a meno di 10. È il tipo di lavoro invisibile che cambia la velocità nel lungo periodo.

Prima di questa release, distribuire una campagna nativa su GAM significava destreggiarsi tra una dozzina di schermate: creare l'order e i line item, caricare gli asset, configurare il targeting, associare le creatività. Ogni passaggio era manuale, ogni errore richiedeva un rollback parziale. La pipeline della v1.3 automatizza l'intera sequenza a partire da uno ZIP di creatività. Il tracciamento in tempo reale via SSE permette di vedere l'esecuzione di ogni passaggio, non solo un loader che gira.

Scegliere FastAPI BackgroundTasks invece di un orchestratore esterno (Celery, Cloud Tasks) si è rivelato giusto per le dimensioni attuali del prodotto. Meno parti in movimento, superficie d'attacco ridotta, latenza inferiore. Lo rivaluteremo se i volumi lo richiederanno.

La v1.0 risponde a una domanda precisa: è possibile collegare un agente IA a Google Ad Manager in modo sicuro, senza esporre chiavi di servizio e senza infrastruttura da mantenere lato utente? L'autenticazione OAuth2 «on behalf of user», con refresh token archiviati in Cloud KMS, era il prerequisito non negoziabile. Senza di essa, tutto il resto è solo una demo. L'onboarding in 2 passaggi (collegamento dell'account + rete GAM) riflette questa priorità: accorciare il percorso verso la prima operazione reale.

Scale-to-zero su Cloud Run fin dal primo giorno — non perché sia la soluzione più semplice, ma perché pagare istanze inattive mentre il prodotto è in fase di validazione non ha senso. Quel vincolo ci ha costretti a progettare correttamente le connessioni fin dall'inizio.