Matomo Analytics in Shopware 6 einrichten

von Der Atilla | Aug. 4, 2026 | Alle, Shopware 6, Shopware Einstellungen, Shopware Monitoring & Analyse | 0 Kommentare

Wer in Shopware 6 wissen will, wie Besucher durch den Shop klicken, wo sie abspringen und welche Kampagne wirklich Umsatz bringt, kommt an einer Web-Analytics-Lösung nicht vorbei. Matomo Shopware 6 ist dabei die naheliegende Wahl für alle, die DSGVO-konform und ohne Datenabfluss zu Google tracken wollen – Matomo lässt sich selbst hosten oder als Cloud-Variante nutzen und bleibt dabei vollständig im eigenen Datenhoheitsbereich. Nur: Eine offizielle Shopware-Doku-Seite für Matomo gibt es nicht. Wer die Integration bauen will, muss zwischen manueller Twig-Einbindung, kostenlosen Open-Source-Plugins und kostenpflichtigen Store-Erweiterungen wählen – und seit Shopware 6.7.3.0 zusätzlich das neue Cookie-Consent-Event-System beachten. Dieser Artikel zeigt alle drei Wege für Shopware 6.7.9.0 mit PHP 8.4 im Detail, inklusive der Fallstricke, die in der Praxis am häufigsten für offene Support-Tickets sorgen. Wer sich vorab entscheiden will, welcher der drei Wege überhaupt zum eigenen Setup passt, findet am Ende jedes Abschnitts eine kurze Einordnung – und in Abschnitt 6 eine kompakte FAQ, die die häufigsten Rückfragen aus der Praxis bündelt.

1. Warum Matomo Shopware 6 sinnvoll ergänzt
2. Lösung A: Matomo manuell per Twig einbinden (Bordmittel)
3. Lösung B: Matomo-Plugins aus dem Shopware Store im Vergleich
4. Matomo korrekt im Cookie-Consent registrieren
5. Bekannte Praxis-Fehlerbilder beim tinect-Plugin
6. Häufige Fragen zu Matomo in Shopware 6
7. Quellen und weiterführende Links

1. Warum Matomo Shopware 6 sinnvoll ergänzt

Matomo (früher Piwik) ist die bekannteste Open-Source-Alternative zu Google Analytics. Der große Unterschied für Shopware-Betreiber: Bei einer selbst gehosteten Matomo-Instanz bleiben alle Trackingdaten auf eigenen Servern – das vereinfacht die DSGVO-Argumentation gegenüber Kunden und Datenschutzbeauftragten erheblich, weil kein Datentransfer in Drittländer stattfindet. Auch die Matomo-Cloud-Variante bewegt sich rechtlich auf einem anderen Fundament als US-Anbieter.

Technisch betrachtet ist Matomo für Shopware 6 aber kein Plug-and-Play-Feature. Anders als bei manchen anderen Trackingdiensten gibt es keine native Konfigurationsoberfläche im Shopware-Administrationsbereich und auch keine Zeile dazu auf den offiziellen Dokuseiten developer.shopware.com oder docs.shopware.com. Wer Matomo einsetzen will, hat im Kern drei Optionen:

Bordmittel: Tracking-Code manuell in eigene Twig-Templates einbinden
Ein kostenloses Community-Plugin wie tinect/matomo-shopware-plugin per Composer installieren
Ein kostenpflichtiges Plugin aus dem offiziellen Shopware Store nutzen

Welcher Weg passt, hängt stark davon ab, wie viel E-Commerce-Tracking (Warenkorb-Events, Produktkategorien, Bestellungen) automatisch mitlaufen soll und wie viel Wartungsaufwand man selbst tragen will. Die folgenden Abschnitte gehen alle drei Wege konkret durch.

Selbst gehostet vs. Cloud: Was das für den Betrieb bedeutet

Für den technischen Teil dieses Artikels macht es kaum einen Unterschied, ob Matomo selbst gehostet oder als Cloud-Variante genutzt wird – in beiden Fällen wird derselbe JavaScript-Tracking-Code eingebunden, nur die matomo_url zeigt auf einen anderen Host. Der Unterschied liegt im Betrieb: Bei Self-Hosting ist man selbst für Updates, Serverkapazität und Backups der Matomo-Instanz verantwortlich, dafür bleiben die Rohdaten vollständig in der eigenen Infrastruktur. Bei der Cloud-Variante übernimmt der Anbieter Betrieb und Updates, wofür im Gegenzug ein Auftragsverarbeitungsvertrag mit dem Cloud-Anbieter nötig ist – ein Punkt, den man vor der Entscheidung mit der eigenen Datenschutzberatung klären sollte, gerade wenn besonders sensible Kundendaten verarbeitet werden.

Zurück zur Übersicht

2. Lösung A: Matomo manuell per Twig einbinden (Bordmittel)

Ohne jedes Plugin lässt sich der Matomo-Tracking-Code klassisch per Twig-Override einbinden. Die Community empfiehlt dafür zwei Ansatzpunkte, die beide im custom/-Verzeichnis überschrieben werden – niemals direkt in vendor/shopware/..., sonst reißt das nächste Shopware-Update die Anpassung wieder heraus:

storefront/component/analytics.html.twig – der dedizierte Analytics-Block, den auch andere Trackingintegrationen nutzen
storefront/layout/meta.html.twig – alternativ, wenn der Code möglichst früh im <head> laden soll

In der Praxis legt man dafür ein eigenes kleines Plugin oder App-Fragment an, das den passenden Twig-Block per sw_extends erweitert und darin den Standard-Matomo-JS-Snippet mit der eigenen matomo_url und idsite einbindet. Das ist der Weg mit der größten Kontrolle: kein zusätzliches Plugin-Update-Risiko, keine Store-Abhängigkeit – aber auch keine automatische E-Commerce-Datenübertragung (Produktkategorien, Warenkorbinhalte, Bestellwerte). Diese Events müsste man bei reiner Twig-Einbindung selbst nachbauen.

Wichtig dabei: Diskussionen im Shopware-Forum (siehe Quellenliste) machen deutlich, dass Matomo bei reiner Skript-Einbindung ohne Plugin nicht automatisch im nativen Shopware-Cookie-Consent-Tool auftaucht. Die Cookie-Registrierung muss in diesem Fall separat über das in Abschnitt 4 beschriebene Event-System nachgezogen werden – sonst läuft das Tracking-Script, ohne dass der Besucher zugestimmt hat, was ein handfestes DSGVO-Problem ist.

Wann sich der manuelle Weg lohnt

Wenn nur Seitenaufrufe getrackt werden sollen, ohne detailliertes E-Commerce-Tracking
Wenn man ohnehin schon ein eigenes Theme mit sauberer Twig-Block-Struktur pflegt
Wenn man keine zusätzliche Composer-Abhängigkeit im Deployment haben will

Bevor der Code eingebunden wird, lohnt ein Blick in die eigene Matomo-Installation: Unter den Website-Einstellungen legt man dort die Tracking-Methode fest, die zur eigenen Infrastruktur passt. Für die klassische Twig-Einbindung ist der JavaScript-Tracking-Code relevant, den Matomo pro Website generiert.

Diesen generierten JS-Snippet kopiert man 1:1 in den überschriebenen Twig-Block – inklusive der von Matomo vergebenen idsite und der URL der eigenen Matomo-Instanz. Wer mehrere Sales Channels mit unterschiedlichen Matomo-Sites betreiben will, sollte die Werte über die Theme- oder Plugin-Konfiguration pro Sales Channel steuerbar machen, statt sie hart zu verdrahten. Gerade bei Multi-Channel-Setups mit Test- und Live-Umgebung zahlt sich das aus: Ohne konfigurierbare Werte landen Testklicks aus der Staging-Umgebung sonst versehentlich in denselben Matomo-Reports wie der Live-Traffic, was die Auswertung verfälscht.

Zurück zur Übersicht

3. Lösung B: Matomo-Plugins aus dem Shopware Store im Vergleich

Wer die manuelle Pflege scheut oder direkt sauberes E-Commerce-Tracking (Warenkorb, Kategorien, Bestellungen) haben will, greift zu einem fertigen Plugin. Hier ist die Auswahl größer als gedacht – aber nicht jede Option ist für Shopware 6.7 tatsächlich geeignet. Zwei ältere Anbieter, „Simple Matomo Analytics“ (Site Concept) und „Matomo (Piwik) Tracking“ (Martin Eisenführer, älteres Plugin), sind laut Store-Kompatibilitätsangabe ausschließlich für Shopware 5.2.0–5.7.20 freigegeben und fallen für Shopware 6 komplett raus.

Von den verbleibenden Optionen ist tinect/matomo-shopware-plugin die einzige kostenlose: ein MIT-lizenziertes Open-Source-Plugin, das nicht im offiziellen Store gelistet ist, sondern per Composer installiert wird (composer require tinect/matomo). Die Composer-Constraint shopware/core: ~6.6.10||~6.7.0 bestätigt die offizielle Kompatibilität mit 6.7.x. Mit 13.771 Installs auf Packagist (Stand: 03.08.2026) ist es auch das mit Abstand am weitesten verbreitete Matomo-Plugin im Shopware-6-Ökosystem – dieser Zähler verändert sich laufend, die genannte Zahl ist also eine Momentaufnahme und kein fixer Wert.

Alle übrigen Optionen sind kostenpflichtige Store-Plugins mit monatlicher oder jährlicher Abrechnung. Die folgende Tabelle zeigt die Preise, wie sie am 03.08.2026 direkt auf den jeweiligen Store-Seiten standen:

Plugin	Anbieter	Preis	SW-Kompatibilität	Letztes Update
tinect/matomo-shopware-plugin	tinect (GitHub/Packagist)	kostenlos, Open Source (MIT)	~6.6.10 \|\| ~6.7.0	v6.1.1, 10.07.2026
Matomo Tracking and Ecommerce	Campit	5,99 €/Monat kündbar bzw. 59,99 €/Jahr	Cloud 6.4.8.0–6.7.12.2	v70.1.0.2, 23.07.2026
Matomo Tag Manager	Campit	1 Monat gratis, danach 14,99 €/Monat bzw. 149,99 €/Jahr	Cloud 6.4.8.0–6.7.12.2	v6.1.2, 23.07.2026
Matomo Tracking and Ecommerce	Martin Eisenführer	6,50 €/Monat kündbar bzw. 60,00 €/Jahr	6.5.0.0–6.7.12.2	v3.2.4, 28.06.2026
Server-side Matomo tracking	Konpio GmbH	14,99 €/Monat kündbar bzw. 149,99 €/Jahr, 1 Probemonat	6.5.0.0–6.7.8.2 ⚠	v3.0.4, 09.02.2026

Beim Konpio-Plugin lohnt ein genauer Blick: Die Store-Kompatibilität ist bis 6.7.8.2 angegeben, unser Referenz-Setup läuft aber bereits auf 6.7.9.0 – eine neuere Version als die höchste offiziell bestätigte. Das Plugin funktioniert dadurch nicht zwangsläufig nicht, aber es ist im Store schlicht (noch) nicht als kompatibel mit 6.7.9.0 ausgewiesen. Vor einem produktiven Einsatz sollte man das entweder direkt beim Anbieter erfragen oder in einer Staging-Umgebung selbst testen.

Kurzcheck: Welches Plugin für welchen Bedarf?

Kein Budget, technisches Know-how vorhanden: tinect/matomo-shopware-plugin per Composer
Server-seitiges Tracking gewünscht (Ad-Blocker-resistent): Konpio-Plugin, aber Kompatibilität vorab prüfen
Zentrale Tag-Verwaltung über mehrere Tools: Matomo Tag Manager von Campit
Einfaches E-Commerce-Tracking ohne Composer-Workflow: Matomo Tracking and Ecommerce (Campit oder Eisenführer)

Ein Kostenaspekt, der in der Tabelle leicht untergeht: Bei den kostenpflichtigen Abo-Plugins summieren sich die Jahrespreise über mehrere Jahre Betrieb durchaus spürbar, während das kostenlose tinect-Plugin dauerhaft ohne laufende Lizenzkosten auskommt – dafür trägt man dort selbst die Verantwortung für Updates und für das Nachverfolgen der in Abschnitt 5 beschriebenen offenen Issues.

Zurück zur Übersicht

Ein Punkt, der bei vielen älteren Anleitungen im Netz veraltet ist: Bis Shopware 6.7.2.x war CookieProviderInterface der Standardweg, um eigene Cookies im Consent-Manager anzumelden. Seit Shopware 6.7.3.0 gilt dieses Interface offiziell als deprecated. Der aktuelle, von Shopware dokumentierte Weg läuft stattdessen über das Event Shopware\Core\Content\Cookie\Event\CookieGroupCollectEvent, das mit einem Listener statt einem Service-Decorator behandelt wird und mit CookieEntry– bzw. CookieEntryCollection-Objekten arbeitet.

Für die konkrete Implementierung – welche Konstruktor-Parameter CookieEntry im Detail erwartet und wie die Objekte exakt der Collection hinzugefügt werden – ist die offizielle Shopware-Entwicklerdokumentation die verlässlichste Quelle, da sich Details zwischen Patch-Versionen verschieben können. Der Guide dazu liegt unter developer.shopware.com/docs/guides/plugins/plugins/storefront/add-cookie-to-manager.html (siehe Quellenliste). Wichtig für die Praxis: Bei jeder Änderung an den registrierten Cookie-Gruppen berechnet Shopware automatisch einen Hash, der bei bestehenden Besuchern einen erneuten Consent-Dialog auslöst – das ist gewolltes Verhalten und kein Bug, wenn nach einem Matomo-Rollout plötzlich wieder alle Besucher den Cookie-Banner sehen.

Wer ein fertiges Plugin nutzt (etwa tinect), sollte prüfen, ob es bereits selbst über CookieGroupCollectEvent registriert – bei aktuellen Versionen der gängigen Plugins ist das in der Regel der Fall
Wer Matomo manuell per Twig einbindet (Lösung A), muss die Cookie-Registrierung zwingend selbst per eigenem Listener nachziehen, sonst läuft Tracking ohne gültigen Consent

Ein weiterer Praxispunkt: Nach der Migration von CookieProviderInterface auf CookieGroupCollectEvent lohnt es sich, den Consent-Dialog nach dem Deployment einmal manuell im Inkognito-Fenster durchzuklicken – gerade weil sich der neue Cookie-Hash bei jeder Änderung neu berechnet, fällt ein fehlerhaft registrierter Eintrag sonst erst auf, wenn Support-Anfragen wegen doppelt erscheinender Consent-Banner eintreffen.

Zurück zur Übersicht

5. Bekannte Praxis-Fehlerbilder beim tinect-Plugin

Weil tinect/matomo-shopware-plugin die mit Abstand meistgenutzte kostenlose Option ist, lohnt ein Blick auf das öffentliche Issue-Tracking auf GitHub. Zum Recherchezeitpunkt (03.08.2026) waren dort mehrere seit Monaten offene, unbeantwortete Issues gemeldet – keiner davon macht das Plugin unbenutzbar, aber alle sollten vor dem produktiven Einsatz bekannt sein:

Issue #24 (16.07.2026, offen): Produktkategorien werden aktuell nicht an Matomo übertragen – relevant, wenn Kategorie-Auswertungen im Reporting eine Rolle spielen sollen
Issue #20 (23.12.2025, offen): Nach Deaktivierung der Shopware-Analytics-Integration und Deinstallation eines Tag-Manager-Plugins feuert das Plugin bei jedem Seitenwechsel fälschlich ein suggestSearch-Event mit dem Suchbegriff null – das verunreinigt das Suchtracking in Matomo
Issue #9 (20.10.2024, offen): Im Wartungsmodus findet bei Proxy-Betrieb kein Tracking statt
Issue #4 (25.03.2024, offen, Feature-Wunsch): Die Community wünscht sich Unterstützung des Matomo Tag Managers (MTM) als zentrale Tracking-Instanz anstelle des Standard-Trackingcodes

Der Status dieser Issues wurde nicht per Commit-Historie nachgeprüft, sondern nur zum Abrufzeitpunkt erfasst – es lohnt sich, vor einem eigenen Rollout direkt in den verlinkten GitHub-Issues nachzusehen, ob sich seither etwas getan hat. Wer produktionskritisch auf saubere Kategorie- oder Suchdaten angewiesen ist, sollte diese Lücken vorab einplanen oder gegen die kostenpflichtigen Store-Alternativen aus Lösung B abwägen.

Praktisch heißt das für die Rollout-Planung: Wer vor allem an Besucherzahlen, Verweildauer und groben Trichter-Auswertungen interessiert ist, stößt an keiner der vier genannten Lücken an. Wer dagegen granulare Kategorie-Reports oder eine sehr saubere Such-Funnel-Auswertung braucht, sollte Issue #24 und Issue #20 vor dem Go-Live gegen die eigenen Reporting-Anforderungen prüfen.

Zurück zur Übersicht

6. Häufige Fragen zu Matomo in Shopware 6

Ist Matomo für Shopware 6 offiziell dokumentiert?

Nein. Weder developer.shopware.com noch docs.shopware.com behandeln Matomo namentlich. Offiziell dokumentiert ist nur das generische Cookie-Consent-System, über das sich Matomo (wie jeder andere Trackingdienst) sauber anmelden lässt.

Welches Matomo-Plugin ist für Shopware 6.7.9.0 kostenlos?

Aktuell nur tinect/matomo-shopware-plugin. Es ist MIT-lizenziert, wird per Composer installiert und ist offiziell mit ~6.6.10||~6.7.0 kompatibel.

Brauche ich für Matomo einen eigenen Cookie-Banner-Eintrag?

Ja. Seit Shopware 6.7.3.0 läuft die Registrierung eigener Tracking-Cookies über das Event CookieGroupCollectEvent. Bei manueller Twig-Einbindung ohne Plugin muss diese Registrierung selbst nachgebaut werden, sonst erscheint Matomo nicht im Consent-Tool.

Ist `CookieProviderInterface` noch der richtige Weg?

Nein, dieses Interface gilt seit Shopware 6.7.3.0 als deprecated. Aktueller Weg ist ein Listener auf CookieGroupCollectEvent.

Funktioniert das Konpio-Plugin sicher mit 6.7.9.0?

Nicht bestätigt. Der Store weist die Kompatibilität nur bis 6.7.8.2 aus, unser Referenz-Setup läuft auf 6.7.9.0. Vor produktivem Einsatz sollte das getestet oder beim Anbieter erfragt werden.

Lohnt sich der manuelle Weg (Lösung A) oder gleich ein Plugin?

Das hängt vom Reporting-Anspruch ab: Reichen einfache Seitenaufrufe, ist die manuelle Twig-Einbindung schlank und ohne zusätzliche Abhängigkeit. Sobald Warenkorb-, Kategorie- oder Bestelldaten in Matomo landen sollen, spart ein fertiges Plugin – kostenlos oder kostenpflichtig – deutlich Implementierungsaufwand, weil die E-Commerce-Events bereits vorgebaut sind.

Zurück zur Übersicht