1. Set a small acceptance contract
A new landing page can look correct while its tracking points to an old website ID, a blocked endpoint or a conversion callback that runs too early. Before sending a campaign to it, test one complete synthetic journey: arrive through a tagged link, browse the intended path, complete a valid action and find the accepted signal under the correct website.
Write down the deployed page URL, application version, intended WhoVisited website, consent mode and primary goal. Define the business outcome in plain language, such as a demo request accepted by the application. This turns a vague dashboard check into an acceptance contract you can repeat after a release.
Use a staging site with its own configured tracking when possible. If you must check production, use a small number of clearly documented synthetic actions and note their time and timezone. Do not invent customer details or submit real orders merely to make a chart change.
2. Start with a deliberate browser context
A tab left open during deployment can retain an older script or configuration. Start a fresh document and confirm that you are testing the deployed version. Inspect the installation source and site ID rather than assuming the newest application build owns the only tracker on the page.
A fresh document is not necessarily a fresh analytics session. WhoVisited keeps a visitor identifier in localStorage and a session record in sessionStorage, scoped by website ID. Its session logic renews the identifier after more than thirty minutes without a tracked action. Reloading the page can therefore continue an existing session.
MDN explains that sessionStorage survives reloads and is separated by origin and tab, with an opener-copy exception. For a deliberate new-session test, use a separate browser profile or private context and record the setup. Avoid clearing all browser storage in a working account; it can disrupt unrelated application state.
This matters for acquisition checks. WhoVisited keeps the session landing path and source fields from the first accepted event for that session. Pasting a different tagged link into an existing session does not prove that the report will replace its earlier acquisition data. Test each intended arrival in a controlled fresh context.
3. Verify the collection chain
- Confirm the intended tracker is installed once and has the correct site ID and consent setting.
- Check that the deployed page origin is allowed and collection is enabled for that website.
- Inspect the tracker file response, then the bootstrap request and the events request separately.
- Confirm the events response accepts the intended event, then inspect the matching visitor journey.
A successful script response proves delivery of JavaScript, not event ingestion. WhoVisited uses bootstrap to obtain collection configuration and authorization, then sends event batches. Browser restrictions or website eligibility can break a later stage while the script itself remains available.
If a release changes Content Security Policy, check collection requests as well as script permissions. MDN documents that connect-src controls destinations for fetch and other script connections. Allowing a script host alone does not establish permission to send its fetch requests. Preserve the application security policy and add only the required destination under your own review.
Do not paste authorization headers or complete network exports into a public issue. Request paths, status codes and a minimal synthetic event summary are usually enough to start a diagnosis.
4. Reduce a synthetic batch to useful evidence
The following read-only helper summarizes an events request body. Run the supplied synthetic example first. For your own test, pass a locally inspected request body object rather than a header block or a full browser export. The helper reports event names, paths and property keys while omitting visitor IDs, session IDs, titles and property values.
function summarizeTestBatch(payload) {
if (!Array.isArray(payload?.events)) {
throw new TypeError("Expected an events array");
}
return payload.events.map((event, index) => {
let path = "invalid URL";
try {
path = new URL(event.url).pathname;
} catch {}
return {
index,
type: event.type,
name: event.name,
path,
propertyKeys: Object.keys(event.properties || {}).join(", "),
};
});
}
console.table(summarizeTestBatch({ events: [
{ type: "page_view", name: "page_view",
url: "https://example.com/demo", properties: {} },
{ type: "event", name: "demo_request_accepted",
url: "https://example.com/demo", properties: { form: "demo" } },
] }));The expected result contains a page_view and demo_request_accepted on /demo, with only form as the custom-property key. It is a readable inventory, not an acceptance checker: it does not contact WhoVisited or establish whether a server saved the batch. Pair it with the response and the resulting journey.
Even this summary is not automatically safe to share. A pathname or a property key can itself contain sensitive information. Inspect the output before storing it in a release note, and use neutral test routes. Do not treat omission of query strings as protection for personal data embedded in a path.
5. Check the journey rather than isolated requests
- Campaign arrival: use known utm_source, utm_medium and utm_campaign values, then confirm the new session landing path and acquisition fields.
- Navigation: follow the actual application link and test browser Back. Compare pathname changes with the documented automatic page-view behavior.
- Rejected action: exercise validation or a documented backend rejection and confirm that the accepted-action event does not appear.
- Accepted action: perform one valid synthetic request and verify the configured exact event name or success-page path.
- Refresh or retry: distinguish repeated event records from a single qualifying converted session.
An events POST can contain multiple events. Count event records and inspect their names instead of treating the number of HTTP requests as the number of page views. In the current Growth report, a selected goal converts a session when at least one retained matching event exists in that same website and session.
Do not expect two form completions in one session to become two converted sessions. Likewise, a thank-you page that can be opened directly can qualify a session without a new submission. Choose a primary signal whose meaning matches your acceptance contract.
6. Include a collection-off case
Repeat a small journey with consent withheld when the installation requires it. The current tracker does not queue disallowed actions for later replay. When collection becomes allowed, it attempts a page view for the current location if it has not stopped and a browser privacy signal does not keep collection disabled.
Also exercise a blocker or unavailable tracking service in a test environment. The form or application action must still work. Do not make analytics delivery a prerequisite for showing a successful business result, and do not ask a user to repeat an accepted submission merely because a goal did not appear.
A missing record can be an expected consequence of privacy controls or best-effort browser delivery. The release check should establish the intended collection boundary, not force every browser to produce identical totals.
7. Repeat the smallest useful check after deployment
A staging pass does not establish that production has the same site ID, policy, origin or container version. After deployment, repeat a fresh arrival and one synthetic completion against the public version. Save the version, test time, expected paths, goal name and observed collection statuses.
If an acceptance check fails, keep the findings specific: wrong site ID, blocked connection, rejected collection, stale session attribution or an early completion callback. Restore the known working integration through the normal release process when needed; do not hot-patch the tracker global in a running tab.
This checklist does not guarantee accurate customer totals, search ranking improvements or attribution across devices. It establishes that the released page can produce the intended evidence under a documented test context. That is a dependable foundation for comparing real campaign results later.