Kowal Analytics to moduł atrybucji dla Magento 2.

SKU: M2-ANALIZA

123,00 zł

Opis / Kowal Analytics dla Magento 2

MAGENTO 2 · ATRYBUCJA · PRZYCHÓD

Zobacz, które elementy sklepu prowadzą do sprzedaży.

Kowal Analytics

Połącz wyświetlenia i kliknięcia z koszykiem, zamówieniem i przychodem. Oceniaj produkty powiązane, blog, banery oraz własne sekcje na podstawie przypisanej im sprzedaży.

Area i object · Kontekst źródłowy · Raporty sprzedaży

JAK TO DZIAŁA W PRAKTYCE

01 · Klient widzi i klika
Tracker zapisuje interakcję z mierzonym obszarem i obiektem.

02 · Produkt trafia do zamówienia
Sesja analityczna łączy zdarzenia z koszykiem i zakupionym SKU.

03 · Oceniasz przypisany przychód
Dashboard i raporty pokazują wyniki według modelu atrybucji.

Co zyskuje Twój sklep?

Sprawdzaj wpływ merchandisingu, treści i układu sklepu na zamówienia oraz przychód.

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 products naprawdę sprzedają?
Które bloki upsell i cross-sell generują 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_products na PDP,
upsell_products na PDP,
crosssell_products w koszyku,
category_listing na liście produktów kategorii,
search_results na 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_products
upsell_products
crosssell_products
category_listing
search_results
wishlist_products
compare_products

Przykłady w content commerce

blog_post_listing
blog_recent_posts_widget
blog_sidebar_recent_posts
blog_sidebar_categories
blog_sidebar_tags
blog_post_view

Przykłady niestandardowe

homepage_promo_box
black_friday_banner
summer_campaign_slider
ai_recommendations
category_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_products daje 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 treningowy wygenerował 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 Bottle jako 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_products sprzedaje 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?”

Konfiguracja i własne obszary

W Stores → Configuration → Kowal → Analytics włączasz moduł dla właściwego zakresu. Frontend Selector Assistant pomaga wskazać własny obszar i przygotować selektory kontenera, elementów oraz linków.

Modele Last Click, First Click, Assisted i View Through pozwalają analizować odpowiednio ostatnie kliknięcie, pierwsze kliknięcie, udział wspomagający i ekspozycję bez kliknięcia. Są to modele przypisywania wpływu na sprzedaż; ich wyniki czytasz w kontekście wybranego modelu.

Przetwarzanie i uruchomienie raportów

Kompletne raporty wymagają działającego Magento cron oraz consumerów kowal_analytics.raw_events, kowal_analytics.conversion i kowal_analytics.attribution. Zdarzenia i konwersje są przetwarzane asynchronicznie.

Podczas wdrożenia możesz włączyć log backendu i logi w konsoli przeglądarki. Po zmianie motywu sprawdź selektory własnych obszarów i przejdź scenariusz od kliknięcia do zamówienia, aby zweryfikować raporty.

Instalacja przez Composer

Pakiet: kowal/module-analytics; moduł: Kowal_Analytics. Po skonfigurowaniu dostępu do repozytorium Kowal zainstaluj pakiet, włącz moduł, wykonaj aktualizację Magento i wyczyść cache. Dla trybu produkcyjnego uwzględnij kompilację oraz wdrożenie treści statycznych odpowiednie dla środowiska.

Od konfiguracji do efektu

1. Klient widzi i klika
Tracker zapisuje interakcję z mierzonym obszarem i obiektem.

2. Produkt trafia do zamówienia
Sesja analityczna łączy zdarzenia z koszykiem i zakupionym SKU.

3. Oceniasz przypisany przychód
Dashboard i raporty pokazują wyniki według modelu atrybucji.

Od rekomendacji do zakupionego SKU

Przykład: klient ogląda Affirm Water Bottle, klika Zing Jump Rope w sekcji produktów powiązanych i kupuje ten produkt.

Raport łączy stronę źródłową, obszar, kliknięty obiekt i zakupione SKU. Przychód przypisany przez model atrybucji pomaga porównywać ścieżki zakupowe.

Podejmuj decyzje o układzie sklepu na podstawie sprzedaży

Chcesz dopasować moduł do swojego sklepu? Zapytaj o wdrożenie Kowal Analytics i omów konfigurację lub potrzebne rozszerzenia.

Więcej informacji

Informacje o zakupie	Dokumentacja Modułu
Zgodność z szablonem	Luma / Blank, KOWAL

Konfiguracja Integracji

Instrukcja konfiguracji Kowal Analytics

Nawigacja w panelu administracyjnym

Główne wejścia do modułu:

Kowal -> Analytics -> Dashboard
Stores -> 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 view po wcześniejszej weryfikacji działania trackerów i consumerów.

2. Debug

Ścieżka:

Stores -> Configuration -> Analytics -> Debug

Pola:

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

Pokazuje zależność:

source product -> clicked object -> purchased SKU

Przykład:

użytkownik jest na PDP Affirm Water Bottle,
klika WB05-S-Orange w related_products,
kupuje WB05-S-Orange.

Blog Commerce Report

To raport dla obszarów blogowych:

blog_post_listing
blog_recent_posts_widget
blog_sidebar_recent_posts
blog_sidebar_categories
blog_sidebar_tags
blog_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 Click
First Click
Assisted
View 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_box
object_type = promotion
container_selector = .homepage-promo
item_selector = .homepage-promo__item
link_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ń.

Instrukcja Instalacji modułu

Przed rozpoczęciem

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:

Dane dostępowe do repozytorium Composer (adres e-mail klienta i token licencyjny) otrzymasz e-mailem po zakupie. Są również dostępne w panelu klienta po zalogowaniu na kowal.store. Zastąp TWOJ_EMAIL_KLIENTA adresem e-mail swojego konta, a TWOJ_TOKEN otrzymanym tokenem. Polecenia wykonaj w katalogu głównym Magento.

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

Dodaj dane dostępowe do prywatnego repozytorium:

composer config http-basic.repo.kowal.store "TWOJ_EMAIL_KLIENTA" "TWOJ_TOKEN"

Zainstaluj moduł:

composer require kowal/module-analytics

Włączenie modułu

Uruchom standardowe komendy Magento:

Włącz moduł

bin/magento module:enable Kowal_Analytics

Zaktualizuj Magento

bin/magento setup:upgrade

Wyczyść pamięć podręczną

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 -> Dashboard
Stores -> 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_products albo 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-area
data-kowal-track-area-id
data-kowal-track-object
data-kowal-track-id
data-kowal-track-sku

Przykład:

kontener sekcji related_products powinien mieć data-kowal-track-area="related_products"
pojedynczy produkt w tej sekcji powinien mieć data-kowal-track-object="product" i własne data-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.

Znaleźliśmy inne produkty, które mogą Cię zainteresować!

Kowal Data Layer dla Magento 2

123,00 zł

Program lojalnościowy Magento 2 - Kowal Loyalty & Rewards Suite

738,00 zł

Pytania i odpowiedzi

Pytanie

Czy moduł umożliwia monitorowanie zachowania klientów w czasie rzeczywistym (wizyty, kliknięcia, ścieżki użytkownika)?

Odpowiedź

Kowal Analytics zbiera zdarzenia storefrontu, m.in. ekspozycje, kliknięcia i powiązanie z zakupionym SKU. Raporty opierają się na asynchronicznym przetwarzaniu zdarzeń i konwersji przez CRON oraz consumerów. Aktualny opis nie gwarantuje natychmiastowej aktualizacji wszystkich raportów.

Pytanie

Czy mogę generować raporty sprzedaży, konwersji oraz porównanie wyników w określonym czasie?

Odpowiedź

Tak — funkcjonalność analityczna obejmuje możliwość analizy konwersji i działań użytkowników, co pozwala tworzyć raporty czasowe i porównywać efektywność kampanii marketingowych.

Pytanie

Czy moduł wspiera środowiska Magento 2 z wieloma sklepami (multi‑store) i wieloma językami?

Odpowiedź

Konfiguracja Analytics może być włączana dla właściwego zakresu sklepu. Po zmianie motywu lub w innym widoku sprawdź selektory mierzonych obszarów oraz cały scenariusz od kliknięcia do zamówienia. Raporty wymagają działającego CRON i consumerów.

Pytanie

Czy wpływa to na wydajność strony sklepu — np. czy zbieranie danych w czasie rzeczywistym może spowolnić działanie?

Odpowiedź

Zbieranie zaawansowanych danych może mieć wpływ — choć moduł mówi o monitorowaniu w czasie rzeczywistym, warto przeprowadzić test wydajności w środowisku testowym i zwrócić uwagę na konfigurację.

Pytanie

Czy mogę ustawiać własne filtry lub warunki analizy (np. zachowanie klientów określonej grupy, klientów B2B, konkretnych kategorii)?

Odpowiedź

Moduł pozwala definiować własne mierzone obszary storefrontu przez selektory oraz analizować obszary, obiekty, strony źródłowe i zakupione SKU. Frontend Selector Assistant pomaga przygotować selektory. Opis nie potwierdza osobnego kreatora segmentów klientów B2B lub grup klientów.

Pytanie

Czy moduł zapewnia automatyczne wysyłanie raportów lub powiadomień (np. co miesiąc) do administratora?

Odpowiedź

Opis nie precyzuje tej funkcji — jeśli automatyczne raporty lub powiadomienia są dla Ciebie istotne, zaleca się zapytać producenta o dostępność tej opcji.

Pytanie

Czy po zakupie modułu otrzymuję wsparcie techniczne oraz aktualizacje?

Odpowiedź

Tak — jako moduł sklepu Kowal w kategorii „Analityka”, objęty jest standardowym wsparciem i aktualizacjami.