Kowal Analytics für Magento 2
Was ist dieses Modul
Kowal Analytics ist ein Modul zur Sales-Attribution für Magento 2. Seine Aufgabe ist es zu zeigen, welche Elemente des Shops den Warenkorb, die Bestellung und den Umsatz tatsächlich beeinflussen.
Es handelt sich nicht um ein gewöhnliches Pixel, das Seitenaufrufe sammelt. Das Modul analysiert den vollständigen Sales-Kontext:
- welcher Bereich angezeigt wurde,
- welches Objekt in diesem Bereich angeklickt wurde,
- von welcher Seite oder von welchem Produkt aus der Nutzer interagiert hat,
- welches Produkt in den Warenkorb gelegt wurde,
- welche SKU letztendlich gekauft wurde,
- welcher Umsatz diesem Pfad zugeordnet werden sollte.
Dadurch kann der Shop Fragen beantworten, auf die Standard-Analytics in der Regel keine Antwort geben:
- Welche
related products-Sektionen verkaufen wirklich? - Welche
upsell- undcross-sell-Blöcke generieren Umsatz? - Welche Blogbeiträge führen zum Verkauf von Produkten?
- Welche Banner, Widgets oder CMS-Sektionen werden nur angeklickt, konvertieren aber nicht?
- Welche Seitenelemente nehmen Platz ein, haben aber keinen Einfluss auf den Verkauf?
Welchen geschäftlichen Mehrwert bietet es
Das Modul wurde für Shops entwickelt, die Merchandising, Content und Seitenlayout auf Grundlage des tatsächlichen Einflusses auf den Verkauf optimieren möchten und nicht nur auf Basis von Traffic oder CTR.
Über die Reports lässt sich bewerten:
- Umsatz per area,
- Anzahl der Bestellungen per area,
- die Effektivität konkreter Objekte innerhalb einer area,
- die Effektivität der Beziehung Produkt -> angeklicktes Produkt -> gekaufte SKU,
- der Einfluss des Blogs auf den Verkauf,
- der Einfluss von First Click, Last Click, Assisted-Anteil und View-through,
- die Quellpfade, die zum Kauf führen.
Was dieses Modul von einfachen Analytics-Pixeln unterscheidet
1. Es misst Verkäufe und nicht nur Aufrufe und Klicks
Ein Klick allein sagt noch nichts über den geschäftlichen Wert aus. Kowal Analytics verbindet Frontend-Ereignisse mit Warenkorb, Bestellung und Umsatz.
2. Es arbeitet mit dem Begriff area
Die grundlegende Einheit der Analyse ist die area, also ein abgegrenzter Seitenbereich, den Sie messen möchten.
Beispiele:
related_productsauf der PDP,upsell_productsauf der PDP,crosssell_productsim Warenkorb,category_listingauf der Produktliste einer Kategorie,search_resultsin den Suchergebnissen,wishlist_products,compare_products,blog_post_listing,blog_sidebar_categories,- eigene Promotions-Box im CMS.
3. Es ermöglicht auch die Analyse von object
In jeder area befinden sich konkrete object, also Elemente, die der Nutzer sieht und anklickt.
Beispiele:
- ein Produkt in der Sektion
related_products, - ein Blogbeitrag in der Beitragsliste,
- eine Blogkategorie in der Sidebar,
- ein Promotions-Banner,
- ein CTA-Link in einer Marketing-Box.
Das bedeutet, dass der Report nicht auf der Ebene endet:
- Die related-Sektion funktioniert
sondern auf die Ebene heruntergeht:
- Produkt X verkauft sich in der related-Sektion am besten
- Blogbeitrag Y führt zur höchsten Anzahl an Bestellungen
4. Es kennt den Quellkontext
Das Modul speichert auch den Quellkontext, also wo der Pfad begonnen hat.
Beispiel:
- der Nutzer befindet sich auf der Produktseite
Affirm Water Bottle, - sieht
related_products, - klickt auf
Zing Jump Rope, - wechselt auf die PDP dieses Produkts,
- legt es in den Warenkorb,
- und kauft schließlich
Zing Jump Rope.
In diesem Fall kann Folgendes angezeigt werden:
source page=Affirm Water Bottle,area=related_products,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope.
Genau diese Analyseebene fehlt in typischen Tools meistens.
Wie die wichtigsten Begriffe zu verstehen sind
Area
Area ist eine Sektion oder ein Block der Seite, die bzw. den Sie als Quelle des Einflusses auf den Verkauf messen möchten.
Beispiele:
- Sektion mit verwandten Produkten,
- Kategorielisting,
- Blog-Widget,
- Blog-Sidebar,
- Promotions-Banner,
- Popup,
- eigener CMS-Block.
Object
Object ist ein konkretes Element innerhalb einer area.
Beispiele:
- ein einzelnes Produkt in einer Liste,
- ein einzelner Blogbeitrag,
- eine einzelne Blogkategorie,
- ein einzelner Tag,
- eine einzelne Folie im Slider,
- ein einzelnes Banner in einer Promotions-Sektion.
Source Page
Source Page ist die Seite, von der aus der Nutzer den mit einer bestimmten area verbundenen Pfad begonnen hat.
Beispiele:
- die Quell-Produktseite für
related_products, - ein Blogbeitrag für einen Link, der zu einem Produkt führt,
- ein Kategorielisting für einen Produktklick,
- Suchergebnisse für ein angeklicktes Produkt.
Purchased SKU
Dies ist die konkrete SKU, die gekauft wurde und der wir den Einfluss einer bestimmten area oder eines object zuordnen.
Welche Bereiche gemessen werden können
Das Modul unterstützt sowohl native Integrationen als auch über Selektoren definierte Bereiche.
Beispiele im E-Commerce
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_products
Beispiele im Content Commerce
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Benutzerdefinierte Beispiele
homepage_promo_boxblack_friday_bannersummer_campaign_sliderai_recommendationscategory_top_cta
Welche Reports der Benutzer erhält
Analytics Dashboard
Dient zur schnellen Übersicht der Ergebnisse.
Es zeigt unter anderem:
- attributed revenue,
- attributed orders,
- CTR,
- top areas,
- top supported products,
- top blog sources.
Area Report
Beantwortet die Frage:
- welcher Bereich funktioniert,
- welche Objekte darin verkaufen,
- aus welchen Quellen der Verkauf entsteht.
Beispiel:
related_productsbringt 12 Bestellungen und 4 800 PLN Umsatz,- das meistverkaufte Produkt ist
WB05-S-Orange, - am häufigsten ist das Produkt
Affirm Water Bottledie Quelle dieses Pfads.
Product Context Report
Dieser Report ist für produktbezogene Bereiche entscheidend.
Er beantwortet die Frage:
- von welchem Quellprodukt aus,
- welches Produkt angeklickt wurde,
- und was letztendlich gekauft wurde.
Beispiel:
source product=Affirm Water Bottle,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope,orders= 7,revenue= 840 PLN.
Blog Commerce Report
Zeigt den Einfluss des Blogs auf den Verkauf.
Er beantwortet Fragen wie:
- welcher Beitrag verkauft,
- welche Blogkategorie verkauft,
- welcher Tag zu Bestellungen führt,
- welche SKU nach dem Einstieg über den Blog gekauft werden.
Beispiel:
- der Beitrag
Wie wählt man eine Trainingsflasche aushat 9 Bestellungen generiert, - die am häufigsten gekaufte SKU nach diesem Beitrag ist
Affirm Water Bottle.
Object Report
Ermöglicht den Einstieg in ein konkretes object.
Beispiel:
- ein konkretes Produkt in
related_products, - ein konkreter Blogbeitrag in
blog_post_listing, - eine konkrete Blogkategorie in der Sidebar.
Der Report zeigt:
- Klicks,
- Bestellungen,
- Umsatz,
- Quellseiten,
- gekaufte SKU, die mit diesem einen object verknüpft sind.
Source Page Report
Dies ist ein Report aus umgekehrter Perspektive.
Statt auf das object zu schauen, betrachten Sie eine einzelne Quellseite und prüfen:
- welche von dieser Seite angeklickten Objekte verkaufen,
- welche SKU später gekauft werden,
- welchen Umsatz diese konkrete Seite als Startpunkt des Pfads generiert hat.
Beispiel:
- die Produktseite
Affirm Water Bottleals source page, - die am besten verkaufenden Objekte von dieser Seite sind zwei Produkte aus
related_products, - der Gesamtumsatz aus diesem Pfad beträgt 1 350 PLN.
Typische Anwendungsszenarien
Optimierung des Merchandisings
Der Shop kann vergleichen, ob:
related_productsbesser verkauft alsupsell_products,- Cross-Sell im Warenkorb den Verkauf tatsächlich abschließt,
- das Kategorielisting zu Produkten führt, die tatsächlich in einer Bestellung enden.
Blog-Analyse
Das Content-Team kann prüfen:
- welche Beiträge zu PDP führen,
- welche Beiträge dabei helfen, ein Produkt in den Warenkorb zu legen,
- welche Beiträge einen tatsächlichen Einfluss auf den Verkauf haben.
Bereinigung des Shop-Layouts
Wenn eine Sektion viele Impressions und einen geringen oder gar keinen Einfluss auf den Umsatz hat, kann bewertet werden, ob sie:
- verbessert werden muss,
- verschoben werden sollte,
- inhaltlich ausgetauscht werden sollte,
- oder vollständig entfernt werden sollte.
Änderungen testen
Nach einer Änderung des Layouts, Widgets, Blogs oder Empfehlungsmechanismus können Sie vergleichen:
- den Zeitraum davor und danach,
- den Einfluss auf die CTR,
- den Einfluss auf Bestellungen,
- den Einfluss auf den Umsatz.
Für wen dieses Modul gedacht ist
Den größten Mehrwert ziehen daraus:
- Inhaber von Magento-Shops,
- E-Commerce-Manager,
- Merchandiser,
- CRO-Teams,
- Content- und SEO-Teams,
- Agenturen, die Magento-Shops weiterentwickeln.
Zusammenfassung
Kowal Analytics macht Storefront-Elemente zu messbaren Verkaufsquellen.
Es ermöglicht den Übergang von der allgemeinen Frage:
- Funktioniert dieser Block?
zur konkreten Frage:
- Welches konkrete Produkt, welcher Beitrag, welche Kategorie oder welche Quellseite generiert Verkäufe und welcher Umsatz steckt dahinter?
Installationsanleitung für Kowal Analytics
Anforderungen
Stellen Sie vor der Installation sicher, dass:
- die Magento-2-Instanz korrekt funktioniert,
- Composer Zugriff auf das Kowal-Paket-Repository hat,
- Sie CLI-Zugriff auf
bin/magentohaben, - in der Umgebung cron und queue consumers ausgeführt werden können,
- die Umgebung korrekt funktionierende Schreibvorgänge in die Datenbank und nach
var/loghat.
Installation über Composer
Fügen Sie das Composer-Repository hinzu:
composer config repositories.kowal composer https://repo.kowal.storeFügen Sie die Zugangsdaten für das private Repository hinzu:
composer config http-basic.repo.kowal.store Installieren Sie das Modul:
composer require kowal/module-analyticsAktivierung des Moduls
Führen Sie die Standardbefehle von Magento aus:
bin/magento module:enable Kowal_Analyticsbin/magento setup:upgradebin/magento cache:flushWenn der Shop im production mode läuft, führen Sie zusätzlich aus:
bin/magento setup:di:compilebin/magento setup:static-content:deploy -fbin/magento cache:flushStart der asynchronen Prozesse
Das Modul nutzt Queues und asynchrone Verarbeitung. Ohne diese sind Dashboard und Reports nicht vollständig.
Starten Sie die erforderlichen Consumer:
bin/magento queue:consumers:start kowal_analytics.raw_eventsbin/magento queue:consumers:start kowal_analytics.conversionbin/magento queue:consumers:start kowal_analytics.attributionAuch Magento cron muss korrekt funktionieren, da das Modul Retry und Backfill für die Attribution verwendet.
Grundlegende Prüfung:
bin/magento cron:runWas nach der Installation passiert
Nach erfolgreicher Installation lädt das Modul:
- den Tracker in der Storefront,
- speichert Frontend-Events,
- verknüpft die Analytics-Session mit
quote, - überträgt Analytics-Identifikatoren nach
sales_order, - speichert Conversions und Conversion-Positionen,
- berechnet die Bestellattribution für area und object,
- stellt Dashboard sowie detaillierte Reports im Magento-Panel bereit.
Wo Sie prüfen können, ob das Modul funktioniert
Prüfen Sie nach der Installation:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Wenn das Modul korrekt aktiv ist, sollten Sie Folgendes sehen:
- das Dashboard des Moduls,
- ein zusammenfassendes Widget auf dem nativen Magento-Dashboard,
- eine Konfigurationssektion unter Stores -> Configuration.
Empfohlener technischer Test nach der Implementierung
Führen Sie einen einfachen End-to-End-Test durch:
- Öffnen Sie die Shop-Seite.
- Öffnen Sie eine Produktseite.
- Klicken Sie auf ein getracktes Element, zum Beispiel ein Produkt in
related_productsoder einen Blogbeitrag. - Legen Sie das Produkt in den Warenkorb.
- Schließen Sie die Bestellung ab.
- Prüfen Sie, ob Events, Conversions und Attribution gespeichert wurden.
Wenn Debug aktiviert ist, prüfen Sie:
- die Logs in der Browserkonsole,
var/log/kowal_analytics_debug.log
Was im HTML geprüft werden sollte
Wenn Sie bestätigen möchten, dass das Tracking beim Rendern der Seite funktioniert, prüfen Sie das Vorhandensein der Attribute:
data-kowal-track-areadata-kowal-track-area-iddata-kowal-track-objectdata-kowal-track-iddata-kowal-track-sku
Beispiel:
- der Container der Sektion
related_productssolltedata-kowal-track-area='related_products'haben - ein einzelnes Produkt in dieser Sektion sollte
data-kowal-track-object='product'und eine eigenedata-kowal-track-idhaben
Typische Probleme nach der Installation
Dashboard ist sichtbar, aber es gibt keine Daten
Prüfen Sie:
- ob die Consumer laufen,
- ob cron läuft,
- ob Analytics in der Konfiguration aktiviert ist,
- ob der Tracker im Frontend geladen wird,
- ob auf der Seite tatsächlich getrackte areas vorhanden sind.
Ereignisse werden gespeichert, aber die Attribution ist unvollständig
Prüfen Sie:
- ob der Consumer
kowal_analytics.attributionläuft, - ob cron retry funktioniert,
- ob die Quell-Events vor der finalen Berechnung der Attribution in der Datenbank ankommen.
Custom area erscheint nicht in den Reports
Prüfen Sie:
- ob die area-Definition korrekt gespeichert wurde,
- ob die Selektoren mit dem tatsächlichen DOM übereinstimmen,
- ob runtime apply
data-kowal-track-*hinzufügt, - ob der betreffende Bereich Objekt-Identifikatoren hat, die für die weitere Analyse benötigt werden.
Empfehlung für die Implementierung
Die sicherste Reihenfolge ist folgende:
- das Modul installieren,
- Consumer und cron starten,
- Debug aktivieren,
- ein einfaches Produktszenario testen,
- das Dashboard prüfen,
- und erst danach das Tracking auf custom area erweitern.
Konfigurationsanleitung für Kowal Analytics
Navigation im Admin-Panel
Haupteinstiege in das Modul:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Konfigurationsstruktur
Aktuell stellt das Modul drei Hauptgruppen von Einstellungen bereit.
1. General
Pfad:
Stores -> Configuration -> Analytics -> General
Feld:
Enable Analytics
Bedeutung:
- aktiviert oder deaktiviert das Frontend-Tracking und die weitere Analytics-Verarbeitung für den ausgewählten scope.
Empfehlung:
- am besten per
store viewaktivieren, nachdem die Funktion der Tracker und Consumer zuvor überprüft wurde.
2. Debug
Pfad:
Stores -> Configuration -> Analytics -> Debug
Felder:
Enable Backend Debug LogEnable Frontend Console Log
Bedeutung:
- Backend-Debug speichert technische Logs in:
var/log/kowal_analytics_debug.log
- Frontend-Debug speichert Tracker-Logs in der Browserkonsole.
Anwendungsfälle:
- Installation,
- QA,
- Fehleranalyse,
- Tests des Selector Assistant,
- Bestätigung, dass Events in die Pipeline gelangen.
Empfehlung:
- während der Implementierung und Tests aktivieren,
- in der Produktionsumgebung nach Abschluss der Validierung deaktivieren.
3. Tools
Pfad:
Stores -> Configuration -> Analytics -> Tools
Feld:
Enable Frontend Selector Assistant
Bedeutung:
- zeigt einen Helfer in der Storefront an, der beim Auswählen und Vorbereiten der Konfiguration für eigene, auf Selektoren basierende areas hilft.
Anwendungsfälle:
- Mapping von custom sections,
- Analyse der DOM-Struktur,
- Vorbereitung von area-Definitionen ohne manuelle Codebearbeitung.
Wie die Konfiguration in der Praxis zu verstehen ist
Scope
Das Modul arbeitet im Magento-scope, daher kann die Konfiguration unterschiedlich sein für:
default,website,store view.
Am sichersten ist es, das Modul als Werkzeug per store view zu behandeln, weil:
- verschiedene Shops unterschiedliche Layouts haben können,
- verschiedene Shops unterschiedliche Blog-, CMS- und Merchandising-Sektionen haben können,
- Reports per store view operativ deutlich verlässlicher sind.
Wie die grundlegenden Begriffe im Modul zu verstehen sind
Area
Area ist ein abgegrenzter Bereich der Seite, den Sie als Quelle des Einflusses auf den Verkauf messen möchten.
Beispiele:
related_productsupsell_productscrosssell_productscategory_listingsearch_resultswishlist_productscompare_productsblog_post_listingblog_sidebar_categorieshomepage_promo_box
Object
Object ist ein konkretes Element innerhalb einer area.
Beispiele:
- ein einzelnes Produkt in einer Liste,
- ein einzelner Blogbeitrag,
- eine einzelne Blogkategorie,
- ein einzelner Tag,
- ein einzelnes Banner,
- eine einzelne Folie.
Source Page
Source Page ist die Seite, von der aus der Nutzer eine Interaktion begonnen hat, die weiter zu einem Verkauf führt.
Beispiele:
- die Quell-Produktseite für
related_products, - ein Blogbeitrag für das angeklickte Produkt,
- ein Kategorielisting für das angeklickte Produkt,
- Suchergebnisse für das Produkt.
Dashboard und Reports
Analytics Dashboard
Dies ist der wichtigste Übersichtsbildschirm. Er zeigt:
- attributed revenue,
- attributed orders,
- average order value,
- CTR,
- top areas,
- top supported products,
- top blog sources,
- Links zu detaillierten Reports.
Dieser Bildschirm beantwortet die Frage:
was funktioniert am besten
Area Report
Dieser Report beantwortet die Fragen:
- welche area Umsatz generiert,
- welche object in dieser area verkaufen,
- von welchen source page der Verkauf stammt.
Beispiel:
related_productshat 18 Bestellungen,- am besten verkauft sich darin
Zing Jump Rope, - am häufigsten ist die Produktseite
Affirm Water Bottledie Quelle dieses Pfads.
Product Context Report
Dies ist ein Report für produktbezogene Bereiche wie:
related_productsupsell_productscrosssell_productscategory_listingsearch_results
Er zeigt die Abhängigkeit:
source product -> clicked object -> purchased SKU
Beispiel:
- der Nutzer befindet sich auf der PDP
Affirm Water Bottle, - klickt auf
WB05-S-Orangeinrelated_products, - kauft
WB05-S-Orange.
Blog Commerce Report
Dies ist ein Report für Blog-Bereiche:
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Er beantwortet Fragen wie:
- welcher Post verkauft,
- welche Blogkategorie verkauft,
- welcher Tag den Verkauf unterstützt,
- welche SKU nach dem Einstieg über den Blog gekauft werden.
Object Report
Dies ist ein Report für ein einzelnes konkretes object.
Beispiel:
- ein Produkt in
related_products, - ein Blogbeitrag aus
blog_post_listing, - eine Blogkategorie aus
blog_sidebar_categories.
Er zeigt:
- wie viele Impressions es hatte,
- wie viele Klicks es hatte,
- wie viele Bestellungen es generiert hat,
- welcher Umsatz ihm zugeordnet wurde,
- von welchen source page diese Pfade stammten.
Source Page Report
Dies ist ein Report für eine einzelne konkrete Quellseite.
Beispiel:
- die Produktseite
Affirm Water Bottle, - der Blogbeitrag
Wie wählt man eine Trainingsflasche aus, - das Kategorielisting
Laufschuhe.
Er zeigt:
- welche clicked object von dieser Seite aus verkaufen,
- welche SKU nach dem Einstieg über diese Seite gekauft werden,
- wie viele Bestellungen und wie viel Umsatz diese konkrete Seite als Startpunkt des Pfads generiert.
Attributionsmodelle
Verfügbare Modelle:
Last ClickFirst ClickAssistedView Through
So sind sie zu lesen:
Last Click
Am besten geeignet für die Frage:
- welches Element den Verkauf direkt abgeschlossen hat.
First Click
Am besten geeignet für die Frage:
- welches Element den zum Kauf führenden Pfad gestartet hat.
Assisted
Am besten geeignet für die Frage:
- welches Element am Pfad beteiligt war, auch wenn es nicht der letzte Klick war.
View Through
Am besten geeignet für die Frage:
- ob die bloße Sichtbarkeit einer Sektion den Verkauf beeinflusst hat, auch ohne Klick.
Konfiguration von custom area
Eine custom area können Sie über den Frontend Selector Assistant vorbereiten.
Typischer Workflow:
Enable Frontend Selector Assistantaktivieren.- Die Storefront öffnen.
- Den Assistant starten.
- Den Bereich auswählen.
- Den vorgeschlagenen
container selectorprüfen. - Den vorgeschlagenen
item selectorprüfen. - Den
link selectorprüfen. - Die Definition speichern.
- Bestätigen, dass runtime apply
data-kowal-track-*hinzugefügt hat. - Den Klick und den Übergang zu den Reports testen.
Beispiel für eine custom area
Angenommen, auf der Startseite haben Sie eine Promotions-Box mit drei Kacheln.
Sie können definieren:
area_code = homepage_promo_boxobject_type = promotioncontainer_selector = .homepage-promoitem_selector = .homepage-promo__itemlink_selector = .homepage-promo__link
Dann zeigt der Report:
- welche Kachel angeklickt wurde,
- welche zum Kauf geführt hat,
- welchen Umsatz sie generiert hat.
Test-Workflow nach der Konfiguration
Die sinnvollste Reihenfolge ist:
- Analytics aktivieren,
- Backend-Debug aktivieren,
- Frontend Console Log aktivieren,
- das Benutzerszenario durchgehen,
- das Dashboard prüfen,
- den area-Report prüfen,
- zum object report oder source page report wechseln,
- Debug nach Bestätigung der Korrektheit deaktivieren.
Betriebliche Empfehlungen
- Consumer unter supervisor oder systemd betreiben,
- darauf achten, dass Magento cron dauerhaft läuft,
- nach Theme-Änderungen prüfen, ob die Selektoren der custom area noch zum DOM passen,
- nach Merchandising-Änderungen die Ergebnisse per area vergleichen,
- CTR allein nicht als Erfolg interpretieren, ohne Umsatz und Bestellungen zu prüfen.
























