- Home
- Blog
- Strumenti e Piattaforme
- Gestire i pubblici su più account: 4 approcci a confronto
Gestire i pubblici su più account: 4 approcci a confronto
Giada Esposito
E-commerce Performance Manager
Se fai girare inserzioni su più di un account, hai già scelto un approccio per gestire i pubblici, che tu l'abbia voluto o no. La maggior parte dei team finisce per default su quello peggiore — ricostruire ogni seed dentro ogni manager nativo — senza mai confrontare le alternative. Questo è uno sguardo fianco a fianco sulle quattro opzioni reali per la gestione dei pubblici cross-account: manager nativi per account, un foglio di calcolo di tracciamento, una convenzione di naming e un hub centrale dei pubblici. Ognuno risolve una fetta diversa del problema, e solo uno lo risolve tutto.
Risposta rapida: ci sono quattro approcci comuni per gestire i pubblici su più account — manager nativi per account, un foglio di calcolo di tracciamento, una convenzione di naming e un hub centrale dei pubblici. I manager nativi intrappolano ogni pubblico nel suo account; i fogli di calcolo descrivono soltanto la dispersione; le convenzioni riducono la confusione ma non la ricostruzione. Un hub costruisce una volta, riusa ovunque e rivela le sovrapposizioni — risolvendo insieme duplicazione, drift e cecità.
I quattro approcci a colpo d'occhio
| Capacità | Manager nativi (per account) | Foglio di calcolo | Convenzione di naming | Hub centrale dei pubblici (Wevion) |
|---|---|---|---|---|
| Costruire un seed una volta e riusarlo | No — ricostruzione per account | No | No | Sì |
| Cross-platform (Meta, Google, TikTok) | Separato per piattaforma | Righe manuali | Manuale | Una schermata |
| Vedere tutti i pubblici in un unico inventario | No | Sì, se tenuto aggiornato | No | Sì |
| Previene il drift del seed tra account | No | No | Parzialmente | Sì |
| Upload di customer list con conteggio di validità | Per account | No | No | Sì |
| Confronto sovrapposizione / cross-audience | Limitato, nella piattaforma | No | No | Sì |
| Sforzo di ricostruzione al crescere degli account | Lineare (peggiora a ogni account) | Alto (manutenzione manuale) | Medio | Piatto |
| Può lanciare campagne? | Sì (nativo) | No | No | No — solo pubblici, lanci tu |
L'ultima riga conta più di quanto sembri. Nessuno di questi è un launcher di campagne, tranne gli stessi manager nativi — l'hub dei pubblici resta deliberatamente nel layer dei pubblici. Costruisce, sincronizza e confronta; sei tu a scegliere cosa far girare. Quel confine è il punto, non una lacuna.
Approccio 1: manager nativi, per account
Questo è il default, e per un singolo account va benissimo. Costruisci le tue custom audience, i pubblici da sito web e i lookalike dentro Meta, Google o TikTok, dove vivono insieme all'account.
Il problema compare nell'istante in cui aggiungi un secondo account. Il manager nativo non ha alcun concetto di condividere un pubblico con un altro account, men che meno con un'altra piattaforma. Così ricostruisci — la customer list ricaricata, il lookalike ricreato, la finestra dei visitatori riselezionata — ogni volta, in ogni account.
I manager nativi sono eccellenti per un account e strutturalmente inadatti per molti. Ognuno conserva i pubblici dentro l'account che li ha creati, senza alcun modo per condividerli. Fai girare cinque account e fai girare cinque copie di ogni pubblico, ognuna creata in un giorno diverso da un export diverso, che vanno in drift senza che nessuno se ne accorga. Lo strumento non è sbagliato — semplicemente non è mai stato costruito per un portafoglio.
Il costo scala con il numero di account. Due account sono fastidiosi; dieci sono una tassa ricorrente misurata in ore, più il costo invisibile di seed che non corrispondono più. È esattamente il problema della dispersione che rende impossibile rispondere alla domanda "quale versione è quella aggiornata?". La gestione nativa è la risposta giusta per un singolo account e quella sbagliata per qualsiasi portafoglio.
Approccio 2: il foglio di calcolo di tracciamento
Il primo istinto, quando la dispersione fa male, è documentarla. Costruisci un foglio di calcolo: ogni pubblico, in quale account vive, qual è il seed, quando è stato aggiornato l'ultima volta. Per un po' sembra di avere il controllo.
Non è così, perché un foglio di calcolo è una descrizione, non una fonte. I pubblici restano in cinque sistemi separati. Ricostruisci comunque ogni seed a mano. E il foglio diventa obsoleto nel momento in cui qualcuno modifica un pubblico senza aggiornare la riga — il che succede entro la prima settimana, perché la manutenzione è manuale e nessuno se ne fa carico.
Un foglio di calcolo di tracciamento documenta la dispersione senza rimuoverla. Ti dice che lo stesso pubblico esiste in cinque posti; non ti permette di costruirlo in uno solo. La mappa non è il territorio — e questa mappa in particolare marcisce in fretta, perché dipende dal fatto che ogni persona si ricordi di aggiornare una riga ogni volta che tocca un pubblico in un sistema che il foglio non può vedere.
Il foglio di calcolo si ripaga solo come inventario temporaneo mentre migri verso qualcosa che i pubblici li tiene davvero. Come sistema permanente è manutenzione senza ritorno — mantieni la documentazione e i pubblici duplicati. Peggio ancora, dà un falso senso di sicurezza: poiché il foglio sembra completo, i team smettono di chiedersi se i pubblici sottostanti corrispondano ancora, e il drift continua inosservato dietro un registro dall'aspetto ordinato. Una descrizione di cui ti fidi ma che è sbagliata è più pericolosa di nessuna descrizione, perché pone fine proprio a quel controllo che avrebbe colto il problema.
Approccio 3: la convenzione di naming
Una convenzione di naming è il miglioramento reale più economico, e la maggior parte dei team dovrebbe adottarne una a prescindere da cos'altro fa. "Purchasers-90g-2026Q2" dice a tutti cos'è un seed e quando è stato creato; "Pubblico 1" garantisce che qualcuno lo ricostruisca il mese prossimo.
Ciò che una convenzione risolve è la confusione — rende ovvia la duplicazione e riduce quella accidentale. Ciò che non risolve è la ricostruzione. Un pubblico con un nome perfetto va comunque ricreato in ogni account, va comunque in drift se i seed differiscono e non ti dà comunque alcuna vista delle sovrapposizioni. E dipende dal fatto che ogni persona la segua perfettamente, per sempre, che è un'assunzione fragile dal giorno in cui entra un freelancer.
Una convenzione di naming è necessaria ma insufficiente. Elimina la confusione del "qual è questo?", cosa che vale davvero la pena fare — ma non fa nulla contro il ricostruire lo stesso seed cinque volte, nulla contro le sovrapposizioni e nulla il giorno in cui qualcuno la ignora. Trattala come un layer sopra una libreria vera, non come la libreria stessa.
Il verdetto onesto: adotta la convenzione, ma non scambiarla per una soluzione. È igiene, non infrastruttura. Abbinala all'Approccio 4 e diventa davvero potente, perché ora la tua unica libreria è anche chiaramente etichettata.
Approccio 4: l'hub centrale dei pubblici
L'hub è l'unico approccio che rimuove la dispersione invece di descriverla. L'Audience Hub di Wevion elenca, sincronizza e costruisce pubblici su Meta, sulle user list di Google e su TikTok da un'unica schermata, limitato agli account a cui hai accesso.
Crei una custom audience, un pubblico da sito web o un lookalike una sola volta. Carichi una customer list e ricevi indietro un conteggio di record validi rispetto a quelli non validi, così sai esattamente cosa ha fatto match. Crei lookalike Meta e Google a partire da un unico seed autorevole. E — la parte che nessun altro approccio offre — fai girare un report di sovrapposizione di Meta e un confronto cross-audience per vedere quanto due pubblici hanno in comune prima di farli girare entrambi, così consolidi o escludi invece di fare offerte contro te stesso.
L'hub centrale è l'unico approccio che costruisce una volta e riusa ovunque, e l'unico che mostra la sovrapposizione prima che ti costi. I manager nativi intrappolano i pubblici per account; i fogli di calcolo li descrivono; le convenzioni li etichettano. L'hub li tiene — un'unica libreria, sincronizzata all'incirca ogni 15 minuti tramite API ufficiali, con la duplicazione e la sovrapposizione cieca rimosse alla fonte.
Due limiti onesti tengono tutto questo accurato. La sincronizzazione gira all'incirca ogni 15 minuti tramite API ufficiali — non è live, e l'hub non agisce di sua iniziativa. E la profondità per piattaforma varia: Meta ha il set più completo di azioni di costruzione, mentre le user list di Google e TikTok sono coperte per elenco, sincronizzazione e i flussi di creazione principali. L'hub inoltre non lancia campagne — è il confine deliberato della tabella qui sopra. È il layer dei pubblici; sei tu a comandare le campagne. Per come si confronta il quadro multi-account più ampio, l'analisi Wevion contro le alternative multi-account estende il discorso oltre i pubblici.
Quale approccio fa per quale team
Non c'è un vincitore unico — c'è un vincitore per situazione, e la variabile che decide è il numero di account.
- Un account: gestione nativa. Non c'è drift cross-account da risolvere, quindi un hub aggiunge poco. Aggiungi una convenzione di naming per igiene e fermati lì.
- Due o tre account, una piattaforma: una convenzione di naming più una gestione nativa disciplinata possono reggere, ma la tassa della ricostruzione è già reale. Questo è il punto di svolta.
- Un portafoglio (più account) o più di una piattaforma: un hub centrale. Nel momento in cui lo stesso seed deve esistere in due posti, iniziano i costi di ricostruzione, drift e sovrapposizione, e solo l'hub li appiattisce.
La variabile che decide è il numero di account, non la preferenza. Un account: il nativo va bene. Un portafoglio o più piattaforme: un hub, perché è precisamente quando "lo stesso pubblico" deve vivere in molti posti e gli approcci per-account iniziano a produrre drift. Abbina l'approccio alla struttura e la scelta si fa da sola.
Questo rispecchia come i team dovrebbero ragionare sul reporting cross-account: il valore del consolidamento è quasi zero con un account e cresce in fretta a ogni account che aggiungi. I pubblici sono semplicemente il consolidamento che ci si dimentica di fare, perché il costo è nascosto nelle sovrapposizioni e nei seed obsoleti, e non in un'ovvia incombenza quotidiana. Per le decisioni di targeting che si appoggiano sopra qualunque approccio tu scelga, la guida avanzata alle custom audience copre il layer della strategia.
Il verdetto onesto
Se fai girare un singolo account, tienilo semplice — nativo più naming. Se fai girare un portafoglio o più di una piattaforma, il confronto non è nemmeno in discussione: gli approcci per-account ti lasciano tutti a ricostruire seed e ciechi sulle sovrapposizioni, e solo un hub centrale costruisce una volta, riusa ovunque e ti mostra la sovrapposizione prima che ti arrivi il conto. Il foglio di calcolo e la convenzione vale la pena tenerli come igiene sopra l'hub — ma non sono il sistema.
Per vedere come una libreria centrale dei pubblici gestisce i tuoi account su Meta, Google e TikTok — sincronizzata all'incirca ogni 15 minuti tramite API ufficiali, con le decisioni di campagna lasciate interamente a te — inizia una prova gratuita di 14 giorni di Wevion affiancata al piano gratuito permanente e mettila a confronto direttamente con lo status quo del ricostruire-ovunque.
Questa guida fa parte del nostro hub di confronto piattaforme — esplora l'intero cluster per playbook correlati.
Domande Frequenti
The Ad Signal
Insight settimanali per media buyer che non tirano a indovinare. Una email. Solo segnale.
Articoli Correlati
I tuoi pubblici sono sparsi tra gli account — ecco come risolvere
Ogni account ha la sua copia "del" custom audience, ogni piattaforma un lookalike diverso, e nessuno sa quale seed è quello aggiornato. Questa è una guida problema-soluzione sul perché i pubblici si frammentano tra account e canali, su quanto costa davvero il disallineamento in spesa sprecata e sovrapposizioni, e su come un hub centrale dei pubblici ti dà una libreria unica che costruisci una volta e riusi ovunque.
Come creare pubblici riutilizzabili su più account pubblicitari
Un workflow pratico, passo passo, per creare i pubblici pubblicitari una volta sola e riusarli su più account e piattaforme. Copre l'inventario di ciò che hai già, l'upload delle liste clienti con controllo di validità, la creazione di custom audience e lookalike, il controllo della sovrapposizione prima di lanciare e il mantenimento dei seed sincronizzati — usando un hub centrale dei pubblici invece di cinque manager nativi.
Custom Audience su Facebook: Guida Avanzata
Strategie avanzate per costruire e ottimizzare le Custom Audience su Facebook — dalla selezione delle fonti e la segmentazione al layering, alle esclusioni e all'utilizzo dei migliori custom audience come seed per le lookalike.