Costo a zero: costruire un alert MCC che segnali problemi veri

L’alert deve dire cosa controllare

Un account che normalmente investe ogni ora e improvvisamente smette di spendere merita attenzione. Può esserci un problema di pagamento, idoneità, pianificazione o un arresto intenzionale. Uno script che scrive soltanto “costo zero” trasferisce però tutta la diagnosi alla persona che riceve il messaggio. Uno strumento utile prepara il contesto necessario per intervenire.

Tibbe van Asten pubblica su Adsscripts un monitor delle campagne senza impressioni, selezionabili tramite etichette MCC e confrontabili con lo storico. Prendiamo questo schema come punto di partenza, ampliandolo a una diagnosi di costo nullo. Non sono segnali equivalenti: impressioni presenti e spesa nulla richiedono una lettura diversa dall’assenza completa di distribuzione.

L’ultima ora non è necessariamente completa

L’ora più recente può essere incompleta. Per ogni account conserva quando hai interrogato il dato e quale finestra descrive. Ripeti la lettura di alcune ore concluse per osservare quanto cambiano: questo controllo empirico aiuta a scegliere il margine di consolidamento. Non serve fingere che tutti gli account abbiano la stessa latenza.

Il detector di Bas Baudoin introduce due idee utili: confrontare giorni della settimana omogenei e considerare la variabilità storica invece di applicare la stessa percentuale ovunque. Il codice pubblicato include anche una configurazione del ritardo. Riprendiamo i criteri, senza assumere che uno script reperito online sia già adatto alle query e alle campagne del nostro account.

Se il job parte alle 16:10, controllare 15:00–15:59 può essere prematuro. Potresti configurare una finestra più vecchia, per esempio 13:00–13:59, e confrontarla con 11:00–11:59 e 12:00–12:59. L’esempio descrive una scelta conservativa, non un valore obbligatorio. Registra sempre quale ora stai verificando.

Combinare continuità recente e storico

Una regola iniziale può richiedere costo nullo nella finestra analizzata, costo positivo nelle due precedenti e attività storicamente attesa nella stessa fascia. Aggiungi un minimo di volume: un account con pochi clic al giorno può legittimamente attraversare un’ora senza spesa. Il medesimo zero ha un significato diverso su una campagna continuativa ad alto volume.

Calcola una baseline usando giorni della settimana comparabili e annota festività, campagne appena attivate e promozioni. La mediana delle ore storiche è una possibile scelta robusta rispetto a giornate eccezionali. Non usare una percentuale quando il valore atteso è quasi zero: applica prima una soglia assoluta coerente con il rischio che vuoi intercettare.

Esempio operativo: nelle due ore precedenti osservi 74 e 81 euro, nell’ora controllata zero, mentre la mediana storica è 68 euro. È un candidato da verificare. In un altro account le ore precedenti valgono 0,40 e 0,70 euro, con mediana 0,30: la stessa logica booleana scatterebbe, ma la priorità operativa dovrebbe essere molto diversa.

Gestire fusi, mezzanotte e ora legale

Un MCC può contenere account con fusi diversi. Per interrogare date e segmenti orari usa il fuso dell’account. Per presentare il riepilogo al team italiano puoi usare Europe/Rome, mantenendo visibile anche l’ora locale verificata. Mescolare questi due livelli crea errori particolarmente difficili da riconoscere intorno alla mezzanotte.

Recupera esplicitamente il fuso dell’account e verifica come la tua implementazione interpreta le date. Costruisci le finestre partendo da istanti completi, quindi formattale nel fuso corretto. Sottrarre semplicemente due al numero dell’ora può produrre valori negativi a mezzanotte e interrogare il giorno sbagliato. Il log deve permettere di ricostruire l’intervallo senza intuizioni.

Durante il cambio di ora legale una giornata locale può avere una durata diversa da ventiquattro ore. Testa questi casi con date di test e verifica che la finestra non venga saltata o analizzata due volte. Se la granularità del report non permette di distinguere due ore locali ripetute, prevedi una regola specifica e rendi visibile la limitazione.

Separare lettura, decisione e notifica

Organizza il processo in tre fasi. La lettura raccoglie metriche e stato tecnico dell’esecuzione. La decisione applica soglie e produce un oggetto di anomalia. La notifica invia soltanto eventi nuovi o cambi di stato. Se la query fallisce, il risultato è “lettura non riuscita”, mai costo zero. Un try/catch per account evita che un cliente problematico interrompa gli altri.

Definisci un elenco esplicito di account inclusi e processali in lotti compatibili con i limiti dell’ambiente. Una lista di account attesi permette di riconoscere quelli saltati per timeout o permessi. Alla fine confronta attesi, letti correttamente e falliti. Il totale dei primi deve coincidere con la somma degli altri due; ogni eccezione richiede un motivo registrato.

Salva una chiave evento con account, regola e finestra. Se il controllo gira di nuovo, aggiorna l’evento senza duplicare le notifiche. Quando l’attività riprende, registra il rientro. Nils Rooijmans offre un complemento utile: un alert sulla cronologia delle modifiche con esclusioni configurabili degli utenti attesi. Affiancarlo al monitor aiuta a collegare un calo a una variazione recente, senza scambiare la coincidenza per causalità.

Validare il monitor prima di fidarsi

Avvia una modalità preview che produca log e proposte di alert senza inviarli. Mostra account, ora controllata, finestra esclusa per latenza, costo recente, baseline e motivazione. Simula una query fallita, un account in pausa, un passaggio di mezzanotte e un dato che arriva in ritardo. Sono questi casi a determinare l’affidabilità dello strumento.

Il messaggio deve riportare cosa sappiamo: account, intervallo, costo atteso e osservato, impressioni, letture fallite e modifiche recenti disponibili. Indica poi cosa controllare: pianificazione, stato campagne, fatturazione e idoneità. Un’anomalia non autorizza da sola la sospensione. Monitora infine il monitor con un segnale di esecuzione completata: il silenzio non dimostra che il job abbia funzionato.

• Zero attività e lettura fallita producono stati distinti.
• La finestra considera latenza e fuso dell’account.
• Ogni evento è deduplicato e può tornare allo stato risolto.
• Preview, log e controllo dell’ultima esecuzione funzionante sono disponibili.