The phrase ‘it works for me’ is usually true and usually useless. The site does work on the computer of the person who built it, in a browser they update every week, over a fast connection, and at the default font size. The problem is that this is not a typical visit—it is just one of many possible conditions, and bugs tend to live in the others.
This article is not about an outage that prevents everyone from submitting a form. Problems like that surface within an hour. It is about bugs that break the journey for a narrow group of visitors and can persist for months because nobody reports them. Below, you will learn how to detect them before someone calls to complain.
We deliberately do not quote browser, operating system, or screen-resolution shares. Those figures vary by industry and market, and the decision about what to test should come from your own data—not from a chart found online.
Why this kind of bug disappears in the statistics
Imagine that a form's submit button stops responding for one person in thirty. Your report will show a conversion drop of a fraction of a percentage point—exactly the kind of fluctuation the site sees in a normal week. No threshold is breached, no alert fires, and nobody has any reason to investigate. The bug dissolves into the average.
The other half of the problem is psychological. When something does not work, people rarely assume the site is at fault. They are more likely to think they tapped the wrong place, have a poor signal, or that the company simply does not respond to enquiries. Leaving is easier than reporting the problem—it takes a second and does not require explaining your phone to a company you do not know. That is why a lack of reports is not evidence that everything works.
This creates an unpleasant paradox: the narrower the affected group, the longer the bug survives. An outage affecting everyone gets fixed the same day. One affecting five percent of visitors may survive the next redesign. This is especially worth remembering after a release, when most such bugs are introduced—we explore measurement continuity further in our article on website redesigns and measurement.
Stop looking at averages and start looking at segments. See how Meetlead breaks down behavior by device and visitor profile.
Common causes of bugs that affect a minority of users
The conditions of a customer's visit differ from yours in several recurring ways. The table below matches what is different for the customer with what most often breaks as a result—and with a way to detect the problem without guessing.
Scroll the table sideways to see all columns.
| What is different for the customer | What usually breaks | How to detect it |
|---|---|---|
| An older browser or phone | Part of the layout does not render, a section remains blank, or a button does not respond | Segment by browser and device in the visitor profile |
| Enlarged system text | Text spills out of a button, labels overlap, or content disappears behind the header | Complete the journey with the page zoomed to 200 percent |
| A slow connection | Scripts load late, and clicking an element that looks ready does nothing | Repeated clicks in the same place on the click map |
| A content blocker or browser extension | A form, map, or embedded element does not appear at all | Sessions missing events that always occur on that page |
| System-enforced dark mode | Text blends into the background, field borders disappear, or an icon becomes invisible | Manually complete the journey with dark mode enabled |
| A very wide or very narrow screen | Columns break apart, an element overflows the viewport, or a button ends up out of reach | Click and scroll maps segmented by device |
| Browser autofill | Data goes into the wrong fields, or validation rejects a valid number or address | Form session recordings in which fields fill abruptly |
We have intentionally treated two rows briefly because each has its own guide. We discuss barriers specific to small screens in our article on mobile conversion, and using a site without a mouse or with a screen reader in our guide to accessible contact journeys. Here, we are interested in the detection method itself: what to do when you do not yet know what you are looking for.
An important note about the tool: Meetlead does not collect JavaScript errors or browser logs and is not a technical monitoring tool. It shows the symptom and who it affects: a session recording with the visitor's full profile—including their browser, device, and URL—alongside click and navigation markers. Finding the technical cause, whether a specific code error, server response, or library version, requires a separate tool and someone who can inspect the code.
Data signals that reveal a narrowly scoped bug
You cannot predict where something will break, but you can learn to recognize the trail a bug leaves in the data. In practice, the four patterns below are enough to form a credible hypothesis.
- A segment with zero conversionsOne browser, operating system, or screen-width range receives traffic but produces no enquiries for an entire month.
- Clicks with no effectRepeated clicks in the same place, followed by no navigation and no subsequent event.
- A shared exit pointSessions from different sources end at exactly the same step in the journey, even though nothing there should prompt people to leave.
- A visit without expected eventsA visitor scrolls through the page and stays for a long time, but events that always occur on that page are missing.
The first signal requires caution: in small segments, zero conversions may simply be chance. Treat it seriously only when the segment contains a meaningful number of visits and other comparable segments convert normally. The second signal is the strongest and easiest to investigate—repeated clicks in the same place are the data equivalent of someone saying, ‘I'm pressing it and nothing is happening.’ An event attached to a specific element then lets you check whether that button records interactions in every segment or only some of them.
Read click and scroll maps separately for phones and computers, because aggregated maps can hide a pattern that occurs in only one group. We explain how to interpret the maps themselves in our guide on reading heatmaps.
A visitor profile alongside the recording, click markers, and maps segmented by device—without them, you are left guessing. See exactly what Meetlead records.
How to confirm the hypothesis with a recording
Quantitative data tells you that something is wrong and identifies the affected group. A recording shows the sequence of events: what the visitor tried to do and when they gave up. We cover the general rules for choosing material in our article on how to analyze session recordings. Hunting for a bug that affects only a minority calls for a different filtering method, however.
- Filter by profile, not date.Choose sessions from the suspect browser, operating system, or device instead of watching the latest visits one after another.
- Choose visits that progressed far but produced nothing.A visitor who completed three steps and disappeared at the fourth wanted something and encountered an obstacle.
- Start watching at the decision point.Jump to the point where a click or navigation should have occurred and watch what happens immediately beforehand.
- Look for three symptoms.Repeated clicks in the same place, a sudden pause after a previously steady pace, and going back one step.
- Run a control check.Watch several sessions from a typical browser on the same page. If the journey is smooth, the hypothesis holds up.
- Reproduce the condition yourself.Enlarged text, dark mode, a slower connection, or an enabled blocker—only this turns a hypothesis into a bug ready to fix.
- 0:00
Arrival from a search engine on a service page, with browser and device shown in the visit profile
- 0:26
Scroll to the form and enter a name and email address
- 0:48
Three clicks on the submit button, with no navigation and no subsequent event
- 1:03
Scroll up, return to the form, and click again
- 1:19
Leave the site without submitting an enquiry
The last step is the easiest to forget. A recording shows that the button did not work, but it cannot tell you why. Reproducing the condition on your side turns an observation into a ticket a developer can act on—and if you cannot reproduce it, at least you know whose experience and which setup require a closer look.
A customer's question is your cheapest detector
Before any chart shows a decline, someone will write a sentence in chat that is easy to dismiss. It is the cheapest bug-detection system you have and the only one that works from day one. There is just one condition: the team must treat comments like these as bug reports, not user error.
- ‘I can't click it’—the element looks active but does not respond, or something else is covering it.
- ‘Nothing happens’—the action was performed, but the page provided no feedback.
- ‘I can't see that button’—the element is outside the viewport or blends into the background.
- ‘The form won't accept my number’—validation rejects a valid format, or autofill placed the data in the wrong field.
- ‘The page layout is broken for me’—the layout fails at that resolution or with enlarged text.
- ‘I had to open it on a computer’—the mobile journey is incomplete, and the customer worked around the problem themselves.
Replying ‘it works for us’ ends the conversation and discards the only available evidence. Ask three questions instead: what the customer is using, exactly what they did, and what they saw. Live chat helps twice over because the operator can see the page the customer is currently viewing and does not have to ask them to describe the URL. If the conversation later becomes a ticket with its history attached, the next similar comment from another person stops being an anecdote and becomes a pattern. We discuss the choice of fields and messages in a separate article on website contact forms.
One sentence in chat plus a recording of the same visit is the shortest route from symptom to cause. Schedule an implementation session, and we will help you set up your first workflow of this kind.
If an issue has several possible causes, use the guide: Troubleshooting instructions: a decision tree instead of random fixes.
A review routine for every change
Most bugs that affect a minority are introduced during a release; they do not appear on their own. The cheapest time to catch them is therefore a few days after a change, while everyone still remembers exactly what was touched. The checklist below takes 15 minutes and catches a surprising amount.
- Complete the entire contact journey in a browser other than the one you use every day.
- Repeat the journey with the page zoomed in and with system dark mode enabled.
- Test the site on an older phone available at the company, using a real mobile connection.
- Open the site with a content blocker enabled and check that the form and embedded elements appear.
- Compare conversion by browser and device with the week before the release.
- Review the click map for a key page, looking for repeated clicks in the same place.
- Read conversations and tickets from the first few days after the change, looking for comments that something does not work.
The final point is often the most productive because it takes only a few minutes and requires nothing beyond your conversation history. To turn this into a routine rather than a one-off push, add these seven points to your release checklist alongside the tests your team already runs. A bug found during release week costs you a fix. The same bug found three months later costs you three months of enquiries.
