How to find duplicate bug reports by page URL

Why is the page URL the best first key for bugs?

Customers describe the same broken thing in very different words. One writes "checkout froze," another writes "pay button does nothing," and a third writes "stuck on step 3." The page URL does not vary with the wording. When the widget sends a report, it saves the page the customer was on, so two reports from the same broken page are strong candidates for being the same bug.

URL matching is not proof. It narrows the list so you read fewer messages. Then you decide, by reading, whether two reports describe the same failure.

How do you sort the export by page URL?

1. Export the product's feedback as CSV from the inbox.
2. Filter the kind column to bug. Ideas and praise do not need this pass.
3. Add a helper column that normalizes the URL. Query strings such as ?step=2 and trailing slashes often make one page look like many. In Google Sheets, =LOWER(REGEXREPLACE(G2,"\?.*$","")) removes the query string and lowercases the address, where G is the page_url column.
4. Sort by the helper column, so reports from the same page sit next to each other.
5. Add a count column with =COUNTIF($H:$H,H2), where H is the helper column, so you can see which pages attract the most bug reports.

If your site uses language prefixes, such as /en/ and /pt/ for the same page, add a second replacement to strip the prefix. Decide the rule once and keep it the same in every export.

How do you group near-identical reports?

Within each page group, read the messages and split them into clusters. Two reports belong together when they describe the same symptom, not just the same page. A page with five reports can hold two bugs: one about a slow load and one about a button that does nothing.

For each cluster, pick a canonical report. Choose the one with the clearest steps, the most useful browser details, and a reachable email address. Then check the others against it. A useful test is whether a developer who reads only the canonical report could reproduce the bug.

For example, suppose the checkout page has 7 bug reports in one week. Five describe the pay button doing nothing on Safari. Two describe a discount code that fails. You have two clusters, not one, and each needs its own canonical report.

How do you link duplicates without a merge button?

Escuta Produto does not merge feedback. Use internal notes instead, which are private to your team:

• On the canonical report, add a note such as "Canonical for the Safari pay button bug. Four more reports point here."
• On each duplicate, add a note such as "Duplicate of the Safari pay button report from the same week."
• Set the duplicate's status to closed only after you have confirmed the fix or decided not to act, so the status keeps its meaning.
• Keep the canonical report in progress or planned while the work is open.

Searching by text helps find the duplicates the URL missed. Search the inbox for a distinctive word from the canonical report, such as the name of a button or an error code, and read the matches.

What counts as a real duplicate?

A duplicate shares the page and the failure. Same page and different failures are two bugs. Different pages and the same failure can also be one bug, for example when a shared component breaks across many pages. Note those cases separately, because the fix is in the component, not in each page.

Reports that are merely similar in mood, such as "this is annoying," are not duplicates. They are signal about experience, and they belong in the ideas or praise pass.

A useful habit is to write the canonical report's symptom as one sentence, such as "pay button does nothing on Safari when the cart holds two items." Read each candidate against that sentence. If the candidate matches it, the candidate is a duplicate. If it matches only part of it, the candidate may be a second bug on the same page, which deserves its own canonical report. A short sentence also makes the test quick to repeat when next week's reports arrive.

When is a cluster big enough to fix first?

Count distinct customers, not reports. One person who sends three reports is one affected customer. Use the email field where it is filled in, and the notes where a customer identifies themselves. Combine that count with severity: a single report of data loss can outrank a cluster of cosmetic reports. The frequency and severity guide sets out a simple grid for this.

Finding page URL duplicates in Escuta Produto

1. Make sure the widget is installed with the page URL saved by default. The widget docs explain the setup, and the REST API docs cover the pageUrl field if you send feedback from your own code.
2. Export the CSV at the start of each triage session and run the steps above. The spreadsheet analysis guide shows the basic columns.
3. Write each decision as an internal note on the canonical report, so the next person can see why the duplicates were closed.
4. Use the same approach for ideas, but there the grouping key is the request rather than the URL. The deduplicating feature requests guide covers that case.