Query Activity em Overwrite direto na Data Extension final

Em uma frase: Overwrite troca todo o conteúdo da Data Extension pelo resultado da query, então um resultado vazio ou incompleto vira uma Data Extension vazia ou incompleta, sem erro nenhum.

O cenário típico é uma automação diária: um import traz o arquivo do CRM para uma DE de origem, uma Query Activity monta o público de envio em Overwrite, e um Send Email Activity dispara logo depois. Funciona por meses. Até o dia em que o arquivo chega vazio, chega pela metade ou não chega.

Por que é um erro crítico

O Overwrite não faz a pergunta "isso aqui parece certo?". Ele substitui. Se a query não encontrou linhas porque a origem estava vazia, a DE de destino termina vazia. Se encontrou só metade porque o import parou no meio, ela termina com metade. Para o Automation Studio, a atividade rodou com sucesso, e o passo seguinte segue em frente.

É crítico por três motivos:

• O dano é imediato. A perda acontece na própria execução, não ao longo de meses.
• O sucesso esconde a falha. Não existe alerta de erro quando a query roda bem e devolve zero linhas.
• O efeito vai para fora da empresa. Se o envio está na mesma automação, ele sai para a base errada (ou para ninguém) antes de qualquer pessoa olhar.

Quando a DE sobrescrita é a de histórico ou uma tabela mestra, o problema deixa de ser um envio perdido: é dado que não existe mais em lugar nenhum da conta.

Como identificar e depurar

Comece pelo mapa: liste as Query Activities com ação Overwrite e, para cada uma, pergunte se o destino é a DE final (a que alimenta envio, Journey ou relatório) ou uma DE intermediária. Overwrite direto na final, sem nenhuma conferência entre a query e o uso, é o desenho a corrigir.

Quando o incidente já aconteceu, o roteiro de investigação é voltar no tempo pela automação:

• o histórico de execuções do Automation Studio mostra quando cada passo rodou e quanto tempo levou;
• a contagem de linhas da DE de origem no momento da execução, se ela tiver data de carga, diz se o problema veio antes da query;
• o File Drop ou o import mostra se o arquivo chegou, e com quantas linhas.

Quase sempre a causa está a montante: o arquivo atrasou, veio com cabeçalho diferente, ou um filtro de data pegou o dia errado por causa do fuso horário (o servidor do Marketing Cloud não está no horário de Brasília).

A correção estrutural tem um nome simples: staging. A query grava numa DE intermediária, uma etapa confere se o resultado faz sentido (tem linhas, tem uma quantidade parecida com a de ontem) e só então os dados vão para a final. Os detalhes dessa conferência variam conforme a conta, e é aí que mora o trabalho de verdade.

Impactos reais na organização

• Campanha que não sai, ou sai errada. Um disparo de Black Friday para zero pessoas é receita que não volta. Um disparo para a metade errada da base é reclamação e descadastro.
• Dado perdido de vez. Overwrite em DE de histórico apaga o passado. Se ninguém exporta essas DEs, não existe backup para restaurar.
• Confiança no time de CRM. Depois do primeiro incidente, a área de negócio passa a pedir conferência manual antes de cada envio, e a automação deixa de economizar tempo.
• Horas de investigação. Sem staging, descobrir o que aconteceu exige reconstruir a execução a partir de logs esparsos, normalmente sob pressão e depois que o cliente já percebeu.