BK-556 — Compras de destinatarios do WhatsApp sem clique

Estado: aguardando decisao do ADMIN; nenhuma implementacao de atribuicao autorizada por inferencia.

Medicao: 15/10/2026, aproximadamente 17:34 -03. Escopo: Rio no Teatro + Divulg AI.

Resposta verificada

Ja existe: /www/wwwroot/divulgai.com.br/campanha.php, ramo vendas (linha 369),

chama a acao vendas de bot/whatsapp/prefs_api.php, que chama

includes/rnt_wa_campanha_publico.php::rnt_wa_campanha_vendas (linha 215).

O publico da campanha e construido a partir do cadastro: chave de recipients = telefone;

c = clientes.id; t = epoch do envio; s = estado do envio; st = retorno de entrega.

O relatorio pega os IDs c com s=enviado, cruza pedidos.cliente_id, filtra

pedidos.id_evento pela peca e pedidos.created pelo primeiro envio da campanha.

Nao depende de cookie, pixel, clique ou telefone digitado novamente no checkout.

Nao faz um novo JOIN por telefone na compra: reaproveita o vinculo cadastral do envio.

Se a pessoa comprar por outro cadastro com o mesmo numero, esse caminho nao cobre automaticamente.

Nao prova causalidade: sabemos que um destinatario comprou depois, nao que comprou por causa da mensagem.

A ausencia de marca tambem NAO prova ausencia de clique (cookie perdido, outro dispositivo, etc.).

Evidencia real (agregada, sem dados pessoais)

7 JSONs em /www/server/divulgai/campaigns/; 5 possuem recipients de campanhas,

todas da peca 1024. Estados s=enviado somam 660 telefones distintos.

A leva 3 tambem tem 393 pendentes e 1 ignorado, excluidos desta analise.

| Campanha | Enviados | Entregue/lido | Falhou | So sent | Pedidos pagos de destinatarios | Venda paga | Pagos pela marca |

|---|---:|---:|---:|---:|---:|---:|---:|

| c20261008-194612-p1024-l1 | 96 | 82 | 9 | 5 | 1 | R$90 | 0 |

| c20261009-120010-p1024-l2 | 56 | 52 | 4 | 0 | 0 | R$0 | 0 |

| c20261009-120010-p1024-l2b | 55 | 51 | 4 | 0 | 1 | R$135 | 0 |

| c20261009-120010-p1024-l2c | 55 | 49 | 6 | 0 | 1 | R$90 | 0 |

| c20261010-140757-p1024-l3 | 398 | 295 | 100 | 3 | 0 | R$0 | 0 |

| Total | 660 | 529 | 123 | 8 | 3 | R$315 | 0 |

Sao 3 pedidos distintos, todos pagos (status 3/4), 7 ingressos. pedidos.valor e unitario:

2 x 45 + 3 x 45 + 2 x 45 = 315. Os tres destinatarios tem estado atual read/read/delivered.

Intervalos envio individual -> criacao do pedido: 36,60h, 97,22h e 0,18h, respectivamente

levas 1, 2b e 2c. Nenhum dos tres antecede o envio individual.

Nenhum tem ultimo_utm_campaign da campanha. Dois possuem linha de atribuicao com

UTMs nulas; o terceiro nao tem linha. Nenhum dos tres tem gclid/fbclid preenchido.

Isso nao exclui contato com anuncio pago: nao ha trilha completa para demonstrar isso.

Sensibilidade exploratoria, sem mudar regra: usando envio individual e pedidos pagos,

janela de 1 dia encontra 1 pedido; 3 dias, 2; 7 dias, 3; 14 dias, 3.

As campanhas tem apenas cerca de 5 a 7 dias de observacao: 7/14 dias ainda nao sao

janelas maturadas para todos. Amostra de tres compras nao permite escolher janela por desempenho.

Banco e rastreio confirmados

• clientes.id, clientes.celular e clientes.telefone existem.
• Coluna de relacionamento: pedidos.cliente_id; peca: pedidos.id_evento;

criacao da compra: pedidos.created; pedidos.data e a sessao, nao a compra.

Nome da coluna confirmado; nao se afirma aqui existencia de constraint FOREIGN KEY.

• rnt_pedido_atribuicao: 27 linhas, 27 pedidos distintos, zero pedido com multiplas linhas

nesta foto. PRIMARY(id), UNIQUE uk_chave(chave), idx_pedido(pedido_id) NAO unico.

includes/atribuicao_helper.php:354 confirma a protecao de aplicacao BK-530.

• rnt_links_curtos: 209 links, 41 cliques acumulados, primeiro criado em

14/10/2026 16:50:32. Os envios estudados comecaram antes desse mecanismo;

contadores de visitas por UTM nao sao contadores de pessoas nem de links curtos.

• Campos de link: destinatario, peca_id, canal, utm_source, utm_medium,

utm_campaign, codigo, criado_em, cliques, primeiro_clique_em, ultimo_clique_em.

Link criado sozinho nao comprova envio ou entrega.

Qualidade dos telefones

Comparacao em memoria contra os 51.110 cadastros, usando a funcao existente

rnt_wa_prefs_phone_variants (includes/rnt_wa_prefs.php:59), sem exportar PII:

• 660/660 IDs do envio existem e seus numeros correspondem ao cadastro normalizado.
• 508 correspondem ao celular; 152 somente ao telefone.
• 542 campos de origem correspondentes tem mascara; 654 nao tem codigo de pais.
• 17 dos 660 telefones correspondem a mais de um cadastro (2/0/2/3/10 por campanha).
• Nenhuma compra adicional da peca apos o corte foi encontrada nesses outros cadastros.

A funcao remove mascara/zeros iniciais e 55, preserva DDD e considera variacao do nono

digito apenas no padrao de celular antigo; nao usar apenas os ultimos oito digitos.

Igualdade literal de telefone perderia correspondencias reais. Igualdade normalizada

nao prova identidade individual, titularidade atual ou exclusividade (numero compartilhado/reciclado).

A contagem acima valida os numeros enviados; nao e auditoria de todos os telefones da base.

Privacidade: esta investigacao somente leu dados locais e publicou agregados. Uma futura tela

deve manter acesso administrativo e evitar exportar telefones ou abrir endpoint publico.

Compatibilidade tecnica nao constitui parecer sobre base legal/consentimento: nao foi feita

validacao juridica nem auditoria de consentimento nesta rodada.

Lacunas e decisoes pendentes

1. Janela: hoje nao ha limite final; o corte e o primeiro envio da campanha, e nao o de cada

destinatario. Opcoes para o ADMIN: 1 dia (associacao mais proxima), 3 dias, 7 dias (inclui as

tres compras observadas), 14 dias (mais sobreposicao e ainda sem observacao completa).

Definir tambem inclusao dos limites e tratamento de reenvios. Nao ha janela universal provada aqui.

1. Recebimento: s=enviado nao equivale a entrega; ha 123 failed e 8 sent sem confirmacao.

Opcao conservadora: exigir delivered/read e medir a partir do envio individual.

Alternativa: publicar separados enviado/entregue/lido. st_em e a data do estado atual,

nao presumir que seja historico imutavel da primeira entrega.

1. Clique e deduplicacao: hoje pela_marca e de_destinatarios podem se sobrepor;

juntos usa mapas por pedido_id e uniao ($marca + $dest), portanto nao duplica dentro

da mesma campanha, mesmo se houver varias linhas de atribuicao. Nao somar os dois totais.

Para um futuro indicador adicional, usar pedido distinto e NOT EXISTS da atribuicao

da campanha, e chamar de "sem atribuicao rastreada", nao "nao clicou".

Decidir se primeiro toque e outros sinais de clique tambem excluem esse grupo.

1. Multi-touch: nao converter associacao em nova linha de credito integral em

rnt_pedido_atribuicao. Opcao: mostrar influencia como metrica separada, preservando

credito rastreado e marcando sobreposicoes observadas com Google/Meta. Alternativa:

excluir pedidos com sinais pagos observados, sabendo que ausencia de sinais nao prova

ausencia de anuncios. Nao escolher pesos nem last-touch automaticamente.

1. Multicampanha/multicadastro: uma compra pode associar-se a varias campanhas futuras;

definir ultimo envio elegivel, todos como assistencia, ou outra regra aprovada. Total

global deve ser COUNT(DISTINCT pedido_id). Nos dados atuais nao ha destinatario repetido

entre as cinco campanhas; existem 17 numeros multicadastro, sem compra extra observada.

1. Comparacao financeira: o CLI calcula RESULTADO pela margem de juntos menos custo

de mensagens. E resultado associado, nao retorno incremental provado do marketing.

O grupo pela marca nao filtra peca/periodo, somente ultimo_utm_campaign; a marca e gerada

por peca/leva/variante, nao por ID unico do disparo. Reutilizacao futura pode misturar rodadas.

Validacao e reproducao

Leituras de codigo, SHOW COLUMNS/SHOW INDEX e SELECTs agregados no banco real.

O calculo principal foi executado por php83 via stdin, com transacao READ ONLY e rollback,

chamando diretamente rnt_wa_campanha_vendas para cada JSON (IDs com s=enviado, menor t,

utm da campanha). Os pedidos foram comparados tambem com t individual e campos atuais

de telefone/celular. Dados pessoais ficaram somente em memoria; nao foram gravados neste documento.

NAO executar o comando campanha.php vendas como se fosse estritamente read-only:

o final chama divulgai_campaign_register_site, que escreve registro de campanha no site.

Nesta investigacao essa chamada nao foi executada, nem houve envio de mensagem.

Consultas de estrutura/duplicacao reproduziveis:

```sql

SHOW COLUMNS FROM pedidos;

SHOW COLUMNS FROM clientes;

SHOW INDEX FROM rnt_pedido_atribuicao;

SELECT COUNT(*) linhas, COUNT(DISTINCT pedido_id) pedidos FROM rnt_pedido_atribuicao;

SELECT pedido_id, COUNT(*) FROM rnt_pedido_atribuicao

WHERE pedido_id IS NOT NULL GROUP BY pedido_id HAVING COUNT(*) > 1;

```

Somente documentacao alterada; nenhuma mudanca de PHP/JS, schema, atribuicao ou campanhas.

BK permanece aberto para as decisoes acima; revisao do usuario pendente.