Gtm Laravel Package

Product Decisions This Supports

• Build vs. buy for tag rendering. The real question is not "should we adopt a five-star package" but "do we keep hand-copying GTM snippet HTML into every Blade layout, or standardise on one auditable component with a published config?" Standardising is the cheaper path and it retires a recurring decision: the rendering layer stops being renegotiated per feature. It frees product judgement for the layer that actually needs it — event schemas, data-layer contracts, consent.
• Tracking policy as a reviewable artefact. The two-key model — a tag renders only when the per-component enabled prop and gtm.enabled config are both true — encodes "on in production, dark in local/CI/staging" in configuration rather than in layout conditionals. That is the PM-relevant property: tracking state shows up in a diff and applies consistently across app, admin, and Filament surfaces without per-template negotiation.
• Reporting integrity as a decision input. v2.0.1 fixes x-gtm::no-script, which read config('site.gtm.id') while the package publishes config/gtm.php — no site namespace exists — so the noscript iframe emitted an empty container ID and reported nothing. Any dashboard, funnel, or audience-size figure that assumed "GTM sees all sessions" was quietly overstated in coverage for the no-JS segment. Historical "no-JS share of sessions" is an artefact of a broken tag, not a measurement, and should not inform channel-mix, capacity, or funnel-completion decisions.
• Roadmap sequencing. The fix is a patch with no API change, so "restore noscript tracking" is a maintenance ticket, not a project. Capacity stays with the analytics work that genuinely needs product judgement — event taxonomy, SPA page_view pushes, consent gating — none of which this package addresses.
• Bus factor and self-service. The new docs/, including an explicit statement of the two-level enable rule, reduces dependence on whoever originally wired up tag management. That informs staffing ("can a generalist engineer add a tag?" vs. "do we need a dedicated analytics engineer?") and shortens the debugging path for the most common support question: why does this page render no GTM markup?
• Verification maturity as a procurement signal. The pre-2.0.1 suite rendered both components together and asserted the container ID appeared somewhere in the output — the healthy script tag satisfied that on its own while the inert iframe passed beside it. That is a false-positive test, not a missing one. v2.0.1 replaces it with per-component assertions plus a full matrix over enabled prop × gtm.enabled config. Useful when deciding whether to certify the dependency for anything load-bearing.

Explicitly not supported: event schemas, data-layer validation, server-side tagging, SPA route-change pushes, and consent capture or enforcement. If the product question is what we track and how we guarantee it fires, this is the wrong level of abstraction — it renders tags, it does not define them.

When to Consider This Package

Adopt when:

• You are on Laravel with Blade layouts and want GTM injected without duplicating snippet HTML or hand-managing container IDs per environment.
• You need per-environment or per-surface switching. The enabled prop × gtm.enabled matrix expresses the whole policy in config, with no layout conditionals.
• You may already depend on noscript tracking — or you don't know whether you do. The broken iframe produced no error and failed no test. There is no visible symptom, so treat this release as an audit trigger rather than an upgrade to schedule whenever.
• You want a small, removable dependency. Output is static HTML; if the maintainer walks away, replacement is roughly an hour of pasting the snippet into a layout partial. Blast radius is near zero.
• You want a green build to mean something. Per-component tests and the full enable matrix are the reason to require ≥ v2.0.1 and to reject any earlier release on sight.

Look elsewhere when:

• You need server-side tagging, an event schema, or a data-layer contract. Wrong layer — pair this with a real taxonomy rather than expecting it here.
• Your frontend is primarily a SPA (Inertia/Vue/React). GTM's page_view on client-side transitions needs explicit pushes the package does not provide; you would be adopting it for initial load only.
• You require consent-management integration out of the box. The flags gate rendering; they do not collect, store, or honour consent signals. GTM firing ahead of consent is a compliance failure this package will happily enable.
• You are not on Laravel/Blade. The components are the entire value proposition; the config file is not.
• You need a support contract or a versioned compatibility matrix. Five stars, zero dependents, single-maintainer cadence, and no stated Laravel/PHP support matrix in the release notes. Acceptable for a snippet renderer; disqualifying for anything load-bearing.
• You already certified v2.0.0 against a coverage requirement. Pre-2.0.1 releases carried less verification signal than their green badge implied — the noscript path was functionally dead while CI passed.

How to Pitch It (Stakeholders)

For executives: This is a maintenance-grade dependency that places Google Tag Manager on our Laravel pages through two Blade components and a config file — no application code, no schema, no routes. The release under review, v2.0.1, is a patch: no new features, no breaking changes. It fixes a defect where visitors browsing without JavaScript were never counted, because the fallback tag rendered with an empty container ID. That segment has been understated silently, with no error and no failing test. Correcting it is a routine upgrade plus a staging smoke check. The release also ships documentation, reducing our dependence on any one engineer for tag management. Cost: a version bump, a rendered-HTML check, and a note on the GA4 property so the small step-change in sessions is not misread as growth.

For engineering: Upgrade past v2.0.1 before anyone relies on noscript page views. x-gtm::no-script read config('site.gtm.id') while the package publishes config/gtm.php — no site namespace exists — so the iframe emitted an empty id. x-gtm::script was unaffected, which is exactly why it survived: the old suite asserted the container ID appeared somewhere in combined output, and the healthy script tag satisfied that check. The new suite tests each component separately, covers all four combinations of enabled × gtm.enabled, and repairs a test-environment bug (gtm.active vs gtm.enabled). Three operational notes: tags render only when both keys are true — deliberate, now documented, not a bug when you hit it in staging; clear or rebuild cached config on deploy so a stale gtm.id does not mask the fix; and if we patched around this with a site.gtm.id entry or an overridden no-script view, delete both in the same commit, or we retain a dead config key and a view that drifts from corrected upstream.

For the product team: Anything downstream of GTM that assumed complete traffic coverage is affected — funnel drop-off, audience sizes, and any channel where a meaningful share of sessions are no-JS, privacy-hardened, or preview/render traffic. After the upgrade, expect a step change in reported volume for that segment; brief whoever owns the dashboards before the deploy lands so it is not read as a campaign effect or a tracking regression. Two things to hold: the historical baseline for "no-JS share of sessions" is an artefact of a broken tag, not a measurement, so do not use it for channel-mix or capacity decisions; and this package only renders tags — deciding which events exist, and honouring consent before they fire, remains our responsibility, not the dependency's.