BK-196 - Saneamento dos warnings de tracking e Meta no console

Contexto

• Pagina observada:
• https://rionoteatro.com.br/os-homens-querem-casar
• O problema visual do fallback em peca.php ja foi tratado separadamente.
• Este BK fica restrito aos erros/warnings de tracking e Meta observados no console.
• A motivacao deste BK e reduzir o retrabalho futuro: o backlog vivo precisa guardar nao apenas o titulo do problema, mas tambem os sinais de console, a leitura tecnica atual e o que ja foi confirmado em codigo.

Sintomas reportados

Logs normais

• GTM Event: view_item - Peça visualizada: Os Homens Querem Casar e as Mulheres Querem Sexo
• Tracking salvo: view_item

Observacao:

• esses dois sao logs operacionais, nao erros.

Warnings/problemas reais

1. Pixels sem permissao de trafego no site

• [Meta pixel] 153827641653058 is unavailable on this website due to it's traffic permission settings
• [Meta pixel] 154941349953295 is unavailable on this website due to it's traffic permission settings

Leitura atual:

• problema real de configuracao
• nao quebra a pagina, mas indica pixel carregado sem permissao valida para este site/dominio
• parte da solucao pode estar fora do PHP local, em Meta Business / Events Manager

2. Evento nao padrao enviado como se fosse padrao

• [Meta Pixel] - You are sending a non-standard event 'rnt_track_event'. The preferred way to send these events is using trackCustom.

Leitura atual:

• problema real
• deve ser corrigido no codigo/local de tracking

3. Pixel duplicado

• [Meta Pixel] - Duplicate Pixel ID: 897210417852424.

Leitura atual:

• problema real
• pode estar vindo de:
• dupla carga local do mesmo pixel
• GTM com tag duplicada
• GTM + codigo local inicializando o mesmo pixel

Evidencias ja coletadas

Evidencias em codigo local

• meta-analytics.php contem inicializacoes locais de multiplos pixels:
• 250773671171307
• 153827641653058
• 897210417852424
• 413227730732075
• meta-analytics.php contem o helper window.rntFbTrackSingle
• meta-analytics.php contem o evento rnt_track_event no payload de GTM/dataLayer
• confirm_pagamento.php tambem referencia o pixel principal 897210417852424

Evidencias ja confirmadas nesta rodada

• O warning de evento nao padrao tem correspondencia direta no tracking local:
• existe rnt_track_event em meta-analytics.php
• O helper local do pixel foi corrigido para tratar evento nao padrao com trackSingleCustom quando fbq.callMethod estiver disponivel.
• O pixel 153827641653058 esta confirmado no codigo local:
• aparece em meta-analytics.php
• O pixel principal 897210417852424 esta confirmado no codigo local:
• aparece em meta-analytics.php
• aparece em confirm_pagamento.php
• O pixel 154941349953295 nao apareceu na busca rapida do codigo local desta rodada:
• isso aumenta a suspeita de origem externa via GTM, script de terceiro ou configuracao fora do PHP versionado
• O container GTM-KTLMMVG foi inspecionado diretamente nesta rodada e confirmou injeção em runtime de:
• 153827641653058
• 154941349953295
• 897210417852424
• 250773671171307

Leitura tecnica atual

O que ja esta bem encaminhado

• O warning sobre rnt_track_event e resolvivel no codigo local.
• A trilha local ja foi endurecida para usar trackCustom quando o evento nao pertencer ao conjunto padrao do Meta Pixel.

O que ja parece confirmado

• 153827641653058 esta presente em codigo local e tambem no GTM.
• 154941349953295 esta vindo do GTM.
• 897210417852424 esta presente em codigo local e tambem no GTM.
• o Duplicate Pixel ID: 897210417852424 e coerente com sobreposicao entre GTM e codigo local.
• o warning de rnt_track_event tinha causa local confirmada no helper do pixel.

Atualização de 2026-04-11 09:55 -03

• o alerta novo do Meta para 154941349953295 foi rechecado contra o código vivo atual
• busca local por ID em .php, .js e *.md confirmou:
• o pixel 154941349953295 não aparece em código executado atual
• ele aparece apenas em documentação/backlog como evidência histórica da injeção em runtime via GTM-KTLMMVG
• o arquivo vivo meta-analytics.php continua contendo hoje:
• 250773671171307
• 153827641653058
• 897210417852424
• conclusão refinada:
• o alerta de 154941349953295 deve ser tratado como pendência de GTM / Meta Events Manager
• não como bug novo do PHP local do site

Implicação prática

• se a intenção for manter esse pixel:
• revisar/reativar no Meta Events Manager
• confirmar se ele ainda deve existir no container GTM
• se a intenção não for manter esse pixel:
• remover do GTM
• essa é a trilha mais limpa para parar o alerta

Retomada explícita para amanhã

Quando voltar descansado, seguir esta ordem:

1. abrir o Meta Events Manager e localizar o pixel 154941349953295
2. confirmar:

• nome do pixel
• business dono
• se o domínio rionoteatro.com.br está associado
• se existe integração ativa ligada a ele

1. abrir o GTM GTM-KTLMMVG
2. verificar se ainda existe tag HTML/pixel disparando 154941349953295
3. decidir só entre duas opções:

• remover do GTM se ele não tiver mais função real
• reativar/regularizar no Meta se ele ainda for pixel válido do negócio

Regra prática

• não recolocar esse pixel no PHP local só porque a Meta sugeriu reativação
• primeiro arbitrar se ele ainda faz parte da arquitetura correta do RNT

Sinal mais provável hoje

• 154941349953295 parece asset legado pendurado no ecossistema Meta/GTM
• não parece pixel que o código vivo atual do site precise carregar

O que ainda e hipotese

• qual deve ser a fonte canonica do pixel 897210417852424
• somente GTM
• ou somente codigo local
• se os pixels 153827641653058, 154941349953295 e 250773671171307 ainda sao necessarios para o site atual
• se os pixels sem permissao devem ser removidos do GTM, do codigo local ou dos dois

Decisao arquitetural recomendada

Recomendacao canonica

• O pixel principal 897210417852424 deve ter como fonte canonica o codigo versionado do projeto, e nao o GTM.

Justificativa

• o codigo local:
• esta versionado
• e auditavel
• e rastreavel por diff, backlog e changelog
• ja contem helper proprio (rntFbTrackSingle) alinhado ao fluxo do site
• o GTM atual:
• injeta varios pixels ao mesmo tempo
• carrega pixels sem permissao valida para o site
• hoje e a principal fonte de opacidade e redescoberta recorrente
• como o problema desta semana foi justamente perda de memoria operacional, deixar o pixel principal no GTM piora a governanca.

Consequencia pratica da recomendacao

• 897210417852424 permanece no codigo local como pixel principal do site
• o GTM deve deixar de inicializar 897210417852424
• os pixels 153827641653058, 154941349953295, 250773671171307 e 236958654275239 devem ser tratados como legados/terceiros e removidos do GTM se nao houver justificativa operacional atual

Plano de migracao seguro

Fase 1. Saneamento local

• manter no codigo local apenas o pixel principal 897210417852424
• manter o helper rntFbTrackSingle / trackSingleCustom
• remover ou manter comentados apenas como historico os blocos legados nao canônicos do PHP

Fase 2. Saneamento do GTM

• remover do container GTM-KTLMMVG as tags HTML que inicializam:
• 897210417852424
• 153827641653058
• 154941349953295
• 250773671171307
• 236958654275239
• manter no GTM apenas o que realmente pertence a GA4, Google Ads e consumo de dataLayer

Fase 3. Revalidacao

• reabrir a pagina observada
• confirmar que:
• sumiu o Duplicate Pixel ID: 897210417852424
• sumiram os warnings de traffic permission dos pixels legados
• rnt_track_event nao gera mais warning de evento nao padrao
• permanecem apenas logs esperados de operacao

Escopo

• meta-analytics.php
• peca.php
• pedido.php
• confirm_pagamento.php
• configuracoes de GTM/Meta relacionadas ao site
• evidencias de console da pagina observada

Pendencias

• confirmar em runtime se o warning de rnt_track_event desapareceu apos o ajuste local
• aplicar no GTM a decisao canonica do pixel 897210417852424
• revisar se 153827641653058, 154941349953295, 250773671171307 e 236958654275239 devem continuar no GTM
• decidir se os pixels sem permissao de trafego:
• devem ser removidos do codigo local
• ou apenas documentados como dependencia de ajuste no Meta Business

Proximo passo

• revisar o runtime da pagina apos os ajustes locais de tracking
• separar os warnings remanescentes em:
• resolvidos no codigo local
• pendentes de GTM
• pendentes de Meta Business / Events Manager
• retirar do GTM a inicializacao do pixel 897210417852424
• se 153827641653058, 154941349953295, 250773671171307 e 236958654275239 nao forem necessarios ao site atual, remover do GTM
• se continuarem necessarios, regularizar permissao no Meta Business / Events Manager

Objetivo

• separar logs normais de erros reais
• remover warnings de evento customizado mal enviado
• localizar a origem do pixel duplicado
• identificar quais pixels antigos/externos ainda estao sendo carregados sem permissao de trafego
• documentar o que e corrigivel em codigo e o que depende de Meta/GTM

Escopo inicial

Critério de aceite

• rnt_track_event deixa de gerar warning de evento nao padrao
• origem do Duplicate Pixel ID: 897210417852424 fica identificada com evidencia
• estrategia canonica do pixel 897210417852424 fica definida e aplicada
• pixels sem permissao de trafego ficam mapeados como:
• removidos do codigo local
• ou pendentes de ajuste em Meta/GTM
• console da pagina fica com apenas logs esperados ou warnings conscientemente remanescentes e documentados

O que documentar para nao redescobrir isso no futuro

• qual e o pixel principal canonico do site
• onde ele deve viver:
• codigo local
• ou GTM
• quais pixels estao explicitamente proibidos/legados
• quais containers GTM podem ou nao inicializar pixel Meta
• qual arquivo local centraliza o tracking:
• meta-analytics.php
• como validar rapidamente em nova sessao:
• inspecionar meta-analytics.php
• inspecionar GTM-KTLMMVG
• comparar pixels do HTML publicado com os pixels do container

Leitura cruzada via worker externo

• Worker usado: gemini
• Resultado util desta rodada:
• reforcou a necessidade de um backlog vivo mais operacional, com secoes de contexto, sintomas, evidencias, leitura tecnica atual, escopo, pendencias, proximo passo e criterio de aceite
• confirmou a direcao de transformar este BK em documento de retomada real, e nao so lista curta de warnings

Conclusão (06/04/2026)

• [x] Saneamento de pixels Meta e GTM concluído e validado em runtime.
• [x] Pasta de trabalho temporária removida.
• [x] BK ENCERRADO ✅