Getting Started

composer require aimeos/laravel-analytics-bridge
php artisan vendor:publish --tag=config   # adjust to the tag listed in the README

Read the package README and its src/ tree first — the repository link is not resolvable from the metadata, so the authoritative install tag, service-provider name, and config filename have to come from the package itself. Aimeos Laravel packages usually auto-register via discovery; confirm with php artisan about or composer show aimeos/laravel-analytics-bridge.
Expect configuration to land either in a dedicated config/analytics.php or inside the large config/shop.php array that Aimeos Laravel setups use. Grep for the provider keys before editing anything.
Set credentials in .env — a web-stream measurement ID plus API secret for GA4, or base URL plus site ID for Matomo/Piwik — and keep the config file free of secrets.
First use case: inject the provider snippet into the storefront layout so page views start flowing, then add server-side order conversion tracking (the reason you would reach for a bridge at all).
To see what is actually supported, open the provider directory (src/Provider/ or similar) and the interface it implements. That interface is the contract you will code against for the rest of the project.

Implementation Patterns

Provider swap via binding. The whole value of the package is that the interface is resolved from the container. Bind your chosen implementation in AppServiceProvider::register() (or select it through config) and inject the interface, never a concrete class, into your own services.
Order conversion tracking. Hook the Aimeos order events (order.aftersave / payment-related events) and call the provider's trackOrder($order) equivalent from a queued listener. This is the pattern that makes the bridge pay for itself — one event, N possible analytics backends.
Page-view middleware. A small TrackPageView middleware on storefront GET routes gives you server-side views without touching every controller. Guard on runningInConsole(), runningUnitTests(), and a path allow/deny list.
Blade layout component. If the provider exposes a getBody()-style snippet, render it from one layout component and gate it behind consent state rather than scattering <script> tags across templates.
Fakes for tests. Bind a null/log implementation in the test container and assert that trackOrder/trackPage were called with the expected order ID and revenue. This is the cleanest way to test checkout flows without hitting a vendor endpoint.

Publishing overwrites. The Aimeos config file is enormous. vendor:publish --force will clobber local edits — back up and diff, or copy the published file aside first.
GA4 identifiers are not interchangeable. The measurement ID (G-…) is used client-side; the Measurement Protocol needs the API secret and a client_id. Persist a client ID per session or server-side conversions will land unattributed.
Money units. Aimeos order totals follow the shop's currency and decimal handling; check whether the provider wants a decimal string, a float, or integer minor units before sending value.
Double counting. Client-side tags plus server-side page views will inflate sessions. Pick client-side for browsing and server-side for conversions, or vice versa — not both for the same event.
Don't block checkout. Default queue connection is sync; a slow vendor call will add latency to order confirmation. Queue the tracking listener.
Consent and local environments. Route everything through a null/no-op provider (or a config flag) in local and staging so test orders don't pollute production analytics.
Octane/queue workers. Keep provider instances stateless; don't cache per-request identifiers on singletons.
Extension point. If your vendor isn't shipped, implement the package's provider interface and register it in the provider map — that is the intended path and keeps your application code unchanged when the package adds a native backend later.