# How to track feedback volume after a release

> To track feedback after a release, compare a fixed window before and after the ship date, tag every item with the app version through setMetadata, then compare bug counts per day by version. A sharp rise in bugs for the new version, on the affected pages, is an early sign of a regression.

Source: https://escutaproduto.com/resources/feedback-volume-after-release
Last updated: 2026-10-11

## What window should you compare?

Pick a window of equal length on each side of the release. Seven days before and seven days after is a good default for most products, because it covers a full weekly cycle of customer behavior. Use the same length every time, so each release is measured the same way.

Compare by day as well as by total. A release that doubles bug reports on day two and returns to normal by day five looks very different from one that stays high for a week. The daily count shows the shape of the change, and the total only shows its size.

Plan the window before you ship. If the window is decided after the release, it is easy to pick dates that favor the story you want.

## How do you tag feedback with the release version?

Send the app version with each feedback item, so the export can split by release. Use setMetadata once the app loads, with the version your build already knows:

```js
window.EscutaProduto.setMetadata({ appVersion: "2.14.0" });
```

Call it on every page load, after the app starts, so each report carries the version it was sent from. If the widget script may not be ready yet, use the queue pattern in the [widget docs](/docs/widget), with setMetadata in place of identify. Keep the metadata small, because the limit is 4 KB, and do not put personal data in it.

The version then appears in the metadata column of the CSV export. A short helper formula pulls it into its own column, as explained in the [segmentation guide](/resources/segment-feedback-with-metadata).

## How do you read a before and after window?

Build a daily table with one row per day and one column per type. Count bugs, ideas and praise for each day in the window. Add a column for the version active that day, so you can see the switch from one release to the next.

Read the table in four passes:

1. Look at the baseline. Seven days of normal volume gives you a range, not a single number.
2. Find the first day above the range for bugs.
3. Check whether that rise is spread across pages or concentrated on one. Use the page_url column.
4. Confirm that the rise belongs to the new version, not to an older app still running in another browser.

Average rating and praise are useful companions. A release that raises bugs and lowers ratings at the same time is a stronger signal than either alone.

## How do you spot a regression early?

A regression is a bug that the new release introduces into something that worked before. Early detection depends on watching the bug signal by version and page, not waiting for the weekly review. Set a simple rule, such as: if bugs from the new version on any single page exceed the same page's normal daily count by a clear margin, someone looks at it the same day.

The rule should be written down before the release, so nobody argues about the threshold after a bad day. Keep it simple enough to check in a few minutes. Overly sensitive rules create noise, and noise teaches people to ignore the alert.

Also watch for silence. If a release is followed by almost no feedback, check that the widget still loads on the new version. A broken widget looks like good news.

## A worked example: a release with a spike on day two

For example, suppose the team ships version 2.14.0 on a Tuesday. In the seven days before, the product receives about 3 bug reports per day. On day two after the release, it receives 11, and 8 of them mention the export page. The version column shows that all 8 came from 2.14.0, and the page URL points to the same export screen.

The team reads the 8 reports, reproduces the failure on the export screen, and finds a change in how the file is named that breaks an import step on some systems. They ship a fix on day three. By day five, the daily count is back near 3, and the export reports stop. The release note records the regression and the fix, and the next release gets the same before and after check.

The example shows why the version tag matters. Without it, the spike looks like general noise and gets lost in the weekly total.

## What do you do when the spike is real?

Act on the signal in this order. First, confirm the failure with one or two reports. Second, decide whether to roll back, patch or wait, based on severity and how many customers the bug touches. Third, reply to the people who reported it, since they are waiting to hear that someone looked.

Then write the outcome in an internal note on the canonical report. Record the version, the page, the number of distinct customers and the date of the fix. Those notes make the next release check faster and show whether regressions are becoming more common.

The [frequency and severity guide](/resources/prioritize-bugs-frequency-severity) helps you decide how urgently to ship a patch, and the [weekly feedback review template](/resources/weekly-feedback-review-template) is where the release check can sit in the team routine.

## Tagging releases in Escuta Produto

Escuta Produto keeps the version in each item's metadata, so the release check works without extra tools. Set appVersion with setMetadata as shown above, then export the CSV after each release and split it by version. The inbox also filters by type and status, which helps you work the bug list while the spike is still happening.

When a fix ships, move the affected items to done and tell the people who reported them. The [guide to telling customers their request shipped](/resources/tell-customers-request-shipped) explains how to close the loop. For the full list of methods available to the widget, see the [widget docs](/docs/widget), and for the public submission endpoint, see the [REST API docs](/docs/api).

## Frequently asked questions

### How do you measure feedback volume before and after a release?

Pick a window of equal length before and after the ship date, such as seven days each side. Count bugs, ideas and praise per day, and compare the daily counts with the baseline before the release, not only the totals.

### How do you know a feedback spike comes from a release?

Tag each feedback item with the app version using setMetadata, then compare counts by version. If the spike comes from the new version and clusters on one page, it is a strong candidate for a regression.

### What counts as an early regression signal?

A sharp rise in bug reports from the new version, concentrated on a specific page, above the normal daily count for that page. Set the threshold before each release so the team acts on the same rule every time.

### What should you do if the feedback spike is real?

Reproduce the failure with one or two reports, decide whether to roll back, patch or wait based on severity, and reply to the customers who reported it. Record the version, page and fix date in an internal note for the next release.