Device Detector Laravel Package

Product Decisions This Supports

• Segmentation and cohort analysis. Device class (mobile, tablet, desktop, TV, console, wearable, smart speaker), OS + version, browser + version, brand/model become first-class dimensions on sessions/events. This is what lets you answer "did mobile conversion drop because of iOS 18 or because of our new checkout?" instead of shipping a pooled average that hides platform regressions.
• Bot and crawler filtering. isBot() (or the standalone BotParser as a fast path) is a data-integrity decision, not a nice-to-have: cleaner funnels, fewer phantom signups, referral-spam and scraper signals, affiliate/ad fraud checks, and a cheap input to rate-limiting and abuse rules.
• Experience adaptation and routing. Server-side decisions like serving a lighter bundle to dated browsers, disabling features that need APIs the client lacks, redirecting TV/console clients to a 10-foot UI, and — a frequent revenue bug — detecting in-app webviews (Instagram/Facebook) that break OAuth and prompting "open in Safari/Chrome" instead of showing an error.
• Support and CS triage. Attach parsed client/OS/device to error reports and tickets. Cuts the "what browser are you on?" round-trip and lets you rank bug fixes by the OS/browser versions that actually generate them.
• Packaging, entitlement, and pricing. Device-class-based plan tiers, per-device seat counting, and platform-specific upgrade prompts ("you're on mobile — get the app").
• Feature gating by capability. OS-family and browser-family checks for WebAuthn, push, WebRTC, and other API-dependent features, rather than ad-hoc string matching scattered across controllers.
• Build vs buy for the roadmap. The strongest argument for adoption: UA/bot data is a permanently maintained regex + dataset treadmill with near-zero differentiation. Buying (adopting) it frees engineering capacity for product work and removes a recurring "our sniffing broke again" incident class.
• Experimentation guardrails. Platform as an orthogonal dimension in A/B analysis, so you can catch that a win on desktop is a loss on mobile before rollout.

When to Consider This Package

Adopt when:

• You need detection server-side, where no browser JS runs: SSR/SEO output, server redirects, email open/click tracking, API request shaping, log enrichment, webhook and fraud checks.
• You need breadth, not precision. Hundreds of OSes, thousands of browsers, thousands of bots, plus TV/console/wearable classes — exactly where homegrown sniffing collapses.
• Bot detection is a first-class output, not a byproduct of a strpos($ua, 'bot') guess.
• You can cache. Parse once per session/request and memoize. This is the package's own guidance: the LaravelCache bridge, PSR-6/PSR-16 bridges, or APCu/Redis. Bind as a singleton; keep parsing at ingestion or middleware rather than inline at render.
• LGPL v3 is acceptable in your deployment model — normally fine for server-side use; confirm with legal if you distribute the code to customers.
• You need Client Hints support. As Chrome and Safari freeze and reduce UA strings, ClientHints::factory() plus an Accept-CH header is the forward-looking path; picking a library without it means re-platforming in ~18 months.

Look elsewhere or hedge when:

• You need hardware-grade accuracy across the Android long tail (exact model, specs, screen class). Commercial datasets — DeviceAtlas, 51Degrees, WURFL — win here. This library is community-maintained regex data; new-device coverage lags weeks to months.
• You need an SLA, indemnity, or audited accuracy benchmarks. Open source offers none of these.
• Latency budget is razor thin and you cannot cache. Use the narrow parsers (bot-only) or precompute at ingestion instead of parsing on the hot path.
• A single isMobile boolean suffices. CSS media queries or browser-side navigator.userAgentData are cheaper.
• Your stack isn't PHP. Use a maintained port (Go, Node, Python, Ruby, Java, Rust all exist) so the data definitions stay aligned with upstream.

How to Pitch It (Stakeholders)

To executives: "We stop guessing who's on the other side of the request. One mature, free library, maintained by the Matomo team, returns device class, OS, browser, brand/model, and whether we're talking to a bot — server-side, with no third-party API bill, no data leaving our infrastructure, and no vendor contract. It replaces brittle UA string-matching code that breaks every few months, and it unlocks segment-level reporting, bot-filtered metrics, device-aware UX, faster support triage, and device-based packaging decisions. Cost is hours, not a quarter. The one real risk is accuracy on the long tail of cheap Android devices, mitigated by caching results and treating device data as a segmentation input rather than a hard gate on anything a customer pays for."

To engineering: "Composer require, LGPL v3, PHP-native, no service to operate. Feed it $request->userAgent() and Client Hints via ClientHints::factory($_SERVER) once we advertise Accept-CH. Bind a singleton, wire the LaravelCache bridge to Redis or APCu so repeated UAs don't re-run regexes, and persist normalized columns — device_type, os_family, browser_family, brand, is_bot — on our sessions/events tables. Then reporting is an index scan instead of a parse per query. Keep enrichment off the critical render path: parse at ingestion or in middleware and pass the result down. It's the engine behind Matomo's own analytics, with PHPUnit coverage and PHPStan/PHPCS-clean CI, so the maintenance tail is small. Don't fork the regex data — consume upstream releases on a schedule, and set version truncation deliberately so we don't store version strings we never query."