- Home
- Blog
- Strumenti e Piattaforme
- Come Ricostruire la Change History di una Campagna Quando il Log Nativo di Meta non Basta
Come Ricostruire la Change History di una Campagna Quando il Log Nativo di Meta non Basta
Giada Esposito
E-commerce Performance Manager
La necessità di ricostruire la change history di una campagna che i team Meta ads affrontano più spesso nasce da una domanda semplice: "Cosa è cambiato su questa campagna tra martedì e venerdì della settimana scorsa?" Apri Ads Manager, vai alla change history, filtri sulla campagna — e trovi una lista di modifiche con timestamp in UTC, senza un attore chiaro, con campi troncati e nessun modo di vedere quale fosse il valore prima della modifica. Se la modifica è avvenuta più di 90 giorni fa, non trovi proprio nulla.
Affidarsi al log nativo per questo lavoro non è un'opzione praticabile per i team che devono rispondere alla domanda in fretta, con precisione e con attribuzione nominale. Questa guida spiega perché il log nativo non basta e come ottenere invece una timeline completa e ricercabile delle modifiche di una campagna.
Risposta rapida: la change history nativa di Meta scade a 90 giorni, non attribuisce le modifiche in modo affidabile a singole persone con nome quando si usano login condivisi, e richiede una ricerca campagna per campagna invece di una ricerca cross-account. L'action log di Wevion cattura ogni modifica nel momento in cui avviene attraverso l'API di Meta, attribuita al membro del team con nome che l'ha fatta, ed è ricercabile e filtrabile su tutti gli account collegati. Ricostruire la timeline delle modifiche di una campagna richiede circa due minuti.
I Fallimenti Specifici del Log Nativo di Meta
La scadenza a 90 giorni
Il momento più comune in cui gli advertiser scoprono questo limite è proprio quando ne hanno più bisogno — un'indagine sulle performance che richiede di guardare indietro di tre o quattro mesi. Una campagna che è andata bene nel Q4 e ha reso meno nel Q1 richiede di capire cosa è cambiato tra quei due periodi. Se il Q4 è più indietro di 90 giorni, la history nativa di Meta è sparita.
Il log nativo non viene archiviato — semplicemente scade e non è più accessibile. Non c'è modo di recuperarlo dopo. I team che si affidano unicamente alla history nativa operano con un punto cieco strutturale per tutto ciò che precede la finestra dei 90 giorni.
I fallimenti di attribuzione con login condivisi
Meta registra le modifiche a livello di identità del Business Manager. Se più membri del team accedono all'account di un cliente attraverso lo stesso ruolo del Business Manager — o attraverso un login condiviso — la change history mostra lo stesso attore per ogni modifica, indipendentemente da chi l'ha fatta davvero. È il fallimento di attribuzione più comune negli ambienti di agenzia.
L'impatto concreto: giovedì salta fuori un picco di CPA. Apri la change history e vedi che martedì è stata cambiata una strategia di offerta. La colonna dell'attore mostra "Business Manager — Acme Agency". Non hai modo di capire quale dei tre buyer ha fatto la modifica senza scrivere un messaggio al team e sperare che qualcuno se lo ricordi.
La change history nativa è affidabile su cosa è cambiato. Spesso è inaffidabile su chi l'ha cambiato, e completamente muta sul perché. Quei due divari — l'attore e la motivazione — sono esattamente quelli che contano quando stai cercando di capire uno spostamento di performance, difendere una decisione davanti a un cliente o stabilire responsabilità in un team.
Ricerca campagna per campagna invece di ricerca cross-account
L'interfaccia nativa richiede di aprire ogni campagna singolarmente per vederne la history. Non c'è una ricerca cross-account — non puoi chiedere "quali campagne, su tutti i miei account, hanno avuto modifiche di budget tra lunedì e mercoledì?". Devi aprire ogni account, poi ogni campagna, poi controllare la history oggetto per oggetto.
Alla scala di un'agenzia che gestisce dieci clienti con venti campagne ciascuno, questo non è un workflow di indagine praticabile. Quando hai controllato il terzo account, hai già dimenticato cosa avevi trovato nel primo.
Secondo i dati operativi di Wevion del Q1 2026, i team che usano action log a livello di piattaforma risolvono le indagini sulle modifiche di campagna in una media di 4 minuti. I team che si affidano alla change history nativa di Meta impiegano una media di 31 minuti per la stessa indagine — e quel numero esclude i casi in cui la modifica è avvenuta fuori dalla finestra dei 90 giorni, che nel tool nativo non hanno alcuna via di risoluzione.
Come un Action Log a Livello di Piattaforma Colma i Divari
Cattura continua attraverso l'API ufficiale
Wevion si collega a Meta attraverso la Marketing API ufficiale, autorizzata via OAuth. Ogni modifica fatta sugli account collegati — che sia avvenuta attraverso l'interfaccia di Wevion o attraverso l'Ads Manager nativo di Meta — viene catturata nell'action log nel momento in cui si verifica, con un timestamp preciso al minuto.
Questa cattura continua è ciò che rende il log utile per la ricostruzione. Non stai chiedendo "cosa ricorda Meta di questa campagna" — stai chiedendo "cosa registra il log su questa campagna", e il log ha registrato in continuo da quando l'account è stato collegato.
Il sync avviene all'incirca ogni 15 minuti. Le modifiche fatte nativamente in Ads Manager compaiono nell'action log di Wevion entro la finestra di sync successiva, attribuite come "modifica esterna" con allegata l'identità riportata da Meta. Le modifiche fatte attraverso l'interfaccia di Wevion sono attribuite al posto nominale di Wevion che le ha fatte.
Attribuzione nominale su ogni modifica
Poiché Wevion opera su un modello a posti nominali — ogni membro del team ha la propria identità con permessi delimitati — le modifiche fatte attraverso la piattaforma sono attribuite alla specifica persona con nome che le ha fatte. Non c'è ambiguità da login condiviso.
I valori prima-e-dopo vengono registrati per ogni modifica di campo. Una modifica di budget da 500 €/giorno a 750 €/giorno compare nel log come: timestamp, persona con nome, nome della campagna, campo "budget giornaliero", da "500", a "750". Il contesto è completo nel record stesso, senza bisogno che qualcuno si ricordi quale fosse il valore precedente.
Ricerca cross-account in pochi secondi
L'action log è filtrabile su tutti gli account collegati contemporaneamente. Per ricostruire la timeline delle modifiche di una campagna:
- Apri l'action history
- Filtra sull'account o sulla campagna in questione
- Imposta l'intervallo di date
- Ordina per timestamp
Il risultato è la sequenza completa delle modifiche nella finestra, in ordine cronologico, con attribuzione nominale per ogni voce. Per una query cross-account — "quali campagne hanno avuto modifiche di budget la settimana scorsa?" — lo stesso filtro si applica su ogni account collegato in una volta sola.
Passo per Passo: Ricostruire la Timeline delle Modifiche di una Campagna
Il workflow concreto per lo scenario di ricostruzione più comune — uno spostamento di performance che devi spiegare — funziona così.
Passo 1: Identifica la finestra di performance
Prima di aprire il log, stabilisci la finestra che ti interessa. Quando è cambiata la metrica? Se il CPA è schizzato mercoledì, stai cercando modifiche fatte nelle 24-48 ore prima che il picco comparisse nel reporting. (Ricorda che il reporting riflette i dati della finestra di sync precedente — le modifiche fatte martedì sera possono comparire nei numeri di mercoledì.)
Conoscere la finestra prima di aprire il log rende il filtro specifico e il risultato corto.
Passo 2: Filtra l'action log sulla campagna e sulla finestra
Filtra per:
- Account (o tutti gli account se non sei sicuro di quale)
- Nome o ID della campagna
- Intervallo di date (le 48-72 ore prima dello spostamento di performance)
Se l'account ha più campagne e non sei sicuro di quale sia coinvolta, filtra solo per account e scorri l'intera lista — la sequenza dei timestamp di solito rende ovvie le modifiche rilevanti.
Passo 3: Leggi la sequenza cronologica
Il risultato filtrato è la timeline delle modifiche della campagna per la finestra. Scorrila cercando:
- Modifiche di budget (in su o in giù)
- Modifiche alla strategia di offerta
- Cambi di targeting del pubblico (sostituzioni di custom audience, aggiunte/rimozioni di interessi)
- Cambi di creatività (nuove inserzioni messe in pausa, altre attivate)
- Modifiche di scheduling (aggiustamenti di dayparting, date di run della campagna)
- Cambi di stato (pause, riattivazioni, pause a livello di gruppo di inserzioni)
La maggior parte degli spostamenti di performance si riconduce a uno di questi tipi di modifica. Il log rende immediato il nesso causale: la modifica è avvenuta alle 14:47 di martedì, fatta dal buyer con nome, e il CPA è salito nel reporting di mercoledì. Attribuzione stabilita.
Il processo di ricostruzione sembra ovvio col senno di poi — certo che vuoi un log con attribuzione nominale e valori prima-e-dopo. Il motivo per cui non è ovvio prima di averlo è che la history nativa di Meta quasi funziona. È abbastanza vicina da far sembrare i divari dei casi limite, finché non ne incontri uno e ti rendi conto che la risposta semplicemente non esiste nel tool a cui ti eri affidato per conservarla.
Passo 4: Documenta il risultato
Una volta identificata la modifica causale, documentala con la voce del log come prova. Per uso interno, uno screenshot o un export delle voci rilevanti è sufficiente. Per la comunicazione col cliente, il deliverable è un riepilogo di cosa è cambiato e di cosa stai facendo al riguardo — con la voce del log come record di supporto se il cliente lo chiede.
Per lo schema di comunicazione col cliente, vedi il nostro caso su come dimostrare quale membro del team ha cambiato la campagna e la guida più ampia su come indagare le modifiche all'account pubblicitario.
Le Situazioni in cui Questo Conta di Più
Dopo uno spostamento di CPA o ROAS. Il trigger più comune è una metrica di performance che si muove in una direzione inattesa. La timeline del log mappa lo spostamento su uno specifico evento di modifica, che è il punto di partenza per l'azione correttiva.
Dopo l'uscita di un membro del team. Quando un buyer se ne va, la domanda su cosa ha cambiato nelle sue ultime settimane spesso non trova risposta dai log nativi. Un action log a livello di piattaforma filtrato sul membro del team in uscita mostra tutta la sua change history su ogni account collegato — rendendo i passaggi di consegne puliti ed escludendo problemi nascosti prima che emergano davanti ai clienti.
Prima di una review col cliente. Preparare una review mensile o trimestrale col cliente è più facile quando puoi tirare fuori la storia di cosa ha fatto il tuo team — le modifiche fatte e la logica dietro di esse — direttamente dal log, invece di ricostruirla a memoria o da appunti.
Dopo un incidente di piattaforma. Quando Meta fa una modifica di backend che impatta la delivery — una nuova dinamica d'asta, un cambio di comportamento di un tipo di pubblico — il log aiuta a distinguere tra "la piattaforma si è comportata diversamente" (nessuna modifica interna registrata) e "qualcuno nel team ha cambiato qualcosa" (modifica registrata con attribuzione).
Secondo i dati della coorte Q1 2026 di Wevion, i team che hanno usato l'action log in modo proattivo — esaminandolo come parte dell'operatività settimanale, non solo come strumento di indagine reattivo — hanno ridotto il tempo di diagnosi sugli incidenti di performance del 74% rispetto ai team che usavano solo le history native delle piattaforme.
Cosa Fa Bene il Log Nativo
La change history nativa di Meta non è inutile — è specificamente tarata per consultazioni reattive, dentro la finestra, su una singola campagna. Se hai notato avvenire una modifica nelle ultime due settimane su una campagna che stai guardando in questo momento, la history nativa te la mostra. Il caso d'uso che serve bene è "devo controllare in fretta cosa è successo a questa specifica campagna negli ultimi giorni".
I divari compaiono quando ti serve: una history più lunga, l'attribuzione a singole persone con nome, la ricerca cross-campagna o un registro che copra Meta più altre piattaforme. Per quei casi d'uso, l'architettura del log nativo non scala. L'action log a livello di piattaforma non è un sostituto dell'uso dell'Ads Manager di Meta — è un sostituto dell'affidarsi alla change history nativa come registro primario.
Per un confronto tra approcci al tracking delle modifiche all'account pubblicitario lungo l'intero spettro — dagli appunti manuali alle history native ai log a livello di piattaforma — vedi i modi per tracciare le modifiche all'account pubblicitario a confronto. Per la discussione completa sull'audit log, comprese le finalità di compliance, vedi i momenti in cui un audit log dell'account pubblicitario ti salva. Il cluster completo ads-management-platform copre lo stack operativo più ampio.
In Sintesi
La change history nativa di Meta è stata costruita per un caso d'uso specifico e ristretto: consultazioni rapide dentro la finestra su una singola campagna, da parte di qualcuno che sa già cosa sta cercando. Non è costruita per la ricostruzione — per il lavoro forense di capire cosa è successo a una campagna nel tempo, attraverso un team, attraverso le piattaforme.
Ricostruire la change history di una campagna senza affidarsi al log nativo significa collegarsi a un action log a livello di piattaforma che cattura le modifiche in continuo, le attribuisce a singole persone con nome, registra i valori prima-e-dopo ed è ricercabile su tutti gli account senza scadenza. Una volta che quel log è attivo, una timeline delle modifiche di una campagna richiede due minuti. Senza, richiede tutto il tempo che l'indagine richiede — e a volte la risposta semplicemente non esiste più.
Domande Frequenti
The Ad Signal
Insight settimanali per media buyer che non tirano a indovinare. Una email. Solo segnale.
Articoli Correlati
Come Indagare una Modifica Inspiegata dell'Account Pubblicitario con la Action History
Quando una metrica si muove e nessuno ammette di aver toccato nulla, non ti serve una riunione — ti serve un metodo. Questo è il passo passo esatto per risalire a qualsiasi modifica inspiegata dell'account pubblicitario usando una action history unificata, dal filtro alla correzione fino all'abitudine della review settimanale.
Chi ha modificato la campagna? Perché i tuoi account pubblicitari hanno bisogno di un vero audit log
Un budget triplica durante la notte. Una campagna vincente si spegne. Nessuno del team ammette la modifica, e le piattaforme native mostrano solo una parte della storia. Ecco perché un audit log unificato su ogni account pubblicitario trasforma il gioco dello scaricabarile in una ricerca da due minuti.
Quando ti serve un audit log dell'account pubblicitario: 8 momenti in cui ti salva
A un audit log non pensi mai, finché non arriva la mattina in cui un winner si spegne o un budget triplica. Ecco otto momenti specifici e riconoscibili in cui una action history unificata su tutti i tuoi account pubblicitari trasforma una crisi costosa in una tranquilla ricerca da due minuti.