These cookies are essential for the website to function properly. They enable core functionality such as security, shopping cart, and account access. You cannot disable these cookies.
These cookies enable enhanced functionality and personalization, such as remembering your language preference or region. If you do not allow these cookies, some features may not work properly.
These cookies help us understand how visitors interact with the website by collecting and reporting information anonymously. This helps us improve our website.
These cookies are used to deliver advertisements that are relevant to you based on your interests. They also help measure the effectiveness of advertising campaigns.
Hotjar connects your PrestaShop storefront to behavioural analysis and labels visits with the shopping actions that matter. Installation, your numeric Hotjar Site ID and one activation switch are enough to start.
The Hotjar service provides heatmaps, session recordings and on-page surveys. Its free account needs no credit card; paid plans increase captured traffic and add action-based filters and survey triggers.
You choose the pages measured, enable nine shopping actions separately and exclude staff visits. Custom rules label steps such as opening a size guide. MPR Cookies Revolution and MPR Cookie Banner pass marketing consent to the connection: approval starts measurement on the open page, and withdrawal stops new data being sent.
Shopping labels focus your review on visits that reached the buying step you need to understand.
Hotjar connects a PrestaShop store to the Hotjar service and turns ordinary shop activity into useful labels for behavioral analysis. Six features connect shopper insights with consent, measurement controls and readiness checks.
Sales reports count the abandoned carts and completed orders. Hotjar shows the experience behind those totals: where shoppers click, how far they scroll, which parts attract attention and what happened on screen before a visit ended. Recordings reproduce the journey, heatmaps combine behavior across visits, and surveys collect the shopper's own explanation.
A free Hotjar account is available without a credit card and includes heatmaps, recordings and surveys. Paid plans increase captured traffic and add filters and survey triggers based on named actions. The service holds and presents this material in its own panel; the module supplies the reliable PrestaShop connection and the shopping context that makes the material useful.
Nine controls cover page view, product view, category view, successful cart addition, successful wishlist addition, checkout start, search, purchase and registration. Each action is switched on independently; with a paid plan that supports action-based filters, the Hotjar panel narrows visits to sessions connected with the question under investigation.
A cart label follows the completed store action rather than the button press, and the purchase label comes from the confirmed order and appears once for that order. A checkout problem is therefore examined among sessions that truly reached checkout, while a product question is examined among people who viewed that product or saved it for later.
Marketing consent controls the connection. When the shopper grants it, Hotjar starts on the open page; when the choice is withdrawn, the module stops sending new actions. The same decision therefore governs the behavioral tool immediately instead of waiting for another page to load.
Employee exclusion is a separate switch and covers storefront visits opened during administration, preview and everyday content work. Heatmaps and recordings then represent customers rather than the team reviewing a banner, price or checkout change.
A size guide opening, a finance tab, a quote request or a configurator step often explains hesitation better than a generic page view. You name that action and tie it to a selected button or element, an address containing chosen text, a page type or a signal already produced by the store. The module validates the target before saving and sends the readable name when the action occurs.
Tracker scope is controlled separately. Hotjar runs across the whole store, only through selected parts of the buying journey, or everywhere except the pages you exclude. This keeps recordings focused on product browsing and checkout without collecting areas that have no place in the analysis.
The first launch needs installation, one numeric Site ID from Hotjar and the activation switch. The module rejects an invalid identifier and remains silent until the connection is complete, so a typing error does not create the appearance of working measurement.
The same screen then opens the deeper controls: nine shopping actions, custom rules, consent behavior, staff exclusion and page scope. Its readiness table reports the effective storefront state and distinguishes an active connection from one that is disabled, incomplete, blocked by consent or excluded for an employee. A simple start therefore grows into precise control without a second installation.
Be the first to share your experience with this product.
Hotjar for PrestaShop adds Hotjar tracking and browser Events API events to your storefront, so you can study heatmaps, recordings, feedback, and key shopping actions from your Hotjar dashboard. It helps you see where shoppers click, scroll, hesitate, search, add products, start checkout, and complete orders.
Each event has its own toggle in the back office, so you send only what you need. The built-in events are page view, product view, category view, add to cart, add to wishlist, checkout start, search, purchase and customer registration.
Custom event rules are a separate setting and are turned off by default, so nothing extra fires until you add your own rules.
Yes. Beyond the built-in ecommerce events you can define custom event rules as JSON in the back office. A rule can fire on a click matching a CSS selector, when the URL contains a fragment, on a specific PrestaShop controller or module, or on a DOM event you dispatch.
The rules run from the module's front-office script, so you do not touch theme files. Custom events stay disabled until you enable them and add at least one rule.
Just the event name. Hotjar's Events API is browser-side and accepts an event name only, not event properties. So the module sends clean names such as product_view, add_to_cart and purchase to Hotjar with hj('event', '...').
Details like order value, currency and product IDs are still prepared by the module, but they are shown in the demo event monitor for transparency rather than sent to Hotjar. You use the event names to filter recordings, heatmaps, funnels and surveys around meaningful shopping moments.
Yes. When purchase tracking is enabled and the module is allowed to track the visitor, it fires a Hotjar purchase event from the PrestaShop order-confirmation hook. The front-office template calls hj('event', 'purchase') on the order confirmation page.
This is useful for Hotjar analysis because you can filter recordings, heatmaps, surveys or funnels around sessions that reached a purchase, then inspect the behavior before the order was placed. It helps answer questions such as where buyers hesitated, what checkout steps they replayed, or which page patterns appear in successful sessions.
It is not a replacement for revenue analytics or server-side order reporting. Hotjar receives the named event for behavioral segmentation; the module's order details are mainly used to build local event context and are not a full transaction feed.
The feature depends on the normal Hotjar module guards. The module must be enabled, the Hotjar Site ID must be configured as digits, purchase tracking must be enabled, and the visitor must pass the module's tracking checks such as consent handling when consent respect is enabled. If tracking is not allowed, the order-confirmation hook returns nothing.
When the hook runs, the module builds local purchase context from the PrestaShop order, including values such as order ID, currency, total value, item count and product identifiers. That context is assigned to the order-confirmation template and can be used by the module's local event recording/demo tooling, but the Hotjar Events API call made by the template is still the simple named event purchase.
In Hotjar, use the purchase event as a behavioral marker. For totals, tax, margin, attribution, refund handling or authoritative conversion reporting, keep using PrestaShop order data or an analytics platform designed for transaction reporting.
Modules our team genuinely pairs with this one, and exactly why each belongs in the same setup.
With Hotjar running, your store connects heatmaps and session recordings to real shopping context, so you can study how visitors behave on product pages, checkout steps, forms and calls to action before they buy or abandon. That behavioural footage is valuable for spotting friction, but recordings on their own cannot tell you how many shoppers a problem affects or how much revenue is at stake, and without that scale it is hard to know which observed issue to tackle first.
Google Analytics GA4 is a separate module that sends ecommerce activity to your GA4 property after validating the Measurement ID, covering product views, cart activity, checkout starts, purchases, searches, logins and account creation. It supplies the quantified funnels and drop-off figures that turn an anecdote from a recording into a measured problem you can size and rank against everything else happening on the store.
Used together, they let you spot a weak step in a Hotjar recording and then confirm its scale in GA4, or notice a drop in GA4 and go watch why it happens in Hotjar. The payoff is disciplined prioritisation: you fix issues in order of how many shoppers and how much revenue they actually affect, so your optimisation effort follows evidence you can both see and measure rather than gut feeling.
A store using Hotjar is investing in qualitative insight: heatmaps and session recordings tied to real shopping context, so friction on product pages, checkout and forms becomes visible rather than guessed at. Hotjar is deliberately focused on behaviour and does nothing to organise the growing collection of marketing and analytics tags a store accumulates, which tend to sprawl across the theme and become hard to keep firing consistently.
Google Tag Manager is a separate module that adds your GTM container to the store and feeds it ecommerce shopping events from real product views, cart changes, checkout starts, purchases, searches, logins and sign-ups. It gives your analytics and marketing scripts a single, event-aware delivery layer instead of scattered snippets, keeping the wider tag stack tidy and consistent as it grows.
Running both keeps behavioural research and tag orchestration in their own lanes: Hotjar reveals where shoppers struggle while GTM manages how your measurement tags are delivered. The payoff is that the improvements you learn from watching recordings land on top of a clean, well-organised tracking foundation, so you are refining a page whose events you can actually trust rather than debugging tag chaos and UX friction at the same time.
If you run Hotjar, you already care about conversion behaviour and want to see where consumer shoppers stall on their way to purchase. Recordings surface individual friction points vividly, but they leave the harder commercial question open: across the whole buying journey, which leak is costing you the most, and what should you fix first? Watching sessions can absorb a lot of time without ever producing a ranked, revenue-weighted plan.
B2C Conversion Audit is an expert service, not a module: a specialist walks your real buying journey on mobile and desktop, analyses the funnel from view to purchase, and pinpoints exactly where shoppers leave, across product-page clarity, checkout friction, trust and social proof, mobile layout and order-confirmation clarity. You receive a prioritised conversion report mapping each leak to its likely revenue impact with a concrete fix.
Commissioned alongside your Hotjar setup, the audit turns its own journey observations and optional GA4 evidence into a structured, prioritised verdict from an outside expert. The payoff is direction: your own session-watching gains a clear answer on what to change first and what to leave alone, so the effort you already put into understanding shopper behaviour converts into a focused list of fixes rather than an open-ended stream of interesting but unranked clips.
30 days return right
Plug & Play Modules
Dedicated Support First
Built and maintained by David Miller and mypresta.rocks. David Miller has worked with PrestaShop since 2013, and the company behind this shop has been registered since 3 December 2018. Every module in this catalogue is our own work, so your questions to support reach the people who wrote the code. The changelog on this page lists every update with its date.
