Product capabilities
Filtering by Device, Browser, and Operating System
Client filters are most reliable when they enforce a real compatibility boundary and preserve an outcome for unknown or conflicting fingerprints.
Tie each filter to a campaign requirement
A mobile-only creative, unsupported operating system, or destination compatibility limit can justify an explicit boundary. Avoid adding demographic or intent assumptions that the device family and browser name cannot substantiate.
Client identification is an interpretation
User-agent strings, client hints, feature observations, and embedded-app markers can disagree or be modified. Parsers also need updates as vendors release new versions and reduce identifying detail for privacy.
Make unknown clients a designed case
New browsers, bots, unusual devices, and stripped headers should not fall through an accidental default. Choose a conservative response and capture enough context to decide later whether the classifier or policy needs adjustment.
Validate combinations rather than isolated labels
A reported desktop operating system with a touch-first embedded browser may be inconsistent, but one strange field is not conclusive. Review device, browser, OS, screen behavior, source path, and network evidence together when the stakes justify it.
Build a representative client matrix
Test supported phones and desktops, major browsers, in-app WebViews, outdated clients, spoofed headers, and absent client hints. Verify both the parsed fields and the final destination so a correct label with incorrect rule precedence is not overlooked.