Kowal Analytics para Magento 2
Qué es este módulo
Kowal Analytics es un módulo de atribución de ventas para Magento 2. Su función es mostrar qué elementos de la tienda influyen realmente en el carrito, el pedido y los ingresos.
No es un simple pixel que recopila vistas de página. El módulo analiza el contexto completo de ventas:
- qué área se ha mostrado,
- qué objeto dentro de esa área ha sido clicado,
- desde qué página o desde qué producto el usuario ha interactuado,
- qué producto se ha añadido al carrito,
- qué SKU se ha comprado finalmente,
- qué ingresos deben atribuirse a ese recorrido.
Gracias a ello, la tienda puede responder a preguntas a las que las analíticas estándar normalmente no responden:
- ¿Qué secciones de
related productsrealmente venden? - ¿Qué bloques de
upsellycross-sellgeneran ingresos? - ¿Qué entradas del blog conducen a la venta de productos?
- ¿Qué banners, widgets o secciones CMS solo reciben clics, pero no convierten?
- ¿Qué elementos de la página ocupan espacio, pero no influyen en las ventas?
Cuál es el valor de negocio
El módulo se ha creado para tiendas que quieren optimizar el merchandising, el contenido y la estructura de la página basándose en el impacto real sobre las ventas, y no solo en el tráfico o el CTR.
Desde los informes se puede evaluar:
- ingresos por area,
- número de pedidos por area,
- eficacia de objetos concretos dentro de una area determinada,
- eficacia de la relación producto -> producto clicado -> SKU comprado,
- impacto del blog en las ventas,
- impacto del primer clic, último clic, contribución asistida y view-through,
- recorridos de origen que conducen a la compra.
Qué diferencia a este módulo de los analytics pixel sencillos
1. Mide las ventas, no solo las visualizaciones y los clics
Un clic por sí solo aún no dice nada sobre el valor de negocio. Kowal Analytics conecta los eventos frontend con el carrito, el pedido y los ingresos.
2. Trabaja con el concepto de area
La unidad básica de análisis es area, es decir, una zona concreta de la página que quieres medir.
Ejemplos:
related_productsen la PDP,upsell_productsen la PDP,crosssell_productsen el carrito,category_listingen el listado de productos de categoría,search_resultsen los resultados de búsqueda,wishlist_products,compare_products,blog_post_listing,blog_sidebar_categories,- tu propia caja promocional en CMS.
3. También permite analizar object
En cada area hay object concretos, es decir, elementos que el usuario ve y en los que hace clic.
Ejemplos:
- producto en la sección
related_products, - entrada de blog en la lista de entradas,
- categoría del blog en la barra lateral,
- banner promocional,
- enlace CTA en una caja de marketing.
Esto significa que el informe no se queda en el nivel de:
- la sección related funciona
sino que baja al nivel de:
- el producto X en la sección related es el que mejor vende
- la entrada del blog Y conduce al mayor número de pedidos
4. Conoce el contexto de origen
El módulo también registra el contexto de origen, es decir, dónde comenzó el recorrido.
Ejemplo:
- el usuario está en la ficha de producto
Affirm Water Bottle, - ve
related_products, - hace clic en
Zing Jump Rope, - va a la PDP de este producto,
- lo añade al carrito,
- y finalmente compra
Zing Jump Rope.
En ese caso se puede mostrar:
source page=Affirm Water Bottle,area=related_products,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope.
Ese es exactamente el nivel de análisis que normalmente falta en las herramientas típicas.
Cómo entender los conceptos más importantes
Area
Area es una sección o bloque de la página que quieres medir como fuente de influencia en las ventas.
Ejemplos:
- sección de productos relacionados,
- listado de categorías,
- widget de blog,
- barra lateral del blog,
- banner promocional,
- popup,
- bloque CMS personalizado.
Object
Object es un elemento concreto dentro de una area.
Ejemplos:
- un producto en una lista,
- una entrada de blog,
- una categoría de blog,
- una etiqueta,
- una diapositiva en un slider,
- un banner en una sección promocional.
Source Page
Source Page es la página desde la que el usuario inició el recorrido relacionado con una area determinada.
Ejemplos:
- la ficha del producto de origen para
related_products, - una entrada del blog para un enlace que lleva al producto,
- un listado de categorías para el clic en un producto,
- los resultados de búsqueda para un producto clicado.
Purchased SKU
Es el SKU concreto que se ha comprado y al que atribuimos la influencia de una area u object determinados.
Qué áreas se pueden medir
El módulo admite tanto integraciones nativas como áreas definidas mediante selectores.
Ejemplos en e-commerce
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_products
Ejemplos en content commerce
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Ejemplos personalizados
homepage_promo_boxblack_friday_bannersummer_campaign_sliderai_recommendationscategory_top_cta
Qué informes recibe el usuario
Analytics Dashboard
Sirve para revisar rápidamente los resultados.
Muestra, entre otras cosas:
- attributed revenue,
- attributed orders,
- CTR,
- top areas,
- top supported products,
- top blog sources.
Area Report
Responde a la pregunta:
- qué área funciona,
- qué objetos dentro de ella venden,
- de qué fuentes proceden las ventas.
Ejemplo:
related_productsaporta 12 pedidos y 4 800 PLN de ingresos,- el producto que mejor vende es
WB05-S-Orange, - la fuente más frecuente de ese recorrido es el producto
Affirm Water Bottle.
Product Context Report
Este informe es clave para las áreas de producto.
Responde a la pregunta:
- desde qué producto de origen,
- se hizo clic en qué producto,
- y qué se compró finalmente.
Ejemplo:
source product=Affirm Water Bottle,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope,orders= 7,revenue= 840 PLN.
Blog Commerce Report
Muestra el impacto del blog en las ventas.
Responde a preguntas como:
- qué entrada vende,
- qué categoría del blog vende,
- qué etiqueta conduce a pedidos,
- qué SKU se compran después de entrar desde el blog.
Ejemplo:
- la entrada
Jak wybrać bidon treningowygeneró 9 pedidos, - el SKU comprado con más frecuencia tras esa entrada es
Affirm Water Bottle.
Object Report
Permite profundizar en un objeto concreto.
Ejemplo:
- un producto concreto en
related_products, - una entrada concreta del blog en
blog_post_listing, - una categoría concreta del blog en la barra lateral.
El informe muestra:
- clics,
- pedidos,
- ingresos,
- páginas de origen,
- SKU comprados relacionados con ese único objeto.
Source Page Report
Es un informe desde la perspectiva inversa.
En lugar de mirar el objeto, miras una única página de origen y compruebas:
- qué objetos clicados desde esa página venden,
- qué SKU se compran después,
- qué ingresos ha generado esa página concreta como punto de inicio del recorrido.
Ejemplo:
- la ficha de producto
Affirm Water Bottlecomo source page, - los objetos que mejor venden desde esa página son dos productos de
related_products, - los ingresos totales de ese recorrido son 1 350 PLN.
Casos de uso habituales
Optimización del merchandising
La tienda puede comparar si:
related_productsvende mejor queupsell_products,- el cross-sell en el carrito realmente ayuda a cerrar la venta,
- el listado de categorías dirige a productos que realmente terminan en pedido.
Análisis del blog
El equipo de contenidos puede comprobar:
- qué entradas llevan a la PDP,
- qué entradas ayudan a añadir un producto al carrito,
- qué entradas tienen un impacto real en las ventas.
Limpieza del layout de la tienda
Si una sección tiene muchas impresiones y un impacto bajo o nulo en los ingresos, se puede evaluar si:
- hay que mejorarla,
- moverla,
- cambiar su contenido,
- o eliminarla por completo.
Prueba de cambios
Después de cambiar el layout, un widget, el blog o el mecanismo de recomendaciones, puedes comparar:
- el periodo anterior y posterior,
- el impacto en el CTR,
- el impacto en los pedidos,
- el impacto en los ingresos.
Para quién es este módulo
Quienes más valor obtendrán de él son:
- propietarios de tiendas Magento,
- responsables de e-commerce,
- merchandisers,
- equipos de CRO,
- equipos de contenidos y SEO,
- agencias que desarrollan tiendas Magento.
Resumen
Kowal Analytics convierte los elementos del storefront en fuentes de ventas medibles.
Permite pasar de la pregunta general:
- este bloque funciona
a la pregunta concreta:
- qué producto, entrada, categoría o página de origen genera ventas exactamente y qué ingresos hay detrás
Guía de instalación de Kowal Analytics
Requisitos
Antes de la instalación, asegúrate de que:
- la instancia de Magento 2 funciona correctamente,
- Composer tiene acceso al repositorio de paquetes de Kowal,
- tienes acceso CLI a
bin/magento, - en el entorno se pueden ejecutar cron y queue consumers,
- el entorno tiene correctamente operativas las escrituras en la base de datos y en
var/log.
Instalación mediante Composer
Añade el repositorio de Composer:
composer config repositories.kowal composer https://repo.kowal.storeAñade las credenciales del repositorio privado:
composer config http-basic.repo.kowal.store Instala el módulo:
composer require kowal/module-analyticsActivación del módulo
Ejecuta los comandos estándar de Magento:
bin/magento module:enable Kowal_Analyticsbin/magento setup:upgradebin/magento cache:flushSi la tienda funciona en production mode, ejecuta también:
bin/magento setup:di:compilebin/magento setup:static-content:deploy -fbin/magento cache:flushPuesta en marcha de los procesos asíncronos
El módulo utiliza colas y procesamiento asíncrono. Sin ello, el dashboard y los informes no estarán completos.
Ejecuta los consumers necesarios:
bin/magento queue:consumers:start kowal_analytics.raw_eventsbin/magento queue:consumers:start kowal_analytics.conversionbin/magento queue:consumers:start kowal_analytics.attributionEl cron de Magento también debe funcionar correctamente, ya que el módulo utiliza retry y backfill para la atribución.
Comprobación básica:
bin/magento cron:runQué ocurre después de la instalación
Tras una instalación correcta, el módulo:
- carga el tracker en el storefront,
- guarda eventos frontend,
- vincula la sesión de analytics con
quote, - transfiere los identificadores de analytics a
sales_order, - guarda conversiones y líneas de conversión,
- calcula la atribución de pedidos a area y object,
- pone a disposición el dashboard y los informes detallados en el panel de Magento.
Dónde comprobar si el módulo funciona
Después de la instalación, comprueba:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Si el módulo está correctamente activo, deberías ver:
- el dashboard del módulo,
- el widget de resumen en el dashboard nativo de Magento,
- la sección de configuración en Stores -> Configuration.
Prueba técnica recomendada tras la implementación
Realiza una prueba end-to-end sencilla:
- Abre la página de la tienda.
- Entra en la ficha de producto.
- Haz clic en un elemento trackeado, por ejemplo un producto en
related_productso una entrada del blog. - Añade el producto al carrito.
- Realiza el pedido.
- Comprueba si se han guardado los eventos, las conversiones y la atribución.
Si el debug está activado, comprueba:
- los logs en la consola del navegador,
var/log/kowal_analytics_debug.log
Qué conviene comprobar en el HTML
Si quieres confirmar que el tracking funciona en el renderizado de la página, comprueba la presencia de los atributos:
data-kowal-track-areadata-kowal-track-area-iddata-kowal-track-objectdata-kowal-track-iddata-kowal-track-sku
Ejemplo:
- el contenedor de la sección
related_productsdebería tenerdata-kowal-track-area='related_products' - cada producto individual de esa sección debería tener
data-kowal-track-object='product'y su propiodata-kowal-track-id
Problemas habituales tras la instalación
El dashboard es visible, pero no hay datos
Comprueba:
- si los consumers están funcionando,
- si cron funciona,
- si analytics está activado en la configuración,
- si el tracker se carga en el frontend,
- si realmente hay áreas trackeadas en la página.
Los eventos se guardan, pero la atribución está incompleta
Comprueba:
- si funciona el consumer
kowal_analytics.attribution, - si funciona el cron de retry,
- si los eventos de origen llegan a la base de datos antes del recálculo final de la atribución.
La custom area no aparece en los informes
Comprueba:
- si la definición del area se ha guardado correctamente,
- si los selectores coinciden con el DOM real,
- si runtime apply añade
data-kowal-track-*, - si esa área tiene los identificadores de objeto necesarios para el análisis posterior.
Recomendación de implementación
La secuencia más segura es la siguiente:
- instalar el módulo,
- poner en marcha los consumers y cron,
- activar el debug,
- probar un escenario de producto sencillo,
- comprobar el dashboard,
- y solo después ampliar el tracking a custom area.
Guía de configuración de Kowal Analytics
Navegación en el panel de administración
Entradas principales al módulo:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Estructura de configuración
Actualmente, el módulo ofrece tres grupos principales de ajustes.
1. General
Ruta:
Stores -> Configuration -> Analytics -> General
Campo:
Enable Analytics
Significado:
- activa o desactiva el tracking frontend y el posterior procesamiento de analytics para el scope seleccionado.
Recomendación:
- lo mejor es activarlo por
store viewtras verificar antes el funcionamiento de los trackers y consumers.
2. Debug
Ruta:
Stores -> Configuration -> Analytics -> Debug
Campos:
Enable Backend Debug LogEnable Frontend Console Log
Significado:
- backend debug guarda logs técnicos en:
var/log/kowal_analytics_debug.log
- frontend debug guarda logs del tracker en la consola del navegador.
Uso:
- instalación,
- QA,
- análisis de errores,
- pruebas del selector assistant,
- confirmación de que los eventos llegan al pipeline.
Recomendación:
- activarlo durante la implementación y las pruebas,
- desactivarlo en el entorno de producción una vez finalizada la validación.
3. Tools
Ruta:
Stores -> Configuration -> Analytics -> Tools
Campo:
Enable Frontend Selector Assistant
Significado:
- muestra un helper en el storefront que ayuda a indicar y preparar la configuración de áreas propias basadas en selectores.
Uso:
- mapeo de custom section,
- análisis de la estructura del DOM,
- preparación de la definición de area sin editar código manualmente.
Cómo entender la configuración en la práctica
Scope
El módulo funciona dentro del scope de Magento, por lo que la configuración puede ser distinta para:
default,website,store view.
Lo más seguro es tratar el módulo como una herramienta por store view, porque:
- las distintas tiendas pueden tener un layout diferente,
- las distintas tiendas pueden tener secciones diferentes de blog, CMS y merchandising,
- los informes por store view son mucho más fiables a nivel operativo.
Cómo entender los conceptos básicos del módulo
Area
Area es una zona concreta de la página que quieres medir como fuente de influencia en las ventas.
Ejemplos:
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_productsblog_post_listingblog_sidebar_categorieshomepage_promo_box
Object
Object es un elemento concreto dentro de una area.
Ejemplos:
- un producto individual en una lista,
- una entrada de blog,
- una categoría de blog,
- una etiqueta,
- un banner,
- una diapositiva.
Source Page
Source Page es la página desde la que el usuario inició la interacción que posteriormente condujo a una venta.
Ejemplos:
- la ficha del producto de origen para
related_products, - una entrada del blog para un producto clicado,
- un listado de categorías para un producto clicado,
- los resultados de búsqueda para un producto.
Dashboard e informes
Analytics Dashboard
Es la pantalla principal de visión general. Muestra:
- attributed revenue,
- attributed orders,
- average order value,
- CTR,
- top areas,
- top supported products,
- top blog sources,
- enlaces a informes detallados.
Esta pantalla responde a la pregunta:
qué funciona mejor
Area Report
Este informe responde a las preguntas:
- qué area genera ingresos,
- qué object dentro de esa area vende,
- de qué source page proceden las ventas.
Ejemplo:
related_productstiene 18 pedidos,- lo que mejor vende dentro de ella es
Zing Jump Rope, - la fuente más frecuente de ese recorrido es la ficha de producto
Affirm Water Bottle.
Product Context Report
Es el informe para áreas de producto como:
related_productsupsell_productscrosssell_productscategory_listingsearch_results
Muestra la relación:
source product -> clicked object -> purchased SKU
Ejemplo:
- el usuario está en la PDP
Affirm Water Bottle, - hace clic en
WB05-S-Orangeenrelated_products, - compra
WB05-S-Orange.
Blog Commerce Report
Es el informe para áreas del blog:
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Responde a preguntas como:
- qué post vende,
- qué categoría del blog vende,
- qué etiqueta apoya las ventas,
- qué SKU se compran después de entrar desde el blog.
Object Report
Es el informe de un object concreto.
Ejemplo:
- un producto en
related_products, - una entrada de blog en
blog_post_listing, - una categoría del blog en
blog_sidebar_categories.
Muestra:
- cuántas impresiones tuvo,
- cuántos clics tuvo,
- cuántos pedidos generó,
- qué ingresos se le atribuyeron,
- de qué source page procedían esos recorridos.
Source Page Report
Es el informe de una página de origen concreta.
Ejemplo:
- la ficha de producto
Affirm Water Bottle, - la entrada del blog
Jak wybrać bidon treningowy, - el listado de categoría
Buty do biegania.
Muestra:
- qué clicked object de esa página venden,
- qué SKU se compran después de entrar desde esa página,
- cuántos pedidos e ingresos genera esa página concreta como punto de inicio del recorrido.
Modelos de atribución
Modelos disponibles:
Last ClickFirst ClickAssistedView Through
Cómo interpretarlos:
Last Click
El mejor para la pregunta:
- qué elemento cerró directamente la venta.
First Click
El mejor para la pregunta:
- qué elemento inició el recorrido que condujo a la compra.
Assisted
El mejor para la pregunta:
- qué elemento participó en el recorrido, aunque no fuera el último clic.
View Through
El mejor para la pregunta:
- si la mera exposición de la sección tuvo impacto en la venta, incluso sin clic.
Configuración de custom area
Puedes preparar una custom area mediante Frontend Selector Assistant.
Workflow típico:
- Activa
Enable Frontend Selector Assistant. - Abre el storefront.
- Inicia el assistant.
- Selecciona el área.
- Comprueba el
container selectorpropuesto. - Comprueba el
item selectorpropuesto. - Comprueba el
link selector. - Guarda la definición.
- Confirma que runtime apply ha añadido
data-kowal-track-*. - Prueba el clic y el acceso a los informes.
Ejemplo de custom area
Supongamos que en la página de inicio tienes una caja promocional con tres mosaicos.
Puedes definir:
area_code = homepage_promo_boxobject_type = promotioncontainer_selector = .homepage-promoitem_selector = .homepage-promo__itemlink_selector = .homepage-promo__link
Entonces el informe mostrará:
- qué mosaico recibió clics,
- cuál condujo a la compra,
- qué ingresos generó.
Workflow de prueba tras la configuración
La secuencia más lógica es:
- activar analytics,
- activar backend debug,
- activar frontend console log,
- recorrer un escenario de usuario,
- comprobar el dashboard,
- comprobar el informe de area,
- bajar al object report o al source page report,
- desactivar debug tras confirmar el correcto funcionamiento.
Recomendaciones operativas
- mantén los consumers bajo supervisor o systemd,
- asegúrate de que el cron de Magento funciona de forma continua,
- tras cambios en el tema, comprueba si los selectores de custom area siguen ajustándose al DOM,
- tras cambios de merchandising, compara los resultados por area,
- no interpretes el CTR por sí solo como éxito sin comprobar ingresos y pedidos.
























