Referer Parser Laravel Package

Product Decisions This Supports

• Acquisition attribution: Classify signup, lead, and checkout referrers into channels such as organic search, social, referral, and direct when UTMs are missing or inconsistent.
• Roadmap prioritization: Use cleaner source/medium data to decide which acquisition channels, content, or partner programs deserve investment.
• Build vs. buy: For a Laravel/PHP product, buying a small parser via Composer is usually cheaper than maintaining search-engine/social-domain regexes and referrer edge cases in-house.
• Feature scoping: Decide whether to expose inferred attribution alongside “How did you hear about us?” and whether to store raw referrer strings plus normalized fields.
• Data quality: Normalize messy referrer data before it reaches CRM, analytics, or warehouse tables; reduce manual marketing reporting cleanup.
• Attribution model support: Provide a parsing primitive for first-touch/last-touch reporting, partner dashboards, and self-serve acquisition analytics—without pretending it is a full attribution platform.
• Risk management: Keep expectations narrow: server-side referrer parsing cannot replace consent management, cross-device identity, ad-click IDs, or warehouse-native attribution.

When to Consider This Package

• Your Laravel/PHP backend needs server-side enrichment of the HTTP Referer header at registration, lead capture, or purchase events.
• You want a small, focused parser for common search/social/referral sources and can wrap it behind your own service interface.
• You can store both the raw referrer and the parsed output, and you have privacy/consent handling in place.
• You accept that the package is a utility, not a Laravel-native attribution suite; integration, testing, and taxonomy gaps remain your responsibility.
• You should look elsewhere if attribution is a core differentiator, or if you need multi-touch modeling, ad-platform click IDs, consent-aware tracking, identity resolution, cross-device stitching, or warehouse-native reporting.
• Do a dependency review before adoption: confirm license, security posture, release cadence, maintainer responsiveness, and coverage for your important referrers. If the repository/source is unclear, treat it as a procurement and maintenance risk.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, narrow utility that improves acquisition reporting with less engineering. It helps us infer which channels drive signups and revenue when UTMs are missing, so we can make better GTM and roadmap bets. It is not a full attribution platform; we should scope it as server-side enrichment and keep the raw data for auditability.

For engineering: Add it as a Composer dependency, isolate it behind an adapter/service, and store raw referrer plus parsed source/medium/channel fields. There is no Laravel-specific API, so keep the integration thin, test top referrers, and fall back to “unknown/direct” when parsing is ambiguous. Validate license, security, and maintenance before committing.

Decision: Pilot it on one or two acquisition flows, compare parsed output against existing analytics/UTM data, and adopt only if it measurably reduces manual classification and improves channel reporting.