Resumos por pasta e por tag
fleet_health, uptime, publishing e alerts agrupam a frota por pasta, tela ou tag em dias UTC inclusivos. Uma linha de pasta conta cada tela que ela contém e as de suas pastas filhas, e a primeira linha é o projeto inteiro. As tags são o segundo agrupamento: uma tela conta em cada tag que possui.
| Relatório | O que uma linha diz |
|---|---|
fleet_health | Telas, online agora, disponibilidade, alertas abertos, alertas iniciados no período, quentes, monitor desconectado, falhando e quantas telas exibem seu conteúdo atual |
uptime | Horas online e offline, disponibilidade e cobertura registrada |
publishing | Telas com conteúdo atual, conteúdo em atualização, conteúdo que precisa de atenção e sem conteúdo |
alerts | Alertas abertos agora e iniciados no período, por condição |
alert_log | Uma linha por alerta iniciado no período: a tela, a condição, quando começou e terminou e quem o reconheceu |
proof_of_play | Exibições das campanhas diretas de um patrocinador ou anunciante por campanha, mídia e tela, com totais |
GET /api/reports/{kind} gera um relatório. from e to são dias UTC (padrão: os últimos 30 dias); group_by é folder (padrão), screen ou tag; folder_id limita o relatório a uma pasta e a tudo o que ela contém, e com direct=true à pasta e às suas pastas filhas ou, agrupado por tela, às telas que estão diretamente nela; tag mantém as telas com essa tag. Uma linha de pasta traz id, parent_id e depth, para que um cliente desenhe a estrutura a partir das linhas. A disponibilidade é o tempo online sobre o tempo registrado, e a cobertura registrada diz que parte do período as telas informaram um estado.
A página Integridade do painel apresenta esses resumos conforme as pastas de telas: cada pasta abre suas subpastas e suas telas, e cada tela abre sua aba Integridade.
CSV, XLSX e PDF
Cada rota de relatório aceita format=csv, xlsx ou pdf e responde com um anexo com as mesmas linhas: os novos relatórios, GET /api/uptime/daily, GET /api/screens/{id}/uptime, GET /api/screens/{id}/health/history, GET /api/health/trend, GET /api/alerts, GET /api/playback, GET /api/playback/plays, GET /api/playback/totals, GET /api/playback/completeness, os relatórios de entrega, preenchimento e gasto de anúncios e o relatório de uma campanha direta. Um relatório paginado é gravado inteiro, até 50.000 linhas; truncated indica quando ele contém apenas as primeiras linhas.
O arquivo XLSX é uma única planilha com o título e o período acima de um cabeçalho fixo, números como números e totais em negrito. O PDF é um demonstrativo sóbrio com o nome screenRIG, o projeto a que se destina, o título e o período, uma tabela cujo cabeçalho se repete em cada página, os totais e os números de página, pronto para enviar. O CSV começa com os rótulos das colunas e neutraliza uma célula de texto que uma planilha executaria como fórmula.
screenrig reports show fleet_health --group-by folder --format pdf --output fleet-health.pdf
screenrig reports show proof_of_play --advertiser "Acme Corp" --from 2026-10-01 --to 2026-10-31 --format pdf --output acme.pdf
screenrig project uptime --format xlsx --output uptime.xlsx
screenrig alerts list --state all --format csv --output alerts.csv
Comprovante de exibição para um patrocinador ou anunciante
proof_of_play soma as exibições das campanhas diretas do projeto. Uma exibição conta quando a tela informa que a mídia terminou na tela. Indique uma campanha com campaign_id, ou todas as campanhas de um patrocinador ou anunciante com advertiser (o nome exato, sem diferenciar maiúsculas). Cada linha é uma campanha, um arquivo de mídia e uma tela com suas exibições, horas exibidas, primeiro e último dia e, quando a tela tem uma estimativa de audiência, impressões estimadas. O PDF é o comprovante para enviar.
Programações de e-mail
Uma assinatura de relatório indica um tipo de relatório e seus filtros, uma cadência, um formato de arquivo e os membros do projeto que o recebem. POST /api/report-subscriptions cria uma; uma organização tem no máximo 50 em todos os seus projetos (report_subscription_limit_reached).
| Membro | Significado |
|---|---|
kind | fleet_health, uptime, publishing, alerts, alert_log ou proof_of_play |
filters | Os filtros do relatório além dos dias: group_by, folder_id, direct, tag, campaign_id, advertiser |
schedule | cadence daily, weekly (weekday) ou monthly (day_of_month, 1 a 28), hour de 0 a 23 e um timezone IANA |
format | pdf, xlsx ou csv, anexado ao e-mail |
recipients | Membros do projeto, indicados por user_id ou pelo endereço de e-mail do membro |
Cada envio cobre o período anterior, em dias UTC: o dia anterior em um envio diário, os sete dias anteriores em um semanal e o mês inteiro anterior em um mensal, pelo calendário do fuso horário da programação. Os destinatários são membros do projeto, verificados de novo a cada envio: qualquer outra pessoa é recusada ao gravar a assinatura, e um membro que sai, ou cujo endereço não está verificado, deixa de recebê-lo. O anexo tem no máximo 8 MiB.
Um envio que falha é repetido após 15 minutos, 1 hora e 4 horas, e depois aguarda a próxima ocorrência. A assinatura mostra last_status (delivered ou failed), last_error, os dias que o último envio cobriu e next_run_at. POST /api/report-subscriptions/{id}/send envia agora para o período que um envio cobriria agora, sem mover a programação, e responde com a assinatura e o resultado deste envio.
screenrig reports subscriptions create --name "Monday fleet health" --kind fleet_health \
--cadence weekly --weekday monday --hour 7 --timezone America/Los_Angeles \
--format pdf --recipients ann@example.com,usr_ID
screenrig reports subscriptions list
screenrig reports subscriptions send rsub_ID
A página Relatórios do painel tem as mesmas programações em Programações de e-mail.
Exportar um projeto inteiro
screenrig project export DIR grava os dados do projeto em um diretório em formatos abertos. Confira o resultado de cada seção antes de usar a cópia para recuperação.
| Caminho | Contém |
|---|---|
export.json | O formato (screenrig.export/v1), quando foi feita, o resultado de cada seção e cada arquivo com seu tamanho e SHA-256 |
project.json, tags.json | O projeto e suas tags com suas telas |
screens/ | screens.json, folders.json e schedules.json (os níveis, a tomada de controle e a programação de exibição de cada tela) |
playlists/ | Cada playlist e cada revisão, em JSON |
campaigns.json, advertising/direct-campaigns.json | Campanhas e campanhas diretas |
cards/, sources.json, applications.json, triggers.json | Cartões com seus dados, configuração de fontes de dados, metadados de aplicativos e gatilhos de alertas |
applications/APP_ID/kv.json | Entradas K/V persistentes de cada aplicativo: valores em base64, tipos de conteúdo, quantidade de bytes, SHA-256 e revisões |
notifications.json, webhooks.json, alert-mutes.json, report-subscriptions.json | Notificações, webhooks, silenciamentos e programações |
media/files/ e media/manifest.json | Os arquivos de mídia originais e, de cada um, o id, o nome, o tipo, o tamanho e o SHA-256 |
data/ | CSV de exibições, totais de reprodução, disponibilidade diária, disponibilidade por tela e alertas |
log/events.jsonl | O registro de eventos do projeto, um evento JSON por linha |
log/audit.jsonl, log/audit-head.json | O registro de auditoria, uma entrada JSON por linha, e o cabeçalho de sua cadeia |
Mantenha os arquivos originais dos aplicativos junto às exportações para recuperar versões, incluindo as fixadas por playlists antigas. As omissões de conteúdo aparecem na seção de arquivos de aplicativos e definem data.complete:false com export_application_content_omitted, inclusive com --no-media. Executar novamente atualiza os metadados.
Os dados K/V dos aplicativos são copiados integralmente tanto com --no-media quanto com --since. Se a leitura da lista K/V ou de um valor falhar, a seção applications falha com export_section_failed e define data.complete:false. Resolva o erro de leitura e execute a exportação novamente para atualizar a cópia.
As credenciais nunca estão na cópia: a chave de assinatura e o endereço de recebimento de um webhook, a credencial de chat ou pager de uma notificação e os segredos de uma fonte de dados ficam de fora (o arquivo mantém a origem do receptor e os nomes dos segredos). Executar de novo é seguro: os arquivos JSON são reescritos inteiros, um arquivo de mídia já completo é mantido e um download parcial continua dos bytes que já tem. Cada arquivo de mídia é verificado contra o SHA-256 que o projeto guarda antes de ser mantido. --no-media pula os arquivos de mídia e --since DAY inicia os dados CSV e o registro de eventos em um dia. Cada requisição é uma requisição de API cobrada, e os downloads de mídia são egress.