Analytics Setup and Measurement Foundations

Measure Decisions, Not Everything

Different evidence answers different questions. One dashboard cannot replace all of it.

Analytics cannot prove that a URL is indexed. Search Console cannot explain every action a visitor takes on the site. A Lighthouse run is not a conversion report. Keep each tool attached to the question it can answer.

For ongoing, low-pressure interpretation after setup, continue to Analytics Without Panic.

Start With a Measurement Plan

Write the purpose of the page before choosing metrics. Then move from purpose to decision:

The example defines a structure, not a universal target. A useful target must come from the site's purpose, existing evidence, capacity, and a realistic review period.

Avoid treating page views, session duration, or a low bounce rate as automatic success. A visitor may get a phone number quickly and leave, which could be a successful visit. The metric needs context.

Define a Baseline Before You Change the Site

A baseline is the recorded starting point used for comparison. Collect only metrics that help answer the measurement question:

• the exact page or journey being changed
• the primary outcome count and rate
• relevant landing-page visits or users
• traffic source and device breakdown when they could affect the result
• the measurement period and any known campaign, outage, or seasonal influence
• the analytics configuration and event definition used
• a performance baseline when speed is part of the change

There is no universal good conversion rate, traffic number, or engagement score. Compare the site with its own purpose and earlier evidence. Small samples are volatile, so report the count as well as the rate and avoid confident conclusions from a handful of visits.

For repeatable lab and field performance evidence, use Measuring Website Performance. For limits and retesting rules, use Performance Budgets and Continuous Improvement.

Start With the Analytics You Already Have

Start with the smallest tool that answers the site's questions and can be maintained responsibly.

GraphitEdge already uses Vercel Web Analytics through the @vercel/analytics Vue package. The analytics component is mounted once in the root application, so page loads and client-side route changes can be measured without adding another provider merely for this lesson.

Vercel documents a limited free allowance for Hobby projects. Features such as custom events and longer reporting windows depend on the current plan. Check the current limits before designing a measurement plan, and use page-view, referrer, device, and route evidence when those are the features available to you.

Do not install several providers for comparison on a live site unless there is a defined, time-bounded evaluation and permission to collect the data. Extra trackers increase maintenance, privacy review, and performance work. A paid Plausible or PostHog account is not required to complete this lesson.

Privacy and Data Minimisation

Analytics configuration is a data decision, not just a code snippet.

• collect only what supports a named measurement question
• do not place names, email addresses, account IDs, form contents, or other personal details in page URLs or event properties
• review consent requirements for the site's users, location, tool, and configuration
• restrict account access and review retention settings
• document each event, its purpose, and its owner
• test that rejected consent is respected where consent is required
• remove unused trackers and stale events

Privacy and consent obligations vary. Use current provider documentation and obtain appropriate legal advice for the site's circumstances rather than copying another site's banner or settings.

Install and Verify the Setup

Provider interfaces change, but the verification workflow is stable:

1. Create or select the correct production property, site, or project.
2. Record the approved domain, data region, retention choice, and account owner.
3. Add the provider's current installation method. Use the real account value rather than a tutorial placeholder.
4. Apply the site's consent rules before sending data that requires consent.
5. Open the deployed site in a clean browser session and use DevTools Network to confirm the expected analytics request.
6. Verify the visit in the provider's live or recent-events view. Allow for the delay described by that provider.
7. Navigate between client-side routes on a Vue site and confirm each intended page view is recorded once.
8. Test one important action and confirm its event name and properties contain no personal data.
9. Record the test date, browser, URL, consent state, expected result, and actual result.

For a Vercel-hosted Vue site, enable Web Analytics for the project, install @vercel/analytics, render its Analytics component once in the root application, deploy, and then check the project dashboard. Verify both a fresh page load and client-side navigation. GraphitEdge already contains this implementation, so learners can inspect it rather than add a duplicate tracker.

For GA4, create a web data stream and install the Google tag directly or through the site's approved tag manager, then use Realtime to verify the visit. Plausible and PostHog remain optional specialist choices for projects that can justify their cost and additional capabilities. Follow the current provider instructions linked in Additional Resources because installation details and plan limits can change.

The production dashboard contains recorded visitor and page-view activity, confirming that the deployed Vercel Analytics integration is collecting data. Summary values have been obscured for privacy.

View full-size Vercel Analytics dashboard

The Pages and Referrers panels provide supporting evidence about where visits occurred and how visitors arrived. They do not prove why a visitor chose a page or whether the visit achieved the site's intended outcome.

View full-size analytics detail

Measure Whether an Optimisation Worked

Define success before changing the site:

1. Write one hypothesis: "Changing X is expected to improve Y because Z."
2. Name the primary metric, guardrail metrics, page scope, and comparison period.
3. Capture the baseline and configuration notes.
4. Make one bounded change where practical.
5. Verify that analytics still records the page and action correctly.
6. Compare a suitable period using the same metric definition and equivalent filters.
7. Check traffic mix, campaigns, seasonality, outages, and simultaneous site changes.
8. Decide to keep, revise, reverse, or monitor the change.

An increase after a change is evidence of association, not automatic proof of cause. If several things changed together, state that limitation. For performance work, repeat the same device, network, location, and test method before comparing lab results.

Use this results table: