RKR API Conversions Pro: Server-side conversions for Meta, GA4, Google Ads, and more

v1.3.122026/10/21

• Consent diagnostics: the names of the cookies present before consent were read only once, when the page loaded, so the ones that other scripts write a few seconds later (aplazame.js and its AMP_...) never showed up. They are read again at 8 seconds and when the page is hidden or left (pagehide, , visibilitychange), while there is still no consent, and only the new names are sent (beacon field pre_consent_cookies).

v1.3.112026/10/21

Consent diagnostics for the relay (contract section 13.1)

• POST /1.0/diagnostics once a day (maintenance pass of the cron), when the debug key changes and from the new button "Send diagnostics" (relay section of the configuration). Only figures, cookie names and states:
• per day (the last 7 complete days and today): new beacons and how many granted, denied, partially granted or unknown consent; events and purchases by state (sent, skipped by consent, other, failed, debug_sent, anonymous);
• the consent platform found by the page (cookiesplus, Cookiebot, OneTrust, Complianz, lgcookieslaw, GTM, the module...), whether a Consent Mode default and updates were seen and who wrote the default;
• the NAMES of the cookies present before consent, normalized to a pattern (AMP_7c485abf30 -> AMP_#), never their values, without the technical ones of the shop and of the consent platforms (new table rkra_acp_diag, kept 30 days);
• the state of the debug mode and of the anonymous GA4 purchase.
• The answer of the relay (and of the handshake) can revoke debug keys (debug_revoked).

Debug mode only with a key of the relay (contract section 13.2)

• The switch of 1.3.10 is gone (the update deletes it). The debug mode is on only while a key issued by the panel of the relay is valid: rkd1.., 24 hours at most. A wrong, expired, too long or foreign key is refused with its reason; a new relay token or a revocation in the panel ends it.
• Same reach as before: test orders and the debug IPs only; deliveries marked debug_sent; a red warning on every screen of the module while it lasts.
• New tests tests/diagnostico-relay.php (against the relay 1.3.0) and tests/consent-exceptions.php (with a key).

v1.3.102026/10/21

Two exceptions to consent (both off by default)

• Debug mode "send without consent (test orders and listed IPs only)": the test orders (e-mail of a test customer) and the visits and orders from the IPs the merchant lists (exact or IPv4 ranges from /24) are sent as if consent were granted. Nobody else. A red warning shows on every screen of the module while it is on, and each delivery is marked "debug, no consent" in the event log (new column delivery_mode of the channel log).
• "GA4: anonymous purchase without consent": the purchase of a visitor who did not consent reaches GA4 through the Measurement Protocol stripped of everything that identifies a person (no user data, no user_id, no IP nor browser, a random client_id used once and never stored, consent DENIED); only value, currency, transaction_id and items. Never to Meta or any other platform. The event is anonymized in the shop, before any builder (the shop or the relay), and its request is not stored. Marked "anonymous".
• Sending everything regardless of consent is not an option and will not be.
• New test tests/consent-exceptions.php (against the fake relay).

v1.3.92026/10/21

Event log

• The column "Campaign" of the events of an order (Purchase, Refund) shows the campaign the order is attributed to: the last touch frozen with the order in rkra_acp_order, not the utm of the event row, which is empty when the purchase is confirmed later or by a payment notification. Google Ads campaigns without utm_campaign show their name from the setting "Google Ads campaign names" or their gad_campaignid (the id is in the tooltip).
• New "Export XML" next to "Export CSV", for the same filtered list (up to 5,000 rows). Both exports carry the attributed source, medium, campaign, campaign id and channel, and the first and last touch (the XML also the landing page and date of each touch).
• New test tests/tools/events-export.js (screen and both downloads): green on 1.7.6.5 and 9.2.0.

v1.3.82026/10/21

Google Ads campaigns without utm_campaign

• Google Ads ads gad_campaignid (and gad_source) to the landing URL, but most campaigns carry no utm_campaign: the column "Campaign" showed "-". The id is now kept as the campaign id of the touch (utm_id, sent to GA4 as campaign_id in campaign_details), and gad_source is kept too.
• When there is no utm_campaign, the campaign is named with the new setting "Google Ads campaign names" (one per line, 21888563683 = Shopping socks; ; =, , ;, , :, , , or a tab), or shows the id itself. It applies to the order panel, the event log, the statistics and GA4/Meta. TO utm_campaign always wins.
• Touches stored by older versions keep gad_campaignid inside their landing URL: the id is read from there, so the orders of before also show it.

Landing page

• With url_passthrough (Consent Mode) the click ids travel to the internal links, and the first beacon can arrive on the second page. When the referrer is a page of the shop with the same click ids, that page is taken as the landing page (closer to the real entry) and no internal referrer is stored.
• New test tests/attribution-gad.php.

v1.3.72026/10/21

Panel of the order page

• On the old order page of 1.7.6 (Bootstrap 3 panel) the table "Campaign of the order" grew with the landing page and referrer URLs (gclid, _gl, gbraid…) and covered the next blocks (nacex: the staff could not change the state of the order). The panel now never makes the page wider: markup valid for panel and card, the tables scroll inside their own box with table-layout: fixed, and the URLs show host and path only (cut to 60 characters, full URL in the title).
• Its own small stylesheet views/css/order-panel.css, loaded only on the order page, instead of the whole admin.css.
• New test tests/tools/order-panel.js (widths, overlap with another block, screenshot): green on 1.7.6.5 with Nacex and on 9.2.0.

Reconciliation and consent of older orders

• The reconciliation starts at the first order the module saw in each shop (lowest id_order of its own table): orders placed before the module was active are never sent, whoever runs it.
• An order never takes the context (consent, campaign) of a visit of its customer that started after the order: findByCustomer() has a date limit, measured with the same clock as the visits.

v1.3.62026/10/21

Orders of payment notifications taken for back office orders (urgent)

• The origin of an order was decided with defined('_PS_ADMIN_DIR_'). The modules cron jobs and autoupgrade define that constant at the top of their main file, so with them installed every order created by a payment notification (Redsys, Bizum...) was stored as bo: its purchase was filtered as a back office order, never sent, and it lost its campaign.
• New RkraRuntime::isBackOffice(): an admin controller (or controller_type "admin"), or an employee in the context without a front controller (the Symfony pages of the back office). The constant is no longer used to decide anything about the visitor or the order (isFrontVisitor() drops it too).
• The update repairs the stored rows: an order stored as bo without the note "Manual order -- Employee: …" (any language) in ps_message becomes other, gets the campaign of the beacon of its cart and the time of its first paid state. When the reconciliation is enabled, the next run of the cron runs it at once, and the purchases that are still inside the window of each platform (GA4 72 h, Meta 7 days) are queued with their campaign. To do it right away: cron?task=reconcile.
• New test tests/origen-bo.php (cronjobs loaded in a notification, employee in the back office, repair, manual order untouched, reconciliation).

v1.3.52026/10/20

Consent Mode with a consent platform that writes its default first

• Some cookie modules (cookiesplus with Google Tag Manager) write gtag('consent', 'default', …) right after , already with the choice of a returning visitor, and send an update only when the banner is used. The module then wrote its own default (all denied) and, at start-up, an update with its own state: a visitor who had accepted ended up denied in GTM, and the module did not send anything to Meta for him.
• Now head.tpl looks at the dataLayer first: if another default without region is there, the module writes neither its default nor the update of its own cookie, and takes those values as the initial state (window.rkraAcpCmpDefault).
• consent.readFromDataLayer() reads that default as the base when there is one, always below any update. The default of the module itself is never read. Without a consent platform nothing changes.
• New test tests/tools/consent-cmp.js (new visitor, accepts, reload, returning visitor without the cookie of the module, rejects; state seen by GTM): all green on 1.7.6.5 with cookiesplus 1.7.1 and on 9.1.5 without a CMP.

v1.3.42026/10/20

GA4 with Google Tag Manager

• New setting "Who sends the browsing to GA4" (GA4 step of the assistant and GA4 section of the configuration). With "Another tool (GTM)" the module sends nothing to GA4 through gtag.js (it does not load the tag either, even in "module" mode) and sends only purchase and refund through the Measurement Protocol, with the client_id and session_id of the _ga cookies so they join the session of GTM. The other platforms keep their browsing events. In GTM only the purchase and refund tags are paused.
• New setting "transaction_id of the purchases in GA4": the reference of the order (default) or its id, the one many GA4 modules and tags used, so old and new reports join. It is decided in the shop and travels with the event (ga4_transaction_id), so the relay that builds the request uses the same one (the relay needs the RkraGa4Sender of this version in its lib/).

v1.3.32026/10/20

Includes everything in 1.3.2, which was not published on its own.

PrestaShop 1.7.6 and 1.7.7

• Minimum version lowered to 1.7.6.0. Tested on 1.7.6.5 (copy of a real shop), 1.7.8.11, , 9.0.0, , 9.1.5 and 9.2.0: installation, the six screens of the back office, an order paid by bank transfer, the queue to the relay, the cancellation (refund to GA4) and the cron.
• Before 1.7.8 the core does not read the translations//*.xlf of a module, and the module came out in English. The catalogs of the module are now added, in memory, to the translator of the request (also used by $this->trans() and by {l s='' d=''} in the templates). Nothing is written to the database or the cache, and 1.7.8 is not touched.

Subscription renewals

• The orders that renew a subscription of RKR Product Subscription (another, older order of the same subscription exists) are sent only to GA4 by default: the revenue adds up there and the advertising platforms do not count a conversion every month. The other platforms store them as skipped with the reason subscription_renewal. New setting "Subscription renewals" (Events): only to GA4, to no platform or to all of them.
• A request without cookies that names a cart or a customer (the cron or a payment webhook of another module) is no longer taken for the visitor: the order is recorded with origin other and the IP and browser of the server are never attached to the customer. Front controllers named chron, , webhook(s), , notification, , IPN or callback are machine calls.

v1.3.22026/10/18

Expected refusals are "skipped", not "failed"

• Events a platform has nothing to receive are now stored as skipped with their reason, do not count as errors and are not written to the error log of PrestaShop: no consent of the visitor (consent:...), no identifier the platform can match, usually a bot or a visitor without cookies (no_identifiers), a free order (zero_value) and an event older than the platform accepts (out_of_windowUntil 1.3.1 They were failed + invalid_event, and filled the log (71 ViewContent in one night).
• The consent gate is checked before the identifiers: an order without consent was skipped in GA4 but failed in Meta with "no identifiers", because without consent its customer data is removed.
• Real problems (invalid currency, negative value, malformed GA4 name, a date in the future, a missing page URL) are still failed with their reason.

Reconciliation

• An order missing in one channel is queued only for the channels that miss it and still accept it. An order within the 7 days of Meta but after the 72 hours of GA4 was queued for both, and failed in GA4 by age.
• A delivery already skipped as out_of_window is counted as out of the window in the report, not as delivered.

Status changes without a currency in the context

• trackOrder, , trackRefunds and trackCancellation load the currency of the order (and its language and shop when missing) in Context while they compute the event, and restore what was there afterwards. A status change from the console, an ERP or a cron failed with ComputingPrecision::getPrecision(): Argument #1 must be of type int, null given and the purchase was lost until the reconciliation.

Orders placed before the module

• They have no consent stored and are treated with the defaults of Consent Mode (denied by default, so they are skipped with consent:ad_user_data_denied). This is deliberate and now explained in the Guide (Consent Mode v2 & privacy → Orders placed before the module).

v1.3.12026/10/08

Campaign attribution (utm)

• Attribution policy: last non-direct touch, as GA4 does for its sessions. A visit with utm_* or an ad click id replaces the campaign; a direct return (not utm_*, no click id) keeps it for the lifetime of the visitor cookie (90 days by default). The first touch is also kept and never replaced.
• Internal campaigns do not replace the external one: new settings "Internal utm_source values" (comma separated) and "Ignore utm on internal links" (utm on a page reached from the shop itself, on by default).
• Each touch keeps utm_source / medium / campaign / term / content / id and, when present, utm_source_platform, utm_creative_format and utm_marketing_tactic, its click ids, landing page, referrer and time. A click id without utm implies google / cpc (gclid, gbraid, wbraid) or bing / cpc (msclkid).
• The campaign is frozen with the order when it is placed: a later visit with another campaign does not move it, and an order typed in the back office has no web campaign. Purchases confirmed later (payment received, back office, cron) keep the campaign of the visit that placed the order.
• Back office: "Campaign of the order" in the order panel (first and last touch, click ids, landing page, referrer), a Campaign column in the event log and in its CSV export, and "Sales by campaign (utm)" in the statistics.
• GA4 Measurement Protocol: campaign_details event (campaign_id, campaign, source, medium, term, content) sent with the purchase only when it cannot join the browser session (no _ga_ cookie: consent denied, blocker). With a session_id GA4 already attributes the purchase to the campaign of that session. New setting "Send the campaign to GA4 and Meta" (on).
• Meta Conversions API: utm_source / medium / campaign / term / content / id as custom properties of custom_data.

AI channel

• Visits from AI assistants form their own channel "AI" with the concrete platform (ChatGPT, Perplexity, Gemini, Copilot, Claude, Meta AI, DeepSeek, Mistral, Grok, You.com, Phind, Poe), detected by the referrer or by utm_source. The list is the constant RkraAttribution::AI_PLATFORMS.
• A visit with a click id of an ad (ChatGPT Ads oppref / obref, gclid, msclkid...) is paid, never organic AI; ChatGPT Ads without utm shows as chatgpt / cpc.
• Kept with the order like the campaign; shown in the order panel (Channel column), the event log and its CSV (ai_platform), and "Sales from AI assistants" in the statistics (orders and revenue per platform).
• GA4 checklist: guided step to create a custom channel group with an "AI" channel ("Source matches regex", expression ready to copy, above "Referral"). With Google connected through the relay (1.2.1 or later) the step has a "Fix" button that creates or updates the group "Canales con IA (RKR)", and the audit ticks it by itself; when the property already has its 2 custom groups, it explains what to do.
• Senders: an event without some keys (quantity, items_count... from another module, an old queue row or the relay) no longer prints PHP warnings.

Fixed

• The landing page and referrer of the visitor were overwritten by every page he visited; they now keep the first visit (each campaign keeps its own).
• Internal banners with their own utm_* replaced the campaign the visitor came from.

Checked (no change needed)

• The module never removes, rewrites or redirects utm_*, gclid or fbclid: no history.replaceState, no redirect, no canonical of its own.
• With GA4 or Google Ads loaded by another module or by GTM it adds no gtag('config') and no page_view; with its own tag, exactly one config.
• It writes only its own cookies (rkra_vid, , rkra_consent); _ga, , _ga_, , _gcl_aw, , _fbp, , _fbc and the cookies of other tags are only read.

v1.3.02026/10/07

New platforms

• Microsoft Advertising (UET Conversions API), Pinterest Conversions API, Snapchat Conversions API and LinkedIn Conversions API: their own step in the assistant, configuration, "Test" button with the platform error explained, health light, reconciliation, event names, consent and click ids (msclkid, , _epik, , ScCid / _scid, , li_fat_id).
• Their browser tags (UET, Pinterest tag, Snap Pixel, LinkedIn Insight Tag) can be loaded by the module with the same event id as the server; UET follows its consent mode, the others load once the visitor accepts the advertising cookies.
• Microsoft gets the email and the phone with its own normalization (no dots nor aliases in the email, E.164 with "+").

Relay (contract v1.2)

• Every call to the relay is signed with the signature v2 (method, path, timestamp and body); v1 only towards a relay that does not know v2.
• "Connect with Google / Meta / TikTok / Microsoft / Pinterest / LinkedIn" in each step of the assistant through the OAuth hub of the relay: choose the account, property, stream, conversion action, pixel or rule, and the module configures it. The shop keeps only the values that are not secret; the relay keeps the tokens ("custody"). Reconnect and disconnect, and a warning on every screen when the relay asks to reconnect.
• GA4 checklist checked with Google when Google is connected: the points the Admin API can see are ticked by themselves and a "Fix" button applies what the API allows (retention, purchase as key event, dimensions, link with Google Ads); the rest stays as a manual task with its path.
• Plans (contract section 12): plan, free trial, expiration and monthly event quota shown in the back office; the channels a plan does not include are sent directly from the shop when they have their own credentials, or are reported as not sent, with the reason in the health light.
• A channel connected through the relay is never sent directly without the shop's own credentials: it waits for the relay.

Data collection

• Each browser tag (Meta Pixel, GA4, Google Ads, TikTok Pixel) has a mode: loaded by the module, loaded by another module or Google Tag Manager, or server only. In the first two the browser and the server send the same event_id, so the platforms deduplicate. GA4 never receives an event twice: navigation goes through gtag, purchases and refunds through the Measurement Protocol (everything through it in server-only mode).
• Consent Mode v2 with stored consent restored before the tags load, ads_data_redaction, , url_passthrough and adapters for Cookiebot, CookieYes, Complianz and OneTrust besides the gtag consent update.
• Complete GA4 e-commerce funnel on Classic, Hummingbird and 1.7.8 themes: view_item_list, , select_item, , view_promotion, , select_promotion, , view_item, , add_to_cart, , remove_from_cart, , view_cart, , begin_checkout, , add_shipping_info, , add_payment_info, , purchase, , search, , login, , sign up, , generate_lead, , add_to_wishlist.
• Items with category path (5 levels), brand, variant, list, index, discount and coupon; the cost price never leaves the shop.
• Click ids (gclid, , gbraid, , wbraid, , fbclid, , ttclid, , msclkid...) and UTM parameters kept 90 days in a signed first-party cookie set by the server, with the first-seen time (Meta fbc).
• Identity: phone in E.164 with the country prefix, external id of the customer and of the visitor, GA4 user_id (plain or hashed), _ga session id.
• Business data: margin as Google Ads value (optional), new customer, lifetime value, coupon, shipping tier and payment method.
• Back office events: purchase when the order is paid (default for new installs; upgrades keep "when created"), orders created in the back office (phone_call), partial refunds for credit slip, cancellations, and Google Ads conversion adjustments (RETRACTION / RESTATEMENT).

Setup and health

• Setup assistant in 11 steps with live format checks, detection of tags already printed by other modules, theme, consent banner, payment modules and cron, and a "Test" button per platform that sends a real test event and translates the platform error. Room for a "Connect with Google / Meta / TikTok" button in each step (not active yet).
• Platform checklists for GA4, Meta and TikTok with deep links to the right screen of each platform; the ticks are stored per shop.
• Health traffic light per platform: order coverage, match quality, click id share, delay and recent errors.

Delivery

• Every event is validated before it is sent (date, platform window, currency, amounts, required identifiers); invalid events are kept with the reason instead of being rejected by the platform.
• Server events without a page (paid in the back office, cron, refunds) carry the shop URL and a coherent action_source.
• Backup cron: when the real cron does not run, visitors' requests process the queue after the response has been sent.
• Daily reconciliation of orders against deliveries per platform, inside each platform's window, with a report in the configuration screen and the cron task reconcile.
• No network call during the front office response or the checkout.

Fixes

• The visitor cookie no longer uses the core Cookie class: creating one with another key replaced the encryption engine of the session cookie and the visitor lost the cart.
• GA4 num_items and server items of browser events were empty.