Agent Detection Laravel Package

Product Decisions This Supports

This package answers a narrow but recurring product question: "What is this request coming from, and should the experience differ because of it?" It exposes user-agent details — mobile vs. desktop, Android vs. iOS, and whether the caller is a bot/crawler/spider — behind a simple Composer-installable Laravel-friendly API.

Concrete decisions it can inform:

• Device-appropriate acquisition funnels. Show a smart app-install banner or deep-link only to mobile web visitors; keep desktop users on the web purchase flow. Measure install-attempt and hand-off rates by device class.
• OS-specific onboarding and menus. Differentiate feature sets, navigation, or payment options for iOS vs. Android vs. desktop, and A/B test whether that differentiation improves activation.
• Bot hygiene in product analytics. Exclude crawlers and spiders from funnel and conversion metrics so dashboards reflect real humans; route bot traffic to a separate log stream.
• Bot-aware edge behavior. Cheap first-pass signal for rate limiting, blocking aggressive scrapers, or serving cache-friendly responses to crawlers. Treat this as one input among several, never as the security control.
• Roadmap / build-vs-buy. A useful benchmark for "should we maintain our own UA parsing?" — the build cost is low (a few regexes), so the real decision is whether breadth of patterns and ongoing upkeep are worth an external dependency.
• Support and QA triage. Tag inbound bug reports or support tickets with device/agent context to spot device-specific regressions faster.

What this release actually tells us: v1.7.0's notes are essentially a README restatement — no changelog, no migration notes, no breaking-change markers, no stated pattern-database updates. Treat the version bump as iteration on packaging and documentation rather than a substantiated capability change, and validate the actual detection surface against real traffic before betting roadmap on it.

When to Consider This Package

Adopt it when most of the following hold:

• You need coarse-grained, boolean-level answers — "is this mobile?", "is this iOS?", "is this a bot?" — not a rich device taxonomy.
• You want a small, MIT-licensed, zero-infrastructure dependency with no external API calls, no database, and no license server.
• Your use case is progressive enhancement: personalization, copy/menu variants, analytics filtering. A wrong answer degrades an experience slightly; it does not break checkout or leak data.
• You can wrap it behind an internal interface (e.g. DeviceContext) so the vendor choice is swappable.
• You are comfortable pinning the version and reviewing diffs yourself, given the apparent single-maintainer profile and thin release documentation.

Look elsewhere — or build the three regexes yourself — when:

• You need high-accuracy device or bot classification. UA-string parsing is heuristic and trivially spoofed; for real bot mitigation use a WAF, signed requests, behavioral signals, or a maintained reputation feed.
• You need maintained pattern coverage across long-tail devices. Matomo's device-detector, Browscap, or 51Degrees/WURFL-class data sets are the appropriate comparison, and the trade-off is size and update cadence.
• Your traffic is Chrome-dominated and modern. User-Agent Client Hints (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform) plus client-side feature detection and CSS media queries are the more durable mechanism; server-side UA parsing is increasingly a fallback.
• You are considering serving different content to crawlers for SEO. That is cloaking territory — get legal/SEO sign-off before shipping, regardless of library.
• You also need intrusive mobile app interstitials. Search engines penalize intrusive install prompts; the package makes the targeting easy, not the policy.

Non-negotiable pairing: responsive design first, this package second. Device detection should select variants, not replace a layout that already adapts.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can ship device- and OS-aware experiences — targeted app-install prompts, tailored onboarding, desktop-vs-mobile menus — for roughly the cost of a Composer dependency. It is MIT-licensed, runs in-process with no vendor contract, no third-party API, and no data leaving our infrastructure, so privacy and procurement review are light. The same capability lets us filter bot traffic out of product analytics, which improves the trustworthiness of numbers we already report on. The honest framing: this is a small, fast, low-cost optimization lever, not a platform investment, and it carries single-maintainer dependency risk that we contain by wrapping it behind our own interface and pinning the version.

To engineering (the ask): Install rmunate/agent-detection, then immediately hide it behind a thin DeviceContext abstraction with three or four methods (isMobile, isIOS, isAndroid, isBot). Add contract tests with a fixture corpus of real and adversarial UA strings, plus fallbacks for empty or malformed headers. Log detected agent class alongside existing request telemetry for one sprint before any UX depends on it, so we can measure false-positive/negative rates on our actual traffic. Keep the abstraction swappable to Matomo device-detector or Client Hints — that is our exit ramp and our argument for why this dependency is low-risk. Do not use it as an authorization or rate-limiting control. Pin the version, watch upstream releases, and re-review when the changelog becomes substantive.

Success measures: lift in mobile-to-app hand-off rate, conversion delta on OS-specific flows, reduction in bot contamination of funnel metrics, and zero incidents attributable to misclassification.