When checking Shopify tracking, I start with an action I can repeat: submitting a form, adding an item to the cart or completing the relevant test flow. Then I look for the expected event.
Seeing a tag in an interface is not enough. I need to know when it fires and what it sends.
Follow the event from the user action
User action → Event → Parameters → Measurement → Report.
For an add_to_cart check, I look at whether the event fires once and carries the expected context. If the result is unexpected, I check the trigger and data layer before treating the report as evidence that the setup works.
Shopify tracking can involve several implementations
My QA work has involved GA4, GTM, Meta Pixel and Shopify Customer Events. Investigations include duplicate events, missing purchase parameters, data-layer issues and differences between browser and platform signals.
These were separate investigations, not every problem in one store. The useful next step depends on which signal I can reproduce and where it differs from the expected result.
Keep implementation and reporting scopes separate
My experience includes GA4/GTM implementation work across 20+ client websites, with responsibilities varying by site. I also worked on a reporting framework covering 40+ maintenance websites.
The reporting framework and the event checks are separate parts of this work.
Write down what the check actually proves
I want to be able to repeat the action and explain the event and parameters it produced. I reproduce the event and check its parameters before relying on the report.
A successful check covers that scenario. It does not establish that every browser, consent state or attribution path will behave the same way.