Start with decisions, not tracking tools
A website redesign changes the pages, forms, navigation, content model, and technical foundation that produce your marketing data. If your team waits until launch week to discuss analytics, developers must retrofit tracking around decisions that have already hardened into code.
Start with the decisions your team needs to make after launch. A B2B company may need to know:
- which pages support qualified inquiries
- which offers attract the right buyers
- where visitors leave a high-intent path
- which campaigns produce accepted leads
- how prospects move from a website action into the CRM
- whether regional or product-specific journeys need separate reporting
Each question should have an owner and a response. If pricing-page engagement falls, who reviews the page and what can that person change? If a form sends records to the wrong CRM queue, who fixes the mapping? Reports without owners become expensive wallpaper.
Keep the first plan short enough to maintain. Your team needs a trusted set of buyer actions more than a catalog of every click, scroll, and hover.
Separate key events from useful context
Google Analytics records interactions as events. Your team can mark the events that matter to the business as key events. That distinction gives the measurement plan a useful hierarchy.
A primary key event should represent a meaningful step in the buyer journey. Examples may include:
- a confirmed consultation request
- a qualified demo request
- a completed application
- a product signup
- an accepted event registration
Supporting events explain the path without carrying the same weight. Pricing-page views, case-study engagement, calculator use, resource downloads, and contact-link clicks can help your team interpret intent. They do not all deserve key-event status.
Document why each event exists. Use this structure:
| Field | What to define |
|---|---|
| Business question | The decision the event supports |
| Event name | The stable name used across systems |
| Success state | The point when the action counts |
| Parameters | Approved context sent with the event |
| Destination | GA4, CRM, ad platform, or warehouse |
| Owner | The person accountable for definition and QA |
| Test case | The steps and expected result |
This table becomes part of the redesign scope. It tells designers which states need feedback, developers which events to emit, and marketers what the reports mean.
Define the success state for every conversion
A button click is easy to track. It is often a weak conversion signal.
Consider a consultation form. The visitor can click submit while required fields contain errors. The browser can send the form while the CRM rejects the record. A spam bot can complete the request. One interface action can produce several business states.
Choose the state that matches the question:
- Submission attempted: the visitor tried to submit.
- Submission confirmed: the website accepted the form.
- CRM record created: the destination system received it.
- Lead accepted: your rules or team accepted the record.
- Opportunity created: sales qualified the lead into a pipeline stage.
The website can report the states it knows. The CRM owns later sales states. Your plan should define the shared identifier or integration needed to connect them without sending prohibited personal data into analytics.
Do not call all five states “lead.” Precise names keep reports, tags, and CRM workflows from collapsing into one ambiguous number.
Give developers a data contract
A redesign measurement plan needs an implementation contract. For custom websites, the data layer provides a stable interface between the site and tools such as Google Tag Manager.
Define events around business actions, not visual components. An event named consultationrequestsubmitted can survive a new form design. A trigger tied to .hero-form-button breaks when someone changes the markup.
For each event, specify:
- the exact name
- the system that emits it
- the success condition
- required and optional parameters
- allowed parameter values
- privacy restrictions
- expected behavior on repeat actions
- the test environment
Use controlled values where reporting needs consistency. If a form appears on several pages, pass a documented formname or formlocation value instead of whatever heading happens to sit above the component.
Keep names, email addresses, phone numbers, and free-text fields out of default analytics payloads. Ask qualified privacy counsel to set the legal requirements for your markets. Then turn those requirements into technical rules and test cases.
Map forms and CRM handoffs before design approval
Forms sit where UX, development, analytics, privacy, and revenue operations collide. Scope them as systems, not rectangles on a wireframe.
For every form, record:
- the fields and validation rules
- hidden attribution fields
- consent copy and state
- spam controls
- success and error behavior
- CRM destination and field mapping
- routing or notification rules
- analytics events
- fallback behavior when an integration fails
- the person who receives test records
Your design needs states for validation, submission, success, and failure. Your development scope needs the integration and error handling. Your QA plan needs proof that the record arrived with the expected values.
A thank-you message confirms what the visitor saw. It does not prove that sales received the record. Test the complete path from browser to CRM before launch and after the production release.
Decide how attribution enters and leaves the website
Campaign parameters, referrer data, landing pages, and first-party identifiers can help your team understand how a visitor reached the site. Each value has limits. Browsers, consent choices, cross-domain journeys, ad blockers, and return visits can break a clean narrative.
Document the attribution fields the website captures and where they go. If the form sends source data to the CRM, define the field names, overwrite rules, and retention behavior. Decide whether you need first-touch, latest-touch, or both.
Avoid promising perfect attribution. Build a traceable system that shows how each platform produced its numbers. Your reporting owner should know which data comes from the website, analytics platform, CRM, and sales process.
If a visitor moves between your marketing site, booking tool, account application, and product, map those domains during discovery. Cross-domain measurement and referral handling belong in scope before developers integrate the tools.
Set consent and regional rules before tags
Consent requirements affect which tools load, which identifiers persist, and which events reach each destination. Treat those requirements as part of the architecture.
Create a matrix that connects:
- visitor region
- consent category
- default state
- approved tags
- storage behavior
- update behavior when a visitor changes a choice
- owner for the requirement
Test a new visitor, an accepting visitor, a rejecting visitor, and a returning visitor. Check the browser requests and the destination platform. A consent banner that changes its visual state without changing tag behavior has not finished the job.
Your legal adviser should decide the legal standard. The design and development team should implement behavior that a tester can verify.
Plan accounts, environments, and access
The business should own the analytics, tag-management, consent, and reporting accounts. Use company-controlled identities and give at least two named employees administrator access. Contractors should use their own identities with access that matches their work.
Define development, staging, and production behavior before implementation. The plan should answer:
- which IDs load in each environment
- where test data goes
- how analysts identify or exclude test traffic
- who can edit measurement configuration
- who can publish changes
- how the team rolls back a bad release
Keep production data out of local and staging builds. Keep production credentials out of source code. Record environment rules in the project documentation so the next developer does not have to reverse-engineer them.
Build acceptance tests into the redesign scope
Measurement QA needs named test cases, not a line item that says “analytics installed.”
For each key event, test the complete path:
- Perform the visitor action.
- Confirm the website emits the expected event once.
- Inspect the approved parameters.
- Confirm consent and environment rules.
- Check the network request or tag behavior.
- Confirm the destination receives the event.
- Verify the CRM record when the event depends on a form.
- Compare the result with the measurement-plan row.
Test errors and repeat actions. Submit invalid data. Trigger an integration failure. Use browser back and forward controls. Change consent. Repeat the conversion. These cases expose duplicate events and false success states.
Run the critical tests in staging, then repeat them on production. Save the evidence with the release record.
Name the reporting owners before launch
A measurement system needs someone to review it after the launch checklist closes.
Assign owners for:
- event definitions
- website implementation
- tag configuration
- consent behavior
- CRM mappings
- dashboards and analysis
- access reviews
- change approval
Set a review rhythm that fits your release volume. The review should catch broken forms, stale tags, new pages without tracking, CRM field changes, duplicate events, and key events that no longer represent the buyer journey.
Add the measurement plan to the website handoff. Include account ownership, event definitions, data-layer documentation, environment rules, consent mappings, test cases, destination IDs, CRM fields, dashboards, and publishing controls.
Use the plan to scope agencies on the same work
A clear measurement plan helps you compare redesign proposals. Ask each agency to state which parts it will own:
| Workstream | Scope question |
|---|---|
| Measurement strategy | Will the agency define business questions and key events? |
| Data layer | Will developers implement and document event contracts? |
| Tag management | Who configures, tests, and publishes tags? |
| Forms and CRM | Who owns mappings, errors, and acceptance tests? |
| Consent | Who implements the approved regional behavior? |
| Reporting | Who builds dashboards and validates definitions? |
| Handoff | Which documentation and account transfers are included? |
If a proposal includes “analytics” without these boundaries, ask the agency to define the deliverables. One team may install a GA4 tag. Another may design the full measurement system. The price difference means little until the scope uses the same nouns.
Virdis handles measurement requirements as part of custom website discovery and development. That keeps forms, events, consent, CRM handoffs, QA, and maintainability connected to the build instead of bolted on after design approval.
Frequently asked questions
When should a website redesign measurement plan be created?
Create it during discovery, before the team finalizes technical scope and starts development. The plan affects forms, data-layer events, consent behavior, CRM integration, environments, QA, and reporting.
What should a website measurement plan include?
Include business questions, approved key events, event triggers and parameters, CRM handoffs, consent rules, account ownership, environment controls, QA cases, reporting owners, and a change process.
Should every form submission count as a conversion?
No. Separate successful submissions from accepted records and qualified opportunities when the systems can support those states. A spam entry or failed CRM handoff should not carry the same meaning as a qualified request.
Who owns measurement after the redesigned website launches?
The business should own the accounts, definitions, and approval policy. Named marketing, development, analytics, and operations owners should maintain their parts of the system. Agencies should hold access that matches their role.
Scope measurement before development starts
If your B2B website redesign needs clean conversion tracking, CRM handoffs, consent behavior, and reporting, define those requirements during discovery. Virdis designs and develops the website and its measurement architecture as one maintainable system.
