RKR API Conversions Pro: Serverseitige Conversions für Meta, GA4, Google Ads und mehr

22.10.2026
v1.3.17

• AddPaymentInfo in onepagecheckoutps: Die Zahlungsoption wird mit jQuery markiert (.prop('checked', true).trigger('change') beim Klicken auf die Karte), was nicht native ändern, Eine Option ist bereits vorausgewählt, sodass für diese Shops keine Zahlungsinformationen mehr erforderlich sind. Diese werden nun auch gesendet:
• per Klick auf eine Zahlungskarte (.payment-option, , .module_payment_container, Etiketten von .payment-options), wobei die Option anschließend angekreuzt wird;
• auf jQuery ändern von Eingang[name="payment-option"];
• mit der ausgewählten Option bei der Bestellung (#Zahlungsbestätigungsbutton, , .js-Zahlungsbestätigungsschaltfläche, , #btn-placer_orderFür Kunden, die die vorausgewählte Option beibehalten. Wie bisher einmal pro Zahlungsmodul und Seite. Getestet in einer Kopie eines Shops mit OnePageCheckout. 5.2.0 auf PS 9.1.4 (Angemeldeter Kunde mit Adresse): vorher nichts; jetzt AddShippingInfo mit dem vorausgewählten Spediteur und AddPaymentInfo.

22.10.2026
v1.3.16

• onepagecheckoutps stoppt die Weitergabe der ändern der Übertragungs- (und Zahlungs-)Funkgeräte, bevor es das Dokument erreicht, sodass die Hörer von 1.3.14, In der Anfangsphase wurde dies nie gemeldet, und es wurden keine Versandinformationen von diesen Shops übermittelt. Die Versanddienstleister und Zahlungsanbieter nutzen nun die Erfassungsphase (geprüft in einer Kopie eines Shops mit OnePageCheckout). 5.2.0 auf PS 9.1.4Das Dokument sah die ändern nur im Erfassungsmodus; damit werden AddShippingInfo-Daten gelöscht).

22.10.2026
v1.3.14

• onepagecheckoutps (PresTeamShop) und thecheckout (Zelarg) überschreiben den OrderController, daher ist ihr Checkout der Befehl Seite: Es handelte sich um eine Checkout-Seite, jedoch nicht um einen einseitigen Checkout. Der JavaScript-Code wartete auf den „Weiter“-Button im Lieferschritt, den diese Checkouts nicht haben. Weder Versandinformationen noch Zahlungsinformationen wurden von diesen Shops übermittelt. Befehl Es handelt sich um eine einseitige Kassenabwicklung, wenn override/controllers/front/OrderController.php gehört zu einem von ihnen (und das Modul ist aktiviert), oder wenn Befehl wird unter „Andere Checkout-Seiten“ aufgeführt.
• Sicherheit für ein installiertes, aber nicht verwendetes einseitiges Modul: wenn die Seite die Lieferoption bestätigen Wenn Sie auf die Schaltfläche im Schritt „Checkout“ klicken, sendet das Speditionsradio keine Versandinformationen (AddShippingInfo), und wenn Sie eine Zahlungsart auswählen, werden diese nicht erneut gesendet, wenn sie bereits für den Warenkorb gesendet wurden.

22.10.2026
v1.3.13

• Einseitige Auscheckvorgänge anderer Module: Ihre Seite war nie die Kasse Seitentyp (nur php_self Bestellung/Checkout gezählt), daher verließen keine InitiateCheckout-, AddShippingInfo- oder AddPaymentInfo-Funktionen einen Shop mit SteasyCheckout. Nun zu den Front-Controllern von SteasyCheckout, SuperCheckout (Knowband), OnePageCheckoutPS (PresTeamShop) und TheCheckout (Zelarg) sowie der order-opc Seite 1: der Kassenbereich.
• Neue Einstellung „Andere Checkout-Seiten“ (Erweitert): Modul: Controller oder php_self Einträge, durch Kommas getrennt, für jedes andere Checkout-Modul.
• Auf diesen Seiten (Seite.eineSeite) AddShippingInfo wird gesendet, wenn sich das Versanddienstleister-Funkmodul ändert, und mit dem vorausgewählten Versanddienstleister, wenn der Kunde eine Zahlungsart auswählt, ohne diese zu ändern; AddPaymentInfo wie zuvor.

21.10.2026
v1.3.12

• Einwilligungsdiagnose: Die Namen der vor der Einwilligung vorhandenen Cookies wurden nur einmal beim Laden der Seite gelesen, die von anderen Skripten einige Sekunden später geschriebenen Cookies (aplazame.js und deren Funktionen) hingegen nicht. AMPERE_...) wurden nie angezeigt. Sie werden nach 8 Sekunden und beim Ausblenden oder Verlassen der Seite erneut vorgelesen (Seite ausblenden, , Sichtbarkeitsänderung), während noch keine Einwilligung vorliegt und nur die neuen Namen gesendet werden (Beacon-Feld). Vorab-Einwilligungs-Cookies).

21.10.2026
v1.3.11

Einwilligungsdiagnostik für das Relay (Vertragsabschnitt 13.1)

• POST /1.0/diagnostics Einmal täglich (Wartungsdurchlauf des Cronjobs), bei Änderung des Debug-Schlüssels und über die neue Schaltfläche „Diagnose senden“ (Relay-Bereich der Konfiguration). Nur Zahlen, Cookie-Namen und -Status:
• pro Tag (die letzten 7 vollen Tage und heute): neue Beacons und wie viele erteilt, verweigert, teilweise erteilt oder unbekannte Zustimmungen; Ereignisse und Käufe nach Status (gesendet, durch Zustimmung übersprungen, andere, fehlgeschlagen, debug_sent, anonym);
• die von der Seite gefundene Einwilligungsplattform (cookiesplus, Cookiebot, OneTrust, Complianz, lgcookieslaw, GTM, das Modul...), ob ein Standard-Einwilligungsmodus und Aktualisierungen angezeigt wurden und wer den Standard-Einwilligungsmodus geschrieben hat;
• die NAMEN der vor der Einwilligung vorhandenen Cookies, normalisiert auf ein Muster (AMP_7c485abf30 -> AMPERE_#Niemals ihre Werte, ohne die technischen Werte des Shops und der Zustimmungsplattformen (neue Tabelle) rkra_acp_diag, 30 Tage aufbewahrt);
• der Status des Debug-Modus und des anonymen GA4-Kaufs.
• Die Antwort des Relais (und des Handshakes) kann Debug-Schlüssel widerrufen (debug_revoked).

Debug-Modus nur mit einem Schlüssel des Relais (Vertragsabschnitt 13.2)

• Der Schalter von 1.3.10 ist nicht mehr vorhanden (das Update löscht es). Der Debug-Modus ist nur aktiv, solange ein vom Bedienfeld des Relais ausgegebener Schlüssel gültig ist: rkd1.., Die Gültigkeitsdauer beträgt maximal 24 Stunden. Ein falscher, abgelaufener, zu langer oder fremder Schlüssel wird mit Begründung abgelehnt; ein neues Relay-Token oder ein Widerruf im Panel beendet den Vorgang.
• Gleiche Reichweite wie zuvor: Nur Testbestellungen und Debug-IPs; Lieferungen markiert debug_sent; eine rote Warnung auf jedem Bildschirm des Moduls, solange es dauert.
• Neue Tests tests/diagnostico-relay.php (gegen das Relais) 1.3.0) Und tests/consent-exceptions.php (mit einem Schlüssel).

21.10.2026
v1.3.10

Zwei Ausnahmen von der Einwilligungspflicht (beide standardmäßig deaktiviert)

• Im Debug-Modus „Senden ohne Zustimmung (nur Testbestellungen und aufgelistete IPs)“ werden die Testbestellungen (E-Mail eines Testkunden) sowie die Besuche und Bestellungen von den vom Händler aufgelisteten IPs (exakte IPs oder IPv4-Bereiche ab /24) so gesendet, als ob eine Zustimmung vorläge. Für alle anderen Nutzer gilt dies nicht. Während der Modus aktiv ist, wird auf jedem Bildschirm des Moduls eine rote Warnung angezeigt, und jede Zustellung wird im Ereignisprotokoll (neue Spalte) als „Debug, keine Zustimmung“ markiert. Liefermodus (des Kanalprotokolls).
• GA4: Anonymer Kauf ohne Einwilligung: Der Kauf eines Besuchers, der nicht eingewilligt hat, erreicht GA4 über das Measurement Protocol, wobei alle personenbezogenen Daten (keine Benutzerdaten, keine Benutzer-ID, keine IP-Adresse oder Browser, eine zufällige Client-ID, die einmalig verwendet und nicht gespeichert wird, Einwilligung VERWEIGERT) entfernt werden; lediglich Wert, Währung, Transaktions-ID und Artikel werden erfasst. Die Daten werden niemals an Meta oder eine andere Plattform weitergegeben. Das Ereignis wird im Shop anonymisiert, bevor es an den jeweiligen Builder (Shop oder Relay) weitergeleitet wird, und die zugehörige Anfrage wird nicht gespeichert. Sie wird als „anonym“ gekennzeichnet.
• Alles ungeachtet der Einwilligung weiterzuleiten, ist keine Option und wird es auch in Zukunft nicht sein.
• Neuer Test tests/consent-exceptions.php (gegen das gefälschte Relais).

21.10.2026
v1.3.9

Ereignisprotokoll

• Die Spalte „Kampagne“ der Ereignisse einer Bestellung (Kauf, Rückerstattung) zeigt die Kampagne an, der die Bestellung zugeordnet ist: die letzte Interaktion, die mit der Bestellung verknüpft war. rkra_acp_order, nicht die UTM-Eigenschaft der Ereigniszeile, die leer ist, wenn der Kauf später oder durch eine Zahlungsbenachrichtigung bestätigt wird. Google Ads-Kampagnen ohne utm_campaign Zeigen Sie ihren Namen aus den Einstellungen „Google Ads-Kampagnennamen“ oder ihre gad_campaignid (Die ID befindet sich im Tooltip).
• Neu ist die Option „XML exportieren“ neben „CSV exportieren“ für dieselbe gefilterte Liste (bis zu 5.000 Zeilen). Beide Exporte enthalten die Attribute Quelle, Medium, Kampagne, Kampagnen-ID und Kanal sowie den ersten und letzten Kontaktpunkt (die XML-Datei zusätzlich die Landingpage und das Datum jedes Kontaktpunkts).
• Neuer Test tests/tools/events-export.js (Bildschirm und beide Downloads): grün an 1.7.6.5 Und 9.2.0.

21.10.2026
v1.3.8

Google Ads-Kampagnen ohne utm_campaign

• Google Ads-Anzeigen gad_campaignid (Und gad_source) zur Landingpage-URL, aber die meisten Kampagnen enthalten keine utm_campaignDie Spalte „Kampagne“ zeigte „-“ an. Die ID wird nun als Kampagnen-ID des Touch-Eintrags beibehalten (utm_id, an GA4 gesendet als Kampagnen-ID In Kampagnendetails), Und gad_source wird ebenfalls aufbewahrt.
• Wenn es kein utm_campaign, Die Kampagne wird mit der neuen Einstellung „Google Ads-Kampagnennamen“ benannt (einer pro Zeile, 21888563683 = Socken kaufen; ; =, , ;, , :, , , oder einem Tab) oder zeigt die ID selbst an. Dies gilt für das Auftragspanel, das Ereignisprotokoll, die Statistiken und GA4/Meta. utm_campaign gewinnt immer.
• Von älteren Versionen gespeicherte Berührungen bleiben erhalten gad_campaignid innerhalb ihrer Landingpage-URL: Die ID wird von dort gelesen, daher wird sie auch in den vorherigen Bestellungen angezeigt.

Landingpage

• Mit url_passthrough (Einwilligungsmodus) Die Klick-IDs werden an die internen Links weitergeleitet, und der erste Beacon kann auf der zweiten Seite eintreffen. Wenn die verweisende Seite eine Seite des Shops mit denselben Klick-IDs ist, wird diese Seite als Landingpage verwendet (da sie näher am eigentlichen Einstiegspunkt liegt), und es wird kein interner Verweis gespeichert.
• Neuer Test tests/attribution-gad.php.

21.10.2026
v1.3.7

Bereich der Bestellseite

• Auf der alten Bestellseite von 1.7.6 (Bootstrap 3 Panel) Die Tabelle „Kampagne der Bestellung“ wuchs mit der Landingpage und den Referrer-URLs (gclid, _gl, gbraid…) und deckte die nächsten Blöcke ab (nacex: Die Mitarbeiter konnten den Status der Bestellung nicht ändern). Das Panel macht die Seite nun nie breiter: Markup gültig für Panel Und Karte, Die Tabellen scrollen in ihrem eigenen Kasten mit Tabellenlayout: fest, Die URLs zeigen nur Host und Pfad an (auf 60 Zeichen gekürzt, vollständige URL im Titel).
• Es hat ein eigenes kleines Stylesheet views/css/order-panel.css, wird nur auf der Bestellseite geladen, anstatt auf der gesamten Seite admin.css.
• Neuer Test tests/tools/order-panel.js (Breiten, Überlappung mit einem anderen Block, Screenshot): grün an 1.7.6.5 mit Nacex und auf 9.2.0.

Versöhnung und Zustimmung zu älteren Anordnungen

• Der Abgleich beginnt mit der ersten Bestellung, die das Modul in jedem Geschäft erfasst hat (niedrigste id_order Bestellungen, die vor der Aktivierung des Moduls aufgegeben wurden, werden niemals gesendet, unabhängig davon, wer das Modul betreibt.
• Eine Bestellung berücksichtigt niemals den Kontext (Einwilligung, Kampagne) eines Besuchs des Kunden, der nach der Bestellung begann: findByCustomer() hat eine zeitliche Begrenzung, die mit der gleichen Uhr wie die Besuche gemessen wird.

21.10.2026
v1.3.6

Zahlungsbenachrichtigungen für Backoffice-Aufträge (dringend)

• Der Ursprung einer Ordnung wurde entschieden mit definiert('_PS_ADMIN_DIR_'). Die Module Cronjobs Und automatisches Upgrade Definieren Sie diese Konstante am Anfang ihrer Hauptdatei, sodass nach deren Installation jede durch eine Zahlungsbenachrichtigung (Redsys, Bizum...) erstellte Bestellung als gespeichert wurde. boDer Kauf wurde als Backoffice-Auftrag gefiltert, nie versendet, und die Kampagne ging verloren.
• Neu RkraRuntime::isBackOffice(): ein Administrator-Controller (oder Controller-Typ "admin") oder ein Mitarbeiter im Kontext ohne Front-Controller (die Symfony-Seiten des Backends). Die Konstante wird nicht mehr verwendet, um Entscheidungen über den Besucher oder die Bestellung zu treffen (isFrontVisitor() lässt es auch fallen).
• Das Update repariert die gespeicherten Zeilen: eine als gespeicherte Bestellung bo ohne den Hinweis "Manuelle Bestellung -- Mitarbeiter: ..." (beliebige Sprache) in ps_message wird andere, Das System erhält die Kampagne des Warenkorb-Beacons und den Zeitpunkt der ersten Zahlung. Sobald der Abgleich aktiviert ist, wird er beim nächsten Cronjob-Lauf sofort ausgeführt. Die Käufe, die sich noch innerhalb des jeweiligen Zeitfensters der Plattformen befinden (GA4 72 Stunden, Meta 7 Tage), werden mit ihrer Kampagne in die Warteschlange gestellt. So geht's: cron?task=reconcile.
• Neuer Test tests/origen-bo.php (Cronjobs in einer Benachrichtigung geladen, Mitarbeiter im Backoffice, Reparatur, manueller Auftrag unberührt, Abgleich).

20.10.2026
v1.3.5

Einwilligungsmodus mit einer Einwilligungsplattform, die zuerst ihre Standardeinstellung schreibt

• Einige Cookie-Module (Cookiesplus mit Google Tag Manager) schreiben gtag('consent', 'default', …) direkt danach , bereits mit der Wahl eines wiederkehrenden Besuchers, und senden Sie eine aktualisieren nur wenn das Banner verwendet wird. Das Modul schrieb dann seine eigene Standardeinstellung (alle bestrittenUnd beim Start-up ein aktualisieren mit seinem eigenen Status: Ein Besucher, der die Anfrage angenommen hatte, wurde in GTM abgewiesen, und das Modul sendete nichts an Meta für ihn.
• Jetzt head.tpl schaut auf Datenschicht Erstens: Wenn ein anderer Standardwert ohne Region vorhanden ist, schreibt das Modul weder seinen Standardwert noch die Aktualisierung seines eigenen Cookies, sondern verwendet diese Werte als Ausgangszustand (window.rkraAcpCmpDefault).
• consent.readFromDataLayer() liest diesen Standardwert als Basiswert, sofern vorhanden, und zwar immer unterhalb jedes anderen Wertes. aktualisieren. Die Standardeinstellung des Moduls selbst wird nie gelesen. Ohne eine Zustimmungsplattform ändert sich nichts.
• Neuer Test tests/tools/consent-cmp.js (Neuer Besucher, akzeptiert, neu laden; wiederkehrender Besucher ohne Cookie des Moduls, lehnt ab; vom GTM erfasster Status): alles grün bei 1.7.6.5 mit Cookiesplus 1.7.1 und an 9.1.5 ohne CMP.

20.10.2026
v1.3.4

GA4 mit Google Tag Manager

• Neue Einstellung „Wer sendet die Browserdaten an GA4?“ (GA4-Schritt des Assistenten und GA4-Abschnitt der Konfiguration). Bei „Anderes Tool (GTM)“ sendet das Modul nichts über gtag.js an GA4 (es lädt auch im Modulmodus kein Tag) und sendet nur kaufen Und Erstattung durch das Messprotokoll, mit dem Client-ID Und Sitzungs-ID der _ga Cookies werden verwendet, damit sie der GTM-Sitzung beitreten. Die anderen Plattformen speichern ihre Browseraktivitäten. In GTM werden lediglich die Kauf- und Rückerstattungs-Tags pausiert.
• Neue Einstellung „transaction_id der Einkäufe in GA4“: die Referenz der Bestellung (Standard) oder ihre ID, die von vielen GA4-Modulen und -Tags verwendet wird, sodass alte und neue Berichte zusammengeführt werden. Sie wird im Shop festgelegt und mit dem Ereignis übertragen (ga4_transaction_idDaher verwendet das Relay, das die Anfrage erstellt, dasselbe (das Relay benötigt das RkraGa4Sender dieser Version in ihrer lib/).

20.10.2026
v1.3.3

Beinhaltet alles in 1.3.2, das nicht separat veröffentlicht wurde.

PrestaShop 1.7.6 Und 1.7.7

• Mindestversion gesenkt auf 1.7.6.0. Getestet am 1.7.6.5 (Nachbildung eines realen Ladens), 1.7.8.11, , 9.0.0, , 9.1.5 Und 9.2.0: Installation, die sechs Bildschirme des Backoffice, eine per Banküberweisung bezahlte Bestellung, die Warteschlange zum Relay, die Stornierung (Rückerstattung an GA4) und der Cronjob.
• Vor 1.7.8 Der Kern liest nicht Übersetzungen//*.xlf eines Moduls, und das Modul wurde in Englisch veröffentlicht. Die Kataloge des Moduls werden nun im Speicher dem Übersetzer der Anfrage hinzugefügt (wird auch verwendet von $this->trans() und von {l s='' d=''} (in den Vorlagen). Es wird nichts in die Datenbank oder den Cache geschrieben, und 1.7.8 wird nicht berührt.

Abonnementverlängerungen

• Bestellungen, die ein RKR-Produktabonnement verlängern (es existiert bereits eine ältere Bestellung desselben Abonnements), werden standardmäßig nur an GA4 gesendet: Dort werden die Umsätze addiert, und die Werbeplattformen zählen keine Conversions pro Monat. Die anderen Plattformen speichern sie als übersprungen aus dem Grund Abonnementverlängerung. Neue Einstellung „Abonnementverlängerungen“ (Ereignisse): nur für GA4, für keine Plattform oder für alle.
• Eine Anfrage ohne Cookies, die einen Warenkorb oder einen Kunden nennt (z. B. ein Cronjob oder ein Zahlungs-Webhook eines anderen Moduls), wird für den Besucher nicht mehr bearbeitet: Die Bestellung wird mit Ursprung erfasst. andere Die IP-Adresse und der Browser des Servers werden niemals dem Kunden zugeordnet. Front-Controller benannt chron, , Webhook(s), , Benachrichtigung, , IPN oder Rückruf sind Maschinenaufrufe.

18.10.2026
v1.3.2

Erwartete Ablehnungen werden "übersprungen", nicht als "fehlgeschlagen" gewertet.

• Ereignisse, die eine Plattform nicht empfangen kann, werden nun wie folgt gespeichert: übersprungen mit ihrer Begründung zählen sie nicht als Fehler und werden nicht in das Fehlerprotokoll von PrestaShop geschrieben: keine Zustimmung des Besuchers (Zustimmung:...), keine Kennung, die die Plattform zuordnen kann, in der Regel ein Bot oder ein Besucher ohne Cookies (keine_Identifikatoren), eine kostenlose Bestellung (Nullwert) und ein Ereignis, das älter ist als das, was die Plattform akzeptiert (außerhalb des FenstersBis 1.3.1 Sie waren fehlgeschlagen + ungültiges Ereignis, und füllte das Protokoll (71 Inhalt anzeigen (in einer Nacht).
• Die Zustimmungsprüfung erfolgt vor der Überprüfung der Kennungen: Eine Bestellung ohne Zustimmung wurde in GA4 übersprungen, schlug aber in Meta mit der Meldung „keine Kennungen“ fehl, da ohne Zustimmung die Kundendaten entfernt werden.
• Reale Probleme (ungültige Währung, negativer Wert, fehlerhafter GA4-Name, Datum in der Zukunft, fehlende Seiten-URL) bestehen weiterhin. fehlgeschlagen mit ihrer Begründung.

Versöhnung

• Eine in einem Kanal fehlende Bestellung wird nur für die Kanäle in die Warteschlange gestellt, in denen sie fehlt und die sie noch annehmen. Eine Bestellung, die innerhalb der 7 Tage von Meta, aber nach den 72 Stunden von GA4 eingegangen ist, wurde für beide Kanäle in die Warteschlange gestellt und scheiterte in GA4 aufgrund ihres Alters.
• Eine bereits übersprungene Lieferung außerhalb des Fensters wird im Bericht als außerhalb des Zeitfensters liegend, nicht als zugestellt, gewertet.

Statusänderungen ohne Währung im Kontext

• Bestellung verfolgen, , trackRefunds Und TrackCancellation Laden Sie die Währung der Bestellung (und gegebenenfalls deren Sprache und Shop) in Kontext Währenddessen wird das Ereignis verarbeitet und der vorherige Zustand wiederhergestellt. Eine Statusänderung über die Konsole, ein ERP-System oder einen Cronjob ist fehlgeschlagen. ComputingPrecision::getPrecision(): Argument #1 muss vom Typ int sein, null wurde übergeben und der Kauf ging bis zur Klärung verloren.

Bestellungen, die vor dem Modul aufgegeben wurden

• Für diese Personen sind keine Einwilligungen gespeichert, und sie werden gemäß den Standardeinstellungen des Einwilligungsmodus behandelt (standardmäßig abgelehnt, daher werden sie übersprungen). Einwilligung: ad_user_data_deniedDies ist beabsichtigt und wird nun im Leitfaden erläutert (Einwilligungsmodus v2 & Datenschutz → Bestellungen, die vor dem Modul aufgegeben wurden).

08.10.2026
v1.3.1

Kampagnenattribution (UTM)

• Attributionsrichtlinie: Letzter nicht-direkter Kontakt, wie GA4 es für seine Sitzungen handhabt. Ein Besuch bei utm_* oder eine Anzeigenklick-ID ersetzt die Kampagne; eine direkte Rückkehr (nicht utm_*, (ohne Klick-ID) wird für die Dauer des Besucher-Cookies gespeichert (standardmäßig 90 Tage). Die erste Berührung wird ebenfalls gespeichert und niemals überschrieben.
• Interne Kampagnen ersetzen nicht die externen: neue Einstellungen „Interne utm_source-Werte“ (kommagetrennt) und „UTM bei internen Links ignorieren“ (UTM auf einer Seite, die vom Shop selbst aus aufgerufen wird, ist standardmäßig aktiviert).
• Jeder Klick speichert utm_source / medium / campaign / term / content / id und, falls vorhanden, utm_source_platform, utm_creative_format und utm_marketing_tactic, die zugehörigen Klick-IDs, die Landingpage, den Referrer und den Zeitpunkt. Eine Klick-ID ohne UTM-Informationen deutet auf Google/CPC (gclid, gbraid, wbraid) oder Bing/CPC (msclkid) hin.
• Die Kampagne wird mit der Bestellung verknüpft, sobald diese aufgegeben wird: Ein späterer Besuch mit einer anderen Kampagne ändert daran nichts, und eine im Backend erfasste Bestellung ist keiner Webkampagne zugeordnet. Später bestätigte Käufe (Zahlungseingang, Backend, Cronjob) behalten die Kampagne des Besuchs bei, bei dem die Bestellung aufgegeben wurde.
• Backoffice: „Kampagne der Bestellung“ im Bestellbereich (erster und letzter Kontaktpunkt, Klick-IDs, Landingpage, Referrer), eine Kampagnenspalte im Ereignisprotokoll und im zugehörigen CSV-Export sowie „Umsatz nach Kampagne (utm)“ in der Statistik.
• GA4-Messprotokoll: Kampagnendetails Das Ereignis (Kampagnen-ID, Kampagne, Quelle, Medium, Begriff, Inhalt) wird nur dann mit dem Kauf gesendet, wenn es nicht an der Browsersitzung teilnehmen kann (nein _ga_ Cookie: Einwilligung verweigert (Blocker). Mit einer Session-ID ordnet GA4 den Kauf bereits der Kampagne dieser Sitzung zu. Neue Einstellung „Kampagne an GA4 und Meta senden“ (aktiviert).
• Meta Conversions API: utm_source / medium / campaign / term / content / id als benutzerdefinierte Eigenschaften von benutzerdefinierte Daten.

KI-Kanal

• Besuche von KI-Assistenten bilden ihren eigenen Kanal „KI“ mit der jeweiligen Plattform (ChatGPT, Perplexity, Gemini, Copilot, Claude, Meta AI, DeepSeek, Mistral, Grok, You.com, Phind, Poe), erkannt durch den Referrer oder durch utm_source. Die Liste ist die Konstante RkraAttribution::AI_PLATFORMS.
• Ein Besuch mit einer Klick-ID einer Anzeige (ChatGPT-Anzeigen) opref / obref, gclid, msclkid...) ist bezahlte, niemals organische KI; ChatGPT-Anzeigen ohne UTM werden als chatgpt / cpc angezeigt.
• Wird in der Reihenfolge der Kampagne beibehalten; angezeigt im Bestellbereich (Spalte „Kanal“), im Ereignisprotokoll und dessen CSV-Datei (KI-Plattform) und „Verkäufe durch KI-Assistenten“ in der Statistik (Bestellungen und Umsatz pro Plattform).
• GA4-Checkliste: Geführte Schritte zum Erstellen einer benutzerdefinierten Kanalgruppe mit einem "KI"-Kanal (Quelle entspricht regulärem Ausdruck, Ausdruck zum Kopieren bereit, über "Verweise"). Mit Google über das Relay verbunden (1.2.1 oder später) verfügt der Schritt über eine Schaltfläche "Reparieren", die die Gruppe "Canales con IA (RKR)" erstellt oder aktualisiert, und das Audit setzt dies automatisch in Kraft; wenn die Immobilie bereits über ihre 2 benutzerdefinierten Gruppen verfügt, wird erklärt, was zu tun ist.
• Absender: Ein Ereignis ohne bestimmte Schlüssel (Menge, Anzahl der Artikel... aus einem anderen Modul, eine alte Warteschlangenzeile oder das Relay) gibt keine PHP-Warnungen mehr aus.

Behoben

• Die Landingpage und der Referrer des Besuchers wurden durch jede von ihm besuchte Seite überschrieben; jetzt wird der erste Besuch beibehalten (jede Kampagne behält ihre eigenen Daten).
• Interne Banner mit eigenen utm_* ersetzte die Kampagne, aus der der Besucher kam.

Geprüft (keine Änderung erforderlich)

• Das Modul entfernt, überschreibt oder leitet niemals um. utm_*, gclid oder fbclid: nein history.replaceState, keine Weiterleitung, keine eigene kanonische URL.
• Wenn GA4 oder Google Ads von einem anderen Modul oder von GTM geladen werden, fügt dies keine zusätzlichen Kosten hinzu. gtag('config') und nein Seitenansicht; mit eigenem Tag, genau eine Konfiguration.
• Es schreibt nur seine eigenen Cookies (rkra_vid, , rkra_consent); _ga, , _ga_, , _gcl_aw, , _fbp, , _fbc und nur die Cookies anderer Tags werden gelesen.

07.10.2026
v1.3.0

Neue Plattformen

• Microsoft Advertising (UET Conversions API), Pinterest Conversions API, Snapchat Conversions API und LinkedIn Conversions API: jeweils ein eigener Schritt im Assistenten, Konfiguration, Schaltfläche „Testen“ mit Erläuterung des Plattformfehlers, Statusanzeige, Abgleich, Ereignisnamen, Einwilligung und Klick-IDs (msclkid, , _epik, , ScCid / _scid, , li_fat_id).
• Ihre Browser-Tags (UET, Pinterest-Tag, Snap Pixel, LinkedIn Insight-Tag) können vom Modul mit der gleichen Ereignis-ID wie der Server geladen werden; UET folgt seinem Zustimmungsmodus, die anderen werden geladen, sobald der Besucher die Werbe-Cookies akzeptiert.
• Microsoft erhält die E-Mail und die Telefonnummer mit eigener Normalisierung (keine Punkte oder Aliase in der E-Mail, E.164 mit "+").

Relay (Vertrag v1.2)

• Jeder Aufruf an das Relay wird mit der Signatur v2 (Methode, Pfad, Zeitstempel und Body) signiert; v1 nur gegenüber einem Relay, das v2 nicht kennt.
• Verbinden Sie sich in jedem Schritt des Assistenten über den OAuth-Hub des Relays mit Google, Meta, TikTok, Microsoft, Pinterest oder LinkedIn: Wählen Sie Konto, Property, Stream, Conversion-Aktion, Pixel oder Regel aus, und das Modul konfiguriert alles. Der Shop speichert nur die nicht geheimen Werte; das Relay verwaltet die Tokens (Verwahrung). Die Verbindung wird automatisch wiederhergestellt und getrennt, und auf jedem Bildschirm wird eine Warnung angezeigt, wenn das Relay eine erneute Verbindung anfordert.
• GA4-Checkliste, die mit Google abgeglichen wird, wenn eine Verbindung zu Google besteht: Die Punkte, die die Admin-API sehen kann, werden automatisch abgehakt, und eine Schaltfläche "Fix" wendet an, was die API zulässt (Retention, Kauf als Schlüsselereignis, Dimensionen, Verknüpfung mit Google Ads); der Rest bleibt eine manuelle Aufgabe mit ihrem jeweiligen Pfad.
• Tarife (Vertragsabschnitt 12): Tarif, kostenlose Testphase, Ablaufdatum und monatliches Veranstaltungskontingent werden im Backoffice angezeigt; die Kanäle, die ein Tarif nicht beinhaltet, werden direkt vom Shop gesendet, wenn sie über eigene Zugangsdaten verfügen, oder es wird gemeldet, dass sie nicht gesendet wurden, wobei der Grund in der Statusanzeige angegeben wird.
• Ein über das Relay verbundener Kanal wird niemals direkt ohne die Zugangsdaten des Shops gesendet: Er wartet auf das Relay.

Datenerfassung

• Jedes Browser-Tag (Meta Pixel, GA4, Google Ads, TikTok Pixel) hat einen Modus: vom Modul geladen, von einem anderen Modul oder dem Google Tag Manager geladen oder nur vom Server geladen. In den ersten beiden Fällen senden Browser und Server dieselben Daten. Ereignis-ID, Die Plattformen deduplizieren also Daten. GA4 empfängt niemals ein Ereignis doppelt: Die Navigation läuft über gtag, Käufe und Rückerstattungen über das Measurement Protocol (alles darüber im reinen Servermodus).
• Einwilligungsmodus v2, bei dem die gespeicherte Einwilligung vor dem Laden der Tags wiederhergestellt wird, Werbedatenredaktion, , url_passthrough und Adapter für Cookiebot, CookieYes, Complianz und OneTrust neben dem gtag Aktualisierung der Einwilligung.
• Vollständiger GA4-E-Commerce-Funnel auf Classic, Hummingbird und 1.7.8 Themen: Artikelliste anzeigen, , select_item, , Werbung ansehen, , Auswahl der Werbeaktion, , Ansichtselement, , in den Warenkorb legen, , aus dem Warenkorb entfernen, , Warenkorb anzeigen, , begin_checkout, , add_shipping_info, , Zahlungsinformationen hinzufügen, , kaufen, , suchen, , Login, , Melden Sie sich an, , Leads generieren, , zur Wunschliste hinzufügen.
• Artikel mit Kategoriepfad (5 Ebenen), Marke, Variante, Liste, Index, Rabatt und Coupon; der Einkaufspreis verlässt niemals das Geschäft.
• Klick-IDs (gclid, , gbraid, , geflochten, , fbclid, , ttclid, , msclkid...) und UTM-Parameter werden 90 Tage lang in einem signierten Erstanbieter-Cookie gespeichert, das vom Server gesetzt wird, wobei die Zeit des ersten Auftretens (Meta) enthalten ist. fbc).
• Identität: Telefonnummer in E.164 mit Ländervorwahl, externe Kennung des Kunden und des Besuchers, GA4 Benutzer-ID (pur oder gehackt), _ga Sitzungs-ID.
• Geschäftsdaten: Marge als Google Ads-Wert (optional), Neukunde, Kundenwert, Gutschein, Versandstufe und Zahlungsmethode.
• Backoffice-Ereignisse: Kauf bei Zahlungseingang (Standardeinstellung für Neuinstallationen; Upgrades behalten die Einstellung „bei Erstellung“), im Backoffice erstellte Bestellungen (Telefonanruf), teilweise Rückerstattungen für Gutschriften, Stornierungen und Anpassungen der Google Ads-Conversion-Rate (RÜCKRUF / NEUSTELLUNG).

Einrichtung und Gesundheit

• Einrichtungsassistent in 11 Schritten mit Live-Formatprüfung, Erkennung bereits von anderen Modulen gedruckter Tags, Theme, Einwilligungsbanner, Zahlungsmodulen und Cronjob sowie einem „Testen“-Button pro Plattform, der ein echtes Testereignis sendet und den Plattformfehler übersetzt. Platz für einen „Mit Google/Meta/TikTok verbinden“-Button in jedem Schritt (noch nicht aktiv).
• Plattform-Checklisten für GA4, Meta und TikTok mit Deep Links zum rechten Bildschirm der jeweiligen Plattform; die Häkchen werden pro Shop gespeichert.
• Gesundheits-Ampelsystem pro Plattform: Auftragsabdeckung, Übereinstimmungsqualität, Klick-ID-Anteil, Verzögerung und kürzlich aufgetretene Fehler.

Lieferung

• Jedes Ereignis wird vor dem Absenden validiert (Datum, Plattformfenster, Währung, Beträge, erforderliche Kennungen); ungültige Ereignisse werden mit Angabe des Grundes gespeichert, anstatt von der Plattform abgelehnt zu werden.
• Serverereignisse ohne Seite (Zahlungen im Backend, Cronjobs, Rückerstattungen) enthalten die Shop-URL und einen zusammenhängenden Aktionsquelle.
• Backup-Cron: Wenn der eigentliche Cronjob nicht ausgeführt wird, werden die Anfragen der Besucher in der Warteschlange verarbeitet, nachdem die Antwort gesendet wurde.
• Täglicher Abgleich von Bestellungen und Lieferungen pro Plattform, innerhalb des jeweiligen Plattformfensters, mit einem Bericht im Konfigurationsbildschirm und der Cron-Aufgabe versöhnen.
• Während der Bearbeitung Ihrer Anfrage im Empfangsbereich oder beim Bezahlvorgang darf kein Netzwerkanruf erfolgen.

Behebt

• Der Besucher-Cookie verwendet nicht mehr den Kern Plätzchen Durch die Erstellung eines neuen Cookies mit einem anderen Schlüssel wurde die Verschlüsselungsfunktion des Session-Cookies ersetzt, und der Besucher verlor seinen Warenkorb.
• GA4 Anzahl_Elemente und die Serverelemente der Browserereignisse waren leer.