Context with every message: page, device, console errors, failed requests

Every message from the widget arrives with its context already attached: the page it was sent from, the visitor's browser and operating system, their device, their language and, if they took one, a screenshot. A bug report also carries the console errors and the failed requests that happened before it was sent. The visitor writes a sentence. The rest comes with it.

The context is included on the free plan.

Why I built it

I have worked on a lot of digital products with a lot of support teams, some of them on complicated ones, like mobile apps in payments. When a bug comes in, the first thing anyone tries is to reproduce it, and that takes as much detail as you can get. Ideally you would know everything, from the first tap to the moment it went wrong. You almost never do.

Without that, a bug you can't reproduce is a bug you patch blind. You try a fix, then another, and a lot of it is trial and error. Even when the reports stop, you can't tell whether it was fixed, because you never saw it happen.

So support asks. Which phone is it? Which version of the operating system? Which version of the app? Over lunch a friend told me his app for his electric car had stopped working, and support had asked him for exactly that list. He shouldn't have to know. Finding the version of your phone's operating system isn't obvious, and what you find can be a kernel number or a build number you can't easily copy. It makes things worse for someone who already has a problem. And when the details don't arrive, support can't move forward, and the situation gets worse.

In a mobile app you can collect the device, the operating system and the app version for free, and the user never thinks about it. When you add Two Cents to a mobile app, every message arrives with the device, the operating system, the app version and the build. When you add it to a website, every message arrives with the page, the browser and the device. Either way, the person writing spends no effort on it. Most people wouldn't take the time to give those details, so without it you would never receive them.

What comes with every message

Whatever kind of message it is (a bug, an idea, a question, a review, or an answer to one of your own questions), it arrives with:

• the address of the page it was sent from, and the page the visitor came from;
• the browser and its version, and the operating system;
• the visitor's language;
• the size of the window, the size of the screen and the pixel ratio;
• the visitor's time zone;
• how long the page took to load;
• the speed of the connection (4G, 3G or 2G), in Chrome and Edge.

The inbox turns the raw browser string into plain words, such as "Safari on iOS", and lists these details under the message in a Technical details block.

A screenshot of what they saw

On a computer, one click captures what the visitor was looking at, the visible part of the page, with the widget itself left out of the picture. On a phone or a tablet, browsers can't capture the page, so the visitor takes a screenshot with their phone and attaches it. The picture is scaled down to 1,600 px and saved again before it is sent, which removes its hidden data, including the location of a photo.

The library that takes the screenshot, about 260 kB, is downloaded when somebody asks for a screenshot. Visitors who never open the widget don't load it. You can switch screenshots off for a project.

What a bug report adds

A bug report carries two more things, recorded from the moment the page loads:

• the last 25 errors and warnings: console.error, console.warn, uncaught exceptions and unhandled promise rejections;
• the last 15 requests that failed, with the method, the status, the address and how long they took, such as POST 500 https://yoursite.com/api/checkout (412 ms). A picture, script or stylesheet that didn't load goes on the same list.

They show in the inbox as two blocks under the message, "Console errors" and "Failed requests". The lists cover what happened before the visitor opened the widget as well as after, so the error that fired two minutes before they clicked is in them.

An example: the form that doesn't work

Say a visitor writes "the form doesn't work". Without context, your reply is "which form, on which page, and what did you see?", and many people never answer.

With it, the message arrives from your checkout page, on an iPhone, in Dutch. The screenshot shows the form with the button greyed out. The console errors hold a TypeError that explains why, and the failed requests hold the POST /api/checkout 500 behind it. Your reply is a fix, not a question.

What the widget keeps, and what it leaves out

• Addresses are cut after the path. The query string and the fragment, where tokens and email addresses often live, are not kept.
• Request and response bodies and headers are not read. A failed request is described by its method, its status, its address and its duration.
• Successful requests, requests the page cancelled itself and the widget's own calls are not recorded.
• The console errors and failed requests belong to bug reports. The other kinds of message carry the page and device details.

Try it on your own site

Open your project's Install page and use the sandbox link, which runs the real widget against your own site. Open the browser console, trigger an error, send a bug report from the widget, and open the message in your inbox. The Technical details, the console error and the failed request are all there.

Where to go next

The widget, its four kinds of message and how it looks on your site are on the feedback widget page. To ask something specific on a page, see custom questions. If visitors send you bug reports, the bug report template lists what a visitor never includes, and what the widget captures for them.

Two Cents is free for one project and 25 messages a month, with the context included.