Version 1.4.2 requires at least PHP 7.2.5 because of its bundled HTTP libraries; the PHP version must also meet the requirements of your PrestaShop version. Server-side purchase and refund tracking additionally requires active PD Cookie Pro in live mode with Consent Mode v2, a matching consent revision, analytics consent and saved client/session attribution. An API Secret alone is not sufficient.
Server-side purchase is not sent for orders with paid gift wrapping, more than 200 order lines or a missing reference/EAN when that item_id format is selected. Credit slips must have consistent amounts and items; records with partial != 0 and voucher types are rejected. Type 2 is supported only for an unambiguous shipping-only refund. A partial refund of product quantities is not the same as the technical partial flag.
Key features and functionalities
- 15 named e-commerce and account events:
view_item, view_item_list, select_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund, search, view_search_results, sign_up and login.
- Optional
page_view: the administrator can keep automatic pageview measurement in the module or disable it when pageview tracking is handled by Google Tag Manager or another solution.
- Purchase after a configured status: version 1.4.2 sends purchase from the server after a status selected by the administrator as confirming payment is saved in the order history and the other conditions are met. The module does not independently verify settlement with the payment provider.
- Measurement Protocol for financial operations: sending
purchase and refund requires the primary Measurement ID, API Secret, saved attribution/session data, and current analytics consent.
- Controlled refunds: the module supports a full refund after the selected status and new PrestaShop credit slips, including partial corrections, only when a qualifying purchase has previously been recorded.
- Financial operations log: a persistent register and per-order lock control the module's own purchases and refunds; the back office offers a read-only view with filtering, sorting and pagination. This does not deduplicate events sent independently by GTM or other modules.
- Two Measurement IDs: you can configure the primary and an optional second GA4 ID for events sent from the browser tag.
- Five ways to build
item_id: product ID, product ID with combination ID separated by a hyphen, product ID with combination ID separated by an underscore, reference, or EAN.
- Catalog data in events: the module sends, among other things, the identifier, name, variant, brand, categories, price, discount, quantity, currency, and product list data, if available in PrestaShop.
- Discount coupons: supported browser events can include the applied cart rule's name and code. In version 1.4.2, the server-side purchase payload sent via Measurement Protocol does not include coupon codes.
- User ID for a logged-in customer: when the option is enabled, the module sends the technical customer identifier to GA4 with
analytics_storage consent; this does not replace contact data.
- User-provided data: when the option is enabled and current
ad_user_data consent is present, the module can send the email address and available phone number or address in the format required by Google; identifying data is normalized and hashed with SHA-256.
- Google Ads dynamic remarketing: when the feature is enabled and the Google Ads ID is provided, the tag receives product identifiers, page type, and cart value.
- DebugView and diagnostics: debug mode logs browser events and sets their debug_mode flag for GA4 DebugView. It does not set this flag for server-side purchase and refund. The panel shows configuration status and the last purchase with an HTTP 2xx response; verify financial events in the log and GA4 reports.
- PrestaShop 1.7.x, 8.x and 9.x: this is the range declared by version 1.4.2, not a guarantee for every PHP version, theme or checkout. The code includes paths for the standard checkout and selected one-page checkout modules; verify your store's actual order flow.
Which sales stages does the GA4 module for PrestaShop measure?
| Store stage |
Events sent by the module |
Data scope |
| Lists and product page |
view_item_list, select_item, view_item |
Product, variant, brand, categories, price, discount, and list position. |
| Cart |
add_to_cart, remove_from_cart, view_cart |
Cart items, quantities, values, currency, and available coupon. |
| Checkout |
begin_checkout, add_shipping_info, add_payment_info |
Cart contents and information selected during the order process. |
| Purchase and refund |
purchase, refund |
Server-side snapshot of a qualifying transaction or refund sent via Measurement Protocol. |
| Search and account |
search, view_search_results, sign_up, login |
Search term, search results, or the account creation and login event. |
Purchase and refund tracking via Measurement Protocol
In the current financial mode, the module does not treat a button click or the confirmation page itself as proof of payment. The purchase event is created after one of the selected payment statuses is saved in the order history. For a refund, the module first checks whether there is a previous purchase for that order recorded as sent in the log; it then settles only the remaining, non-refunded value. A full refund can be triggered by the selected status, and new PrestaShop credit slips are handled independently, including partial ones.
The sent status in the log means an HTTP 2xx response, i.e. the request was accepted by the Measurement Protocol endpoint. This is not confirmation that the event has already been processed or displayed in Google Analytics reports. The module does not recreate historical purchases or refunds after an update and has no automatic queue, CRON, or button to force a retry of an uncertain send.
GA4, Google Ads, consents, and user data
The module can initialize the GA4 tag for one or two Measurement IDs. For Google Ads dynamic remarketing, it additionally requires an identifier in the AW-… format. In the current purchase-by-payment-status mode, the purchase and refund events are sent to GA4 via Measurement Protocol; in this mode, the module does not send a direct browser-based purchase conversion to Google Ads.
The user-provided data option requires active PD Cookie Pro with Consent Mode v2 and current ad_user_data consent. In addition, the store owner must enable the collection of such data in the GA4 property and in the Google tag settings; configuring enhanced conversions in Google Ads is a separate task on the Google account side. Withdrawing consent removes identifying data from the tag configuration, and the server-side sending of financial operations checks the current consent again before sending. User ID and user-provided data also rely on active PD Cookie Pro in live mode, Consent Mode v2 and the current consent revision. Withdrawing analytics_storage clears User ID in the tag; withdrawing ad_user_data clears user_data. This does not delete data already sent to Google.
Configuration and implementation verification
- Enter the primary GA4 Measurement ID, and the second ID only if it is needed.
- For purchases and refunds, provide the Measurement Protocol API Secret and select the statuses that actually confirm payment and a full order refund in the given store.
- Match the
item_id format to the identifier used in the catalog or product feed.
- Enable only the required Google Ads, User ID, and user-provided data features, after checking the settings and consents in Google tools.
- For testing, use debug mode and GA4 DebugView, and for financial operations check the module log. The test should be performed on the actual purchase path and the correct order status.
Module scope and important limitations
- The module sends data to the configured Google services; it does not create or administer a GA4, Google Ads, Merchant Center account, or advertising campaigns.
- It does not replace consent configuration or the store’s legal analysis. The store owner is responsible for the legal basis for data processing, the content of consents, and Google account settings.
- Script blocking, lack of consent, missing saved attribution, incorrect identifiers, or Google settings may limit measurement. The module does not guarantee data completeness.
- Sending data with the API Secret requires correct GA4 configuration. An HTTP 2xx response should be treated as confirmation of request receipt, not as proof of transaction visibility in reports.
