Why Two Parsers Disagree About One String

Feed one string to two parser libraries and the answers often differ. The disagreements are systematic rather than random, and each cause has a different remedy.

Dataset age is the largest factor

A parser recognises what its rules describe. A string from a product released after the dataset was assembled falls through to whatever general rule matches.

Because strings inherit tokens, that fallback is usually plausible rather than obviously wrong. A new browser is reported as the mainstream product it derives from.

Comparing two parsers with different dataset dates therefore compares two snapshots of the ecosystem, not two parsing algorithms.

Definitions of the fields differ

Parsers do not agree on what a device name, browser name or platform should contain. One may report a marketing name, another a model code, another a family.

None is wrong. They serve different consumers, and a parser aimed at analytics naturally groups differently from one aimed at asset selection.

Comparing outputs field by field without normalising these definitions produces disagreement counts that overstate the real divergence.

Rule ordering resolves ambiguity differently

When several rules match a string, ordering decides. Two libraries with equivalent rules in different order return different answers for the ambiguous cases.

Ambiguity is common because derivative browsers deliberately include their parent's tokens. Almost every string in those families is matched by more than one rule.

The disagreement is therefore concentrated in derivative products rather than spread evenly across traffic.

Unknown handling varies

Some parsers return an empty result for an unrecognised string. Others return the closest general match, and some return a partial result with fields missing.

Downstream code treats these very differently. An empty result is visible in reporting; a plausible general match disappears into the totals.

Preferring explicit unknowns makes coverage gaps measurable, which is usually worth more than the extra rows of unclassified traffic.

Reconciling for a specific purpose

The right parser depends on the decision being made. Asset selection needs accurate device classes; analytics needs stable groupings; log analysis needs speed and explicit unknowns.

Running two parsers and comparing is useful once, as a way to size the disagreement and see where it clusters. Running both permanently doubles maintenance for little benefit.

What matters most is choosing one, recording its version alongside the output, and being able to explain any shift in reporting after an update.