Hotjar Integration for Mobile App Heatmaps

Hotjar mobile SDK: where heatmap collection breaks

In-app heatmaps break more quietly than on a website: event collection is formally running, the report opens, but the picture does not match reality.

Almost all defects come from three causes — lost binding to elements, broken sessions on a weak network, and shifting screen markup after a release.

The first failure — events do not bind to elements. The mobile interface is assembled from reusable containers that have no stable identifiers: the handler sits on the root layer, and the tap goes to it rather than to a specific button.

In the report, such clicks collapse into a single point, and the map shows activity where there is none.

The second — lost sessions. Events accumulate in a buffer and are sent in batches, and if the network disappears, the app goes to the background, or the system unloads the process, the buffer disappears.

Without writing to disk and resending, up to a third of sessions are lost, and unevenly: the long scenarios where the user goes to a subscreen and returns are the ones that drop out.

The third — screen markup after an interface update. If binding relies on an element's position in the tree, rearranging blocks shifts all keys, and data from the previous version is overlaid on the new one.

It is fixed with stable keys on every interactive element and a screen schema version in the event itself — old and new slices no longer mix.

We break down how this is closed: where edits are needed in the mobile SDK wrapper, where in screen markup, and where in event intake and storage.

What a correct in-app heatmap provides

A per-screen heatmap answers the question "where do they tap" but not the question "why do they not reach".

When events are bound to stable element identifiers rather than touch coordinates, collection provides an end-to-end user path: you can see the entry screen, returns back, and the step at which the screen funnel breaks.

What is found is not an "ugly button" but a specific transition that loses a noticeable share of the audience.

Data quality rests on two things — binding to interface elements and a unified event naming schema.

Without them, the map lies systematically: transparent zones appear where an overlapping layer actually lies, and "dead" areas appear where the markup simply did not work.

Incorrect markup is more dangerous than its absence: it produces confident but wrong decisions. A typical failure — an element was renamed or moved, the event continues to go to the old binding, and the team optimizes a block that is no longer in the current build.

On new interface versions, markup behavior must be predictable: before release we verify events against the screen tree, and a discrepancy is caught before rollout, not a week later from strange numbers.

We organize collection on the application side and use Hotjar as a showcase — maps, session recordings, and funnels in one window. Then interface decisions rely on data, not guesses.

Collection methods: cloud service, own collection, hybrid

The choice of a behavioral data collection method is dictated not by the convenience of the panel but by which events the application is ready to expose and what is allowed to be done with them afterward.

A cloud analytics service takes intake, storage, and visualization upon itself, but imposes its own rules on the event composition and sending frequency.

Own event collection removes these rules but adds its own intake pipeline, storage, and map rendering — this is a separate operational loop. A hybrid scheme divides the flow: depersonalized telemetry goes to the cloud, sensitive events remain inside the perimeter.

Hotjar is an example of the cloud path: in a mobile application it provides less than in web because native screens have to be marked up manually, and maps are built from a limited set of events.

If such completeness is sufficient, the cloud wins on timelines; if not, we consider a hybrid or own collection.

Implementing heatmap collection: stages of work

A heatmap distorts the picture if touches are bound to screen coordinates rather than to elements: on a different resolution, in dark theme, or after a layout change, points shift and draw nonexistent problems.

Therefore collection is not turned on with a single switch but deployed step by step — from audit to a regulation for the team that will add events further.

1. Markup audit. We go through screens and states: what is marked up, where events are duplicated, where they are lost on transitions between windows and after authorization.
2. Event schema. A unified reference: name, parameters, send moment, binding to element. We fix naming rules immediately — otherwise one tap will produce five different events.
3. Collection setup. We connect Hotjar in a test build, enable session recording and touch maps according to the reference, and check on real devices and OS versions, not only in an emulator.
4. Completeness control. We compare the flow with product analytics: share of taps that arrived, gaps on transitions, discrepancies between platforms.
5. Acceptance check. A run through the checklist on a release build: network loss, send failure, screen update. Collection must not block the interface or stretch response time.
6. Team handover. Documentation on markup and a revision regulation before release: who adds an event, where they check it, and when they remove an outdated one.

After that, the schema lives by these rules, not by the taste of an individual developer: new screens are marked up the same way, outdated events are removed. That is why maps remain readable after a dozen releases rather than turning into a set of incompatible data.

Event schema, field masking, and regulations

The event schema is as much a project artifact as the build configuration: it is handed over together with the code, not left in chat.

Below is the composition of the kit by which an engineer turns on collection in a day, and an analyst builds reports without edits in the application.

• Event registry: name, meaning, screen, call location, property composition, and owner. Each name is verified against the actual layout so that no dead events remain in the schema.
• Naming rules: template "section_action_result" in lower case, length limit, ban on abbreviations and versions in the name — otherwise one action becomes overgrown with duplicates and the funnel does not add up.
• Masking policy: list of fields that are not sent in clear form — phone, email, payment details, free text. For each, the method of replacement with a mask or irreversible hash and the check point before sending are specified.
• Collection policy: what is written before consent, how refusal is accounted for, how long exports live, and how they are deleted on request.
• Screen and transition map: key routes are marked up, it is visible where scenarios diverge between platforms and which paths are not covered.
• Change regulation: the document has a version and owner, schema edits go together with interface changes, and outdated events are taken out of circulation according to plan.
• Verification instruction: how to make sure an event is sent with the required properties, and how to turn off collection in an internal build.

Separately, we fix which reports in Hotjar are built on these events — so that the panel does not turn into a dump.

Case: share of lost sessions fell to single-digit percentages

In an application with a dense user flow, session recording arrived in fragments: going to the background, changing screen orientation, and fast transitions between sections interrupted the recording.

Heatmap reports were missing some taps — by measurements, about 40% of events were lost, and in some scenarios the chain fell apart in the middle.

The team made decisions based on a distorted picture: "dead" zones on the map turned out to be areas where there was simply no data.

What was changed

Collection was moved to Hotjar not "as is": each screen was assigned a stable identifier, and key actions were marked up with separate events with clear names.

This removed binding to the screen number in navigation — previously, after a section was renamed, events went to the wrong branch and statistics got mixed.

We separately configured behavior on connection loss: recordings are queued and sent to the server on the next launch rather than disappearing.

Metrics before and after

The share of lost sessions fell from 40% to 3-4%, and the completeness of the screen chain in a key scenario grew from 58% to 96%.

Markup for a new screen is now released in one to two days instead of two weeks: identifiers and events are described declaratively, without edits in navigation code.

The failure class "blind spots in analytics" is closed — heatmaps are built on continuous recordings. Interface changes are verified by actual behavior, not by guesses about where the user "should have" tapped.

What to do if Hotjar is already deployed in the application?

If Hotjar is already deployed, nothing needs to be reinstalled — the question is diagnostics.

Most often data is incomplete not because of the tool but because of initialization order: collection starts later than the first screen, and some transitions occur before the session opens.

We check in order: whether collection starts before the first screen renders, whether the screen identifier is passed in all transitions, whether consent to data processing suppresses sending, and whether events are duplicated on return from the background. Such a run separates false positives from real gaps in markup.

We perform markup migration without breaking history: screen and element names are fixed in the reference, old events are not deleted but marked, and new collection is enabled behind a switch.

This creates a period of parallel data where it is visible that the discrepancy is in behavior, not in markup.

Doubts about data accuracy and privacy

Touch recording in a mobile application is reconstructed from gesture coordinates, not from a video stream of the screen.

If an element is rendered by a native layer on top of the window, it will appear on the heatmap, but the binding to the interface node will shift — and the map will start to lie.

Therefore we verify screen markup against the view hierarchy and mark containers with explicit identifiers: then recordings of the same screen land in one map rather than five different ones.

We work with privacy at the build level: input field values are masked and do not leave the device, only the fact of completion goes out.

Screens with payments, documents, and personal account are included in the exclusion list, and the start of Hotjar collection is tied to user consent — until it is confirmed, recording does not start at all.

Can personal data leak into the recording?

Technically — only what the developer did not mask. We go through all forms and lists, mark fields with names, phone numbers, and addresses as hidden, and grant access to view recordings by roles and limit it by retention period.

Will the build size grow?

The mobile SDK library is a fraction of a percent of the application weight. We measure the increase before release in a test build and, if it exceeds the agreed threshold, move initialization to deferred launch.

Let's discuss the task — we will return with an estimate and work plan

To return with an implementation plan and work estimate rather than general words, we need to understand how your application is structured and what you want to see in the data.

Describe the task: which questions about user behavior remain unanswered and what decisions you plan to make based on the results — the markup schema and depth of session recording depend on this.

Useful to know before starting:

• platform and current framework branch, whether there are native inserts and modules in different languages;
• what is already marked up and where analytics is collected — so as not to duplicate events and preserve report continuity;
• key scenarios by priority: registration, payment, search, checkout — recording and funnels are configured for them;
• privacy requirements: which fields must not be recorded, whether masking and explicit user consent are needed;
• access: repository or project archive, test builds, a Hotjar account with project rights, a channel for building and distributing builds;
• release cycle constraints — how often you roll out and whether there are windows into which changes can be embedded.

In response, you will receive a staged implementation plan with the order of work and dependencies, a labor estimate, and the composition of deliverables: project configuration, event markup schema, sensitive data masking policy, team instructions, and operational notes.

Describe the task in a convenient form — a short email or a 30-minute call. We will ask clarifying questions and return with a plan and estimate.