Zhandos, the developer, shows an HTTP 200 and suggests closing the analytics task. The marketer opens the report, and the purchase is not there. Both are describing what they really see; they are just looking at different stretches of the route. Your job is to join their observations and find the first transition that nothing confirms.
For each case, write down what is known, what you check next and what will tell you the work is done. This is a written self-check, and the numbers in the examples are made up. For the practical part, use a test environment or approved records without personal data.
Case: the request arrived, but nothing was sent onward
The browser sent a request to a server-side endpoint, and the server answered HTTP 200. The container preview shows the incoming request and an event object. But there is no outgoing request to the analytics platform it was meant for.
A colleague suggests waiting for the report to refresh. Which stretch needs investigating before anyone waits? And which observations will you need after the fix to tell a sent request from a purchase the platform recorded correctly?
Analysis: each stage needs its own evidence
HTTP 200 is your endpoint's response. The case tells you the request reached it and an event object appeared. So the first unconfirmed transition lies between the server tag doing its work and the send to the recipient.
sGTM preview shows the incoming request, Client, events, tags, outgoing requests and responses, so you can walk the route step by step. But a step that passed does not confirm the ones after it.
Each stage needs its own evidence
Endpoint
Incoming request accepted, HTTP 200
An event object appeared
Server tag
Check status, conditions and errors
Client and required fields also need checking
Recipient
No outgoing request
Incoming HTTP 200 does not confirm a send to the platform
HTTP 200 alone cannot identify the exact cause. Repeat the same scenario after the repair.
Look at the tag's status, its firing conditions and any error messages. If the tag did not fire, find the condition that was not met. If it failed, read the error and its parameters. Then find out whether the tag got the required fields and whether the right Client built the data. A single HTTP 200 will not give you the exact cause.
After the fix, run the same scenario again. In the request to the recipient, compare the destination, event type, identifier, amount and currency. Read the recipient's response together with its diagnostics: the request was delivered, but how the platform processed it and whether it reached the right report is still not clear from that response.
In the end, the check covers the whole path: the real operation, the event, the send, receipt and recording. If everything matches on test values but a gap remains in production, that gap becomes the next task. One successful test does not describe every event in a month.
Case: a field was hidden from one tag
The event object contains internal_note, an internal note that external recipients do not need. Zhandos created a transformation for one tag and announced that the note had been removed from the whole infrastructure.
How will you check what the rule actually applies to? What is the danger of an allow-list that lets extra fields through, and of one that cuts needed ones? Which places stay outside the transformation of the chosen tag?
Analysis: check the filter for each recipient
sGTM transformations change event-data parameters. By default a rule applies to all tags; the Affected tags section narrows it to tag types or individual tags. So you look at the rule's conditions and the list of affected tags first, and then at the actual data in every outgoing request.
If the rule covers one tag, another may still be receiving internal_note. And even a correct filter before sending will not retroactively remove the field from the incoming browser request, a proxy or a log: they have their own settings and their own storage. So state your conclusion only for the route you actually checked.
In Allow parameters mode, only the permitted parameters stay. A list that is too broad may let the unneeded note through. A list that is too narrow cuts a field the tag cannot work without, and you trade one risk for lost data. Build the list around what the recipient needs and test it on the events it receives.
On the test event from the server-tag field walkthrough, Exclude parameters and Allow parameters produce the same request; on a production event with other fields, the results diverge. That is why the work is accepted on the outgoing request; a screenshot of the setting is not enough for that.
When sending goes through your own server, decisions about which data goes where, who has access and which destinations are allowed stay with the team. In this exercise, it is enough to confirm the filter's technical boundary. Such a check does not replace a legal assessment or compliance with every recipient's rules.
Case: 130 sends for 100 orders
Another shop has 100 paid orders in its agreed register, while its log for the same period holds 130 attempts to send a purchase event. Each order is worth 10,000 ₸. For this calculation, all orders are paid, there are no cancellations or refunds, and each purchase should be counted once.
The team sees amounts totalling 1,300,000 ₸ in the log. One employee calls it sales growth; another suggests deleting rows with the same amount. Why does neither work? Build a reconciliation key and list the statuses you need to get.
Analysis: retries and missing events can coexist
At the start you know of 100 business operations and 130 transmission attempts. A difference of 30 is not yet the number of duplicates: some purchases may never have gone out, while others may have been retried several times. The event type and period boundaries also have to match.
Join the register to the log on a stable operation identifier and the event type. A separate identifier for each attempt helps you tell retries apart. For every order you need the time, the number of attempts, their results and confirmation that the recipient processed the event. Records that do not match the register get investigated separately and are never attached to orders by amount.
Suppose reconciliation shows this:
| Reconciliation result | Count |
|---|---|
| Unique orders represented in the log | 96 |
| Additional attempts for those same orders | 34 |
| Paid orders with no send attempt | 4 |
| Total attempts in the log | 130 |
It all adds up: 96 + 34 = 130 attempts, and 96 + 4 = 100 orders. Under the case conditions, the shop's revenue is 100 × 10,000 = 1,000,000 ₸. The sum over all attempts overstates it by 300,000 ₸. Keeping only the unique orders in the log gives 96 × 10,000 = 960,000 ₸, which is 40,000 ₸ below the register.
Extra attempts and gaps live side by side here. And if you delete rows with the same amount, a single 10,000 ₸ value is left, although the shop has 100 different orders. A stable key links an operation; an identical price cannot do that job.
What the platform has already recorded out of all this, the reconciliation cannot tell you. It may have handled the retries by its own rules, rejected them or recorded them again. Deduplication works when the type and identifier of one event match the way the recipient requires. For the gaps, first find the cause and a safe way to resend the event, keeping the operation's original identifier.
Exercise: document the diagnosis
Take one test route from your own project. Write down the operation and its key, the expected fields, the sender, the recipient and the evidence at each transition. Attach an approved log excerpt or describe what you observed. Name an owner for the first unconfirmed stretch and write down the repeat test the work will be accepted on.
A good record lets another specialist repeat your check. "There is an HTTP 200" gives them nothing without saying who answered and to which request. "Duplicates removed" needs a key, the count of unique operations and a reconciliation with the register. Even if the totals agree after the fix, you still have to confirm the fields and that no operation went missing: identical totals can hide different errors.