Lookup dentro de loop no AMPscript: rápido no teste, lento no envio real

Em uma frase: cada Lookup é uma consulta a uma Data Extension, e colocar um dentro de um FOR multiplica as consultas pelo número de linhas, para cada assinante do envio.

O código nasce assim porque é o jeito mais direto de pensar: para cada produto do carrinho, busque o nome; para cada pedido, busque o status. No preview, com um assinante e cinco linhas, renderiza na hora. No envio de verdade, com centenas de milhares de assinantes, o mesmo código faz milhões de consultas.

Por que é um erro médio

Ele não perde dado nem fere consentimento, por isso não é crítico. Também não é comum no sentido de "pequeno": o custo cresce com o volume, e o volume costuma crescer justamente nas campanhas que mais importam.

O que o torna médio é o tipo de dano. O envio fica lento, a fila de render demora, e em casos mais pesados o e-mail de um assinante pode falhar no render e não ser enviado para ele. É desempenho e confiabilidade, não perda permanente. Mas é o tipo de problema que aparece no pior momento, porque só se manifesta em escala.

Como identificar e depurar

O sinal mais claro é a diferença entre o teste e o real: preview instantâneo, envio que leva muito mais tempo do que envios de tamanho parecido. Outro sinal é o relatório de envio com assinantes que não receberam por erro de render, concentrados nos que têm mais linhas relacionadas (o cliente com 30 pedidos, não o com 1).

No código, procure o padrão: Lookup, LookupRows ou LookupOrderedRows entre um FOR e o NEXT. Conte quantas consultas um assinante "pesado" dispara: se são 30 linhas e dois lookups por linha, são 60 consultas para uma única pessoa, antes mesmo do resto do e-mail.

A linha de investigação é sempre a mesma: trazer os dados de uma vez e iterar sobre o que já veio. Muitas vezes um único LookupRows antes do loop resolve. Quando a informação está espalhada em várias DEs, a resposta melhor costuma estar fora do e-mail: uma Query Activity que junta tudo numa DE já pronta para o envio. Qual dos dois caminhos serve depende do volume e de quantas DEs entram na conta.

Impactos reais na organização

• Envio que atrasa. Campanha de horário marcado (abertura de vendas, aviso de prazo) que chega horas depois perde boa parte do sentido.
• Assinantes que não recebem. Falha de render tira pessoas do envio sem que a área de negócio saiba quem foram.
• Escala travada. O mesmo e-mail que funciona para 10 mil assinantes vira problema com 500 mil. A empresa cresce e o template precisa ser reescrito.
• Diagnóstico difícil. Como o preview sempre funciona, o time tende a culpar a plataforma, e a investigação começa pelo lugar errado.