BK-557 — Reconciliacao de atribuicao por pedido

Investigado em 15/10/2026, a pedido do ADMIN (apos o BK-556 mostrar que a tabela final

de atribuicao por pedido quase nunca fecha). Investigacao pelo Codex (gpt-6-astra);

2 fixes aplicados foram revisados e validados por mim (Claude) com execucao real,

porque a rodada do Codex foi interrompida por timeout antes do proprio relato final.

Causa raiz 1 (confirmada e corrigida): chave de sessao errada

rnt_atrib_capturar_interno() (includes/atribuicao_helper.php) detectava cliente logado

checando $_SESSION['cliente']['id'] e $_SESSION['CLIENTE_X']['id'] -- **nenhuma das

duas e a chave real**. O login de cliente de verdade (painel/data/Login.php, area do

CLIENTE) grava em $_SESSION['CMS_X_Cliente']['id'], via Login::setId()

(initLogged($tipo='cliente') grava ['logged']/['tipo'] antes). Resultado pratico:

cliente_id ficava SEMPRE null em rnt_atribuicao_contatos, mesmo com o cliente

logado no momento do clique -- confirmado com a campanha do Meta Ads investigada no

BK-556 (utm_campaign=6630301268372): 459 contatos capturados, 0 com cliente_id.

Risco considerado: produtor compartilha a MESMA estrutura de sessao

(CMS_X_Cliente), so com tipo='produtor'. Por isso a correcao exige

$_SESSION['CMS_X_Cliente']['tipo'] === 'cliente' antes de usar o id -- produtor

continua sem gerar cliente_id (nao e cliente).

Fix: includes/atribuicao_helper.php, nova condicao checando CMS_X_Cliente/tipo

primeiro, mantendo os fallbacks antigos (cliente, CLIENTE_X) depois, por seguranca

caso exista algum outro caminho de login legado que ainda os use.

Validado com execucao real (sessao simulada, sem tocar em cliente real, dados de

teste removidos depois):

• Sessao CMS_X_Cliente com tipo=cliente, id=775 (conta real de teste) -> gravou

cliente_id=775 em rnt_atribuicao_contatos (antes do fix, teria ficado null).

• Sessao CMS_X_Cliente com tipo=produtor -> cliente_id ficou vazio, como esperado

(produtor nao e cliente, nao deve ganhar atribuicao de compra).

Causa raiz 2 (confirmada e corrigida): chave de atribuicao perdida ao reaproveitar rascunho

action.php (case de finalizar pedido) reaproveita um pedido "rascunho" (status 1,

criado por pedido.php ha menos de 60min) fazendo UPDATE pedidos SET metadados=...

com um $meta MONTADO DE NOVO nesse momento -- sem reler o rnt_atrib que o rascunho

original ja carregava (gravado mais perto do clique/cookie, portanto mais confiavel).

O UPDATE sobrescrevia metadados e descartava essa chave, quebrando o elo que

rnt_atrib_vincular_interno()/a reconciliacao horaria precisam pra ligar o pedido

final a visita/clique original.

Fix: action.php, le metadados do rascunho (rnt_order_meta_array(),

config/functions_new.php) e copia SO o campo rnt_atrib pro $meta novo antes de

serializar -- sem reutilizar nenhum outro campo antigo do carrinho (comentario do

proprio fix documenta essa decisao, pra nao reabrir o problema que o BK-464

(20/09/2026) resolveu: misturar campanhas de momentos diferentes num hibrido).

Validado com execucao real: rnt_order_meta_array() chamada com metadados

serializada simulada (com e sem rnt_atrib) extrai a chave certa quando existe, e

nao quebra (so fica vazio) quando nao existe (rascunho antigo, anterior a essa chave

ter passado a ser gravada).

O que isso NAO resolve (fora do escopo autorizado, nao implementado)

• Visitante anonimo que nunca loga antes de comprar: o unico jeito de ligar visita a

pedido nesse caso e por cookie (navegador_id/visita_id) casado no momento da compra --

isso ja e o que rnt_atrib_reconciliar()/rnt_atrib_vincular_interno() tentam fazer

via rnt_atrib_carimbar()/chave gravada no carrinho. Os 2 fixes acima destravam o

caminho de quem loga ANTES de clicar/comprar (cliente_id) e o de quem reaproveita

rascunho (chave preservada); nao criam um mecanismo novo de casamento por cookie puro

nem alteram a janela de tempo da reconciliacao ($horas=48/$dias_pedido=45).

• Dado historico (ja gravado como sem atribuicao): nenhum backfill foi feito nem

autorizado. As ~5.800 pessoas da campanha do BK-556, por exemplo, continuam sem

atribuicao retroativa -- os 2 fixes valem pra cliques/compras NOVAS a partir de agora.

• **Prova de que a reconciliacao horaria vai passar a encontrar vinculos de verdade em

produção:** o cron (/etc/cron.d/rnt-atribuicao, de hora em hora) roda sem erro desde

sempre, so nunca achou nada pra ligar (vinculos=0 em toda execucao do log recente).

Os 2 fixes atacam duas causas reais e confirmadas da ausencia de dado pra casar: falta

validar, ao longo dos proximos dias, se o numero de vinculos sai de zero.

Arquivos, backups e protocolo

• includes/atribuicao_helper.php, action.php: editados, com backup

.bkp_original_20261015-220620_BK-557 ao lado de cada um. php83 -l limpo nos dois

(revalidado por mim, nao so pelo Codex).

• Monitor de integridade do Mercado Pago: pausado (--pausar=20 --somente=action.php)

antes da edicao, por decisao do proprio Codex; re-selado por mim depois de revisar

e validar o diff (a rodada do Codex foi interrompida antes de fazer isso sozinha).

• Nenhuma chamada a API externa, nenhum dado real de cliente alterado -- so os 2

arquivos de codigo acima.