In this article
1. Confirm the action
Write down the exact action the event represents. For a purchase, identify the business-system evidence that makes the order eligible. For a lead, distinguish a button click from a successfully accepted submission. Then perform one known action and confirm that the observed event matches the definition.
Include a nearby action that should not qualify. A failed payment or rejected form is a useful test because it challenges the trigger logic. A review that checks only the successful path leaves an important part of the event definition untested.
2. Check the important values
Choose a few values that make the event useful: its identity, amount, currency, or relevant product information. Compare them with the source system, not with another report derived from the same tracking implementation. Use test cases that can reveal formatting or mapping mistakes, such as an order containing multiple items.
3. Repeat the journey
Reload, navigate back, and repeat the action where the test environment allows it. Write the expected event count and identity behavior in advance. This helps distinguish a repeated delivery from a genuinely new business action.
If more than one integration can report the event, inspect all relevant paths. Record who owns each integration. The person reviewing the server container should be able to identify the related browser or application behavior without guessing.
4. Exercise consent choices
Test the consent states your implementation supports, including a changed choice. Google's server-side consent-mode documentation explains how consent information travels from the web implementation and influences Google product tags. Use the configured behavior as an acceptance criterion, and review other destinations against their own requirements.
Record what you expected to be collected or sent in each state, then compare the observed result. This turns a general statement about consent into a review that another teammate can repeat.
5. Inspect the destination
Server-container preview can show outgoing requests and the responses returned by destination endpoints. Inspect the destination and payload, then use the destination's own verification tools where available. A fired tag is one piece of evidence, rather than the entire acceptance test.
Finish with a compact record: test action, expected result, observed result, configuration version, and reviewer. Keep unresolved issues visible. A small review that the team repeats after meaningful changes is more useful than a large checklist completed once and forgotten.
