Olá, pessoa que criou a estratégia baseada no relatório de emprego,
Você criou uma regra simples: após o relatório de emprego dos EUA, sua estratégia mantém um ETF de ações por cinco sessões se o crescimento mensal da folha de pagamento superar 175,000. Caso contrário, fica em caixa. Você programou a entrada para depois da abertura do mercado de ações, incluiu os custos de negociação e manteve o limite fixo. Depois, baixou uma série histórica de folhas de pagamento e a usou para reconstruir cada sinal.
O problema que resta está nos dados baixados. Uma série econômica histórica pode conter estimativas revisadas que não estavam disponíveis nas datas em que, supostamente, sua estratégia negociou. Para fazer um backtest honesto de um sinal macroeconômico, você precisa da versão disponível em cada momento de decisão. Adiar a entrada em 1 candle não corrige o uso de um número publicado dois meses depois.
Sua observação de janeiro tem vários aniversários
Considere este histórico de divulgações fictício. As datas e variações na folha de pagamento ilustram o mecanismo; não são resultados econômicos divulgados.
| Divulgação | Mês de referência | Variação divulgada na folha de pagamento | Sua regra naquela divulgação |
|---|---|---|---|
| 7 de fevereiro, 08:30 ET | Janeiro | +150,000 | Ficar em caixa |
| 7 de março, 08:30 ET | Janeiro, revisado | +185,000 | Não altera a decisão de fevereiro |
| 4 de abril, 08:30 ET | Janeiro, revisado novamente | +210,000 | Não altera a decisão de fevereiro |
Se os dados baixados mostram janeiro como +210,000, sua simulação entra no ETF em fevereiro. Sua regra real teria ficado em caixa. Todos os preços, horários de ordens e comissões podem estar corretos, mas essa operação inteira é fictícia.
Não dá para presumir que essa contaminação melhora o desempenho. As revisões podem gerar operações vencedoras, gerar operações perdedoras ou eliminar qualquer uma delas. O problema é que sua simulação responde a uma pergunta que sua estratégia não poderia ter feito naquele momento.
E janeiro é apenas o período medido. Não é a data em que você soube o resultado da medição. Uma linha identificada como 1º de janeiro não dá permissão para negociar com base nela nesse dia.
Registre o histórico de disponibilidade de cada valor
Sua tabela de pesquisa precisa de mais do que um mês e um número. Guarde o período de referência, o valor, o horário da divulgação, o identificador da versão e a fonte. Se a coleta for contínua, registre também quando seu sistema recebeu a divulgação. Preserve as versões antigas em vez de sobrescrever seus valores.
Em cada momento de decisão, selecione a versão elegível mais recente de cada observação cujo horário de disponibilidade seja igual ou anterior à decisão. Em seguida, calcule suas variáveis a partir desse retrato reconstruído dos dados.
Sua regra de consulta: primeiro, filtre os registros pelo que já estava disponível; depois, selecione as versões aplicáveis; por fim, calcule o sinal. Calcular as variáveis com base no histórico revisado de hoje e deslocar o resultado depois mantém o vazamento.
O período de manutenção de cinco sessões não torna essa organização opcional. Ele dá mais margem para escolher um horário de entrada conservador; não dá acesso antecipado às revisões.
Em pesquisas antigas, talvez você tenha comprovação do horário de divulgação pública, mas nenhum registro de quando recebeu os dados. Deixe essa diferença explícita. Você pode modelar o acesso após um horário de publicação documentado, aplicando um atraso declarado. Não descreva essa suposição como se fosse um registro medido da entrega histórica.
Você também vai querer um horário com fuso definido. Armazene o horário local documentado da divulgação e faça a conversão corretamente; um deslocamento UTC fixo para Nova York falhará quando o horário de verão mudar. Faça essa pequena gentileza para seu eu do futuro. Seu eu de setembro não deveria ter que decifrar a coluna do seu eu de março chamada date_actual_final2.
Suas variáveis móveis precisam considerar toda a versão dos dados
Suponha que você troque o limite fixo por “crescimento da folha de pagamento acima da média dos 12 meses anteriores”. Agora, precisa das observações anteriores tal como eram naquele momento de decisão, incluindo as revisões já publicadas até então.
Usar para sempre a primeira divulgação de cada mês define uma variável diferente. Esse pode ser um desenho válido se você quiser explicitamente um histórico dos anúncios iniciais. Mas ele não reconstrói o histórico econômico visível em uma manhã específica, pois o conjunto de informações disponível naquela manhã talvez já incluísse revisões de meses anteriores.
Se você calcular as variações mensais da folha de pagamento a partir dos níveis de emprego, reconstrua a série de níveis usando a versão pertinente antes de calcular as diferenças. Misturar um nível recém-divulgado com o nível do mês anterior de uma versão mais antiga pode criar uma variação que não constava em nenhum retrato publicado dos dados.
Por isso, você precisa especificar o que sua variável representa: anúncios iniciais, o quadro econômico mais recente disponível ou as próprias revisões. “Crescimento da folha de pagamento” deixa muita coisa em aberto.
Corrija uma divulgação antes de refazer 10 anos de backtest
Você pode começar pelo ALFRED, que oferece históricos de versões para muitas séries econômicas. Confira se há cobertura para a série e o período exatos que você usa. A data de uma versão, por si só, não comprova a disponibilidade intradiária; combine-a com o horário documentado da divulgação antes de usá-la em um sinal do mesmo dia.
Para sua primeira auditoria, escolha uma divulgação e reconstrua os dados manualmente:
- Encontre a divulgação arquivada e registre o horário de publicação, o mês de referência e o valor inicial.
- Reconstrua o retrato dos dados que sua estratégia teria recebido antes da entrada.
- Calcule o sinal manualmente e compare-o com o da simulação.
- Adicione uma revisão posterior ao repositório de dados e confirme que a decisão anterior continua igual.
Essa última verificação é especialmente útil em um pipeline automatizado de pesquisa. Forneça ao seu agente de pesquisa o limite temporal do retrato dos dados e os identificadores das versões selecionadas junto com os valores das variáveis. Você precisa de evidências suficientes para rastrear uma operação até uma divulgação específica, mesmo depois que o banco de dados subjacente crescer.
Depois que essa decisão isolada for reproduzida, refaça o histórico e compare as divergências entre sinais antes de comparar os retornos. Conte as entradas criadas, removidas ou deslocadas pela correção. Você aprenderá mais com essas decisões alteradas do que com um único Sharpe antes e depois.
Sua operação de fevereiro precisa se sustentar com as informações disponíveis em fevereiro. Deixe a revisão de abril em abril.
← Todos os artigos


