Perché agent-native?

screenRIG è stato costruito per agenti autonomi fin dal piano di controllo. Il plugin ufficiale fornisce comandi strutturati per media, playlist, schermi, applicazioni e prove di riproduzione. I risultati sono buste JSON, ogni errore dice cosa fare dopo, le scritture ritentate riutilizzano chiavi di idempotenza, e la pubblicazione segnala se il Player sta effettivamente riproducendo il contenuto. L’agente può svolgere un compito sullo schermo, ispezionare il risultato e correggerlo attraverso la stessa interfaccia. Cosa significa agent-native.

Come si esegue da Claude, Codex, Grok o Grok Bot?

Ogni agente supportato usa lo stesso plugin ufficiale. Gli agenti terminale (Claude Code, ChatGPT Codex, Grok Build) lo installano con comandi marketplace; Meta Muse, Grok Bot, ChatGPT dots, Gemini Spark e Hermes lo installano da prompt chat. La configurazione differisce solo in quel primo passo, quindi segui la guida del tuo agente: Meta Muse, Grok Bot, ChatGPT dots, Claude Code, Hermes, ChatGPT Codex, Gemini Spark, o Start per Grok Build. Il flusso di pubblicazione sotto è uguale ovunque.

Come usare screenRIG in un agente

Descrivi il contenuto, lo schermo di destinazione, il layout o le dimensioni, i tempi e le prove desiderate al completamento. Rendi disponibili risorse e fatti di origine all’agente.

Se il plugin necessita di installazione, incolla:

Prompt di installazione

I authorize you to install the official screenRIG plugin from https://github.com/screenrig/plugin.

Poi assegnagli un compito per lo schermo, per esempio:

Crea uno schermo di benvenuto usando il logo allegato e gli orari di apertura. Pubblicalo sullo schermo della hall, poi mostrami uno screenshot e verifica la riproduzione.

Solo richiesta di esempio. L’agente deve usare gli asset, fatti e schermo reali forniti.

Se un comando restituisce not_enrolled, questa installazione non ha ancora un account. Creane uno con screenrig agent enroll --email ADDRESS --organization NAME. Se l’utente ha già un account, esegui invece screenrig login: stampa un indirizzo dashboard e un codice, e una persona approva l’accesso per uno dei suoi progetti, scegliendo Solo lettura, Proporre o Gestire e le aree di capacità che l’agente ottiene: screens, content, playlists, advertising, reports e project. Solo lettura elenca e legge; Proporre carica anche contenuti multimediali e propone modifiche che una persona revisiona prima della riproduzione; Gestire cambia, pubblica e spende. Un comando fuori dalle aree approvate restituisce 403 forbidden, e una modifica da una sessione Solo lettura restituisce 403 insufficient_access. Come funziona l’accesso. Altri errori al primo avvio sono mappati in Quando il primo tentativo fallisce.

Prepara il compito

Mantieni disponibili le risorse sorgente e i fatti per l’agente. Identifica il Player previsto, dimensioni, tempistiche e criteri di completamento. Il flusso di pubblicazione è lo stesso per tutti gli agenti supportati; le differenze di installazione sono in Avvio.

Per app kiosk, usa il browser SDK. Per orari e fasce orarie, fornisci il fuso orario dello schermo e le finestre temporali previste.

Cosa fa l’agente in modo continuativo?

L’agente carica media esistenti, genera design completi presentabili, posiziona card integrate per il testo che cambia o pubblica video live, pagine web e applicazioni. Poi prepara una playlist con playlist init e la pubblica con screen publish. Per modificare una playlist esistente, usa playlist show --output e playlist update. Vedi il riferimento workflow CLI.

Usa la generazione a pagina intera per poster e menu. Usa una card integrata per testo, tabelle e bacheche che cambiano. L’animazione non cambia la scelta. Leggi la guida alle decisioni di authoring.

Per le applicazioni, usa emit quando l’agente deve agire su un evento nominato, log per diagnostica e kv per stato persistente tra le versioni. Leggi il riferimento SDK.

Come gestisce un agente una flotta?

Tagga gli schermi per scopo e archiviali in cartelle per luogo, poi indirizza il tag o la cartella. Quando un lettore è associato, l’agente nomina lo schermo e lo tagga: screen pair CODE, poi screen tag scr_ID --add Lobby,Floor2. Ogni schermo porta fino a 16 tag e sta al massimo in una cartella (screen move scr_ID --folder sfd_ID).

01
Pubblica una volta. playlist create crea la playlist e screen assign --tag Lobby --playlist-id ID punta ogni schermo Lobby attivo su di essa con un’azione flotta unica.
02
Agisci sulla flotta. screen reload, screen toast e screen tag accettano lo stesso --tag o più ID schermo. Un comando flotta è un’azione fatturata senza limite di numero di schermi. La CLI segue automaticamente le pagine di risultati limitate e attende il reset dei budget di controllo, mantenendo la stessa chiave azione. La risposta elenca ogni schermo come ok o con il proprio problema, così l’agente segnala esattamente quali schermi hanno fallito e agisce su di essi per ID.
03
Verifica sullo schermo. screen screenshot --tag Lobby --output lobby-shots cattura ogni schermo taggato in una cartella. Controlla ogni immagine prima di segnalare l’aggiornamento della flotta.
04
Osserva le interruzioni. Tieni events follow aperto. screen.offline arriva dopo che uno schermo è offline da 60 secondi e screen.online quando torna online; entrambi gratuiti sul flusso di ascolto.

Leggi i comandi della flotta.

Come gestisce un agente daypart e takeover?

Un programma playlist cambia cosa uno schermo riproduce in base all’ora; una campagna commuta un’intera flotta su una playlist per le sue date o i suoi orari; un takeover interrompe tutto per un annuncio e termina da solo.

01
Assegna una fascia oraria a uno schermo. Crea una playlist per fascia oraria con playlist create, tieni una predefinita assegnata con screen assign e assicurati che lo schermo abbia un fuso orario. Scrivi le voci in un file ed esegui screen schedule set scr_ID --file dayparts.json, o --tag Cafe per ogni schermo del caffè. screen show riporta effective_playlist con il suo source e until, così l’agente può confermare quale fascia oraria è attiva e quando cambia.
02
Trasmetti una campagna su una flotta. Per i menu del pranzo in ogni negozio north, campaign create --name Lunch --playlist-id pl_LUNCH --tag north --window mon-fri@11:00-14:00 commuta ogni schermo alle sue 11:00 locali e lo fa tornare indietro alle 14:00, e anche uno schermo taggato north in un secondo momento la riceve. Ogni schermo necessita di una playlist predefinita e di un fuso orario. campaign screens cmp_ID elenca ogni schermo raggiunto dalla campagna con il suo stato (playing, pending, waiting con next_start, outranked, blocked), e campaign explain scr_ID spiega perché uno schermo non la riproduce. Usa --from e --until per le date di una promozione, --monthly, --date e --except per le date mensili e singole, --on-touch per un livello che viene riprodotto finché qualcuno usa lo schermo, e --priority quando due campagne possono essere in vigore contemporaneamente. Le modifiche alle campagne richiedono l’accesso Gestisci.
03
Prendi il controllo per un’emergenza o un lancio. screen takeover --tag Lobby --playlist-id pl_NOTICE --for 30m --reason "Fire drill" mette una playlist su ogni schermo Lobby prima di campagne, programmazioni e assegnazioni. Usa --until per una fine fissa, o --until none per tenerla fino a screen takeover clear --tag Lobby.
04
Verifica e osserva. Richiedi screen screenshot --tag Lobby una volta che il takeover è attivo, e segui screen.takeover_started, screen.takeover_ended e screen.playlist_switched nel registro eventi. screen.playlist_unavailable significa che una playlist programmata non è stata mostrata.

Leggi i comandi di programmazione e takeover e i comandi delle campagne. Per programmare molti schermi da un foglio di calcolo, usa Importazione programmazione.

Bozze, prova e promozione, cronologia

Una modifica a ciò che viene riprodotto può iniziare come bozza, raggiungere prima alcuni schermi di prova, essere controllata prima di essere effettuata e ripristinata dalla sua cronologia.

01
Crea una bozza. campaign create --paused crea una campagna che non raggiunge alcuno schermo, e "paused": true su una voce di programma in un file screen schedule set fa lo stesso per quella voce. Una bozza non è nello stack di alcuno schermo, e il calendario la mostra tratteggiata.
02
Controlla prima della modifica. campaign preview accetta i flag di campaign create o campaign update, e screen schedule preview scr_ID --file FILE accetta il file del programma. Nessuno dei due scrive nulla. Ciascuno elenca gli schermi che guadagnerebbero o perderebbero il livello, e il calendario prima e dopo su una settimana, o fino a 93 giorni con --calendar-from e --calendar-to. campaign preview cmp_ID --publish mostra in anteprima la pubblicazione di una bozza.
03
Provala. campaign publish cmp_ID --test-folder sfd_TEST o --test-screen scr_A,scr_B toglie la pausa alla bozza solo per quegli schermi. Controllali con screen screenshot. campaign publish cmp_ID senza opzione di prova la invia al suo pubblico.
04
Promuovila. campaign promote cmp_ID --revision N dà alla campagna il pubblico della sua revisione di bozza N, la revisione in pausa elencata da campaign revisions cmp_ID, così raggiunge gli schermi reali.
05
Leggi la cronologia e ripristina. campaign revisions cmp_ID e screen schedule revisions scr_ID elencano ogni versione, la più recente per prima. campaign restore cmp_ID --revision N e screen schedule restore scr_ID --revision N copiano una versione precedente in avanti come nuova revisione e lasciano le altre com’erano. Un ripristino di programma da una sessione Propose attende l’approvazione di una persona, come screen schedule set; un ripristino di campagna richiede l’accesso Manage.

Il dashboard ha gli stessi controlli: una vista Cronologia elenca le modifiche con Ripristina e Riporta indietro, e pubblicare, promuovere o ripristinare mostra il suo prima e dopo per la conferma.

Leggi i comandi delle campagne e i comandi dei programmi.

Come riporta l’agente la prova di riproduzione?

Ogni inizio visibile di immagine o video è un record di riproduzione, così l’agente può fornire a un cliente, un inserzionista o un revisore le riproduzioni esatte per un periodo.

01
Seleziona l’intervallo. Un report copre fino a 31 giorni di riproduzioni, filtrati per --screen-id, --media-id o --tag. Usa istanti RFC 3339 per periodi di calendario, o età come 7d.
02
Esporta. screenrig playback plays --format csv --from 2026-09-01T00:00:00Z --to 2026-10-01T00:00:00Z --tag Lobby --output september-lobby.csv scrive una riga per ogni riproduzione in una richiesta fatturata. screenrig playback list --format csv --day-from 2026-09-01 --day-to 2026-09-30 aggiunge i totali giornalieri.
03
Controlla e consegna. La busta riporta rows, bytes e sha256; citare con il file. Se il flusso fallisce a metà, seguire error.next, che esporta il resto dell’intervallo in un secondo file.

Leggi i comandi di riproduzione.

Come gestisce un agente la salute e imposta gli orari del monitor?

I rapporti di salute e il controllo del monitoraggio consentono all’agente di mantenere gli schermi attivi e spenti dopo l’orario senza nessuno in loco.

01
Fai il triage. screenrig alerts list mostra cosa è aperto adesso, un alert per schermo e condizione, e screenrig screen list --human segnala gli schermi che richiedono attenzione nella sua colonna HEALTH. screenrig screen show scr_ID fornisce il rapporto completo: connessione del display, temperatura, batteria, uptime, crash e se il rapporto è obsoleto. Indica anche la causa probabile dell’ultima interruzione quando screenRIG riesce a determinarla: il dispositivo si è riavviato, il Player si è riavviato o è andato in crash, la rete dello schermo oppure un’interruzione di screenRIG. screenrig alerts ack ID riconosce un alert su cui qualcuno sta lavorando, e alerts snooze ID --for 4h lo mette da parte per 4 ore. Crea una notifica per screen_offline, display_disconnected, running_hot, not_playing e crashing così un avviso avvia questo lavoro.
02
Correggi nell'ordine meno invasivo. screen reload aggiorna i contenuti. Se il Player dichiara restart_app, screen restart-app scr_ID riavvia l'applicazione del Player; se dichiara clear_cache, screen clear-cache scr_ID svuota le sue cache e scarica di nuovo i contenuti; se dichiara reboot, screen reboot scr_ID riavvia il dispositivo; una flotta richiede --yes. A uno schermo offline viene inviato uno qualsiasi di essi quando torna online entro 24 ore. Per un riavvio ricorrente, screenrig screen reboot-schedule set --tag Cafe --window "Mon-Sun 04:00-04:30" fa riavviare a screenRIG ogni schermo all'inizio della finestra nel proprio fuso orario; uno schermo offline in quel momento mantiene il riavvio solo fino alla fine della finestra, e un riavvio che si completa entro dieci minuti non genera alcun alert di offline. screen update-software scr_ID installa l'ultima release del Player dove il Player dichiara update. Un display scollegato di solito richiede qualcuno sul posto; dillo nel report.
03
Imposta l’alimentazione fuori orario. Scrivi l’orario di apertura in un file ed esegui screenrig screen display-schedule set --tag Cafe --file hours.json; il Player spegne il display fuori da quelle finestre, anche offline. Per un’eccezione, screen display scr_ID --power on --for 2h sovrascrive la programmazione fino al prossimo limite o all’ora indicata. screen display-idle scr_ID --after 300 --wake touch,presence oscura uno schermo che nessuno sta usando e lo riaccende quando qualcuno lo tocca o si avvicina.
04
Conferma. screen show riporta la potenza del display raggiunta dal Player, screen.display_changed e screen.reboot_requested appaiono nel registro eventi e il comando in commands termina con done o failed e la sua causa.
05
Controllare lo schermo. screenrig screen show scr_ID mostra Playlist stalled quando uno schermo è online con contenuti aggiornati, ma nessun avvio di immagine o video è arrivato a screenRIG da più tempo di quanto il suo ciclo consenta, e Blank screen o Frozen picture quando gli screenshot che screenRIG ha preso lungo una serie che copre l’intero ciclo erano tutti di un unico tono uniforme o tutti la stessa immagine. Una notifica su loop_stalled, glass_blank o glass_frozen lo annuncia, e screen screenshot indica se una singola immagine è uniforme, il che da solo non è un verdetto. I controlli non dicono nulla su uno schermo con il display spento, sotto un takeover, che mostra una sola immagine fissa o un video wall, o il cui Player non invia numeri di riproduzione; uno schermo silenzioso non è quindi la prova che stia riproducendo.

Leggi i comandi di salute e alimentazione del dispositivo.

Come si riceve un avviso, o si sveglia un agente, quando succede qualcosa?

Una notifica invia e-mail alle persone, pubblica in Slack, Teams, PagerDuty o Telegram, oppure invia una richiesta POST HTTPS firmata quando uno schermo va offline, perde il display, si surriscalda, funziona a batteria, non riesce a memorizzare i contenuti, si blocca su un aggiornamento dei contenuti, mostra un errore invece di riprodurre, va in crash di continuo, smette di avanzare nella playlist, diventa vuoto o si congela. Una persona ne viene informata, o un agente inizia a lavorare, senza che nessuno guardi uno stream. Ogni progetto invia già un’e-mail al proprietario quando uno schermo è offline da 10 minuti, e le e-mail di notifica e gli avvisi sugli schermi sono gratuiti.

Tre o più schermi che entrano nella stessa condizione entro cinque minuti e condividono una rete, una posizione, un modello, una versione del Player o un tag diventano un unico avviso, con un unico ripristino, in un'e-mail o in un messaggio di chat o di uno strumento di allerta, che indica cosa condividono e quanti sono; un webhook firmato continua a inviare un POST per schermo. Un messaggio di ripristino dice che uno schermo è tornato solo quando screenRIG l’ha visto: quando uno schermo bloccato, nero o congelato smette semplicemente di essere controllato, perché è andato offline o il suo display si è spento, l’alert si chiude e non viene inviato alcun messaggio di ripristino.

01
Invia un’email a una persona. screenrig notifications create --email owner --conditions screen_offline,display_disconnected invia un’email al proprietario del progetto; aggiungi gli ID utente dei membri del progetto dopo owner per includerli. --tag Lobby la limita agli schermi taggati, e un avviso attende --hold minuti (10 per impostazione predefinita), così una riconnessione rapida resta silenziosa. Quando lo schermo si ripristina segue un’email di risoluzione. Ogni email ha un link di annullamento dell’iscrizione valido solo per il suo destinatario, e screenrig notifications resubscribe ID --user USER_ID invia di nuovo le email a una persona. Per svegliare invece un agente o un altro sistema, usa un webhook.
02
Pubblicare in una chat o in un sistema di reperibilità. screenrig notifications create --slack - --conditions screen_offline pubblica in un canale Slack, e --teams, --pagerduty e --telegram fanno lo stesso per Teams, PagerDuty e Telegram. Slack accetta l'URL di un webhook in entrata, Teams l'URL di un webhook di Workflows, PagerDuty una chiave di instradamento dell'API Events v2 e Telegram un token di bot con --telegram-chat CHAT_ID. Un - legge la credenziale da una riga di stdin così non finisce nella cronologia della shell; screenRIG la sigilla e mostra solo un destination_hint mascherato. Ogni interruzione pubblica una volta per schermo, PagerDuty apre un solo incidente e il ripristino segue dopo l'invio di quel messaggio, risolvendo l'incidente. screenrig notifications test ID pubblica un messaggio di prova; per PagerDuty apre un evento informativo e lo risolve subito.
03
Esegui un ricevitore. Qualsiasi endpoint HTTPS controllato sulla porta 443 o 8443: un piccolo servizio, una funzione serverless o il trigger inbound della tua piattaforma agente o bot. Verifica ScreenRig-Signature con il segreto webhook, deduplica su ScreenRig-Event-Id e risponde 2xx entro 10 secondi.
04
Iscriviti. screenrig notifications create --webhook https://HOST/PATH --conditions screen_offline,crashing restituisce il segreto di firma una sola volta; salvalo nel deposito segreto del ricevitore. Aggiungi --events application.event per ricevere anche gli eventi grezzi del progetto. screenrig notifications test ID invia un POST di test firmato per provare il percorso.
05
Passaggio. Il ricevitore avvia un’esecuzione agente con l’avviso come compito: attiva un lavoro agente programmato o su richiesta, o invia l’avviso nella chat dove Grok Bot o un altro agente con il plugin screenRIG lavora. Per esempio: “Schermo scr_LOBBY offline alle 14:02. Controlla e segnala.” L’agente poi procede tramite il plugin come di consueto, con screen show, screen reload e uno screenshot.
06
Mantienila in salute. screenrig notifications deliveries ID elenca ogni tentativo e dice perché un avviso non è stato inviato. Una notifica che fallisce per 72 ore consecutive viene disabilitata; screenrig notifications update ID --enable riprende dall’evento corrente. --snooze 2h mette in pausa gli avvisi durante la manutenzione.
07
Silenzia gli schermi durante la manutenzione. screenrig alerts mute --tag Lobby --for 2h --note "Rewiring" impedisce, per un massimo di 30 giorni, che gli alert di questi schermi richiedano attenzione e che qualsiasi notifica li segnali. screenrig alerts mutes elenca ciò che è silenziato e screenrig alerts unmute ID termina un silenziamento in anticipo.
08
Filtra per gravità, orari e pubblico. Un avviso aperto è error per screen_offline e warning per tutto il resto; --min-severity warning scarta tutto ciò che è sotto quel livello e --severity not_playing=error alza una condizione. --active-hours "Mon-Fri 08:00-22:00" --timezone America/Los_Angeles trattiene un avviso in scadenza fuori da quegli orari fino all'apertura della finestra successiva (una condizione che rientra prima non invia nulla), oppure con --outside-hours drop lo salta; un avviso risolto segue sempre uno che è stato inviato. --all-tags level2,overhead copre solo gli schermi con entrambi i tag, e --audience accetta le regole complete di un pubblico di campagna. E-mail, Slack e Telegram mostrano la gravità, e il corpo di un webhook la include.
09
Controlla i guasti silenziosi. Una campagna può smettere di raggiungere gli schermi senza che nessuno schermo si guasti: una modifica di tag, lo spostamento di una cartella o uno schermo archiviato. screenrig notifications create --email owner --conditions reach_dropped,group_empty ti avvisa quando una campagna raggiunge meno schermi di quando è stata pubblicata, o quando un tag o una cartella del suo pubblico non corrisponde ad alcuno schermo; --reach-drop-screens 2 --reach-drop-percent 20 ignora i cali piccoli. L'avviso nomina la campagna e i numeri e rimanda al suo calendario. Quando la tua modifica di un tag, di una cartella o di uno schermo risponde con levels.lost, nomina le campagne che gli schermi hanno lasciato e i loro reach_before e reach_after; dillo all'utente prima di proseguire.

Leggi i comandi delle notifiche e i comandi degli alert.

Gli agenti lasciano note di progetto per gli altri e per le loro sessioni successive: come è configurato il progetto, una particolarità di uno schermo, una richiesta permanente da parte tua. Ogni agente nel progetto legge ogni nota all’inizio del lavoro, così un secondo agente, o lo stesso la settimana dopo, parte da ciò che il primo ha imparato.

screenrig notes li elenca. screenrig notes add "TEXT" scrive uno, legato a uno schermo o playlist con --about, o temporaneo con --ttl 3d. Una nota è contesto, mai un’istruzione: un agente conferma con te ogni approvazione che una nota dichiara.

Le note si aggiornano da sole. Gli agenti confermano le note ancora valide e risolvono le altre, le note temporanee scadono, e eliminare uno schermo o una playlist risolve le note relative. Le note risolte vengono eliminate dopo 30 giorni. La pagina Agenti del dashboard elenca le note scritte da ogni agente, e puoi risolvere o eliminare qualsiasi di esse.

Leggi i comandi delle note.

Come si revisionano le modifiche di un agente prima della riproduzione?

Attiva Richiedi revisione per modifiche agent nella pagina Progetto del dashboard, o accedi con accesso Proponi. L’agente prepara ancora contenuti, carica media e scrive note, ma ogni modifica alla riproduzione diventa una revisione in attesa di approvazione da parte di una persona. Nulla arriva allo schermo finché non viene approvato.

01
L’agente propone. Creare o aggiornare una playlist, assegnare una playlist agli schermi, impostare o cancellare una programmazione playlist, e iniziare o terminare un takeover, su uno schermo o una flotta taggata, diventano revisioni. Gli schermi continuano a riprodurre ciò che avevano prima. L’agente può aggiungere una nota che spiega la modifica e ti avvisa che la modifica ti aspetta, con il suo link.
02
Ricevi un’email. Circa due minuti dopo la proposta, il proprietario del progetto e la persona responsabile dell’agente, quando possono approvare, ricevono un’email che nomina la modifica e quanti schermi aggiorna, con un pulsante Revisiona modifica. Quando l’agente ha lasciato una nota, l’email lo indica; la leggi nelle Revisioni. Diverse modifiche in attesa arrivano come un’unica email che le elenca, con un pulsante Apri Revisioni, e una serie di modifiche a una sola modifica invia un’email per la versione più recente. Aprire il link non approva nulla.
03
Decidi nelle Revisioni. La pagina Revisioni della dashboard elenca ogni modifica in attesa, con quelle decise sotto. Una modifica alla playlist mostra le playlist live e proposte affiancate, con pagine segnate Aggiunte, Modificate o Rimosse. Approva la mette sugli schermi; Richiedi modifiche invia all’agente la tua nota così può rivedere e proporre di nuovo; Rifiuta la chiude con la tua motivazione. Quando una nuova playlist e la sua assegnazione allo schermo aspettano insieme, approvare la playlist offre di approvare anche l’assegnazione. Una modifica a una grande flotta si applica in background, e la revisione mostra il risultato di ogni schermo man mano che arriva.
04
L’agente segue. L’agente legge la decisione con screenrig reviews show ID o il suo evento, rivede dopo una richiesta di modifica o un rifiuto, e controlla gli schermi dopo un’approvazione.

Il proprietario del progetto può sempre approvare, e ogni membro può farlo a meno che il proprietario non disattivi Può approvare per lui nella pagina Persone. Gli agenti di un membro che non può approvare lavorano al massimo in Proponi. Una proposta diventa obsoleta quando la playlist live cambia dopo la sua creazione; l’agente propone di nuovo a partire dalla nuova versione. Anche l’approvazione di una modifica di playlist diventa obsoleta quando i suoi selettori tag, folder o all riprodurrebbero ora contenuti multimediali che non erano visibili quando è stata proposta. Una cartella contrassegnata come protetta invia a un secondo approvatore ogni modifica che raggiunge i suoi schermi; vedi Permessi per cartella di schermi.

Anche i cambiamenti dei media attendono. Un nuovo caricamento viene riprodotto in tag, cartella e tutte le playlist solo dopo l’approvazione di una persona, e quando un agente ritagga o sposta media approvati, gli schermi continuano a riprodurli come approvati finché il cambiamento non è approvato. Ogni elemento riceve la propria revisione che mostra i suoi tag e cartella prima e dopo, e elenca le playlist a cui si unirebbe o da cui uscirebbe e quante schermate raggiungono. L’approvazione applica il cambiamento a tutte; il rifiuto o la richiesta di modifiche riportano un elemento ritaggato o spostato come era approvato, e un caricamento rifiutato resta spento sugli schermi. Anche un file sostitutivo o una versione ripristinata di un media approvato attende allo stesso modo, e il vecchio file continua a essere riprodotto finché una persona non approva. Le reti pubblicitarie revisionano le creatività degli acquirenti nella stessa pagina Reviews. Livelli di accesso e impostazioni di revisione · Comandi di revisione.

Cosa conta come completo?

Conferma che la playlist prevista sia assegnata allo schermo previsto, o a ogni schermo della flotta. Richiedi uno screenshot, uno per ogni schermo taggato in una flotta, ispeziona i record di riproduzione e rivedi gli eventi rilevanti, inclusi eventuali screen.offline. Riporta ciò che tali osservazioni stabiliscono e ogni incertezza residua. Un cambiamento in attesa di revisione non è ancora visibile: segnala il link alla revisione e ricontrolla dopo la decisione di una persona.

Un comando riuscito è un passo in quella prova. Non stabilisce da solo che uno schermo fisico abbia mostrato il risultato previsto.