Quebre Queries Grandes em Stages em Vez de Tentar Ser Herói
Tabelas intermediárias são padrão de arquitetura, não derrota.
O nível de evidência descreve minha experiência com o conteúdo. Fonte oficial descreve contrato/documentação da plataforma. Observação de produção não deve ser tratada automaticamente como limite oficial.
Quando uma Query Activity acumula joins, scans e transformações demais, divida o trabalho em etapas determinísticas. Você ganha observabilidade, scans menores e isolamento de falhas muito melhor.
Cada stage deve ter uma responsabilidade óbvia.
Use Overwrite em tabelas de staging descartáveis quando fizer sentido.
Mantenha contratos downstream explícitos.
Meça runtime por etapa em vez de tratar a automation como uma caixa-preta única.
Por que isso importa no SFMC
Query Activities possuem limite rígido de 30 minutos de execução. A Salesforce também publica soft limits para quantidade de joins e Data Extensions operadas em uma única query.
A Salesforce recomenda 3 joins ou menos para melhor performance, embora 4 joins seja o soft limit publicado.
Um desenho prático
Em vez de uma query enorme de tracking, crie etapas Jobs → Opens → Subscribers → Final Target. Isso espelha o próprio exemplo de otimização com tabelas intermediárias da Salesforce.
Ganho operacional
Quando uma etapa falha, você sabe onde está o problema. É possível inspecionar a DE intermediária, validar volume de linhas e rerodar apenas o necessário.