Job ga4-ecommerce-event-schema-implemented · revised 11 October 2026
Send your shop's GA4 funnel events: view item, add to cart, checkout and purchase
One store sends view_item, add_to_cart, begin_checkout and purchase with items, currency, value and transaction ID, checked in DebugView, one report and one exploration.
You might be seeing
- The shopping behaviour report shows no steps or only purchase
- Purchases have revenue but no item names or a missing currency
No passwords, keys, card details or admin invites needed to start.
What usually happened
The store is not sending GA4's recommended ecommerce events with the parameters GA4 expects. Items must be an array with identifiers and prices, currency should be set whenever value is sent, and purchase needs a transaction ID. Missing or inconsistent events leave the funnel reports empty or misleading.
Who it’s for: An online shop owner or agency whose GA4 shows page views but no usable shopping funnel or product-level revenue.
Usually starts when: The ecommerce reports are empty or partial, or purchases arrive without items, value or a transaction ID.
The result: On one store, a test shopping journey produces view_item, add_to_cart, begin_checkout and purchase events in DebugView with the agreed items, currency, value and a transaction ID, and, once Google has processed the data, the Ecommerce purchases report shows the test product's item revenue and an exploration lists the test order by its transaction ID.
Check whether this job fits
Answer these without order data or logins.
Checks you can run yourself
Check the data layer on a product page
Open Tag Assistant or the browser console on a product page and look for a data layer entry for the product.
Look for: An item identifier, name, price and currency. Their absence is the gap to fill.
What you get
- A written event specification for the four events on your store
- The tags, triggers and data layer changes prepared for your approval
- DebugView evidence for each event, the Ecommerce purchases report row for the test product and the exploration row for the test order
Included
- One store on Shopify, WooCommerce or a custom build, one GA4 web stream, the four events above
- A data layer or platform route for product, cart, checkout and confirmation steps, as the platform allows
- Tag Manager tags and triggers that send each event from the data layer, with the ecommerce object cleared before each push
- A test journey with a known product, quantity and price
- A written note, agreed with you, of how the purchase value treats discounts, shipping and tax on your store; the test order uses no discount code
Not included
- Other recommended events such as refunds, wishlist, promotions and list impressions unless quoted
- Fixing duplicate purchase events already present, which has its own outcome
- Reconciling GA4 revenue to orders, tax, shipping or refunds
- Replacing your platform's checkout or building new store features
- Any promise about sales, ad performance or rankings
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The known test product viewed on the store produces one view_item event in DebugView with the agreed item ID, name, price and currency.
Evidence: DebugView screenshot of the event with its items parameter expanded.
Adding two of the product to the cart produces add_to_cart with quantity 2, and starting checkout produces begin_checkout carrying the same items and no earlier product.
Evidence: DebugView screenshots of both events.
The test order, placed with no discount code, produces one purchase event with a transaction ID, currency, and a value equal to the sum of price times quantity for its items, as Google's purchase sample describes.
Evidence: DebugView screenshot of the purchase event and the shop's own order record for the same order.
After Google has processed the data, the Ecommerce purchases report filtered to the test product's Item ID shows its items purchased and item revenue, and an exploration with the Transaction ID dimension lists the test order's transaction ID once with its purchase count and revenue. (That report has item dimensions only, so the order itself is found in the exploration.)
Evidence: Report screenshot filtered to the test product's Item ID, and exploration screenshot showing the test transaction ID.
Sign-off. We prepare the change and run the journey in preview; you compare DebugView and the order record and publish the change yourself; we then repeat the journey on the live site and read the report and exploration rows; you sign off in writing after that. Payment follows sign-off.
If it fails. If the test journey does not pass, you do not pay for this scope. If the platform cannot expose the data, we explain what is missing and stop or re-quote in writing.
When it fits, and when we stop
It fits when
- The platform allows tracking code or events to be added on product, cart, checkout and confirmation steps
- A test order route exists, such as test mode or a product you accept paying and cancelling
- The GA4 property and web stream already receive page views
- Analytics cookies can be accepted in the test browser
- No Active data filter on the property drops the test order. Google says a developer-traffic filter removes activity from debug mode and that excluded data is never processed; if one is Active, the report check uses a separate test order placed without debug mode, agreed in writing before work starts
We stop and tell you if
- The checkout is hosted and gives no way to send events or read them
- The store has more than three product page templates that differ in structure and no spec for them
- The only test route is a live card charge you will not make
What could go wrong
Tags are a Tag Manager workspace change, recorded as a version when you publish, so you can republish the earlier version; theme or plugin changes are listed with a copy of the previous file or setting so that each can be reverted.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Theme edits break the storefront. | Changes are made on a theme copy or preview first and the previous theme file is kept. |
| Previous items remain in the data layer and appear on a later event. | Each push clears the ecommerce object first, and the test journey checks each event's items. |
A separate reviewer repeats the journey and checks parameter types and that no personal data is in an event. You approve theme changes and publish.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the platform, the test product and the access route in writing
- Write the event specification: names, parameters and where each is pushed
- Build the data layer pushes and tags in a workspace, clearing the ecommerce object before each push
- Run the test journey in Tag Manager preview with DebugView open and fix any missing parameter
- Independent review, then hand over for you to publish
- After you publish, repeat the test journey on the live site and check the Ecommerce purchases report and the exploration once Google has processed the data
This is a one-off job, not a subscription or emergency cover. We confirm eligibility, the price, a start window and a delivery date before you accept. Work starts only after the agreed inputs and the least access the job needs are in place. Fees charged by Google, Meta, your host or any tool you use are not included. No charge or booking is created by an enquiry.
Need to keep it working?
A standing check can place a test order each month and compare event parameters.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Google publishes the event and parameter definitions and a Tag Manager guide for ecommerce, which a developer can implement directly. developers.google.com
- Many store platforms offer a built-in Google integration; ask whether it sends these four events with items.
Questions
Why a report check after DebugView?
Google notes purchase data reaches reports after about 24 hours and says many reports and explorations can take 24-48 hours, so DebugView proves collection and the report rows prove processing. The Ecommerce purchases report shows items, so the order itself is found by its transaction ID in an exploration.
Does it matter which platform I use?
The route to the data differs, so we quote after seeing the platform. The four events and the acceptance test are the same.
Send an enquiry
Send us
- Platform name, whether checkout is on your domain, and what the GA4 ecommerce reports show today
- The three most important products or collections for the test
- No customer data, no logins.
Later, once you agree
- A scoped Editor role on GA4 and Edit access to the container (Google describes Edit as able to create workspaces and make edits but not create versions or publish; you publish); for the store, the least role that can edit the theme or tracking settings. All are granted to the identity we agree with you before work starts
- A test product and test payment route
- Your named person to publish and to approve theme changes
You own the website, the Google and Meta accounts, the tag manager container and all the data. We ask for the lowest role that lets us do the job. Before any work starts we agree with you in writing which identity receives that role; you grant it and can remove it at any time. We never ask for your passwords. You keep the right to publish: we prepare changes and you publish them.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “ga4-ecommerce-event-schema-implemented” as the subject.