Tracking Code Manager Laravel Package

Product Decisions This Supports

• Analytics and marketing instrumentation on Statamic sites: This package manages tracking codes (e.g., analytics, pixels, tag managers) for Statamic-powered sites, removing the need to hand-edit templates or rely on a separate tag manager. It supports decisions like "standardize how marketing tags are injected across all content-managed sites."
• Build vs. buy for tag management: If the team is weighing a third-party tag manager (GTM, Segment) against a lightweight native solution, this package is a candidate for the "buy less, configure in-repo" option — relevant when tag requirements are simple and privacy/consent control matters.
• Roadmap scoping for Statamic vs. Laravel-only properties: The v1.0.2 fix is explicitly Statamic 4 compatibility. If the roadmap includes upgrading Statamic (3→4), this release unblocks that migration for any property dependent on tracking code injection.
• Control panel access and permissions design: The middleware fix in cp.php routes indicates the package's control panel surface is being aligned with Statamic's expected middleware stack — relevant if the team has opinions about who in the org can edit tracking codes and how that's gated.

When to Consider This Package

Consider it when:

• The site runs Statamic (this release specifically targets Statamic 4 — verify your version before adopting).
• Tracking requirements are moderate and declarative — a managed set of codes per site/environment rather than complex event orchestration, server-side tagging, or audience segmentation.
• You want tagging editable by non-engineers through the control panel without a deploy, but without adding a third-party script manager and its consent/data-residency implications.
• You are already upgrading to Statamic 4 and need a tracking solution whose CP routes work correctly under the new middleware expectations.

Look elsewhere when:

• You need consent management, server-side tagging, or vendor-agnostic event pipelines — that is a different product category.
• The site is Laravel-only, not Statamic — the recent work is Statamic-specific; the value proposition and support surface center on that ecosystem.
• You require published security posture, an audit trail, or a formal support SLA — this is a small, young package (v1.0.2, first external contributor), so evaluate maintainer capacity and bus factor before depending on it for revenue-critical instrumentation.
• You need Statamic 5+ support or a documented compatibility matrix — confirm explicitly rather than assuming forward compatibility.

How to Pitch It (Stakeholders)

To executives: This is a small, focused add-on that lets marketing and analytics tags be managed from the CMS control panel instead of through code changes and releases. The practical value is faster tag changes without engineering cycles and fewer deploy risks for marketing instrumentation. The v1.0.2 release is a compatibility fix that keeps the tool working through a Statamic 4 upgrade — low risk, no data-model or breaking changes. Caveat for decision-makers: it is an early-stage, single-maintainer package, so treat it as a convenience layer rather than infrastructure, and keep an exit path (the tags remain plain configuration you can migrate).

To engineering: v1.0.2 corrects middleware on the control panel routes so they match Statamic 4's expected stack — this resolves CP access issues introduced by the version bump. No API or schema changes, so upgrade should be a drop-in patch from v1.0.1. Because the fix touches route middleware, sanity-check CP permissions after upgrading: confirm that only intended roles can create or edit tracking codes, since that surface governs what scripts execute on production pages. Worth noting the package has just gained its first outside contributor — a positive signal for sustainability, but still a small maintainer base; pin the version and review changelogs on each bump.