Script errors

A script error is a JavaScript error thrown during a real visit. Something on the page broke while a person was using it: a third-party widget failed to load, an event handler hit an exception, a feature silently stopped working. Clickport catches that moment and counts it, so a quiet failure does not stay quiet.

What a script error is

Most analytics tools tell you what visitors did. A script error tells you when the page itself failed to hold up its end. It is recorded only when an actual error fires in a visitor's browser during a live visit, not from a synthetic test or a crawler. If a button stops working because the script behind it threw, you see the error instead of guessing why conversions dipped.

How it is captured

Everything happens in the visitor's browser, in the tracker, and only a thin signal is sent. Clickport listens for uncaught errors and records two things: the script filename and the line number where it broke. That is it.

• Script filename and line, nothing more. An error from app.4f2a.js at line 88 is stored as app.4f2a.js:88. The page it happened on rides along, the same way every signal does.
• No message bodies. Error messages can carry user input, tokens, or other personal data, so Clickport never stores the message text. Only the script and line survive.
• Cookieless. No cookies, no fingerprinting, no cross-session identity. The signal stands on its own.
• Capped per page. A single broken loop cannot flood your data. Repeated errors on one page visit are limited to a handful.

How to read it

In the Signals breakdown, Script errors is one ranked row showing the visitors who hit an error and the total error events. Expand the row to see the individual script:line pairs, ranked by frequency, so the script that breaks most for the most people sits at the top.

Click the row, or any sub-item, to cross-filter the whole dashboard to the visits where that error fired. From there you can see which pages, browsers, and sources are affected.

How to act on it

• Catch failing third-party widgets. Chat boxes, payment embeds, review widgets, and ad scripts break often and break silently. A spike in widget.embed.js:12 points you straight at the culprit.
• Find broken handlers. When an error correlates with rage and dead clicks on the same page, you have likely found a button whose handler is throwing. The visitor clicks, nothing happens, and the error explains why.
• Pick pages to QA. Errors clustered on one route tell you exactly where to test next, instead of clicking through your whole site hoping to reproduce a bug.

Relationship to dead clicks

A broken script is one of the most common causes of a dead click. When a handler throws an exception, the element looks interactive but does nothing, so the visitor clicks a button that quietly fails. Seeing a script error and a dead click on the same element, on the same page, is a strong sign you have found a real bug rather than a confusing label. Pair the two signals to tell broken from merely unclear.

What is stored

Script error signals are deliberately thin. For each one Clickport keeps the script filename, the line number, and the page it happened on. What is never stored: the error message text, stack traces, variable values, user input, screen recordings, and any personal data. There is nothing here that identifies a person.

Good to know

• Forward-only. Script errors exist for visits after the feature is active on your site. Past sessions cannot be backfilled.
• Single-page apps are covered. An error is tied to the right route even after a client-side navigation.
• It does not use your pageview allowance. Script errors are events, like outbound clicks and form submissions, and do not count toward your monthly pageview limit.
• Pairs with engagement. Cross-filter to an error and check engagement on the affected pages to see how much the breakage costs you.