Kowal Analytics for Magento 2
What is this module
Kowal Analytics is a sales attribution module for Magento 2. Its purpose is to show which store elements actually affect the cart, order, and revenue.
This is not a regular pixel that collects page views. The module analyzes the full sales context:
- which area was displayed,
- which object in that area was clicked,
- from which page or product the user started the interaction,
- which product was added to the cart,
- which SKU was ultimately purchased,
- which revenue should be attributed to that path.
Thanks to this, the store can answer questions that standard analytics usually do not answer:
- Which
related productssections actually sell? - Which
upsellandcross-sellblocks generate revenue? - Which blog posts lead to product sales?
- Which banners, widgets, or CMS sections are only clicked but do not convert?
- Which page elements take up space but have no impact on sales?
What is the business value
The module was created for stores that want to optimize merchandising, content, and page layout based on real impact on sales, not just traffic or CTR.
From the reports, you can evaluate:
- revenue per area,
- number of orders per area,
- performance of specific objects within a given area,
- performance of the relationship product -> clicked product -> purchased SKU,
- the blog's impact on sales,
- the impact of first click, last click, assisted share, and view-through,
- source paths leading to a purchase.
What makes this module different from simple analytics pixel solutions
1. It measures sales, not just views and clicks
A click alone says nothing about business value. Kowal Analytics connects frontend events with the cart, order, and revenue.
2. It works with the concept of area
The basic unit of analysis is an area, meaning a defined part of the page that you want to measure.
Examples:
related_productson PDP,upsell_productson PDP,crosssell_productsin the cart,category_listingon the category product list,search_resultson search results pages,wishlist_products,compare_products,blog_post_listing,blog_sidebar_categories,- a custom promotional box in CMS.
3. It also lets you analyze object
Each area contains specific object items, meaning the elements the user sees and clicks.
Examples:
- a product in the
related_productssection, - a blog post in a post list,
- a blog category in the sidebar,
- a promotional banner,
- a CTA link in a marketing box.
This means the report does not stop at the level of:
- the related section works
but goes down to the level of:
- product X in the related section sells best
- blog post Y leads to the highest number of orders
4. It knows the source context
The module also stores the source context, meaning where the path started.
Example:
- the user is on the
Affirm Water Bottleproduct page, - sees
related_products, - clicks
Zing Jump Rope, - goes to that product's PDP,
- adds it to the cart,
- and ultimately purchases
Zing Jump Rope.
In that case, you can show:
source page=Affirm Water Bottle,area=related_products,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope.
This is exactly the level of analysis that is usually missing in typical tools.
How to understand the most important concepts
Area
Area is a section or block of the page that you want to measure as a source of sales impact.
Examples:
- a related products section,
- a category listing,
- a blog widget,
- a blog sidebar,
- a promotional banner,
- a popup,
- a custom CMS block.
Object
Object is a specific element inside an area.
Examples:
- a single product in a list,
- a single blog post,
- a single blog category,
- a single tag,
- a single slide in a slider,
- a single banner in a promotional section.
Source Page
Source Page is the page from which the user started the path related to a given area.
Examples:
- the source product page for
related_products, - a blog post for a link leading to a product,
- a category listing for a product click,
- search results for a clicked product.
Purchased SKU
This is the specific SKU that was purchased and to which we attribute the impact of a given area or object.
Which areas can be measured
The module supports both native integrations and areas defined by selectors.
Examples in e-commerce
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_products
Examples in content commerce
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Custom examples
homepage_promo_boxblack_friday_bannersummer_campaign_sliderai_recommendationscategory_top_cta
Which reports the user gets
Analytics Dashboard
Used for a quick results overview.
It shows, among other things:
- attributed revenue,
- attributed orders,
- CTR,
- top areas,
- top supported products,
- top blog sources.
Area Report
Answers the question:
- which area works,
- which objects in it sell,
- which sources generate sales.
Example:
related_productsgenerates 12 orders and 4 800 PLN in revenue,- the best-selling product is
WB05-S-Orange, - the most common source for this path is the
Affirm Water Bottleproduct.
Product Context Report
This report is key for product areas.
It answers the question:
- from which source product,
- which product was clicked,
- and what was ultimately purchased.
Example:
source product=Affirm Water Bottle,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope,orders= 7,revenue= 840 PLN.
Blog Commerce Report
Shows the blog's impact on sales.
It answers the questions:
- which post sells,
- which blog category sells,
- which tag leads to orders,
- which SKU items are purchased after entering from the blog.
Example:
- the post
How to choose a training water bottlegenerated 9 orders, - the most frequently purchased SKU after that post is
Affirm Water Bottle.
Object Report
Lets you drill down into one specific object.
Example:
- one specific product in
related_products, - one specific blog post in
blog_post_listing, - one specific blog category in the sidebar.
The report shows:
- clicks,
- orders,
- revenue,
- source pages,
- purchased SKU items related to that one object.
Source Page Report
This is a reverse-perspective report.
Instead of looking at the object, you look at one source page and check:
- which clicked objects from that page sell,
- which SKU items are later purchased,
- how much revenue that specific page generated as the starting point of the path.
Example:
- the
Affirm Water Bottleproduct page as the source page, - the best-selling objects from that page are two products from
related_products, - the total revenue from that path is 1 350 PLN.
Typical use cases
Merchandising optimization
The store can compare whether:
related_productssells better thanupsell_products,- cross-sell in the cart really closes sales,
- the category listing leads users to products that actually end in an order.
Blog analysis
The content team can check:
- which posts lead to PDP,
- which posts help add a product to the cart,
- which posts have a real impact on sales.
Store layout cleanup
If a section has high impressions and low or zero impact on revenue, you can assess whether it should:
- be improved,
- be moved,
- have its content replaced,
- or be removed completely.
Testing changes
After changing the layout, widget, blog, or recommendation mechanism, you can compare:
- the earlier and later period,
- the impact on CTR,
- the impact on orders,
- the impact on revenue.
Who this module is for
It provides the most value to:
- Magento store owners,
- e-commerce managers,
- merchandisers,
- CRO teams,
- content and SEO teams,
- agencies developing Magento stores.
Summary
Kowal Analytics turns storefront elements into measurable sales sources.
It lets you move from the general question:
- does this block work?
to the specific question:
- which exact product, post, category, or source page generates sales and how much revenue stands behind it?
Kowal Analytics Installation Guide
Requirements
Before installation, make sure that:
- the Magento 2 instance is running correctly,
- Composer has access to the Kowal package repository,
- you have CLI access to
bin/magento, - cron and queue consumers can run in the environment,
- the environment can correctly write to the database and to
var/log.
Installation via Composer
Add the Composer repository:
composer config repositories.kowal composer https://repo.kowal.storeAdd credentials for the private repository:
composer config http-basic.repo.kowal.store Install the module:
composer require kowal/module-analyticsEnabling the module
Run the standard Magento commands:
bin/magento module:enable Kowal_Analyticsbin/magento setup:upgradebin/magento cache:flushIf the store runs in production mode, also execute:
bin/magento setup:di:compilebin/magento setup:static-content:deploy -fbin/magento cache:flushStarting asynchronous processes
The module uses queues and asynchronous processing. Without them, the dashboard and reports will not be complete.
Start the required consumers:
bin/magento queue:consumers:start kowal_analytics.raw_eventsbin/magento queue:consumers:start kowal_analytics.conversionbin/magento queue:consumers:start kowal_analytics.attributionMagento cron must also work correctly because the module uses retry and backfill for attribution.
Basic check:
bin/magento cron:runWhat happens after installation
After correct installation, the module:
- loads the tracker on the storefront,
- saves frontend events,
- binds the analytics session to the
quote, - transfers analytics identifiers to
sales_order, - saves conversions and conversion items,
- calculates order attribution for area and object,
- provides a dashboard and detailed reports in the Magento admin panel.
Where to check if the module works
After installation, check:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
If the module is active correctly, you should see:
- the module dashboard,
- a summary widget on the native Magento dashboard,
- a configuration section in Stores -> Configuration.
Recommended technical test after deployment
Perform a simple end-to-end test:
- Open the store page.
- Go to a product page.
- Click a tracked element, for example a product in
related_productsor a blog post. - Add the product to the cart.
- Place an order.
- Check whether events, conversions, and attribution were saved.
If debug is enabled, check:
- logs in the browser console,
var/log/kowal_analytics_debug.log
What is worth checking in HTML
If you want to confirm that tracking works on page render, check for the presence of these attributes:
data-kowal-track-areadata-kowal-track-area-iddata-kowal-track-objectdata-kowal-track-iddata-kowal-track-sku
Example:
- the
related_productssection container should havedata-kowal-track-area='related_products' - a single product in that section should have
data-kowal-track-object='product'and its owndata-kowal-track-id
Common issues after installation
The dashboard is visible, but there is no data
Check:
- whether consumers are running,
- whether cron is running,
- whether analytics is enabled in the configuration,
- whether the tracker loads on the frontend,
- whether there are actually tracked areas on the page.
Events are being saved, but attribution is incomplete
Check:
- whether the
kowal_analytics.attributionconsumer is running, - whether cron retry is working,
- whether source events reach the database before the final attribution calculation.
Custom area does not appear in reports
Check:
- whether the area definition was saved correctly,
- whether the selectors match the real DOM,
- whether runtime apply adds
data-kowal-track-*, - whether the given area has object identifiers needed for further analysis.
Deployment recommendation
The safest order is:
- install the module,
- start consumers and cron,
- enable debug,
- test one simple product scenario,
- check the dashboard,
- only then extend tracking to custom areas.
Kowal Analytics Configuration Guide
Navigation in the admin panel
Main entry points to the module:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Configuration structure
Currently, the module provides three main groups of settings.
1. General
Path:
Stores -> Configuration -> Analytics -> General
Field:
Enable Analytics
Meaning:
- enables or disables frontend tracking and further analytics processing for the selected scope.
Recommendation:
- it is best to enable it per
store viewafter verifying that trackers and consumers are working correctly.
2. Debug
Path:
Stores -> Configuration -> Analytics -> Debug
Fields:
Enable Backend Debug LogEnable Frontend Console Log
Meaning:
- backend debug saves technical logs to:
var/log/kowal_analytics_debug.log
- frontend debug saves tracker logs to the browser console.
Use cases:
- installation,
- QA,
- error analysis,
- selector assistant tests,
- confirmation that events reach the pipeline.
Recommendation:
- enable it during deployment and testing,
- disable it in the production environment after validation is completed.
3. Tools
Path:
Stores -> Configuration -> Analytics -> Tools
Field:
Enable Frontend Selector Assistant
Meaning:
- shows a helper on the storefront that helps indicate and prepare configuration for custom selector-based areas.
Use cases:
- custom section mapping,
- DOM structure analysis,
- preparing area definitions without manual code editing.
How to understand the configuration in practice
Scope
The module works within Magento scope, so the configuration can differ for:
default,website,store view.
It is safest to treat the module as a per-store-view tool because:
- different stores may have a different layout,
- different stores may have different blog, CMS, and merchandising sections,
- per-store-view reports are much more reliable operationally.
How to understand the basic concepts in the module
Area
Area is a defined part of the page that you want to measure as a source of sales impact.
Examples:
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_productsblog_post_listingblog_sidebar_categorieshomepage_promo_box
Object
Object is a specific element inside an area.
Examples:
- a single product in a list,
- a single blog post,
- a single blog category,
- a single tag,
- a single banner,
- a single slide.
Source Page
Source Page is the page from which the user started an interaction that later led to a sale.
Examples:
- the source product page for
related_products, - a blog post for a clicked product,
- a category listing for a clicked product,
- search results for a product.
Dashboard and reports
Analytics Dashboard
This is the main overview screen. It shows:
- attributed revenue,
- attributed orders,
- average order value,
- CTR,
- top areas,
- top supported products,
- top blog sources,
- links to detailed reports.
This screen answers the question:
what works best
Area Report
This report answers the questions:
- which area generates revenue,
- which objects in that area sell,
- which source page drives sales.
Example:
related_productshas 18 orders,Zing Jump Ropesells best there,- the most common source for that path is the
Affirm Water Bottleproduct page.
Product Context Report
This is a report for product areas such as:
related_productsupsell_productscrosssell_productscategory_listingsearch_results
It shows the relationship:
source product -> clicked object -> purchased SKU
Example:
- the user is on the PDP of
Affirm Water Bottle, - clicks
WB05-S-Orangeinrelated_products, - and buys
WB05-S-Orange.
Blog Commerce Report
This is a report for blog areas:
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
It answers the questions:
- which post sells,
- which blog category sells,
- which tag supports sales,
- which SKU items are purchased after entering from the blog.
Object Report
This is a report for one specific object.
Example:
- one product in
related_products, - one blog post from
blog_post_listing, - one blog category from
blog_sidebar_categories.
It shows:
- how many impressions it had,
- how many clicks it had,
- how many orders it generated,
- what revenue was attributed to it,
- which source pages those paths came from.
Source Page Report
This is a report for one specific source page.
Example:
- the
Affirm Water Bottleproduct page, - the blog post
How to choose a training water bottle, - the
Running Shoescategory listing.
It shows:
- which clicked objects from that page sell,
- which SKU items are purchased after entering from that page,
- how many orders and how much revenue that specific page generates as the starting point of the path.
Attribution models
Available models:
Last ClickFirst ClickAssistedView Through
How to read them:
Last Click
Best for the question:
- which element directly closed the sale.
First Click
Best for the question:
- which element started the path leading to a purchase.
Assisted
Best for the question:
- which element participated in the path, even if it was not the last click.
View Through
Best for the question:
- whether the section exposure itself had an impact on sales, even without a click.
Custom area configuration
You can prepare a custom area through the Frontend Selector Assistant.
Typical workflow:
- Enable
Enable Frontend Selector Assistant. - Open the storefront.
- Launch the assistant.
- Select the area.
- Check the suggested
container selector. - Check the suggested
item selector. - Check the
link selector. - Save the definition.
- Confirm that runtime apply added
data-kowal-track-*. - Test the click and the path to reports.
Custom area example
Assume you have a promotional box with three tiles on the homepage.
You can define:
area_code = homepage_promo_boxobject_type = promotioncontainer_selector = .homepage-promoitem_selector = .homepage-promo__itemlink_selector = .homepage-promo__link
Then the report will show:
- which tile was clicked,
- which one led to a purchase,
- how much revenue it generated.
Testing workflow after configuration
The most sensible sequence:
- enable analytics,
- enable backend debug,
- enable frontend console log,
- go through a user scenario,
- check the dashboard,
- check the area report,
- drill down to the object report or source page report,
- disable debug after confirming correctness.
Operational recommendations
- keep consumers under supervisor or systemd,
- make sure Magento cron runs continuously,
- after theme changes, check whether custom area selectors still match the DOM,
- after merchandising changes, compare results per area,
- do not treat CTR alone as success without checking revenue and orders.
























