Migrare da MGID ad Adgora senza perdere ricavi
Guida pratica per migrare da MGID ad Adgora proteggendo i ricavi: ambito, baseline, posizionamenti critici e metriche da monitorare.
In questa pagina0%

Definisci l’ambito della migrazione in funzione della protezione dei ricavi, non della piena parità tra piattaforme
Il primo errore è cercare di copiare ogni dettaglio di MGID già dal primo giorno. Sembra ordinato, ma può trascinare un editore in settimane di ritocchi mentre i ricavi calano. Parti da una domanda: cosa deve rimanere stabile affinché il sito continui a guadagnare?
Per la maggior parte degli editori, la risposta è ristretta. Mantieni i posizionamenti che rendono, mantieni le fonti di traffico che convertono e mantieni le pagine che hanno già una storia. Se stai scrivendo come migrare da MGID ad Adgora senza perdere i ricavi dell’editore, l’ambito va definito in termini economici, non di prodotto.
Una buona definizione dell’ambito nomina tre cose: la sezione esatta del sito, il modello di ricavo che la sostiene e l’arco temporale da proteggere. Un sito potrebbe migrare prima solo 5 pagine articolo ad alto valore. Un altro potrebbe dover includere la homepage e 2 pagine di categoria. Ambito ridotto. Protezione reale.
Non partire dalla “piena parità”. Questa formula invita a fare lavoro extra. Invece, indica ciò che non è negoziabile per i ricavi: numero di posizionamenti, densità pubblicitaria e budget di velocità della pagina. Se una modifica non incide su questi tre elementi, può aspettare.
Un editore una volta tratta il passaggio come un progetto di redesign e finisce per toccare 14 piccole impostazioni tutte insieme. Poi compare un calo e nessuno sa se la causa sia un widget, un timeout o uno spostamento del layout. Evita quel caos. Mantieni la prima migrazione abbastanza piccola da poterla diagnosticare in una mattinata.
Verifica quali posizionamenti, widget e regole critici per i ricavi devono restare invariati
Fai un elenco con 4 colonne: nome del posizionamento, comportamento attuale in MGID, impatto sui ricavi e se Adgora può replicarlo direttamente. L’elenco dovrebbe includere i widget esatti sopra la piega, nel corpo dell’articolo e a fine contenuto, perché sono di solito i primi punti in cui emergono variazioni di RPM, e perché i posizionamenti pubblicitari da mantenere nella migrazione devono essere chiari fin dall’inizio.
Concentrati sugli elementi che influenzano fill rate, caricamento della pagina ed esperienza utente. Se un widget aggiunge 1,5 secondi al tempo di caricamento, conta. Se un elemento sticky spinge il contenuto verso il basso e aumenta la frequenza di rimbalzo, conta anche quello. Un piccolo ritardo può costare più di quanto qualsiasi ottimizzazione sofisticata riuscirà mai a recuperare.
Esamina con attenzione le regole di delivery. Frequency cap, targeting per dispositivo, filtri geografici e blocchi per categoria di contenuto possono modificare rapidamente il mix di ricavi. Se una regola non è documentata, contrassegnala chiaramente. Non tirare a indovinare. Indovinare costa caro.
Ecco l’abitudine utile: separa ciò che va “assolutamente mantenuto” da ciò che è “bello da mantenere”. Un posizionamento che genera il 40% dell’RPM della pagina appartiene al primo gruppo. Un wrapper decorativo che cambia solo l’aspetto appartiene al secondo. La stessa logica vale per il comportamento di refresh dei widget, la spaziatura degli slot pubblicitari e le regole di lazy loading.
- Nomi e posizioni dei posizionamenti
- Widget sopra la piega e nel contenuto
- Intervalli di refresh
- Regole specifiche per dispositivo
- Filtri geografici e per fonte di traffico
- Impatto sulla velocità della pagina
C’è un test pratico semplice. Se rimuovere un’impostazione cambierebbe i ricavi più dell’aspetto visivo, tienila nell’ambito. Semplice. Nessuna poesia necessaria.
Crea una baseline usando l’ultimo periodo stabile di MGID
Prima di qualsiasi passaggio, acquisisci uno snapshot dell’ultimo periodo stabile di MGID. Usa 7 giorni o 14 giorni se il sito ha un traffico regolare; se il traffico oscilla molto nel weekend, includi sia i dati dei giorni feriali sia quelli del fine settimana. Ti serve una baseline che rifletta un comportamento normale, non un picco fortunato: la baseline ricavi MGID prima della migrazione deve essere costruita su dati solidi.
Registra il set minimo di confronto: pagine principali, fonti di traffico, distribuzione per dispositivo, viewability e performance a livello di posizionamento. Se salti la distribuzione per dispositivo, potresti non accorgerti che il mobile sta sostenendo l’intero account. Se salti le fonti di traffico, un singolo partner referral potrebbe mascherare un calo altrove.
Metti i numeri in un unico foglio. Poi mettili in un altro. Sembra scrupoloso, ma quando le prime 48 ore dopo la migrazione diventano rumorose, vorrai una copia pulita di cui fidarti. Tieni la baseline abbastanza compatta da leggerla in 5 minuti.
Includi almeno tre riferimenti ai ricavi: RPM della pagina, RPM del posizionamento e guadagni giornalieri totali. Aggiungi poi una metrica di salute del traffico, come il bounce rate o la profondità di pagina, perché una configurazione pubblicitaria che aumenta i clic ma allontana gli utenti non è una vittoria. È solo una perdita ritardata.
Una nota a margine: non confrontare la prima ora migrata con un intero giorno stabile e andare nel panico. È così che si inventano problemi. Confronta ciò che è comparabile, preferibilmente la stessa ora del giorno e la stessa combinazione di fonti di traffico.
Ricrea in Adgora il flusso di monetizzazione attuale con il minor numero possibile di elementi mobili
La tua prima configurazione Adgora dovrebbe rispecchiare il percorso di ricavo attivo, non migliorarlo. Resisti alla tentazione di testare 6 idee nuove insieme. L’obiettivo è la continuità. Un’ottimizzazione più pulita potrà arrivare dopo, quando l’account avrà dimostrato di poter mantenere i ricavi stabili.
Parti con lo stesso ordine dei posizionamenti, la stessa profondità del contenuto e, per quanto possibile, lo stesso equilibrio tra mobile e desktop. Se MGID mostrava un annuncio dopo il paragrafo 3 e Adgora può fare qualcosa di funzionalmente simile, replica prima quello. Non ridisegnare il corpo dell’articolo il primo giorno.
Se Adgora offre più formati, scegli quello più vicino al flusso esistente. Non stai costruendo un’esposizione museale. Stai preservando il percorso dei ricavi. Per un editore che confronta stack pubblicitari, la configurazione Adgora dovrebbe essere noiosa nel modo migliore possibile.
Qui può essere utile un riferimento interno. Se il tuo sito esegue anche altri test di monetizzazione, la pagina più ampia con le guide su crypto advertising, monetizzazione e Ad-Tech è un buon posto per verificare note correlate sulla configurazione senza allontanarti dalla migrazione stessa.
Tieni la prima configurazione ridotta al minimo: una sola struttura di account, uno o due tipi di posizionamento principali e una sola vista di reporting. Se un’impostazione non ti aiuta a proteggere i ricavi nella settimana 1, lasciala intatta. Il miglior primo lancio è quasi noioso.
Fai uno split controllato del traffico solo sulle pagine a rischio più alto
Sposta prima un piccolo sottoinsieme sensibile ai ricavi. Scegli pagine che già rendono bene e pagine che hanno traffico sufficiente per mostrare rapidamente eventuali cambiamenti. Uno split del 10% può bastare a far emergere un problema senza mettere a rischio l’intero sito.
Scegli pagine con comportamenti diversi. Un articolo lungo, una pagina di categoria che si carica rapidamente e una pagina con traffico prevalentemente mobile spesso dicono più di un campione casuale di 20 URL. Se lo split funziona lì, hai una prova. Se fallisce lì, intercetti il problema prima che il danno si diffonda.
Usa una regola di split semplice e mantienila costante per tutta la finestra di test. Non cambiare la distribuzione ogni poche ore. Renderebbe i dati inutili. L’obiettivo è confrontare le performance dei ricavi in condizioni simili, non dimostrare che il caos esiste.
Monitora prima le pagine a rischio più alto perché sono quelle che già portano più ricavi. Se una pagina genera il 30% dei guadagni giornalieri, anche un piccolo calo conta in fretta. Pagine lente, layout insoliti e template di articolo molto ricchi di annunci meritano qui un’attenzione speciale.
Un’ultima cosa: fai lo split per pagina, non per sensazione. Una pagina che “sembra” sicura può nascondere il calo di ricavi più grande. I numeri sono meno affascinanti, ma pagano meglio.
Individua le perdite di ricavi nascoste durante le prime 48–72 ore
Le prime 48–72 ore sono il momento in cui emergono le perdite nascoste. Gli annunci possono essere online, la dashboard può sembrare attiva e, tuttavia, i ricavi calano perché uno slot viene renderizzato in ritardo o non viene mostrato affatto. Controlla rendering dei posizionamenti interrotto, caricamento ritardato, report mancanti o instradamento errato del traffico.
Presta particolare attenzione al mobile. Un posizionamento che si comporta bene sul desktop può crollare su uno schermo più קטן se la larghezza del contenitore cambia anche solo di pochi pixel. Osserva anche la viewability. Un annuncio live che compare troppo spesso sotto la piega non manterrà lo stesso profilo di guadagno.
Cerca lacune nel reporting. Se Adgora registra le impression ma i confronti con l’era MGID mostrano un ponte di ricavi mancante, il problema potrebbe essere nel tracciamento e non nella delivery. Questa distinzione conta. Uno è un problema di configurazione; l’altro è denaro che lascia il sito senza essere notato.
Durante questa finestra ci sono tre controlli rapidi: tempo di caricamento della pagina, tasso di rendering del posizionamento e ricavi per 1.000 sessioni. Se uno di questi cambia bruscamente, fermati e analizza la pagina prima di espandere oltre. Reazioni rapide salvano ricavi.
Qui basta una frase breve: aspetta. Poi controlla. Poi confronta di nuovo.
Decidi quando scalare, mettere in pausa o fare rollback in base a soglie di ricavo
Le decisioni non dovrebbero dipendere dall’umore. Imposta in anticipo una soglia. Può essere una banda percentuale attorno alla baseline, oppure un minimo di ricavi fisso per le pagine di test, ma deve esistere prima che venga servita la prima impression.
Usa solo tre azioni: scalare, mettere in pausa o fare rollback. Se le pagine migrate restano entro l’intervallo accettabile per tutta la finestra di test, passa al gruppo successivo. Se i ricavi calano ma la causa è chiara e correggibile, metti in pausa e intervieni. Se le perdite continuano a crescere, fai rollback immediatamente.
Tieni la soglia visibile a tutti i coinvolti. Questo include l’editore, il traffic manager e chi controlla i report alle 2 del mattino. Una soglia nascosta in un thread di chat non è affatto una soglia.
Una regola semplice funziona bene: se il gruppo migrato esce dall’intervallo accettato per due controlli consecutivi, interrompi l’espansione. Se il calo riguarda solo una classe di dispositivo o una fonte di traffico, isolala prima di modificare l’intero account. Il punto è reagire ai ricavi, non al rumore.
Non c’è nessun premio per la testardaggine. Se una pagina perde il 12% e non recupera, scalarla significa solo moltiplicare l’errore. Soglie oneste proteggono l’account.
Stabilizza il monitoraggio post-migrazione per mantenere i ricavi costanti
Una volta completato il passaggio iniziale, imposta un processo di revisione ricorrente. Per molti editori va bene una verifica settimanale; per i primi 10 giorni dopo il cutover, è meglio una verifica quotidiana. L’obiettivo è intercettare piccoli cambiamenti prima che diventino un calo silenzioso dei ricavi.
Controlla ogni volta tre cose: performance dei posizionamenti, variazioni del mix di traffico e coerenza del reporting. Se il traffico mobile cresce del 15% in una settimana, l’account potrebbe aver bisogno di un diverso equilibrio dei posizionamenti. Se appare improvvisamente una fonte referral, potrebbe cambiare abbastanza il comportamento degli utenti da contare davvero.
Annota qualsiasi modifica al layout, cambiamento nel formato dei contenuti o variazione delle campagne che avvenga dopo la migrazione. Senza questo registro, potresti incolpare Adgora per un calo causato da un redesign del sito o da una cattiva fonte di traffico. Questo errore è comune e costoso.
Questo è anche un buon momento per confrontare la tua configurazione con altri temi ad tech quando serve. Se stai regolando la strategia di monetizzazione oltre la migrazione stessa, il glossario ad tech può aiutare a tenere distinti i termini, e l’articolo più ampio sulla rete pubblicitaria crypto per editori è utile se il tuo mix di ricavi include traffico o offerte legate alle crypto.
Fai un’ultima cosa. Archivia la baseline, la soglia e la configurazione finale accettata in un documento condiviso. I cambiamenti futuri saranno più semplici e la prossima migrazione non partirà da zero. Risparmia ore.
I piccoli problemi si sommano. Uno scostamento del 3% nei posizionamenti questa settimana può diventare un movimento del 10% il mese prossimo, se nessuno controlla i numeri. Mantieni vivo il ritmo di revisione e i ricavi resteranno dove ti servono.
Termini in questo articolo
Definizioni brevi dal glossario di Adgora.
- Impressione
- Un annuncio servito a un utente, una sola volta.
- Offerta
- Una cosa specifica pubblicizzata con un pagamento definito per un'azione definita — l'unità di CPA. Vedi la guida al marketing CPA.
Domande frequenti
Su cosa dovrebbero concentrarsi gli editori quando definiscono l'ambito della migrazione da MGID a Adgora?
Dovrebbero definire l'ambito attorno alla protezione dei ricavi, non alla parità completa della piattaforma. L'obiettivo è mantenere stabili durante la migrazione le posizioni, le fonti di traffico e le pagine che già generano entrate.
Quali posizioni e regole di MGID dovrebbero essere verificate prima della migrazione?
Gli editori dovrebbero controllare le posizioni critiche per i ricavi, i widget e le regole di consegna come i widget sopra la piega, in contenuto e alla fine del contenuto, oltre ai limiti di frequenza, targeting per dispositivo, filtri geografici e blocchi per categoria di contenuto. La chiave è identificare ciò che deve rimanere invariato perché influisce sul comportamento di riempimento, sul caricamento della pagina o sull'esperienza dell'utente.
Quali dati di base dovrebbero essere raccolti prima di passare da MGID a Adgora?
Utilizzare l'ultimo periodo stabile di MGID, idealmente 7 o 14 giorni a seconda dei modelli di traffico, e registrare le pagine principali, le fonti di traffico, la suddivisione per dispositivo, la visibilità e le prestazioni a livello di posizionamento. Includere anche RPM della pagina, RPM del posizionamento, guadagni totali giornalieri e un indicatore di salute del traffico come il tasso di rimbalzo o la profondità della pagina.
Come dovrebbe essere configurato il primo setup di Adgora durante la migrazione?
Dovrebbe rispecchiare il percorso di ricavi di MGID dal vivo il più possibile, con lo stesso ordine di posizionamento, profondità del contenuto e bilanciamento tra mobile e desktop dove possibile. Il primo lancio dovrebbe utilizzare il minor numero possibile di parti mobili in modo che la stabilità dei ricavi possa essere testata prima di apportare ottimizzazioni.
Perché gli editori dovrebbero eseguire un test controllato del traffico solo sulle pagine a più alto rischio per prime?
Una piccola suddivisione consente agli editori di testare pagine sensibili al reddito senza mettere a rischio l'intero sito. È sufficiente per rivelare rapidamente i problemi mantenendo il rischio complessivo della migrazione basso.