# Build a Competitor Feature Matrix From Checked Public Evidence

Compare competitors without making up missing features by defining one buyer task, checking each vendor’s official sources, and recording what each source supports. Use a feature matrix: a table with buyer tasks as rows and products as columns. Mark evidence as documented, tested by you, or unknown. A search that finds no answer leaves a question open. It does not prove that a feature is unavailable.

Start with manual checks of official product pages and help pages. Use search to find those pages when needed. Your result should be a dated comparison table with source links, stated limits, and unresolved questions. Keep documented support separate from proof that a product works in your own setting.

## 1. Define the buyer task before searching

The supplied public buyer question asks how competitors handle software functions that a team also plans to build. This calls for a comparison of how a task works. A list of feature names will not answer that question. The public post gives useful context, but it does not establish how common the need is. [Public buyer question, published July 5, 2024; retrieved October 25, 2026; context only](https://www.reddit.com/r/ProductManagement/comments/1dw40o7/how_do_you_all_manage_competitor_research/).

Write one sentence that states the buyer’s task. Name the action and the required result. For example, a buyer might need to export a report as CSV. CSV means comma-separated values, a text format used to store table data. The buyer might also need a history of who approved a report. Those are separate requirements. Give each one its own row.

Before you search, record:

1. The buyer’s task and required result.
2. The named products you will compare.
3. The evidence needed to answer each requirement.
4. Any required plan, region, or software version.
5. The date of the comparison and a clear stopping point.

A plan is a product’s subscription level. A version identifies a particular software release. These conditions can affect whether a source answers your question. If you do not yet know a required condition, record it as unresolved.

Make each row narrow enough to check. “Reporting features” is too broad. “Official documentation names CSV as an export format” is a checkable criterion. Whether the exported file contains the buyer’s required columns is another criterion if that matters to the decision.

Fix this scope before collecting results. If a new requirement appears later, record the change and apply it to every product. Do not add a row only because one vendor describes it well.

This table compares evidence about buyer tasks. If you need to compare where competitor websites appear in search, use the separate method for a [fixed competitor query panel](/en/articles/web-localized-competitors/). Search position does not establish product capability.

## 2. Set clear evidence states

Define your evidence states before filling the table. Use the same rule for every product.

| Evidence state | What it means | What it does not establish |
| --- | --- | --- |
| Documented | Checked official text supports the exact criterion within its stated conditions | Successful use in the buyer’s setting |
| Tested by reader | You performed the stated test and saved its result and conditions | Support for other plans, versions, or tasks |
| Unknown | The checked evidence does not settle the criterion | A missing feature or a zero score |

Keep documentation evidence and test evidence in separate fields. A product can have both. When you add a test result, retain the official source that guided the test.

Use a short note to explain an unknown state. Useful notes include “format unclear,” “page could not be opened,” “plan unclear,” and “no checked source.” These notes explain the evidence gap. They are not extra product claims.

For example, a page that says “export reports” does not establish CSV export. It supports a broad export statement. The narrower CSV criterion remains unknown until a checked source names the format or your own test answers it.

If an official page states a limit, record that limit precisely. A restriction for one plan does not establish a restriction for every plan. Preserve words such as “only,” “except,” and “up to.” They can change the decision.

## 3. Check official pages first

Open each vendor’s official site and find the pages most closely tied to the buyer task. Useful candidates include help pages, product documentation, and plan pages. A primary source comes from the organization responsible for the product. It records that organization’s claim; it does not replace your own test.

Check that the page belongs to the intended vendor. A review site, reseller, or website with a similar name is a different source. Keep third-party comments separate from official product evidence.

For each relevant page:

1. Record the exact page address and the date you opened it.
2. Read the passage that addresses the criterion.
3. Save a short exact passage and its heading or section name.
4. Record the plan, region, version, and other conditions stated there.
5. Write a narrow evidence decision that the passage supports.

A search snippet is the short text shown with a search result. Treat it as a clue. Open the page before using it to support a matrix cell. The separate guide to [checking page passages before using them as evidence](/en/articles/web-agent-evidence/) explains that source check in more detail.

If the page shows no date or version, write “not stated.” Do not substitute the date you opened it. Your observation date tells the reader when you checked the page. It does not establish when the vendor wrote or changed it.

This method produces a dated comparison. It does not establish product release dates or changes over time.

## 4. Use a small search input to find candidate sources

You can complete the comparison through manual research. When you need help finding pages, the [Google Search Scraper](https://apify.com/chronometrica/google-search-scraper) has documented input and result fields that fit the discovery step. An Actor is a hosted data collection program. A Task is a saved input preset for an Actor.

The supplied evidence checked public default build 1.0.15 on October 25, 2026. Its schema, which defines the input structure and fields, declares the fields used below. A static check confirmed that this sample meets that schema. No Actor run occurred for this brief. The check does not prove live results, complete coverage, or successful collection. [Public default build, checked October 25, 2026; schema evidence only, no live run](https://api.apify.com/v2/acts/mlmVX4amk2biciJaB/builds/default).

Use this proposed small input:

```json
{"country":"US","engines":["google"],"language":"en","maxResultsPerExecutedQuery":3,"queries":["reporting software CSV export documentation"]}
```

4. Use a small search input to find candidate sources

A query is the text sent to a search engine. Replace the sample query with one named vendor and your actual buyer task. Keep the question narrow enough to find a relevant official page. Repeat the same research approach for each product.

The sample requests Google, country US, and language en. Keep those values only if they match your research scope. The result cap is 3 results per executed query. A cap limits the requested collection; it does not promise three results or complete coverage of relevant pages.

The public [Competitor SERP Research Task, checked October 25, 2026; page presence only](https://apify.com/chronometrica/google-search-scraper/examples/competitor-serp-research) was present with Task ID `Pjq0JLkzo0wHTcabU`. SERP means search engine results page. The Task is a possible starting point. Its current saved settings and runtime behavior were not verified. The sample above is a proposed replacement input, not a copy of verified saved settings.

Retain these declared result fields when you use search:

| Field | How to use it |
| --- | --- |
| `executedQuery` | Keep the exact query associated with the result |
| `engine` | Record the search engine reported for the row |
| `title` | Identify the candidate page |
| `canonicalUrl` | Keep the returned result address, then check the destination |
| `resultDomain` | Help identify the reported website domain |
| `snippet` | Find possible relevance; preserve a missing value |
| `isSponsored` | Keep the paid-result label visible |
| `rank` | Record the running position among parsed supported result blocks |
| `observedAt` | Record the search observation time |

These fields help trace how you found a source. They do not establish that the page supports your feature claim. Record the page check separately. Search rank is not a product quality score.

## 5. Save enough detail to support each cell

Use a summary matrix for reading and an evidence table for checking. A matrix cell can contain a state and an evidence reference. That reference should lead to the source passage and conditions.

Save the following fields in the evidence table:

| Saved field | What to record |
| --- | --- |
| Product | Exact vendor and product name |
| Buyer task | The action and required result |
| Criterion | The specific question this record answers |
| Evidence state | Documented, tested by reader, or unknown |
| Source URL | Exact official page address, or an explicit missing value |
| Page title and location | Title plus the relevant heading or section |
| Supporting passage | Short exact text, with conditions preserved |
| Page date or version | What the page states, or “not stated” |
| Observation date | When you actually checked the page |
| Plan and region | Stated conditions and unresolved matches |
| Scope note | What the passage supports and leaves open |
| Reader test | Not performed, or a reference to your test record |
| Unresolved question | The missing fact needed for the decision |
| Next action | A specific page check, test, or vendor question |

Keep the search reference beside the source record if search helped you find it. Keep each supporting page as a separate evidence record when several pages address one cell.

Do not fill missing fields with guessed values. “Version not stated” is different from version zero. “No test performed” is different from a failed test. “No checked source” is different from an official statement that a feature is unavailable.

Public pages can support public documentation claims. They do not reveal private account settings, internal approval records, or your own export results. If you perform an authorized account test, keep its account conditions and results in a separate test record. This brief contains no such records.

## 6. Match conditions before drawing a conclusion

Compare each source against the buyer’s actual needs. A page may document the right feature while leaving buyer fit unresolved.

Check these conditions for each product:

1. Does the page refer to the intended product?
2. Does it address the exact task and result?
3. Does the stated plan match the buyer’s plan?
4. Does the region match, where relevant?
5. Does the software version match, where relevant?
6. Does the passage state a limit that affects the task?

Do not assume a condition matches because the page says nothing about it. Record the missing condition and narrow your conclusion.

If two official pages appear to disagree, retain both. Note their dates, scope, and conditions. Mark the decision unresolved until a source check, vendor answer, or stated reader test resolves the issue. Do not select the more favorable passage without explaining the conflict.

When a test is needed, define the expected result before performing it. Save the steps, test date, environment, expected result, actual result, and evidence. A test supports only the task and conditions you checked. It does not establish that a product is better overall.

## 7. Work through an original fiction example

Original fiction teaching example. The products, buyer needs, and source descriptions below are invented. This is not an Actor run, customer result, or observed company finding. No reader test occurred.

The fictional buyer needs CSV export and approval history. Product A’s official help page documents CSV export. Product B’s marketing page mentions export but does not name the format. Product C has no checked source for the chosen task. None of these source descriptions answers the approval-history question.

Keep the two tasks separate:

| Buyer task | Product A | Product B | Product C |
| --- | --- | --- | --- |
| Export as CSV | Documented; help page describes CSV export | Unknown; export format unclear | Unknown; no checked source |
| View approval history | Unknown; no supporting passage supplied | Unknown; no supporting passage supplied | Unknown; no checked source |

The example contains three products and two buyer tasks:

3 products × 2 buyer tasks per product = 6 comparison cells.

1 documented cell + 5 unknown cells = 6 comparison cells.

0 reader tests were performed. Zero is valid for that test count because the example explicitly states that no tests occurred. The five unknown cells are missing evidence. They are not five absent features and must not become five zero scores.

Product A’s CSV cell supports a narrow statement: its fictional official help page documents CSV export. The supplied fiction gives no plan, region, version, exact passage, or page address. Those fields remain unresolved. Do not invent them to make the evidence record look complete.

Product B’s page supports the broad statement that export is mentioned. It does not answer the CSV question. Product C’s gap says only that no source has been checked. It does not establish whether CSV export exists.

The next questions follow from those gaps:

| Product | Next evidence question |
| --- | --- |
| A | What conditions apply to documented CSV export, and what source addresses approval history? |
| B | Which export formats does the product document? |
| C | Which official page addresses either buyer task? |

You cannot rank these products for the full workflow from this table. You can identify the next checks needed to make that decision.

## 8. Check gaps and failure states before sharing

Read every cell against its source record. Confirm that a reader can follow each documented claim to an official page and a relevant passage.

Use clear failure states:

| Situation | Record | Decision limit |
| --- | --- | --- |
| Search returns no useful page | Unknown; no useful source found | Do not infer feature absence |
| A candidate page cannot be opened | Unknown; page unavailable for checking | Do not use its snippet as proof |
| The page describes only a broader function | Unknown for the narrower criterion | Keep the broader statement separate |
| A required condition is missing | Condition unresolved | Do not claim buyer fit |
| Official pages conflict | Conflict unresolved | Retain both sources |
| No reader test occurred | Not tested | Do not imply hands-on results |

Keep search collection problems separate from product findings. An empty or incomplete collection does not show that a vendor lacks a feature.

Review the summary wording too. “We found documentation for this task” is narrower than “this product meets all our needs.” A documented feature is not proof of tested superiority. Use the matrix to state what you know, what remains open, and which gap affects the next decision.

## Choose one next check

Start with the unresolved question that most affects the buyer’s choice. Check one official page, ask the vendor one precise question, or propose one small account test. State the expected evidence before taking that action. A proposed test remains proposed until you perform it and save the result.

Use the [Google Search Scraper](https://apify.com/chronometrica/google-search-scraper) when you need help finding candidate pages. Begin with the small replacement input above. Then open the relevant official source and complete its evidence record. Share the dated matrix with its unresolved questions so the next decision rests on checked evidence.

## Sources

- [Google Search Scraper public default build 1.0.15, checked October 25, 2026; declared fields and static validation only, no live collection](https://api.apify.com/v2/acts/mlmVX4amk2biciJaB/builds/default)
- [Competitor SERP Research Task, checked October 25, 2026; public page and exact Task ID confirmed, saved settings and runtime unverified](https://apify.com/chronometrica/google-search-scraper/examples/competitor-serp-research)
- [Public competitor-research question, published July 5, 2024; retrieved October 25, 2026; buyer context only, not demand or product evidence](https://www.reddit.com/r/ProductManagement/comments/1dw40o7/how_do_you_all_manage_competitor_research/)