Documentação / Simulacao: 100 mensagens MARKETING com IA rewrite + Jitter humano

Simulacao: 100 mensagens MARKETING com IA rewrite + Jitter humano

Entrar

Simulacao: 100 mensagens MARKETING com IA rewrite + Jitter humano

Objetivo

Simular o comportamento de anti-spam quando um tenant envia 100 mensagens de template MARKETING com:

  • marketingOptions.aiRewriteEnabled = true (reescrita por IA por mensagem)
  • jitter humano ativo no worker (estado por tenant + instancia + ambiente)

Valido para os dois caminhos de origem:

  • API publica (POST /v1/messages/send)
  • Tela Messages (apps/fullstack/src/spa/pages/Messages.tsx) com toggle de IA marcado

Premissas da simulacao

  • Todas as 100 mensagens sao MARKETING e entram no mesmo fluxo (mesmo tenant + mesma instancia conectada + mesmo ambiente).
  • A API/fullstack apenas persiste intencao; quem decide atraso e o worker.
  • Parametros de jitter:
    • base entre 8s e 25s (random walk, sem repeticao imediata)
    • pausa longa entre 90s e 180s
    • frequencia media de pausa longa: a cada 5 a 8 mensagens
  • O worker permanece estavel (sem queda), e o Redis esta saudavel no cenario principal.

O que acontece por mensagem

Para cada mensagem:

  1. Entra como QUEUED com intencao de jitter humano no renderPlan.humanJitter.
  2. Worker calcula o proximo atraso do fluxo (Redis + random walk humano).
  3. Worker persiste deliverBy + humanJitter.applied=true (idempotente).
  4. Mensagem espera ate deliverBy e depois segue envio.
  5. Se aiRewriteEnabled=true, o texto final renderizado passa por variacao de IA antes do envio efetivo.

Resultado: as mensagens ficam menos "identicas no tempo" (jitter) e menos "identicas no texto" (IA).

Simulacao numerica (100 mensagens)

Distribuicao esperada de pausas longas

  • Intervalo de pausa a cada 5-8 mensagens:
    • minimo teorico: 12 pausas (100/8 arredondado para cima)
    • maximo teorico: 20 pausas (100/5)
    • media pratica esperada: ~15 pausas

Tempo acumulado esperado (mesmo fluxo serial)

  • Delay base medio aproximado: 16.5s por mensagem
    • 100 x 16.5s = 1650s (~27m30s)
  • Pausa longa media aproximada: 135s cada
    • 15 x 135s = 2025s (~33m45s)
  • Total medio adicional estimado:
    • 1650s + 2025s = 3675s (~61m15s)

Leitura pratica: para 100 mensagens no mesmo fluxo, a campanha tende a se espalhar em cerca de 50-75 minutos (variando conforme RNG e quantidade de pausas).

Amostra de sequencia (primeiras 20 mensagens)

Exemplo ilustrativo de uma corrida possivel:

  • Mensagens 1-6: delays entre 11s e 19s (sem repeticao imediata)
  • Mensagem 7: pausa longa de 124s
  • Mensagens 8-13: delays entre 9s e 21s
  • Mensagem 14: pausa longa de 171s
  • Mensagens 15-20: delays entre 10s e 23s

Mesmo com faixa 8-25s, a sequencia nao fica "escadinha" constante; ha inversoes e ruido de direcao, e pausas quebram burst.

Impacto combinado das 2 estrategias anti-spam

1) Reescrita por IA (conteudo)

  • Reduz repeticao textual entre mensagens consecutivas.
  • Mantem intencao semantica do template.
  • Caso a variacao nao seja possivel, fallback para texto original (sem bloquear envio).

2) Jitter humano (tempo)

  • Reduz padrao de disparo mecanico.
  • Evita repeticao imediata de delay e tendencia monotona longa.
  • Insere pausas humanas ocasionais para "parar e voltar".

Combinacao pratica

Para um lote de 100:

  • a similaridade textual cai (IA)
  • a regularidade temporal cai (jitter)
  • o risco de assinatura de spam por repeticao de texto + ritmo tende a diminuir

Diferenca entre API publica e tela Messages

No cenario descrito, o comportamento anti-spam final e o mesmo nos dois canais, desde que:

  • template seja MARKETING
  • marketingOptions.aiRewriteEnabled=true esteja presente

A diferenca principal e apenas de origem da requisicao (cliente API x UI).

Cenario degradado (Redis indisponivel)

Se Redis falhar durante a campanha:

  • worker continua enviando em stateSource=degraded_local
  • usa jitter basico dentro de min/max (sem estado distribuido)
  • dispara alerta de degradacao para Dev (com throttle/dedupe)
  • quando Redis volta, retorna automaticamente para stateSource=redis

Efeito esperado: preserva continuidade de envio (objetivo primario), com perda temporaria de "sequencia humana stateful" entre mensagens.

Checklist rapido para rodar essa simulacao em ambiente real

  • Preparar 100 destinos validos (ou sandbox controlado).
  • Usar template MARKETING aprovado.
  • Enviar com marketingOptions.aiRewriteEnabled=true (API ou UI).
  • Coletar no banco/traces:
    • renderPlan.humanJitter (applied, computedDelayMs, pauseApplied, stateSource)
    • eventos de trace de etapa do worker para jitter aplicado
  • Conferir:
    • ausencia de repeticao imediata relevante em computedDelayMs
    • presenca de pausas longas recorrentes
    • distribuicao total da campanha no tempo

Conclusao

Para um lote de 100 mensagens MARKETING com IA rewrite habilitado, o efeito combinado esperado e:

  • campanha menos bursty no tempo
  • mensagens menos repetitivas no texto
  • maior resiliencia operacional (com fallback em falha de Redis)

Isso melhora o perfil anti-spam sem alterar o contrato de envio para quem usa API publica ou tela de envio.