A developer shows HTTP 200 and proposes closing the analytics task. The marketer opens the report, but the purchase is missing. Both are looking at real observations, just at different stages of the route. Your job is to connect them and identify the first transition without supporting evidence.
For each case, record the known fact, next check and completion condition. This is a written self-check; the figures are illustrative. Use a test environment or approved records without personal data for the practical work.
Case: the request arrived, but nothing was sent onward
The browser sent a request to a server-side endpoint. The server returned HTTP 200. The container's preview shows the incoming request and an event object. There is no outgoing request to the intended analytics platform.
A colleague suggests waiting for the report to refresh. Name the stage that needs investigation before waiting. Which observations after a repair would distinguish a sent request from a correctly recorded purchase?
Analysis: each stage needs its own evidence
HTTP 200 describes your endpoint's response. The case establishes that the request reached it and an event object appeared. The next unconfirmed transition lies between the server tag's work and sending to the recipient.
sGTM preview shows the incoming request, Client, events, tags, outgoing requests and responses. These let you trace the route in sequence. Evidence of one step does not replace information about the following ones.
You need the intended tag's status, firing conditions and error messages. For a tag that did not fire, look for an unmet condition. For one that failed, examine the error and parameters. Then establish whether it received required fields and whether the expected Client produced the data. HTTP 200 alone cannot identify the precise cause.
After a repair, repeat the same scenario. In the request to the recipient, reconcile the destination, event type, identifier, amount and currency. Read the recipient's response alongside its diagnostics: transport success still leaves questions about processing and inclusion in the intended report.
The completed check follows the entire path: real operation, event, sending, receipt and recording. If test values are correct but a discrepancy remains in production, investigate it separately. 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 should not reach external recipients. A developer created a transformation for one tag and announced that the note had been removed from the entire infrastructure.
Describe how to check the scope. How does an allow-list that permits unnecessary fields differ from one that removes required fields? Which locations remain outside the selected tag's transformation?
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. The first checks are therefore the rule's conditions and affected tags, followed by the actual contents of each outgoing request.
If the rule covers one tag, another may still receive internal_note. Even correct filtering before sending does not retrospectively remove the field from an incoming browser request, proxy or log. Those stages have their own settings and storage locations. Describe the result in terms of the route actually checked.
Allow parameters retains permitted parameters. An overly broad list may allow an unnecessary note through. An overly narrow list can remove a field the tag needs, creating data loss while addressing another risk. Define the list for the recipient's purpose and test the events it uses.
On the test event from the server-tag field analysis, Exclude parameters and Allow parameters produce the same request; on a production event with other fields, the results diverge. Acceptance therefore needs an outgoing request, beyond a screenshot of the setting.
Moving delivery to your own server leaves the team responsible for decisions about data scope, access and permitted destinations. This exercise establishes the filter's technical boundary. Its result cannot replace a legal assessment or establish compliance with every recipient rule.
Case: 130 sends for 100 orders
Another shop's agreed register contains 100 paid orders. Over the same period, its log records 130 attempts to send a purchase event. Every 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 proposes deleting rows with identical amounts. Why is neither approach suitable? Define a reconciliation key and list the statuses the check needs to produce.
Analysis: retries and missing events can coexist
Initially, you know of 100 business operations and 130 transport attempts. A difference of 30 does not yet describe the duplicate count: some purchases may be absent while others have several retries. Event types and period boundaries also need to match.
Join the register and log using a stable business-event identifier and event type. A separate attempt identifier distinguishes repeated sends. For each order, retain timing, attempt count, outcomes and confirmation of processing by the recipient. Investigate records without a register match separately; do not join them by amount.
Suppose reconciliation establishes the following:
| 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 |
The counts reconcile: 96 + 34 = 130 attempts, while 96 + 4 = 100 orders. The shop's revenue under the case conditions is 100 × 10,000 = 1,000,000 ₸. Summing every attempt overstates it by 300,000 ₸. Retaining only unique orders from the log produces 96 × 10,000 = 960,000 ₸, which is 40,000 ₸ below the register.
Extra attempts and omissions therefore coexist. Removing repeated amounts would leave just one value of 10,000 ₸ here, despite the shop having 100 distinct orders. A stable key connects the operation; an identical price does not.
The table does not yet show what the platform recorded. Retries may have been handled under its rules, rejected or counted again. Consistent deduplication requires the event type and identifier that the recipient supports for one operation. For omissions, identify the cause and establish a safe delivery method that preserves the operation's original identity.
Exercise: document the diagnosis
Choose one test route from your project. Record the operation and its key, expected fields, sender, recipient and evidence at each transition. Attach an approved log excerpt or describe the observations. Assign an owner to the first unconfirmed stage and define the repeat test that will establish acceptance.
A useful record lets another specialist repeat the check. “There is an HTTP 200” is insufficient without naming who responded and to which request. “Duplicates removed” needs a key, the unique-operation count and reconciliation with the register. Even if totals agree after a repair, fields and missing operations still need checking: matching totals can hide different errors.