PrestaShop analytics, tracking and session replay

What we would do

We would inventory the measurement you already have before installing another tracker. The right route depends on your shop's modules, theme, checkout, payment and ERP integrations, catalogue identifiers, order data, markets and the people who will maintain it. Keep a working integration when it meets the decisions you need to make. First establish whether a missing report reflects missing events, a different purchase definition or a collection fault.

For a change of sender, consent setup or analytics platform, work on a staging copy with the live theme and relevant integrations. Protect copied customer data, isolate live payments, emails and external order exports, and send test events to test destinations. Rehearse the affected journeys, save the previous module settings and container version, then plan the production switch with a named owner and a way to restore the previous configuration. Restoring code cannot remove incorrect events already sent, so keep production destinations out of the rehearsal.

Choose the route from the problem

If you need the discrepancy diagnosed, the PrestaShop Product Feed & Tracking Audit checks feeds and conversion measurement against the live shop and ranks the findings; corrections and ongoing campaign management are separate.

Choose, set up or debug

• Choose: use the table above, then compare the analytics platforms or the behaviour investigation.
• Set up: start with the property and sender, agree event coverage and connect consent.
• Debug: separate loading, dispatch and receipt, then match the order records.

Choose the decisions and metrics

Start with the decisions you need to make: which campaigns bring profitable customers, which products need attention, where checkout loses visitors and whether customers return. More tags and dashboards do not automatically improve those decisions.

Your back office supplies orders, carts, customer history and financial records. Analytics adds acquisition and behavioural measurement. Optional native statistics modules can also collect visitor information with JavaScript, so native Stats is not universally a script-free transactional report.

Use the same denominator, time window and eligibility rules when comparing rates. For these arithmetic examples, assume each converting visitor places one order. Ten thousand visitors at a three-percent purchase rate then produce 300 orders; fifty thousand at half a percent produce 250. Revenue also depends on average order value.

At equal measured populations, a one-percent purchase rate with EUR 200 orders produces EUR 2 per person; three percent with EUR 20 orders produces EUR 0.60. A higher conversion rate alone does not imply more revenue.

For example, 10,000 visitors at two-percent conversion and EUR 80 per order produce EUR 16,000. Increasing traffic by fifty percent to 15,000 visitors, at the same conversion rate and EUR 53.33 per order, produces EUR 15,999. If acquiring a new customer costs EUR 25 and first-order contribution before acquisition is EUR 20, the first order loses EUR 5 after acquisition.

Page views, bounce rate, duration, followers and real-time visitor counts can help diagnose a question. They are weak success measures alone. A long session can reflect difficulty as well as engagement.

Create a GA4 property and choose the sender

Record the current setup before changing it

• List the shop and checkout versions, active tracking modules, theme snippets and containers. Include tags loaded by a marketing or catalogue connector.
• Record the account, property, stream, container and pixel identifiers, with the shop and domain each belongs to. Give the business appropriate access rather than leaving ownership solely with an agency login.
• For each destination, write down who supplies the product/order data and who sends it. Include server credentials and scheduled delivery ownership without putting secrets in the inventory.
• Identify the order states that qualify, the refund route, languages and currencies, and whether multistore shares product or order references.
• Keep a sample of current reports and matched orders, plus the release and consent settings, so the post-change comparison has a baseline.

Create or select the destination

1. Create or select the property for the production business.
2. Choose a reporting time zone and reporting currency deliberately.
3. Create the appropriate web stream and copy its Measurement ID.
4. Choose direct Google-tag delivery or a GTM-managed GA4 route.
5. Keep staging and test traffic separate and define a validation plan.

A single web stream is a practical starting point for one storefront, rather than an absolute limit for every multistore or multi-domain design. Use a separate test property when you need isolated test data.

You can use the official PrestaShop Google Analytics module, a dedicated integration or GTM with an ecommerce data layer. Check the installed version's event coverage and compatibility.

A Google tag can send page views when configured. A GTM container by itself does not send GA4 page views or create ecommerce events. Product, cart and purchase measurement needs explicit instrumentation.

For a direct module route, Google Analytics GA4 connects store events to the property; use the GA4 module help for its setup, event controls, consent integration and diagnostics.

Universal Analytics standard properties stopped processing in July 2023; Analytics 360 had an extension until July 2024. Access and export shut down beginning July 2024. Only previously retained exports remain available. Settings migration tools existed, but historical UA sessions cannot become an equivalent GA4 event history.

Define and verify the ecommerce event coverage

Record the action, event name, parameters and owning integration for every event you need. Confirm the action actually succeeded before reporting a cart addition. A button click alone can be followed by an out-of-stock or validation error.

This is not a promise that every recommended event is automatic. Other modules and custom integrations can have a different matrix. Test shipping and payment events separately, especially with an external payment redirect or replacement checkout.

Keep product identifiers stable across views, cart events, purchases and catalogue feeds. Include relevant names, categories, brand, quantity and selected variant when available. The same item ID should not silently change from a product ID to a reference halfway through the journey. Write down whether an ID identifies the product or the combination, and how that maps to the feed. For a size and colour selection, compare the viewed variant, successful cart response and purchased line; a populated field can still describe the previous selection.

Build a correct purchase payload

For GA4 ecommerce, set value to the sum of discounted item unit prices multiplied by quantity, excluding tax and shipping. Send tax and shipping separately, with the actual transaction currency.

For example, two items at EUR 20 and one at EUR 10 yield an item value of EUR 50. If tax is EUR 10 and shipping EUR 5, the comparable order total is EUR 65, assuming no other charges. Do not send 65 as item revenue.

{
  "event": "purchase",
  "ecommerce": {
    "transaction_id": "shop-1-order-10482",
    "currency": "EUR",
    "value": 50,
    "tax": 10,
    "shipping": 5,
    "items": [
      {"item_id": "4521-3", "item_name": "Cotton T-shirt", "item_variant": "Blue / M", "price": 20, "quantity": 2},
      {"item_id": "4630-1", "item_name": "Cotton Socks", "item_variant": "Black", "price": 10, "quantity": 1}
    ]
  }
}

This is an illustrative payload. Build production values from the qualifying order and its line items, including the allocation of order discounts and rounding. Clear an old GTM ecommerce object before pushing the new event so earlier item data cannot carry over.

In PrestaShop, displayOrderConfirmation receives the Order object. The native confirmation template receives a presented order instead; its reference is under order.details.reference. Do not paste code that assumes raw Order fields and an unrelated products array exist in that template.

Build a dedicated payload in PHP and serialize the whole structure as JSON. For safe embedding, use the appropriate JSON encoding flags, such as JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT, and handle encoding failure. Escape neither individual strings as JavaScript nor the entire finished JSON as ordinary HTML text.

A different reporting currency is supported. Label every transaction with its real currency and let Analytics perform the supported conversion. Changing the property's reporting currency can also convert historical reporting; it does not repair events that were originally labelled with the wrong currency. See the currency reference.

Define purchase timing and deduplicate delivery

Decide whether Purchase means order placed, payment accepted or another qualifying commercial state. Document that definition across analytics and advertising destinations. An order-confirmation page can exist for an offline or pending payment, so reaching it is not proof that payment was received.

Use one stable, non-empty transaction ID per actual transaction, without customer-identifying information. Scope it so separate shops or orders cannot collide. GA4 deduplicates web purchases sharing the appropriate transaction ID. Reloading a page does not necessarily create a second counted purchase, but missing, reused or changing IDs can still corrupt reports.

Give one integration responsibility for each event and destination; that integration may coordinate browser and server delivery with matching identifiers and the destination's deduplication. A module supplying only the data layer can coexist with GTM. Direct GA4 can coexist with a GTM container used for other vendors. Audit duplicate senders rather than disabling the data producer that GTM needs.

A browser storage guard is not a delivery receipt. Storage may be blocked, and writing sent before a tag is ready can suppress an event that never reached the destination. Coordinate consent, readiness, retries and acknowledgement, and retain a stable event identity on retry.

A server fallback must capture qualifying order or payment changes independently of the confirmation-page visit. A server request made only inside that rendering hook cannot recover a customer who never returned. Use supported order/payment hooks, a durable queue and delivery tracking rather than modifying core payment logic.

Use GTM as a tag manager and data dispatcher

GTM centralises tags, triggers, variables, preview and published versions. It does not generate PrestaShop product data or remove the vendor libraries those tags load.

1. Create a web container and install its official snippets through a maintained integration or a controlled theme customisation.
2. Verify the container on all relevant page types, including confirmation.
3. Configure the Google tag for the destination Measurement ID.
4. Create GA4 event tags and Custom Event triggers for the data-layer events.
5. Map the ecommerce parameters or use the supported ecommerce-data option.
6. Configure consent behaviour, preview the complete journey and publish a named version.

A manual installation places the head snippet and the body fallback in the appropriate layout locations. Preserve theme customisations through updates and clear relevant HTML caches after changing the container. Remotely managed tags survive independently, but a storefront snippet can still be removed by a theme change.

Prefer structured server-generated product and order data to scraping formatted prices or IDs from page text. DOM scraping depends on theme markup and can silently read the wrong variant or tax display.

Use GTM Preview and Tag Assistant to inspect the event, variables and fired tags before publishing. Keep a known-good container version for rollback. A preview can still send real hits, so use the test destination and traffic controls you planned.

Google Tag Manager provides the PrestaShop connection for this route; follow the GTM module help for container installation, data-layer integration and its server-purchase options.

Agree a data-layer contract with the maintainer: exact event names, parameter types, item-ID policy, value definition and the point at which each action is considered successful. Keep a sample payload alongside the container version that reads it. Renaming an event in the shop while leaving the old GTM trigger published can stop delivery without a visible storefront error.

Implement consent before relying on collection

Connect each tracker to your actual consent manager. For non-essential device tracking, apply the relevant ePrivacy rules and assess subsequent personal-data processing under GDPR where applicable. Explain purposes and recipients, support refusal and withdrawal, and use meaningful purpose granularity. One separate toggle per vendor is not a universal banner-layout rule.

Google Consent Mode communicates choices; it does not obtain consent or certify a deployment as lawful. In applicable advertising setups, map analytics_storage, ad_storage, ad_user_data and ad_personalization to the choices actually made.

Basic Consent Mode blocks Google tags until consent and sends no denied-state measurements. Advanced mode loads Google tags with the relevant denied defaults and can send measurements without cookies. Modelling depends on eligibility and available data; it does not reconstruct a complete record of every refused visit.

For direct Google-tag code, set defaults before commands that send measurement. For GTM consent templates, use its consent APIs and initialization ordering. Do not substitute an invented browser event for your CMP's supported interface. See Google's implementation guidance.

Tags without built-in consent handling need explicit additional checks. Google settings do not automatically gate Meta, TikTok or a replay tool.

1. Test a new visitor before any choice.
2. Test saved refusal and saved acceptance on a later visit.
3. Change individual choices and verify the corresponding storage and requests.
4. Withdraw consent and confirm future collection and queued delivery stop as required.
5. Test a slow CMP and a tag library that loads late.

Do not recover a refused marketing event through a server API. Hashing customer data does not make the event anonymous or remove the need for an appropriate legal basis.

If Cookies Revolution supplies the choices, review its cookie inventory and blocking rules against the integrations actually installed. Record the purpose and CMP signal each connector consumes, including replay tools; do not assume a category labelled analytics controls every one of them. Use the GDPR guide to plan the related data-rights and retention workflow.

Use Meta Pixel for a defined measurement purpose

Meta Pixel can report PageView, ViewContent, AddToCart, InitiateCheckout and Purchase with the applicable product and transaction parameters. Product-content IDs should match the Meta catalogue when you use catalogue event matching.

Install it when you have a defined use, appropriate consent and a maintenance plan. It cannot retroactively collect an untracked visit. That does not mean an old installation guarantees cheaper ads, removes a cold-start penalty or creates an indefinitely growing usable audience.

Audience eligibility, source types, matching and retention windows affect what you can use. Do not treat a purchase-history threshold as a universal rule for every lookalike audience.

Initialize the pixel once within the permitted consent flow. If consent was already saved, handle that state; if granted later, respond to the real CMP change. Queue eligible events until the library is ready and use stable identities on retry. Do not place Purchase outside the consent path merely because the base loader is gated.

Verify browser events with Meta Pixel Helper and the receiving events in Events Manager. Event diagnostics are not a complete page-by-page website funnel report. Keep GA4 or another analytics system for the broader acquisition and funnel view.

For module delivery, use Facebook Pixel and check the Facebook Pixel help for setup and supported event controls.

Use Meta CAPI and other server delivery carefully

Conversions API sends eligible events from the server to Meta. TikTok, Pinterest and Snap also have server APIs. These can provide another delivery path when a permitted browser event is lost, but they do not guarantee complete measurement or attribution.

For a browser/server pair, use the same event name and matching stable identity according to that platform's deduplication rules. Meta uses browser eventID and server event_id. Keep transaction and destination identity consistent, and inspect duplicate status at the receiver.

Normalise and hash supported customer matching fields exactly as the vendor requires. Some transport fields, such as IP address and user agent, use different treatment. Send only justified fields and do not log access tokens or unnecessary personal data in diagnostics.

Marketing Revolution uses a shared server-purchase queue with checks for shop, destination ownership, enabled settings and its configured consent policy. Its platform task is scheduled every five minutes. Monitor actual task runs, queue results and receiving-platform diagnostics.

Use the Marketing Revolution help for its current queue, consent, credentials, test-event and diagnostic workflow.

Test late payment acceptance, refused consent, withdrawal, repeat callbacks, retry after failure and a customer who never visits confirmation. Keep order qualification and delivery state separate. A browser dispatch attempt does not confirm that the platform received an event.

Map TikTok, Pinterest and Snap events explicitly

Vendor names and parameter models differ. Do not forward one platform's event name unchanged to every other tracker.

TikTok renamed CompletePayment to Purchase in its May 2025 update. CompletePayment remains a supported legacy name; use the current name for new work. These TikTok names use PascalCase. See the event migration guidance.

Choose the platforms from your own audience and campaigns rather than fixed demographic or cheap-impression claims. A tracker installed just in case still adds processing, privacy and maintenance work.

A one-time check that the library exists can lose an event if it loads later. Coordinate library readiness and consent changes, with bounded retries and the same stable event ID. Each platform has its own deduplication rules and windows.

The matching integrations are TikTok Pixel, Pinterest Tag and Snapchat Pixel. Use the TikTok Pixel help, Pinterest Tag help or Snapchat Pixel help for the relevant integration.

One purchase can receive credit from several ad platforms, while other purchases receive none. Attribution windows, consent loss, matching and delivery can make the sum higher or lower than shop orders. Do not add platform-attributed conversions together as a unique-order count.

Verify loading, dispatch and receiver data separately

Use three checkpoints: the correct code loaded, the intended request was dispatched under the correct consent state, and the destination accepted the event with the expected parameters.

1. Open Tag Assistant or GTM Preview, and enable GA4 debug mode deliberately. Opening DevTools alone does not enable DebugView.
2. Browse a category, open a product, change its variant, add and remove a quantity, view the cart and enter checkout.
3. Confirm events after successful AJAX operations, not only page loads.
4. Complete a test transaction and inspect its ID, discounted item sum, tax, shipping, currency and items.
5. Reload confirmation and retry a callback. Check stable IDs and deduplication.
6. Check consent refusal, later grant and withdrawal in the browser Network panel.
7. Inspect receiving diagnostics, test events and relevant queue results.

Missing Realtime data does not prove that a tag failed to load. Consent, filters, blockers, wrong destinations and processing delays can produce the same symptom. Check the network and tag state before drawing a conclusion.

Test basic and advanced Consent Mode against their different expected behaviour. An advanced denied-state request is not the same as a forbidden cookie write; inspect both storage and requests.

Marketing Revolution's order Debug Inspector rebuilds a current payload from extractors and shows order logs and configuration context. It is not the exact historical platform JSON previously transmitted. Use the installed module's current diagnostics rather than relying on an old console prefix.

Turn off unnecessary production debugging after validation. Avoid exposing order data, identifiers or credentials to visitors or shared logs.

Use the first failed checkpoint to narrow the fault

A firing tag, an HTTP response and a counted report row establish different things. Keep evidence from the failed layer when asking for help, so a developer can reproduce the fault instead of replacing the whole integration on the basis of an empty report.

Read GA4 reports with the right scope

All five report groups below depend on the relevant ecommerce or purchase events. A landing-page purchase rate needs Purchase too, even if the landing page itself is measured by a page view.

GA4 has standard Purchase journey and Checkout journey reports. Explore adds custom steps and breakdowns. Report navigation depends on the collection published in your property. Before interpreting unexpected results, check the report's data-quality indicator for sampling or privacy thresholds, and whether high-cardinality values were grouped into an "(other)" row. These reporting effects are separate from events failing to arrive.

For a custom funnel, start with view_item, add_to_cart, begin_checkout and purchase. Decide whether it is open or closed, its step order and time limits. Add shipping and payment steps only when those events are reliably captured.

The native checkout in PrestaShop 1.7.8 and the earlier 9 flow uses personal information, addresses, delivery and payment, with conditional omissions. A single checkout URL is not a distinct URL per step. PrestaShop 9.2 also bundles a native one-page checkout option, so test the actual checkout implementation.

A large product-to-cart drop suggests checking product information, price, availability and measurement. A cart-to-checkout drop suggests checking delivery costs and access to checkout. A checkout-to-purchase drop suggests checking forms, carrier and payment behaviour. These are investigation paths, not proven causes.

Lower mobile revenue alone does not prove a broken checkout. Compare traffic intent, product mix, pricing, cross-device behaviour and tracking coverage, then reproduce the mobile journey.

Configure traffic filters, identity and integrations

Define internal traffic in the web stream's tag settings. In Admin, Data collection and modification, Data filters, test the internal-traffic filter before making it active. An active exclusion changes collected reporting data, so verify which events it will remove.

GA4 reporting identity uses User-ID, device ID and modelling according to the selected option. Google Signals is not the current reporting-identity mechanism. Review advertising enrichment, sharing and linked-product controls separately.

If you implement User-ID, use a stable pseudonymous identifier containing no names, email addresses or phone numbers, send it consistently for eligible signed-in users and clear it after logout. An identifier linked to a customer record is still personal data. It cannot join every anonymous visit across devices.

Use consistent campaign parameters for external marketing links. Do not use campaign tags on ordinary internal navigation. Check payment-provider referrals and cross-domain configuration where the real journey requires them.

Link Google Ads, Search Console, Merchant Center or BigQuery only for a defined purpose and with appropriate permissions. BigQuery export supports event analysis; it does not turn missing browser collection into complete order records.

Audiences can use product views, cart additions, purchase exclusions and repeat-purchase windows. Set windows that fit your sales cycle and platform eligibility. Defining an audience is separate from running an onsite recovery email sequence or an advertising campaign.

Compare GA4 with Matomo and plan a transition

GA4 provides hosted analytics and Google advertising links. Self-hosted Matomo gives you control over the analytics installation and database, with responsibility for updates, archiving, backups, retention and capacity. Matomo Cloud is another hosting choice with its own provider arrangements. Matomo also offers paid heatmap, session recording and form analytics extensions; assess their hosting, licensing, masking and consent requirements separately if keeping behavioural data on your own infrastructure matters.

Self-hosting does not mean only you can access data or that no international transfer exists. Review the host, administrators, remote access, backups, geolocation services, plugins and other recipients. With GA4, inspect account sharing settings and linked-product controls. Google states that with all sharing settings off, Analytics data is used to provide and maintain the service.

Matomo can disable tracking cookies and mask IP addresses. Call the documented disableCookies method before tracking, and configure IP anonymization on the server. Use an additional tracker only when intentionally sending data to another destination.

A consent exemption depends on the applicable national audience-measurement rules and the complete deployment. IP masking plus disabled cookies alone is insufficient. Check purpose limitation, cross-linking with customer data, recipients, retention and user rights, following the relevant regulator's guidance such as CNIL's audience-measurement conditions.

Unsampled reporting means the report is not calculated from a statistical subset of collected data. It does not mean all visits were collected or identified perfectly. Blocking, consent and cookieless identification affect coverage and visitor/session metrics.

Matomo uses its own ecommerce APIs, including product views, cart updates and order tracking. They are not GA4 event names. The PrestaShop integration supports product and category views, cart addition, checkout start and purchase, among other configured actions. Additional list-impression or shipping/payment tracking needs its own integration.

Matomo Analytics connects the store to your chosen Matomo installation; use the Matomo module help for its connection and event configuration.

Matomo provides a Google Analytics Importer, including supported GA4 report-import tooling. Imported reports do not recreate an identical raw-event history or guarantee metric equivalence. Check supported reports, access and dates in the importer documentation. Running both tools during a controlled transition can help establish a new baseline, provided you configure consent and avoid treating the two datasets as identical.

Decide what continuity means before switching

List the reports the team uses and the decisions they support, including any Google Ads dependency. Mark which can be rebuilt from new Matomo collection, which can use an importer and which must remain accessible in an existing export or account. Do not promise an unchanged year-on-year user count when visitor identification and session rules change.

1. Name the person responsible for the analytics host, archiving task, database growth, backups and a restore check, or choose the hosted arrangement you can maintain.
2. Map the existing product IDs, currencies, purchase qualification and refund treatment to Matomo's own ecommerce model.
3. During the agreed overlap, use the same qualifying store orders to check each destination separately. Keep their visitor and session denominators labelled.
4. Record the switch in the reporting change log and retain the comparison evidence before retiring the old sender.

Use Clarity for heatmaps, recordings and funnels

Microsoft Clarity provides heatmaps, session replay, frustration signals and funnels. It is free, but recordings are not unlimited: the documented ceiling is up to 100,000 sessions per project per day, and a replay is not available for every tracked session.

Replay reconstructs DOM content and interactions rather than recording a literal video. It cannot reproduce third-party iframe or canvas content. Hosted payment fields can therefore require the gateway's own diagnostics. See the Clarity FAQ.

Use click maps to find apparently interactive elements, scroll maps to check whether important content is reached, and filtered recordings to investigate a particular path. Rage clicks, dead clicks and quick backs are useful clues, not proof of one cause.

Clarity has its own funnels with conversion and drop-off measures and links to filtered recordings or heatmaps. It is not limited to an unstructured recording list.

Microsoft describes Clarity as a data controller in its Clarity FAQ. Review the Clarity terms and explain the actual recipient, purposes and consent choices in your privacy information.

Load the integration once and communicate analytics and ad-storage choices through consentv2 or a supported CMP integration. Propagate changes and withdrawal. Since 31 October 2025, Clarity enforces consent-signal requirements for EEA, UK and Swiss visits. Delaying the loader alone does not communicate those choices. Follow ConsentV2 guidance.

The Microsoft Clarity integration connects the store to your project; use the Microsoft Clarity module help for installation and consent integration.

Mask personal data and test the capture

Clarity's default Balanced mode masks recognized sensitive content such as numbers and emails. It does not hide all ordinary text, including every displayed name or address. Inputs and dropdowns are masked in all modes.

Use explicit region masking or an appropriate stricter mode for account information, address displays, confirmation details and other personal content. Clarity supports selector rules and the data-clarity-mask attribute. Correctly masked content is excluded before upload, rather than hidden only when someone watches it. See masking guidance.

Masking DOM content does not clean URLs, query strings, custom events, survey responses or arbitrary data sent by another tag. Keep personal information out of those channels too.

1. Use test customer details to walk account, address, checkout and confirmation pages.
2. Check both normal and replacement checkout markup.
3. Inspect a new recording after the masking configuration has taken effect.
4. Confirm consent refusal and withdrawal behaviour.
5. Restrict project access and check the provider's retention periods against your requirements.

Apply equivalent checks to any replay or feedback provider. Do not assume default input masking covers every custom component.

Use current Contentsquare and legacy Hotjar features

Hotjar has become part of Contentsquare. Check your account's migration and current plan rather than comparing a new subscription with an old Hotjar daily-session allowance.

As of October 2026, the Contentsquare Free plan advertises 200,000 monthly analytics sessions, including heatmaps, funnels and basic surveys. Replay capture is separately limited to five percent of sessions, with a maximum of 10,000 monthly. Paid plans add capacity or features. See the current plan comparison.

Funnels can calculate conversion for the captured population. Revenue or attribution features depend on the product and plan. Neither a funnel rate nor an attributed revenue feature replaces reconciliation with store and payment records.

Choose a survey when you need the customer's explanation rather than inferring it from interaction alone:

• Product: Is anything missing that would help you decide?
• Cart: What is stopping you from continuing?
• Checkout: Did anything here confuse you?
• Confirmation: What almost stopped you from completing the order?

Keep questions relevant, optional and unobtrusive. Avoid asking for sensitive data in free text. Test the survey trigger and whether its responses can be used alongside the corresponding captured journey.

Use an idempotent loader connected to the real CMP. Handle already-saved choices and withdrawal, and test masking and future collection after a choice changes. A fictional analytics-accepted event is not a complete integration.

The Hotjar module is a direct integration option when that matches your account; use the Hotjar integration help for the supported module and account workflow.

Turn behaviour into a testable store change

Start with a question from the numbers, then inspect relevant recordings and feedback. Do not watch random sessions until a persuasive anecdote appears.

Work through a mobile product-page problem

Suppose mobile product views remain steady but successful cart additions fall after a theme change. First reproduce a successful and a rejected variant selection and confirm their tracking, so a lost AJAX event is not mistaken for lost demand. Then filter recordings to the affected product and mobile layout, separating visits before and after the release.

If repeated recordings show customers opening tall size and colour controls without reaching the purchase button, use the scroll map to check that pattern across the captured visits. Reproduce the layout on a phone with the same combination and availability. The candidate change is to shorten or reposition the controls while keeping the selected variant, price, stock message and add-to-cart accessible together.

Rehearse the revised layout on staging with unavailable combinations, quantity changes and validation errors. After release, check fresh recordings for usability and masking, then compare successful cart additions and qualifying purchases under comparable traffic and measurement conditions. A button becoming easier to reach is useful evidence, but an extra click alone does not establish extra orders.

Use feedback to test the explanation

For a cart-to-checkout drop, recordings may show shoppers opening the coupon field and leaving; that sequence does not prove why they left. Combine it with an optional cart question about what is stopping them, and check whether delivery cost or availability explains the same pattern. If the evidence points to code hunting, test a clearly labelled collapsible coupon field, keep code entry available and measure abandonment and orders after the change.

If you need the journey assessed and the fixes ranked, the PrestaShop UX & Conversion Design Audit provides an evidenced repair plan; implementation and analytics setup are separate.

Inspect your own traffic for suspicious patterns and compare server logs where useful. Server-side crawler requests do not automatically execute analytics or replay scripts, so an abandoned database cart is not proof of a recorded bot session.

Measure the configured tag stack's network, CPU and memory costs. Asynchronous loading does not mean execution happens after content or that it cannot affect LCP, INP or CLS. Sending purchases server-side does not remove browser libraries still used for other events.

Reconcile analytics with orders, invoices and payments

Choose equivalent definitions before comparing totals. An order placed, a valid invoiced order, a paid order, a payment receipt and revenue after credit slips are different records.

Match dates and time zones, order states, currencies, tax, shipping, discounts, cancellations and refunds. Then compare transaction IDs for a representative sample. Track whether the gap changes after a release rather than expecting universal agreement to the cent.

Fewer analytics purchases can reflect consent refusal, blocking, a missed return page, filters or a fault. More can reflect duplicate or changing IDs, different date/state rules or attribution definitions. Neither direction alone identifies the cause.

Financial Revolution's profit reporting uses valid-order invoices less credit slips, with costs; its cash-flow report separately uses payment records. It does not supply customer cohorts, customer-level margin or channel-attributed profit by default. Use the Financial Revolution help for the implemented reports.

For channel economics, join acquisition cost and attribution analysis with the appropriate financial records using a deliberate reporting workflow. Do not describe an invoice summary as collected cash or a platform's attributed orders as the only orders it caused.

Work through a discrepancy using the purchase above

For this example, define Purchase as payment accepted and use the earlier EUR 50 item-value order, with EUR 10 tax and EUR 5 shipping. A shop total of EUR 65 and GA4 item value of EUR 50 are compatible. Match the same transaction and components before treating that difference as lost revenue.

Mark every unmatched transaction as explained, a delivery fault or unresolved. Keep refusal separate from a failed permitted delivery and leave unknown causes visible. Do not divide a report gap by the banner acceptance rate to manufacture an exact missing-sales total: the consented audience may buy differently from the audience you cannot observe.

For campaign decisions, distinguish an event received from an event credited to an advert. A correctly received purchase can receive different credit under different attribution settings; fixing the sender cannot make every platform's attributed revenue equal the shop's revenue.

Agree the switch and the handover

Before the production change, agree which old senders will stop, which data producers must remain and which container version reads the new events. Record the release time, destination identifiers and rollback owner. Check public cached pages as well as your logged-in test browser, because they may still serve the previous snippet.

What to ask your developer or agency

• Can you show the event-to-sender map for browser and server delivery, including tags added by existing marketing modules?
• Which shop, theme, checkout and module releases passed the tests, and which events still need custom integration?
• Can you show the order-line calculation, variant/feed ID mapping and received purchase payload for the same test order?
• What happens after a later consent grant, withdrawal, a lost browser return, delayed payment, repeated callback and refund?
• Where are queue failures and rejected events visible, who investigates them and how do retries retain their identity?
• Which configuration and container version would you restore, and what evidence shows the restored route works?
• Does the business retain access to the accounts, the change log and redacted acceptance evidence if the agency changes?

After switching, follow the first qualifying journeys through receipt and reconciliation, then compare the reporting gap with the saved baseline. If the acceptance checks fail, restore the agreed configuration and investigate before publishing another overlapping sender. Annotate any period with known missing or malformed data so the team does not interpret it as a commercial change.

Keep a review and maintenance routine

1. Compare eligible orders, refunds and financial totals over comparable periods.
2. Check purchase rate and value by source, device and landing page.
3. Review purchase and checkout progression, then products with views but few purchases. Under Orders > Shopping Carts (Customers > Shopping Carts on PrestaShop 1.6), inspect carts without an order, their contents and timestamps; a cart record alone does not show which checkout step was reached.
4. Inspect a focused sample of recordings or feedback for the largest question.
5. Check tag, consent and queue health after releases or checkout changes.
6. Record one decision, its intended effect and how you will evaluate it.

Do not use a universal threshold of thirty days or two hundred conversions. Choose sample size from baseline rate, the minimum effect worth detecting and the confidence and statistical power you need. Low-volume shops may need longer observation, while an obvious broken payment flow should be repaired immediately.

Use comparable weekdays, campaigns and seasonal conditions, or a properly assigned control group. Keep a change log so a new banner, pricing change or tracking release is visible when interpreting a shift.

Remove unused tags, review access and retention, and repeat the complete consent and purchase test after changes to themes, modules, URLs or payment flows.

Keep a short scorecard with the reporting period, metric definition, source, comparable segment, current result, previous comparable result, caveat and named next action. Attach the qualifying-order and refund reconciliation, note staff/test exclusions and flag suspected automation separately. Mark releases and consent changes beside the affected period, rather than resetting the baseline silently.

For example, a blended purchase rate can fall when a broad campaign brings more browsing traffic even while each established channel holds its own rate. Check channel and device mix before commissioning a checkout redesign. Conversely, a stable overall rate can hide a regression on the payment method or mobile layout that the release changed.

Questions owners ask

Do I need GTM if a direct analytics module already works?

Only if container management solves a requirement your current route does not. Compare access, event coverage and who maintains the tags. Adding GTM for another vendor does not require moving a working GA4 sender; document their separate ownership.

Why do I see visitors but no product revenue?

Page measurement can work while ecommerce instrumentation is missing. Follow a qualifying order from its product and purchase data through the published tag to the receiving property, using the checkpoints above. Check the report's date and filters after establishing delivery.

Should analytics match the back-office total exactly?

First match the purchase definition, period and value components. Use orders, invoices and payment records for their respective financial questions. Investigate a new or unexplained gap rather than accepting every shortfall as consent loss or every excess as duplication.

Will server tracking count everyone who refuses cookies?

Refusal is a collection constraint, not a failed delivery to recover. Server delivery can retry an eligible event lost on another route, under the agreed consent policy, but cannot promise a complete customer history.

Should I install Meta or replay now in case I need it later?

Define the advertising or usability question and the person who will act on the data first. Audience retention and tool coverage limit the future benefit, while collection, access and maintenance obligations begin with installation.

Can a recording tell me why a payment failed?

It can show the shopper's visible path and help you reproduce the problem. Inspect the payment connector and provider diagnostics for the payment outcome, especially where hosted fields or redirects are outside the replay.

Can I change analytics platforms without breaking comparisons?

Preserve the old reports, map the commercial definitions and establish a new baseline during a controlled overlap. Label changes in visitor identity and session rules; an importer does not make two measurement models identical.