Tracking V2: events and troubleshooting
Tracking V2 separates browser actions from business events from edoobox. Clicking ‘Book’ is not yet a confirmed purchase; an incoming payment is not automatically a second purchase. Use this distinction for reports and conversion goals.
Browser events during booking
| Event | Trigger |
|---|---|
| view_item_list | An actual offer/list view. |
| view_item | An actual offer detail view. |
| select_item | Click on an offer details link. |
| add_to_cart | An actual increase in a price or additional service quantity. Unchanged or reduced quantities do not generate this trigger. |
| begin_checkout | The first displayed booking step, once per process and browser session. |
| add_payment_info | Selection of a payment method or submission of the preselected method. |
| waitlist_join | Permitted integration hook; business confirmation of waiting list registration is determined server-side. |
In the dataLayer, V2 triggers are named edoobox_v2_<ereignis>. Additionally, edoobox_event_name and edoobox_analytics_version: 2 are available. The exported container forwards permitted standard names. In iframe operation, these events reach the parent website’s dataLayer through the checked channel.
Names, email addresses and free form values are not included as general funnel parameters.
Purchase, payment and reversal
| Event | Meaning |
|---|---|
| purchase | Completed, confirmed booking without waiting list, MustPay or cancellation status. |
| payment | An actual payment in the associated process. |
| booking_cancelled | Cancellation of the booking. |
| refund | Recorded repayment or business reversal. |
A MustPay completion or waiting list registration must not already be analysed as a definitive purchase. If status changes later, analysis must account for the actual state.
Google purchase values distinguish net value (value), tax (tax) and gross value (booking_gross_value). The transaction identifier combines the public booking reference with currency. A booking with several currencies must therefore not be combined into a single arbitrary sum based merely on a browser click.
Differences between providers
- Google Analytics: receives events permitted for it with the recorded analytics context.
- Microsoft Ads: receives purchase, payment, cancellation, refund and waiting list as separate custom events.
- ChatGPT / OpenAI Ads: receives purchase as
order_created; other states as custom events.
For Microsoft and OpenAI, cancellation/refund events do not automatically retract an original purchase conversion. Configure your goals so additional payment events do not count further purchases.
Recent events and connection checking
- Open Settings → Google & E-Commerce → Server-side Tracking V2.
- Under Recent events, check provider, event name, booking reference, status, error code and time.
- After changing credentials, first check the saved connection or configuration.
- Then compare a controlled process with the actual report in the destination system.
The scope of a successful check differs by provider: Google checks the validation request and responses; Microsoft checks configuration completeness locally; OpenAI validates without storing a conversion event. None of these displays alone guarantees later attribution in a report.
Even HTTP acceptance by a provider does not prove complete processing. If transmission is uncertain, a new booking must not be used as a technical retry.
Narrow down common error patterns
| Observation | Check |
|---|---|
| No browser events | Active V2 configuration, Google tag for the same measurement ID, consent, V2 web container and website helper. |
| Iframe sends no context | Exact iframe ID, bookingOrigin, measurement ID, provider selection and referrer setting. Update the helper after a CMP change. |
| Funnel present, purchase missing | Definitive booking status, saved destination configuration, permitted context and server-side event list. Waiting list/MustPay are not a definitive purchase. |
| Purchase counted twice | Check old edoobox purchase tags, other browser pixels and conversion goals for payment/refund. |
| Advertising event missing | Active provider, its credentials, website provider switch and separate permissions for ad_storage and ad_user_data. |
| Still the wrong destination after a change | Saving in edoobox and matching helper configuration on the website; each embedded instance belongs to the intended account. |
Account, provider, booking reference, time and visible error code are sufficient for a support request. Do not send API secrets or unabridged request contents containing participant data.
Example: Analyse waiting list and payment separately
A fully booked seminar initially produces a waiting list registration. The team counts this as interest rather than a purchase. A purchase is expected only after conversion to a confirmed booking. A later bank payment is an incoming payment. The report therefore does not count the person again as a new purchase with every status change.
Next: Set up Tracking V2 · Connect iframe and consent
Avoid uncertain transmission and duplicate conversions
A timeout can occur after an event is accepted. Use neither a new booking nor an artificially redated conversion to retry uncertain sending. Have event identifier, time, destination and visible status checked using the same process.
If an additional Microsoft or OpenAI browser pixel reports the same conversion, intended deduplication requires matching event identifiers and event names. Without a deliberately coordinated implementation, disable parallel conversion sending for the same completion. A payment goal counted as another purchase also creates incorrect multiple counting.