Criteo OneTag-Integration

Ja. Das Modul hat optionales serverseitiges Criteo Retail Media Purchase Tracking. Dafür muss Purchase Tracking aktiviert sein und die serverseitigen Einstellungen müssen konfiguriert sein: Criteo Partner ID, S2S_ENABLED, Region eu oder us, Desktop- und Mobile-API-Page-IDs und ein Batch Limit. Das Standard-Batch-Limit serverseitig ist 20, mit Validierung auf 1 bis 100 begrenzt.

Wenn PrestaShop actionValidateOrder auslöst, stellt der Hook eine trackTransaction-Conversion für Provider criteo_retailmedia in die Warteschlange und verarbeitet sofort einen kleinen Batch. Er prüft jedoch den Bestellstatus oder Zahlungsstatus nicht selbst. Der Queue-Pfad läuft, wenn Modultracking laufen darf, Purchase Tracking aktiviert ist, die serverseitige Konfiguration gültig ist und ein geladenes Order-Objekt vorhanden ist. Wenn Sie paid-only Semantik benötigen, muss das durch den Order-Validation-Kontext garantiert oder als explizite Statusprüfung ergänzt werden.

Eine Cron-Aufgabe namens send_criteo_retailmedia_conversions ist ebenfalls registriert, um alle 300 Sekunden eingereihte Conversions zu verarbeiten. Die Serveranfrage wird an Criteos Retail Media-Endpunkt für die konfigurierte Region gesendet, etwa d.eu.criteo.com oder d.us.criteo.com, mit Transaction ID, Item, Price, Quantity, Currency, Visitor-/Customer-Daten und Page ID. Die optionale Einstellung S2S_SEND_IP_UA steuert, ob IP- und User-Agent-Daten enthalten sind. Diese serverseitige Queue ist vom Browser-trackTransaction-Event auf der Bestellbestätigungsseite getrennt, sodass fehlgeschlagene Server-Sends wiederholt werden können, ohne von der Browser-Session des Kunden abhängig zu sein.

Die serverseitige Funktion wird mit der gemeinsamen Conversion-Queue-Tabelle und Cron-Registrierung installiert. Sie ist standardmäßig deaktiviert: S2S_ENABLED=0, S2S_REGION=eu, Desktop Page ID trackTransactionApiDesktop, Mobile Page ID trackTransactionApiMobile, S2S_SEND_IP_UA=1 und S2S_BATCH_LIMIT=20. Die Partner ID muss numerisch und 4 bis 20 Ziffern lang sein, die Region muss eu oder us sein, und Page IDs dürfen Buchstaben, Zahlen, Unterstrich, Doppelpunkt und Bindestrich enthalten.

Bei Order Validation prüft das Modul zuerst die High-Level-Tracking-Guards: Criteo muss aktiv sein, Purchase Tracking muss aktiviert sein, Consent muss Tracking erlauben, wenn der Consent Guard an ist, und die serverseitigen Einstellungen müssen die Validierung bestehen. Wenn eine dieser Prüfungen fehlschlägt, wird kein Server Event in die Warteschlange gestellt.

Die Purchase Payload wird aus Bestellpositionsdaten gebaut. Item IDs, Preise und Mengen werden für die Criteo Retail Media Query mit Pipe-Zeichen verbunden. Wenn keine Item IDs gemappt werden können, sendet das Modul einen Fallback item=None, price=0.00 und quantity=1, statt ein leeres Pflichtfeld zu senden. Der Environment-Wert wird aus dem User Agent als Desktop d, Mobile m oder Tablet t gewählt, und dieses Environment wählt die Desktop- oder Mobile Page ID.

Der Admin Controller stellt außerdem operative Werkzeuge für diese Queue bereit: Er kann Pending-/Sending-/Sent-/Failed-Zählungen anzeigen, einen API Probe senden und fehlgeschlagene Criteo-Server-Side-Events für Retry zurück auf Pending setzen.

Required server-side setup:
ENABLED=1
PARTNER_ID=12345
TRACK_PURCHASE=1
S2S_ENABLED=1
S2S_REGION=eu or us
S2S_DESKTOP_PAGE_ID=trackTransactionApiDesktop
S2S_MOBILE_PAGE_ID=trackTransactionApiMobile

Ja, Händler können eigene Trigger-Regeln für unterstützte Criteo-Events definieren. Die PrestaShop-Konfiguration akzeptiert validierte JSON-Regeln mit Klick-, URL-, Controller- oder DOM-Event-Triggern und normalisiert Eventnamen auf das von Criteo unterstützte OneTag-Vokabular.

Sie können Criteo OneTag zu PrestaShop hinzufügen, indem Sie eine numerische Criteo Partner ID konfigurieren und Browser-Tracking aktivieren. Das Modul baut dann OneTag-Events im Header für unterstützte E-Commerce-Seiten und bleibt inaktiv, wenn die Partner ID fehlt oder ungültig ist.

Ja, wenn SEND_CUSTOMER_IDENTIFIERS aktiviert ist. Das Modul baut separate Criteo Customer Events neben den normalen Page- oder Purchase-Events. Es sendet in diesen Customer Events nie die Klartext-E-Mail; es lowercased und trimmt die E-Mail und hasht sie dann mit SHA-256. Die Customer ID wird ebenfalls mit einem customer:-Präfix gehasht.

[{"event":"setCustomerId","id":"sha256(customer:123)"},{"event":"setEmail","email":"sha256(alice@example.com)"}]

Die obigen Werte sind Platzhalter und zeigen nur die Form. In der echten Storefront-Ausgabe enthalten die Hash-Felder 64-Zeichen-SHA-256-Hex-Strings. Die Events werden vollständig ausgelassen, wenn Kundenkennungen deaktiviert sind oder wenn kein gültiger Kunde aus aktuellem Kontext oder Bestellung geladen werden kann.

Die Einstellung ist standardmäßig deaktiviert, ein Händler muss sich also bewusst dafür entscheiden, bevor diese Events erstellt werden. Für normale Page Events verwendet das Modul den aktuellen PrestaShop-Kunden aus dem Storefront-Kontext. Für Order-Confirmation-Purchase-Events kann es den Kunden aus id_customer der Bestellung laden. In beiden Pfaden prüft die Quelle, dass ein gültiges Kundenobjekt existiert, bevor eines der Identifier Events hinzugefügt wird.

Die Browser-Templates platzieren diese Identifier Events in der Universal Queue mit setAccount und setSiteType, bevor das Page-, Basket- oder Purchase-Event in window.criteo_q gepusht wird. Das Modul sendet in diesen Browser-Customer-Events nicht den Namen, die Telefonnummer, Postadresse oder rohe PrestaShop-Kunden-ID.

Für serverseitiges Purchase Tracking kann dieselbe Opt-in-Flag außerdem einen gehashten E-Mail-Wert zur Retail-Media-Abfrage hinzufügen, wenn der Bestellkunde eine E-Mail-Adresse hat. Dieser serverseitige Pfad hängt weiterhin von den normalen Tracking Guards ab: Das Modul muss aktiv sein, Consent muss Tracking erlauben, wenn aktiviert, Purchase Tracking muss an sein, und die serverseitigen Criteo-Einstellungen müssen gültig sein.

Ja, es kann Cookie Consent respektieren, wenn RESPECT_CONSENT aktiviert ist, was der Moduldefault ist. Das Modul prüft zuerst mprcookiesrevolution, indem es das mprcr_consent-Cookie parst und nach marketing:1 sucht. Wenn dieses Cookie fehlt, fällt es auf den DEFAULT_CONSENT-Wert von mprcookiesrevolution zurück.

Wenn Cookies Revolution nicht aktiv ist, prüft es mprcookiebanner. Ein Cookie-Wert von mprcookie_consent=granted erlaubt Criteo; jeder andere vorhandene Wert blockiert es. Wenn das Banner-Cookie fehlt, verwendet das Modul den DEFAULT_CONSENT von mprcookiebanner.

Wenn kein unterstütztes MPR-Consent-Modul installiert oder aktiv ist, gibt hasMarketingConsent() allowed zurück, sodass Criteo nicht allein durch Consent blockiert wird. Für ein striktes consent-first Setup lassen Sie Respect marketing consent aktiviert und betreiben eines der unterstützten MPR-Consent-Module. Das clientseitige Consent Gate ist nur aktiviert, wenn Respect marketing consent an ist und entweder mprcookiesrevolution oder mprcookiebanner aktiv ist.

Die Consent-Prüfung ist Teil von canTrack(), das vor Header Events, Order-Confirmation-Purchase-Events und serverseitigem Purchase Queueing verwendet wird. Wenn die serverseitige Consent-Prüfung Tracking blockiert, baut das Modul daher keine normalen Browser-Events und stellt die serverseitige Conversion aus actionValidateOrder nicht in die Warteschlange.

Das Browser-Template enthält außerdem eine clientseitige Consent-Prüfung, wenn das Consent Gate aktiv ist. Es kann window.MPRCR.isGranted('marketing') aufrufen, wenn Cookies Revolution diesen Helper bereitstellt, oder dieselben Cookies mprcr_consent und mprcookie_consent direkt lesen. Wenn diese JavaScript-Prüfung false zurückgibt, stoppt es, bevor Criteo-Events in window.criteo_q gepusht werden.

RESPECT_CONSENT=0: consent check is bypassed
RESPECT_CONSENT=1 + mprcr_consent contains marketing:1: allowed
RESPECT_CONSENT=1 + mprcookie_consent=granted: allowed
RESPECT_CONSENT=1 + no supported MPR consent module: allowed by this module

Consent ist nicht der einzige Tracking Guard. Browser-Tracking erfordert weiterhin auch ENABLED=1 und eine gültige numerische Criteo Partner ID, und Mitarbeiter-Browsing kann ausgeschlossen werden, wenn EXCLUDE_EMPLOYEES aktiviert ist.

Das Modul ordnet PrestaShop-Storefront-Seiten und Hooks Criteo-OneTag-Events zu, mit separaten Einstellungen für jedes Standard-Event.

Alle Browser-Events hängen weiterhin davon ab, dass das Modul aktiv ist, eine Criteo Partner ID konfiguriert ist, der Besucher die Tracking-/Consent-Prüfungen des Moduls besteht und der jeweilige Event-Schalter aktiviert ist.