Website Analytics Setup Checklist Before Launch

Define the buyer actions before you touch tags

Start with the business actions, not the tool settings.

List the actions that should matter after launch:

• demo request submitted
• contact form submitted
• consultation or call booked
• pricing page viewed
• case study viewed
• resource downloaded
• newsletter signup completed
• outbound sales email click landing on the site
• qualified tool or calculator completion

Then decide which actions deserve key event status in GA4 and which actions need supporting context.

A founder does not need a dashboard filled with every scroll, click, and tab change. The team needs a clean view of how qualified buyers move from a channel to a page to a conversion point.

For custom websites, this decision should shape the build. If a form, CTA, or resource matters to pipeline, the frontend should expose a stable tracking point. Do not depend on brittle selectors that break when someone changes a button label next month.

Map the analytics plan to the site structure

Your analytics plan should match the production URL plan.

Create a simple tracking map with these columns:

The map gives designers, developers, and marketers the same target. It also prevents a common launch mistake: the team adds tracking after the site structure has already made clean measurement hard.

Use the map during QA. Every row should produce a test result before launch.

Audit Google Tag Manager container rules

If the site uses Google Tag Manager, treat the container like production code.

Check these items before launch:

• the production container ID appears on the production site and not staging
• staging and preview sites do not pollute production analytics
• tags fire on the intended pages and interactions
• triggers use stable IDs, data attributes, or data layer events
• old tags from the previous site no longer fire
• duplicate GA4 configuration tags do not send double events
• consent settings match the site's cookie and privacy approach

Use preview mode and Tag Assistant to test the full path. Open the page, click the CTA, submit the form, and confirm the tags fire once.

Once is the important word. Double firing can make a launch look stronger than it is. Missing tags can hide real demand. Both problems make the team question the data.

A custom build gives you a better option than guessing from the DOM. Add explicit data layer events for important actions. A button redesign should not break revenue reporting.

Configure GA4 around decisions, not noise

GA4 can collect more data than your team can use. Keep the launch setup tied to decisions.

At minimum, confirm:

• the GA4 property belongs to the right business and domain
• the web data stream uses the production domain
• internal traffic rules exclude the team where appropriate
• enhanced measurement settings match the site behavior
• key events reflect the buyer actions you defined
• custom dimensions capture useful context such as form type, content type, or CTA location
• DebugView receives test events from the production-like environment

Use clear event names. A custom event called formsubmit tells you less than an event that includes form type, page path, and CTA context.

Do not create a new event for every button. Create a small system your team can read six months from now.

For a Virdis-style custom site, the goal is not more tracking. The goal is a maintainable measurement layer that helps the business see which pages and offers create qualified conversations.

Test every form and lead path

Forms break attribution more often than teams think.

Run each form like a buyer would:

1. Land on the page with a tagged URL.
2. Accept or reject cookies based on the site's consent flow.
3. Submit the form with a test contact.
4. Confirm the success message or thank-you page.
5. Confirm the GA4 event.
6. Confirm the contact in the CRM or marketing platform.
7. Confirm the source, medium, campaign, landing page, and form name.
8. Confirm the right notification reaches the right owner.

Do this for every form that matters. Contact forms, demo forms, newsletter forms, gated resources, embedded calendar forms, and product-qualified lead flows can behave in different ways.

If the CRM record lacks source data, the launch did not pass analytics QA. The website captured a lead, but the business lost the context that helps sales follow up and helps marketing decide what to improve.

Standardize UTMs before campaigns point at the new site

UTM cleanup after launch wastes time.

Write the naming rules before traffic starts moving:

• lowercase source and medium values
• one approved source name for each platform
• one approved medium list, such as organicsocial, paidsocial, email, referral, or cpc
• campaign names that match the team's reporting structure
• content values for meaningful CTA or creative differences
• no personal shorthand that one person understands

Then test the most common campaign URLs.

Open each URL, submit a form, and confirm that the UTM values reach GA4 and the CRM. If the site strips parameters, rewrites URLs, or loses attribution across redirects, fix that before launch.

A redesign often changes URLs, redirects, and landing page structure. That makes UTM testing part of migration QA, not a marketing afterthought.

Check redirects against attribution

Redirects can preserve SEO and break analytics at the same time.

During launch QA, test the paths that matter:

• old campaign URLs
• old service page URLs
• old blog posts with active backlinks
• high-intent landing pages
• thank-you pages or post-submit routes
• URLs used in email sequences or sales decks

Confirm that redirects keep the campaign parameters intact. A redirect that drops UTMs can make a working campaign look unattributed.

Also confirm that redirected URLs land on the right intent match. Sending an old pricing page to the homepage may preserve traffic, but it can destroy the buyer context that made the visit valuable.

Separate team traffic from real visitors

Launch week creates noisy data.

Designers refresh pages. Developers test forms. The founder opens the site from five devices. The team shares links in Slack. If you do nothing, that activity can distort launch reporting.

Create a plan for internal traffic:

• IP filters where they fit
• developer and staging environments separated from production data
• test form submissions marked with clear names
• QA events reviewed in DebugView before public launch
• internal launch checks kept out of campaign reporting where possible

You may not remove every internal visit. That is fine. The goal is to keep launch reports from telling a story built on team activity.

Build a post-launch analytics QA routine

Pre-launch QA catches setup mistakes. Post-launch QA catches real-world behavior.

Check the data after the first day, first week, and first campaign push:

• Are key events firing at believable volumes?
• Do source and medium values look clean?
• Do top landing pages match the launch plan?
• Do forms create CRM records with the right fields?
• Do thank-you pages or success events line up with actual submissions?
• Do redirects preserve campaign parameters?
• Do excluded internal visits stay out of core reporting?

Do not wait a month to learn that the main demo form never sent source data. Launch analytics deserve the same urgency as visual bugs.

The website analytics setup checklist

Use this before launch:

1. Define the buyer actions that matter.
2. Decide which actions count as GA4 key events.
3. Map events to pages, templates, CTAs, forms, and CRM destinations.
4. Confirm the GA4 property and web stream belong to the production site.
5. Separate staging and production tracking.
6. Test Google Tag Manager tags in preview mode.
7. Remove old or duplicate tags.
8. Use stable data layer events for important actions.
9. Test every form from landing page to CRM record.
10. Confirm source, medium, campaign, landing page, and form name fields.
11. Standardize UTM naming rules.
12. Test campaign URLs through redirects.
13. Preserve UTMs on redirected URLs.
14. Filter or label internal traffic.
15. Review GA4 DebugView with test events.
16. Check reports after launch day and the first campaign push.

Where analytics fits in a custom website project

Analytics should not sit in a separate tab at the end of the project.

The tracking plan affects CTA structure, form architecture, CMS fields, routing, redirects, thank-you states, and CRM integration. If the team waits until the site is built, analytics QA turns into patchwork.

The better path: plan the measurement layer while the website system takes shape. Then the site can launch with design, development, content, and reporting pointed at the same business outcome.

That is how a custom website earns trust after launch. The team can see what buyers did, where leads came from, and which parts of the site deserve the next round of improvement.

Frequently asked questions

Should analytics setup happen before or after website launch?

Analytics setup should happen before launch. Post-launch review still matters, but the team should test GA4, Tag Manager, forms, UTMs, redirects, and CRM routing before production traffic arrives.

What should count as a GA4 key event on a B2B website?

Use key events for actions tied to business value, such as demo requests, contact forms, consultation bookings, resource downloads, or qualified tool completions. Keep minor clicks as supporting events.

Do small B2B websites need Google Tag Manager?

Not every site needs Tag Manager, but many marketing teams use it because it gives them a controlled way to manage analytics and campaign tags without redeploying the site for every change.

How do you know if launch tracking works?

Test the full buyer path. Visit the page with UTMs, submit the form, confirm the GA4 event, inspect the CRM record, and check that source, medium, campaign, landing page, and form details survived.