Google Analytics Bundle Laravel Package

Product Decisions This Supports

• Analytics instrumentation architecture: v2.2.0 formalizes a Stimulus-based data layer bridge, making analytics a first-class, package-managed concern rather than per-feature JavaScript. This supports a decision to standardize event collection across all Live Components instead of hand-rolling fetch wrappers in each feature.
• Build vs. buy for the event bridge: The package now owns the plumbing between server-rendered component responses and the browser data layer. Teams can avoid building an in-house bridge for Livewire/Live Components, while retaining control over payloads and downstream destinations.
• Roadmap sequencing for measurement: Because events are pushed automatically on render:started, near-term roadmap items can include analytics coverage without dedicated frontend tickets per component. This shifts effort toward event taxonomy, consent, and validation rather than wiring.
• Migration decision for existing instrumentation: Replacing the documented fetch wrapper is a breaking change for any product area relying on it. This forces an explicit roadmap decision: migrate affected flows in v2.2.0, or pin the prior version while planning the transition.
• Vendor flexibility: Dispatching each payload as an analytics:event CustomEvent lets the product route events to Google Analytics, GTM, or other consumers without coupling the package to a single vendor. This supports decisions to keep analytics destinations swappable.
• Shop-specific AJAX coverage: pushAnalyticsEvents(response) extends the same event model to a shop’s own AJAX calls, reducing inconsistent measurement between Live Components and custom endpoints.
• Configuration and branding control: google_analytics_head() now emits the data-controller bootstrap, and stimulus_controller_name configures the identifier. This supports multi-brand or multi-tenant setups where controller naming must align with frontend conventions.

When to Consider This Package

Consider adoption when:

• The application is built on Laravel with Live Components/Livewire and needs consistent analytics events tied to component renders.
• The team wants server-influenced event payloads pushed into a browser data layer without maintaining bespoke JavaScript for every component.
• Google Analytics/GTM is the primary destination, or the team is willing to consume analytics:event CustomEvents in its own listener.
• Multiple teams contribute Live Components and would benefit from a single, package-owned instrumentation path.
• The product needs a migration path for existing AJAX calls via pushAnalyticsEvents(response) rather than parallel tracking implementations.
• Controller naming or head bootstrap must be configurable (stimulus_controller_name, google_analytics_head()), for example in themed storefronts.

Look elsewhere or defer when:

• The frontend is not Stimulus/Live Components based; the bridge’s automatic render:started hook provides little value.
• The product requires strict server-side-only analytics with no client-side data layer.
• There is a hard requirement for vendor SDK-native ecommerce schemas that the package does not model.
• The team cannot absorb the breaking change from the documented fetch wrapper in the near term and needs a zero-migration release.
• A strict CSP or consent architecture prohibits injecting the data layer bootstrap in the document head without additional controls.

How to Pitch It (Stakeholders)

For executives: This release turns analytics instrumentation into shared infrastructure. Instead of each feature team writing and maintaining its own tracking code, Live Components automatically publish the events they already collect. That means faster measurement coverage, fewer inconsistencies in reporting, and lower long-term maintenance cost. The trade-off is a planned migration for any flows still using the old fetch wrapper.

For engineering: v2.2.0 replaces the documented fetch wrapper with a Stimulus data layer bridge. data_layer_controller.js listens to each Live Component’s render:started and pushes the events returned in that response. analytics_events.js exposes pushAnalyticsEvents(response) for non-component AJAX and emits each payload as an analytics:event CustomEvent, giving consumers a clean integration point. google_analytics_head() now renders the data-controller attribute on the data layer bootstrap, with stimulus_controller_name controlling the identifier. Treat the removal of the fetch wrapper as breaking: audit existing usages, migrate to the bridge or the explicit push API, and verify event payloads and consent handling before rollout.