Livewire Google Analytics Laravel Package

Getting Started

• Install with composer require arviddejong/livewire-google-analytics, then follow the quickstart — it is the fastest path because it ships one complete, copyable contact form: layout, Livewire component, Blade view, and route, each with its file name and imports.
• Add the package's listener script view (livewire-google-analytics::script) to your layout once. The package does not load gtag.js for you, so you also need your own Google tag snippet (or GTM) with your measurement ID in place before any event will land.
• Pull the tracking trait into the component that owns the interaction you care about (e.g. the contact form), and call a tracking method at the point the action succeeds — not on render and not before validation.
• Verify immediately using the "Check that it works" section on the installation page: it gives two console checks, a pasteable test event, and where to look in GA4 DebugView. Treat this as your smoke test before wiring up real events.
• First real use case: a form submit that fires a single named event with a couple of non-PII params, then confirm it in DebugView.

Implementation Patterns

• Trait on the component, call on success. Keep tracking calls next to the domain action ($this->track...() after save()/mail send), so the event reflects a real outcome rather than a click.
• Two flavours of every method. The plain methods dispatch immediately; the …AfterRedirect() variants stash the event so it is sent on the next page load. Use the plain form for in-place interactions (modals, filters, live search) and the …AfterRedirect() form for the redirect-after-submit pattern where the component is destroyed.
• Pass params as an array. Include 'debug_mode' => true in the params while developing — that is the reliable way to get the event into DebugView, either on the tag or on a single event.
• Queueing is your friend on slow pages. If window.gtag does not exist yet (script still loading, tag manager delayed), events wait until it does. Pass ['queue' => false] when you would rather drop the event than have it fire late.
• wire:navigate works, with a nuance. The listener does not attach a second time on navigation, but it does flush events carried over from the previous page — so …AfterRedirect() events survive SPA-style navigation.
• Compose events, don't spam them. One well-named event per meaningful outcome plus a small, stable param set beats ten micro-events; you cannot retrofit recommended names or custom dimensions later without re-instrumenting.

Gotchas and Tips

• Two distinct view errors, two distinct fixes. No hint path defined for [livewire-google-analytics]. means the service provider is not loaded (package not discovered / provider removed from bootstrap/providers.php). View [script] not found. means the provider is fine but the view name you referenced is wrong. Check which one you have before touching config.
• The package sends nothing from the server. All events go through window.gtag. Ad blockers, JS disabled, or a missing tag snippet means zero data — no server-side fallback exists, so do not use this for business-critical auditing.
• No consent handling, by design. The page-level docs are explicit: the package knows nothing about consent mode. If you operate under GDPR/ePrivacy, gate the script view and your gtag.js load behind your own consent layer; the queue only controls when a waiting event is sent once window.gtag exists.
• …AfterRedirect() writes into the next page's listener script. Since 1.3.0, the event is serialised as JSON with tags and quotes escaped. Keep those payloads small and free of user-entered text — the old "form values are never written into a script" guarantee no longer holds for these methods, and escaping is not a licence to put PII in params.
• Debug tooling has moved on. The old advice about the "Google Analytics Debugger extension" is stale; use Tag Assistant and the debug_mode parameter, and find DebugView under Admin → "Data display".
• Don't trust folklore about GA4. The docs deliberately removed claims about Realtime latency, why recommended event names are preferred, and what registering a custom dimension does. For those, go to Google's own documentation rather than the package docs.
• Extension point is the layout, not the package. Because there is no measurement-ID setting and no config-driven script loading, all environment-specific wiring (IDs, consent, sampler, debug_mode defaults) belongs in your own layout/partial that includes the package's script view.