MVA / FIELD GUIDES / Conversion tracking
Before the redesign: the tracking you cannot afford to lose.
The new website can look better while quietly losing the measurement your team relies on. Put the important journeys in the brief before the old site disappears.

Do this while the old journey still exists.
A redesign can change the things tracking depends on: page paths, form behavior, button markup, checkout steps, and embedded tools. The old tags may load perfectly and still miss the outcome the team needs.
Start with a short inventory of important business actions. Accepted inquiries, completed purchases, and meaningful signups each need an agreed definition. For each, record where it happens, how it is measured now, where the business record goes, and who owns the next implementation.
Carry the outcome forward, not just the tag.
| Keep in view | Current site | Redesigned site | Before signing off |
|---|---|---|---|
| Business outcome | An accepted contact inquiry. | The same outcome, even though the form design changes. | Agree on acceptance and delivery definitions. |
| Success signal | A thank-you page marks completion. | The new form confirms success on the same page. | Use the actual acceptance result, not the old page URL. |
| Implementation owner | GTM uses the old journey. | A developer exposes the result; the tracking owner maps the event. | Name both owners in the launch brief. |
| Validation | Existing behavior provides a reference. | Successful and rejected requests follow new paths. | Review both paths and the receiving destination. |
The event name can stay the same while its trigger needs to change. Copying the old container alone would not resolve this example.
The worksheet is a requirement for the people building and tagging the site. It is not evidence that the new behavior has been implemented. Keep that distinction visible in the launch plan.
Give developers something they can act on.
- Outcome: What must have happened for this event to count?
- Signal: Which reliable result should the site expose for measurement?
- Destinations: Which agreed analytics or advertising systems need the event?
- Ownership: Who changes the site, who changes the tracking, and who reviews both?
- Evidence: Which successful and unsuccessful journeys will be checked before and after launch?
Include external forms, cross-domain journeys, consent behavior, and third-party tools when they matter to the outcome. Avoid filling the brief with every click anyone might someday want. Prioritize the decisions and business actions the team actually depends on.
Launch needs its own check.
The tracking owner can use GTM Preview to inspect a draft configuration before publication. Ask for checks of the deployed site and its live configuration after launch too. A successful preview of the draft is useful evidence for that draft; the launch can change the conditions.
Have the team walk the agreed journeys again. Check the event reaches the intended destination, rejected requests do not produce the acceptance signal, and the inquiry reaches the business system. Document the launch date and any changes to metric definitions.
If collection improves at launch, the conversion line may rise without a corresponding rise in actual inquiries. Give a measurement change its own explanation beside the chart.
An inventory can also reveal old measurement you no longer need. Retire it deliberately, with an owner and a reason. The goal is a new site that preserves useful measurement, with a clear record of what changed.