DM5: Tracking: events, tags and measurement plans

Lesson 5 of 5 · reading 15–25 minutes; practice and project time is on the module page

Testing tracking before you trust it

🎯You'll be able to

Check events with browser tools and automated tests, find doubled, missing and malformed events, and run a tracking QA checklist before release.

🏠The everyday picture

Before a wedding, someone counts the chairs, checks the sound system and walks the route from the gate to the hall. Finding a problem the day before is far better than during the ceremony.

📘What it really is

Look at the requests: the browser's Network tab (filter for the collection address), the tool's debug view, or MittiMart's terminal output.
Automate the checks: a browser test that runs a journey and captures every request (Project 1's tests use Playwright to do this).
A QA checklist for each release:
no request before consent; none after Reject;
each event fires once, at the right moment;
names and parameters match the plan; values are numbers in the stated unit;
no personal data in any event or address;
purchases aren't doubled by reloads or back buttons;
campaign tags survive the visit.
Doubles: a thank-you page reload sends a second purchase. Guard it with the transaction_id: remember which orders were sent (MittiMart's solved shop.js keeps a list in localStorage).
Tag managers (such as Google Tag Manager) let marketers add tags without a code release, with preview modes for testing; they need the same checklist and change control. Not verified in this kit.
Monitor after release: sudden drops or spikes in an event usually mean a tracking change, not a change in customers.

📝A worked example

Input: Project 1's test 7 reloads the thank-you page twice.

Steps:

On the starter, read the failure: three purchase events for one order.
In shop.js, before sending purchase, check a stored list of sent order IDs; send only if this ID isn't there, then add it.
Run the test again.

Expected output: one purchase per order, however often the page is reloaded.

🌍Where it's used

Analytics engineers run automated tracking tests in the release pipeline.
Agencies use tag manager preview modes before publishing.
Finance teams compare analytics revenue with orders to spot drift.

📝Case scenario

After a redesign, a shoe shop's conversion rate doubled overnight. Nobody had improved anything: the new thank-you page sent purchase twice. Two weeks of campaign decisions had been made on doubled numbers before an analyst compared them with the order database.

🖱️Try it

Run npm run test:tracking on your Project 1 work and read the first failing test's message. Fix just that, and run it again. Success: one more test passes, and you can say what the event looked like before and after.

⚠️Common mistakes

Trusting tracking because the report has numbers. Sign: no one has checked the events. Fix: a QA checklist and automated tests.
Doubled purchases. Sign: a jump in conversion after a release. Fix: guard with transaction_id, and compare with orders.
Changing tags without the plan. Sign: a new event no one documented. Fix: plan, code and tests in one change.

🛠️For your project

Project 1's ten tests are a tracking QA checklist in code; all ten should pass, twice in a row, before you trust MittiMart's data.

✅Quick check

How do you stop a purchase being counted twice when the thank-you page is reloaded?

Show the answer

Remember the transaction_ids already sent, and send purchase only for a new one.

What does a sudden doubling of conversions after a release usually mean?

Show the answer

A tracking problem, such as an event firing twice, until checked against orders.