Bug Analyst logo
3 min read

Privacy and your data: what we store and why

Buganalyst

Any script you add to your site deserves scrutiny, and a bug reporting widget — which by definition sends data from your pages to a third party — deserves more than most. This post is a plain-language account of what data flows through the widget, what we store, where it goes, how long it lives, and what control you and your users have. Our design principle throughout is data minimization: collect what is needed to deliver a useful bug report, and nothing else.

What a report contains

When a user submits a report, the following is transmitted and stored: the widget ID (so the report routes to the right project), the title and description the user typed, the URL of the page they were on, their viewport dimensions and user agent string, an optional screenshot or video if they chose to attach one, and a timestamp.

Each of these exists for a specific reason. The URL, viewport, and user agent are what make a report reproducible — without them, your team is back to asking "which page? which browser?" The media attachment exists only if the user deliberately added it. The timestamp lets your team correlate reports with deploys and incidents.

What a report does not contain

Equally important is what is never collected. The widget does not record browsing history, does not log keystrokes, does not read or transmit the content of your pages, does not set cross-site tracking cookies, and does not fingerprint users for identification. It is dormant until a user explicitly opens the form, and it transmits data only when they press submit.

We do not sell data, share it with advertisers, or use report contents for anything other than delivering the service. Your users' bug reports are your data, full stop.

Where reports go

Reports are stored so they can appear in your dashboard, and they are forwarded to the destinations you have configured — a Slack channel via your webhook, a Trello board via the OAuth connection you authorized. Both integrations are optional and can be disconnected at any time from your settings; disconnecting stops all future forwarding immediately.

It is worth being explicit about the implication: when you route reports into Slack or Trello, those copies live under those platforms' terms and your workspace's retention rules. The dashboard copy remains the canonical record under your control.

Media handling

Screenshots and videos are stored with the report and served only in the context of viewing that report. Users choose what to capture — an attachment never happens automatically. It is good practice to remind your team that screenshots can incidentally contain personal data visible on screen, and to treat report media with the same care as any user-submitted content.

Retention and deletion

You can delete any individual report from the dashboard, which removes the report and its media. Deleting a widget removes its configuration and stops all collection through its embed code. Deleting your account removes your account data, widgets, and stored reports. Operational logs are retained only as long as needed for security and reliability purposes, then discarded.

We intentionally avoid indefinite silent retention. Data that no longer serves you should not persist simply because deleting it required effort.

Your responsibilities as a site owner

Because the widget collects data from your users on your site, it belongs in your own privacy disclosures. Practical guidance: mention in your privacy policy that users can submit feedback and bug reports, describe what a report includes (their description, page URL, and technical environment details), and note the purpose — improving the product and fixing defects. If you operate under GDPR or similar regimes, bug report data typically falls under legitimate interest or consent depending on your setup; consult your own counsel for your specific situation.

Questions we welcome

Security reviews, data processing questions, and compliance questionnaires are a normal part of adopting any tool, and we would rather answer them early than have you guess. If your team needs specifics beyond what is covered here — data location, subprocessors, deletion timelines — reach out through the contact page and we will give you direct answers. A feedback tool asks for a small amount of trust; earning it with clarity is part of the product.