A script on the page is the beginning, not acceptance
An analytics installation is working only when intended actions produce the intended records, unwanted data stays out, and reports agree with the test journey. Seeing a script tag or a green connection badge proves much less. It does not establish that navigation is counted once, consent is respected or paid conversions are genuine.
Use a staging project and synthetic activity first. Keep a short acceptance record with the website revision, tracker configuration, browser, time, expected events and observed results. This lets another person repeat the test and prevents a later production regression from being dismissed as “it worked when we installed it.”
Define the contract before opening developer tools
List the few events you need and their precise trigger. “Signup” could mean clicking a button, submitting a form or successfully creating an account. Pick one meaning and name the other actions differently. Decide which routes count as pageviews and which values are allowed in event properties.
Write down your consent and storage policy separately from your event list. The test below assumes a consent-gated implementation that sends no analytics event before permission. Other products may use different documented behavior. Test against your approved policy and applicable requirements; do not assume that a product described as cookieless has no privacy obligations.
- pageview: an accepted public route becomes visible.
- signup-completed: the application confirms account creation.
- checkout-started: a valid checkout session is created.
- payment-succeeded: the trusted payment system confirms success, not the browser.
Inspect actual browser requests
Open the Network panel before the journey, clear old traffic and filter to the collection endpoint. Chrome documents request inspection, payloads and response details in its developer tools. A successful HTTP response is useful evidence, but still verify the corresponding record in the correct project.
Check the destination host, project identifier, event name, allowed source labels and timestamp. Look for accidental email addresses, search text, access tokens or customer-specific URLs. An event can be technically valid and still collect information your measurement plan did not authorize.
If a request is missing, work from the browser outward: script load, JavaScript errors, policy restrictions, network request, server validation and stored record. Do not repeatedly reinstall the script before locating the failing layer.
Run a small, explicit journey matrix
This is a synthetic acceptance example, not a claim about any deployed tracker. Use a new test identifier for each run and preserve a sanitized evidence log. Counts below refer to the chosen consent-gated policy, not every analytics vendor’s behavior.
SYNTHETIC TEST MATRIX
Action Expected browser analytics
Load / with consent denied 0 events
Grant consent on / 1 permitted initial pageview
Navigate to /pricing 1 new pageview
Refresh /pricing 1 new pageview for that load
Change only a filter query 0, if policy ignores query-only changes
Withdraw consent No subsequent analytics collection
Complete test payment Server verifies money separatelyTest single-page navigation without double counting
A single-page application can change screens without reloading the document. A tracker tied only to the first page load may therefore miss navigation. At the opposite extreme, automatic history tracking plus a manual router event can count the same screen twice. Google’s SPA guide specifically warns about overlapping tracking approaches in its implementation.
Choose one owner for pageview emission and test initial load, client-side navigation, back, forward and refresh. If your router uses hash paths, test those explicitly. If a query change only sorts a table, decide whether it is a new analytical screen; do not let an accidental implementation detail choose the metric.
Confirm that instrumentation does not break navigation. Buttons, history, form state and error handling should behave normally with tracking enabled, disabled and blocked. Analytics should observe the product, not become a requirement for using it.
Exercise permission changes and failure cases
Test denied, granted and withdrawn permission in the same session. Inspect storage and network behavior after each transition. Withdrawal cannot unsend an event already delivered, so the expected outcome should distinguish stopping future collection from deleting historical records.
Next, block the analytics request and repeat the main application action. The user should still be able to sign up or proceed through checkout if analytics is unavailable. Test a slow connection as well: a timing dependency can disappear on a fast development machine and fail on a phone.
Check the implementation’s stated treatment of browser privacy signals and storage restrictions. Record a limitation honestly if it cannot be supported or measured. Missing data is preferable to bypassing the visitor’s choice just to make a chart look complete.
Verify revenue independently, then verify the association
Create a provider test payment and inspect its authoritative state. Confirm that the analytics project receives one canonical payment with the correct currency and amount. Then replay the notification and check that money does not double. A partial refund should follow the documented refund rule.
Only after the financial path works should you inspect whether the consented visit was associated with it. Repeat without an eligible visit; an Unattributed payment can be the correct result. Testing only the happy path encourages systems to hide precisely the uncertainty they should expose.
Leave a repeatable release check
Keep the matrix with the installation documentation and repeat it after changes to routing, consent management, checkout, domains or the tracker. Save sanitized evidence, not production customer payloads. Record the actual date and configuration rather than a permanent “verified” badge.
Passing this check establishes the tested behavior under stated conditions. It does not guarantee complete visitor coverage, legal compliance or correct future deployments. That narrower conclusion is useful: you now know which part works, which part failed and exactly what the next repair should target.