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.


