A régua de medição do FARM,
pronta para virar decisão.
Um raio-x completo da conta GA4 da CCAB AGRO e o desenho do Dash Analytics do FARM. O que já é confiável, o que precisa ser instrumentado e o caminho para o dashboard mostrar receita, jornada e mídia.
Cinco movimentos, uma decisão.
A leitura foi organizada em blocos que vão do estado real da conta até o plano de execução. Cada bloco existe para responder uma pergunta de negócio.
Diagnóstico
O que o GA4 coleta hoje, seção por seção, com números reais.
Base
Leitura dupla de usuário e cobertura, personas e clusters.
Régua
Dicionário de métricas, identidade e plano de eventos.
Canais
Rastreabilidade por canal, UTM e placar por vendedor.
Dashboard
Visão do painel, cronograma, riscos e recomendações.
A plataforma de relacionamento e compra da CCAB no agro.
O FARM é a área logada da CCAB AGRO em farmibrasil.com.br, construída sobre Magento. E onde o cliente do agronegócio consulta preço, faz pedido, acompanha histórico e usa o painel de gestão. O público e profissional e regional, concentrado no interior produtor.
O valor está na área logada, não na porta de entrada.
As páginas mais acessadas revelam o que o usuário realmente faz dentro do FARM. Login e recuperação de senha aparecem no topo por volume, mas o tempo de uso se concentra no painel de gestão.
Quanto do tempo do usuário e valor real, e quanto é só login?
A pergunta central do negócio é direta: se um usuário passa seis minutos na plataforma e quatro deles são apenas para entrar, o número de engajamento engana. A conta precisa separar o tempo de autenticação do tempo de valor.
A tela de login registra 38 segundos de engajamento. O painel de gestão registra 4 minutos e 55 segundos. O valor está depois da autenticação.
Não existe hoje um evento que marque a fronteira entre entrar e começar a usar. Esse evento precisa ser criado, e é o que destrava a leitura pedida. HIPÓTESE a validar
Todo número tem origem. Toda leitura tem selo.
A análise saiu direto da propriedade GA4 CCAB AGRO, fluxo web único do farmibrasil.com.br, na janela de 05/06 a 02/07/2026. Nenhum dado foi estimado sem aviso. Cada afirmação carrega um selo de confiança.
O que a conta coletou na janela.
A base de comportamento e navegação está saudável e confiável. Estes são os números de coleta ativa.
De onde vem o tráfego.
O tráfego se concentra em acesso direto. Isso é coerente com uma área logada de clientes fieis, mas também revela que os canais de campanha ainda não chegam etiquetados.
77,6% do tráfego sem origem rastreável
281 de 289 usuários chegam sem origem.
Por primeira origem, quase todo mundo cai em direct sem nenhuma. As frações de whatsapp, e-mail e busca são mínimas. Isso não é um problema de tráfego, é uma oportunidade de atribuição: com UTM padronizada, cada acesso passa a contar a sua própria história.
Enquanto a origem não for etiquetada, o dashboard não consegue dizer qual canal trouxe qual cliente. A padronização de UTM é um dos marcos do plano. RECOMENDAÇÃO
281 usuários entram sem origem
As páginas que sustentam a experiência.
O relatório completo tem 67 caminhos. Os principais mostram uma jornada de cliente logado, com forte peso do painel de gestão e do fluxo de conta.
O painel de gestão retém o tempo de valor
O painel de gestão tem 402 visualizações e o maior tempo de uso da conta, 4min55s. E o coração da experiência logada.
| Página | Views | Tempo |
|---|---|---|
| Login do cliente | 482 | 38s |
| Painel de gestão | 402 | 4min55s |
| Home | 314 | 47s |
| Recuperar senha | 312 | |
| Histórico de pedidos | 91 | 13s |
| Catálogo fungicidas | 75 | 21s |
A conta coleta cinco eventos. Todos automáticos.
Dos 6.589 eventos, todos vem do rastreio padrão do GA4, mais um view_item residual. Nenhum evento de negócio ou de feature existe ainda. Esse é o ponto que a régua de medição resolve.
Nenhum evento de negócio dispara ainda
O funil de compra existe na configuração. Falta ligar a coleta.
Os eventos add_to_cart, begin_checkout, purchase e view_cart estão marcados como principais, mas não disparam. Assim que forem instrumentados, o dashboard passa a exibir receita, conversão e ticket. E o destravamento de maior valor da conta.
Sem Google Ads vinculado, não há custo nem ROAS.
A seção de Publicidade está na tela inicial, o que confirma que nenhuma conta de Google Ads está vinculada a propriedade. Enquanto o vínculo não for feito, o dashboard não mostra investimento, CPA nem ROAS.
Muita entrada nova, espaço para trabalhar recorrência.
São 247 usuários novos contra 133 recorrentes. A curva por coorte cai forte depois do segundo dia, padrão comum, mas relevante porque grande parte do tráfego e de clientes que já tem conta.
133 recorrentes para a retenção proteger
O peso da área logada mostra que há base para nutrir recorrência. O caminho e transformar visitante único em usuário recorrente com ação segmentada.
RISCO não tratar baixa recorrência como churn sem descontar a sazonalidade de fim de safra.
Um perfil clássico de agronegócio.
A geografia e o perfil confirmam o público: interior produtor, predominância masculina e faixa produtiva. Os sinais do Google estão ativos em todas as regiões, os alertas nos cards são apenas aviso de amostragem por volume, não falha de configuração.
Núcleo na faixa 25 a 34 anos
Público majoritariamente masculino
Demanda concentrada no interior produtor
Desktop domina. Uso profissional, no horário de trabalho.
O FARM é usado no computador, com 84,5% de desktop contra 15,5% de mobile. Windows lidera com folga e Chrome é o navegador principal. Esse perfil orienta o desenho do dashboard é a prioridade de layout.
84,5% acessa pelo desktop
A fundação que ainda precisa ser criada.
Além da coleta, o dashboard depende de estrutura. Hoje não existem dimensões, métricas ou públicos de negócio, nem identificador estável de usuário. Sem isso, não há corte por vendedor, regional ou tipo de cliente.
Sem user_id
Contagem por dispositivo, não por pessoa. Recorrência fica imprecisa.
Zero dimensões custom
Nenhum recorte de negócio disponível. Precisa ser criado do zero.
Só públicos padrão
All Users e Purchasers. Nenhum público personalizado.
BigQuery desligado
Exportação bruta a confirmar para análises profundas.
O que já é confiável, e o que destrava o dashboard.
A coleta de comportamento e sólida. As duas dimensões que são o coração de um dash de e-commerce, receita e mídia, dependem de instrumentação. Essa é a fronteira de trabalho.
- Aquisição por canal e sessão
- Engajamento e páginas, 67 caminhos
- Demografia e geografia
- Tecnologia e dispositivo
- Fluxo único ativo, 14 meses de retenção
- Tagueamento de e-commerce, receita
- Vínculo de Google Ads, mídia e ROAS
- Padronização de UTM, atribuição
- user_id, dimensões e públicos custom
- Evento de fronteira login e valor
Usuário e cobertura são dois números, nunca um só.
Existe uma ambiguidade importante na leitura da base. Usuário único mede quem opera a plataforma. Cliente por CPF ou CNPJ mede quantas contas comerciais são alcançadas. A decisão e reportar os dois lado a lado.
Quem opera o FARM. KPI de adoção. Subiu de 129 para 285 no acumulado. A meta de 500 é medida aqui. referência comercial
Contas comerciais alcançadas. 2,11 clientes por usuário. KPI de cobertura. referência comercial
Três perfis movem a plataforma.
O comportamento dentro do FARM é sustentado por perfis distintos, cada um com uma ação clara no plano.
Cliente produtor
Profissional do agro, acessa no desktop, consulta preço e faz pedido. Concentrado no interior produtor.
Vendedor
23 vendedores, média de 4,65 visitas cada, 107 visitas na base. Motor da campanha da camisa.
Cliente na base sem login
Cadastrado mas nunca entrou. O maior espaço de crescimento rumo a meta de 500.
Quatro grupos de comportamento, quatro ações.
Segmentar por comportamento transforma número em ação. Cerca de três em cada quatro usuários entraram uma vez e não voltaram, e cerca de um em cada quatro voltou. Os cortes vêm da contagem parcial, com lacuna de maio, então são ponto de partida a calibrar.
| Cluster | Critério de sessões | Tamanho parcial | Ação típica |
|---|---|---|---|
| Nunca entrou | 0 sessões, existe na base sem primeiro acesso | Base menos os 285 logados hipótese | Ativação, reforço de convite por vendedor e e-mail |
| Entrou e não voltou | 1 sessão, recência alta | cerca de 217 usuários, 76% parcial | Reengajamento, entender por que não achou valor |
| Uso leve | 2 a 3 sessões na janela | recorte dentro dos recorrentes parcial | Educação de features, mostrar o que ainda não usou |
| Uso recorrente | 4 ou mais sessões, ou frequência alta e recência baixa | 68 com mais de 1 visita, 24%, um usuário com 16 parcial | Reter, ouvir, transformar em referência interna |
Ativo até 30, esfriando 31 a 60, frio 61 a 90, inativo acima de 90. Enquanto a frequência é manual e com furos, priorizar o eixo de recência, que vem limpo do último acesso do Magento.
Muita frequência com recência inativa é um recorrente que abandonou. Uma sessão com recência ativa é um recém-chegado, ainda dá para converter em recorrente.
O cluster nunca entrou e o caminho até a meta de 500.
A adoção hoje está em 285 usuários. A meta é 500. A diferença mora no grupo de clientes que já estão na base e nunca fizeram login. Isolar e ativar esse grupo é a ação de maior impacto sobre a meta.
Uma régua única, para todos falarem a mesma língua.
A régua é o conjunto de definições que elimina ambiguidade. Ela cobre quatro camadas: identidade, acesso, engajamento e negócio. Cada métrica tem nome, definição e fonte.
Identidade
Quem é usuário, quem é cliente, como são contados.
Acesso
Primeiro acesso, recorrência e frequência por janela.
Engajamento
Tempo até o valor, tempo por sessão, uso por feature.
Negócio
Funil de compra, receita e conversão após instrumentação.
A régua também separa expectativa de realidade: o que dá para medir hoje, o que só depois da integração Edrone com Magento, e o que só depois da virada de arquitetura que separa usuário de cliente.
| Métrica | Hoje | Pós-integração | Pós-arquitetura |
|---|---|---|---|
| Primeiro acesso e usuários únicos | Sim | Sim | Sim |
| Último acesso e recência | Sim | Sim | Sim |
| Contagem de sessões e frequência | Não, só manual | Sim | Sim |
| Recorrência automatizada | Não | Sim | Sim |
| Tempo de login separado do tempo útil | Não | Sim | Sim |
| Profundidade e uso por feature | Não | Sim | Sim |
| Visualização de produto por usuário | Não | Sim | Sim |
| Atribuição de lead em nível de usuário | Não | Parcial | Sim |
| Comportamento por cliente, desamarrado do usuário | Não | Não | Sim |
Definições oficiais, com fonte marcada.
Cada linha é uma decisão de leitura. Onde há número, a origem está marcada como fato ou hipótese.
| Métrica | Definição | Referência |
|---|---|---|
| Usuário único | Pessoa física que faz login, identificada por user_id estável | 285 acumulado, 289 janela 28d GA4 |
| Cliente CPF ou CNPJ | Entidade comercial dentro do pool de compras de um usuário | 601, ou 2,11 por usuário comercial |
| Primeiro acesso | Primeiro login registrado de um user_id | 247 na janela GA4 |
| Recorrência | Usuários com mais de um acesso no período | cerca de 24%, 68 de 285 parcial |
| Frequência | Sessões médias por usuário por janela | 1,67 geral, 4,65 vendedores parcial |
| Tempo até valor | Do session_start ao primeiro evento não de autenticação | a criar depende de evento |
| Uso por feature | Acessos por área funcional do FARM | a criar, hoje via page_view |
user_id, a base de tudo.
Sem identidade estável, recorrência e frequência continuam manuais e imprecisas. O customer_id do Magento entra no GA4 como user_id, via dataLayer, no momento da autenticação. Isso transforma contagem por dispositivo em contagem por pessoa.
window.dataLayer = window.dataLayer || [];
dataLayer.push({
event: 'farm_identify',
user_id: '48213', // customer_id do Magento, estavel
is_vendedor: false, // true para os 23 vendedores
regional: 'centro-oeste',
clientes_associados: 3 // contagem, nunca a lista de CPF ou CNPJ
});
Os eventos que faltam para o dashboard existir.
A conta sai de 5 eventos automáticos para um conjunto que enxerga login, valor, feature e compra. Cada evento tem gatilho, parâmetro e responsável de implementação.
| Evento (dataLayer) | Quando dispara | Parâmetros | Status hoje |
|---|---|---|---|
| farm_identify | Uma vez por sessão, logo após o login | user_id, is_vendedor, regional, clientes_associados | criar |
| login_success | No instante em que a autenticação é confirmada | user_id, metodo_login, login_timestamp | criar |
| primeiro_evento_util | Na primeira ação de valor após o login, 1x por sessão | user_id, tipo_acao, ms_desde_login | criar |
| feature_acessada | Ao entrar em uma feature nomeada (catálogo, pedidos, histórico, cotação) | user_id, feature_nome, origem | criar |
| view_produto | Ao abrir a página ou o card de um produto | produto_id, produto_nome, categoria | parcial, view_item |
| session_start | Automático do GA4, com user_id herdado | user_id herdado | existe |
A conta que responde a pergunta central.
O tempo até o primeiro evento útil isola os minutos de login do tempo de valor real. Essa é a resposta direta ao caso dos seis minutos que eram só login.
=
timestamp(first_useful_event)
menos
timestamp(login_farm)
A evidência do GA4 confirma a necessidade: login com 38s de engajamento contra 4min55s no painel de gestão. O evento de fronteira torna essa leitura automática e confiável.
Os recortes de negócio, criados do zero.
Hoje existem zero definições personalizadas. Sem elas o dashboard não segmenta por vendedor nem por regional. Estas são as dimensões e métricas mínimas a criar no GA4.
O que da para medir em cada canal.
Nem todo canal se mede do mesmo jeito. A matriz deixa claro o que é mensuravel, o que é ponto cego e qual a saída técnica de cada um.
| Canal | Da para medir | Ponto cego | Saída |
|---|---|---|---|
| Abertura, clique, chegada com UTM, lead identificado | Comportamento antes do clique | UTM completa mais webhook na chegada | |
| WhatsApp orgânico | Nada de forma direta | Quem enviou, clique real, atribuição | Proxy por volume e região, link oficial |
| Meta pago | Impressão, clique, alcance e visualização. Após o login, o lead vira identificado | Identidade da pessoa antes do cadastro, o tracking é do Meta | UTM no anúncio, fbclid em cookie 1st-party, advantage_audience 0 |
| Link com UTM | Canal, campanha, lead após interceptação | Identidade sem login | Interceptar UTM na landing e disparar webhook |
O WhatsApp pessoal é um ponto cego estrutural.
Nenhuma solução técnica torna o disparo pessoal 100% rastreável. Existem duas saídas: tratar por proxy, com link único por vendedor, ou migrar o disparo para a API oficial do Meta. As duas estão no plano.
RISCO seguir sem rastreio de canal impede qualquer leitura de origem de lead. A interceptação de UTM mais webhook unifica e-mail, Meta e link numa leitura única. RECOMENDAÇÃO
Uma etiqueta única, obrigatória, para toda campanha.
Com 77,6% do tráfego em direct, a padronização de UTM é o que devolve origem ao dado. Este é o padrão obrigatório para o FARM.
utm_medium = email | paid_social | whatsapp | cpc
utm_campaign = farm_ativacao_2026 | camisa_selecao_2026
utm_content = v01 a v23 (vendedor) | id do anuncio
utm_term = reservado, usar so quando fizer sentido
Transformar disparo pessoal em placar confiável.
Como o disparo e pelo WhatsApp pessoal, a CCAB não sabe quem enviou. A solução e gerar um link único por vendedor. Quem realmente disparou é inferido por volume de logins novos por utm_content e por concentração regional.
Link por vendedor, proxy A
utm_content igual ao id do vendedor (v01 a v23), distribuído antes de cada onda. É o proxy mais forte, o mais próximo do envio real.
Volume vira ranking
Logins novos por utm_content ordenam o placar de atividade.
Regional pelo farm_identify, proxy B
O campo regional do farm_identify cruza com o salto de logins na janela. É o proxy mais fraco, usar só quando não houver link por vendedor.
A visita do vendedor não é a ativação do cliente.
Com o link único e a UTM padronizada, o placar por vendedor e regional deixa de ser manual. São 23 vendedores, 107 visitas registradas e média de 4,65 por vendedor na base atual. Esse número é a visita do próprio vendedor, uma leitura parcial.
O vendedor movimenta quase 3x mais
Começar rápido, sem pagar retrabalho duas vezes.
A integração é o primeiro passo da coleta automatizada. Ela e bloqueante: sem ela toda recorrência continua manual. Duas rotas foram avaliadas.
- Mais rápida, reaproveita o dataLayer
- Menos desenvolvimento
- Depende do navegador: ad-blocker, ITP e consentimento derrubam parte dos eventos
- Risco médio de retrabalho na virada
- Controle total, identidade na origem
- Resiliente a virada de arquitetura
- Mais lenta e mais custosa
- Risco alto de prazo, baixo depois de pronta
Disparo que escala, rastreia e gera placar.
A API oficial substitui o disparo pessoal por mensagens aprovadas, rastreáveis e escaláveis. Todo link carrega a UTM padrão. Os templates cobrem as três categorias vigentes da plataforma: Utility, Marketing e Authentication.
Convite de ativação
Olá nome, aqui é a CCAB. O FARM é a nossa plataforma de compras. Acesse pelo link e faça seu primeiro login. Exige opt-in de marketing.
Cliente inativo
Nome, faz um tempo que você não acessa o FARM. Novidades no catálogo de defensivos e fertilizantes esperam por você, com link.
Safra chegando
Nome, período de safra chegando. Garanta seu planejamento de insumos no FARM, com link.
Confirmação de pedido
Olá nome, seu pedido número foi confirmado. Valor R$ valor. Acompanhe o status pelo link. Transacional, não exige opt-in.
Aviso de cotação
Olá nome, a cotação que você pediu no FARM foi atualizada. Veja o preço atual e feche pelo link. Só quando há solicitação prévia.
Código de acesso
Código é o seu código de acesso ao FARM, expira em 10 minutos, não compartilhe. Só se o FARM usar login por código, sem link.
O Dash Analytics do FARM, em cinco abas.
O painel consolida tudo numa única interface. Enquanto receita e mídia são instrumentadas, os campos dependentes ficam sinalizados, sem inventar número.
Onde o cliente passa o tempo dentro do FARM.
A leitura por área funcional confirma o painel de gestão como o ponto de valor, seguido de login, home, histórico e catálogo. Hoje vem de page_view por caminho, até os eventos de feature existirem.
O painel de gestão lidera o uso
A sequência de entregas, priorizada pelo diagnóstico.
A ordem não e aleatoria. As três primeiras etapas técnicas são pré-requisito: sem elas o dashboard nasce com receita e mídia em branco.
Alinhamento de escopo
Definir escopo do dash, integrações ativas e responsabilidades com o parceiro de tecnologia.
Corrigir tagueamento de e-commerce
Instrumentar add_to_cart, begin_checkout, purchase e view_cart. Marco técnico que destrava receita.
Vincular Google Ads
Habilitar custo, CPA e ROAS na seção de publicidade.
Padronizar UTMs
Aplicar o padrão único e reduzir o tráfego sem origem.
Criar dimensões e públicos
user_id, tipo_usuário, regional, feature, cliente_count e públicos de negócio.
Desenhar as visões do dash
Aquisição, engajamento, funil, conversão, demografia e tecnologia.
Revisão e entrega
Conferir consistência de dados e estrutura antes da entrega final.
Três pré-requisitos técnicos, tratados como marcos.
Sem estes três destravamentos, o dashboard nasceria mostrando receita e mídia em branco e com atribuição de origem distorcida.
Funil de e-commerce
Correção do tagueamento. Habilita receita e conversão no painel.
Vínculo Google Ads
Habilita investimento, CPA e ROAS por canal.
UTM padronizada
Devolve origem ao dado e corrige a atribuição.
O que vigiar para a leitura não enganar.
Cada risco tem uma ressalva de leitura. Registrar aqui protege a decisão de conclusões erradas.
Baixa recorrência pode ser fim de safra, não churn. Não tratar visitante único como perda definitiva sem descontar a estação.
O ranking por link mede atividade e volume, não envio real. Sempre reportar como proxy para não premiar o vendedor errado.
O user_id precisa ser hash estável, nunca CPF ou CNPJ em texto puro trafegando no GA4.
Iniciar a Rota A sem planejar a virada de arquitetura pode gerar remapeamento. Planejar as duas rotas em conjunto.
A ação de maior impacto, e para onde ela leva.
A prioridade única e publicar user_id estável e o evento de fronteira login e valor. Isso destrava recorrência real e tempo de valor de uma só vez. Em seguida, ativar o cluster nunca entrou aproxima a base da meta de 500.
Identidade e evento de valor primeiro, correção de e-commerce e vínculo de Google Ads em paralelo, ativação do cluster nunca entrou como motor da meta.
Meta 57% cumprida, 285 de 500
O rastreio existe, mas o valor não chega ao GA4.
A análise leu o código servido pelo site em três tipos de página, home, categoria e produto, e extraiu o dataLayer real de cada uma. A leitura vem do dataLayer renderizado no HTML, sem acesso ao painel do GTM nem ao container publicado. Por isso os eventos de meio e fim de funil ficam marcados como não confirmados, não como ausentes em definitivo.
"pageType": "product",
"event": "view_item",
"ecommerce": {
"items": [{
"item_name": "TRICLOPIR CCAB 480 EC 4 X 5L",
"item_id": "121",
"price": "44.03" // texto, não número
"currency": "BRL"
}]
// falta a chave value no nível do ecommerce
}
}
O evento view_item existe e traz currency, mas não traz o value no nível do evento, que é o campo que carrega o valor monetário para o GA4. O preço vem entre aspas, como texto.
Três causas zeram a receita no GA4.
O valor do pedido e do carrinho não aparecem no GA4 por uma combinação de três causas confirmadas no código. As três precisam ser tratadas juntas, corrigir uma sem as outras não destrava a receita.
Sem o parâmetro value
view_item e view_item_list não enviam value no nível do evento. Sem ele, o GA4 registra o evento mas reporta valor zero.
Preço como texto
O preço chega como "44.03", entre aspas. O GA4 exige número. Mesmo adicionando value, se for texto continua zerando. Os 33 preços da categoria estão como texto.
Funil não confirmado
No código servido só aparecem view_item e view_item_list. add_to_cart, begin_checkout e purchase não foram confirmados.
value e currency precisam viver no nível do evento e como número, não só dentro do item. Para o view_item, value iguala o price do item.
dataLayer.push({
event: "view_item",
ecommerce: {
currency: "BRL",
value: 44.03, // número, no nível do evento
items: [{ item_id: "H154.480.EC.002", price: 44.03, quantity: 1 }]
}
});
Quatro ajustes de estrutura e conformidade.
Além das três causas raiz, a auditoria encontrou quatro pontos que não zeram a receita, mas degradam relatório, remarketing e conformidade.
| Achado | Severidade | O que fazer |
|---|---|---|
| Item incompleto | ALTA | Falta quantity, item_brand e item_variant. Padronizar o item com id, nome, preço numérico, quantity, marca e variante. |
| Nomenclatura fora do padrão | ALTA | Chaves como item_sku e item_image_url não populam as dimensões nativas do GA4. Mapear para os nomes oficiais na tag. |
| Home sem event nem ecommerce | MÉDIA | As vitrines, mais vendidos e novidades, não geram view_item_list. Adicionar a lista por vitrine e o select_item no clique. |
| Sem Consent Mode v2 | ALTA | Não há evidência de consentimento no fluxo. Confirmar o banner e implementar o default negado com update no aceite. |
As críticas são a causa direta do valor zerado
A ordem de correção, e o que ainda falta para fechar.
A sequência segue o impacto: primeiro o que mais pesa na receita, depois o que melhora relatório e conformidade.
Confirmar o funil em ambiente logado
Validar add_to_cart, begin_checkout e purchase com value e currency. É o que mais dói, então vem primeiro.
Corrigir value e o tipo numérico
value e price como número, no nível do evento, em toda a cadeia de eventos de e-commerce.
Padronizar nomenclatura e completar o item
Nomes oficiais do GA4, mais quantity, marca e variante, e o item_id igual ao id do feed do Merchant Center.
Instrumentar a home e confirmar o consentimento
view_item_list por vitrine e select_item no clique, e o Consent Mode v2 default negado com update no aceite.
A ordem é ditada pela dependência técnica, não pelo calendário.
Nada de comportamento é coletado antes da integração existir, então os marcos seguem a dependência real. As datas são relativas, por semana, porque as datas firmes só fecham no alinhamento inicial. Antes disso, publicar prazo absoluto é estimativa sem base.
Insumos já prontos, a base que define o caminho técnico
| Documento | Papel no projeto |
|---|---|
| Dicionário e régua de medição | Define 285 versus 601 e o que é mensurável em cada fase |
| Plano de eventos GA4 e GTM | dataLayer, user_id, login versus tempo útil |
| Matriz de rastreabilidade por canal | O que dá e o que não dá para medir por canal |
| UTM e campanha da camisa | Padrão de marcação e proxy por vendedor |
| Clusterização da base | Segmentos de comportamento |
| Dashboard consolidado HTML | Painel com campos de entrada |
| Integração Edrone com Magento | Rota A versus B em fases |
| Templates de WhatsApp Meta | Canal oficial rastreável |
Linha do tempo por marcos
Nove marcos, do alinhamento à coleta durável.
Cada marco traz o que entrega, quem executa, do que depende, o prazo relativo e a saída concreta.
| Marco | O que | Responsável | Depende de | Prazo | Saída |
|---|---|---|---|---|---|
| M0 Alinhamento | Validar o plano de eventos e a integração, fechar datas firmes e a lista de features. | Execução de tráfego conduz, parceiro de tecnologia e time técnico da CCAB participam | Nada, é o ponto de partida | S1 | Datas firmes de M1 e M2, lista fechada de features |
| M1 Integração F1 | Interceptar UTM e disparar webhook ao Edrone com user_id e origem (Rota A mínima). | Parceiro de tecnologia, validação da execução de tráfego | M0, parceiro de tecnologia | S2 a S3 | Atribuição de canal começa a funcionar |
| M2 Eventos | farm_identify, login_success, primeiro_evento_util, feature_acessada, view_produto, dimensões e métricas no GA4. | Parceiro de tecnologia, validação no GA4 DebugView | M0 e export do container GTM, parceiro de tecnologia | S2 a S4 | Coleta de comportamento ativa, tempo de login separado do tempo útil |
| M3 Coleta | Confirmar que os eventos disparam corretos, sem duplicação, com user_id antes do session_start. | Execução de tráfego | M2 | S4 | Dado limpo entrando, base para popular o dashboard |
| M4 Dashboard | Preencher o dashboard com o dado real que passou a ser coletado. | Execução de tráfego | M3 | S4 a S5 | Painel de navegação real, o que foi pedido |
| M5 Clusters | Primeira clusterização por recência, cruzada com o calendário de safra. | Execução de tráfego | M3 e calendário de safra da CCAB | S5 | Base segmentada em nunca entrou, entrou e não voltou, uso leve, recorrente |
| M6 Canais | Padronizar UTM, distribuir os 23 links por vendedor, submeter os templates Utility ao WhatsApp Manager. | Execução de tráfego e comercial da CCAB | Parcialmente independente, roda em paralelo desde a S2 | S2 a S4 | WhatsApp deixa de ser canal cego, placar da camisa por proxy |
| M7 Visita versus venda | Metodologia e execução do cruzamento por chave CPF ou CNPJ. | Execução de tráfego | Bases de vendas e de acessos da CCAB | S5 a S6 | Taxa real de visita para venda, sem estimativa |
| M8 Rota B | Módulo no Magento para coleta server-side e vínculo correto usuário versus cliente. | Parceiro de tecnologia | Virada de arquitetura usuário versus cliente, sem data | S6+ | Coleta durável, imune a ad-blocker e ITP |
O que define a velocidade do projeto.
Metade dos marcos depende do parceiro de tecnologia. Se o alinhamento inicial escorrega, todo o resto escorrega junto. Por isso ele é o marco urgente.
A integração Edrone com Magento ainda não existe, e os marcos M1 a M5 dependem dela. As bases de vendas e de acessos ainda não chegaram, e o M7 depende delas. A virada de arquitetura usuário versus cliente não tem data, e o M8 depende dela.
Metade dos marcos depende do parceiro de tecnologia. Datas firmes só existem depois do alinhamento inicial, então publicar prazos absolutos antes disso é estimativa sem base.
Os oito documentos já prontos deixam o caminho técnico definido, então o cronograma sai com dependências reais, não com estimativa solta.
Fechar o alinhamento inicial nesta semana, porque é ele que destrava todos os marcos de coleta, e enviar a lista de dados do cruzamento visita versus venda.
Três indicadores conduzem a leitura: ativação, engajamento e features.
Cada indicador traz fórmula, como captar, ferramentas, cadência, responsável e meta. Eles formalizam o que o dashboard vai acompanhar e conversam direto com o resto do relatório: a ativação amarra na meta de adoção, o engajamento amarra na recorrência, e as features amarram no evento de uso por feature.
Base Total → Primeiro Acesso, número e porcentagem
% Ativação = (Usuários com 1º login no período) ÷ (Base Total elegível) × 100
Taxa Média de Engajamento Geral
Engajamento = (Usuários ativos no período) ÷ (Usuários com ≥ 1 acesso), em janelas DAU, WAU e MAU
Engajamento por Sessão, features mais acessadas
Top features = ranking de eventos por sessão (views, ações, tempo médio na feature)
Tempo na tela não é tempo de valor.
A leitura de comportamento engana quando o número técnico não é desmembrado nem traduzido. Duas correções mudam a conversa: separar fricção de uso real, e falar em linguagem de negócio.
Enquanto o dado por usuário não existe, a leitura é por volume de página e por feature: onde o usuário navega, o que acessa, onde para e onde encontra fricção.
O dado individual por usuário, quem fez o quê, entra na Fase 1, com a coleta por user_id. Aí a navegação deixa de ser volume agregado e passa a ser jornada por pessoa.
Quantas vezes cada perfil volta, não só se voltou.
A recorrência ganha duas camadas que hoje se perdem: a contagem de quantas vezes cada usuário entra, e o recorte por tipo de usuário. Isso complementa a recência e a coorte que já estão no relatório.
Quantas vezes cada pessoa entra no período, reconstruída por user_id na Fase 1, não mais por IP. É o que separa entrada nova de retorno recorrente.
Cliente, vendedor, gestor de crédito e gestores gerais têm padrões de retorno diferentes. Ler cada perfil separado evita a média que esconde comportamento.
A jornada influencia venda que não acontece na tela.
Nem toda venda influenciada pelo FARM é venda direta na plataforma. Parte da receita é offline, mas passou pela jornada. Medir só o que fecha na tela subestima o papel do FARM.
Estimativa comercial: cerca de 1.000 de uma base de 2.100 a 2.200 compradores passaram pela plataforma. Tratar como referência até a base de vendas ser apurada, e nunca somar com outra visão.
Contar só a venda direta na tela ignora a compra que foi influenciada pela jornada e fechada fora da plataforma, com o vendedor ou pelo canal tradicional.
Menos planilha manual, mais leitura qualitativa.
Duas frentes fecham o plano: tirar a consolidação do trabalho manual, e somar uma camada qualitativa ao número.
Ouvir vendedores, gerentes e clientes para ler a experiência que o número não mostra. Montar um mix entre quem mais clicou e quem nunca voltou, para captar os dois extremos, conduzido por um facilitador neutro para a resposta não vir enviesada.
A leitura de dados precisa provocar ação. O time de análise sugere impactos e ações de comunicação de forma proativa, não só quando é perguntado, para o dado não parar no relatório.
A base já prova onde está o valor.
Falta instrumentar e ler.
O GA4 do FARM já mostra que o valor está na área logada, no painel de gestão. Aprovado o dicionário e o plano de eventos, o dashboard passa a mostrar jornada, recorrência, receita e mídia num único lugar.