GA4 Analytics
Maya sends its own events to Google Analytics 4, so what happens inside the Maya widget shows up in your reports next to the rest of your site traffic.
Every event carries the same set of context parameters, listed in section 3, plus a few of its own. Section 4 covers the events one at a time.
1. What it is
The Maya widget is a separate application from your website, so it does not appear in your analytics on its own. Instead Maya sends a small set of events straight to GA4 whenever a visitor does something: sends a message, presses a button, opens a recommendation, follows a link in an answer.
There are five events today, and they are the same for every client, so a report you build once keeps working. More may be added as Maya grows, the search experiences in particular, and anything added follows the same shape: the parameters in section 3 on every event, plus a few of its own.
Events can go to two properties at the same time:
- Your own GA4 property, so what visitors do in the widget sits beside your existing site reports
- Maya's property, which we use to see how the product performs across all clients
You decide whether yours is one of them. If neither is set up, Maya sends nothing at all.
2. Turning it on
Send us the measurement ID of the property you want the events in. It looks like G-XXXXXXXXXX, and you will find it in GA4 under Admin, then Data streams, then your web stream.
We set it on your organisation and the widget picks it up the next time it loads. There is nothing to add to your website: the widget loads Google's tag itself using the ID we set, and sends its events through a group of its own. So this works whether or not you already have a GA4 tag on the page, and where you do have one, Maya does not change how it is configured.
Two things worth settling before you build reports on this.
Register the parameters you want to report on. GA4 receives every parameter below, but reports and explorations only offer the ones you have registered. In GA4 go to Admin, then Custom definitions, then Create custom dimension, and enter the parameter name exactly as it is spelled here. Do this before you need the data, because GA4 does not fill in the past.
Values are cut at 100 characters. That is a GA4 limit rather than ours. It mostly shows on item_title and button_text, where a long trip name or a long piece of link text arrives truncated.
3. What arrives with every event
These are sent every time, regardless of which event it is. Whatever the visitor did, the event recording it also carries all eight parameters below, so you can group or filter any event by any of them without having to check first whether that particular event includes it:
| Parameter | What it is |
|---|---|
chat_id | The identifier of the conversation. Every event from the same conversation carries the same value |
url | The full address of the page the widget was open on |
organization | Your organisation's short name in Maya |
domain | The hostname of the page, with www. removed, so one value covers your site whether or not the visitor used the www form |
mode | How the widget was embedded: popover for the bubble in the corner, full-page for a page of its own, search or quick-search for the search experiences |
language | The language the conversation is being held in |
test_user | true when the conversation is one of ours or yours rather than a visitor's. See section 7 |
environment | Which Maya environment sent the event. production is your live traffic |
chat_id is the one to build on. It is the only parameter that ties several events together into one conversation, so counting distinct values of chat_id is how you count conversations, and it is what lets you see the order things happened in for a single visitor.
4. The events
maya_sent_message
Sent when a message goes to Maya on the visitor's behalf. It counts the visitor's side of the conversation, not Maya's replies.
| Parameter | What it is |
|---|---|
message_type | user for something typed in the box, quick_reply for a suggested reply the visitor pressed, cta for a message a button sent on their behalf |
message_subtype | Only present when message_type is cta. Today the one value is leave_details, the message that starts the request for someone to get back to them |
Asking Maya to try an answer again counts here too, as user, because that is what it sends.
maya_click_button
Sent for every button in the widget. This is the busiest of the five, so button_type is what makes it readable.
button_type | Where it is | button_subtype |
|---|---|---|
popover_icon | The bubble in the corner, and the controls in the widget's own frame | open_popover, close_popover, send_chat |
notification | The message that appears beside the bubble inviting someone to start | open_popover |
tab | Switching between the conversation and the recommendations, in full page mode | to_chat, to_recommendations |
cta | A call to action inside the conversation | leave_details when it asks for the visitor's details, continue_chatting when it returns to the conversation, and none at all for the button that opens the recommendations |
quick_reply | A suggested reply that you wrote | none |
quick_reply_ai | A suggested reply that Maya generated | none |
restart | Starting the conversation over | none |
button_text carries the label the visitor actually saw, in their own language. It comes with calls to action, quick replies and tabs. The bubble, the notification and restart have no label to record, so they do not send it, and the conversation tab is always recorded as Chat rather than translated.
The two kinds of quick reply are worth keeping apart: quick_reply is one of yours and quick_reply_ai is one Maya wrote for that moment, so comparing them tells you whether your own suggestions are the ones people press.
maya_click_grid_item
Sent when a visitor opens one of the recommendations Maya showed on the cards under the conversation.
| Parameter | What it is |
|---|---|
item_url | The address the visitor was sent to. This is the one to match against your own page reports |
item_title | The name of the trip or property, as shown on the card |
item_subtitle | The price as it appeared on the card. It is a piece of text rather than a number, and it carries whatever currency and formatting the card showed |
item_destination | The first destination on the item. An item covering several destinations still reports one |
item_type | The label printed over the card's image. It comes from your own content, so what appears here is whatever you put there |
item_entity | What kind of thing was opened. Today this is always trips |
Match on item_url****, not item_title****. Titles are cut at 100 characters and can be reworded in your content, while the URL is what your own reports are keyed on, so joining the two sides on the URL is what holds up over time.
maya_url_click_chat
Sent when a visitor follows a link inside one of Maya's written answers, rather than on a recommendation card.
| Parameter | What it is |
|---|---|
item_url | The address the link pointed to |
item_title | The text of the link, as the visitor saw it |
item_type | Always text, which is what separates these from the card clicks above |
Despite the name, this one is not limited to chat: it is sent from the search experiences too, and mode tells them apart. Taken together with maya_click_grid_item, it is how you see the traffic Maya sends into your own site, recommendations in one event and links inside answers in the other.
maya_identify
Sent once per conversation, just before the first of the events above. It exists so a conversation can be tied to a visitor, which the next section explains.
| Parameter | What it is |
|---|---|
ga_client_id | The visitor's GA4 client identifier, when there is one to read. Absent otherwise, and the event is still sent |
5. Tying a conversation to a visitor
Maya reads the visitor's GA4 client identifier from the _ga cookie your own GA4 tag sets, sends it on maya_identify, and stores it on the conversation.
That cookie only exists if the visitor accepted analytics, so this follows your consent banner without needing to know anything about it. No consent means no cookie, which means no identifier, and the conversation is simply recorded without one. Nothing else about the visitor is read or stored.
Two things it buys you:
- In your own GA4,
ga_client_idlets you map a conversation onto the visitor GA4 already knows, if you want a user-scoped custom dimension for it - On our side, it is what allows purchases to be traced back to a conversation, which is the next section
It is sent once per conversation, on the first thing the visitor does, and not at all for a conversation that is only being read back rather than held.
6. Bringing purchases back to conversations
Whether someone chatted and then booked is a different question from the ones above, and the events cannot answer it on their own: the purchase happens on your site, well after the conversation, and usually on a page the widget never appeared on.
So it is answered from your GA4 export instead. If you send your GA4 data to BigQuery and give us access, we read your purchases and key events from it and attribute them to a conversation through the identifier from section 5. What we need is the BigQuery project and dataset of the export, your numeric property ID, and which events you count as a conversion.
The result is conversion figures per conversation, which is what the revenue reporting in your dashboard is built on. It is set up per client rather than on by default, so ask us if you want it.
7. Test traffic
Conversations we or you run as tests are marked, so you can keep them out of your reporting.
test_useristrueon every event from a test conversation. Filtering it out is worth doing on any report you shareenvironmentisproductiononly for your live traffic, so our development and staging environments are easy to exclude in one go- Events from those environments, and from a test conversation the widget already knows about when it loads, are also flagged to GA4 as debug traffic. That puts them in GA4's DebugView and keeps them out of the standard reports
That last point is also the quickest way to check a new setup: open DebugView in GA4, use the widget, and watch the events arrive as you click.
8. When you do not see events
Nothing arrives at all. The likeliest reason is that no measurement ID is set on your organisation, because Maya sends nothing rather than guessing where to put it. Ask us to check. Beyond that, an ad or tracking blocker in the browser stops these events exactly as it stops your own.
The events arrive, but the parameters are missing from reports. They are being received and are not yet registered. See the custom dimensions step in section 2. A dimension you register now only fills from now on.
maya_identify has no ga_client_id****. The visitor did not accept analytics, or your own GA4 tag is not on the page the widget was opened from. Both are expected rather than a fault.
A value looks cut off. It reached 100 characters, which is GA4's limit. Match on item_url rather than on titles.
The numbers do not match your dashboard. Your dashboard counts every conversation. GA4 only ever sees the ones where the visitor did something, because every event here is triggered by an action, so a conversation that was opened and abandoned appears in one and not in the other.
Events go to one property but not the other. Each property is configured separately, so a missing or mistyped measurement ID stops that one alone and leaves the other looking healthy. Check which property you are reading before assuming the events are gone.