Kowal Analytics pour Magento 2
Qu’est-ce que ce module
Kowal Analytics est un module d’attribution des ventes pour Magento 2. Sa mission est de montrer quels éléments de la boutique influencent réellement le panier, la commande et le chiffre d’affaires.
Ce n’est pas un simple pixel qui collecte des vues de pages. Le module analyse l’ensemble du contexte de vente :
- quelle zone a été affichée,
- quel objet dans cette zone a été cliqué,
- depuis quelle page ou depuis quel produit l’utilisateur a interagi,
- quel produit a été ajouté au panier,
- quel SKU a finalement été acheté,
- quel chiffre d’affaires doit être attribué à ce parcours.
Grâce à cela, la boutique peut répondre à des questions auxquelles les outils d’analytics standards ne répondent généralement pas :
- Quelles sections
related productsgénèrent réellement des ventes ? - Quels blocs
upselletcross-sellgénèrent du chiffre d’affaires ? - Quels articles de blog mènent à la vente de produits ?
- Quels bannières, widgets ou sections CMS sont seulement cliqués sans convertir ?
- Quels éléments de page occupent de l’espace sans avoir d’impact sur les ventes ?
Quelle est la valeur métier
Le module a été conçu pour les boutiques qui souhaitent optimiser le merchandising, le contenu et la mise en page sur la base de leur impact réel sur les ventes, et non uniquement sur le trafic ou le CTR.
Depuis les rapports, il est possible d’évaluer :
- le chiffre d’affaires par area,
- le nombre de commandes par area,
- l’efficacité d’objets précis au sein d’un area donné,
- l’efficacité de la relation produit -> produit cliqué -> SKU acheté,
- l’impact du blog sur les ventes,
- l’impact du premier clic, du dernier clic, de la contribution assistée et du view-through,
- les parcours source menant à l’achat.
Ce qui distingue ce module des simples analytics pixel
1. Il mesure les ventes, et pas seulement les vues et les clics
Un clic seul ne dit encore rien de la valeur métier. Kowal Analytics relie les événements frontend au panier, à la commande et au chiffre d’affaires.
2. Il s’appuie sur la notion d’area
L’unité d’analyse de base est l’area, c’est-à-dire une zone distincte de la page que vous souhaitez mesurer.
Exemples :
related_productssur une PDP,upsell_productssur une PDP,crosssell_productsdans le panier,category_listingsur la liste des produits de catégorie,search_resultssur les résultats de recherche,wishlist_products,compare_products,blog_post_listing,blog_sidebar_categories,- votre propre box promotionnelle dans le CMS.
3. Il permet aussi d’analyser l’object
Dans chaque area se trouvent des object précis, c’est-à-dire les éléments que l’utilisateur voit et clique.
Exemples :
- un produit dans la section
related_products, - un article de blog dans une liste d’articles,
- une catégorie de blog dans la sidebar,
- une bannière promotionnelle,
- un lien CTA dans une box marketing.
Cela signifie que le rapport ne s’arrête pas au niveau :
- section related performante
mais descend jusqu’au niveau :
- le produit X dans la section related vend le mieux
- l’article de blog Y mène au plus grand nombre de commandes
4. Il connaît le contexte source
Le module enregistre également le contexte source, c’est-à-dire le point de départ du parcours.
Exemple :
- l’utilisateur se trouve sur la fiche produit
Affirm Water Bottle, - il voit
related_products, - il clique sur
Zing Jump Rope, - il accède à la PDP de ce produit,
- il l’ajoute au panier,
- et achète finalement
Zing Jump Rope.
Dans ce cas, il est possible d’afficher :
source page=Affirm Water Bottle,area=related_products,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope.
C’est exactement le niveau d’analyse qui manque habituellement dans les outils classiques.
Comment comprendre les notions les plus importantes
Area
Area est une section ou un bloc de page que vous souhaitez mesurer comme source d’impact sur les ventes.
Exemples :
- section de produits associés,
- listing de catégorie,
- widget de blog,
- sidebar de blog,
- bannière promotionnelle,
- popup,
- bloc CMS personnalisé.
Object
Object est un élément précis à l’intérieur d’un area.
Exemples :
- un produit dans une liste,
- un article de blog,
- une catégorie de blog,
- un tag,
- un slide dans un slider,
- une bannière dans une section promotionnelle.
Source Page
Source Page est la page depuis laquelle l’utilisateur a commencé le parcours lié à un area donné.
Exemples :
- la fiche produit source pour
related_products, - un article de blog pour un lien menant vers un produit,
- un listing de catégorie pour un clic sur un produit,
- les résultats de recherche pour un produit cliqué.
Purchased SKU
Il s’agit du SKU précis qui a été acheté et auquel nous attribuons l’impact d’un area ou d’un object donné.
Quelles zones peuvent être mesurées
Le module prend en charge à la fois les intégrations natives et les zones définies par sélecteurs.
Exemples en e-commerce
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_products
Exemples en content commerce
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Exemples personnalisés
homepage_promo_boxblack_friday_bannersummer_campaign_sliderai_recommendationscategory_top_cta
Quels rapports l’utilisateur obtient-il
Analytics Dashboard
Il sert à obtenir un aperçu rapide des résultats.
Il affiche entre autres :
- attributed revenue,
- attributed orders,
- CTR,
- top areas,
- top supported products,
- top blog sources.
Area Report
Il répond à la question :
- quelle zone fonctionne,
- quels objets y génèrent des ventes,
- quelles sources sont à l’origine des ventes.
Exemple :
related_productsgénère 12 commandes et 4 800 PLN de chiffre d’affaires,- le produit qui vend le mieux est
WB05-S-Orange, - la source la plus fréquente de ce parcours est le produit
Affirm Water Bottle.
Product Context Report
Ce rapport est essentiel pour les zones produit.
Il répond à la question :
- depuis quel produit source,
- quel produit a été cliqué,
- et qu’est-ce qui a finalement été acheté.
Exemple :
source product=Affirm Water Bottle,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope,orders= 7,revenue= 840 PLN.
Blog Commerce Report
Il montre l’impact du blog sur les ventes.
Il répond aux questions :
- quel article vend,
- quelle catégorie du blog vend,
- quel tag mène à des commandes,
- quels SKU sont achetés après une entrée depuis le blog.
Exemple :
- l’article
Comment choisir une gourde de sporta généré 9 commandes, - le SKU le plus souvent acheté après cet article est
Affirm Water Bottle.
Object Report
Il permet d’entrer dans un objet précis.
Exemple :
- un produit précis dans
related_products, - un article de blog précis dans
blog_post_listing, - une catégorie de blog précise dans la sidebar.
Le rapport affiche :
- les clics,
- les commandes,
- le chiffre d’affaires,
- les pages source,
- les SKU achetés associés à cet objet unique.
Source Page Report
Il s’agit d’un rapport en perspective inversée.
Au lieu d’observer l’objet, vous observez une page source précise et vérifiez :
- quels objets cliqués depuis cette page génèrent des ventes,
- quels SKU sont ensuite achetés,
- quel chiffre d’affaires cette page précise a généré comme point de départ du parcours.
Exemple :
- la fiche produit
Affirm Water Bottlecomme source page, - les objets les plus performants depuis cette page sont deux produits de
related_products, - le chiffre d’affaires total de ce parcours est de 1 350 PLN.
Scénarios d’usage typiques
Optimisation du merchandising
La boutique peut comparer si :
related_productsvend mieux queupsell_products,- le cross-sell dans le panier conclut réellement la vente,
- le listing de catégorie dirige vers des produits qui débouchent effectivement sur une commande.
Analyse du blog
L’équipe contenu peut vérifier :
- quels articles mènent à une PDP,
- quels articles aident à ajouter un produit au panier,
- quels articles ont un impact réel sur les ventes.
Nettoyage du layout de la boutique
Si une section a beaucoup d’impressions et un impact faible ou nul sur le chiffre d’affaires, il est possible d’évaluer s’il faut :
- l’améliorer,
- la déplacer,
- remplacer son contenu,
- ou la supprimer complètement.
Test des changements
Après une modification du layout, d’un widget, du blog ou du mécanisme de recommandation, vous pouvez comparer :
- la période avant et après,
- l’impact sur le CTR,
- l’impact sur les commandes,
- l’impact sur le chiffre d’affaires.
À qui s’adresse ce module
Il apportera le plus de valeur à :
- les propriétaires de boutiques Magento,
- les e-commerce managers,
- les merchandisers,
- les équipes CRO,
- les équipes contenu et SEO,
- les agences qui développent des boutiques Magento.
Résumé
Kowal Analytics transforme les éléments du storefront en sources de vente mesurables.
Il permet de passer de la question générale :
- ce bloc fonctionne-t-il ?
à la question concrète :
- quel produit, article, catégorie ou page source génère des ventes, et quel chiffre d’affaires en résulte ?
Guide d’installation de Kowal Analytics
Prérequis
Avant l’installation, assurez-vous que :
- l’instance Magento 2 fonctionne correctement,
- Composer a accès au dépôt de packages Kowal,
- vous disposez d’un accès CLI à
bin/magento, - l’environnement permet d’exécuter cron et les queue consumers,
- l’environnement écrit correctement dans la base de données et dans
var/log.
Installation via Composer
Ajoutez le dépôt Composer :
composer config repositories.kowal composer https://repo.kowal.storeAjoutez les identifiants d’accès au dépôt privé :
composer config http-basic.repo.kowal.store Installez le module :
composer require kowal/module-analyticsActivation du module
Exécutez les commandes Magento standard :
bin/magento module:enable Kowal_Analyticsbin/magento setup:upgradebin/magento cache:flushSi la boutique fonctionne en production mode, exécutez également :
bin/magento setup:di:compilebin/magento setup:static-content:deploy -fbin/magento cache:flushLancement des processus asynchrones
Le module utilise des files d’attente et un traitement asynchrone. Sans cela, le dashboard et les rapports ne seront pas complets.
Démarrez les consumers requis :
bin/magento queue:consumers:start kowal_analytics.raw_eventsbin/magento queue:consumers:start kowal_analytics.conversionbin/magento queue:consumers:start kowal_analytics.attributionLe cron Magento doit également fonctionner correctement, car le module utilise le retry et le backfill pour l’attribution.
Vérification de base :
bin/magento cron:runCe qui se passe après l’installation
Après une installation correcte, le module :
- charge le tracker sur le storefront,
- enregistre les événements frontend,
- associe la session analytics au
quote, - transfère les identifiants analytics vers
sales_order, - enregistre les conversions et les lignes de conversion,
- calcule l’attribution des commandes aux area et aux object,
- met à disposition un dashboard ainsi que des rapports détaillés dans le panneau Magento.
Où vérifier que le module fonctionne
Après l’installation, vérifiez :
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Si le module est correctement actif, vous devriez voir :
- le dashboard du module,
- le widget de synthèse sur le dashboard natif de Magento,
- la section de configuration dans Stores -> Configuration.
Test technique recommandé après déploiement
Effectuez un test end-to-end simple :
- Ouvrez la boutique.
- Accédez à une fiche produit.
- Cliquez sur un élément tracké, par exemple un produit dans
related_productsou un article de blog. - Ajoutez le produit au panier.
- Passez une commande.
- Vérifiez que les événements, les conversions et l’attribution ont bien été enregistrés.
Si le debug est activé, vérifiez :
- les logs dans la console du navigateur,
var/log/kowal_analytics_debug.log
Ce qu’il vaut la peine de vérifier dans le HTML
Si vous souhaitez confirmer que le tracking fonctionne au rendu de page, vérifiez la présence des attributs :
data-kowal-track-areadata-kowal-track-area-iddata-kowal-track-objectdata-kowal-track-iddata-kowal-track-sku
Exemple :
- le conteneur de la section
related_productsdoit avoirdata-kowal-track-area='related_products' - un produit individuel dans cette section doit avoir
data-kowal-track-object='product'et son propredata-kowal-track-id
Problèmes typiques après installation
Le dashboard est visible, mais il n’y a pas de données
Vérifiez :
- si les consumers fonctionnent,
- si le cron fonctionne,
- si analytics est activé dans la configuration,
- si le tracker se charge sur le frontend,
- si des area trackés sont effectivement présents sur la page.
Les événements sont enregistrés, mais l’attribution est incomplète
Vérifiez :
- si le consumer
kowal_analytics.attributionfonctionne, - si le cron de retry fonctionne,
- si les événements source arrivent bien en base avant le calcul final de l’attribution.
Une custom area n’apparaît pas dans les rapports
Vérifiez :
- si la définition de l’area a bien été enregistrée,
- si les sélecteurs correspondent au DOM réel,
- si le runtime apply ajoute bien
data-kowal-track-*, - si la zone en question dispose d’identifiants d’objet nécessaires pour l’analyse ultérieure.
Recommandation de déploiement
L’ordre le plus sûr est le suivant :
- installer le module,
- démarrer les consumers et le cron,
- activer le debug,
- tester un scénario produit simple,
- vérifier le dashboard,
- puis seulement étendre le tracking aux custom area.
Guide de configuration de Kowal Analytics
Navigation dans le panneau d’administration
Points d’entrée principaux du module :
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Structure de la configuration
Actuellement, le module propose trois groupes principaux de paramètres.
1. General
Chemin :
Stores -> Configuration -> Analytics -> General
Champ :
Enable Analytics
Signification :
- active ou désactive le tracking frontend et le traitement analytics ultérieur pour le scope sélectionné.
Recommandation :
- il est préférable d’activer par
store viewaprès avoir préalablement vérifié le bon fonctionnement des trackers et des consumers.
2. Debug
Chemin :
Stores -> Configuration -> Analytics -> Debug
Champs :
Enable Backend Debug LogEnable Frontend Console Log
Signification :
- le backend debug enregistre des logs techniques dans :
var/log/kowal_analytics_debug.log
- le frontend debug enregistre les logs du tracker dans la console du navigateur.
Utilisation :
- installation,
- QA,
- analyse des erreurs,
- tests du selector assistant,
- confirmation que les événements arrivent bien dans le pipeline.
Recommandation :
- l’activer pendant le déploiement et les tests,
- le désactiver en environnement de production une fois la validation terminée.
3. Tools
Chemin :
Stores -> Configuration -> Analytics -> Tools
Champ :
Enable Frontend Selector Assistant
Signification :
- affiche un assistant sur le storefront qui aide à désigner et à préparer la configuration de vos propres area basés sur des sélecteurs.
Utilisation :
- mapping des custom section,
- analyse de la structure DOM,
- préparation de la définition d’area sans édition manuelle du code.
Comment comprendre la configuration en pratique
Scope
Le module fonctionne dans le scope Magento, la configuration peut donc être différente pour :
default,website,store view.
Le plus sûr est de traiter le module comme un outil par store view, car :
- différentes boutiques peuvent avoir un layout différent,
- différentes boutiques peuvent avoir des sections de blog, CMS et merchandising différentes,
- les rapports par store view sont beaucoup plus fiables sur le plan opérationnel.
Comment comprendre les notions de base dans le module
Area
Area est une zone distincte de la page que vous souhaitez mesurer comme source d’impact sur les ventes.
Exemples :
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_productsblog_post_listingblog_sidebar_categorieshomepage_promo_box
Object
Object est un élément précis à l’intérieur d’un area.
Exemples :
- un produit individuel dans une liste,
- un article de blog,
- une catégorie de blog,
- un tag,
- une bannière,
- un slide.
Source Page
Source Page est la page depuis laquelle l’utilisateur a interagi d’une manière menant ensuite à une vente.
Exemples :
- la fiche produit source pour
related_products, - un article de blog pour un produit cliqué,
- un listing de catégorie pour un produit cliqué,
- les résultats de recherche pour un produit.
Dashboard et rapports
Analytics Dashboard
C’est l’écran principal de synthèse. Il affiche :
- attributed revenue,
- attributed orders,
- average order value,
- CTR,
- top areas,
- top supported products,
- top blog sources,
- des liens vers les rapports détaillés.
Cet écran répond à la question :
qu’est-ce qui fonctionne le mieux
Area Report
Ce rapport répond aux questions :
- quel area génère du chiffre d’affaires,
- quels object dans cet area vendent,
- de quelles source page proviennent les ventes.
Exemple :
related_productscompte 18 commandes,- le produit qui y vend le mieux est
Zing Jump Rope, - la source la plus fréquente de ce parcours est la fiche produit
Affirm Water Bottle.
Product Context Report
Il s’agit d’un rapport pour les zones produit telles que :
related_productsupsell_productscrosssell_productscategory_listingsearch_results
Il montre la relation :
source product -> clicked object -> purchased SKU
Exemple :
- l’utilisateur est sur la PDP
Affirm Water Bottle, - il clique sur
WB05-S-Orangedansrelated_products, - il achète
WB05-S-Orange.
Blog Commerce Report
Il s’agit d’un rapport pour les zones blog :
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Il répond aux questions :
- quel post vend,
- quelle catégorie de blog vend,
- quel tag soutient les ventes,
- quels SKU sont achetés après une visite depuis le blog.
Object Report
Il s’agit d’un rapport pour un object précis.
Exemple :
- un produit dans
related_products, - un article de blog de
blog_post_listing, - une catégorie de blog de
blog_sidebar_categories.
Il affiche :
- combien d’impressions il a eues,
- combien de clics il a eus,
- combien de commandes il a générées,
- quel chiffre d’affaires lui a été attribué,
- de quelles source page provenaient ces parcours.
Source Page Report
Il s’agit d’un rapport pour une page source précise.
Exemple :
- la fiche produit
Affirm Water Bottle, - l’article de blog
Comment choisir une gourde de sport, - le listing de catégorie
Chaussures de running.
Il affiche :
- quels clicked object depuis cette page génèrent des ventes,
- quels SKU sont achetés après une visite depuis cette page,
- combien de commandes et de chiffre d’affaires cette page précise génère comme point de départ du parcours.
Modèles d’attribution
Modèles disponibles :
Last ClickFirst ClickAssistedView Through
Comment les lire :
Last Click
Le meilleur pour répondre à la question :
- quel élément a directement conclu la vente.
First Click
Le meilleur pour répondre à la question :
- quel élément a démarré le parcours menant à l’achat.
Assisted
Le meilleur pour répondre à la question :
- quel élément a participé au parcours, même s’il n’a pas été le dernier clic.
View Through
Le meilleur pour répondre à la question :
- si la simple exposition de la section a eu un impact sur la vente, même sans clic.
Configuration de custom area
Vous pouvez préparer une custom area via le Frontend Selector Assistant.
Workflow typique :
- Activez
Enable Frontend Selector Assistant. - Ouvrez le storefront.
- Lancez l’assistant.
- Désignez la zone.
- Vérifiez le
container selectorproposé. - Vérifiez le
item selectorproposé. - Vérifiez le
link selector. - Enregistrez la définition.
- Confirmez que le runtime apply a ajouté
data-kowal-track-*. - Testez le clic et le passage aux rapports.
Exemple de custom area
Supposons que vous ayez sur la page d’accueil une box promotionnelle avec trois tuiles.
Vous pouvez définir :
area_code = homepage_promo_boxobject_type = promotioncontainer_selector = .homepage-promoitem_selector = .homepage-promo__itemlink_selector = .homepage-promo__link
Le rapport montrera alors :
- quelle tuile a été cliquée,
- laquelle a mené à un achat,
- quel chiffre d’affaires elle a généré.
Workflow de test après configuration
L’ordre le plus pertinent est :
- activer analytics,
- activer le backend debug,
- activer le frontend console log,
- suivre un scénario utilisateur,
- vérifier le dashboard,
- vérifier le rapport area,
- descendre vers l’object report ou le source page report,
- désactiver le debug après confirmation du bon fonctionnement.
Recommandations opérationnelles
- maintenez les consumers sous supervisor ou systemd,
- veillez à ce que le cron Magento fonctionne en permanence,
- après des changements de thème, vérifiez que les sélecteurs des custom area correspondent toujours au DOM,
- après des changements de merchandising, comparez les résultats par area,
- n’interprétez pas le CTR seul comme un succès sans vérifier le chiffre d’affaires et les commandes.
























