On-site tracking of the shopper (Storefront) #3621
fschmtt
started this conversation in
RFC / Proposal
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Context
As part of Shopware's endeavors to provide data-driven features to merchants, it's crucial to understand how shoppers behave on the Storefront. To obtain these kind of insights, it's necessary to track the shopper's interactions on the Storefront.
The overall goals and iterations are:
APIs
Tracking library
Similar to existing solutions, like e.g. Google Tag Manager or Matomo, we provide a generalized tracking library. This library is not bound to only work with Shopware's default Storefront bundle, but can be used in any shopper-facing application that can run JavaScript.
The library and its API are heavily inspired by Segment's analytics-next.js (see also https://github.com/DavidWells/analytics) but aims to be tailored to the needs to track in a Shopware Storefront.
Store API (API-first and headless support)
For custom storefronts other than Shopware's default Storefront bundle, e.g. Shopware Frontends, we provide the Store API endpoints necessary to initialize and run the generalized tracking library.
Those endpoints are provided as custom endpoints powered by app scripts.
For the time being, these endpoints are:
For Shopware Frontends we plan to provide a Nuxt package in the future that can be used to easily integrate the tracking library.
Default Storefront
The integration into Shopware's default Storefront bundle is provided within the app. It does not rely on the PluginManager to register, initialize and run the tracking library. The tracking library should always run independently with as little dependencies as possible. It is also private and should not be decorated or modified.
Additionally, the default cookie consent manager is used to determine and store the consent of the shopper.
The event tracking in the Shopware Storefront should be decoupled from the actual tracking library. At the same time, developers must be able to rely on something that is already there and can be used out of the box. This is why we want to use the
document.$emitter
to publish analytics events:With this approach, any tracking integration (even independent of our tracking library) can consume every
sw-analytics-event
published via the global event emitter. At the same time we define a common interface for tracking events and enforce a consistent naming and structure:At a later point, we cannot only track page views, but any other event relevant for analytics, e.g.
Summary
document.$emitter
to track analytics eventsBeta Was this translation helpful? Give feedback.
All reactions