The shop delivered by go~mus runs without tracking by default: no analytics services, no marketing pixels, no tracking cookies. A strict content security policy blocks third-party services at browser level. That is a quality feature, not a gap: the shop is privacy-friendly from day one, fast, and in this state needs no cookie banner.
When your venue wants to measure online sales, we retrofit web analytics deliberately, as a conscious decision by your venue. From then on you manage all tags yourself via Google Tag Manager (GTM): GA4, advertising pixels, conversion tracking, without needing go~mus for every change. The standard is not up for negotiation: before consent no third-party service is loaded, not even one that promises to stay quiet afterwards. This page describes the setup, the available data and what your venue provides for activation.
Three layers, clear responsibilities
| Layer | Who owns it | What it does |
|---|---|---|
| Data layer | go~mus | The shop publishes structured ecommerce events into the dataLayer, from the offer list to the purchase. |
| Consent layer | go~mus, categories and copy agreed with your venue | The shop brings its own cookie notice, settings dialog and load gate. No third-party consent library, no bought CMP required. |
| Tag layer | your venue, fully | Your GTM container. Tags, triggers and destinations are maintained by your marketing team in the GTM interface. |
The data layer is the contract between the shop and GTM. Once it is in place, your team works exclusively in GTM and GA4.
If your venue already runs a consent solution on its main website, it stays there. The shop uses its own layer, because that is the only way to guarantee the load gate sits in front of every service.
Nothing happens before consent
Before consent, the shop transmits no data to Google: no Google server is contacted, no cookie is set, the GTM container is not loaded.
That is stricter than the usual route. Google's standard solution (Consent Mode without a load gate in front of it) loads the container and lets it stay quiet afterwards. In doing so the visitor's IP address already reaches Google. In the shop that connection is only made after the opt-in. The assurance holds regardless of which tags sit in the container: what is not loaded cannot send anything.
The data layer stays empty too. A dataLayer looks like a private buffer and is not one: the tag manager reads whatever it finds the moment it starts. Events from before the opt-in are therefore dropped, not buffered and replayed later.
On top of that the shop reports Google Consent Mode v2, with all seven signals: the four Consent Mode v2 requires and the three further ones Google defines. All start on "denied"; after the opt-in the shop updates them to the granted categories. An unset signal is indistinguishable from a forgotten one during an audit, which is why we also set the ones we do not need.
On withdrawal the shop reports the revoked consent to Google and deletes the Google cookies it can reach from its own domain.
Legal responsibility for the tags you run lies with your venue as the operator. go~mus itself does not track and does not analyse your marketing data.
The events in the dataLayer
The shop reports the complete sales funnel following the GA4 ecommerce schema:
| Event | When | Key parameters |
|---|---|---|
view_item_list | offer list rendered | item_list_id, items[] |
view_item | detail view of an offer | items[], value, currency |
select_item | date or time slot chosen | item_list_id, visit_date, timeslot |
add_to_cart / remove_from_cart | cart changed | items[] (the change only), value, currency, visit_date |
begin_checkout | checkout entered | items[], value, currency, coupon, visit_date |
add_payment_info | payment method chosen | payment_type, items[], value, currency |
purchase | order completed | transaction_id, value, currency, items[], coupon, visit_date |
An item carries item_id, item_name, item_category, price (in euros), quantity and visit_date. List views that show no price do not carry prices; the purchase events always do.
What causes questions in practice:
visit_dateis the visit date, not the purchase date. So you can analyse which visit days people buy for and how long the lead time is. For venues that is usually the more interesting figure.item_categoryis the type of line (ticket, event, guided tour), not the go~mus ticket category. A finer mapping is feasible and is scoped before implementation (checklist item 8).purchasefires exactly once per order, including when the confirmation page is reloaded or opened again later.- Redeemed vouchers are payment, not a line item. They do not appear in
items[]but in thecouponparameter.valuestays the value of the booked services.
The event set is the contract. Which points in the shop emit them is agreed together during setup.
Who measures: the container, not the shop
The shop delivers the purchase journey, the measuring happens in your venue's container. The split is deliberate: measurement and consent checking sit with you, we supply the data and the load gate in front of it.
One consequence of that reliably comes up after go-live. Whether the events turn into a GA4 report depends on whether your container has tags configured for them. Without such tags, GA4 shows page views only, even though the data sits ready in the data layer. So if revenue, orders or the funnel from offer to checkout are missing, the cause is usually not the shop. We can neither check nor fix it, because we have no access to the container. Your agency configures the tags in a short time.
You can look for yourself: run a test purchase in GTM preview mode. Once consent is given, the events above appear in the data layer.
Self-service and its boundary
Everything that works with the existing events and parameters you do yourself in GTM: new tags, changed triggers, additional destinations. go~mus is involved in exactly two cases, both small and plannable:
- A new data point the dataLayer does not publish yet: a short scoping conversation, then we add it.
- A new tag destination (a service your tags call): the shop's security policy allows declared destinations only, by name, never wholesale. Allowing one is a small, reviewed change.
The strict policy stays in place on purpose. It is the reason nothing unwanted ever loads in the shop.
The container is a position of trust. Tags run with the rights of the shop page, so whoever may publish in the container executes code in the shop. The security policy limits where data may flow, it does not sandbox the tags. That is why the checklist asks for a named contact: whoever owns the container also owns what it loads.
Advertising and remarketing are not a switch
Reach measurement and advertising are separate matters. A shop that starts with a statistics consent does not gain advertising or remarketing tags by configuration. That needs a second category in the cookie notice, a fresh decision from every visitor (the earlier one does not cover the new category), an update to the privacy notice and the contractual basis with the vendor. Plannable, but a project of its own. Talk to us before you add tags of that kind to the container.
Checklist: what your venue provides
Items 1 to 7 are prerequisites for activation, item 8 is optional, item 9 is needed for go-live.
| # | What | Details |
|---|---|---|
| 1 | GTM container | container ID of your web container (GTM-XXXXXXX) |
| 2 | GA4 property | measurement ID (G-XXXXXXX), if you use GA4 |
| 3 | Tag destinations | complete list of services your tags call |
| 4 | Consent categories | which categories the cookie notice offers; the consent layer itself ships with the shop |
| 5 | Consent mapping | which category releases which tags |
| 6 | Legal basis | DPA with Google, contracts with other tag vendors |
| 7 | Privacy notice | updated, covers the tags you run |
| 8 | Additional data points | optional, scoped together before implementation |
| 9 | Sign-off | named contact for the container, data flows and go-live |
Send the completed checklist to go~mus support, we set things up (consent layer, container wiring, allowing the tag destinations), you verify in GTM preview mode and approve.
Embedding instead of a standalone shop?
This page describes the standalone shop delivered by go~mus. If you embed the bundle or individual web components into your own website instead, the page is yours, and so are analytics and consent: your GTM, your consent solution, your responsibility, with no go~mus involvement at all. For data points inside the embedded booking flow, talk to us.
Alternatives to Google
The data layer is not tied to Google. Server-side tagging (a first-party endpoint, less browser weight, full control over what reaches Google) or a different vendor such as Matomo are feasible; the scope is agreed individually. The consent layer's load gate applies to every one of these services alike. Talk to us.