Dead Clicks Analysis (clicks on non-clickable elements)

Dead click analysis: where the interface loses users

A user clicks a product card, pricing plan tile, or icon in the header — visually it is an obvious control: the cursor changes, there is an underline and a hover state.

But there is no click handler behind it, the click goes to the parent container or an overlapping layer, and the page does not respond.

There are usually three causes in the markup: a link without an address, a button in an inactive state after asynchronous data loading, and an element covered by a transparent layer with a high stacking level.

For analytics, such clicks are not harmless noise but a systemic interface problem.

Clicks on non-clickable elements are recorded as normal interaction and end up in heatmaps, funnels, and the user path: time to target action grows, step conversion drops, and exit points shift to elements that were not interactive to begin with. Metrics look worse than reality, and improvement decisions are made based on distorted data.

A separate challenge is distinguishing a click into empty space from a deliberate abandonment: the user may have clicked, not waited for a response, and left, or may simply have changed their mind.

Therefore the analysis starts from comparing markup and handlers — which nodes look clickable by styles and semantics, whether they are subscribed to an event, and whether the parent intercepts the click.

Next we look at the sequence: whether the click occurred immediately after the block rendered, before data appeared in it, and whether it repeated on the same node across different sessions.

This finds the answer to why the element does not work and makes it clear which dead clicks are real. We break down how this is addressed: how to separate them from false positives and what to fix first.

What analyzing clicks on inactive elements provides

A click on an inactive area is recorded automatically, but by itself it is not a problem. A user may miss the button, tap text during inertial scrolling, or click an element again while a transition is loading.

In Yandex Metrica, such events are collected into a click map report, where genuine interface failures and noise sit side by side — the engineer's task is to separate one from the other.

The first measurable effect is the share of confirmed interface problems. Without filtering by coordinates, target size, and the time between click and page structure change, the report shows hundreds of “hot” spots, of which only a handful actually break the scenario.

After configuring the sample, most signals in the report are confirmed instead of roughly a tenth — the front-end developer no longer spends a shift sorting through false positives.

The second effect is the time to find the cause of a conversion drop at a specific step. Once the analysis is set up, the cause is localized within a workday: you can see on which screen users click a non-clickable banner, price block, or label under a field. Previously this took a week of hypotheses and blind markup edits.

The third effect is a removed class of false signals. A tap during scroll, a click on text inside a linked element, a repeated click after navigation has already fired — all of this stops ending up in tasks and stops distorting priorities.

As a result, the team's trust in reports grows: priorities in the work queue are based on confirmed data rather than arguments like “I think this is inconvenient.” Analyzing clicks on inactive areas becomes a regular pre-release check instead of a one-off action after a conversion drop.

Implementation options: manual tracking, rules, ready-made reports

The choice of option determines where the source of truth about a click is located: in the interface markup, in event processing rules, or in a ready-made report.

This affects how much manual work goes into each new element and how quickly the report starts diverging from the real interface. Below are four working alternatives and their applicability limits.

In practice, the options are combined: component tracking covers the main scenarios, rules pick up dynamic blocks, and the ready-made dashboard serves as a showcase for regular viewing.

We record the limitations of each approach before work starts — otherwise, a month later the report stops answering the question of why the user did not reach the target action.

How the work is structured: stages from markup audit to handover

We start with an inventory of what is already being collected on the site: counters, goals, session recording.

This data is usually enough for the share of clicks on non-clickable elements, but not to understand which exact element was clicked: the handler is attached to the container, and coordinates shift with responsive markup. Therefore the first step is a markup audit, not new reports.

1. Markup audit. We compare templates: where elements are already identified by attributes and where they are not. We separately mark dynamic blocks that change their selector after loading.
2. Event schema. We agree on what counts as a click on a non-clickable element: text, an empty area of a card, an image inside a link. We fix the event fields so the report does not fill up with junk.
3. Rule setup. We tie the rule to a stable attribute of the element, not to an ordinal selector. Only a click that leads to neither navigation nor a state change falls into dead clicks.
4. Validation on live traffic. Several days with real visitors, selective manual reproduction, and comparison with automated tracking. We filter out swipes, inertial scrolling, and accidental touches.
5. Page summary. We group findings by templates and elements — fixes are driven by frequency, not by gut feeling.
6. Project handover. We provide the event schema, rule documentation, access credentials, and instructions on how to add a new element without a developer. We train the team and establish markup review at releases.

What you receive: configurations, schemas, regulations

Dead click reporting lives longer than the project itself: a new analyst or contractor should be able to understand it without messaging us. Therefore we hand over not a one-off export but a working kit — from markup to the procedure for handling an anomaly.

• Event map — a list of tracked actions with the exact element attribute, event type, and person responsible for tracking. It shows which click is considered dead and which is navigation within the interface.
• Event filtering rules — what we discard before calculation: hidden and disabled elements, service clicks, duplicates from repeated counter initialization. The rules sit next to the tracking code, not in a chat thread.
• Data access policies — roles, visibility scopes, and retention periods for raw logs. It is separately recorded what goes into the report, what remains in storage, and who can see it.
• Report review regulations — the frequency of reconciliation, acceptable deviation for key scenarios, and the procedure for responding to a spike in dead clicks after a release.
• Project documentation — collection architecture, data flow diagram, and instructions for connecting new pages without modifying the core.
• Markup check suite — tests for key scenarios that catch a mismatch between the event map and the interface before publication.
• Change log — what and when a rule or event changed, linked to releases: rollback stops being guesswork.

We hand the kit over to your side in working formats — so reporting can be developed by your own team or handed to another contractor without rebuilding from scratch.

Case study: removed false signals and restored trust in data

Before the analysis, analytics brought about 1,800 signals about “dead” clicks — clicks on non-clickable elements.

The team reviewed them selectively: only a small part reached the interface, and disputed cases were closed with the wording “looks like noise.” Fixes were made based on hypotheses, and after a release no one could say whether the problem had gone away or simply shifted.

We divided the signals by type (click on text without a link, on an image in a card, on a visually active but disabled button), filtered out bots and clicks with element overlap, and compared the remainder with the page markup in Yandex Metrica. Only what repeated across several users on the same element made it into the report.

What was confirmed and what was dismissed

Three causes were confirmed: a disabled add-to-cart button on the card, a “share” block without a link in the mobile version, and a tooltip in the order form that looked like a button.

Two hypotheses were dismissed — about the menu markup and about the tap area size: the signals for them came from bots and double taps.

After that, product teams stopped arguing about whose data was correct. Each interface fix is tied to a confirmed cause, and the effect is visible in the drop of signals on a specific element.

How does a dead click differ from a tracking failure and a false event?

A dead click is a press to which the interface does not respond at all: the handler is not attached, the element is decorative, or it is covered by an invisible layer.

The user hits the button a second and third time, then leaves — and the session recording shows a series of clicks with no response at all.

A tracking failure looks different: the element works, there is a response, but the event is sent with incorrect data — the button ID is lost, the step number is not passed, the handler is attached to the container instead of the button itself.

The action is present in the report, but it can no longer be tied to a specific scenario: the metric lies softly, and this is noticed later.

A false event is the third case, when the handler fires on the user's service actions: programmatic clicks, autofocus, form restoration after a reload, repeated submission when going back.

Here there are more clicks and submissions than real actions, and the metric growth looks like success.

Three signs help distinguish the cases: whether there was a visual reaction to the press, whether a request went to the server, and whether the event's dataset matches the element that was clicked.

The first sign points to a dead click, the other two separate a tracking failure from a false event.

The reliability of measurements rests on the fact that any analytics system, including Yandex Metrica, records only the event that was sent, not the user's intention.

Therefore, before drawing conclusions, we compare the funnel with session recordings and handler markup — a discrepancy in one place usually means that some clicks are not captured by the measurement at all.

Common concerns: measurement accuracy and false positives

Measurement accuracy depends on configuration, not on the behavior capture tool itself.

If any click that did not lead to a screen change is considered a problem, false positives will end up in the report: decorative frames, areas with their own gestures, elements with a response delay.

Therefore, the element type, click zone, and response time are recorded, and clicks inside active areas of widgets are excluded from the sample. Below are concerns that usually arise before the start.

We already have our own event tracking — will we have to throw it away?

No. Working events remain reference points, and click collection on non-clickable elements is connected alongside and linked to them by block identifiers.

What personal data ends up in the report?

Only depersonalized technical data: element type, click zone, response time, and session identifier. Text that a person enters into fields is not read, form contents are not stored, and there is no linkage to a person or device.

Will we have to modify the product code, and how long will it take?

The main application code does not change — integration happens in a separate layer. A trial launch on one section takes several days, including false-positive validation; after that we expand coverage in iterations. Point edits are needed only where the interface itself reports that a block is ready.

Let's discuss the task: what data is needed to start the project

You can start without full access to the infrastructure and without exporting the entire history — for an initial assessment, a set of behavior data on 2-3 key scenarios is enough.

The more specific the input, the more accurate the estimate of the scope of work: we immediately see where tracking setup is enough and where reworking the markup and interface logic will be required.

• the resource address and a list of pages or scenarios where clicks on non-clickable elements are most noticeable;
• access to the web analytics system with permissions to export reports and build segments;
• the current event tracking schema: which actions are already recorded and by what rules they are named;
• an export of session recordings for 2-4 weeks or examples of specific visits where behavior looks strange;
• a description of interface elements that look clickable but do not respond to a press;
• project constraints: test environment, personal data handling rules, windows for deploying changes;
• the contact of a person on the client side who confirms priorities and answers questions about scenarios.

In response, we return an estimate of the scope of work by stage, an implementation plan with the sequence of steps, and a list of metrics by which we will measure the result — the share of abandoned click attempts, scenario completion depth, and the number of support requests about non-working buttons.

You can discuss the task with our engineer or practice lead: describe the scenario in two paragraphs and attach what you have from the list above — we will come back with an estimate and a plan.