PrestaShop-Besuchersitzungen: Daten, Datenschutz und Integrationen
Verstehen Sie gemeinsames Besuchertracking, erfasste Daten, Attributionsgrenzen, Einwilligungsgrenzen, Bereinigungsregeln und die Integrations-API.
Verstehen Sie die Besucherdaten, die Ihre Module erfassen, bevor Sie eine gemeinsame Sitzungserfassung verwenden. Definieren Sie Zweck, Zugriffsgrenzen und Aufbewahrung getrennt von den Cookies und Datensätzen, die den Bestellablauf ermöglichen.
So würden wir vorgehen
Wir würden zunächst festhalten, welche Entscheidung das Tracking unterstützen soll, und dann prüfen, ob Ihre vorhandenen Datensätze diese Frage bereits beantworten. Der passende Umfang hängt von Ihren installierten Modulen und Integrationen, Ihrem Theme, den bereits erfassten Daten, Ihren Märkten und dem Team ab, das die Ergebnisse nutzen wird. Legen Sie die Verantwortung für den gemeinsamen Dienst fest, bevor Sie eine weitere Datenerfassung hinzufügen.
Nehmen Sie Änderungen an der Erfassung oder am Paket auf einer privaten Staging-Kopie vor, die dem Live-Shop entspricht. Verwenden Sie Testidentitäten und isolieren Sie ausgehende Analysen, Werbung, E-Mails und andere Live-Integrationen. Proben Sie die folgenden Prüfungen und planen Sie anschließend die Live-Umstellung. Halten Sie dabei den bisherigen Code und die Einstellungen bereit und benennen Sie eine Person, die das Ergebnis prüft.
| Ihre Anforderung | Erster Ansatz | Anzufordernder Nachweis |
|---|---|---|
| Anmeldung, Warenkörbe oder Downloads funktionsfähig halten. | Untersuchen Sie den jeweiligen Geschäftsablauf, bevor Sie Besuchertracking ergänzen. | Ein reproduzierbarer Fehler, dessen Ursache bei Authentifizierung, Warenkorb oder Berechtigungsprüfung nachvollzogen wurde. |
| Missbrauch oder einen Abbruch an der Kasse verstehen. | Nutzen Sie zunächst den vorhandenen Kontext der jeweiligen Integration; ergänzen Sie Details nur für eine klar definierte Diagnosefrage. | Ein Testablauf mit den zugehörigen Datensätzen, die den Vorfall erklären. |
| Kampagnen zuordnen oder einen Funnel messen. | Definieren Sie die gewünschten Ereignisse und das Verhalten bei Einwilligung, bevor Sie die optionale Erfassung aktivieren. | Abgleich der erwarteten Ereignisse und Felder mit den beobachteten Schreibvorgängen für jeden Einwilligungsstatus. |
| Mehrere Shops getrennt auswerten. | Klären Sie vor der Berichtserstellung, wie jedes Ereignis einem Shop zugeordnet wird. | Ein Test, der zeigt, dass ein Bericht oder Export ohne Berechtigung keine Aktivitäten eines anderen Shops enthalten kann. |
Wenn Sie eine individuelle Datenerfassung oder Integration benötigen, kann der PrestaShop Custom Module Development Service den erforderlichen Ablauf und die Abnahmeprüfungen definieren.
Besuchertracking und Authentifizierung trennen
PrestaShop verwendet Cookies, Warenkorbdatensätze in der Datenbank und Authentifizierungs-/Sitzungsmechanismen für den Shop-Betrieb. Ein gemeinsames Paket zur Besuchererfassung ergänzt Datensätze für Analysen, Sicherheitskontext und Abläufe beteiligter Module. Es ersetzt weder die Kundenauthentifizierung noch speichert es Warenkorbinhalte als PHP-Sitzungsdateien.
Das Paket myprestarocks/prestashop-session verwendet den Namespace MyPrestaRocks\Session. Beteiligte Module können Tabellen wie mpr_sessions mit dem konfigurierten Präfix der Shopdatenbank gemeinsam nutzen. Dadurch lässt sich Besucherkontext wiederverwenden, doch jede Integration entscheidet selbst, wann sie ihn erstellt, aktualisiert oder liest. Gleichen Sie das nachfolgend beschriebene Schema, die API-Standardwerte und das Erfassungsverhalten mit der Paketversion ab, die Ihr Shop tatsächlich lädt.
Die gemeinsame Tabellennutzung erfolgt innerhalb der Datenbank der Installation. Sie erzeugt kein websiteübergreifendes Tracking zwischen unabhängigen Shops. Die grundlegende Sitzungstabelle hat keine Spalte id_shop, und mehrere Suchmethoden arbeiten über die gesamte Tabelle hinweg. Wenden Sie beim Aufbau von Multistore-Berichten oder Integrationen ausdrückliche Kontext- und Zugriffsgrenzen an.
Für die Kassenintegration verwenden Sie die Hilfeseite zu Checkout Revolution; für die sicherheitsbezogene Erfassung und Bereinigung die Hilfeseite zu Security Revolution; für Abläufe mit digitalen Produkten die Hilfeseite zu Digital Revolution.
Die speicherbaren Daten der Integration kennen
Das gemeinsame Schema unterstützt die folgenden Kategorien. Welche tatsächlich befüllt werden, hängt vom aufrufenden Modul und den aktivierten Funktionen ab.
| Kategorie | Beispiele |
|---|---|
| Identitätsverknüpfungen | Sitzungs-ID/-Hash, Gast-ID und optionale Kunden-ID |
| Netzwerk und Gerät | Vollständige IP-Adresse, abgeleitetes IP-Präfix, Land, unverarbeiteter User-Agent, User-Agent-Hash, Browser, Betriebssystem und Geräteklasse |
| Klassifizierung | Flags für Bots und JavaScript-Verifizierung, Netzwerk-/ASN-Informationen, Flags für Rechenzentren/Anonymisierer, Verhaltensbewertungen und Klassifizierungszeitstempel |
| Attribution | Details zu Quelle/Referrer, UTM-Parameter, gclid, fbclid, msclkid und ttclid |
| Besuchskontext | Einstiegs-URL/-Typ/-ID, Sprache, Währung, Erstbesuchsflag, Seitenanzahl, letzte Seite und Aktivitätszeiten |
| Detaillierte Seitenaufrufe | Sitzungsverknüpfung, Seitentyp/-ID, Controller, URL und Zeitstempel in mpr_page_views |
| Warenkorbaktionen | Warenkorb-, Produkt- und Kombinations-IDs, Aktion zum Hinzufügen/Entfernen/Aktualisieren oder für Gutscheine, Mengen, optionaler Produktname/-preis und Zeitstempel in mpr_cart_actions |
Zugehörige Tabellen für Analyseereignisse und Aggregate können zusätzliche Funnel-Daten enthalten. Nehmen Sie diese Tabellen in Ihr Dateninventar auf, wenn eine Integration sie verwendet.
Der URL-Helfer kann den Anfragepfad und die Abfragezeichenfolge erfassen. Verhindern Sie, dass Tokens, E-Mail-Adressen und andere unnötige personenbezogene Informationen in gespeicherte URLs gelangen. Bereinigen Sie beispielsweise die Tracking-Kopie von URLs zum Zurücksetzen von Passwörtern und für Zahlungsrückleitungen vor dem Speichern anhand einer Positivliste zulässiger Parameter. Erhalten Sie die ursprünglichen Anfrageparameter für die Passwort- oder Zahlungsabwicklung. Beschränken Sie die erfassten Felder auf den definierten Zweck.
Ein deterministischer User-Agent-Hash oder ein Sitzungshash beweist keine Anonymität der Daten. Vollständige IP-Adressen und Verknüpfungen mit Gästen, Kunden oder Ereignishistorien benötigen angemessene Zugriffs- und Aufbewahrungskontrollen.
Attribution und Bot-Einstufungen als Signale behandeln
Module können eine aktive Sitzung anhand des Hashs oder der Gast-ID suchen. Das Paket bietet außerdem eine Suche nach einer aktuellen Nicht-Bot-Sitzung anhand der IP-Adresse. Diese IP-Ersatzsuche erfordert keinen übereinstimmenden User-Agent. Ein gemeinsames Netzwerk, ein Proxy oder wechselnde IP-Adressen können die Zuordnung daher mehrdeutig machen. So können Kollegen im selben Büro unterschiedliche Gastdatensätze hinter derselben öffentlichen IP haben. Stellen Sie den Ablauf mit getrennten Browserprofilen nach, prüfen Sie die ausgewählte Sitzung und welche Suche sie geliefert hat; führen Sie ihre Verläufe nicht zusammen, nur damit ein IP-basierter Bericht stimmig aussieht.
Verwenden Sie für geschäftliche Vorgänge einen vertrauenswürdigen Gast-/Kundenkontext. Verwenden Sie niemals einen IP-Treffer, Besucherhash, eine Gerätebezeichnung oder einen Trackingdatensatz als Autorisierung für den Zugriff auf Konto, Adresse, Bestellung oder Download.
Der Sitzungs-Trait bietet User-Agent-Heuristiken und eine grobe Erkennung von Browser, Gerät und Betriebssystem. Optionale Reputations- und Verhaltensverarbeitung kann Netzwerk- und Aktivitätssignale ergänzen. User-Agents können gefälscht, Einstufungen falsch und Heuristiken veraltet sein. Prüfen Sie Klassifizierungen, bevor Sie sie für folgenreiche Einschränkungen verwenden.
Das Erstbesuchsflag der Kassenintegration prüft, ob für diesen Gast bereits eine Zeile besteht. Zurückgesetzte Cookies, Aufbewahrungsbereinigung und ein anderes Gerät können das Ergebnis ändern. Es ist ein Wiedererkennungsflag für die verfügbaren Datensätze und keine garantierte Identifizierung derselben Person über Tage oder Geräte hinweg.
Das Kassentracking knüpft an eine bestehende Handelsidentität an, etwa einen angemeldeten Kunden oder einen Warenkorb mit Produkten, abhängig von seinen Einstellungen und Anfrageregeln. Das Sicherheitstracking hat eigene Gast-, Zeitlimit- und Ausschlussregeln. Setzen Sie nicht voraus, dass die Module auf jeder Seite genau dieselben Datensätze erzeugen.
Zwecke, Einwilligung und Zugriff definieren
Trennen Sie die Zwecke, den Bestellablauf funktionsfähig zu halten, Missbrauch zu erkennen, Besuche zu messen und Werbung zuzuordnen. Prüfen Sie für jede tatsächliche Nutzung die anwendbare Rechtsgrundlage und die Einwilligungsregeln für Tracker. Eine gemeinsame technische Tabelle macht nicht jede Nutzung für den Bestellablauf erforderlich.
Die GDPR verlangt Zweckbindung, Datenminimierung, angemessene Sicherheit und Speicherbegrenzung. Richten Sie Hinweise, Zugriffskontrollen, Bearbeitung von Betroffenenrechten und Aufbewahrung nach den tatsächlich verarbeiteten Daten aus.
Die Tabellenhelfer des Pakets sind APIs für den Datenzugriff. Die aufrufende Integration muss Zweckbindung, gegebenenfalls Einwilligung, Berechtigungen und Datenminimierung vor der Erfassung oder Nutzung durchsetzen. Der Ablauf zur Werbezuordnung an der Kasse liest einen shopbezogenen Einwilligungsstatus und behandelt den Widerruf getrennt von der grundlegenden Identität für den Shop-Betrieb. Werden einwilligungsabhängige Zuordnungsfelder nach einer Ablehnung weiterhin geschrieben, verfolgen Sie die schreibende Anfrage und das Modul: Eine geänderte Banneranzeige beweist nicht, dass die serverseitige Erfassung der Auswahl folgt.
- Listen Sie jede Erfassungsstelle, Tabelle, jedes Feld, Cookie und jeden nachgelagerten Empfänger auf.
- Entscheiden Sie, welche Funktionen vor einer Einwilligungsentscheidung laufen dürfen und welche eine Erlaubnis benötigen.
- Testen Sie das Einwilligungsverhalten mit einem neuen Browserprofil vor einer Auswahl, nach Ablehnung, nach Zustimmung und nach Widerruf.
- Prüfen Sie nach jeder Entscheidung Anfragen, Cookies und Datenbankzeilen.
- Prüfen Sie, ob die optionale Erfassung wo erforderlich stoppt, während die Kasse nutzbar bleibt.
- Beschränken Sie Mitarbeiter-/Berichtszugriffe und testen Sie Kundendatenexport oder -löschung über alle verknüpften Datensatzgruppen hinweg.
Einwilligungsausnahmen für Reichweitenmessung haben besondere Voraussetzungen und können je nach Rechtsordnung variieren. Leiten Sie aus Selbsthosting oder Hashing keine Ausnahme ab. Verwenden Sie den PrestaShop-Datenschutzleitfaden für die Planung des umfassenderen Ablaufs.
Bereinigung konfigurieren und Löschung prüfen
Die Aufbewahrungsbegrenzung wird nur durchgesetzt, wenn die betreffende Bereinigungsaufgabe erfolgreich läuft. Ein Sitzungszeitlimit bestimmt, ob ein Datensatz als aktiv gilt; es ist davon getrennt, wie lange die Datenbank den Datensatz aufbewahrt.
| Paket-Einstiegspunkt | Standardverhalten |
|---|---|
| SessionInstaller::cleanAll() | 24 Stunden für inaktive Sitzungen, 24 Stunden für das Alter von Seitenaufrufen und 168 Stunden für das Alter von Warenkorbaktionen. |
| SessionInstaller::cleanAllSmart() | 24 Stunden für Bot-Inaktivität, 2160 Stunden für allgemeine Sitzungsinaktivität und das Alter von Seitenaufrufen sowie 720 Stunden für das Alter von Warenkorbaktionen. Entfernt außerdem verwaiste Seitenaufrufe. |
| Direkter Aufruf von SessionTable::cleanOldSessionsSmart() | Eigene Standardwerte von 24 Stunden für Bots und 72 Stunden für die allgemeine Inaktivitätsgrenze. |
Dies sind API-Standardwerte, keine vorgeschriebene Datenschutzrichtlinie. Ein Nutzer der API kann andere Werte übergeben. Die Bereinigung von Security Revolution verwendet die konfigurierten Aufbewahrungswerte für Bots, Sitzungen echter Besucher und Warenkorbaktionen. Die Bereinigung einer anderen Integration kann einen anderen Zeitstempel verwenden; ermitteln Sie deshalb jede Aufgabe, die gemeinsame Zeilen löschen kann.
Aktivitätsbasierte Aufbewahrung kann eine laufend aktualisierte Sitzung länger behalten als eine feste Frist ab Erstellung. Das Alter detaillierter Seitenaufrufe wird durch den Smart-Wrapper separat begrenzt. Beziehen Sie andere Ereignistabellen, Aggregate, Exporte, Anwendungsprotokolle und Sicherungen in den Aufbewahrungsplan ein; die Bereinigung der drei wichtigsten Trackingtabellen bestimmt nicht deren Lebensdauer.
- Dokumentieren Sie die tatsächliche Aufrufstelle, Argumente, Zeitplan und geladene Paketversion.
- Wählen Sie Aufbewahrungswerte für Ihre dokumentierten Zwecke.
- Führen Sie die Bereinigung auf Staging aus und prüfen Sie gelöschte Zeilen und Fehler. Berücksichtigen Sie eine alte Sitzung mit aktuellen Aktivitäten, eine abgelaufene inaktive Sitzung und einen Seitenaufruf ohne übergeordneten Datensatz; vergleichen Sie das Ergebnis mit dem gewählten Einstiegspunkt.
- Bestätigen Sie, dass abgelaufene und verwaiste Datensätze im Produktivbetrieb planmäßig entfernt werden. Dokumentieren Sie den letzten erfolgreichen Abschluss und die Löschzahlen und bestimmen Sie eine Person zur Fehleranalyse; dass ein Zeitplaner den Auftrag startet, beweist nicht, dass die Löschung abgeschlossen wurde.
- Prüfen Sie, ob Lösch-/Exportabläufe Gast- und Kundenverknüpfungen sowie nachgelagerte Kopien erfassen.
Deinstallationshelfer für gemeinsame Tabellen behalten die Tabellen, solange ein anderes installiertes Modul erkannt wird, das das Paket mitliefert. Das Entfernen eines Moduls ist nicht mit dem Löschen aller gemeinsam genutzten Besucherdaten gleichzusetzen. Prüfen Sie die weiterhin darauf zugreifenden Module, bevor Sie gemeinsame Tabellen entfernen.
Die Paket-API mit ausdrücklichen Grenzen verwenden
Die API bietet Helfer zur Tabelleninstallation, Suche, Verknüpfung, Aufzeichnung und Bereinigung. Halten Sie Paketversionen zwischen beteiligten Modulen kompatibel und testen Sie, welche Implementierung der Autoloader auflöst.
| API | Aufgabe |
|---|---|
| SessionInstaller::installAll() | Gemeinsame Tabellen für Sitzungen, Seitenaufrufe, Warenkorbaktionen und Traffic-Unterstützung installieren. |
| SessionTable::getActiveSessionByGuest() | Eine kürzlich aktive Sitzung für einen bekannten Gast finden. Standardaktivitätsfenster: 60 Minuten. |
| SessionTable::getActiveSessionId() | Eine aktive Zeile anhand des Sitzungshashs finden. |
| SessionTable::linkGuestToCustomer() | Zuvor unverknüpfte Gastdatensätze mit einem von der autorisierten Aufrufstelle angegebenen Kunden verknüpfen. |
| SessionTable::trackPageView() | Seitenzähler der Sitzung erhöhen und Aktivität aktualisieren. |
| PageViewsTable::trackPageView() | Eine detaillierte Seitenaufrufzeile schreiben, wenn diese Erfassungstiefe beabsichtigt ist. |
| CartActionsTable::trackCartAction() | Unterstützte Warenkorb- oder Gutscheinaktionen aufzeichnen. |
| AttributionContext::capture() | Ein Datenpaket mit Identitäts- und Attributionsdaten aufbauen. Prüfen Sie Eingabe und zurückgegebene Felder vor deren Speicherung oder Übermittlung. |
Wenn ein Bericht eine steigende Zahl von Sitzungsseiten, aber keinen detaillierten Verlauf zeigt, prüfen Sie zuerst, welche Seitenaufruf-API die Integration aufruft, bevor Sie von Datenverlust ausgehen. Entscheiden Sie, ob Zähler oder einzelne Ereignisse Ihre Frage beantworten, bevor Sie die Erfassung erweitern.
Diese Aufrufe ersetzen keine Prüfung von Zugehörigkeit oder Einwilligung. Stellen Sie keine beliebigen Sitzungs-/Kunden-IDs über einen öffentlichen Endpunkt bereit. Verwenden Sie den aktuellen authentifizierten oder anderweitig autorisierten Kontext und behandeln Sie fehlende Tabellen oder fehlgeschlagene Schreibvorgänge.
Testen Sie vor der Aktivierung einer Integration die Wiederverwendung von Sitzungen, Gast-zu-Kunde-Verknüpfung, Multistore-Geltungsbereich, Ablehnung und Widerruf der Einwilligung, Bereinigungsfehler und Deinstallation, während ein anderes Modul den gemeinsamen Sitzungsdienst noch verwendet. Verhindern Sie, dass Fehler im optionalen Tracking Käufe oder Anmeldungen unterbrechen.
Änderung proben und übergeben
- Prüfen Sie vor der ersten Staging-Anfrage oder dem ersten Testlauf, dass Datenbankverbindungen die Staging-Datenbank verwenden. Deaktivieren Sie kopierte geplante Aufgaben und isolieren Sie externe Empfänger. Aktivieren Sie nur die isolierten Aufgaben, die für die Probe nötig sind.
- Dokumentieren Sie die installierten PrestaShop- und PHP-Versionen, die Versionen der beteiligten Module und die geladene Paketdatei. Bewahren Sie die Konfiguration und Datenbankstruktur auf, die zur Wiederholung des Tests nötig sind.
- Führen Sie auf der isolierten Kopie die oben genannten Prüfungen zu Einwilligung, Identität und Bereinigung mit Ihrem tatsächlichen Theme und den aktivierten Integrationen durch. Dokumentieren Sie erwartete Schreibvorgänge, beobachtete Datensätze und nachgelagerte Nachrichten, ohne Geheimnisse in den Testbericht zu kopieren.
- Deaktivieren Sie eine optionale Datenerfassung und wiederholen Sie den Kaufablauf. Prüfen Sie, ob die übrigen Nutzer der Daten weiterhin funktionieren, und unterscheiden Sie zwischen dem Beenden neuer Erfassungen und dem Entfernen bestehender Datensätze.
- Legen Sie fest, wer die Änderung ausrollt, wer die entstehenden Datensätze prüft und welches Ergebnis eine Rücknahme auslöst. Setzen Sie Code oder Konfiguration so zurück, dass seit der Umstellung eingegangene Bestellungen erhalten bleiben; eine Datenbankwiederherstellung benötigt einen eigenen Wiederherstellungsplan.
- Vergleichen Sie nach der Umstellung einen kontrollierten Live-Ablauf mit den Staging-Nachweisen und bestätigen Sie den Abschluss der nächsten Bereinigung. Bewahren Sie die vereinbarten Datensatzdefinitionen und die Betriebsanleitung bei den Übergabeunterlagen des Shops auf.
Fragen an Ihren Entwickler oder Ihre Agentur
- Können Sie zeigen, welche Paketdatei geladen wird, wenn die beteiligten Module in verschiedenen Kombinationen aktiviert sind?
- Wo werden URL-Parameter vor dem Speichern gefiltert, und können Sie nachweisen, dass ein Testgeheimnis weder Tabelle noch Protokoll oder Export erreicht?
- Wer erhält bei einer fehlgeschlagenen Bereinigung eine Benachrichtigung, und wo steht die Anleitung zur Untersuchung?
- Welcher Empfänger muss kontaktiert werden, wenn ein Export den Shop bereits verlassen hat, und wie wird seine Löschung oder Korrektur bestätigt?
Häufige Fragen von Shopbetreibern
Werden damit Bildschirmaufzeichnungen erstellt?
Datensätze zu Seitenaufrufen und Warenkorbaktionen beschreiben erfasste Ereignisse, keine Bildschirmaufzeichnung. Wenn Sie Sitzungswiedergaben benötigen, prüfen Sie Erfassung, Maskierung und Zugriffskontrollen des separaten Werkzeugs, statt anzunehmen, dass diese Tabellen das leisten.
Warum weichen die Sitzungszahlen von einem anderen Analysebericht ab?
Vergleichen Sie Berichtszeiträume, Zeitzonen, die berücksichtigten Einwilligungsgruppen, Bot-Ausschlüsse und die Definition einer Sitzung, bevor Sie die Abweichung als fehlenden Traffic werten. Gleichen Sie Verkäufe mit Bestell- und Zahlungsdatensätzen ab, statt Besucherzahlen zwanghaft anzugleichen.
Verhindert ein längeres Tracking-Zeitlimit, dass Kunden abgemeldet werden?
Untersuchen Sie zuerst den Authentifizierungsablauf und seine Cookies. Ein längeres Zeitfenster für das Besuchertracking belegt nicht, dass die Kontoanmeldung oder die Wiederherstellung des Warenkorbs repariert wurde.
Wer ist verantwortlich, wenn verschiedene Agenturen die Module betreuen?
Benennen Sie auf Shopseite eine verantwortliche Person für das gemeinsame Datenverzeichnis und die Freigabe von Änderungen. Jeder Betreuer sollte seine Datenerfassung, den Aufrufer der Bereinigung und die Empfänger dokumentieren, damit sich Änderungen einer Agentur auf ihre Auswirkungen auf die anderen Integrationen prüfen lassen.