Kowal Analytics per Magento 2
Che cos è questo modulo
Kowal Analytics è un modulo di attribuzione delle vendite per Magento 2. Il suo compito è mostrare quali elementi dello store influenzano realmente il carrello, l ordine e i ricavi.
Non è un semplice pixel che raccoglie visualizzazioni di pagina. Il modulo analizza l intero contesto di vendita:
- quale area è stata visualizzata,
- quale oggetto in quell area è stato cliccato,
- da quale pagina o da quale prodotto l utente ha iniziato l interazione,
- quale prodotto è stato aggiunto al carrello,
- quale SKU è stato infine acquistato,
- quali ricavi devono essere attribuiti a questo percorso.
In questo modo, lo store può rispondere a domande a cui le analitiche standard di solito non rispondono:
- Quali sezioni
related productsvendono davvero? - Quali blocchi
upsellecross-sellgenerano ricavi? - Quali articoli del blog portano alla vendita di prodotti?
- Quali banner, widget o sezioni CMS vengono solo cliccati ma non convertono?
- Quali elementi della pagina occupano spazio ma non hanno alcun impatto sulle vendite?
Qual è il valore di business
Il modulo è stato creato per gli store che vogliono ottimizzare merchandising, contenuti e layout della pagina sulla base dell impatto reale sulle vendite, e non solo in base al traffico o al CTR.
Dai report è possibile valutare:
- ricavi per area,
- numero di ordini per area,
- efficacia di specifici oggetti all interno di una determinata area,
- efficacia della relazione prodotto -> prodotto cliccato -> SKU acquistato,
- impatto del blog sulle vendite,
- impatto del primo clic, dell ultimo clic, del contributo assistito e del view-through,
- percorsi di origine che portano all acquisto.
Cosa distingue questo modulo dai semplici analytics pixel
1. Misura le vendite, non solo visualizzazioni e clic
Il solo clic non dice ancora nulla sul valore di business. Kowal Analytics collega gli eventi frontend con il carrello, l ordine e i ricavi.
2. Si basa sul concetto di area
L unità base di analisi è l area, cioè una sezione distinta della pagina che vuoi misurare.
Esempi:
related_productssu PDP,upsell_productssu PDP,crosssell_productsnel carrello,category_listingnell elenco prodotti della categoria,search_resultsnei risultati di ricerca,wishlist_products,compare_products,blog_post_listing,blog_sidebar_categories,- un box promozionale personalizzato in CMS.
3. Consente di analizzare anche l object
In ogni area si trovano specifici object, cioè elementi che l utente vede e clicca.
Esempi:
- prodotto nella sezione
related_products, - articolo del blog nell elenco articoli,
- categoria del blog nella sidebar,
- banner promozionale,
- link CTA in un box marketing.
Questo significa che il report non si ferma al livello:
- la sezione related funziona
ma arriva al livello:
- il prodotto X nella sezione related vende meglio
- l articolo del blog Y porta al maggior numero di ordini
4. Conosce il contesto di origine
Il modulo salva anche il contesto di origine, cioè da dove è iniziato il percorso.
Esempio:
- l utente è sulla scheda prodotto
Affirm Water Bottle, - vede
related_products, - clicca
Zing Jump Rope, - passa alla PDP di quel prodotto,
- lo aggiunge al carrello,
- infine acquista
Zing Jump Rope.
In questo caso è possibile mostrare:
source page=Affirm Water Bottle,area=related_products,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope.
È esattamente questo il livello di analisi che di solito manca negli strumenti tipici.
Come interpretare i concetti più importanti
Area
Area è una sezione o un blocco della pagina che vuoi misurare come fonte di impatto sulle vendite.
Esempi:
- sezione prodotti correlati,
- listing di categoria,
- widget del blog,
- sidebar del blog,
- banner promozionale,
- popup,
- blocco CMS personalizzato.
Object
Object è un elemento specifico all interno dell area.
Esempi:
- un prodotto nell elenco,
- un articolo del blog,
- una categoria del blog,
- un tag,
- una slide nello slider,
- un banner nella sezione promozionale.
Source Page
Source Page è la pagina da cui l utente ha iniziato il percorso collegato a una determinata area.
Esempi:
- scheda prodotto di origine per
related_products, - articolo del blog per un link che porta a un prodotto,
- listing di categoria per il clic su un prodotto,
- risultati di ricerca per il prodotto cliccato.
Purchased SKU
È lo SKU specifico che è stato acquistato e al quale attribuiamo l impatto di una determinata area o object.
Quali aree si possono misurare
Il modulo supporta sia integrazioni native, sia aree definite tramite selettori.
Esempi nell e-commerce
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_products
Esempi nel content commerce
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Esempi personalizzati
homepage_promo_boxblack_friday_bannersummer_campaign_sliderai_recommendationscategory_top_cta
Quali report riceve l utente
Analytics Dashboard
Serve per una rapida panoramica dei risultati.
Mostra tra l altro:
- attributed revenue,
- attributed orders,
- CTR,
- top areas,
- top supported products,
- top blog sources.
Area Report
Risponde alla domanda:
- quale area funziona,
- quali oggetti al suo interno vendono,
- da quali fonti nasce la vendita.
Esempio:
related_productsgenera 12 ordini e 4 800 PLN di ricavi,- il prodotto che vende meglio è
WB05-S-Orange, - la fonte più frequente di questo percorso è il prodotto
Affirm Water Bottle.
Product Context Report
Questo report è fondamentale per le aree prodotto.
Risponde alla domanda:
- da quale prodotto di origine,
- è stato cliccato quale prodotto,
- e cosa è stato infine acquistato.
Esempio:
source product=Affirm Water Bottle,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope,orders= 7,revenue= 840 PLN.
Blog Commerce Report
Mostra l impatto del blog sulle vendite.
Risponde alle domande:
- quale articolo vende,
- quale categoria del blog vende,
- quale tag porta agli ordini,
- quali SKU vengono acquistati dopo l accesso dal blog.
Esempio:
- l articolo
Come scegliere una borraccia da allenamentoha generato 9 ordini, - lo SKU acquistato più spesso dopo questo articolo è
Affirm Water Bottle.
Object Report
Consente di entrare in un singolo oggetto specifico.
Esempio:
- un prodotto specifico in
related_products, - un articolo specifico del blog in
blog_post_listing, - una categoria specifica del blog nella sidebar.
Il report mostra:
- clic,
- ordini,
- ricavi,
- pagine di origine,
- SKU acquistati collegati a questo singolo oggetto.
Source Page Report
È un report con prospettiva inversa.
Invece di guardare all oggetto, osservi una singola pagina di origine e verifichi:
- quali oggetti cliccati da quella pagina vendono,
- quali SKU vengono poi acquistati,
- quali ricavi ha generato quella specifica pagina come punto di partenza del percorso.
Esempio:
- la scheda prodotto
Affirm Water Bottlecome source page, - gli oggetti che vendono meglio da questa pagina sono due prodotti di
related_products, - i ricavi totali di questo percorso sono 1 350 PLN.
Scenari d uso tipici
Ottimizzazione del merchandising
Lo store può confrontare se:
related_productsvende meglio diupsell_products,- il cross-sell nel carrello chiude davvero la vendita,
- il listing di categoria indirizza verso prodotti che si trasformano effettivamente in ordine.
Analisi del blog
Il team contenuti può verificare:
- quali articoli portano alla PDP,
- quali articoli aiutano ad aggiungere il prodotto al carrello,
- quali articoli hanno un impatto reale sulle vendite.
Pulizia del layout dello store
Se una sezione ha molte impression e un impatto basso o nullo sui ricavi, è possibile valutare se:
- va migliorata,
- spostata,
- sostituito il suo contenuto,
- oppure rimossa completamente.
Test delle modifiche
Dopo aver modificato il layout, il widget, il blog o il meccanismo di raccomandazione, puoi confrontare:
- il periodo precedente e quello successivo,
- l impatto sul CTR,
- l impatto sugli ordini,
- l impatto sui ricavi.
Per chi è questo modulo
Ne trarranno il massimo valore:
- proprietari di store Magento,
- e-commerce manager,
- merchandiser,
- team CRO,
- team contenuti e SEO,
- agenzie che sviluppano store Magento.
Riepilogo
Kowal Analytics trasforma gli elementi dello storefront in fonti di vendita misurabili.
Consente di passare dalla domanda generale:
- questo blocco funziona?
alla domanda concreta:
- quale prodotto, articolo, categoria o pagina di origine genera vendite e quali ricavi ci sono dietro?
Istruzioni di installazione di Kowal Analytics
Requisiti
Prima dell installazione, assicurati che:
- l istanza Magento 2 funzioni correttamente,
- Composer abbia accesso al repository dei pacchetti Kowal,
- tu abbia accesso CLI a
bin/magento, - nell ambiente sia possibile eseguire cron e queue consumers,
- l ambiente abbia scritture verso il database e verso
var/logfunzionanti correttamente.
Installazione tramite Composer
Aggiungi il repository Composer:
composer config repositories.kowal composer https://repo.kowal.storeAggiungi le credenziali di accesso al repository privato:
composer config http-basic.repo.kowal.store Installa il modulo:
composer require kowal/module-analyticsAbilitazione del modulo
Esegui i comandi standard di Magento:
bin/magento module:enable Kowal_Analyticsbin/magento setup:upgradebin/magento cache:flushSe lo store funziona in production mode, esegui anche:
bin/magento setup:di:compilebin/magento setup:static-content:deploy -fbin/magento cache:flushAvvio dei processi asincroni
Il modulo utilizza code ed elaborazione asincrona. Senza questo, dashboard e report non saranno completi.
Avvia i consumer richiesti:
bin/magento queue:consumers:start kowal_analytics.raw_eventsbin/magento queue:consumers:start kowal_analytics.conversionbin/magento queue:consumers:start kowal_analytics.attributionAnche Magento cron deve funzionare correttamente, perché il modulo utilizza retry e backfill per l attribuzione.
Controllo di base:
bin/magento cron:runCosa succede dopo l installazione
Dopo una corretta installazione, il modulo:
- carica il tracker sullo storefront,
- salva gli eventi frontend,
- collega la sessione analytics al
quote, - trasferisce gli identificatori analytics in
sales_order, - salva le conversioni e le righe di conversione,
- calcola l attribuzione degli ordini ad area e object,
- rende disponibili dashboard e report dettagliati nel pannello Magento.
Dove verificare se il modulo funziona
Dopo l installazione controlla:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Se il modulo è correttamente attivo, dovresti vedere:
- la dashboard del modulo,
- un widget riepilogativo nella dashboard nativa di Magento,
- la sezione di configurazione in Stores -> Configuration.
Test tecnico consigliato dopo il deployment
Esegui un semplice test end-to-end:
- Apri la pagina dello store.
- Entra nella scheda prodotto.
- Clicca un elemento tracciato, per esempio un prodotto in
related_productsoppure un articolo del blog. - Aggiungi il prodotto al carrello.
- Effettua un ordine.
- Verifica che eventi, conversioni e attribuzione siano stati salvati.
Se il debug è abilitato, controlla:
- i log nella console del browser,
var/log/kowal_analytics_debug.log
Cosa vale la pena controllare nell HTML
Se vuoi confermare che il tracking funzioni durante il rendering della pagina, controlla la presenza degli attributi:
data-kowal-track-areadata-kowal-track-area-iddata-kowal-track-objectdata-kowal-track-iddata-kowal-track-sku
Esempio:
- il contenitore della sezione
related_productsdovrebbe averedata-kowal-track-area='related_products' - il singolo prodotto in quella sezione dovrebbe avere
data-kowal-track-object='product'e il propriodata-kowal-track-id
Problemi tipici dopo l installazione
La dashboard è visibile, ma non ci sono dati
Controlla:
- se i consumer sono in esecuzione,
- se cron è in esecuzione,
- se analytics è abilitato nella configurazione,
- se il tracker viene caricato nel frontend,
- se nella pagina sono effettivamente presenti aree tracciate.
Gli eventi vengono salvati, ma l attribuzione è incompleta
Controlla:
- se il consumer
kowal_analytics.attributionè in esecuzione, - se il cron retry è in esecuzione,
- se gli eventi di origine arrivano nel database prima del ricalcolo finale dell attribuzione.
La custom area non appare nei report
Controlla:
- se la definizione dell area è stata salvata correttamente,
- se i selettori corrispondono al DOM reale,
- se il runtime apply aggiunge
data-kowal-track-*, - se la determinata area ha gli identificatori oggetto necessari per ulteriori analisi.
Raccomandazione di implementazione
La sequenza più sicura è la seguente:
- installare il modulo,
- avviare consumer e cron,
- abilitare il debug,
- testare un semplice scenario di prodotto,
- controllare la dashboard,
- solo successivamente estendere il tracking alle custom area.
Istruzioni di configurazione di Kowal Analytics
Navigazione nel pannello di amministrazione
Accessi principali al modulo:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Struttura della configurazione
Attualmente il modulo mette a disposizione tre gruppi principali di impostazioni.
1. General
Percorso:
Stores -> Configuration -> Analytics -> General
Campo:
Enable Analytics
Significato:
- abilita o disabilita il tracking frontend e l ulteriore elaborazione analytics per lo scope selezionato.
Raccomandazione:
- è preferibile abilitare per
store viewdopo aver verificato in precedenza il funzionamento di tracker e consumer.
2. Debug
Percorso:
Stores -> Configuration -> Analytics -> Debug
Campi:
Enable Backend Debug LogEnable Frontend Console Log
Significato:
- il backend debug salva i log tecnici in:
var/log/kowal_analytics_debug.log
- il frontend debug salva i log del tracker nella console del browser.
Utilizzo:
- installazione,
- QA,
- analisi degli errori,
- test del selector assistant,
- conferma che gli eventi arrivino alla pipeline.
Raccomandazione:
- abilitarlo durante deployment e test,
- disabilitarlo nell ambiente di produzione al termine della validazione.
3. Tools
Percorso:
Stores -> Configuration -> Analytics -> Tools
Campo:
Enable Frontend Selector Assistant
Significato:
- mostra un helper sullo storefront che aiuta a indicare e preparare la configurazione per custom area basate su selettori.
Utilizzo:
- mappatura di custom section,
- analisi della struttura DOM,
- preparazione della definizione dell area senza modifica manuale del codice.
Come interpretare la configurazione nella pratica
Scope
Il modulo funziona nello scope Magento, quindi la configurazione può essere diversa per:
default,website,store view.
La scelta più sicura è trattare il modulo come strumento per store view, perché:
- store diversi possono avere layout diversi,
- store diversi possono avere sezioni blog, CMS e merchandising differenti,
- i report per store view sono molto più affidabili a livello operativo.
Come interpretare i concetti di base nel modulo
Area
Area è una sezione distinta della pagina che vuoi misurare come fonte di impatto sulle vendite.
Esempi:
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_productsblog_post_listingblog_sidebar_categorieshomepage_promo_box
Object
Object è un elemento specifico all interno dell area.
Esempi:
- un singolo prodotto nell elenco,
- un articolo del blog,
- una categoria del blog,
- un tag,
- un banner,
- una slide.
Source Page
Source Page è la pagina da cui l utente ha avviato un interazione che porta successivamente alla vendita.
Esempi:
- scheda prodotto di origine per
related_products, - articolo del blog per il prodotto cliccato,
- listing di categoria per il prodotto cliccato,
- risultati di ricerca per il prodotto.
Dashboard e report
Analytics Dashboard
È la schermata principale di panoramica. Mostra:
- attributed revenue,
- attributed orders,
- average order value,
- CTR,
- top areas,
- top supported products,
- top blog sources,
- link ai report dettagliati.
Questa schermata risponde alla domanda:
cosa funziona meglio
Area Report
Questo report risponde alle domande:
- quale area genera ricavi,
- quali object in quell area vendono,
- da quali source page provengono le vendite.
Esempio:
related_productsha 18 ordini,- al suo interno vende meglio
Zing Jump Rope, - la fonte più frequente di questo percorso è la scheda prodotto
Affirm Water Bottle.
Product Context Report
È il report per aree prodotto come:
related_productsupsell_productscrosssell_productscategory_listingsearch_results
Mostra la relazione:
source product -> clicked object -> purchased SKU
Esempio:
- l utente è sulla PDP
Affirm Water Bottle, - clicca
WB05-S-Orangeinrelated_products, - acquista
WB05-S-Orange.
Blog Commerce Report
È il report per le aree blog:
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Risponde alle domande:
- quale post vende,
- quale categoria del blog vende,
- quale tag supporta le vendite,
- quali SKU vengono acquistati dopo l accesso dal blog.
Object Report
È il report per un singolo object specifico.
Esempio:
- un prodotto in
related_products, - un articolo del blog da
blog_post_listing, - una categoria del blog da
blog_sidebar_categories.
Mostra:
- quante impression ha avuto,
- quanti clic ha avuto,
- quanti ordini ha generato,
- quali ricavi gli sono stati attribuiti,
- da quali source page provenivano questi percorsi.
Source Page Report
È il report per una singola pagina di origine specifica.
Esempio:
- scheda prodotto
Affirm Water Bottle, - articolo del blog
Come scegliere una borraccia da allenamento, - listing di categoria
Scarpe da corsa.
Mostra:
- quali clicked object di questa pagina vendono,
- quali SKU vengono acquistati dopo l accesso da questa pagina,
- quanti ordini e ricavi genera questa specifica pagina come punto di partenza del percorso.
Modelli di attribuzione
Modelli disponibili:
Last ClickFirst ClickAssistedView Through
Come interpretarli:
Last Click
Il migliore per la domanda:
- quale elemento ha chiuso direttamente la vendita.
First Click
Il migliore per la domanda:
- quale elemento ha iniziato il percorso che porta all acquisto.
Assisted
Il migliore per la domanda:
- quale elemento ha preso parte al percorso, anche se non è stato l ultimo clic.
View Through
Il migliore per la domanda:
- se la sola esposizione della sezione ha avuto un impatto sulle vendite, anche senza clic.
Configurazione della custom area
Puoi preparare una custom area tramite Frontend Selector Assistant.
Workflow tipico:
- Abilita
Enable Frontend Selector Assistant. - Apri lo storefront.
- Avvia l assistant.
- Indica l area.
- Controlla il
container selectorproposto. - Controlla il
item selectorproposto. - Controlla il
link selector. - Salva la definizione.
- Conferma che il runtime apply abbia aggiunto
data-kowal-track-*. - Testa il clic e il passaggio ai report.
Esempio di custom area
Supponiamo che nella home page tu abbia un box promozionale con tre riquadri.
Puoi definire:
area_code = homepage_promo_boxobject_type = promotioncontainer_selector = .homepage-promoitem_selector = .homepage-promo__itemlink_selector = .homepage-promo__link
In questo modo il report mostrerà:
- quale riquadro è stato cliccato,
- quale ha portato all acquisto,
- quali ricavi ha generato.
Workflow di test dopo la configurazione
La sequenza più sensata è:
- abilitare analytics,
- abilitare backend debug,
- abilitare frontend console log,
- percorrere uno scenario utente,
- controllare la dashboard,
- controllare il report area,
- scendere nell object report oppure nel source page report,
- disabilitare il debug dopo aver confermato la correttezza.
Raccomandazioni operative
- mantieni i consumer sotto supervisor o systemd,
- assicurati che Magento cron sia sempre in esecuzione,
- dopo modifiche al tema verifica se i selettori della custom area corrispondono ancora al DOM,
- dopo modifiche al merchandising confronta i risultati per area,
- non interpretare il solo CTR come un successo senza verificare ricavi e ordini.
























