Start with business questions
Do not begin with a list of tags. Begin with the decisions your team needs to make.
A B2B marketing team may need to know:
- Which pages contribute to qualified demo requests?
- Which campaigns produce leads that sales accepts?
- Where do buyers leave high-intent paths?
- Which resources assist a later conversion?
- Which site changes affect form completion or meeting bookings?
Each question needs an event, useful context, and a destination. “Track conversions” does not meet that standard. It gives the implementation team no definition of a conversion and gives QA no expected result.
Write each requirement in plain language. For example: “When a visitor submits the enterprise demo form, record one successful demo-request event with the form name, page path, campaign values, and consent state. Send the same source context to the CRM record.”
That sentence gives design, development, marketing operations, and QA one shared target.
Build a conversion event map
Create an event map before anyone rebuilds forms or navigation. The map should cover primary conversions and the steps that help diagnose those conversions.
Primary conversion events
Primary events represent a clear hand raise or commercial action. Common B2B examples include:
- Demo request submitted
- Contact form submitted
- Meeting booked
- Trial or account started
- Sales inquiry completed
Choose names that describe the action. Keep one naming convention across the site. If three forms represent the same business action, use an event parameter to identify the form instead of inventing three unrelated event names.
Supporting events
Supporting events explain what happened before the conversion. They may include pricing-page views, product-page engagement, case study views, resource downloads, form starts, form errors, or key calls to action.
Do not track every click. More events create more maintenance and more ways to misread noise as intent. Track actions that answer a stated business question or help your team diagnose a failed path.
Event context
An event name cannot carry enough detail on its own. Define the parameters your team needs, such as:
- Page path and page type
- Form name and offer
- Product or service interest
- Campaign source values
- Visitor consent state
- Error type for failed submissions
Avoid sending personal information into analytics tools. Keep names, email addresses, phone numbers, and free-form message fields out of analytics payloads. Send lead details to the CRM through the approved form workflow.
Specify form and CRM handoff
A form success message does not prove that the full system worked. Your redesign scope should test the browser event, form endpoint, CRM record, routing rule, and notification.
For each lead form, document:
- The form owner
- Required and optional fields
- Validation behavior
- Spam controls
- Success and error states
- Analytics event and parameters
- CRM destination and field mapping
- Lead source fields
- Routing and notification rules
- The person who checks failed submissions
Capture campaign values before the visitor submits the form. Decide how long your site should retain them and which attribution fields the CRM should receive. If your team uses original-source and latest-source fields, define both. Do not let a developer guess which model sales trusts.
Meeting schedulers need the same treatment. Test the booking confirmation, embedded script behavior, cross-domain flow, CRM activity, and analytics event. A click on “Book a demo” is not the same as a completed booking.
Protect measurement continuity
A redesign changes URLs, templates, forms, scripts, and page structure. Each change can break historical comparisons.
Create an inventory of the current measurement system before replacing it:
- Analytics properties and data streams
- Tag manager containers
- Active tags and triggers
- Conversion definitions
- Form endpoints and CRM mappings
- Consent platform rules
- Reporting dashboards
- Internal traffic filters
- Cross-domain settings
- Campaign naming rules
Record current event names and note which ones the new site will keep, replace, or retire. Preserve names when the business action has not changed. If you rename an event, document the cutover date so reports do not join two different definitions under one label.
Save a baseline before launch. Use a period that reflects normal business conditions, and note campaigns, seasonality, outages, or form changes that could distort the comparison. The baseline will not prove that the redesign caused a result. It gives your team a reference point for investigation.
Define consent behavior with the tracking plan
Consent cannot sit in a footer task. It affects which tags run, when they run, and what data reaches each platform.
Your requirements should name:
- Regions or audiences with different consent rules
- Consent categories shown to visitors
- Default tag behavior before a choice
- Tag behavior after acceptance or rejection
- How a visitor changes a prior choice
- Who owns policy language and legal review
- How QA will test each consent state
Marketing, development, and the consent platform owner should agree on the behavior before implementation. Ask qualified counsel to review legal requirements. The development team should implement the approved rules, not invent them.
Test consent on the production domain after launch. Staging tests help, but domain settings, script permissions, and platform configuration can change the result.
Put the data layer in the development scope
A durable tracking system should not depend on brittle selectors such as button color, visible text, or a chain of page elements. A copy edit or component update can break those triggers without warning.
Ask the development team to expose stable events and values through the site’s data layer or event interface. The implementation should identify the business action and relevant context at the point where the site confirms success.
For a form, fire the conversion event after the server accepts the submission, not when the visitor clicks the button. For a meeting, record completion after the scheduler confirms the booking. For a download, decide whether the business needs the click, the file response, or a gated-form completion.
Document the event contract near the component or integration documentation. Future developers need to know which values other systems expect before they change the component.
Write a launch QA plan
Tracking QA needs named test cases and evidence. “Analytics checked” invites a fast glance and a future argument.
For each primary conversion, test:
- Accepted submission
- Validation error
- Server or integration failure
- Repeat submission
- Mobile and desktop behavior
- Each consent state
- Campaign values
- CRM field mapping
- Lead routing
- Analytics event count
Use test records that your sales team can identify and remove. Capture the page, test time, consent state, expected result, observed result, and owner for each defect.
Check for duplicate events. Tag manager rules, embedded form scripts, analytics libraries, and application code can all record the same action. One demo request should not appear as two leads because two systems listened to the same confirmation.
Run a production smoke test after deployment. Confirm the live domain, forms, scheduler, CRM, consent behavior, and analytics collection. Then monitor the first days of data for gaps or sudden count changes.
Assign ownership after launch
The agency can build the system, but someone inside the business needs to own its definitions.
Name owners for:
- Event and parameter documentation
- Tag manager access
- Analytics access and settings
- CRM field definitions
- Consent configuration
- Dashboard logic
- Monthly data checks
- Release QA for future site changes
Require a handoff that includes account access, container or property identifiers, the event map, test evidence, known limitations, and instructions for common changes. Avoid shared personal logins. Give each person the access their role needs.
Add tracking checks to the website release process. A new form, campaign landing page, scheduler, or consent change can alter measurement long after the redesign team leaves.
Use these requirements to compare redesign proposals
Ask each agency to show where its scope covers:
- Measurement planning
- Event and parameter specification
- Data-layer development
- Form and CRM integration
- Consent implementation
- Staging and production QA
- Documentation and handoff
- Post-launch monitoring
If a proposal lists GA4 and GTM installation without these deliverables, it covers tools rather than a working measurement system. Ask who will define conversions, test the CRM handoff, resolve duplicate events, and document the result.
Virdis treats analytics as part of the website system. We connect conversion paths, component behavior, integrations, QA, and maintainability so marketing teams can inspect the site without rebuilding their tracking after each release.
Frequently asked questions
Should we keep our current GA4 property during a redesign?
In most redesigns, keep the existing property when the business and measurement scope remain the same. Preserve useful history, document event changes, and test the new data stream setup before launch.
Should form submissions fire on button clicks or success messages?
Record the conversion after the form system confirms a successful submission. Button clicks include validation failures, network errors, and repeat attempts that did not create a lead.
Who should write the conversion tracking requirements?
Marketing should define business questions and conversion meaning. Marketing operations should define CRM and reporting needs. The agency or development team should turn those definitions into a technical event contract and QA plan.
How do we know whether tracking survived the launch?
Run production test conversions, verify each system in the chain, check for duplicates, and compare early event patterns with the documented baseline. Investigate count changes before calling them redesign results.
