A manager sees a new lead, a developer shows a record in the dataLayer, but analytics has no event. The team proposes moving the sending process to a server. Before changing infrastructure, find the point where the current path broke; otherwise the same error may move into the new stack.
Record your decisions for the three exercises and the observations that would confirm them. Then compare them with the walkthroughs. The site does not grade these notes. All data are illustrative; lead_sent and lead_submit were invented for this exercise and do not replace event names in the Start track.
Situation 1: the event appeared, the request did not leave
After a successful form submission, the site records lead_sent in the dataLayer. The required tag is configured for lead_submit. When you reproduce the action in debugging, the event is visible, the tag does not fire, and no network request goes to the destination.
Choose an action and explain what you expect to observe afterwards:
- A: wait for the data to appear in the report;
- B: agree on the event name, fix the mismatch and submit the form again;
- C: immediately move the sending process to a server.
The diagram shows how far the check has reached:
Situation 2: the ad report and CRM disagree
The ad account shows 40 conversions, while the CRM shows 25 paid orders for the same calendar period. The owner concludes that the system lost 15 sales. However, the ad account calls a form submission a conversion, while the CRM counts payments.
What can you conclude immediately? Which definitions, dates and records do you need before investigating data loss? Write a reconciliation sequence that does not begin by trying to make the two totals identical.
Situation 3: revenue grew after a join
In the orders table, order 101 has a total of 10,000 ₸. The line-item table contains two products for that order. Joining the tables by order ID produces two rows, each repeating the full 10,000 ₸ order total. The report sums that field and shows 20,000 ₸.
Explain what happened to the row and which result is needed. Then add order 102: it also totals 10,000 ₸, but contains one line item. How many rows will the join produce, what total will the old calculation return, and how much revenue was in the original orders? Would summing only distinct monetary values help?
Walkthrough 1: fix the unconfirmed transition
Option B is justified in the first exercise. The GTM data layer passes data and events that tags can respond to. A record confirms that step. Sending data further requires the conditions to be met and the required tag to run.
Here, the reason it did not fire is known: the name in the condition does not match the event name. Check the agreement with the developer. If the site correctly implements the agreed lead_sent, change the trigger. If the agreement was lead_submit, change the site code. The choice depends on the agreed specification; blindly renaming an event in one place can affect other consumers.
After the fix, repeat a successful form submission. See whether the required tag fired, a request went to the correct destination, and the parameters match the submitted form. Then confirm receipt at the destination and appearance in the appropriate report after processing. Each step answers a different question. "Tag fired" does not yet establish that the address, data and subsequent processing are correct.
Option A overlooks the absence of the request itself: waiting for a report cannot create a send. Option C changes the system's architecture even though the break has already been located in the firing condition. A server route may address other needs, but the name correction can be tested in the current setup.
Add a negative check: a form with an error should not generate a successful-lead event. Reopening the page should not turn one lead into another. If you find these cases, record them separately and fix their cause before publishing. The event count should match the agreed definition of a lead.
Walkthrough 2: agree on what is being counted
The subtraction 40 - 25 = 15 is arithmetically correct, but it does not establish "15 lost sales". A form and a paid order belong to different stages. One person may submit several enquiries, some people are still deciding, and payment may occur in a different period.
For each report, record the event, source, advertising attribution rules, date, time zone and treatment of duplicates. Establish which time defines the period: form submission, ad interaction or payment. Then choose a comparable definition and a sufficiently long window for leads to reach the outcome. Set that duration from the project's sales process.
To check the connection, use lead and order identifiers you are permitted to access. Trace several records from the form to the CRM: was a lead created, did a payment occur, was it cancelled, and which period contains the record? Do not copy customer names, phone numbers or other unnecessary personal data into the shared investigation.
If one payment has no linked lead, that is a separate discrepancy with a location and a cause to investigate. The rest of the difference cannot automatically be declared the same error. Reconciliation aims to explain what makes up the difference. Afterwards, the reports may still have different totals if they continue to count different events.
Walkthrough 3: return the calculation to order level
In the original table, one row represented an order. After the join, a row represents one of its line items. The complete order total appears on each item, so summing it directly multiplies the money by the row count.
| Order | Order total | Line items | Contribution to the incorrect sum |
|---|---|---|---|
| 101 | 10,000 ₸ | 2 | 20,000 ₸ |
| 102 | 10,000 ₸ | 1 | 10,000 ₸ |
| Total | 20,000 ₸ | 3 | 30,000 ₸ |
Order 101 still contributes 10,000 ₸ in revenue. The correct total for both orders is 10,000 + 10,000 = 20,000 ₸, while the old method produces 2 × 10,000 + 1 × 10,000 = 30,000 ₸. Joining tables created no new payments.
You can calculate revenue from one confirmed record per unique order. Another approach works when product rows have their own amounts and the treatment of discounts, delivery and returns is clear: reconcile those amounts to the order total first. Repeating the complete order total on each row does not turn it into a line-item amount.
SUM(DISTINCT amount) will not solve this problem. Different orders in the example have the same value, so removing repeated monetary values leaves only 10,000 ₸. Distinguish orders by ID. When analysing tables with AI, this check matters even for a syntactically valid query: an assistant can build a working calculation at the wrong row level.
Exercise on your own project
Choose one event and one report from your project. For the event, record the expected reason for sending, its name, required parameters and destination. For the report, define what one row represents and which business action enters the total. Keep observations for one permitted test record at each stage.
If you do not have site access yet, practise the event and tag in the training sandbox, using the names in the exercise itself. Then calculate the two orders above without hints and explain why the ID must remain available when joining tables.
The completed investigation should let another person repeat the route. "Analytics is broken" is insufficient; "the event exists, the required tag did not fire, and the condition has a different name" defines a testable correction. For the report, provide the original and resulting totals and explain the row count. After fixing the issue, repeat the same example, including a case where no event should be sent. Close the task based on an observed result, and keep any unknown section marked as such.