In the Pink Balloon project, the begin_checkout event appeared to be working. It entered the data layer, triggered the expected tag, and carried the ecommerce parameters. But Tag Assistant reported no hits sent.
The event looked correct inside the tagging interface. It was not reaching its destination.
Follow the event all the way through
The investigation moved beyond the trigger and into the browser’s behaviour. Console messages pointed to a session-storage problem: event processing was stopping before the request was sent.
After the configuration was corrected, the expected hit was generated and checkout events began reaching GA4. The important lesson is the verification sequence, rather than treating one project’s configuration as a universal fix.
Three questions worth asking
- Was the action captured? Check that the expected business interaction creates the right event.
- Was the request sent? Confirm that a fired tag results in an outbound request.
- Did the destination receive the right data? Verify the event and its useful parameters in the receiving system.
A tag firing in GTM does not prove GA4 received the event.
Validate before the traffic arrives
For Pink Balloon, this work happened before the Neptune store reopened. That timing meant the redesigned store could start collecting useful shopping behaviour as customer activity returned.
The practical takeaway: include end-to-end measurement checks in launch preparation, alongside testing the website itself.
A diagnostic sequence you can repeat
Start with one action you can reproduce. Record the page, browser, consent state, expected event name and destination property. Use a test record that the business can recognise without putting personal enquiry data into analytics.
- Check the business action. Submit successfully, then try a validation failure. The conversion should describe the accepted action, not merely the attempt.
- Check the event. Inspect the data layer and Tag Assistant. Confirm the name and parameters at the moment the tag evaluates; a value becoming available later does not prove it was available earlier.
- Check the request. Inspect the browser network activity for the expected destination. Review console errors and blocking. Do not assume a particular endpoint applies if the site uses a server-side transport.
- Check the destination. Verify the intended GA4 property and stream, then inspect DebugView or the relevant validation view. Standard reports may have processing delays.
- Check repetition. Refresh, retry and navigate back. Look for unintended repeat conversions or listeners attached more than once.
Interpret the point of failure
If the action never creates the event, investigate the platform callback or success definition. If the event exists but the tag does not fire, review trigger conditions, exceptions and consent state. If the tag fires but no request leaves the browser, investigate execution errors or blocking. If a request leaves but expected data is absent, check the destination, parameters and processing context.
These are diagnostic branches, not guaranteed causes. In the Pink Balloon project, a storage-related problem interrupted processing. That observation should not become a blanket instruction to change storage settings on other sites.
Need help tracing the gap? Start with a GA4 and GTM audit, or read about custom form-success tracking.
