Você tem dúvidas sobre os dados do Google Analytics?

1) Conecte o Tag Assistant e confirme que seu navegador aparece no DebugView. 2) Conclua a jornada de teste e anote o ID do pedido. 3) Revise o evento purchase e as tags que o enviam para cada destino. 4) Recarregue a confirmação e volte a ela pelo histórico: registre qualquer novo envio. 5) Se houver tentativas de reenvio previstas, peça evidências de deduplicação para cada destino. Para comparar o total com a loja, use o controle de conciliação: não existe uma margem universal de 5% que valide a implementação.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: O pedido tem um identificador estável e não gera compras adicionais nos destinos revisados. Qualquer reenvio previsto tem um mecanismo de deduplicação verificado.

Vale investigar se: Uma ação aciona duas tags para o mesmo destino, o ID muda ao recarregar ou ocorrem reenvios cuja deduplicação não foi verificada.

Deixe o DebugView aberto em uma aba e navegue pelo site em outra como um novo visitante: página inicial, uma categoria e um artigo do blog. Nenhum add_to_cart, begin_checkout, add_shipping_info ou purchase deve aparecer no fluxo de eventos. Depois, abra o produto A e adicione-o ao carrinho: deve aparecer um único add_to_cart ao clicar no botão. Clique nesse evento e abra o parâmetro items ou a aba de itens nos detalhes à direita: o nome ou ID deve ser o do produto A. Sem esvaziar o carrinho, visite a página inicial e outra categoria: nenhum novo add_to_cart deve aparecer. Abra um produto B diferente e adicione-o: deve aparecer um segundo add_to_cart com o produto B em items, e não o A. Por fim, abra o carrinho e clique no botão para o checkout: begin_checkout deve aparecer uma vez. Volte à página inicial e verifique se ele não se repete.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: Nenhuma página de conteúdo aciona eventos de carrinho ou checkout; cada add_to_cart aparece uma vez com o produto que acabou de ser adicionado; begin_checkout aparece apenas ao entrar no checkout e não se repete durante a navegação.

Vale investigar se: Um add_to_cart ou begin_checkout aparece ao carregar a página inicial, repete-se durante a navegação ou contém os dados do produto anterior.

1) Liste as ações existentes na loja: ver produto, adicionar ou remover itens, abrir carrinho, iniciar checkout, informar envio ou pagamento e confirmar uma compra. 2) Com a depuração ativa, realize essas ações e verifique os eventos: view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info e purchase, conforme aplicável. 3) Repita as jornadas relevantes por dispositivo e meio de pagamento. 4) Use os relatórios históricos para identificar interrupções ou diferenças e compare com o volume de atividade. Um zero isolado ou uma etapa omitida por definição da jornada não comprova uma falha.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: Os eventos previstos aparecem quando as ações são realizadas, e as etapas que não se aplicam estão documentadas.

Vale investigar se: Você realiza uma ação prevista e seu evento não chega, repete-se ou contém dados incorretos. A comparação entre dispositivos ou meios de pagamento mostra uma diferença ainda sem explicação.

1) Peça o inventário de contêineres e destinos autorizados. 2) Percorra a página inicial, produto e checkout com o Tag Assistant. 3) Compare os IDs detectados com o inventário. 4) Para cada tag adicional, verifique a finalidade, o responsável e o destino. Pode haver vários IDs válidos ou uma tag com vários destinos: a quantidade, por si só, não comprova duplicação. 5) Documente qualquer ID desconhecido antes de propor sua remoção.

Abrir na sua propriedade: Fluxos de dados

Você pode considerar verificado se: Cada contêiner e destino tem uma finalidade conhecida, e os eventos chegam às propriedades previstas sem duplicação involuntária.

Vale investigar se: Há um destino sem responsável, uma propriedade anterior continua recebendo dados por engano ou duas implementações enviam a mesma ação para o mesmo destino.

1) Liste os parâmetros necessários para cada evento conforme o plano de mensuração, como tipo de página ou status de login. 2) No Tag Assistant, selecione o evento que aciona a tag e revise os valores das variáveis naquele momento. 3) Compare com os parâmetros recebidos no DebugView. 4) Não exija dados que ainda não existem nessa etapa, como a identidade de alguém que não fez login. Um valor configurado em uma tag não comprova, por si só, seu recebimento: se a interface não permitir confirmar, peça a revisão da requisição enviada ou do registro correspondente.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: Os parâmetros necessários para a ação têm valores corretos no envio, e há evidências de seu recebimento.

Vale investigar se: Faltam dados que deveriam estar disponíveis, chegam valores de uma ação anterior ou a variável só é preenchida depois do envio do evento.

1) Defina quais páginas e visualizações virtuais seu plano de mensuração contabiliza. 2) Navegue por uma amostra com produto, carrinho e checkout, com a depuração ativa. 3) Verifique um page_view por visualização prevista, com page_location e page_title corretos. 4) Se houver duplicações, revise se uma medição automática e uma tag manual cobrem a mesma visualização. Mecanismos podem coexistir para jornadas diferentes; o que deve ser evitado é enviar a mesma visualização duas vezes.

Abrir na sua propriedade: DebugView · Fluxos de dados

Você pode considerar verificado se: Cada visualização prevista gera um page_view com a URL e o título correspondentes.

Vale investigar se: Uma visualização é duplicada, uma visualização prevista não é registrada ou o evento mantém a URL ou o título anterior.

1) Compare os nomes enviados com os recomendados para as ações implementadas, respeitando maiúsculas, minúsculas e sublinhados. 2) No DebugView, revise items e a identificação dos produtos; em purchase, revise também transaction_id, value e currency quando houver valor informado. 3) Compare produtos e métricas em Compras de e-commerce. 4) Se um evento não aparecer em uma lista recente, reproduza a ação ou amplie o período antes de concluir que ele está ausente. Um relatório vazio exige revisar configurações, filtros e dados disponíveis.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: As ações implementadas usam os nomes previstos, seus parâmetros identificam os produtos e os relatórios recebem os dados necessários.

Vale investigar se: Há nomes que não correspondem aos eventos recomendados, produtos sem identificação ou parâmetros necessários que não chegam em um teste verificável.

1) Confirme como sua equipe distingue testes de tráfego de clientes: propriedade separada, regras de tráfego interno ou outro critério documentado. 2) Verifique se o critério cobre os ambientes e as redes usados nos testes. 3) Confira o estado e o efeito dos filtros antes de ativá-los; a exclusão ativa afeta permanentemente os dados processados. 4) Revise os nomes de host e explique os que não pertencem à produção. Nem toda empresa tem um IP fixo de escritório, e um filtro em teste pode ser uma etapa deliberada de validação.

Abrir na sua propriedade: Fluxos de dados · Filtros de dados

Você pode considerar verificado se: Existe um critério documentado e validado para separar ou reconhecer os testes sem excluir tráfego de clientes por engano.

Vale investigar se: Os ambientes de teste contaminam os relatórios usados nas decisões, ou um filtro exclui tráfego válido. Ainda não há um método definido ou seu efeito não foi verificado.

1) Faça uma compra de teste combinada com a equipe e anote o ID. 2) Verifique o transaction_id enviado em purchase. Pode ser o número visível do pedido ou outro identificador estável com correspondência documentada. 3) Recarregue a confirmação e verifique se qualquer reenvio mantém o ID e é tratado corretamente em cada destino. 4) Revise uma amostra de pedidos históricos. Não descarte um ID apenas pelo formato nem use o relatório agregado como única prova de que não houve reenvios.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: Cada pedido está relacionado a um ID único, que não muda ao reenviar a mesma compra e não contém dados pessoais.

Vale investigar se: O ID está vazio, muda entre envios do mesmo pedido, é reutilizado em compras diferentes ou não pode ser relacionado a um pedido.

1) Combine uma compra de teste e verifique se ela aparece no DebugView. 2) Confira se value é numérico e currency é o código da moeda enviada, como ARS, USD ou BRL. 3) Pela definição do Google Analytics, value corresponde à soma de price × quantity dos itens, sem frete nem impostos: shipping e tax são informados separadamente. 4) Compare com os mesmos componentes do comprovante. 5) Para comparar relatórios, revise a moeda da propriedade e se a métrica desconta reembolsos ou inclui outras receitas. Não compare Receita total com faturamento sem revisar sua composição.

Abrir na sua propriedade: DebugView · Detalhes da propriedade

Você pode considerar verificado se: O valor, a moeda e os componentes do pedido são consistentes com a definição do evento, e a comparação usa a mesma base.

Vale investigar se: value chega como texto, usa centavos em vez de unidades, tem a moeda incorreta ou inclui componentes que não correspondem à sua definição.

1) Anote o preço de tabela e o desconto de um produto. 2) Ative a depuração e conclua o teste. 3) Compare price, quantity e discount com os detalhes da transação. O preço enviado deve refletir o desconto aplicado ao item. 4) Revise view_item e add_to_cart se estiverem disponíveis: uma diferença pode ser válida quando um cupom é aplicado ou a variante muda depois. 5) Se purchase não aparecer, verifique o modo de depuração e se o envio ocorre pelo servidor antes de concluir que o evento está ausente.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: price corresponde ao preço unitário vendido, e qualquer variação durante a jornada tem uma causa documentada.

Vale investigar se: O preço de tabela é enviado embora outro valor tenha sido cobrado, o desconto é subtraído duas vezes ou o preço não corresponde ao item comprado.

1) Combine testes que cubram os descontos e encargos da loja. 2) Anote value, shipping, tax e os campos price e quantity dos itens. 3) Verifique se value é a soma dos valores dos itens após os descontos, sem frete nem impostos. 4) Revise como esses componentes recompõem o comprovante, incluindo qualquer acréscimo que precise de tratamento separado. 5) Se price já reflete o desconto, não o subtraia novamente. Descontos no carrinho exigem uma distribuição coerente entre os itens; documente diferenças de arredondamento. Uma regra aplicada de forma consistente também pode estar mal definida.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: Os componentes permitem conciliar a transação, com descontos aplicados uma vez e critérios documentados para impostos, frete, encargos e arredondamentos.

Vale investigar se: Um desconto ou encargo é duplicado, value inclui componentes incorretos ou os itens não permitem explicar o valor da compra.

1) Em um teste combinado, adicione e remova um produto; depois, compre outros dois, sendo um com mais de uma unidade. 2) Verifique se items contém apenas os produtos comprados, com identificadores e quantidades corretos. 3) Compare uma amostra de unidades por produto com a loja, usando os mesmos períodos, status de pedido e critérios de reembolso. Uma ordem diferente entre os produtos mais vendidos é um sinal para investigar, não uma prova automática de erro.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: Os itens da compra de teste correspondem ao pedido, e as diferenças históricas têm uma explicação ou uma investigação documentada.

Vale investigar se: Aparece um produto removido, faltam itens, as quantidades não correspondem ao pedido ou há diferenças de unidades ainda sem explicação.

1) Confirme se sua implementação mede listas de produtos e como preserva o contexto. Se não se aplicar, deixe o item pendente e registre a explicação fora do checklist. 2) Entre por uma categoria ou recomendação e acompanhe a jornada de um produto. 3) Revise item_list_name nos eventos e em items onde o plano prevê seu envio. 4) Compare com os relatórios de listas usando métricas compatíveis. Nem toda compra parte de uma lista, e uma linha (not set) exige contexto.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: A lista é preservada nas etapas definidas, e as compras sem lista têm uma explicação coerente com a jornada.

Vale investigar se: A lista muda ou desaparece onde o plano exige sua preservação, ou o relatório não permite interpretar a origem das compras que partiram de uma lista.

1) Documente qual status do pedido purchase representa no seu negócio e quando uma venda é confirmada; considere meios de pagamento com confirmação posterior, se houver. 2) Compare uma amostra de IDs e status com os eventos enviados. Um clique em pagar não basta para comprovar uma compra. 3) Revise reembolsos totais e parciais e o transaction_id dos eventos refund, se essa mensuração estiver no escopo. 4) Para testar recusa ou cancelamento, use com sua equipe o ambiente e os meios de teste autorizados pelo intermediador de pagamento. Não use cartões de teste em produção. 5) Uma diferença nos totais exige revisar datas, status, filtros e duplicação antes de atribuir uma causa.

Você pode considerar verificado se: As compras correspondem ao status definido, e os reembolsos medidos podem ser vinculados ao pedido e ao valor correspondentes.

Vale investigar se: purchase é enviado por uma tentativa malsucedida, um reembolso previsto não é registrado ou seu ID ou valor não corresponde ao pedido.

1) Compare a conta vinculada com a utilizada pelo negócio, incluindo a vinculação por uma conta de administrador quando aplicável. 2) Revise a codificação automática e qualquer modelo ou sufixo de acompanhamento. 3) Confirme se essas opções correspondem ao plano de campanhas. 4) Compare um período com atividade real e dados de campanha disponíveis. Ver google / cpc não comprova, por si só, que a vinculação funciona, e um nome de campanha ausente pode ter várias causas. Se faltar permissão, peça a verificação a quem administra as contas.

Abrir na sua propriedade: Vinculações com o Google Ads

Você pode considerar verificado se: A vinculação e a marcação correspondem às contas previstas, e seu funcionamento é sustentado pela configuração e pelos dados.

Vale investigar se: A conta vinculada está incorreta, a marcação prevista está desativada ou faltam informações de campanhas ainda sem explicação.

1) Use a URL final de uma campanha e teste se os redirecionamentos preservam um parâmetro de teste, como gclid=TESTE123; acrescente-o com ? ou & conforme a URL. Isso verifica o transporte do parâmetro, não valida um clique publicitário real. 2) Revise com sua equipe a tag do Google e o mecanismo de vinculação de conversões adequado à instalação. 3) Compare campanhas com dados reais no Analytics. 4) Se o parâmetro desaparecer, investigue em qual etapa e se a informação foi capturada antes; não conclua apenas pela URL final. Cliques e sessões não são métricas equivalentes.

Você pode considerar verificado se: A jornada preserva ou processa corretamente os identificadores previstos, e a comparação com campanhas reais sustenta a implementação.

Vale investigar se: Um redirecionamento elimina informações antes da captura ou faltam dados de campanha sem uma explicação verificada.

1) Revise a convenção acordada para cada plataforma e tipo de campanha. 2) Compare uma amostra de links publicados com essa convenção. 3) Procure variações de maiúsculas, abreviações ou erros de escrita nos relatórios. 4) Diferencie alterações acidentais de combinações válidas, como tráfego pago e orgânico da mesma rede. Não é necessário reduzir um canal a uma única linha. 5) No Google Ads, verifique se as UTMs e o acompanhamento não contradizem a codificação automática ou as regras da implementação.

Você pode considerar verificado se: As origens, mídias e nomes permitem identificar as campanhas sem fragmentação acidental, com exceções documentadas.

Vale investigar se: A mesma campanha usa variações por engano, faltam parâmetros previstos ou os nomes impedem a comparação dos resultados.

1) Identifique os domínios de pagamento que participam das jornadas. 2) Revise quais podem gerar referências indesejadas e se o tratamento está configurado corretamente. Não exclua parceiros ou veículos que realmente trazem visitas. 3) Compare uma jornada antes e depois do retorno do intermediador e revise a origem da sessão. 4) Analise dados posteriores às mudanças, pois uma exclusão não reescreve o histórico. A exclusão de referências não substitui a mensuração entre domínios próprios.

Abrir na sua propriedade: Fluxos de dados

Você pode considerar verificado se: Os intermediadores não recebem crédito de aquisição apenas pelo retorno do pagamento, e o tratamento é sustentado por testes.

Vale investigar se: Um intermediador aparece como origem pelo retorno do checkout ou a jornada perde informações de sessão ainda sem explicação.

1) Liste os domínios que você controla e nos quais há mensuração da mesma jornada. Não adicione um intermediador de terceiros onde você não pode instalar sua tag. 2) Se a jornada cruza domínios diferentes, revise a configuração e a transmissão do parâmetro _gl quando aplicável. 3) Verifique a continuidade dos identificadores e da sessão com sua equipe; a barra de endereço ou a ausência de referências não bastam como única prova. 4) Subdomínios também precisam de uma configuração de cookies compatível. Se o caso não se aplicar, deixe-o pendente e documente o motivo fora do checklist.

Abrir na sua propriedade: Fluxos de dados

Você pode considerar verificado se: Os testes mostram continuidade da mensuração nos domínios previstos, sem autorreferências inesperadas.

Vale investigar se: A configuração omite um domínio necessário, os identificadores se perdem ou aparecem autorreferências sem explicação.

1) Anote a participação de (not set) em Origem/mídia e Página de destino, e de Unassigned no grupo de canais. 2) Revise também Direct e compare períodos equivalentes. 3) Relacione as mudanças com campanhas, consentimento, checkout e publicações de tags. Não existe um limite universal de 5% que determine se a mensuração está correta. 4) Para investigar, revise a ordem de configuração da tag, os parâmetros de sessão e o conteúdo dos eventos. Se um evento não aparecer no DebugView, verifique primeiro as condições de depuração e consentimento.

Você pode considerar verificado se: Você conhece a evolução dessas linhas, suas causas verificadas e as diferenças que ainda precisam de investigação.

Vale investigar se: Há uma variação relevante sem explicação ou um teste mostra perda de informações de origem, sessão ou página.

1) Confirme com sua equipe quais estados devem ser aplicados ao visitante e à região de teste. 2) Inicie uma sessão de teste sem preferências anteriores. 3) No Tag Assistant, verifique quando o estado inicial é definido e quando as tags o utilizam. 4) Teste aceitar, rejeitar e não interagir. 5) Revise analytics_storage, ad_storage e os demais tipos configurados. O estado deve estar disponível antes de uma tag agir com base nele; o teste não consiste apenas em contar eventos do banner.

Você pode considerar verificado se: As tags utilizam o estado previsto desde a primeira execução, e as mudanças refletem as escolhas do visitante.

Vale investigar se: Uma tag usa um estado incorreto ou age antes de o consentimento necessário estar disponível.

1) Confirme se a implementação é básica ou avançada. 2) Teste a jornada sem aceitar e depois com aceitação. No modo básico, as tags do Google podem permanecer bloqueadas até haver consentimento. No modo avançado, podem enviar sinais sem cookies sob consentimento negado. 3) Compare o comportamento com o modo acordado. 4) Revise as condições adicionais de cada tag antes de propor mudanças. Bloquear uma tag não é automaticamente um erro; habilitar o modo avançado também não garante acesso à modelagem.

Você pode considerar verificado se: As tags se comportam conforme o modo documentado e respeitam os estados de consentimento nos testes.

Vale investigar se: A configuração real contradiz o modo acordado, o bloqueio impede um envio previsto ou são enviados dados ou identificadores incompatíveis com o estado de consentimento.

1) Teste aceitar, rejeitar e alterar uma escolha anterior. 2) Verifique se o estado atualizado reflete cada escolha antes dos envios que dependem dela. Uma atualização de Granted para Denied é válida quando a pessoa retira o consentimento. 3) Procure atualizações repetidas que reiniciam identificadores ou contradizem a escolha. 4) Com uma campanha de teste identificável, compare os dados de aquisição considerando os filtros e os tempos de processamento. Um teste filtrado ou sem consentimento pode não aparecer no relatório; sua ausência não basta para diagnosticar a causa.

Você pode considerar verificado se: Cada escolha deixa o estado correto, e não são detectadas mudanças de identidade ou origem causadas por atualizações inconsistentes.

Vale investigar se: O estado não reflete a escolha, é sobrescrito sem uma ação que explique a mudança ou o teste mostra perda de informação coincidente com uma atualização incorreta.

1) Combine uma compra de teste com um ID conhecido. 2) Identifique se purchase é enviado pelo navegador, pelo servidor ou por ambos. 3) Revise os IDs e as tentativas de reenvio nos registros de cada origem. 4) Verifique o resultado no Analytics após o processamento dos dados. Uma linha agregada não revela todos os envios que podem ter sido deduplicados. 5) Se a compra não aparecer, investigue filtros, consentimento, depuração e processamento; não altere a identidade dos relatórios apenas para concluir o checklist.

Abrir na sua propriedade: DebugView

Você pode considerar verificado se: Os envios do mesmo pedido correspondem a um identificador estável, e o resultado não inclui compras duplicadas.

Vale investigar se: O mesmo pedido usa IDs diferentes, há reenvios sem tratamento verificado ou o resultado registra uma compra adicional.

1) Confirme quais eventos devem passar pelo servidor e a qual propriedade chegam. 2) Realize uma ação de teste e acompanhe suas requisições do navegador ao destino. 3) Verifique se também existe uma instalação independente que envia a mesma ação diretamente para a mesma propriedade. 4) Identifique a finalidade de cada requisição: sinais auxiliares da plataforma não são necessariamente eventos duplicados. Se não conseguir distingui-los, peça essa verificação à equipe técnica.

Você pode considerar verificado se: O percurso corresponde à arquitetura documentada, e não há uma segunda implementação enviando o mesmo evento por engano.

Vale investigar se: A mesma ação é enviada por duas instalações independentes sem um desenho que justifique isso, ou parte do tráfego usa rotas com tratamento de identidade incompatível.

1) Use um perfil de teste sem cookies anteriores e teste rejeição, aceitação e retirada do consentimento. 2) Verifique se o estado recebido pelo servidor corresponde ao do navegador. 3) Revise com sua equipe se as respostas gravam cookies do Analytics, incluindo FPID se a implementação usar, com analytics_storage negado. 4) Compare as tags executadas e os dados enviados com o modo básico ou avançado acordado. Requisições de rede sob rejeição, por si só, não comprovam descumprimento: é preciso revisar o que é enviado e como está configurado.

Você pode considerar verificado se: Os estados são transmitidos e as tags do servidor adaptam seu comportamento; elas não gravam cookies do Analytics quando o armazenamento está negado.

Vale investigar se: O servidor recebe um estado incorreto, sobrescreve-o ou uma tag grava cookies ou envia identificadores contrários à configuração de consentimento.

1) Confirme quando a mudança foi ativada e qual parte da mensuração foi modificada. 2) Guarde períodos comparáveis de usuários, sessões, compras e receita antes e depois. 3) Registre também campanhas, promoções, mudanças no site e no consentimento. 4) Compare com pedidos e vendas da loja. 5) Explique quais variações têm evidências e quais continuam em aberto. Uma métrica mudar no dia da ativação não comprova, por si só, que a nova mensuração foi a causa.

Você pode considerar verificado se: Existe uma comparação documentada com datas, definições, contexto e limites de interpretação.

Vale investigar se: Uma variação é apresentada como crescimento do negócio ou recuperação da mensuração sem que essas explicações tenham sido verificadas.

1) Confirme quais ações são enviadas pelo navegador e pelo servidor. Se a implementação usa apenas uma origem, documente que este item não se aplica. 2) Combine um teste e identifique as cópias por event_name e event_id. 3) Para ver envios do servidor na ferramenta de teste, pode ser necessário um código de teste configurado por quem administra a integração. 4) Revise os sinais de deduplicação disponíveis e os registros de envio. Uma diferença entre a Meta e a loja, ou um percentual agregado acima de zero, não comprova, por si só, a deduplicação dessa compra.

Você pode considerar verificado se: As cópias da mesma ação compartilham os identificadores previstos, e há evidências de que são tratadas como um único evento.

Vale investigar se: As cópias usam IDs diferentes, falta um identificador necessário ou são observadas duplicações sem explicação.

1) Abra os detalhes de Purchase e procure a avaliação de qualidade da correspondência dos eventos do servidor. 2) Revise as recomendações e os parâmetros ausentes ou inválidos. 3) Compare com os dados que seu negócio pode enviar de forma válida e com o consentimento adequado. Nem todos os identificadores estão disponíveis em todas as visitas. 4) Documente o estado e as melhorias pertinentes com o responsável pela integração. A pontuação não valida o valor da compra, a deduplicação nem um resultado comercial.

Você pode considerar verificado se: A avaliação foi revisada, e não há erros de formato sem tratamento nos parâmetros que devem ser enviados.

Vale investigar se: Há dados com formato inválido ou recomendações relevantes sem revisão. Se não houver dados suficientes para avaliar, deixe o item pendente.

1) Combine uma compra de teste com um pedido identificável. 2) Revise value e currency e, quando aplicável à integração, contents ou content_ids. 3) Compare valor, moeda, produtos e quantidades com o comprovante e a definição de valor usada pela conta. 4) Se o evento for enviado apenas pelo servidor, peça o registro ou um teste dessa origem. A ausência de avisos em Diagnóstico não comprova que o valor está correto, e uma diferença de ROAS entre plataformas não identifica a causa.

Você pode considerar verificado se: Os dados enviados representam o pedido, e o critério de valor usado na comparação está documentado.

Vale investigar se: Faltam parâmetros necessários, a moeda ou a unidade está incorreta, aparecem outros produtos ou o valor não pode ser conciliado.

1) Identifique as ações que as campanhas usam para otimização. 2) Revise o status, o último dado recebido e qualquer aviso de diagnóstico. 3) Compare com um período em que havia conversões esperadas e considere o tempo de processamento. 4) Se não houver dados recentes, investigue a atividade e a origem da mensuração antes de concluir que há uma falha. 5) Anote os alertas sem solução e quem deve revisá-los.

Você pode considerar verificado se: As ações relevantes recebem os dados esperados ou há uma explicação verificada para a falta de atividade.

Vale investigar se: Uma ação com atividade esperada é interrompida, há alertas sem solução ou ninguém consegue explicar seu status.

1) Identifique a origem da conversão. 2) Se ela usa uma tag do Google Ads no Google Tag Manager, compare o ID e o rótulo de conversão com os da ação prevista; resolva os valores das variáveis quando os campos não forem literais. 3) Se vier do Analytics, revise a propriedade, o evento e a conta vinculada. 4) Considere a mensuração por uma conta de administrador se a organização usar esse recurso. 5) Verifique o envio em um teste combinado. Não altere IDs durante o autodiagnóstico.

Abrir na sua propriedade: Vinculações com o Google Ads · Eventos principais

Você pode considerar verificado se: A configuração aponta para a ação e a conta previstas, e o teste confirma esse destino.

Vale investigar se: O ID, o rótulo ou a vinculação corresponde a outra ação, conta ou propriedade sem uma razão documentada.

1) Liste as ações que representam a mesma venda, como uma tag do Ads e uma importação do Analytics. 2) Revise quais são principais e quais metas cada campanha usa. 3) Verifique se duas cópias da mesma compra não alimentam a otimização por engano. 4) Revise também as metas personalizadas: elas podem usar ações secundárias nos lances. 5) Documente por que uma campanha usa compras, leads ou outras ações. Várias ações podem ser válidas quando representam resultados diferentes; não decida apenas contando quantas são principais em toda a conta.

Você pode considerar verificado se: Cada campanha usa os resultados definidos para sua meta, sem contar a mesma venda duas vezes por fontes duplicadas.

Vale investigar se: Duas cópias da mesma compra alimentam a otimização ou são incluídas ações que não correspondem à meta da campanha.

1) Abra cada ação relevante e anote se ela conta Uma ou Todas/Cada conversão, conforme o rótulo da interface. 2) Para vendas, verifique se é necessário contar cada compra. Para leads, avalie se faz sentido contar um por interação ou cada resultado. 3) Documente o critério com quem administra as campanhas. 4) Revise a identificação dos pedidos separadamente: escolher Uma não substitui a deduplicação de compras e pode ocultar compras distintas válidas.

Abrir na sua propriedade: Eventos principais

Você pode considerar verificado se: A contagem corresponde à definição de negócio, e a configuração está documentada.

Vale investigar se: A configuração descarta resultados válidos, conta repetições sem valor ou é usada como substituto para corrigir duplicações.

1) Confirme se a implementação usa conversões otimizadas e onde elas são administradas. Se não se aplicar, documente isso sem marcar uma verificação que não realizou. 2) Revise os avisos de dados ausentes, formato e atividade recente. 3) Compare qualquer falta de dados com o volume esperado e o consentimento. 4) Se houver importações, revise o resultado e uma amostra das linhas rejeitadas. Um aviso de clique não encontrado exige investigação; não comprova, por si só, que a venda veio de outro canal.

Você pode considerar verificado se: A configuração prevista funciona, e os alertas relevantes ou erros de upload têm explicação e tratamento documentados.

Vale investigar se: Há erros de formato, envios malsucedidos ou uma interrupção de dados esperados ainda sem explicação.

1) Revise quem tem acesso à conta e quem pode ler, editar, aprovar ou publicar no contêiner. 2) Confirme se cada permissão corresponde ao trabalho atual da pessoa ou equipe. 3) Identifique quem autoriza e quem publica mudanças. 4) Verifique se a organização mantém acesso administrativo e uma alternativa caso alguém deixe de estar disponível. 5) Documente os acessos que precisam de revisão; não remova permissões durante o checklist.

Você pode considerar verificado se: A organização mantém o controle, há responsáveis pela publicação e as permissões correspondem às funções atuais.

Vale investigar se: Há pessoas com permissão de publicação sem responsável conhecido, acessos de antigos colaboradores ou dependência de uma única pessoa para administrar a conta.

1) Revise várias versões recentes, incluindo a publicada. 2) Verifique se é possível identificar o que mudou, por quê, quem aprovou e quais testes foram realizados. 3) Confira se o registro contém links para as evidências quando elas estão em outra ferramenta. 4) Confirme se a equipe sabe qual versão restaurar e como validar uma reversão. Os detalhes não precisam estar todos no nome da versão, mas devem ser localizáveis.

Você pode considerar verificado se: Cada publicação revisada tem uma mudança compreensível, um responsável e evidências de testes.

Vale investigar se: Não é possível reconstruir o que foi publicado, quem autorizou ou como seu funcionamento foi verificado.

1) Compare as tags ativas com o inventário vigente. 2) Revise as que estão pausadas, apontam para contas antigas ou têm nomes ambíguos. 3) Peça a finalidade e o responsável; uma tag pausada pode ter uma razão válida. 4) Documente quais devem ser removidas e quais dependências precisam ser verificadas antes. Não exclua uma tag pelo nome nem por estar pausada.

Você pode considerar verificado se: As tags têm finalidade e destino conhecidos; as que não são mais usadas têm uma decisão documentada.

Vale investigar se: Permanecem destinos desconhecidos, tags de instalações antigas ativas por engano ou elementos sem finalidade que dificultam a manutenção.

1) Escolha um período encerrado com tempo suficiente para o processamento dos dados. 2) Documente datas, status de pedidos, moeda, fuso horário, reembolsos e tratamento de frete e impostos. 3) Use métricas compatíveis de compras e receita; Contagem de eventos, Transações e Receita total não são intercambiáveis. 4) Compare os totais e uma amostra de IDs quando disponível. 5) Se calcular (Analytics − loja) / loja × 100, faça isso por métrica e apenas quando o denominador for diferente de zero. 6) Registre a revisão semanal e as diferenças em aberto. Estabilidade não significa correção, e um total maior não comprova duplicação por si só.

Você pode considerar verificado se: A comparação tem uma base comum, revisão periódica e explicações respaldadas ou investigações em aberto identificadas.

Vale investigar se: São comparadas métricas incompatíveis, os critérios mudam sem registro ou há diferenças relevantes que ninguém revisa.

1) Identifique qual controle monitora compras, receita ou outros eventos relevantes. 2) Revise a condição, a frequência, o segmento e os destinatários. Os insights personalizados do Analytics podem enviar avisos por email. 3) Compare o limite com o volume e a sazonalidade do negócio. 4) Revise um alerta anterior ou um teste controlado do sistema de monitoramento, sem gerar compras falsas em produção. 5) Documente quem investiga e em qual prazo. Um alerta indica uma variação; a causa pode estar na mensuração ou no negócio.

Você pode considerar verificado se: O controle tem uma condição útil, destinatários atuais e evidências de funcionamento ou de um teste controlado.

Vale investigar se: Não existe um controle, os avisos não chegam ao responsável ou as condições geram alertas que a equipe não consegue interpretar.

1) Revise qual necessidade cada dimensão atende e quantos valores distintos pode gerar. 2) Identifique IDs únicos ou registros de data e hora cadastrados sem uma necessidade justificada; eles podem aumentar a cardinalidade. 3) Verifique se aparece (other) e quanto detalhe essa linha agrupa no relatório. Ela pode ter mais de uma causa e não comprova que uma dimensão específica é responsável. 4) Para analisar pedidos individuais, avalie com sua equipe as dimensões padrão e, quando necessário, dados exportados.

Abrir na sua propriedade: Definições personalizadas

Você pode considerar verificado se: As dimensões têm uma finalidade documentada, e o nível de detalhe disponível é suficiente para a análise prevista.

Vale investigar se: Valores únicos consomem capacidade sem uma necessidade clara ou a agregação impede responder à pergunta do relatório.

1) Abra os relatórios que você usa regularmente. 2) Leia o indicador de qualidade e registre se ele informa limites, amostragem, modelagem ou outra restrição. 3) Avalie como isso afeta a pergunta que você quer responder. 4) Quando adequado, compare um período mais amplo ou remova uma dimensão desnecessária. 5) Não altere a identidade dos relatórios como correção automática: ela pode mudar a leitura de usuários e exige uma decisão documentada. Usar todos os dados disponíveis não comprova que todas as ações reais foram observadas.

Abrir na sua propriedade: Identidade de relatórios

Você pode considerar verificado se: Os relatórios permitem a análise prevista, e suas limitações são identificadas e consideradas nas conclusões.

Vale investigar se: São tomadas decisões com base em detalhes ocultos ou incompletos sem revisar o aviso de qualidade dos dados.

1) Liste os parâmetros personalizados que você precisa usar nos relatórios. 2) Revise se eles exigem uma dimensão ou métrica personalizada, ou se já existe um campo padrão que os cobre. Não registre por padrão todos os parâmetros enviados. 3) Verifique nome e escopo: evento, usuário ou item, conforme aplicável. 4) Confirme o recebimento e analise dados posteriores ao registro, considerando o tempo de processamento. O registro não reconstrói o histórico. 5) Se não aparecer informação, revise a compatibilidade da exploração, os filtros e os dados disponíveis antes de atribuir uma causa.

Abrir na sua propriedade: DebugView · Definições personalizadas

Você pode considerar verificado se: Os campos necessários para a análise estão registrados quando adequado, com nome, tipo e escopo corretos, e mostram dados compatíveis.

Vale investigar se: Um parâmetro necessário chega, mas não pode ser usado por falta de definição ou definição incorreta, ou são registrados campos redundantes sem finalidade.