Kowal Analytics für Magento 2
- SKU
- M2-ANALIZA
Beschreibung / Kowal Analytics für Magento 2
MAGENTO 2 · ATTRIBUTION · UMSATZ
Sehen Sie, welche Elemente Ihres Shops zum Verkauf führen.
Kowal Analytics
Verknüpfen Sie Impressionen und Klicks mit Warenkorb, Bestellung und Umsatz. Bewerten Sie verwandte Produkte, Blog, Banner und eigene Bereiche anhand der ihnen zugeordneten Verkäufe.
Area und Object · Quellkontext · Verkaufsberichte
So funktioniert es in der Praxis
01 · Der Kunde sieht und klickt
Der Tracker speichert die Interaktion mit dem gemessenen Bereich und Objekt.
02 · Das Produkt landet in der Bestellung
Die Analytics-Session verbindet Ereignisse mit dem Warenkorb und der gekauften SKU.
03 · Sie bewerten den zugeordneten Umsatz
Dashboard und Berichte zeigen die Ergebnisse nach Attributionsmodell.
Was gewinnt Ihr Shop?
Prüfen Sie den Einfluss von Merchandising, Inhalten und Shop-Layout auf Bestellungen und Umsatz.
Was ist dieses Modul?
Kowal Analytics ist ein Modul zur Umsatzattribution für Magento 2. Es zeigt, welche Elemente des Shops tatsächlich Warenkorb, Bestellung und Umsatz beeinflussen.
Es ist kein gewöhnliches Pixel, das Seitenaufrufe sammelt. Das Modul analysiert den vollständigen Verkaufskontext:
- 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 letztlich gekauft wurde,
- welcher Umsatz dieser Journey zugeordnet werden soll.
Dadurch kann der Shop Fragen beantworten, die Standard-Analytics in der Regel nicht beantworten:
- Welche
related products-Sektionen verkaufen wirklich? - Welche
upsell- undcross-sell-Blöcke generieren Umsatz? - Welche Blogbeiträge führen zu Produktverkäufen?
- Welche Banner, Widgets oder CMS-Sektionen werden zwar geklickt, konvertieren aber nicht?
- Welche Seitenelemente nehmen Platz ein, haben aber keinen Einfluss auf den Verkauf?
Welchen Geschäftswert bietet das Modul?
Das Modul wurde für Shops entwickelt, die Merchandising, Content und Seitenlayout anhand des tatsächlichen Einflusses auf Verkäufe optimieren möchten, nicht nur anhand von Traffic oder CTR.
Über die Berichte können Sie bewerten:
- Umsatz pro area,
- Anzahl der Bestellungen pro area,
- Wirksamkeit einzelner Objekte innerhalb einer bestimmten area,
- Wirksamkeit der Beziehung Produkt -> geklicktes Produkt -> gekaufte SKU,
- Einfluss des Blogs auf Verkäufe,
- Einfluss von First Click, Last Click, unterstützendem Anteil und View-through,
- Quellpfade, die zum Kauf führen.
Was unterscheidet dieses Modul von einfachen analytics pixel?
1. Es misst Verkäufe, nicht nur Aufrufe und Klicks
Ein Klick allein sagt noch nichts über den Geschäftswert aus. Kowal Analytics verknüpft Frontend-Ereignisse mit Warenkorb, Bestellung und Umsatz.
2. Es arbeitet mit dem Begriff area
Die grundlegende Analyseeinheit ist 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,- eine eigene Promo-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 Promotion-Banner,
- ein CTA-Link in einer Marketing-Box.
Das bedeutet, dass der Bericht nicht auf der Ebene endet:
- „die related-Sektion funktioniert“
sondern bis auf diese Ebene heruntergeht:
- „Produkt X in der related-Sektion verkauft am besten“
- „Blogbeitrag Y führt zu den meisten 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
Zing Jump Rope, - wechselt zur PDP dieses Produkts,
- legt es in den Warenkorb,
- kauft schließlich
Zing Jump Rope.
In diesem Fall kann angezeigt werden:
source page=Affirm Water Bottle,area=related_products,clicked object=Zing Jump Rope,purchased sku=Zing Jump Rope.
Das ist genau die Analyseebene, die in typischen Tools meist fehlt.
Die wichtigsten Begriffe verstehen
Area
Area ist eine Sektion oder ein Seitenblock, den Sie als Quelle des Verkaufseinflusses messen möchten.
Beispiele:
- Sektion für verwandte Produkte,
- Kategorie-Listing,
- Blog-Widget,
- Blog-Sidebar,
- Promotion-Banner,
- Popup,
- eigener CMS-Block.
Object
Object ist ein konkretes Element innerhalb einer area.
Beispiele:
- ein Produkt auf einer Liste,
- ein Blogbeitrag,
- eine Blogkategorie,
- ein Tag,
- ein Slide in einem Slider,
- ein Banner in einer Promotion-Sektion.
Source Page
Source Page ist die Seite, von der aus der Nutzer den mit einer bestimmten area verbundenen Pfad gestartet hat.
Beispiele:
- Produktseite des Quellprodukts für
related_products, - Blogbeitrag für einen Link, der zu einem Produkt führt,
- Kategorie-Listing 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 bestimmten object zuordnen.
Welche Bereiche können gemessen werden?
Das Modul unterstützt sowohl native Integrationen als auch Bereiche, die über Selektoren definiert werden.
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
Individuelle Beispiele
homepage_promo_boxblack_friday_bannersummer_campaign_sliderai_recommendationscategory_top_cta
Welche Berichte erhält der Nutzer?
Analytics Dashboard
Dient der schnellen Ergebnisübersicht.
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 die Verkäufe entstehen.
Beispiel:
related_productsbringt 12 Bestellungen und 4 800 PLN Umsatz,- am besten verkauft sich das Produkt
WB05-S-Orange, - die häufigste Quelle dieses Pfads ist das Produkt
Affirm Water Bottle.
Product Context Report
Dieser Bericht ist entscheidend für Produktbereiche.
Er beantwortet die Frage:
- von welchem Quellprodukt aus,
- welches Produkt angeklickt wurde,
- und was letztlich 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 Verkäufe.
Er beantwortet die Fragen:
- 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
Jak wybrać bidon treningowyhat 9 Bestellungen generiert, - die nach diesem Beitrag am häufigsten gekaufte SKU ist
Affirm Water Bottle.
Object Report
Ermöglicht den Einstieg in ein konkretes Objekt.
Beispiel:
- ein konkretes Produkt in
related_products, - ein konkreter Blogbeitrag in
blog_post_listing, - eine konkrete Blogkategorie in der Sidebar.
Der Bericht zeigt:
- Klicks,
- Bestellungen,
- Umsatz,
- Quellseiten,
- gekaufte SKU, die mit diesem einen Objekt verbunden sind.
Source Page Report
Das ist ein Bericht aus der umgekehrten Perspektive.
Statt auf das Objekt zu schauen, betrachten Sie eine Quellseite und prüfen:
- welche von dieser Seite aus geklickten Objekte verkaufen,
- welche SKU später gekauft werden,
- welchen Umsatz diese konkrete Seite als Startpunkt des Pfads generiert hat.
Beispiel:
- Produktseite
Affirm Water Bottleals source page, - die bestverkaufenden Objekte von dieser Seite sind zwei Produkte aus
related_products, - der Gesamtumsatz aus diesem Pfad beträgt 1 350 PLN.
Typische Einsatzszenarien
Merchandising-Optimierung
Der Shop kann vergleichen, ob:
related_productsbesser verkauft alsupsell_products,- Cross-Sell im Warenkorb den Verkauf wirklich abschließt,
- das Kategorie-Listing zu Produkten führt, die tatsächlich in Bestellungen enden.
Blog-Analyse
Das Content-Team kann prüfen:
- welche Beiträge zur PDP führen,
- welche Beiträge dabei helfen, ein Produkt in den Warenkorb zu legen,
- welche Beiträge realen Einfluss auf Verkäufe haben.
Bereinigung des Shop-Layouts
Wenn eine Sektion hohe Impressionen und einen niedrigen oder keinen Einfluss auf den Umsatz hat, können Sie bewerten, ob sie:
- verbessert werden muss,
- verschoben werden sollte,
- mit anderem Inhalt befüllt werden sollte,
- oder vollständig entfernt werden sollte.
Änderungen testen
Nach einer Änderung am Layout, Widget, Blog oder Empfehlungsmechanismus können Sie vergleichen:
- den früheren und späteren Zeitraum,
- den Einfluss auf die CTR,
- den Einfluss auf Bestellungen,
- den Einfluss auf Umsatz.
Für wen ist dieses Modul?
Den größten Nutzen ziehen daraus:
- Betreiber von Magento-Shops,
- E-Commerce-Manager,
- Merchandiser,
- CRO-Teams,
- Content- und SEO-Teams,
- Agenturen, die Magento-Shops weiterentwickeln.
Zusammenfassung
Kowal Analytics verwandelt Storefront-Elemente in messbare Verkaufsquellen.
Es ermöglicht den Wechsel von der allgemeinen Frage:
- „funktioniert dieser Block?“
zur konkreten Frage:
- „welches Produkt, welcher Beitrag, welche Kategorie oder welche Quellseite generiert genau Verkäufe und welcher Umsatz steckt dahinter?“
Konfiguration und eigene Bereiche
Unter Stores → Configuration → Kowal → Analytics aktivieren Sie das Modul für den passenden Scope. Der Frontend Selector Assistant hilft dabei, einen eigenen Bereich zu markieren und Selektoren für Container, Elemente und Links vorzubereiten.
Die Modelle Last Click, First Click, Assisted und View Through ermöglichen die Analyse des letzten Klicks, des ersten Klicks, des unterstützenden Anteils und der Exposition ohne Klick. Es handelt sich um Modelle zur Zuordnung des Verkaufseinflusses; ihre Ergebnisse werden im Kontext des gewählten Modells gelesen.
Verarbeitung und Start der Berichte
Vollständige Berichte erfordern einen funktionierenden Magento cron sowie die Consumer kowal_analytics.raw_events, kowal_analytics.conversion und kowal_analytics.attribution. Ereignisse und Konversionen werden asynchron verarbeitet.
Während der Implementierung können Sie das Backend-Log und Logs in der Browserkonsole aktivieren. Prüfen Sie nach einem Theme-Wechsel die Selektoren eigener Bereiche und durchlaufen Sie das Szenario vom Klick bis zur Bestellung, um die Berichte zu verifizieren.
Installation über Composer
Paket: kowal/module-analytics; Modul: Kowal_Analytics. Nachdem Sie den Zugriff auf das Kowal-Repository konfiguriert haben, installieren Sie das Paket, aktivieren Sie das Modul, führen Sie das Magento-Update aus und leeren Sie den Cache. Berücksichtigen Sie für den Produktionsmodus die Kompilierung und die Bereitstellung statischer Inhalte entsprechend der Umgebung.
Von der Konfiguration zum Ergebnis
1. Der Kunde sieht und klickt
Der Tracker speichert die Interaktion mit dem gemessenen Bereich und Objekt.
2. Das Produkt landet in der Bestellung
Die Analytics-Session verbindet Ereignisse mit dem Warenkorb und der gekauften SKU.
3. Sie bewerten den zugeordneten Umsatz
Dashboard und Berichte zeigen die Ergebnisse nach Attributionsmodell.
Von der Empfehlung zur gekauften SKU
Beispiel: Der Kunde betrachtet Affirm Water Bottle, klickt Zing Jump Rope in der Sektion für verwandte Produkte und kauft dieses Produkt.
Der Bericht verbindet Quellseite, Bereich, geklicktes Objekt und gekaufte SKU. Der vom Attributionsmodell zugeordnete Umsatz hilft dabei, Kaufpfade zu vergleichen.
Treffen Sie Entscheidungen zum Shop-Layout auf Basis von Verkäufen
Möchten Sie das Modul an Ihren Shop anpassen? Fragen Sie nach der Implementierung von Kowal Analytics und besprechen Sie die Konfiguration oder benötigte Erweiterungen.
Weitere Informationen
| Addtocart Description | |
|---|---|
| Übereinstimmung mit der Vorlage | Luma / Leer, KOWAL |
Konfiguration der Integration
Konfigurationsanleitung für Kowal Analytics
Navigation im Administrationspanel
Haupteinstiege in das Modul:
Kowal -> Analytics -> DashboardStores -> Configuration -> Analytics
Konfigurationsstruktur
Derzeit stellt das Modul drei Hauptgruppen von Einstellungen bereit.
1. General
Pfad:
Stores -> Configuration -> Analytics -> General
Feld:
Enable Analytics
Bedeutung:
- aktiviert oder deaktiviert Frontend-Tracking und die weitere Analytics-Verarbeitung für den ausgewählten scope.
Empfehlung:
- am besten pro
store viewaktivieren, nachdem Tracker und Consumer zuvor verifiziert wurden.
2. Debug
Pfad:
Stores -> Configuration -> Analytics -> Debug
Felder:
Enable Backend Debug LogEnable Frontend Console Log
Bedeutung:
- Backend-Debug speichert technische Logs unter:
var/log/kowal_analytics_debug.log
- Frontend-Debug speichert Tracker-Logs in der Browserkonsole.
Anwendung:
- Installation,
- QA,
- Fehleranalyse,
- Tests des selector assistanta,
- Bestätigung, dass Events in die Pipeline gelangen.
Empfehlung:
- für die Dauer 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 Helper in der Storefront an, der dabei hilft, die Konfiguration für eigene selector-basierte area zu markieren und vorzubereiten.
Anwendung:
- Mapping von custom section,
- Analyse der DOM-Struktur,
- Vorbereitung von area-Definitionen ohne manuelle Codebearbeitung.
Konfiguration in der Praxis verstehen
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 Tool pro store view zu behandeln, weil:
- verschiedene Shops unterschiedliche Layouts haben können,
- verschiedene Shops andere Blog-, CMS- und Merchandising-Sektionen haben können,
- Berichte pro store view operativ deutlich verlässlicher sind.
Grundbegriffe im Modul verstehen
Area
Area ist ein abgegrenzter Seitenbereich, den Sie als Quelle des Verkaufseinflusses 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 auf einer Liste,
- ein Blogbeitrag,
- eine Blogkategorie,
- ein Tag,
- ein Banner,
- ein Slide.
Source Page
Source Page ist die Seite, von der aus der Nutzer eine Interaktion gestartet hat, die weiter zum Verkauf führt.
Beispiele:
- Produktseite des Quellprodukts für
related_products, - Blogbeitrag für das angeklickte Produkt,
- Kategorie-Listing für das angeklickte Produkt,
- Suchergebnisse für ein Produkt.
Dashboard und Berichte
Analytics Dashboard
Dies ist die zentrale Übersichtsseite. Sie zeigt:
- attributed revenue,
- attributed orders,
- average order value,
- CTR,
- top areas,
- top supported products,
- top blog sources,
- Links zu Detailberichten.
Diese Ansicht beantwortet die Frage:
co działa najlepiej
Area Report
Dieser Bericht beantwortet die Fragen:
- welche area Umsatz generiert,
- welche object in dieser area verkaufen,
- aus welchen source page die Verkäufe stammen.
Beispiel:
related_productshat 18 Bestellungen,- am besten verkauft sich darin
Zing Jump Rope, - die häufigste Quelle dieses Pfads ist die Produktseite
Affirm Water Bottle.
Product Context Report
Dies ist ein Bericht für Produktbereiche wie:
related_productsupsell_productscrosssell_productscategory_listingsearch_results
Er zeigt die Beziehung:
source product -> clicked object -> purchased SKU
Beispiel:
- der Nutzer befindet sich auf der PDP
Affirm Water Bottle, - klickt
WB05-S-Orangeinrelated_products, - kauft
WB05-S-Orange.
Blog Commerce Report
Dies ist ein Bericht für Blogbereiche:
blog_post_listingblog_recent_posts_widgetblog_sidebar_recent_postsblog_sidebar_categoriesblog_sidebar_tagsblog_post_view
Er beantwortet die Fragen:
- 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 Bericht für ein konkretes object.
Beispiel:
- ein Produkt in
related_products, - ein Blogbeitrag aus
blog_post_listing, - eine Blogkategorie aus
blog_sidebar_categories.
Er zeigt:
- wie viele Impressionen 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 Bericht für eine konkrete Quellseite.
Beispiel:
- Produktseite
Affirm Water Bottle, - Blogbeitrag
Jak wybrać bidon treningowy, - Kategorie-Listing
Buty do biegania.
Er zeigt:
- welche clicked object von dieser Seite verkaufen,
- welche SKU nach dem Einstieg über diese Seite gekauft werden,
- wie viele Bestellungen und welchen Umsatz diese konkrete Seite als Startpunkt des Pfads generiert.
Attributionsmodelle
Verfügbare Modelle:
Last ClickFirst ClickAssistedView Through
So lesen Sie sie:
Last Click
Am besten für die Frage:
- welches Element den Verkauf direkt abgeschlossen hat.
First Click
Am besten für die Frage:
- welches Element den Pfad zum Kauf gestartet hat.
Assisted
Am besten für die Frage:
- welches Element am Pfad beteiligt war, auch wenn es nicht der letzte Klick war.
View Through
Am besten für die Frage:
- ob allein die Exposition einer Sektion Einfluss auf den Verkauf hatte, auch ohne Klick.
Konfiguration von custom area
Custom area können Sie über den Frontend Selector Assistant vorbereiten.
Typischer Workflow:
Enable Frontend Selector Assistantaktivieren.- Storefront öffnen.
- Assistant starten.
- Bereich markieren.
- Vorgeschlagenen
container selectorprüfen. - Vorgeschlagenen
item selectorprüfen. link selectorprüfen.- Definition speichern.
- Bestätigen, dass runtime apply
data-kowal-track-*hinzugefügt hat. - Klick testen und zu den Berichten wechseln.
Beispiel für custom area
Angenommen, auf der Startseite befindet sich eine Promo-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 Bericht:
- welche Kachel geklickt wurde,
- welche zum Kauf geführt hat,
- welchen Umsatz sie generiert hat.
Test-Workflow nach der Konfiguration
Die sinnvollste Reihenfolge:
- analytics aktivieren,
- backend debug aktivieren,
- frontend console log aktivieren,
- Nutzerszenario durchlaufen,
- Dashboard prüfen,
- area report prüfen,
- zum object report oder source page report wechseln,
- Debug nach Bestätigung der Korrektheit deaktivieren.
Operative Empfehlungen
- Consumer unter supervisor oder systemd betreiben,
- sicherstellen, dass Magento cron dauerhaft läuft,
- nach Theme-Änderungen prüfen, ob die Selektoren für custom area weiterhin zum DOM passen,
- nach Merchandising-Änderungen Ergebnisse pro area vergleichen,
- CTR nicht allein als Erfolg interpretieren, ohne Umsatz und Bestellungen zu prüfen.
Installationsanleitung für das Modul
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 in die Datenbank und nach
var/logschreiben kann.
Installation über Composer
Fügen Sie das Composer-Repository hinzu:
Die Zugangsdaten zum Composer-Repository (E-Mail-Adresse des Kunden und Lizenz-Token) erhalten Sie nach dem Kauf per E-Mail. Sie sind außerdem nach der Anmeldung im Kundenpanel unter kowal.store verfügbar. Ersetzen Sie TWOJ_EMAIL_KLIENTA durch die E-Mail-Adresse Ihres Kontos und TWOJ_TOKEN durch den erhaltenen Token. Führen Sie die Befehle im Magento-Stammverzeichnis aus.
composer config repositories.kowal composer https://repo.kowal.storeFügen Sie die Zugangsdaten zum privaten Repository hinzu:
composer config http-basic.repo.kowal.store 'TWOJ_EMAIL_KLIENTA' 'TWOJ_TOKEN'Installieren Sie das Modul:
composer require kowal/module-analyticsModul aktivieren
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:flushAsynchrone Prozesse starten
Das Modul verwendet Queues und asynchrone Verarbeitung. Ohne diese sind Dashboard und Berichte 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.attributionMagento cron muss ebenfalls korrekt funktionieren, da das Modul retry und backfill für die Attribution verwendet.
Grundprüfung:
bin/magento cron:runWas nach der Installation passiert
Nach korrekter Installation:
- lädt das Modul den Tracker in die Storefront,
- speichert Frontend-Events,
- verknüpft die Analytics-Session mit
quote, - überträgt Analytics-IDs nach
sales_order, - speichert Konversionen und Konversionspositionen,
- berechnet die Attribution von Bestellungen zu area und object,
- stellt Dashboard und detaillierte Berichte 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 sehen:
- das Modul-Dashboard,
- ein Zusammenfassungs-Widget auf dem nativen Magento-Dashboard,
- den Konfigurationsbereich unter Stores -> Configuration.
Empfohlener technischer Test nach der Implementierung
Führen Sie einen einfachen End-to-End-Test aus:
- Öffnen Sie die Shopseite.
- Gehen Sie auf eine Produktseite.
- Klicken Sie auf ein getracktes Element, zum Beispiel ein Produkt in
related_productsoder einen Blogbeitrag. - Legen Sie das Produkt in den Warenkorb.
- Geben Sie eine Bestellung auf.
- Prüfen Sie, ob Events, Konversionen und Attribution gespeichert wurden.
Wenn Debug aktiviert ist, prüfen Sie:
- Logs in der Browserkonsole,
var/log/kowal_analytics_debug.log
Was Sie im HTML prüfen sollten
Wenn Sie bestätigen möchten, dass 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 ein eigenesdata-kowal-track-idhaben
Typische Probleme nach der Installation
Das 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 es auf der Seite tatsächlich getrackte area gibt.
Ereignisse werden gespeichert, aber die Attribution ist unvollständig
Prüfen Sie:
- ob der Consumer
kowal_analytics.attributionläuft, - ob cron retry funktioniert,
- ob Quell-Events vor der finalen Neuberechnung der Attribution in der Datenbank ankommen.
Custom area erscheint nicht in den Berichten
Prüfen Sie:
- ob die area-Definition korrekt gespeichert wurde,
- ob die Selektoren mit dem realen DOM übereinstimmen,
- ob runtime apply
data-kowal-track-*hinzufügt, - ob der betreffende Bereich Objekt-IDs hat, die für die weitere Analyse benötigt werden.
Empfehlung für die Implementierung
Die sicherste Reihenfolge ist:
- Modul installieren,
- Consumer und cron starten,
- Debug aktivieren,
- ein einfaches Produktszenario testen,
- Dashboard prüfen,
- erst danach Tracking auf custom area erweitern.