Skip to content
BestCoding
pl

E-commerce analytics & conversion measurement in PrestaShop

First we check whether GA4, GTM and your PrestaShop data capture purchases and the key funnel stages according to an agreed measurement plan. We fix confirmed errors, document the setup and show the limits of the data. We don't promise a conversion uplift before analysis — reliable measurement helps identify problems and formulate hypotheses for later verification.

Request an analytics review
PrestaShop Expert

The problem

A gap between GA4 and PrestaShop orders rarely has a single cause. Depending on the store, it may stem from the timing of the purchase event, the return from a payment gateway, duplicated transactions, a wrong transaction_id, consent configuration, blocked scripts, or simply GA4 and the shop counting sales by different definitions. This isn't solved by adding another module or rolling out server-side tracking blindly — first we separate the data-completeness problem from the attribution problem and from plain reporting differences. We usually look at several layers at once:

  • The purchase event doesn't fire for some payment methods or after returning from an external gateway
  • The same order reaches GA4 more than once — duplicated transactions inflate the numbers
  • A purchase is measured before payment is confirmed, or skipped after the order status changes
  • The payment provider shows up in GA4 as a referral and takes over the original traffic attribution
  • Product identifiers differ between the store, the feed, GA4 and Google Ads
  • The consent mechanism fires tags in the wrong order or with an incorrect default state
  • GA4 and the shop compare different order statuses, time zones, currencies or revenue definitions
  • Refunds and cancellations aren't reflected in the data, so the reported result is overstated

When you should consider this

  • GA4 misses or duplicates some orders compared with the PrestaShop admin
  • Different payment methods produce different results when measuring purchases
  • Google Ads, GA4 and PrestaShop show three different numbers for the same sales
  • Data quality dropped noticeably after changing a module, the checkout or the consent banner
  • It's unclear which checkout stages are actually being measured
  • The GTM container has no documentation and no safe publishing process
  • You want server-side tracking, but first want to check whether scale and the problem justify it
  • Marketing needs margin or profitability data that standard GA4 doesn't calculate out of the box
  • You need a stable baseline before running CRO tests

Scope of work

Plan and audit

  • Measurement plan — definitions of macro- and micro-conversions, events, parameters, data sources and counting rules, matched to the store's purchase funnel
  • GA4, GTM and dataLayer audit — properties, streams, tags, triggers, variables, identifiers, environments and container versioning

Purchase path and the purchase event

  • PrestaShop purchase path — product lists, product page, cart, checkout, shipping and payment methods, purchase and returns
  • Purchase event and order lifecycle — where and when it fires, payment status, confirmation-page refreshes, deduplication and differences between payment modules

Consent, reconciliation and advanced solutions

  • Consent and advertising products — technical integration with the CMP, Consent Mode v2, Google Ads and Enhanced Conversions per the client's approved rules
  • Reconciliation with store data — comparing purchase events with orders for an agreed period, statuses, currencies, time zone, cancellations and refunds
  • Advanced solutions, only where justified — Measurement Protocol, server-side GTM, BigQuery export, Looker Studio dashboards, margin data and data-quality monitoring

What you get

Diagnosis and data

  • A measurement plan matched to your store's purchase funnel
  • A report of confirmed problems, their impact and priority — backed by evidence from tests
  • A comparison of GA4 purchase events against an agreed set of PrestaShop orders

Implementation and verification

  • Implemented and versioned changes in GTM, code or the tracking module, when implementation is part of the engagement
  • A matrix of tested payment methods, devices and consent variants
  • Before/after verification results

Documentation and next steps

  • Documentation of events, dataLayer parameters and dependencies
  • A list of known limitations, risks and recommended next steps

What the report gives you for each issue

What we check

  • The tested scenario and expected behavior
  • The actual state and evidence from testing (GTM Preview, DebugView, network requests, logs)
  • Impact on data completeness, attribution or business decisions

What we establish

  • The confirmed cause, or a note on what hasn't been confirmed yet
  • Recommended solution
  • Priority, dependencies and implementation estimate

What happens next

  • How it's verified after implementation
  • The test result, or the reason for leaving a limitation in place

How the process works

  1. 1

    Definitions and scenarios

    We agree what counts as a purchase, which order statuses we compare and which customer paths matter most for the business, then pick representative scenarios to test.

  2. 2

    Baseline measurement

    We test devices, payment methods, consent states and a sample of orders, and record the current discrepancies between GA4 and actual orders.

  3. 3

    Diagnosis

    We separate event loss, duplication, attribution problems, reporting differences and consent-related limits — pointing to confirmed causes, not guesses.

  4. 4

    Change plan

    You get recommendations with priority, implementation effort, risk, dependencies and the expected, measurable effect on data quality. Together we decide what to implement.

  5. 5

    Implementation and testing

    We implement on a staging environment where possible and verify in GTM Preview, DebugView, network requests, logs and order records.

  6. 6

    Post-launch verification

    We compare results against the baseline over an agreed period and document the remaining differences and what's worth monitoring further.

Why this works

Most measurement problems in PrestaShop sit at the seam between layers — the payment module, the store code, the dataLayer, GTM and the server. We work across that whole range: PrestaShop and PHP, the database, Linux and DevOps, plus GA4, GTM and integrations. That means we don't bounce you between a "developer" and an "ads specialist" — one accountable person follows the thread from the browser, through when the event is sent, all the way to the order status and events sent from the backend. Our aim is data you can trust, not impressive-looking numbers in a proposal.

Conditions for a reliable result

Before we start, we agree on the reference data: order statuses, reporting period, time zone, currencies, refunds and test orders. A full audit may require access to GA4, GTM, the CMP, store code, module configuration and order data. We don't guarantee a perfect match between GA4 and the store database, or a conversion uplift from tracking alone — some data stays unavailable because of user decisions, technical blocking or platform limits, and modeled data is an estimate, not a recovery of observed events. We implement server-side tracking only when its benefit justifies the extra infrastructure and maintenance. We configure how consent signals are passed technically, per the approved CMP setup; we don't decide the legal basis, banner wording or retention rules for the client, and the technical implementation itself is not a legal-compliance assessment.

Related services

PrestaShop performance optimization

A slow checkout and poor Core Web Vitals can lower conversion. Store performance optimization with measured before/after results.

PrestaShop stores

Deployments, modifications, custom modules and integrations. Comprehensive PrestaShop store support.

AI & automation

Business process automation with AI. Intelligent workflows, integrations and time savings.

DevOps & servers

Infrastructure, monitoring, backups and CI/CD. A stable technical foundation for analytics and your store.

Frequently Asked Questions

Does this service increase conversion, or measure it?

We focus on reliable measurement and audit. Trustworthy data lets us flag stages with unusual drop-off and form hypotheses, but analytics on its own doesn't tell you why customers leave, nor does it raise conversion automatically. Conversion optimization — A/B tests, UX changes, checkout work — is a separate stage we propose only once measurement is reliable and traffic is enough to draw conclusions from.

Why doesn't GA4 data match my store sales?

It helps to separate two problems. Completeness: a missing or duplicated purchase event, a customer who doesn't return to the confirmation page after payment, blocked scripts, or misconfigured consent. Attribution and reporting: the payment provider appearing as a referral, or different order statuses, time zones, currencies or revenue definitions on each side. In the audit we compare purchase events with orders for an agreed period and show where and how much data is lost — and what is merely a difference in definitions.

What does a typical problem with incomplete purchase tracking look like?

A common pattern: purchase measurement depends solely on the confirmation page, so some customers returning from an external payment gateway aren't counted, and the gateway itself shows up in GA4 as a referral. The fix is often sending purchase after payment validation with the correct identifiers, excluding the provider from referral traffic, and deduplicating transactions. This is an illustrative example of a typical mix of causes — the exact scope is always confirmed by measuring the specific store, because the right event moment depends on the payment module.

What is Consent Mode v2 and is it required on PrestaShop?

Consent Mode v2 is not a feature or requirement of PrestaShop itself. It's a mechanism for passing the user's decision to Google's tags — including analytics_storage, ad_storage and the v2 additions ad_user_data and ad_personalization. Google requires appropriate consent signals for certain products and advertising uses; the details depend on region, the features used and the CMP configuration. We implement the technical integration with an approved consent mechanism, and where Google's thresholds are met data can be modeled — but modeling is an estimate, not a recovery of observed events, and it doesn't replace the client's legal assessment.

What is server-side tracking and when is it worth it?

Server-side tracking processes events through your own endpoint (a server-side GTM container) instead of only in the browser. It can reduce some of the loss from browser blocking and gives more control over the scope of data reaching Google, but it usually still runs alongside a client-side layer, is still subject to consent, and requires domain configuration, hosting, monitoring and maintenance. It's not an automatic fix for a GA4-vs-orders gap. It makes sense when it solves a concrete problem with data control, quality, performance or backend integration, and the expected benefit justifies the infrastructure cost.

Server-side GTM or Measurement Protocol — what's the difference?

They're two different things. Server-side GTM is an architecture with a server container that browser and backend events pass through. The Measurement Protocol is a way of sending events to GA4 directly from the server over HTTP — useful, for example, for events driven by the order lifecycle (payment confirmation, refund). The Measurement Protocol augments client-side measurement rather than replacing it: to tie an event to the earlier session and traffic source, the implementation must pass identifiers consistent with the GA4 tag in the browser. The choice depends on the problem, not on hype.

How do Enhanced Conversions work and why implement them?

Enhanced Conversions send hashed data to Google — e.g. the email address the customer provides at checkout — to more accurately attribute some conversions to ad clicks when matching is lost in the browser. They run on data passed after the user consents and Google's terms are accepted; hashing is not anonymization or permission to use the data. The feature can improve signal quality and the matching of some conversions, but it doesn't guarantee higher ROAS in every account — the effect depends on volume and implementation quality, so we check it in Google Ads diagnostics rather than promising it upfront.

How long does analytics implementation take?

We confirm the scope after checking the checkout, payment methods, the current state of GTM and the consent configuration. A simple audit of a standard store usually fits within a few business days; a full eCommerce tracking implementation depends on the number of custom events and payment modules. Server-side tracking is quoted separately, because it requires infrastructure, domain configuration, testing and ongoing maintenance. We don't give fixed timelines before inspecting the store.

What do you need from me to start?

The store URL and PrestaShop version, a short description of the problem (GA4-vs-orders gap, missing transactions, different numbers in Google Ads), the current GA4/GTM setup and CMP in use, a list of payment methods, and an example discrepancy with a date range. With that we can give an initial assessment and plan the baseline measurement.

Let's check whether your store's data can be trusted

Tell us about your store and what concerns you: missing transactions in GA4, different numbers in Google Ads and GA4, a drop in data quality after a module change, or measurement before planned tests. Include the store URL, PrestaShop version, current GA4/GTM setup, the CMP and payment methods you use, and an example discrepancy with a date range — we'll propose a first step from there.

Request an analytics review Get in touch: contact@bestcoding.net