Utm Cookie Bundle Laravel Package

Product Decisions This Supports

• Attribution for acquisition spend: UTM capture is the plumbing that lets you answer "which campaign produced this signup/order?" Without it, paid channels get credit by guesswork and budget reallocation is anecdotal.
• Feature scoping — lead/order source fields: Informs whether to add utm_source, utm_medium, utm_campaign, utm_term, utm_content (plus landing page and timestamp) to user, lead, and order models, and whether those fields ship in v1 or behind a flag.
• Build vs. buy vs. borrow: This package's entire value is "parse query string → write cookie → read it back later." That is a middleware plus a helper — roughly 50–150 lines. The decision is not "adopt a dependency," it's "adopt a pattern." Evaluate against: (a) internal middleware, (b) an existing tag manager / CDP (GTM server-side, Segment, RudderStack, Matomo) already in the stack.
• First-touch vs. last-touch policy: Cookie persistence forces an explicit product decision about whether you overwrite on each visit or preserve the original source. This package sits in that decision space and should be tuned, not accepted as-is.
• Roadmap candidates it unlocks: campaign performance dashboards, affiliate/partner referral tracking, landing-page A/B cohort tagging (UTM as cohort key), CRM lead-source sync for B2B sales routing, and payback-period modeling per channel.
• Stack-fit caveat that changes the decision: despite the framing, this is a Symfony bundle (tattali is a Symfony author; bundle + DI + config semantics). On a Laravel codebase the honest decision is "reimplement in a Laravel middleware," using this repo as a reference spec.

When to Consider This Package

Consider it when:

• The application is Symfony, and you want cookie-based UTM persistence configured via bundle config rather than hand-rolled.
• You need something deliberately lightweight: capture on request, read on conversion, no event pipeline, no warehouse, no identity graph.
• You want a readable reference implementation to fork or port — the surface is small enough to audit in an afternoon.
• Timeline is tight and you want a working capture path this sprint, behind a feature flag, with intent to replace or own the fork.

Look elsewhere / do not adopt as a dependency when:

• Adoption signal is nil: 0 stars, 0 dependents. No community, no external bug reports, no third-party validation. Treat maintenance as your responsibility from day one; assume you will vendor or fork.
• No Laravel-native integration: no service provider, no middleware alias, no facade. A Laravel team pays an integration tax for a Symfony-shaped package.
• Consent is unresolved: UTM cookies are marketing cookies under GDPR/ePrivacy in the EU/UK. Capture must be gated on consent state, with a lawful basis recorded. If your consent management platform isn't wired up, this package makes the compliance gap more visible, not less.
• You need configurability the package likely doesn't expose: cookie TTL, domain/subdomain scope, SameSite, Secure, HttpOnly, cookie-name versioning, size limits (five UTMs plus landing page and referrer can push past comfortable limits), and PII hygiene in query strings.
• Architecture doesn't have a persistent cookie jar: pure API / mobile / SPA-with-token-auth flows need server-side session or a first-party identity service instead.
• You already have server-side tagging or a CDP — don't run two attribution sources of truth.
• Release metadata looks anomalous (a 2026-dated release on a 0-star repo). Verify the tag actually exists, that it installs, that PHP/Symfony constraints match yours, and that the code is what the description claims before it touches a production dependency tree.

Minimum due diligence before any adoption: read every source file, confirm test presence, check PHP and framework version constraints, confirm no network calls or telemetry, and confirm the cookie write path honors consent.

How to Pitch It (Stakeholders)

For executives (30 seconds): We lose attribution the moment a visitor navigates past the landing page — campaign parameters vanish from the URL, so the signup that follows can't be traced to the ad that paid for it. This package is a small, MIT-licensed helper that captures those parameters into a cookie and hands them back at conversion time. It is cheap to evaluate and cheap to replace. The real recommendation is not "buy a tool," it's "close the attribution gap this quarter." The pattern is a half-day of engineering; we should own it either way rather than depend on an unmaintained package.

For engineering: The scope is a request middleware that parses UTM query params, writes a scoped/SameSite/Secure cookie with a defined TTL and first-touch-vs-last-touch rule, and a small accessor to read values at conversion. This repo is Symfony-shaped and has zero external adoption, so treat it as a spec, not a dependency: port the logic to a Laravel middleware (or a Symfony service if that's the stack), add tests for param parsing, overwrite policy, expiry, and consent gating, and keep the cookie name versioned so we can migrate later. Estimated effort: 1–2 days including tests and consent integration.

Recommendation: Run a one-day spike. If the stack is Symfony and the code audits clean, vendor a fork under our namespace. If the stack is Laravel, skip the dependency and implement the middleware directly. Either way, ship behind a feature flag, gate on consent, and route the captured values into the lead/order record so the data is queryable — a cookie nobody reads is not attribution.