Pular para o conteúdo

O resultado

Um job concluido devolve inteligência, não dado bruto: os achados, contas prontas sobre a simulação, e o veredito de cada UF. Eles vêm pela API (GET /v1/jobs/{id}/findings), pelo MCP (get_findings) e no app, em Achados, na página do job. O arquivo que a máquina produz fica no armazenamento privado da plataforma, com o hash e o tamanho no registro do job, e não é servido: nenhuma linha de evento e nenhuma tabela por célula sai da plataforma.

  • Antes de o job concluir, o pedido é recusado com 409 result_not_ready.
  • Os achados ficam guardados por 365 dias depois do job, ou até você apagar os dados dele.
  • O mesmo pedido, na mesma release e com o mesmo motor, gera os mesmos achados: a simulação é determinística.

Cada tabela é uma conta sobre o que a simulação publicou, por município e indicador:

tabela O que traz
saturacao O total, a penetração e os dias até 50% e 90%, por município e indicador.
alcance_efetivo As primeiras exposições por município e fonte (boca a boca ou mídia).
alcance_potencial A população que cada canal pode alcançar dentro do alvo.
contribuicao e elasticidade O efeito de cada canal, por município e indicador: por contrafactual no mesmo grupo de comparação, com a intensidade a 90% e com o canal removido.
veredito O teste fora da amostra de cada UF, ao lado da calibracao: o veredito, e cada teste com o período, o valor e o limite.
  • Por padrão vêm só as linhas dos municípios do público do cenário (a tabela veredito, que é por UF, vem inteira); municipio (repetível) escolhe outros, e uma lista vazia no MCP traz todos.
  • limite vai de 1 a 1.000 linhas (padrão 200), e total diz quantas linhas casaram antes do limite.
  • Uma tabela que o tipo de resultado não tem volta vazia: a adoção, por exemplo, não tem efeito de canal.

Num público em faixas de 5 anos, aberto hoje em todas as UFs menos o Piauí (Cenário), os achados são calculados sobre a grade etária, por município, faixa de 5 anos e sexo; grade, na resposta, diz qual grade a tabela descreve (principal ou etaria).

Toda conta dos achados é uma soma sobre as células que a simulação publicou, e cada célula carrega dois rótulos que os achados herdam:

  • origem é sempre sintetico_generativo: todo número é gerado por modelo, nunca observado.
  • calibracao vale calibrado ou nao_calibrado: se o número vem de um cenário-base ajustado a uma série real, num job de uma release em que o ajuste foi testado (hoje, a v2.0.0 e a v1.2.0). Os dias depois do dia 365 ficam além do horizonte validado e nunca são calibrado. Veja O que medimos.

A simulação conta pessoas por dia, área e célula do público (faixa de idade, sexo, renda, escolaridade e raça). Uma célula com 1 a 4 pessoas nunca é publicada, e a célula que a revelaria por diferença com um total que o Censo publica também sai; uma mídia que chega só a uma parte de uma célula retém a célula; e um público em faixas de 5 anos retém, na grade principal, as células com o perfil dele, na UF inteira. Os achados são somados só sobre o que foi publicado, e por isso os totais erram sempre para baixo, mais onde há muitas células pequenas: municípios pequenos, áreas pouco povoadas e públicos muito recortados. Para o total de uma área, compare com a população que o Censo publica para ela. A regra vale para todo resultado e não pode ser desligada por pedido (Privacidade).

O rótulo calibracao diz que o número vem de um cenário-base ajustado a uma série real. O veredito diz como esse ajuste foi no teste fora da amostra, nos 12 meses depois da janela de ajuste, para cada UF do job. Ele vem nos achados, na tabela veredito, e no plano.json, ao lado da calibracao:

veredito O que quer dizer
passou A UF passou em todos os testes: o erro contra a série real (MAPE) em cada trimestre, a ordem por idade e a ordem entre municípios.
reprovado_declarado A UF reprovou num teste de ordem, e a reprovação está declarada, com o valor e o limite. O erro contra a série real passou.
nao_pontuado O teste não rodou para este job: outra release, ou um cenário diferente do ajustado. A calibracao também é nao_calibrado.

Cada linha da tabela é um teste num período, com o valor, o limite e o resultado (passou, reprovou ou nao_se_aplica). A ordem entre municípios não se aplica a uma UF de um município só, como o DF. A recepção de mensagens não tem veredito, porque ainda não tem teste fora da amostra. O método e a tabela completa estão em O que medimos.

GET /v1/jobs/compare?a={id}&b={id} (ou compare_jobs no MCP) põe lado a lado duas simulações concluídas do projeto, na mesma release:

  • a e b, o cenário de cada uma: nome, release, familia, horizonte, grupo_comparacao, a grade dos achados e, quando o cenário roda sobre uma base calibrada, o veredito de cada UF (nulo na recepção).
  • tabelas, os números principais de cada tabela dos achados (saturacao, alcance_efetivo, alcance_potencial, contribuicao e elasticidade), linha a linha. chaves diz as colunas que casam as linhas dos dois jobs (município, indicador, fonte, canal) e valores, os números comparados: a média das réplicas, ou a população em alcance_potencial. Cada linha traz a, b e a diferenca, b menos a; uma linha que só um dos jobs tem vem com o outro lado e a diferença nulos.

A comparação lê só o que a rota dos achados serve, somas sobre as células publicadas: a regra das células retidas vale do mesmo jeito. Por padrão vêm os municípios que um dos dois cenários tem como alvo (todos, se nenhum nomeia municípios); municipio (repetível) escolhe outros, e limite vai de 1 a 1.000 linhas por tabela.

  • mesmo_grupo_comparacao: dois cenários do mesmo grupo de comparação usam os mesmos números aleatórios, e a diferença vem do plano, não do acaso. Em grupos diferentes, parte dela pode ser acaso.
  • O que não se compara: jobs de releases diferentes (422 release_mismatch: a release é a população que os números contam), uma calibração (422 not_a_simulation) e um job que não concluiu ou teve os dados apagados (409 result_not_ready). Os dois jobs são do projeto da chave: um job de outro projeto responde 404 not_found, como em toda rota.