Bug reporting for e-commerce stores

Shoppers and staff can show you exactly where the store broke, and you can set it up so that customer details and payment data stay out of the report.

The problem: a broken store loses sales quietly

A clothing store launches a summer collection. On some phones the size picker overlaps the 'Add to cart' button, so tapping it opens the size list instead. Nobody on the team uses that phone. Most shoppers who hit it simply leave. The few who write in say 'your site doesn't work'.

Store bugs are usually visual and device-specific: a layout on one screen size, a theme app that clashes with another, a discount that applies on desktop but not in the mobile drawer. A screenshot with the viewport, pixel ratio and browser attached is often the whole diagnosis.

Setting up the widget on a store

  1. 1

    Create a project for the store

    Add your storefront domain to allowed domains, for example shop.example.com, and your preview or development theme domain if your platform gives it a different host.

  2. 2

    Add the snippet to the theme

    Paste the script tag into the theme's <head>. The Shopify, WordPress and Wix guides show where that is. Using a tag manager instead? See Google Tag Manager.

  3. 3

    Pick categories for a store

    Product page, Cart and checkout, Search and filters, Content, Something else. Your team knows who fixes what; shoppers just pick the closest.

  4. 4

    Start with staff, then open it up

    Run the widget during a launch with staff and a few trusted customers first. Once the reports are useful, decide whether to leave the button visible for everyone or to hide it and open the form from a 'Report a problem' link in your footer with Flawsnap.open().

Keep payment and personal data out of reports

This matters more on a store than almost anywhere else. Flawsnap gives you the controls, but you decide where they go:

  • Never ask for card details. The report form has no payment fields, and you should not ask shoppers to paste card numbers, order passwords or full addresses into the description.
  • Blur before sending. The screenshot tools include Blur, which pixelates an area in the browser before upload. Tell staff to blur names, addresses and emails on order pages.
  • Block sensitive elements in recordings (Pro). Typed values are always masked in recordings. Add data-flawsnap-block to address blocks, order summaries or any element you never want in a replay.
  • Network capture has no bodies. The last 100 requests are recorded with method, URL, status and duration only. Request and response bodies are never captured, so avoid putting personal data in URLs.
  • Watch your own console logs. The report includes the last 100 console messages. If your theme logs customer objects, remove those logs.
  • Hosted checkout pages. If your checkout runs on your platform's or a payment provider's domain, the widget only runs there if that domain is in your project and you can install the script on it. Many stores can't, and that is fine.
Keep an element out of recordings
<div class="order-address" data-flawsnap-block>
  …customer address…
</div>

What a useful store report contains

  • The product URL, attached automatically, plus the variant: 'Linen shirt, size M, colour sand'.
  • A box around the problem and an arrow to what they tapped.
  • Viewport and pixel ratio, which explain most "only on my phone" layout bugs.
  • Any failed cart or discount API call in the network tab, with its status.
  • For a discount bug, the code they tried. Not their order number unless you need it, and never a card number.

Triage during a sale

On launch or sale days, turn on auto-add to board and filter the reports list by Critical, then by High. Anything in Cart and checkout goes straight to Todo. Insights on Pro adds API timing, so a slow cart endpoint shows up as a trend rather than a single complaint, and error tracking on both plans groups repeated front-end errors into one issue.

Pitfalls

  • Forgetting the preview theme domain, so staff testing a new theme get refused.
  • Leaving the button on top of your own chat or cart drawer. Move it to the left with the position setting if your theme puts something in the bottom-right corner.
  • Treating reports as support tickets. Shoppers get no automatic reply from Flawsnap. If they left an email and need an answer, someone has to write back.

Questions

Can shoppers report a bug without an account?
Yes. Anyone on a domain you listed can open the form and send a report. They don't sign up for anything.
Does Flawsnap see what shoppers type at checkout?
Screenshots show what is on screen, so reporters should blur personal details. Recordings, on Pro, always mask typed values, and network capture never includes request or response bodies.
Can I try it on a store before installing?
The live demo runs the real widget on a pretend shop. Reports sent there are deleted after 24 hours.

Try it on your own site

7-day free trial, then $9 a month for Starter or $19 for Pro, per organization, with unlimited team members.

Updated