How to optimize a Webflow e-commerce site with Hotjar

Your Webflow store's analytics can tell you how many shoppers abandoned their carts, but not what happened on the page that made them leave. Hotjar closes that gap on a Webflow Ecommerce site, surfacing the friction behind the numbers so you can act on the reason and not just the metric.

Hotjar is a behavior analytics tool. It records how real people move through your pages, where they click, how far they scroll, and where they stall inside checkout.

You install it the same way you install any script on Webflow, through the site head, and then layer custom events on top so the data speaks in the language of your store: add to cart, begin checkout, purchase.

This guide walks the full path and calls out each trap as it comes up.

What do you need to add Hotjar to a Webflow e-commerce site?

You need to set up four things:

• A Webflow site on a paid plan that allows custom code
• A Hotjar account with a site and its tracking snippet
• A consent management setup to keep the integration GDPR compliant
• A clear idea of which Hotjar plan tier covers the features you want.

None of these are heavy, but skipping the consent piece or the plan check causes most of the problems I see later.

Before you touch any code, set these up.

7 steps to set up Hotjar on your Webflow e-commerce site

The setup moves from the base install outward to store-specific tracking. First, you install the snippet and gate it behind consent. Then you teach Hotjar your store's key actions with events and user attributes. Finally, you build a funnel, lock down PII, and verify the whole thing is firing.

Work through these in order. Each step ends with what you should see before moving on, so you never have to guess whether it worked.

1. Install the Hotjar tracking code in Webflow's site head

First, copy your exact tracking snippet from Hotjar. In your Hotjar dashboard, open the site you created, go to the tracking code screen, and copy the full block. In Webflow, open Site settings, click the Custom code tab, and paste the snippet into the Head code field, then save and publish.

The snippet looks like this, with your own site ID in place of the placeholder:

<!-- Hotjar Tracking Code -->
<script>
    (function(h,o,t,j,a,r){
        h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)};
        h._hjSettings={hjid:YOUR_SITE_ID,hjsv:6};
        a=o.getElementsByTagName('head')[0];
        r=o.createElement('script');r.async=1;
        r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv;
        a.appendChild(r);
    })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');
</script>

This snippet creates the global hj() queue, sets your site ID in _hjSettings, and appends Hotjar's async script to the page head so it loads without blocking your content. Because it sits in the site-wide head, it runs on every page, including product, cart, and checkout.

Always paste your own copy rather than this example, since the site ID must match your account. Expected outcome: after publishing, your live domain loads the Hotjar script on every page.

2. Gate Hotjar behind cookie consent

Do not let the raw snippet fire before a visitor consents. The safest pattern is to stop the Hotjar script from loading until your consent tool reports agreement, rather than loading it and hoping to opt people out afterward. Most consent platforms handle this by controlling script tags for you.

If you manage loading yourself, wrap the Hotjar call so it only runs after the consent event:

<script>
  window.addEventListener('CookiebotOnAccept', function () {
    if (Cookiebot.consent.statistics) {
      // Load Hotjar only after statistics consent is granted
      (function(h,o,t,j,a,r){
        h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)};
        h._hjSettings={hjid:YOUR_SITE_ID,hjsv:6};
        a=o.getElementsByTagName('head')[0];
        r=o.createElement('script');r.async=1;
        r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv;
        a.appendChild(r);
      })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');
    }
  });
</script>

The code listens for the consent platform's accept event, checks that the visitor allowed the statistics category, and only then injects the Hotjar loader. This keeps you compliant by default: no behavioral data is captured from anyone who declines.

Swap Cookiebot for whichever platform you use, since each fires its own consent event name. Expected outcome: Hotjar collects data only from shoppers who accept analytics cookies.

3. Track e-commerce events with the Events API

Teach Hotjar your store's real actions using the Events API. Webflow commerce interactions don't reload the page, so the cleanest approach is to assign a custom class to your Add to Cart button in the Webflow Designer, then bind a click listener in the site footer code.

Hotjar's event call is a single line:

<script>
  document.addEventListener('click', function (e) {
    if (e.target.closest('.add-to-cart')) {
      window.hj = window.hj || function(){ (hj.q = hj.q || []).push(arguments) };
      hj('event', 'add_to_cart');
    }
  });
</script>

The listener watches for clicks anywhere on the page, checks whether the click landed inside an element carrying your .add-to-cart class, and sends a named add_to_cart event to Hotjar when it does.

Event names can be up to 250 characters and can't include properties, so keep them descriptive and consistent, like begin_checkout and purchase. Fire the purchase event on your Webflow order confirmation page. Expected result: within a few minutes, these events appear in Hotjar and become filters for recordings and heatmaps.

4. Identify logged-in shoppers with user attributes

Attach what you know about a shopper so you can segment behavior later. If your store has customer accounts, the Identify API tags the current session with attributes like lifetime spend or customer status, which lets you watch how returning buyers behave differently from first-timers.

The call takes a user ID and an object of attributes:

<script>
  hj('identify', 'USER_ID_FROM_YOUR_DB', {
    is_customer: true,
    total_spend: 500,
    plan_tier: 'returning'
  });
</script>

Here, the first argument is a stable user ID from your database or the Webflow CMS API (or null if unknown), and the object holds the attributes. Hotjar accepts numbers, strings up to 200 characters, ISO-8601 dates, booleans, and a dedicated email key, with up to 100 distinct attribute names per site.

Each identify call overwrites the stored values for that user, so send the current state. This feature needs an Observe Business plan or higher. Expected outcome: recordings and heatmaps can now be filtered by shopper attributes such as returning versus new.

5. Build a checkout funnel in Hotjar

Turn your events and page views into a measurable funnel. Inside Hotjar, create a new funnel and add ordered steps that mirror your buying journey. A funnel step can be a viewed page, a clicked element, or a custom event, which is exactly why you set up events in step three.

A clean e-commerce funnel looks like this in plain terms:

• Step 1: product page viewed
• Step 2: add_to_cart event fired
• Step 3: checkout page viewed
• Step 4: order confirmation page viewed

Each step maps to something Hotjar can already detect on your published store, so the funnel assembles quickly. Hotjar allows up to ten steps, and every step must happen inside a single session for it to count as a conversion.

The payoff is a drop-off percentage between each stage, so you learn precisely where shoppers leave. Funnels require the Observe Scale plan. Expected result: a live funnel showing conversion and abandonment rates between each stage of your checkout.

6. Suppress PII on cart and checkout pages

Protect customer data before you review a single recording. Because the tracking code runs on checkout, you must stop Hotjar from capturing anything sensitive. Hotjar already suppresses all user keystrokes by default and automatically hides any number with nine or more digits, which covers card and phone numbers.

For everything else, add the data-hj-suppress attribute to elements that render personal data, such as saved addresses or order summaries.

You can add custom attributes to any element from the Webflow Designer's element settings panel:

<div data-hj-suppress>
  <p>Jane Doe</p>
  <p>221B Baker Street</p>
</div>

Applying data-hj-suppress to a parent suppresses everything inside it, including child text and images, so wrapping a whole address block is enough. Note that Hotjar cannot suppress inline SVGs, only linked image sources.

Expected outcome: recordings and heatmaps play back with personal fields masked, keeping the integration privacy safe.

7. Verify the integration end to end

Confirm every piece is firing before you trust the data. Start in Hotjar, where the dashboard reports whether the tracking code is detected on your domain. Then open your live store in a normal browser, accept cookies, and complete a full test purchase. Add a product, move through checkout, and reach the confirmation page.

Wait a few minutes, then check three things in Hotjar: your test session shows up under Recordings, your add_to_cart and purchase events appear as filters, and the funnel registers your run as a conversion.

If you use Google Tag Manager alongside Hotjar, confirm the tag fires on the same consent trigger. Expected result: a single test purchase visible across recordings, events, and the funnel, which confirms the whole pipeline works.

What causes Hotjar tracking problems on Webflow e-commerce sites?

Most failures trace to a handful of predictable causes: the site was never republished after adding the code, consent is silently blocking collection, events break Hotjar's naming or session limits, suppression masks too much, or your daily session cap throttles how much you see. Each one produces a distinct symptom.

The sections below pair the symptom you notice with its cause and the fix, in the order you are most likely to hit them.

No data appears in Hotjar at all

If Hotjar reports the tracking code as not found, the most common cause on Webflow is a site that was edited but never republished. Custom code only goes live on publish, so saving the Head field isn't enough. Republish to your production domain and confirm you pasted the snippet into the Head code field rather than the footer.

The second cause is a plan issue: site-wide custom code needs a paid Webflow Site plan, and if that section is missing, the head code was never applied. The third is a mismatched site ID in the snippet.

Verify the ID matches the site shown in your Hotjar dashboard, since a copied example ID will silently collect nothing for you.

Recordings are empty, or data is missing

When recordings exist but look blank, or collection is far lower than your traffic, consent is usually the reason. If the Hotjar script is correctly gated behind consent, every visitor who declines analytics cookies produces no data, which is working as intended but can look like a bug. Confirm your consent tool is actually granting the statistics category on accept.

Another common cause is over-suppression: applying data-hj-suppress to a high-level container, like the page body, masks far more than you meant to. Pull the attribute down to the specific elements that hold personal data.

Test by accepting cookies yourself and completing a session, then confirming it records with only the sensitive fields hidden.

Custom events never show up in filters

If your add_to_cart or purchase events do not appear, start with your Hotjar plan. The Events API requires an Observe Plus plan or higher, and on the free Basic tier, your event calls simply do nothing.

Next, check the event name against Hotjar's rules: names can be up to 250 characters, use letters, numbers, and a limited set of symbols, and can't include properties.

A third cause is Hotjar's session limits, where only the first 50 unique events in a single session are searchable by filters, so a page firing dozens of events can bury the ones you care about. Keep your event set small and intentional.

Finally, confirm the click listener actually matches the class you assigned in the Designer.

Sampling hides sessions you expected to see

If sessions seem to vanish on a busy store, you are likely hitting your plan's daily session limit. Hotjar's free Basic tier caps collection at roughly 35 sessions per day, and paid tiers raise that ceiling in steps. Once you reach the cap, Hotjar stops recording new sessions until the next day, so a traffic spike or a sale can mean your most important sessions go uncaptured.

There is no fix beyond understanding it: either upgrade the tier to raise the cap, or use targeting to record only the pages that matter, like cart and checkout, so your limited quota is spent where it counts.

On a growing store, planning for this sampling limit is part of choosing a plan.

Turn behavior data into revenue on your Webflow store

Every abandoned cart on your store is a shopper who wanted to buy and hit something in the way. The point of putting Hotjar on Webflow is to make that invisible friction visible so that you can fix the one dropdown, the one shipping surprise, or the one confusing button that quietly costs you orders.

Once you can see where shoppers struggle, the natural next move is to smooth the path. If your funnel shows drop-off at the payment step, tightening your Stripe checkout flow is often the highest-impact fix.

If shoppers convert but never return, the post-purchase experience is where you win them back, starting with reliable order confirmation emails and a way to automate e-commerce orders into your back office so nothing slips.

For the analytics layer itself, the official Webflow and Hotjar integration page is the reference for connection options. If you want to model behavioral data alongside your store data, you can pull it into your own real-time dashboard.

Start by installing the snippet, watch ten real checkout sessions this week, and let what you see decide your next fix.