Documentação

Relatórios e exportações

Os relatórios leem os agregados do projeto: resumos de disponibilidade, histórico de alertas, estado das telas e entrega de campanhas diretas. Eles nunca varrem eventos brutos. Cada relatório é uma tabela que é gravada como JSON, CSV, XLSX ou PDF, e qualquer relatório pode ser enviado por e-mail em uma programação.

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órioO que uma linha diz
fleet_healthTelas, online agora, disponibilidade, alertas abertos, alertas iniciados no período, quentes, monitor desconectado, falhando e quantas telas exibem seu conteúdo atual
uptimeHoras online e offline, disponibilidade e cobertura registrada
publishingTelas com conteúdo atual, conteúdo em atualização, conteúdo que precisa de atenção e sem conteúdo
alertsAlertas abertos agora e iniciados no período, por condição
alert_logUma linha por alerta iniciado no período: a tela, a condição, quando começou e terminou e quem o reconheceu
proof_of_playExibiçõ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).

MembroSignificado
kindfleet_health, uptime, publishing, alerts, alert_log ou proof_of_play
filtersOs filtros do relatório além dos dias: group_by, folder_id, direct, tag, campaign_id, advertiser
schedulecadence daily, weekly (weekday) ou monthly (day_of_month, 1 a 28), hour de 0 a 23 e um timezone IANA
formatpdf, xlsx ou csv, anexado ao e-mail
recipientsMembros 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.

CaminhoContém
export.jsonO 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.jsonO 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.jsonCampanhas e campanhas diretas
cards/, sources.json, applications.json, triggers.jsonCartões com seus dados, configuração de fontes de dados, metadados de aplicativos e gatilhos de alertas
applications/APP_ID/kv.jsonEntradas 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.jsonNotificações, webhooks, silenciamentos e programações
media/files/ e media/manifest.jsonOs 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.jsonlO registro de eventos do projeto, um evento JSON por linha
log/audit.jsonl, log/audit-head.jsonO 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.