Kowal Analytics para Magento 2
O que é este módulo
Kowal Analytics é um módulo de atribuição de vendas para Magento 2. A sua função é mostrar que elementos da loja influenciam realmente o carrinho, a encomenda e a receita.
Não se trata de um pixel comum que recolhe visualizações de páginas. O módulo analisa o contexto completo de vendas:
- que área foi visualizada,
- que objeto nessa área foi clicado,
- de que página ou de que produto o utilizador iniciou a interação,
- que produto foi adicionado ao carrinho,
- que SKU foi finalmente comprado,
- que receita deve ser atribuída a esse percurso.
Assim, a loja pode responder a perguntas às quais as analíticas padrão normalmente não respondem:
- Que secções
related productsvendem realmente? - Que blocos
upsellecross-sellgeram receita? - Que artigos do blog conduzem à venda de produtos?
- Que banners, widgets ou secções CMS são apenas clicados, mas não convertem?
- Que elementos da página ocupam espaço, mas não têm impacto nas vendas?
Qual é o valor para o negócio
O módulo foi criado para lojas que querem otimizar merchandising, conteúdo e layout da página com base no impacto real nas vendas, e não apenas com base no tráfego ou no CTR.
A partir dos relatórios, é possível avaliar:
- receita por area,
- número de encomendas por area,
- eficácia de objetos concretos dentro de uma determinada area,
- eficácia da relação produto -> produto clicado -> SKU comprado,
- impacto do blog nas vendas,
- impacto do primeiro clique, último clique, contribuição assistida e view-through,
- percursos de origem que conduzem à compra.
O que distingue este módulo de simples analytics pixel
1. Mede vendas, e não apenas visualizações e cliques
Um clique, por si só, ainda não diz nada sobre o valor para o negócio. Kowal Analytics liga eventos de frontend ao carrinho, à encomenda e à receita.
2. Trabalha com o conceito de area
A unidade básica de análise é a area, ou seja, uma zona definida da página que pretende medir.
Exemplos:
related_productsno PDP,upsell_productsno PDP,crosssell_productsno carrinho,category_listingna listagem de produtos da categoria,search_resultsnos resultados de pesquisa,wishlist_products,compare_products,blog_post_listing,blog_sidebar_categories,- uma caixa promocional própria no CMS.
3. Também permite analisar object
Em cada area existem object concretos, ou seja, elementos que o utilizador vê e clica.
Exemplos:
- produto na secção
related_products, - artigo do blog na lista de artigos,
- categoria do blog na sidebar,
- banner promocional,
- link CTA numa caixa de marketing.
Isto significa que o relatório não termina ao nível de:
- secção related funciona
mas desce ao nível de:
- produto X na secção related vende melhor
- artigo de blog Y conduz ao maior número de encomendas
4. Conhece o contexto de origem
O módulo também guarda o contexto de origem, ou seja, onde começou o percurso.
Exemplo:
- o utilizador está na página de produto
Affirm Water Bottle, - vê
related_products, - clica em
Zing Jump Rope, - vai para o PDP desse produto,
- adiciona-o ao carrinho,
- e finalmente compra
Zing Jump Rope.
Neste caso, é possível mostrar:
source page=Affirm Water Bottle,area=related_products,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope.
Este é exatamente o nível de análise que normalmente falta nas ferramentas típicas.
Como entender os conceitos mais importantes
Area
Area é a secção ou bloco da página que pretende medir como fonte de influência nas vendas.
Exemplos:
- secção de produtos relacionados,
- listagem de categorias,
- widget do blog,
- sidebar do blog,
- banner promocional,
- popup,
- bloco CMS personalizado.
Object
Object é um elemento concreto dentro de area.
Exemplos:
- um produto na lista,
- um artigo do blog,
- uma categoria do blog,
- uma tag,
- um slide no slider,
- um banner na secção promocional.
Source Page
Source Page é a página a partir da qual o utilizador iniciou o percurso relacionado com uma determinada area.
Exemplos:
- página do produto de origem para
related_products, - artigo do blog para um link que conduz ao produto,
- listagem de categorias para o clique num produto,
- resultados de pesquisa para o produto clicado.
Purchased SKU
É o SKU concreto que foi comprado e ao qual atribuímos a influência dessa area ou object.
Que áreas podem ser medidas
O módulo suporta tanto integrações nativas como áreas definidas por seletores.
Exemplos em e-commerce
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_products
Exemplos em content commerce
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Exemplos personalizados
homepage_promo_boxblack_friday_bannersummer_campaign_sliderai_recommendationscategory_top_cta
Que relatórios o utilizador recebe
Analytics Dashboard
Serve para uma consulta rápida dos resultados.
Mostra, entre outros:
- attributed revenue,
- attributed orders,
- CTR,
- top areas,
- top supported products,
- top blog sources.
Area Report
Responde à pergunta:
- que área funciona,
- que objetos nela vendem,
- de que origens resulta a venda.
Exemplo:
related_productsgera 12 encomendas e 4 800 PLN de receita,- o produto que vende melhor é
WB05-S-Orange, - a origem mais frequente deste percurso é o produto
Affirm Water Bottle.
Product Context Report
Este relatório é fundamental para áreas de produto.
Responde à pergunta:
- a partir de que produto de origem,
- foi clicado que produto,
- e o que foi finalmente comprado.
Exemplo:
source product=Affirm Water Bottle,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope,orders= 7,revenue= 840 PLN.
Blog Commerce Report
Mostra o impacto do blog nas vendas.
Responde às perguntas:
- que artigo vende,
- que categoria do blog vende,
- que tag conduz a encomendas,
- que SKU são comprados após a entrada pelo blog.
Exemplo:
- o artigo
Como escolher uma garrafa de treinogerou 9 encomendas, - o SKU mais frequentemente comprado após esse artigo é
Affirm Water Bottle.
Object Report
Permite entrar num único objeto concreto.
Exemplo:
- um produto específico em
related_products, - um artigo específico do blog em
blog_post_listing, - uma categoria específica do blog na sidebar.
O relatório mostra:
- cliques,
- encomendas,
- receita,
- páginas de origem,
- SKU comprados relacionados com esse único objeto.
Source Page Report
É um relatório de perspetiva inversa.
Em vez de olhar para o objeto, olha para uma única página de origem e verifica:
- que objetos clicados dessa página vendem,
- que SKU são comprados posteriormente,
- que receita foi gerada por essa página concreta como ponto de partida do percurso.
Exemplo:
- página do produto
Affirm Water Bottlecomo source page, - os objetos que mais vendem a partir dessa página são dois produtos de
related_products, - a receita total deste percurso é 1 350 PLN.
Cenários de utilização típicos
Otimização de merchandising
A loja pode comparar se:
related_productsvende melhor do queupsell_products,- o cross-sell no carrinho realmente ajuda a fechar a venda,
- a listagem de categorias direciona para produtos que de facto terminam em encomenda.
Análise do blog
A equipa de conteúdos pode verificar:
- que artigos conduzem ao PDP,
- que artigos ajudam a adicionar o produto ao carrinho,
- que artigos têm impacto real nas vendas.
Limpeza do layout da loja
Se uma secção tiver muitas impressões e impacto baixo ou nulo na receita, é possível avaliar se:
- é preciso melhorá-la,
- movê-la,
- substituir o seu conteúdo,
- ou removê-la completamente.
Teste de alterações
Depois de alterar o layout, widget, blog ou mecanismo de recomendações, pode comparar:
- o período anterior e o posterior,
- o impacto no CTR,
- o impacto nas encomendas,
- o impacto na receita.
Para quem é este módulo
Quem mais valor retirará dele:
- proprietários de lojas Magento,
- gestores de e-commerce,
- merchandisers,
- equipas de CRO,
- equipas de conteúdo e SEO,
- agências que desenvolvem lojas Magento.
Resumo
Kowal Analytics transforma elementos do storefront em fontes mensuráveis de vendas.
Permite passar da pergunta geral:
- este bloco funciona?
para a pergunta concreta:
- que produto, artigo, categoria ou página de origem gera vendas e que receita está associada a isso?
Instruções de instalação do Kowal Analytics
Requisitos
Antes da instalação, certifique-se de que:
- a instância Magento 2 está a funcionar corretamente,
- o Composer tem acesso ao repositório de pacotes Kowal,
- tem acesso CLI a
bin/magento, - é possível executar cron e queue consumers no ambiente,
- o ambiente permite corretamente gravações na base de dados e em
var/log.
Instalação via Composer
Adicione o repositório Composer:
composer config repositories.kowal composer https://repo.kowal.storeAdicione os dados de acesso ao repositório privado:
composer config http-basic.repo.kowal.store Instale o módulo:
composer require kowal/module-analyticsAtivação do módulo
Execute os comandos padrão do Magento:
bin/magento module:enable Kowal_Analyticsbin/magento setup:upgradebin/magento cache:flushSe a loja estiver em production mode, execute também:
bin/magento setup:di:compilebin/magento setup:static-content:deploy -fbin/magento cache:flushArranque dos processos assíncronos
O módulo utiliza filas e processamento assíncrono. Sem isso, o dashboard e os relatórios não estarão completos.
Inicie os consumers necessários:
bin/magento queue:consumers:start kowal_analytics.raw_eventsbin/magento queue:consumers:start kowal_analytics.conversionbin/magento queue:consumers:start kowal_analytics.attributionO Magento cron também tem de funcionar corretamente, porque o módulo utiliza retry e backfill para a atribuição.
Verificação básica:
bin/magento cron:runO que acontece após a instalação
Após uma instalação correta, o módulo:
- carrega o tracker no storefront,
- guarda eventos de frontend,
- associa a sessão analytics ao
quote, - transfere os identificadores analytics para
sales_order, - guarda conversões e itens de conversão,
- calcula a atribuição das encomendas a area e object,
- disponibiliza o dashboard e relatórios detalhados no painel do Magento.
Onde verificar se o módulo está a funcionar
Após a instalação, verifique:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Se o módulo estiver corretamente ativo, deverá ver:
- o dashboard do módulo,
- o widget de resumo no dashboard nativo do Magento,
- a secção de configuração em Stores -> Configuration.
Teste técnico recomendado após a implementação
Execute um teste end-to-end simples:
- Abra a página da loja.
- Entre na página de produto.
- Clique num elemento monitorizado, por exemplo, um produto em
related_productsou um artigo do blog. - Adicione o produto ao carrinho.
- Faça uma encomenda.
- Verifique se os eventos, conversões e a atribuição foram guardados.
Se o debug estiver ativado, verifique:
- os logs na consola do navegador,
var/log/kowal_analytics_debug.log
O que vale a pena verificar no HTML
Se quiser confirmar que o tracking funciona no render da página, verifique a presença dos atributos:
data-kowal-track-areadata-kowal-track-area-iddata-kowal-track-objectdata-kowal-track-iddata-kowal-track-sku
Exemplo:
- o contentor da secção
related_productsdeve terdata-kowal-track-area='related_products' - um produto individual nessa secção deve ter
data-kowal-track-object='product'e o seu própriodata-kowal-track-id
Problemas típicos após a instalação
O dashboard está visível, mas não há dados
Verifique:
- se os consumers estão a funcionar,
- se o cron está a funcionar,
- se o analytics está ativado na configuração,
- se o tracker está a carregar no frontend,
- se existem realmente areas monitorizadas na página.
Os eventos são guardados, mas a atribuição está incompleta
Verifique:
- se o consumer
kowal_analytics.attributionestá a funcionar, - se o cron retry está a funcionar,
- se os eventos de origem chegam à base de dados antes do cálculo final da atribuição.
A custom area não aparece nos relatórios
Verifique:
- se a definição da area foi guardada corretamente,
- se os seletores correspondem ao DOM real,
- se o runtime apply adiciona
data-kowal-track-*, - se essa área tem os identificadores de objetos necessários para análise posterior.
Recomendação de implementação
A ordem mais segura é a seguinte:
- instalar o módulo,
- iniciar os consumers e o cron,
- ativar o debug,
- testar um cenário simples de produto,
- verificar o dashboard,
- só depois expandir o tracking para custom area.
Instruções de configuração do Kowal Analytics
Navegação no painel de administração
Principais pontos de acesso ao módulo:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Estrutura da configuração
Atualmente, o módulo disponibiliza três grupos principais de definições.
1. General
Caminho:
Stores -> Configuration -> Analytics -> General
Campo:
Enable Analytics
Significado:
- ativa ou desativa o tracking de frontend e o processamento posterior de analytics para o scope selecionado.
Recomendação:
- o ideal é ativar por
store viewapós validação prévia do funcionamento dos trackers e consumers.
2. Debug
Caminho:
Stores -> Configuration -> Analytics -> Debug
Campos:
Enable Backend Debug LogEnable Frontend Console Log
Significado:
- o backend debug grava logs técnicos em:
var/log/kowal_analytics_debug.log
- o frontend debug grava logs do tracker na consola do navegador.
Utilização:
- instalação,
- QA,
- análise de erros,
- testes do selector assistant,
- confirmação de que os eventos chegam ao pipeline.
Recomendação:
- ativar durante a implementação e os testes,
- desativar no ambiente de produção após concluir a validação.
3. Tools
Caminho:
Stores -> Configuration -> Analytics -> Tools
Campo:
Enable Frontend Selector Assistant
Significado:
- mostra um helper no storefront que ajuda a indicar e preparar a configuração de areas próprias baseadas em seletores.
Utilização:
- mapeamento de secções personalizadas,
- análise da estrutura DOM,
- preparação da definição de area sem edição manual de código.
Como entender a configuração na prática
Scope
O módulo funciona no scope do Magento, pelo que a configuração pode ser diferente para:
default,website,store view.
O mais seguro é tratar o módulo como uma ferramenta por store view, porque:
- lojas diferentes podem ter layouts diferentes,
- lojas diferentes podem ter secções de blog, CMS e merchandising diferentes,
- os relatórios por store view são muito mais fiáveis do ponto de vista operacional.
Como entender os conceitos básicos no módulo
Area
Area é uma zona definida da página que pretende medir como fonte de influência nas vendas.
Exemplos:
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_productsblog_post_listingblog_sidebar_categorieshomepage_promo_box
Object
Object é um elemento concreto dentro da area.
Exemplos:
- um produto individual na lista,
- um artigo do blog,
- uma categoria do blog,
- uma tag,
- um banner,
- um slide.
Source Page
Source Page é a página a partir da qual o utilizador iniciou a interação que posteriormente levou à venda.
Exemplos:
- página do produto de origem para
related_products, - artigo do blog para o produto clicado,
- listagem de categorias para o produto clicado,
- resultados de pesquisa para o produto.
Dashboard e relatórios
Analytics Dashboard
Este é o ecrã principal de visão geral. Mostra:
- attributed revenue,
- attributed orders,
- average order value,
- CTR,
- top areas,
- top supported products,
- top blog sources,
- ligações para relatórios detalhados.
Este ecrã responde à pergunta:
o que funciona melhor
Area Report
Este relatório responde às perguntas:
- que area gera receita,
- que object nessa area vendem,
- de que source page vem a venda.
Exemplo:
related_productstem 18 encomendas,- o que mais vende nela é
Zing Jump Rope, - a origem mais frequente deste percurso é a página do produto
Affirm Water Bottle.
Product Context Report
Este é o relatório para áreas de produto como:
related_productsupsell_productscrosssell_productscategory_listingsearch_results
Mostra a relação:
source product -> clicked object -> purchased SKU
Exemplo:
- o utilizador está no PDP
Affirm Water Bottle, - clica em
WB05-S-Orangeemrelated_products, - compra
WB05-S-Orange.
Blog Commerce Report
Este é o relatório para áreas de blog:
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Responde às perguntas:
- que post vende,
- que categoria do blog vende,
- que tag apoia a venda,
- que SKU são comprados após a entrada pelo blog.
Object Report
Este é o relatório para um único object concreto.
Exemplo:
- um produto em
related_products, - um artigo do blog de
blog_post_listing, - uma categoria do blog de
blog_sidebar_categories.
Mostra:
- quantas impressões teve,
- quantos cliques teve,
- quantas encomendas gerou,
- que receita lhe foi atribuída,
- de que source page vieram esses percursos.
Source Page Report
Este é o relatório para uma única página de origem concreta.
Exemplo:
- página do produto
Affirm Water Bottle, - artigo do blog
Como escolher uma garrafa de treino, - listagem da categoria
Sapatos de corrida.
Mostra:
- que clicked object dessa página vendem,
- que SKU são comprados após a entrada por essa página,
- quantas encomendas e quanta receita essa página concreta gera como ponto de partida do percurso.
Modelos de atribuição
Modelos disponíveis:
Last ClickFirst ClickAssistedView Through
Como interpretá-los:
Last Click
O melhor para responder à pergunta:
- que elemento fechou diretamente a venda.
First Click
O melhor para responder à pergunta:
- que elemento iniciou o percurso que conduziu à compra.
Assisted
O melhor para responder à pergunta:
- que elemento participou no percurso, mesmo que não tenha sido o último clique.
View Through
O melhor para responder à pergunta:
- se a simples exposição da secção teve impacto na venda, mesmo sem clique.
Configuração de custom area
Pode preparar uma custom area através de Frontend Selector Assistant.
Workflow típico:
- Ative
Enable Frontend Selector Assistant. - Abra o storefront.
- Inicie o assistant.
- Indique a área.
- Verifique o
container selectorproposto. - Verifique o
item selectorproposto. - Verifique o
link selector. - Guarde a definição.
- Confirme que o runtime apply adicionou
data-kowal-track-*. - Teste o clique e a passagem para os relatórios.
Exemplo de custom area
Suponha que na página inicial tem uma caixa promocional com três blocos.
Pode definir:
area_code = homepage_promo_boxobject_type = promotioncontainer_selector = .homepage-promoitem_selector = .homepage-promo__itemlink_selector = .homepage-promo__link
Nesse caso, o relatório mostrará:
- que bloco foi clicado,
- qual conduziu à compra,
- que receita gerou.
Workflow de teste após a configuração
A sequência mais sensata é:
- ativar o analytics,
- ativar o backend debug,
- ativar o frontend console log,
- percorrer um cenário de utilizador,
- verificar o dashboard,
- verificar o relatório de area,
- descer ao object report ou ao source page report,
- desativar o debug após confirmar o funcionamento correto.
Recomendações operacionais
- mantenha os consumers sob supervisor ou systemd,
- garanta que o Magento cron está sempre a funcionar,
- após alterações no tema, verifique se os seletores da custom area continuam a corresponder ao DOM,
- após alterações de merchandising, compare os resultados por area,
- não interprete apenas o CTR como sucesso sem verificar a receita e as encomendas.
























