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

Kowal Analytics für Magento 2

30,75 € 25,00 €
Installation von COMPOSER
M2-ANALIZA
Erfordert Änderungen an der Vorlage
Nein
Kleine Änderungen
Wesentliche Änderungen
Erfordert Programmierkenntnisse
Nein
Grundlegend
Erweitert
Schwierigkeiten bei der Konfiguration
Auswirkungen auf die Leistung
Kompatibilität mit Magento-Standards
  • Polnisch Polnisch
  • Englisch Englisch
  • 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

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- und cross-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_products auf der PDP,
  • upsell_products auf der PDP,
  • crosssell_products im Warenkorb,
  • category_listing auf der Produktliste einer Kategorie,
  • search_results in 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:

  1. der Nutzer befindet sich auf der Produktseite Affirm Water Bottle,
  2. sieht related_products,
  3. klickt auf Zing Jump Rope,
  4. wechselt auf die PDP dieses Produkts,
  5. legt es in den Warenkorb,
  6. 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_products
  • upsell_products
  • crosssell_products
  • category_listing
  • search_results
  • wishlist_products
  • compare_products

Beispiele im Content Commerce

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

Benutzerdefinierte Beispiele

  • homepage_promo_box
  • black_friday_banner
  • summer_campaign_slider
  • ai_recommendations
  • category_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_products bringt 12 Bestellungen und 4 800 PLN Umsatz,
  • das meistverkaufte Produkt ist WB05-S-Orange,
  • am häufigsten ist das Produkt Affirm Water Bottle die 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 aus hat 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 Bottle als 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_products besser verkauft als upsell_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/magento haben,
  • in der Umgebung cron und queue consumers ausgeführt werden können,
  • die Umgebung korrekt funktionierende Schreibvorgänge in die Datenbank und nach var/log hat.

Installation über Composer

Fügen Sie das Composer-Repository hinzu:

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

Fü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-analytics

Aktivierung des Moduls

Führen Sie die Standardbefehle von Magento aus:

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

Wenn 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:flush

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

Auch Magento cron muss korrekt funktionieren, da das Modul Retry und Backfill für die Attribution verwendet.

Grundlegende Prüfung:

bin/magento cron:run

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

  1. Öffnen Sie die Shop-Seite.
  2. Öffnen Sie eine Produktseite.
  3. Klicken Sie auf ein getracktes Element, zum Beispiel ein Produkt in related_products oder einen Blogbeitrag.
  4. Legen Sie das Produkt in den Warenkorb.
  5. Schließen Sie die Bestellung ab.
  6. 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-area
  • data-kowal-track-area-id
  • data-kowal-track-object
  • data-kowal-track-id
  • data-kowal-track-sku

Beispiel:

  • der Container der Sektion related_products sollte data-kowal-track-area='related_products' haben
  • ein einzelnes Produkt in dieser Sektion sollte data-kowal-track-object='product' und eine eigene data-kowal-track-id haben

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.attribution lä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:

  1. das Modul installieren,
  2. Consumer und cron starten,
  3. Debug aktivieren,
  4. ein einfaches Produktszenario testen,
  5. das Dashboard prüfen,
  6. und erst danach das Tracking auf custom area erweitern.

Konfigurationsanleitung für Kowal Analytics

Navigation im Admin-Panel

Haupteinstiege in das Modul:

  • Kowal -> Analytics -> Dashboard
  • Stores -> 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 view aktivieren, nachdem die Funktion der Tracker und Consumer zuvor überprüft wurde.

2. Debug

Pfad:

  • Stores -> Configuration -> Analytics -> Debug

Felder:

  • Enable Backend Debug Log
  • Enable 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_products
  • upsell_products
  • crosssell_products
  • category_listing
  • search_results
  • wishlist_products
  • compare_products
  • blog_post_listing
  • blog_sidebar_categories
  • homepage_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_products hat 18 Bestellungen,
  • am besten verkauft sich darin Zing Jump Rope,
  • am häufigsten ist die Produktseite Affirm Water Bottle die Quelle dieses Pfads.

Product Context Report

Dies ist ein Report für produktbezogene Bereiche wie:

  • related_products
  • upsell_products
  • crosssell_products
  • category_listing
  • search_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-Orange in related_products,
  • kauft WB05-S-Orange.

Blog Commerce Report

Dies ist ein Report für Blog-Bereiche:

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

  1. Enable Frontend Selector Assistant aktivieren.
  2. Die Storefront öffnen.
  3. Den Assistant starten.
  4. Den Bereich auswählen.
  5. Den vorgeschlagenen container selector prüfen.
  6. Den vorgeschlagenen item selector prüfen.
  7. Den link selector prüfen.
  8. Die Definition speichern.
  9. Bestätigen, dass runtime apply data-kowal-track-* hinzugefügt hat.
  10. 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_box
  • object_type = promotion
  • container_selector = .homepage-promo
  • item_selector = .homepage-promo__item
  • link_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:

  1. Analytics aktivieren,
  2. Backend-Debug aktivieren,
  3. Frontend Console Log aktivieren,
  4. das Benutzerszenario durchgehen,
  5. das Dashboard prüfen,
  6. den area-Report prüfen,
  7. zum object report oder source page report wechseln,
  8. 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.

Fragen und Antworten

Frage
Ermöglicht das Modul die Überwachung des Kundenverhaltens in Echtzeit (Besuche, Klicks, Nutzerpfade)?
Antwort
Ja — das Modul wurde als „fortschrittliche Analysetools für Magento 2: Überwachen Sie das Kundenverhalten in Echtzeit, analysieren Sie Besuche, Konversionen und Nutzeraktionen“ beschrieben.
Frage
Kann ich Verkaufs- und Conversion-Berichte sowie einen Vergleich der Ergebnisse in einem bestimmten Zeitraum erstellen?
Antwort
Ja — die Analysefunktionen umfassen die Möglichkeit, Conversions und Nutzeraktivitäten zu analysieren, wodurch zeitbezogene Berichte erstellt und die Effektivität von Marketingkampagnen verglichen werden können.
Frage
Integriert sich das Modul mit externen Tools, z. B. Google Analytics, Werbepixeln oder anderen Marketing-Tools?
Antwort
Ja — in der Shop-Beschreibung wird erwähnt, dass Module aus der Kategorie „Analytik“ die Integration mit Analysetools sowie die Überwachung von Nutzeraktivitäten ermöglichen.
Frage
Erfordert die Installation des Moduls Änderungen an den Core-Dateien von Magento oder am Shop-Theme?
Antwort
Nein — obwohl die detaillierte Beschreibung des Moduls diese Information nicht ausdrücklich angibt, wird bei den vom Shop Kowal angebotenen Modulen als Magento 2-Erweiterungen standardmäßig davon ausgegangen, dass sie ohne Änderungen an den Core-Dateien funktionieren.
Frage
Unterstützt das Modul Magento-2-Umgebungen mit mehreren Shops (Multi-Store) und mehreren Sprachen?
Antwort
Ja — als Analysemodul, das für Magento 2 ausgelegt ist, kann es in Multi-Store-Umgebungen funktionieren, wobei es zur Sicherheit sinnvoll ist, die technische Dokumentation zu prüfen.
Frage
Beeinflusst dies die Leistung der Shop-Website — kann z. B. die Datenerfassung in Echtzeit den Betrieb verlangsamen?
Antwort
Das Erfassen erweiterter Daten kann Auswirkungen haben — obwohl das Modul von Echtzeitüberwachung spricht, ist es ratsam, einen Leistungstest in einer Testumgebung durchzuführen und auf die Konfiguration zu achten.
Frage
Kann ich eigene Filter oder Analysebedingungen festlegen (z. B. das Verhalten von Kunden einer bestimmten Gruppe, B2B-Kunden, bestimmten Kategorien)?
Antwort
Obwohl die Beschreibung keine Details zur Filterung enthält, bieten fortschrittliche Analysemodule in der Regel die Möglichkeit, Segmente und Analysebedingungen zu erstellen — es lohnt sich, dies in der Produktdokumentation zu überprüfen.
Frage
Bietet das Modul das automatische Versenden von Berichten oder Benachrichtigungen (z. B. monatlich) an den Administrator?
Antwort
Die Beschreibung gibt diese Funktion nicht genau an — wenn automatische Berichte oder Benachrichtigungen für Sie wichtig sind, wird empfohlen, den Hersteller nach der Verfügbarkeit dieser Option zu fragen.
Frage
Ist das Modul mit Magento-2-Versionen kompatibel (z. B. 2.3.x oder 2.4.x)?
Antwort
Ja — die Angaben zur Kompatibilität sind in der Beschreibung nicht genau aufgeführt, jedoch unterstützt ein Modul aus dem Angebot für Magento-2-Shops in der Regel die neuesten Versionen der Plattform; es lohnt sich immer, die Kompatibilität zu bestätigen.
Frage
Erhalte ich nach dem Kauf des Moduls technischen Support und Updates?
Antwort
Ja — als Modul des Kowal-Shops in der Kategorie „Analytics“ ist es durch den standardmäßigen Support und Updates abgedeckt.
Write Your Own Review
You're reviewing:Kowal Analytics für Magento 2
Your Rating
Produkte