Dash Corinthians: futebol como produto de dados

01 — De uma referência a uma pergunta própria

A ideia começou depois que vi esta publicação no LinkedIn. O post serviu como inspiração para pensar: como seria um painel que olhasse para o Corinthians não apenas como uma sequência de placares, mas como um produto de dados completo?

Em vez de reproduzir uma interface, usei a referência como ponto de partida para formular minhas próprias perguntas. Como comparar temporadas e competições sem perder contexto? Como projetar cenários sem apresentar probabilidade como certeza? Como reunir desempenho esportivo, elenco, mercado e finanças deixando visível a origem e a limitação de cada informação?

O resultado foi o Dash Corinthians, um projeto independente e não oficial. Ele transforma dados públicos e informações editoriais documentadas em uma visão única da campanha, cobrindo da coleta à experiência de leitura.

02 — O problema não era criar mais um gráfico

Resultados e tabelas são fáceis de encontrar. O problema real aparece quando tentamos responder perguntas que atravessam fontes e granularidades:

• o desempenho mudou entre temporadas ou apenas entre competições?
• o time rende de forma diferente em casa e fora?
• qual é o efeito da sequência de jogos e do tempo de descanso?
• quais setores do elenco apresentam sinais de carência?
• que cenários de classificação ainda são plausíveis?
• quais dados sustentam uma análise de mercado ou financeira?

Responder a isso exige mais que visualização. Exige identidade de partidas, padronização de competições, regras para dados ausentes, métricas consistentes e distinção clara entre fato observado, estimativa e heurística.

Essa separação se tornou um princípio do projeto: o dashboard deveria ser informativo sem fingir uma precisão que os dados não oferecem.

03 — Arquitetura: processamento privado, leitura pública

A principal decisão arquitetural foi separar completamente a atualização dos dados da publicação do site:

APIs esportivas ─┐
                 ├─→ ETL local → validação → dashboard.json → Vercel
Dados editoriais ┘

O ETL roda localmente em Python. É nesse ambiente que ficam chaves opcionais, cache HTTP e decisões de atualização. A Vercel recebe somente os arquivos estáticos e o dashboard.json já processado.

Essa escolha produz algumas vantagens profissionais importantes:

• credenciais nunca chegam ao navegador ou à hospedagem;
• o frontend não depende da disponibilidade momentânea das APIs;
• o artefato publicado pode ser versionado e auditado;
• o custo e a complexidade de operação permanecem baixos;
• uma atualização ruim pode ser identificada antes de virar publicação.

O trade-off é intencional: não se trata de tempo real. O painel representa um snapshot com data de geração explícita.

04 — Fontes diferentes, responsabilidades diferentes

A ESPN funciona como fonte principal para partidas, tabelas, súmulas, estatísticas e elenco. API-Football e football-data.org podem complementar lacunas quando configuradas, enquanto o TheSportsDB auxilia nas fotos de atletas.

Já informações sobre técnicos, balanços, valores de mercado e transfer bans passam por arquivos editoriais. Nesses casos, cada registro precisa manter sua fonte e sua data-base.

Essa divisão evita um erro comum em projetos analíticos: tratar todos os dados como se tivessem a mesma natureza. Um placar coletado de uma súmula, uma projeção Monte Carlo e uma obrigação financeira noticiada possuem graus diferentes de atualização, precisão e interpretação. A interface precisa preservar essas diferenças.

05 — Coleta resiliente e normalização

Integrações externas falham. Elas também mudam, limitam requisições e podem devolver o mesmo conceito em formatos distintos. Por isso, a camada de coleta implementa cache em disco, TTL, retries, limitação de chamadas e fallback para cache vencido.

Depois da coleta, as partidas são normalizadas sempre na perspectiva do Corinthians. Mando de campo, adversário, placar, resultado, competição e intervalo de descanso passam a obedecer ao mesmo contrato, independentemente da fonte original.

Resposta externa
      ↓
Adaptador da fonte
      ↓
Modelo normalizado
      ↓
Métricas e recortes

Essa fronteira impede que detalhes de uma API vazem para todo o sistema. Quando uma integração muda, o impacto fica concentrado no adaptador e não em cada gráfico do dashboard.

06 — A camada analítica

Com os dados normalizados, o pipeline constrói visões por temporada, competição e mando de campo. O painel reúne:

• campanha, aproveitamento, pontos por jogo, saldo e forma recente;
• evolução de pontos e distribuição de resultados;
• comparação casa versus fora e temporada versus temporada;
• jogos, estádios, público, descanso e sequências;
• clássicos, gols por faixa de minuto, artilheiros e assistentes;
• comparação dos cinco trabalhos mais recentes de técnicos;
• diagnóstico explicável do elenco por setor;
• radar de mercado e custo-benefício quando há valor documentado;
• receitas, passivo e riscos editoriais de transfer ban;
• cobertura e qualidade do próprio conjunto de dados.

O ponto não é acumular indicadores. Cada bloco tenta responder uma pergunta e expõe contexto suficiente para que o número não seja interpretado sozinho.

07 — Simulação sem promessa

Para o Brasileirão, o projeto executa 10.000 cenários com um modelo de Poisson e seed fixa. A simulação estima distribuições de posição e probabilidades para diferentes faixas da tabela.

O uso profissional de um modelo como esse depende da forma como ele é comunicado. A saída é apresentada como cenário probabilístico, não como previsão garantida. Os resultados mudam quando entram partidas, tabela e calendário novos; portanto, sempre pertencem à data-base do snapshot.

Reprodutibilidade também importa. A seed fixa permite investigar uma alteração no modelo sem confundir mudança de lógica com simples variação aleatória.

08 — Qualidade como parte do produto

O pipeline não considera o trabalho concluído quando consegue gerar JSON. Antes da publicação, um validador offline confere contrato, totais, duplicidades e valores numéricos inválidos.

No snapshot usado neste case, havia 198 partidas concluídas de 2024 a 2026, 448 eventos de gol detalhados e nenhuma duplicidade por identidade de evento. Súmulas, estádios e estatísticas estavam presentes para todas as partidas concluídas; público tinha cobertura de aproximadamente 88%.

Esses números são exibidos como cobertura, não como certificado de exatidão. Essa distinção é importante: verificar que um campo existe não prova que a fonte esteja correta.

A validação também roda na integração contínua, junto com verificações de sintaxe do Python e do JavaScript. A CI não chama APIs nem refaz o ETL; ela avalia o artefato versionado de maneira determinística.

09 — O snapshot como contrato entre engenharia e interface

O dashboard.json é mais que um arquivo de dados. Ele funciona como contrato entre dois contextos:

Python produz → JSON documenta → JavaScript consome

Essa abordagem permite evoluir o processamento e o frontend separadamente, desde que o contrato seja preservado. Quando ele muda, produtor, consumidor, validador e documentação precisam mudar juntos.

No navegador, JavaScript puro gerencia filtros, temas, estados de erro e os gráficos do Apache ECharts. Não há framework frontend nem etapa de compilação no deploy. Para este escopo, reduzir camadas tornou a entrega mais previsível e manteve o foco no produto de dados.

10 — Decisões de produto e transparência

Algumas análises exigem julgamento. O diagnóstico de elenco, por exemplo, usa regras editáveis e mostra qual indicador disparou cada alerta. O radar de mercado pondera produção e força da liga, mas reconhece limitações de cobertura por posição. Valor de mercado não é tratado como preço de transferência ou salário.

Da mesma forma, a estimativa financeira do ano corrente é parcial, e o indicador de transfer ban é informativo — não um parecer jurídico.

Documentar essas limitações não enfraquece o projeto. Pelo contrário: torna o dado utilizável porque deixa claro até onde cada conclusão pode ir.

11 — O que este projeto demonstra

Embora o tema seja futebol, as competências são transferíveis para outros domínios:

• desenho de pipelines com múltiplas fontes e fallbacks;
• modelagem de contratos entre processamento e consumo;
• cache, resiliência e controle de custos de integração;
• criação de métricas com definição explícita;
• validação automatizada e observabilidade de cobertura;
• comunicação responsável de modelos e estimativas;
• transformação de requisitos amplos em um produto navegável;
• equilíbrio entre valor analítico e simplicidade operacional.

O futebol tornou o processo mais próximo e motivador. A disciplina aplicada, porém, é a mesma necessária em um dashboard operacional, financeiro ou de negócio: entender a pergunta, conhecer a origem do dado, controlar a transformação e comunicar limites.

12 — Próximos passos

O projeto pode evoluir em três frentes. A primeira é ampliar a cobertura histórica sem perder rastreabilidade. A segunda é fortalecer testes das transformações e contratos. A terceira é acompanhar a calibração das probabilidades ao longo da temporada, comparando cenários projetados com resultados observados.

Mais do que adicionar novas telas, o objetivo é melhorar a confiança: saber quando o dado foi atualizado, de onde veio, qual regra o transformou e que decisão ele realmente ajuda a tomar.

Você pode explorar o dashboard publicado ou consultar o repositório do Dash Corinthians. O projeto não possui vínculo oficial com o Sport Club Corinthians Paulista ou com as fontes de dados utilizadas.