Kowal Analytics dla Magento 2
Czym jest ten moduł
Kowal Analytics to moduł atrybucji sprzedaży dla Magento 2. Jego zadaniem jest pokazanie, które elementy sklepu realnie wpływają na koszyk, zamówienie i przychód.
To nie jest zwykły pixel zbierający odsłony stron. Moduł analizuje pełny kontekst sprzedażowy:
- jaki obszar został wyświetlony,
- jaki obiekt w tym obszarze został kliknięty,
- z jakiej strony lub z jakiego produktu użytkownik wszedł w interakcję,
- jaki produkt został dodany do koszyka,
- jakie SKU zostało ostatecznie kupione,
- jaki przychód należy przypisać do tej ścieżki.
Dzięki temu sklep może odpowiedzieć na pytania, na które standardowe analityki zwykle nie odpowiadają:
- Które sekcje
related productsnaprawdę sprzedają? - Które bloki
upsellicross-sellgenerują przychód? - Które wpisy blogowe prowadzą do sprzedaży produktów?
- Które bannery, widgety lub sekcje CMS są tylko klikane, ale nie konwertują?
- Które elementy strony zajmują miejsce, ale nie mają wpływu na sprzedaż?
Jaka jest wartość biznesowa
Moduł powstał dla sklepów, które chcą optymalizować merchandising, content i układ strony na podstawie realnego wpływu na sprzedaż, a nie tylko na podstawie ruchu czy CTR.
Z poziomu raportów można ocenić:
- przychód per area,
- liczbę zamówień per area,
- skuteczność konkretnych obiektów wewnątrz danego area,
- skuteczność relacji produkt -> kliknięty produkt -> zakupione SKU,
- wpływ bloga na sprzedaż,
- wpływ pierwszego kliknięcia, ostatniego kliknięcia, udziału wspomagającego i view-through,
- ścieżki źródłowe prowadzące do zakupu.
Co odróżnia ten moduł od prostych analytics pixel
1. Mierzy sprzedaż, a nie tylko odsłony i kliknięcia
Sam klik nie mówi jeszcze nic o wartości biznesowej. Kowal Analytics łączy zdarzenia frontendowe z koszykiem, zamówieniem i przychodem.
2. Pracuje na pojęciu area
Podstawową jednostką analizy jest area, czyli wydzielony obszar strony, który chcesz mierzyć.
Przykłady:
related_productsna PDP,upsell_productsna PDP,crosssell_productsw koszyku,category_listingna liście produktów kategorii,search_resultsna wynikach wyszukiwania,wishlist_products,compare_products,blog_post_listing,blog_sidebar_categories,- własny box promocyjny w CMS.
3. Pozwala analizować także object
W każdym area znajdują się konkretne object, czyli elementy, które użytkownik widzi i klika.
Przykłady:
- produkt w sekcji
related_products, - wpis blogowy na liście wpisów,
- kategoria bloga w sidebarze,
- baner promocyjny,
- link CTA w boxie marketingowym.
To oznacza, że raport nie kończy się na poziomie:
- „sekcja related działa”
ale schodzi do poziomu:
- „produkt X w sekcji related sprzedaje najlepiej”
- „wpis blogowy Y prowadzi do największej liczby zamówień”
4. Zna kontekst źródłowy
Moduł zapisuje również kontekst źródłowy, czyli skąd zaczęła się ścieżka.
Przykład:
- użytkownik jest na karcie produktu
Affirm Water Bottle, - widzi
related_products, - klika
Zing Jump Rope, - przechodzi na PDP tego produktu,
- dodaje go do koszyka,
- finalnie kupuje
Zing Jump Rope.
W takim przypadku można pokazać:
source page=Affirm Water Bottle,area=related_products,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope.
To jest dokładnie ten poziom analizy, którego zwykle brakuje w typowych narzędziach.
Jak rozumieć najważniejsze pojęcia
Area
Area to sekcja lub blok strony, który chcesz mierzyć jako źródło wpływu na sprzedaż.
Przykłady:
- sekcja produktów powiązanych,
- listing kategorii,
- widget blogowy,
- sidebar bloga,
- baner promocyjny,
- popup,
- własny blok CMS.
Object
Object to konkretny element wewnątrz area.
Przykłady:
- jeden produkt na liście,
- jeden wpis blogowy,
- jedna kategoria bloga,
- jeden tag,
- jeden slajd w sliderze,
- jeden baner w sekcji promocyjnej.
Source Page
Source Page to strona, z której użytkownik rozpoczął ścieżkę związaną z danym area.
Przykłady:
- karta produktu źródłowego dla
related_products, - wpis blogowy dla linku prowadzącego do produktu,
- listing kategorii dla kliknięcia produktu,
- wyniki wyszukiwania dla klikniętego produktu.
Purchased SKU
To konkretne SKU, które zostało kupione i do którego przypisujemy wpływ danego area lub object.
Jakie obszary można mierzyć
Moduł wspiera zarówno integracje natywne, jak i obszary definiowane przez selektory.
Przykłady w e-commerce
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_products
Przykłady w content commerce
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Przykłady niestandardowe
homepage_promo_boxblack_friday_bannersummer_campaign_sliderai_recommendationscategory_top_cta
Jakie raporty dostaje użytkownik
Analytics Dashboard
Służy do szybkiego przeglądu wyników.
Pokazuje między innymi:
- attributed revenue,
- attributed orders,
- CTR,
- top areas,
- top supported products,
- top blog sources.
Area Report
Odpowiada na pytanie:
- który obszar działa,
- jakie obiekty w nim sprzedają,
- z jakich źródeł powstaje sprzedaż.
Przykład:
related_productsdaje 12 zamówień i 4 800 PLN przychodu,- najlepiej sprzedaje produkt
WB05-S-Orange, - najczęściej źródłem tej ścieżki jest produkt
Affirm Water Bottle.
Product Context Report
Ten raport jest kluczowy dla obszarów produktowych.
Odpowiada na pytanie:
- z jakiego produktu źródłowego,
- kliknięto jaki produkt,
- i co finalnie zostało kupione.
Przykład:
source product=Affirm Water Bottle,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope,orders= 7,revenue= 840 PLN.
Blog Commerce Report
Pokazuje wpływ bloga na sprzedaż.
Odpowiada na pytania:
- który wpis sprzedaje,
- która kategoria bloga sprzedaje,
- który tag prowadzi do zamówień,
- jakie SKU są kupowane po wejściu z bloga.
Przykład:
- wpis
Jak wybrać bidon treningowywygenerował 9 zamówień, - najczęściej kupowanym SKU po tym wpisie jest
Affirm Water Bottle.
Object Report
Pozwala wejść w jeden konkretny obiekt.
Przykład:
- jeden konkretny produkt w
related_products, - jeden konkretny wpis blogowy w
blog_post_listing, - jedna konkretna kategoria bloga w sidebarze.
Raport pokazuje:
- kliknięcia,
- zamówienia,
- przychód,
- źródłowe strony,
- zakupione SKU powiązane z tym jednym obiektem.
Source Page Report
To raport odwrotnej perspektywy.
Zamiast patrzeć na obiekt, patrzysz na jedną stronę źródłową i sprawdzasz:
- które kliknięte obiekty z tej strony sprzedają,
- jakie SKU są później kupowane,
- jaki przychód wygenerowała ta konkretna strona jako punkt startowy ścieżki.
Przykład:
- karta produktu
Affirm Water Bottlejako source page, - najlepiej sprzedające obiekty z tej strony to dwa produkty z
related_products, - łączny przychód z tej ścieżki to 1 350 PLN.
Typowe scenariusze użycia
Optymalizacja merchandisingu
Sklep może porównać, czy:
related_productssprzedaje lepiej niżupsell_products,- cross-sell w koszyku naprawdę domyka sprzedaż,
- listing kategorii kieruje do produktów, które faktycznie kończą się zamówieniem.
Analiza bloga
Zespół contentowy może sprawdzić:
- które wpisy prowadzą do PDP,
- które wpisy pomagają dodać produkt do koszyka,
- które wpisy mają realny wpływ na sprzedaż.
Czyszczenie layoutu sklepu
Jeśli sekcja ma wysokie impresje i niski lub zerowy wpływ na przychód, można ocenić, czy:
- trzeba ją poprawić,
- przenieść,
- wymienić jej zawartość,
- albo całkowicie usunąć.
Testowanie zmian
Po zmianie layoutu, widgetu, bloga lub mechanizmu rekomendacji możesz porównać:
- wcześniejszy i późniejszy okres,
- wpływ na CTR,
- wpływ na zamówienia,
- wpływ na przychód.
Dla kogo jest ten moduł
Najwięcej wartości wyciągną z niego:
- właściciele sklepów Magento,
- e-commerce managerowie,
- merchandiserzy,
- zespoły CRO,
- zespoły contentowe i SEO,
- agencje rozwijające sklepy Magento.
Podsumowanie
Kowal Analytics zamienia elementy storefrontu w mierzalne źródła sprzedaży.
Pozwala przejść od ogólnego pytania:
- „czy ten blok działa?”
do konkretnego pytania:
- „który dokładnie produkt, wpis, kategoria albo źródłowa strona generuje sprzedaż i jaki przychód za tym stoi?”
Instrukcja instalacji Kowal Analytics
Wymagania
Przed instalacją upewnij się, że:
- instancja Magento 2 działa poprawnie,
- Composer ma dostęp do repozytorium pakietów Kowal,
- masz dostęp CLI do
bin/magento, - na środowisku można uruchamiać cron oraz queue consumers,
- środowisko ma poprawnie działające zapisy do bazy i do
var/log.
Instalacja przez Composer
Dodaj repozytorium Composer:
composer config repositories.kowal composer https://repo.kowal.store
Dodaj dane dostępowe do prywatnego repozytorium:
composer config http-basic.repo.kowal.store <YOUR_EMAIL> <YOUR_TOKEN>
Zainstaluj moduł:
composer require kowal/module-analytics
Włączenie modułu
Uruchom standardowe komendy Magento:
bin/magento module:enable Kowal_Analytics
bin/magento setup:upgrade
bin/magento cache:flush
Jeżeli sklep działa w production mode, wykonaj również:
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush
Uruchomienie procesów asynchronicznych
Moduł korzysta z kolejek i przetwarzania asynchronicznego. Bez tego dashboard i raporty nie będą kompletne.
Uruchom wymagane consumery:
bin/magento queue:consumers:start kowal_analytics.raw_events
bin/magento queue:consumers:start kowal_analytics.conversion
bin/magento queue:consumers:start kowal_analytics.attribution
Magento cron również musi działać poprawnie, ponieważ moduł wykorzystuje retry i backfill dla atrybucji.
Kontrola podstawowa:
bin/magento cron:run
Co dzieje się po instalacji
Po poprawnej instalacji moduł:
- ładuje tracker na storefront,
- zapisuje eventy frontendowe,
- wiąże sesję analytics z
quote, - przenosi identyfikatory analytics do
sales_order, - zapisuje konwersje i pozycje konwersji,
- liczy atrybucję zamówień do area i object,
- udostępnia dashboard oraz raporty szczegółowe w panelu Magento.
Gdzie sprawdzić, czy moduł działa
Po instalacji sprawdź:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Jeżeli moduł jest poprawnie aktywny, powinieneś widzieć:
- dashboard modułu,
- widget podsumowujący na natywnym dashboardzie Magento,
- sekcję konfiguracyjną w Stores -> Configuration.
Zalecany test techniczny po wdrożeniu
Wykonaj prosty test end-to-end:
- Otwórz stronę sklepu.
- Wejdź na kartę produktu.
- Kliknij trackowany element, na przykład produkt w
related_productsalbo wpis blogowy. - Dodaj produkt do koszyka.
- Złóż zamówienie.
- Sprawdź, czy eventy, konwersje i atrybucja zostały zapisane.
Jeśli debug jest włączony, sprawdź:
- logi w konsoli przeglądarki,
var/log/kowal_analytics_debug.log
Co warto sprawdzić w HTML
Jeżeli chcesz potwierdzić, że tracking działa na renderze strony, sprawdź obecność atrybutów:
data-kowal-track-areadata-kowal-track-area-iddata-kowal-track-objectdata-kowal-track-iddata-kowal-track-sku
Przykład:
- kontener sekcji
related_productspowinien miećdata-kowal-track-area="related_products" - pojedynczy produkt w tej sekcji powinien mieć
data-kowal-track-object="product"i własnedata-kowal-track-id
Typowe problemy po instalacji
Dashboard jest widoczny, ale nie ma danych
Sprawdź:
- czy consumery działają,
- czy cron działa,
- czy analytics jest włączone w konfiguracji,
- czy tracker ładuje się na frontendzie,
- czy na stronie rzeczywiście są trackowane area.
Zdarzenia są zapisywane, ale atrybucja jest niepełna
Sprawdź:
- czy działa consumer
kowal_analytics.attribution, - czy działa cron retry,
- czy eventy źródłowe docierają do bazy przed finalnym przeliczeniem atrybucji.
Custom area nie pojawia się w raportach
Sprawdź:
- czy definicja area została zapisana poprawnie,
- czy selektory zgadzają się z realnym DOM,
- czy runtime apply dodaje
data-kowal-track-*, - czy dany obszar ma identyfikatory obiektów potrzebne do dalszej analizy.
Rekomendacja wdrożeniowa
Najbezpieczniejsza kolejność jest taka:
- zainstalować moduł,
- uruchomić consumery i cron,
- włączyć debug,
- przetestować jeden prosty scenariusz produktowy,
- sprawdzić dashboard,
- dopiero potem rozszerzać tracking na custom area.
Instrukcja konfiguracji Kowal Analytics
Nawigacja w panelu administracyjnym
Główne wejścia do modułu:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Struktura konfiguracji
Obecnie moduł udostępnia trzy główne grupy ustawień.
1. General
Ścieżka:
Stores -> Configuration -> Analytics -> General
Pole:
Enable Analytics
Znaczenie:
- włącza lub wyłącza tracking frontendowy i dalsze przetwarzanie analytics dla wybranego scope.
Zalecenie:
- najlepiej włączać per
store viewpo wcześniejszej weryfikacji działania trackerów i consumerów.
2. Debug
Ścieżka:
Stores -> Configuration -> Analytics -> Debug
Pola:
Enable Backend Debug LogEnable Frontend Console Log
Znaczenie:
- backend debug zapisuje logi techniczne do:
var/log/kowal_analytics_debug.log
- frontend debug zapisuje logi trackera do konsoli przeglądarki.
Zastosowanie:
- instalacja,
- QA,
- analiza błędów,
- testy selector assistanta,
- potwierdzenie, że eventy trafiają do pipeline’u.
Zalecenie:
- włączyć na czas wdrożenia i testów,
- wyłączyć na środowisku produkcyjnym po zakończeniu walidacji.
3. Tools
Ścieżka:
Stores -> Configuration -> Analytics -> Tools
Pole:
Enable Frontend Selector Assistant
Znaczenie:
- pokazuje helper na storefrontzie, który pomaga wskazać i przygotować konfigurację dla własnych area opartych o selektory.
Zastosowanie:
- mapowanie custom section,
- analiza struktury DOM,
- przygotowanie definicji area bez ręcznej edycji kodu.
Jak rozumieć konfigurację w praktyce
Scope
Moduł działa w scope Magento, więc konfiguracja może być różna dla:
default,website,store view.
Najbezpieczniej traktować moduł jako narzędzie per store view, bo:
- różne sklepy mogą mieć inny layout,
- różne sklepy mogą mieć inne sekcje bloga, CMS i merchandisingu,
- raporty per store view są znacznie bardziej wiarygodne operacyjnie.
Jak rozumieć podstawowe pojęcia w module
Area
Area to wydzielony obszar strony, który chcesz mierzyć jako źródło wpływu na sprzedaż.
Przykłady:
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_productsblog_post_listingblog_sidebar_categorieshomepage_promo_box
Object
Object to konkretny element wewnątrz area.
Przykłady:
- pojedynczy produkt na liście,
- jeden wpis blogowy,
- jedna kategoria bloga,
- jeden tag,
- jeden baner,
- jeden slajd.
Source Page
Source Page to strona, z której użytkownik wszedł w interakcję prowadzącą dalej do sprzedaży.
Przykłady:
- karta produktu źródłowego dla
related_products, - wpis blogowy dla klikniętego produktu,
- listing kategorii dla klikniętego produktu,
- wyniki wyszukiwania dla produktu.
Dashboard i raporty
Analytics Dashboard
To główny ekran przeglądowy. Pokazuje:
- attributed revenue,
- attributed orders,
- average order value,
- CTR,
- top areas,
- top supported products,
- top blog sources,
- linki do raportów szczegółowych.
Ten ekran odpowiada na pytanie:
co działa najlepiej
Area Report
Ten raport odpowiada na pytania:
- który area generuje przychód,
- które object w tym area sprzedają,
- z jakich source page bierze się sprzedaż.
Przykład:
related_productsma 18 zamówień,- najlepiej sprzedaje w nim
Zing Jump Rope, - najczęściej źródłem tej ścieżki jest karta produktu
Affirm Water Bottle.
Product Context Report
To raport dla obszarów produktowych takich jak:
related_productsupsell_productscrosssell_productscategory_listingsearch_results
Pokazuje zależność:
source product -> clicked object -> purchased SKU
Przykład:
- użytkownik jest na PDP
Affirm Water Bottle, - klika
WB05-S-Orangewrelated_products, - kupuje
WB05-S-Orange.
Blog Commerce Report
To raport dla obszarów blogowych:
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Odpowiada na pytania:
- który post sprzedaje,
- która kategoria bloga sprzedaje,
- który tag wspiera sprzedaż,
- jakie SKU są kupowane po wejściu z bloga.
Object Report
To raport dla jednego konkretnego object.
Przykład:
- jeden produkt w
related_products, - jeden wpis blogowy z
blog_post_listing, - jedna kategoria bloga z
blog_sidebar_categories.
Pokazuje:
- ile miał impresji,
- ile miał kliknięć,
- ile wygenerował zamówień,
- jaki przychód został mu przypisany,
- z jakich source page pochodziły te ścieżki.
Source Page Report
To raport dla jednej konkretnej strony źródłowej.
Przykład:
- karta produktu
Affirm Water Bottle, - wpis blogowy
Jak wybrać bidon treningowy, - listing kategorii
Buty do biegania.
Pokazuje:
- jakie clicked object z tej strony sprzedają,
- jakie SKU są kupowane po wejściu z tej strony,
- ile zamówień i przychodu generuje ta konkretna strona jako punkt startowy ścieżki.
Modele atrybucji
Dostępne modele:
Last ClickFirst ClickAssistedView Through
Jak je czytać:
Last Click
Najlepszy do pytania:
- który element bezpośrednio domknął sprzedaż.
First Click
Najlepszy do pytania:
- który element rozpoczął ścieżkę prowadzącą do zakupu.
Assisted
Najlepszy do pytania:
- który element brał udział w ścieżce, nawet jeśli nie był ostatnim kliknięciem.
View Through
Najlepszy do pytania:
- czy sama ekspozycja sekcji miała wpływ na sprzedaż, nawet bez kliknięcia.
Konfiguracja custom area
Custom area możesz przygotować przez Frontend Selector Assistant.
Typowy workflow:
- Włącz
Enable Frontend Selector Assistant. - Otwórz storefront.
- Uruchom assistant.
- Wskaż obszar.
- Sprawdź proponowany
container selector. - Sprawdź proponowany
item selector. - Sprawdź
link selector. - Zapisz definicję.
- Potwierdź, że runtime apply dodało
data-kowal-track-*. - Przetestuj kliknięcie i przejście do raportów.
Przykład custom area
Załóżmy, że na stronie głównej masz box promocyjny z trzema kaflami.
Możesz zdefiniować:
area_code = homepage_promo_boxobject_type = promotioncontainer_selector = .homepage-promoitem_selector = .homepage-promo__itemlink_selector = .homepage-promo__link
Wtedy raport pokaże:
- który kafel był klikany,
- który prowadził do zakupu,
- jaki przychód wygenerował.
Workflow testowy po konfiguracji
Najbardziej sensowna kolejność:
- włączyć analytics,
- włączyć backend debug,
- włączyć frontend console log,
- przejść scenariusz użytkownika,
- sprawdzić dashboard,
- sprawdzić raport area,
- zejść do object report albo source page report,
- wyłączyć debug po potwierdzeniu poprawności.
Zalecenia operacyjne
- utrzymuj consumery pod supervisorem albo systemd,
- pilnuj, aby Magento cron działał stale,
- po zmianach motywu sprawdzaj, czy selektory custom area nadal pasują do DOM,
- po zmianach merchandisingu porównuj wyniki per area,
- nie interpretuj samego CTR jako sukcesu bez sprawdzenia przychodu i zamówień.
























