Free cookie consent management tool by TermsFeedAktualizacja preferencji plików cookie

Kowal Analytics per Magento 2

30,75 € 25,00 €
Instalacja COMPOSER
M2-ANALIZA
Richiede modifiche al modello
No
Piccole modifiche
Cambiamenti significativi
Richiede conoscenze di programmazione
No
Base
Avanzato
Difficoltà di configurazione
Impatto sulle prestazioni
Conformità agli standard Magento
  • Polacco Polacco
  • Inglese Inglese
  • 2.4.9
  • 2.4.8
  • 2.4.7
  • 2.4.6
  • 2.4.5
  • 2.4.4
  • 2.4.3
  • 2.4.2
  • 2.4.1
  • 2.4.0
  • 2.3.7
  • 2.3.6
  • 2.3.5
  • 2.3.4

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 products vendono davvero?
  • Quali blocchi upsell e cross-sell generano 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_products su PDP,
  • upsell_products su PDP,
  • crosssell_products nel carrello,
  • category_listing nell elenco prodotti della categoria,
  • search_results nei 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:

  1. l utente è sulla scheda prodotto Affirm Water Bottle,
  2. vede related_products,
  3. clicca Zing Jump Rope,
  4. passa alla PDP di quel prodotto,
  5. lo aggiunge al carrello,
  6. 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_products
  • upsell_products
  • crosssell_products
  • category_listing
  • search_results
  • wishlist_products
  • compare_products

Esempi nel content commerce

  • blog_post_listing
  • blog_recent_posts_widget
  • blog_sidebar_recent_posts
  • blog_sidebar_categories
  • blog_sidebar_tags
  • blog_post_view

Esempi personalizzati

  • homepage_promo_box
  • black_friday_banner
  • summer_campaign_slider
  • ai_recommendations
  • category_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_products genera 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 allenamento ha 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 Bottle come 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_products vende meglio di upsell_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/log funzionanti correttamente.

Installazione tramite Composer

Aggiungi il repository Composer:

composer config repositories.kowal composer https://repo.kowal.store

Aggiungi le credenziali di accesso al repository privato:

composer config http-basic.repo.kowal.store  

Installa il modulo:

composer require kowal/module-analytics

Abilitazione del modulo

Esegui i comandi standard di Magento:

bin/magento module:enable Kowal_Analyticsbin/magento setup:upgradebin/magento cache:flush

Se lo store funziona in production mode, esegui anche:

bin/magento setup:di:compilebin/magento setup:static-content:deploy -fbin/magento cache:flush

Avvio 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.attribution

Anche Magento cron deve funzionare correttamente, perché il modulo utilizza retry e backfill per l attribuzione.

Controllo di base:

bin/magento cron:run

Cosa 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 -> Dashboard
  • Stores -> 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:

  1. Apri la pagina dello store.
  2. Entra nella scheda prodotto.
  3. Clicca un elemento tracciato, per esempio un prodotto in related_products oppure un articolo del blog.
  4. Aggiungi il prodotto al carrello.
  5. Effettua un ordine.
  6. 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-area
  • data-kowal-track-area-id
  • data-kowal-track-object
  • data-kowal-track-id
  • data-kowal-track-sku

Esempio:

  • il contenitore della sezione related_products dovrebbe avere data-kowal-track-area='related_products'
  • il singolo prodotto in quella sezione dovrebbe avere data-kowal-track-object='product' e il proprio data-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:

  1. installare il modulo,
  2. avviare consumer e cron,
  3. abilitare il debug,
  4. testare un semplice scenario di prodotto,
  5. controllare la dashboard,
  6. 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 -> Dashboard
  • Stores -> 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 view dopo aver verificato in precedenza il funzionamento di tracker e consumer.

2. Debug

Percorso:

  • Stores -> Configuration -> Analytics -> Debug

Campi:

  • Enable Backend Debug Log
  • Enable 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_products
  • upsell_products
  • crosssell_products
  • category_listing
  • search_results
  • wishlist_products
  • compare_products
  • blog_post_listing
  • blog_sidebar_categories
  • homepage_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_products ha 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_products
  • upsell_products
  • crosssell_products
  • category_listing
  • search_results

Mostra la relazione:

  • source product -> clicked object -> purchased SKU

Esempio:

  • l utente è sulla PDP Affirm Water Bottle,
  • clicca WB05-S-Orange in related_products,
  • acquista WB05-S-Orange.

Blog Commerce Report

È il report per le aree blog:

  • blog_post_listing
  • blog_recent_posts_widget
  • blog_sidebar_recent_posts
  • blog_sidebar_categories
  • blog_sidebar_tags
  • blog_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 Click
  • First Click
  • Assisted
  • View 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:

  1. Abilita Enable Frontend Selector Assistant.
  2. Apri lo storefront.
  3. Avvia l assistant.
  4. Indica l area.
  5. Controlla il container selector proposto.
  6. Controlla il item selector proposto.
  7. Controlla il link selector.
  8. Salva la definizione.
  9. Conferma che il runtime apply abbia aggiunto data-kowal-track-*.
  10. 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_box
  • object_type = promotion
  • container_selector = .homepage-promo
  • item_selector = .homepage-promo__item
  • link_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 è:

  1. abilitare analytics,
  2. abilitare backend debug,
  3. abilitare frontend console log,
  4. percorrere uno scenario utente,
  5. controllare la dashboard,
  6. controllare il report area,
  7. scendere nell object report oppure nel source page report,
  8. 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.

Domande e risposte

Domanda
Il modulo consente di monitorare il comportamento dei clienti in tempo reale (visite, clic, percorsi dell’utente)?
Risposta
Sì — il modulo è stato descritto come “strumenti analitici avanzati per Magento 2: monitora il comportamento dei clienti in tempo reale, analizza visite, conversioni e azioni degli utenti”.
Domanda
Posso generare report sulle vendite, sulle conversioni e confrontare i risultati in un determinato periodo di tempo?
Risposta
Sì — la funzionalità analitica include la possibilità di analizzare le conversioni e le azioni degli utenti, consentendo di creare report temporali e confrontare l’efficacia delle campagne di marketing.
Domanda
Il modulo si integra con strumenti esterni, ad es. Google Analytics, pixel pubblicitari o altri strumenti di marketing?
Risposta
Sì — nella descrizione del negozio è indicato che i moduli della categoria “Analisi” consentono l’integrazione con strumenti di analisi e il monitoraggio delle azioni degli utenti.
Domanda
L'installazione del modulo richiede modifiche ai file core di Magento o al tema del negozio?
Risposta
No — sebbene la descrizione dettagliata del modulo non fornisca esplicitamente questa informazione, per impostazione predefinita i moduli offerti dal negozio Kowal come estensioni Magento 2 sono pensati per funzionare senza modificare i file core.
Domanda
Il modulo supporta ambienti Magento 2 con più negozi (multi-store) e più lingue?
Risposta
Sì — come modulo di analisi adattato a Magento 2, può funzionare in ambienti multi-store, anche se per maggiore sicurezza vale la pena consultare la documentazione tecnica.
Domanda
Questo influisce sulle prestazioni del sito del negozio — ad esempio, la raccolta dei dati in tempo reale può rallentarne il funzionamento?
Risposta
La raccolta di dati avanzati può avere un impatto — anche se il modulo parla di monitoraggio in tempo reale, è consigliabile eseguire un test delle prestazioni in un ambiente di prova e prestare attenzione alla configurazione.
Domanda
Posso impostare filtri o condizioni di analisi personalizzati (ad es. il comportamento dei clienti di un determinato gruppo, clienti B2B, categorie specifiche)?
Risposta
Sebbene la descrizione non fornisca dettagli sul filtraggio, i moduli analitici avanzati di solito offrono la possibilità di creare segmenti e condizioni di analisi: vale la pena verificarlo nella documentazione del prodotto.
Domanda
Il modulo consente l’invio automatico di report o notifiche (ad es. ogni mese) all’amministratore?
Risposta
La descrizione non specifica questa funzione: se i report o le notifiche automatiche sono importanti per te, si consiglia di chiedere al produttore la disponibilità di questa opzione.
Domanda
Il modulo è compatibile con le versioni di Magento 2 (ad es. 2.3.x o 2.4.x)?
Risposta
Sì — i dati sulla compatibilità non sono indicati in modo dettagliato nella descrizione, tuttavia un modulo appartenente all’offerta per negozi Magento 2 in genere supporta le versioni più recenti della piattaforma; vale sempre la pena confermare la compatibilità.
Domanda
Dopo l'acquisto del modulo ricevo supporto tecnico e aggiornamenti?
Risposta
Sì — in quanto modulo del negozio Kowal nella categoria “Analisi”, è coperto dal supporto standard e dagli aggiornamenti.
Write Your Own Review
You're reviewing:Kowal Analytics per Magento 2
Your Rating
Prodotti