RKR API Conversions Pro: conversões do lado do servidor para Meta, GA4, Google Ads e muito mais.

22/10/2026
v1.3.17

• AddPaymentInfo em onepagecheckoutps: a opção de pagamento é marcada com jQuery (.prop('checked', true).trigger('change') ao clicar no cartão), que dispara um evento não nativo mudar, E uma opção já vem pré-selecionada, então nenhum AddPaymentInfo foi enviado para essas lojas. Agora também é enviado:
• ao clicar em um cartão de pagamento (.opção-de-pagamento, , .módulo_container_de_pagamento, rótulos de .opções-de-pagamento), com a opção marcada em seguida;
• no jQuery mudar de entrada[name="payment-option"];
• com a opção selecionada ao fazer o pedido (Botão de confirmação de pagamento, , Botão de confirmação de pagamento .js, , #btn-placer_order), para os clientes que mantêm a opção pré-selecionada. Uma vez por módulo de pagamento e página, como antes. Testado em uma cópia de uma loja com checkout em uma única página. 5.2.0 no PS 9.1.4 (Cliente conectado com endereço): nada antes; Adicionar informações de envio com a transportadora pré-selecionada e adicionar informações de pagamento agora.

22/10/2026
v1.3.16

• onepagecheckoutps impede a propagação do mudar de sua portadora (e pagamento) rádios antes de chegar ao documento, então os ouvintes de 1.3.14, Na fase de borbulhamento, nunca ouvi nada e nenhum AddShippingInfo saiu dessas lojas. Os sistemas de escuta da transportadora e do pagamento agora usam a fase de captura (verificado em uma cópia de uma loja com onepagecheckoutps). 5.2.0 no PS 9.1.4O documento viu o mudar apenas na captura; com ela, AddShippingInfo sai).

22/10/2026
v1.3.14

• onepagecheckoutps (PresTeamShop) e thecheckout (Zelarg) sobrescrevem o OrderController, portanto, o checkout deles é o ordem página: era a página de finalização de compra, mas não uma finalização de compra em uma única página, e o JS aguardava o botão "continuar" da etapa de entrega, que essas finalizações de compra não possuem. Nem AddShippingInfo nem AddPaymentInfo saíram dessas lojas. Agora o ordem A página é um checkout de página única quando override/controllers/front/OrderController.php pertence a um deles (e o módulo está ativado), ou quando ordem Está listado em "Outras páginas de finalização de compra".
• Segurança para um módulo de uma página instalado, mas não em uso: quando a página tem o confirmarOpçãoDeEntrega Ao clicar no botão da etapa de finalização da compra, o sistema não envia o AddShippingInfo e, ao escolher uma forma de pagamento, ele não é enviado novamente quando já foi enviado para o carrinho.

22/10/2026
v1.3.13

• Checkouts de outros módulos em uma única página: a página deles nunca foi a Confira tipo de página (somente) php_self (pedido/finalização de compra contabilizados), portanto, nenhum InitiateCheckout, AddShippingInfo ou AddPaymentInfo saiu de uma loja com steasycheckout. Agora, os controladores frontais do steasycheckout, supercheckout (Knowband), onepagecheckoutps (PresTeamShop) e thecheckout (Zelarg), e o ordem-opc página, são as de finalização da compra.
• Nova configuração "Outras páginas de finalização de compra" (Avançado): módulo:controlador ou php_self entradas, separadas por vírgulas, para qualquer outro módulo de finalização de compra.
• Nessas páginas (página.umaPáginaO parâmetro AddShippingInfo é enviado quando a transportadora é alterada e, com a transportadora pré-selecionada, quando o cliente escolhe um método de pagamento sem alterá-lo; o parâmetro AddPaymentInfo funciona da mesma forma que antes.

21/10/2026
v1.3.12

• Diagnóstico de consentimento: os nomes dos cookies presentes antes do consentimento foram lidos apenas uma vez, quando a página foi carregada, portanto, os que outros scripts gravam alguns segundos depois (aplazame.js e seus) AMP_...) nunca apareceram. Eles são lidos novamente aos 8 segundos e quando a página é ocultada ou deixada (ocultar página, , mudança de visibilidade), enquanto ainda não há consentimento, e apenas os novos nomes são enviados (campo de sinalização). cookies_de_consentimento_pré).

21/10/2026
v1.3.11

Diagnóstico de consentimento para o relé (seção 13.1 do contrato)

• POST /1.0/diagnóstico Uma vez por dia (manutenção programada pelo cron), quando a chave de depuração muda e a partir do novo botão "Enviar diagnósticos" (seção de retransmissão da configuração). Somente figuras, nomes de cookies e estados:
• por dia (os últimos 7 dias completos e hoje): novos beacons e quantos concederam, negaram, concederam parcialmente ou tiveram consentimento desconhecido; eventos e compras por estado (enviado, ignorado por consentimento, outro, falhou, debug_sent, anônimo);
• a plataforma de consentimento encontrada pela página (cookiesplus, Cookiebot, OneTrust, Complianz, lgcookieslaw, GTM, o módulo...), se um Modo de Consentimento padrão e atualizações foram visualizados e quem escreveu o padrão;
• os NOMES dos cookies presentes antes do consentimento, normalizados para um padrão (AMP_7c485abf30 -> AMP_#), nunca seus valores, sem os valores técnicos da loja e das plataformas de consentimento (nova tabela) rkra_acp_diag, mantido por 30 dias);
• O estado do modo de depuração e da compra anônima do GA4.
• A resposta do relé (e do handshake) pode revogar as chaves de depuração (debug_revoked).

Modo de depuração apenas com uma chave do relé (seção 13.2 do contrato)

• A mudança de 1.3.10 desapareceu (a atualização o exclui). O modo de depuração só está ativado enquanto uma chave emitida pelo painel do relé for válida: rkd1.., no máximo 24 horas. Uma chave incorreta, expirada, muito longa ou estrangeira é rejeitada com a devida justificativa; um novo token de retransmissão ou uma revogação no painel encerra o processo.
• Mesmo alcance de antes: apenas pedidos de teste e IPs de depuração; entregas marcadas. debug_sent; um aviso vermelho em todas as telas do módulo enquanto durar.
• Novos testes testes/diagnóstico-relay.php (contra o revezamento) 1.3.0) e testes/exceções-de-consentimento.php (com uma chave).

21/10/2026
v1.3.10

Duas exceções ao consentimento (ambas desativadas por padrão)

• Modo de depuração "enviar sem consentimento (somente pedidos de teste e IPs listados)": os pedidos de teste (e-mail de um cliente de teste) e as visitas e pedidos dos IPs listados pelo comerciante (exatos ou intervalos IPv4 de /24) são enviados como se o consentimento tivesse sido concedido. Ninguém mais. Um aviso vermelho é exibido em todas as telas do módulo enquanto ele estiver ativado, e cada entrega é marcada como "depuração, sem consentimento" no registro de eventos (nova coluna). modo_de_entrega do registro do canal).
• "GA4: compra anônima sem consentimento": a compra de um visitante que não deu seu consentimento chega ao GA4 através do Protocolo de Medição, sem qualquer informação que identifique a pessoa (sem dados do usuário, sem user_id, sem IP ou navegador, um client_id aleatório usado uma única vez e nunca armazenado, consentimento NEGADO); apenas o valor, a moeda, o transaction_id e os itens. Nunca chega ao Meta ou a qualquer outra plataforma. O evento é anonimizado na loja, antes de qualquer construtor (a loja ou o relay), e sua solicitação não é armazenada. Marcado como "anônimo".
• Enviar tudo, independentemente do consentimento, não é uma opção e não será.
• Novo teste testes/exceções-de-consentimento.php (contra o falso relé).

21/10/2026
v1.3.9

Registro de eventos

• A coluna "Campanha" dos eventos de um pedido (Compra, Reembolso) mostra a campanha à qual o pedido está atribuído: o último contato registrado com o pedido em andamento. rkra_acp_order, não o UTM da linha do evento, que fica vazio quando a compra é confirmada posteriormente ou por uma notificação de pagamento. Campanhas do Google Ads sem campanha_utm Exibir o nome deles a partir da configuração "Nomes de campanhas do Google Ads" ou o seu gad_campaignid (O ID está na dica de ferramenta).
• Nova opção "Exportar XML" ao lado de "Exportar CSV", para a mesma lista filtrada (até 5.000 linhas). Ambas as exportações incluem a origem, o meio, a campanha, o ID da campanha e o canal atribuídos, além do primeiro e do último contato (o XML também inclui a página de destino e a data de cada contato).
• Novo teste testes/ferramentas/exportação de eventos.js (tela e ambos os downloads): verde ligado 1.7.6.5 e 9.2.0.

21/10/2026
v1.3.8

Campanhas do Google Ads sem utm_campaign

• Anúncios do Google Ads gad_campaignid (e gad_source) para o URL de destino, mas a maioria das campanhas não carrega campanha_utmA coluna "Campanha" mostrava "-". O ID agora é mantido como o ID da campanha do toque (utm_id, enviado para GA4 como id_da_campanha em detalhes_da_campanha), e gad_source também é mantido.
• Quando não há campanha_utm, a campanha é nomeada com a nova configuração "Nomes de campanhas do Google Ads" (um por linha, 21888563683 = Meias para compras; ; =, , ;, , :, , , ou uma guia), ou mostra o próprio ID. Aplica-se ao painel de pedidos, ao registro de eventos, às estatísticas e ao GA4/Meta. PARA campanha_utm Sempre vence.
• Os toques armazenados por versões mais antigas permanecem gad_campaignid dentro da URL de destino: o ID é lido de lá, então os pedidos anteriores também o exibem.

Página inicial

• Com url_passthrough (Modo de Consentimento) os IDs de clique são direcionados para os links internos, e o primeiro beacon pode chegar à segunda página. Quando a página de referência é uma página da loja com os mesmos IDs de clique, essa página é considerada a página de destino (mais próxima da entrada real) e nenhum referenciador interno é armazenado.
• Novo teste testes/atribuição-gad.php.

21/10/2026
v1.3.7

Painel da página de pedidos

• Na página de pedidos antigos de 1.7.6 (Bootstrap 3 painel) a tabela "Campanha do pedido" cresceu com a página de destino e URLs de referência (gclid, _gl, gbraid…) e cobriu os blocos seguintes (nacex: a equipe não pôde alterar o estado do pedido). O painel agora nunca aumenta a largura da página: marcação válida para painel e cartão, as tabelas rolam dentro de sua própria caixa com layout-da-tabela: fixo, e os URLs mostram apenas o host e o caminho (reduzido para 60 caracteres, URL completo no título).
• Sua própria pequena folha de estilo views/css/order-panel.css, carregado apenas na página de pedidos, em vez de em toda a página. admin.css.
• Novo teste testes/ferramentas/painel-de-pedidos.js (larguras, sobreposição com outro bloco, captura de tela): verde em 1.7.6.5 com a Nacex e em 9.2.0.

Reconciliação e consentimento de ordens anteriores

• A reconciliação começa no primeiro pedido que o módulo viu em cada loja (o mais baixo). id_order (de sua própria tabela): pedidos feitos antes do módulo estar ativo nunca são enviados, independentemente de quem o execute.
• Um pedido nunca assume o contexto (consentimento, campanha) de uma visita do cliente que começou após o pedido: encontrarPorCliente() Possui um limite de data, medido com o mesmo relógio das visitas.

21/10/2026
v1.3.6

Pedidos de notificação de pagamento recebidos para pedidos de back office (urgentes)

• A origem de um pedido foi decidida com definido('_PS_ADMIN_DIR_'). Os módulos tarefas cron e atualização automática defina essa constante no início do arquivo principal, de forma que, com eles instalados, cada pedido criado por uma notificação de pagamento (Redsys, Bizum...) fosse armazenado como boA compra foi filtrada como um pedido interno, nunca foi enviada e a campanha foi perdida.
• Novo RkraRuntime::isBackOffice(): um controlador de administrador (ou tipo_controlador "admin"), ou um funcionário no contexto sem um controlador frontal (as páginas Symfony do back office). A constante não é mais usada para decidir nada sobre o visitante ou o pedido (éVisitanteFrontal() também o deixa cair).
• A atualização corrige as linhas armazenadas: um pedido armazenado como bo sem a nota "Ordem manual -- Funcionário: ..." (qualquer idioma) ps_mensagem torna-se outro, obtém a campanha do beacon do seu carrinho e o horário do seu primeiro pagamento. Quando a reconciliação está habilitada, a próxima execução do cron a executa imediatamente, e as compras que ainda estão dentro do período de cada plataforma (GA4 72 h, Meta 7 dias) são enfileiradas com sua respectiva campanha. Para fazer isso imediatamente: cron?tarefa=reconciliar.
• Novo teste testes/origem-bo.php (Tarefas agendadas carregadas em uma notificação, funcionário no back office, reparo, pedido manual intocado, conciliação).

20/10/2026
v1.3.5

Modo de consentimento com uma plataforma de consentimento que grava primeiro o seu valor padrão.

• Alguns módulos de cookies (cookiesplus com o Google Tag Manager) escrevem gtag('consentimento', 'padrão', …) logo depois , já com a opção de um visitante recorrente, e enviar um atualizar somente quando o banner é usado. O módulo então escreveu seu próprio valor padrão (todos). negadoE, no início das operações, um atualizar com seu próprio estado: um visitante que havia aceitado acabou sendo rejeitado no GTM, e o módulo não enviou nada para o Meta em nome dele.
• Agora cabeça.tpl olha para o camada de dados primeiro: se houver outro valor padrão sem região, o módulo não grava nem seu valor padrão nem a atualização de seu próprio cookie e usa esses valores como estado inicial (window.rkraAcpCmpDefault).
• consent.readFromDataLayer() lê esse valor padrão como a base quando houver um, sempre abaixo de qualquer outro. atualizar. O valor padrão do próprio módulo nunca é lido. Sem uma plataforma de consentimento, nada muda.
• Novo teste testes/ferramentas/consentimento-cmp.js (novo visitante, aceita, recarrega; visitante recorrente sem o cookie do módulo, rejeita; estado visto pelo GTM): tudo verde em 1.7.6.5 com cookiesplus 1.7.1 e em 9.1.5 sem um CMP.

20/10/2026
v1.3.4

GA4 com o Google Tag Manager

• Nova configuração "Quem envia a navegação para o GA4" (etapa GA4 do assistente e seção GA4 da configuração). Com "Outra ferramenta (GTM)", o módulo não envia nada para o GA4 através do gtag.js (nem carrega a tag, mesmo no modo "módulo") e envia apenas comprar e reembolso através do Protocolo de Medição, com o id_do_cliente e id_da_sessão do _ga Os cookies permitem que os usuários participem da sessão do GTM. As outras plataformas mantêm seus registros de navegação. No GTM, apenas as tags de compra e reembolso são pausadas.
• Nova configuração "transaction_id das compras no GA4": a referência do pedido (padrão) ou seu ID, usado por muitos módulos e tags do GA4, para que relatórios antigos e novos sejam integrados. É definido na loja e acompanha o evento (ga4_transaction_id), então o relay que constrói a requisição usa o mesmo (o relay precisa do RkraGa4Sender desta versão em sua biblioteca/).

20/10/2026
v1.3.3

Inclui tudo em 1.3.2, que não foi publicado isoladamente.

PrestaShop 1.7.6 e 1.7.7

• Versão mínima reduzida para 1.7.6.0. Testado em 1.7.6.5 (cópia de uma loja real), 1.7.8.11, , 9.0.0, , 9.1.5 e 9.2.0: instalação, as seis telas do back office, um pedido pago por transferência bancária, a fila para o relay, o cancelamento (reembolso para GA4) e o cron.
• Antes 1.7.8 o núcleo não lê o traduções//*.xlf de um módulo, e o módulo foi lançado em inglês. Os catálogos do módulo agora são adicionados, na memória, ao tradutor da solicitação (também usado por $this->trans() e por {l s='' d=''} nos modelos). Nada é gravado no banco de dados ou no cache, e 1.7.8 não é tocado.

Renovação de assinaturas

• Os pedidos de renovação de uma assinatura do RKR Product Subscription (já existe um pedido anterior da mesma assinatura) são enviados por padrão apenas para o GA4: a receita é contabilizada lá e as plataformas de publicidade não registram uma conversão por mês. As outras plataformas armazenam esses dados como... pulado com a razão renovação_de_assinatura. Nova configuração "Renovação de assinaturas" (Eventos): somente para GA4, para nenhuma plataforma ou para todas elas.
• Uma solicitação sem cookies que mencione um carrinho ou um cliente (o cron ou um webhook de pagamento de outro módulo) não será mais processada para o visitante: o pedido será registrado com a origem. outro e o endereço IP e o navegador do servidor nunca são associados ao cliente. Controladores frontais nomeados cronologia, , webhook(s), , notificação, , IPN ou ligar de volta São chamadas de máquina.

18/10/2026
v1.3.2

As recusas esperadas são "ignoradas", não "reprovadas".

• Os eventos que uma plataforma não tem nada a receber agora são armazenados como pulado com sua justificativa, não são contabilizados como erros e não são registrados no log de erros do PrestaShop: sem consentimento do visitante (consentimento:...), nenhum identificador que a plataforma possa corresponder, geralmente um bot ou um visitante sem cookies (sem identificadores), um pedido gratuito (valor zero) e um evento mais antigo do que a plataforma aceita (fora_da_janelaAté 1.3.1 Eles eram fracassado + evento inválido, e preencheu o tronco (71 Ver conteúdo em uma noite).
• A verificação de consentimento ocorre antes da verificação dos identificadores: um pedido sem consentimento era ignorado no GA4, mas falhava no Meta com a indicação "sem identificadores", porque sem consentimento os dados do cliente são removidos.
• Problemas reais (moeda inválida, valor negativo, nome GA4 malformado, data futura, URL de página ausente) ainda existem. fracassado Com a razão deles.

Reconciliação

• Um pedido ausente em um canal é enfileirado apenas nos canais que o não receberam, mas ainda o aceitam. Um pedido dentro do prazo de 7 dias do Meta, mas após as 72 horas do GA4, foi enfileirado em ambos os canais e falhou no GA4 devido à sua antiguidade.
• Uma entrega já foi ignorada. fora_da_janela É contabilizado como tendo saído pela janela no relatório, não como tendo sido entregue.

Alterações de status sem uma moeda no contexto

• rastrearPedido, , rastrear reembolsos e cancelamento de rastreamento Carregar a moeda do pedido (e o idioma e a loja, se estiverem faltando) em Contexto enquanto processam o evento e restauram o que estava lá em seguida. Uma alteração de status no console, um ERP ou um cron falhou com ComputingPrecision::getPrecision(): O argumento #1 deve ser do tipo int, null fornecido e a compra foi perdida até a conciliação.

Pedidos feitos antes do módulo

• Eles não têm consentimento armazenado e são tratados com as configurações padrão do Modo de Consentimento (negados por padrão, portanto, são ignorados). consentimento: dados_do_usuário_de_anúncios_negadosIsso é intencional e agora está explicado no Guia (Modo de Consentimento v2 e privacidade → Pedidos feitos antes do módulo).

08/10/2026
v1.3.1

Atribuição de campanha (utm)

• Política de atribuição: último contato indireto, como o GA4 faz para suas sessões. Uma visita com utm_* ou um ID de clique de anúncio substitui a campanha; um retorno direto (não utm_*, (sem ID de clique) mantém o registro durante toda a vida útil do cookie do visitante (90 dias por padrão). O primeiro contato também é mantido e nunca substituído.
• As campanhas internas não substituem as externas: novas configurações "Valores utm_source internos" (separados por vírgula) e "Ignorar utm em links internos" (utm em uma página acessada a partir da própria loja, ativado por padrão).
• Cada interação armazena os dados utm_source/medium/campaign/term/content/id e, quando presentes, utm_source_platform, utm_creative_format e utm_marketing_tactic, seus IDs de clique, página de destino, referenciador e horário. Um ID de clique sem UTM implica em Google/CPC (gclid, gbraid, wbraid) ou Bing/CPC (msclkid).
• A campanha é congelada com o pedido no momento em que ele é feito: uma visita posterior com outra campanha não a altera, e um pedido digitado no painel administrativo não possui campanha web. Compras confirmadas posteriormente (pagamento recebido, painel administrativo, agendamento) mantêm a campanha da visita que gerou o pedido.
• Back office: "Campanha do pedido" no painel de pedidos (primeiro e último contato, IDs de cliques, página de destino, referenciador), uma coluna "Campanha" no registro de eventos e em sua exportação CSV, e "Vendas por campanha (utm)" nas estatísticas.
• Protocolo de medição GA4: detalhes_da_campanha evento (campaign_id, campaign, source, medium, term, content) enviado com a compra somente quando não for possível ingressar na sessão do navegador (não _ga_ cookie: consentimento negado, bloqueador). Com um session_id, o GA4 já atribui a compra à campanha dessa sessão. Nova configuração "Enviar a campanha para o GA4 e Meta" (ativada).
• API Meta Conversions: utm_source / medium / campaign / term / content / id como propriedades personalizadas de dados_personalizados.

Canal de IA

• As visitas de assistentes de IA formam seu próprio canal "IA" com a plataforma concreta (ChatGPT, Perplexity, Gemini, Copilot, Claude, Meta AI, DeepSeek, Mistral, Grok, You.com, Phind, Poe), detectado pelo referenciador ou por utm_source. A lista é a constante RkraAttribution::AI_PLATFORMS.
• Uma visita com um ID de clique de um anúncio (ChatGPT Ads) oppref / obref, gclid, msclkid...) é IA paga, nunca orgânica; anúncios do ChatGPT sem utm são exibidos como chatgpt / cpc.
• Mantido com o pedido, assim como a campanha; exibido no painel de pedidos (coluna Canal), o registro de eventos e seu CSV (plataforma_ai), e "Vendas de assistentes de IA" nas estatísticas (pedidos e receita por plataforma).
• Lista de verificação do GA4: passo a passo para criar um grupo de canais personalizado com um canal "AI" ("A origem corresponde à expressão regular", expressão pronta para copiar, acima de "Referência"). Com o Google conectado por meio do relay (1.2.1 ou posterior) a etapa tem um botão "Corrigir" que cria ou atualiza o grupo "Canais com IA (RKR)", e a auditoria o marca automaticamente; quando a propriedade já possui seus 2 grupos personalizados, explica o que fazer.
• Remetentes: um evento sem algumas chaves (quantidade, contagem de itens... de outro módulo, uma linha antiga da fila ou o relay) não imprime mais avisos do PHP.

Fixo

• A página de destino e a página de referência do visitante eram substituídas por todas as páginas que ele visitava; agora, elas mantêm o registro da primeira visita (cada campanha mantém o seu próprio).
• Banners internos com seus próprios nomes utm_* substituiu a campanha de onde o visitante veio.

Verificado (nenhuma alteração necessária)

• O módulo nunca remove, reescreve ou redireciona. utm_*, gclid ou fbclid: não history.replaceState, sem redirecionamento, sem canônico próprio.
• Com o GA4 ou o Google Ads carregados por outro módulo ou pelo GTM, não há acréscimo. gtag('config') e não visualização_de_página; com sua própria etiqueta, exatamente uma configuração.
• Ele grava apenas seus próprios cookies (rkra_vid, , consentimento_rkra); _ga, , _ga_, , _gcl_aw, , _fbp, , _fbc e os cookies de outras tags são apenas lidos.

07/10/2026
v1.3.0

Novas plataformas

• Microsoft Advertising (API de conversões UET), API de conversões do Pinterest, API de conversões do Snapchat e API de conversões do LinkedIn: cada etapa no assistente, configuração, botão "Testar" com explicação do erro da plataforma, indicador de integridade, reconciliação, nomes de eventos, consentimento e IDs de cliques (msclkid, , _epik, , ScCid / _scid, , li_fat_id).
• As tags do navegador (UET, tag do Pinterest, Snap Pixel, tag do LinkedIn Insight) podem ser carregadas pelo módulo com o mesmo ID de evento do servidor; a UET segue seu modo de consentimento, as outras são carregadas assim que o visitante aceita os cookies de publicidade.
• A Microsoft recebe o e-mail e o telefone com sua própria normalização (sem pontos nem aliases no e-mail, E.164 com "+").

Relé (contrato v1.2)

• Cada chamada para o relay é assinada com a assinatura v2 (método, caminho, carimbo de data/hora e corpo); v1 é usada apenas para relays que não conhecem v2.
• "Conecte-se com Google / Meta / TikTok / Microsoft / Pinterest / LinkedIn" em cada etapa do assistente por meio do hub OAuth do servidor: escolha a conta, propriedade, fluxo, ação de conversão, pixel ou regra, e o módulo configura tudo. A loja mantém apenas os valores que não são secretos; o servidor mantém os tokens ("custódia"). Reconecte e desconecte, e um aviso será exibido em cada tela quando o servidor solicitar a reconexão.
• A lista de verificação do GA4 é verificada com o Google quando a conexão é estabelecida: os pontos que a API de administração consegue visualizar são marcados automaticamente e um botão "Corrigir" aplica o que a API permite (retenção, compra como evento-chave, dimensões, vinculação com o Google Ads); o restante permanece como uma tarefa manual com seu respectivo procedimento.
• Planos (seção 12 do contrato): plano, período de teste gratuito, data de expiração e cota mensal de eventos exibidos no painel administrativo; os canais não incluídos em um plano são enviados diretamente da loja quando possuem suas próprias credenciais, ou são relatados como não enviados, com o motivo indicado no ícone de saúde.
• Um canal conectado através do relé nunca é enviado diretamente sem as credenciais da própria loja: ele aguarda o relé.

Coleta de dados

• Cada tag do navegador (Meta Pixel, GA4, Google Ads, TikTok Pixel) possui um modo: carregada pelo módulo, carregada por outro módulo ou pelo Google Tag Manager, ou somente pelo servidor. Nos dois primeiros modos, o navegador e o servidor enviam a mesma mensagem. id_do_evento, Assim, as plataformas eliminam as duplicatas. O GA4 nunca recebe um evento duas vezes: a navegação passa pelo gtag, as compras e os reembolsos pelo Protocolo de Medição (tudo por meio dele no modo somente servidor).
• Modo de consentimento v2 com consentimento armazenado restaurado antes do carregamento das tags, redação de dados de anúncios, , url_passthrough e adaptadores para Cookiebot, CookieYes, Complianz e OneTrust, além do gtag. atualização de consentimento.
• Funil de e-commerce GA4 completo no Classic, Hummingbird e 1.7.8 temas: lista_de_itens, , selecionar_item, , ver_promoção, , selecionar_promoção, , ver_item, , adicionar ao carrinho, , remover_do_carrinho, , ver_carrinho, , iniciar_finalização_do_checkout, , adicionar_informações_de_envio, , adicionar_informações_de_pagamento, , comprar, , procurar, , Conecte-se, , inscrever-se, , gerar_lead, , adicionar_à_lista_de_desejos.
• Itens com caminho de categoria (5 níveis), marca, variante, lista, índice, desconto e cupom; o preço de custo nunca sai da loja.
• IDs de clique (gclid, , trança, , trança, , fbclid, , ttclid, , msclkid...) e parâmetros UTM mantidos por 90 dias em um cookie primário assinado, definido pelo servidor, com o horário da primeira visualização (Meta fbc).
• Identificação: telefone em E.164 com prefixo do país, ID externo do cliente e do visitante, GA4 ID do usuário (texto simples ou hachurado), _ga ID da sessão.
• Dados comerciais: margem como valor do Google Ads (opcional), novos clientes, valor vitalício do cliente, cupom, nível de frete e método de pagamento.
• Eventos do back office: compra quando o pedido é pago (padrão para novas instalações; atualizações mantêm "quando criadas"), pedidos criados no back office (chamada_telefórica), reembolsos parciais para créditos, cancelamentos e ajustes de conversão do Google Ads (RETRACTION / REATABLE).

Configuração e saúde

• Assistente de configuração em 11 etapas com verificação de formato em tempo real, detecção de tags já impressas por outros módulos, tema, banner de consentimento, módulos de pagamento e cron, além de um botão "Testar" por plataforma que envia um evento de teste real e traduz o erro da plataforma. Há espaço para um botão "Conectar com Google/Meta/TikTok" em cada etapa (ainda não ativo).
• Listas de verificação para GA4, Meta e TikTok com links diretos para a tela correta de cada plataforma; os itens marcados são armazenados por loja.
• Semáforo de saúde por plataforma: cobertura de pedidos, qualidade da correspondência, compartilhamento de IDs de cliques, atraso e erros recentes.

Entrega

• Cada evento é validado antes de ser enviado (data, janela da plataforma, moeda, valores, identificadores obrigatórios); eventos inválidos são mantidos com a respectiva justificativa, em vez de serem rejeitados pela plataforma.
• Eventos do servidor sem página (pagamentos no painel administrativo, cron, reembolsos) incluem o URL da loja e um texto coerente. fonte_de_ação.
• Cron de backup: quando o cron principal não está em execução, as solicitações dos visitantes são processadas na fila após o envio da resposta.
• Conciliação diária de pedidos com entregas por plataforma, dentro da janela de cada plataforma, com relatório na tela de configuração e tarefa cron. conciliar.
• Nenhuma chamada de rede durante o atendimento na recepção ou no processo de finalização da compra.

Correções

• O cookie de visitante não utiliza mais o núcleo. Biscoito classe: criar uma com outra chave substituiu o mecanismo de criptografia do cookie de sessão e o visitante perdeu o carrinho.
• GA4 num_itens e os itens do servidor nos eventos do navegador estavam vazios.