How to Use Hotjar to Find Where a Signup Form Loses People

The short answer: with no Hotjar account yet, do this on Contentsquare's free plan, because Hotjar no longer opens new accounts and that plan replays 5% of sessions up to 10k a month at no cost (Contentsquare pricing, checked on 5 November 2026); with an existing Hotjar account, the job is: confirm the tracking code with the verify tab and debug mode, suppress the fields, fire one event when the form submits and one when it fails, filter recordings by those events, read the click and scroll maps for the form page, target a survey at the failures, and let Zapier write each answer into a Google Sheet that a person reads once a week.

Disclosure: I may earn a commission through some links on this site. It does not change what this page says.

A signup form is where the budget turns into a name, and the analytics usually stop one page short of it. For example: 1,200 pageviews of the form, 60 signups in the CRM, and nobody can say what the other 1,140 did. Recordings answer that, if they are filtered to the moment that matters rather than watched at random. Plans, prices and the merger are in the Hotjar glossary entry; this page is the work.

Before you touch the form:

1. Work out how much of the form you will see. Coverage is your plan's daily session limit divided by potential traffic: for example, 500 daily sessions on a site with 1,000 potential sessions a day gives 500 / 1,000 = 50%. Narrow session capture to the form's URL and the sample is drawn from those sessions instead, so the form gets more of the 500 (sampling article).
2. Collect what you already have. The form page URL, the thank-you URL, the person who can add one line of JavaScript, and the consent rule your site already applies to analytics scripts.
3. Take the baseline from your own numbers. Submissions per form-page session for the past four weeks, from your analytics or CRM. Hotjar's counts are a sample and its recordings are deleted after 365 days (retention article), so the proof that the fix worked has to live where the baseline does.

What you need

• A Hotjar account with Observe; the API references carry plan badges at the top, and Hotjar's own prices are no longer public.
• The tracking code in the head of every page, through the site template or a tag manager (install article).
• A decision on consent, made with counsel. Hotjar's documentation places it as data processor under its DPA, with you as controller (processing personal data).

1. Confirm the code is live on the form page

On the Sites page, open View tracking code and run the check on the Verify installation tab; a Content Security Policy can block Hotjar even when the snippet is correct (check article). Then open the form page with ?hjDebug=1 on the end of the URL and watch the console: a line reading WEBSOCKET: Web Socket opened means session data can flow (debug mode article).

2. Suppress what the form collects

Keystrokes in input fields are suppressed by default. Anything else personal on the page, a prefilled name or an account's plan price, gets data-hj-suppress as an attribute or class; inline SVGs cannot be suppressed, and whole pages can be excluded (suppression article).

3. Fire one event for success and one for failure

Hotjar's own example is a checkout that sends hj('event', 'Added Credit Card successfully') when the server replies and a second event when the call fails; copy the shape: signup_submitted on the thank-you response, signup_error when validation rejects the submission (Events API reference). The same reference sets the rules. Names up to 250 characters of letters, numbers, underscores, dashes, spaces, periods, colons, pipes and slashes. No personal data, no email, no number of 9 digits or more. If an Identify call runs too, it goes before the event or a targeted survey will not show. If your script can run before the tracking code loads, add window.hj=window.hj||function(){(hj.q=hj.q||[]).push(arguments);}; above it.

Test it: fire hj('event', 'signup_submitted') from the console and look for COMMAND: Processing command: event signup_submitted, then submit the form as a visitor would and check the same line appears on its own (debug mode article).

4. Point session capture at the form

An Admin can set Hotjar to start capturing when a visitor lands on the form URL or when an event fires, and events take priority over URL rules (targeting article). Once capture is narrowed, the traffic coverage widget will fall: it always measures against potential traffic for the whole site and ignores your targeting rules, per the sampling article. That widget is built to name a larger session tier whenever the site is bigger than the page you care about, so read it as a number about the site, not about the form.

5. Filter the recordings three ways

Events filter recordings and heatmaps, and the Clicked Element filter is built in for buttons (events setup article). Sessions with signup_error: watch five and note which field rejects people. Sessions where the button was clicked but neither event fired: the request that never completed. Sessions on the form page with no click: the people who read and left.

6. Read the heatmaps of the form page

Filter the heatmaps by the same events to put the click map of people who submitted beside the people who hit an error, and read the scroll map for how many reach the button at all.

7. Ask the people the form rejected

Events trigger surveys as well as filters, the reference's own example being a survey shown after subscribed_to_email_list fires (Events API reference). Target a one-question survey at signup_error: what were you trying to do?

8. Let Zapier file every answer, and a person read them

Hotjar's documented automation for this is Zapier to Google Sheets: a Zap with Hotjar as the trigger, New Survey Response or New Recording as the event, an optional Filter step by country or device, and Create Spreadsheet Row as the action (Google Sheets reports article). The human check is the weekly read: one person opens the sheet, groups the answers by field, and picks the one change for the week. The article warns that renaming a column breaks the Zap, so settle the headers before you publish it.

This step is Hotjar-only: Contentsquare's migration FAQ lists Zapier and webhooks as unsupported on its Growth plan and offers its MCP server instead, with 300 tool calls a month on Free (migration FAQ, Contentsquare pricing).

9. Change one thing, then compare whole weeks

Fix the field that rejects the most people, leave the rest alone, and compare submissions per form-page session over the next full weeks with your baseline. One change at a time is the only way the recordings can say which fix did it.

What Hotjar's documentation warns about

• An event fired before the tracking code loads throws an error and is lost, unless the queue line in step 3 is present.
• An Identify call after the event stops a targeted survey from showing.
• GTM data layers, SKUs, dates, referral codes and error logs should not be passed as events, per the reference.
• Do Not Track makes Hotjar discard user attributes for the session, which debug mode reports as a blocked identify command (debug mode article).

FAQ

Why does debug mode say "No recording in progress. Not sending."?

The visitor's session was not being captured, which happens when sampling is in effect or capture is restricted to other pages (debug mode article). Check the coverage widget and the targeting rules from step 4.

Can I run the same job in Contentsquare after my account moves?

Partly. URL targeting rules and suppression settings carry over; event-based targeting rules do not yet, and Zapier is unsupported, so the sheet in step 8 needs another route (migration FAQ).

Do I need the Events API, or will the Clicked Element filter do?

For the button alone, the filter is enough, per Hotjar's setup article; the events separate a submission the server accepted from one it rejected, which no click can show (events setup article).