A spreadsheet full of browser names is not a compatibility strategy. The useful unit is a journey: sign in, search, upload a file, complete checkout, play media, publish a post, or return from an external provider. Each journey needs a small set of browser and container rows that protect a real user or a known product risk. The matrix is best understood as a queue for decisions, not a catalogue of every browser ever shipped.

Give each row a job

An illustrative row can be explicit about why it exists:

journey: publish community post
target: Android WebView, Chromium major 124+
risk: callback or file hand-off may fail
evidence: two support reports plus current WebView traffic
expected: approved post confirmation is visible after submit
owner: community QA
last_run: 2026-07-08

The target is meaningful because it names a journey and an expected result. A row that only says “Android WebView” is a label without a test contract.

Select targets from evidence

Include current stable browsers, one older supported version when the business requires it, mobile Safari, Android Chrome, Android WebView, and enterprise browsers that appear in real logs. Do not add a combination because a generic browser list says it is popular. Add it because it protects a supported customer, represents a measured traffic segment, or covers a known risk.

Separate frequency from severity. A low-volume browser can deserve a row if it blocks account recovery. A high-volume browser can have a low-risk row if only an optional animation differs. The matrix should make that trade-off visible to product and QA instead of hiding it in a priority column nobody reads.

Tie the row to a minimal reproduction

Every failing row should link to steps that another engineer can run: URL, account state, data fixture, action sequence, and expected result. Keep private credentials out of the matrix. Use a seeded test account or a local fixture, and describe any third-party hand-off that needs a controlled environment.

When the failure is a User-Agent classification issue, include the sample and parser output beside the journey. When it is a WebView issue, include the host app and callback step. When it is a Safari issue, include the container and viewport. The matrix is where the abstract browser label becomes a reproducible product question.

Review the queue, not just the grid

Set a review cadence that follows product risk rather than a ritual date. A release that changes login, payment, or file handling should trigger a focused review. A browser release that changes only a token may update reference fixtures without expanding the full matrix.

At review time, delete rows that no longer protect a user, merge duplicate coverage, add a row when traffic or an incident changes the risk, and mark the last meaningful run. A stale row creates false confidence because it looks complete while nobody can say whether the journey still works.

Share the decision with the right teams

Support needs a plain-language outcome and fallback. QA needs the reproducible steps. Analytics needs the population and scope behind the target. Product needs the impact and cost of supporting it. Keep those links in the row so the matrix remains a working agreement rather than a QA-only spreadsheet.

Put failure evidence beside the row

When a row fails, attach the smallest useful evidence: the route, step, expected result, observed result, browser context, and last successful checkpoint. For a community post, that might be submit, response, moderation state, and visible confirmation. For checkout, it might be the external return and the cookie or message result. This makes the row useful to support and product, not just to the person who ran the test.

Use a severity field that describes user consequence. A low-volume browser that cannot recover an account should outrank a high-volume browser with a cosmetic difference. Include a confidence field for traffic evidence and a last-run date for the reproduction. An old green result should not outweigh a recent support report without a review note.

Keep the matrix small enough to run

Count the rows per journey and remove combinations that do not change a decision. If two browsers share the same engine, container, and risk for a flow, one representative fixture may be enough, while a separate row remains justified for a different storage or hand-off policy. Record why a row was merged so it can be restored when traffic or an incident changes.

The matrix should answer what the team will do next: fix the journey, document a limitation, add a fallback, or gather missing evidence. A larger grid is not automatically more responsible coverage. It can simply make stale assumptions harder to notice.

Our preferred matrix is smaller than the browser universe and more detailed about the journeys that matter. Each row answers three questions: who is protected, what can fail, and how can another engineer reproduce it? That is enough to turn compatibility work into a visible sequence of decisions.