Track completed signups in a Next.js app with WhoVisited

Install WhoVisited in a Next.js App Router layout, record successful signups, and verify which traffic sources bring conversions without tracking personal data.

1. Decide what a successful signup means

A busy landing page does not necessarily bring customers. Before installing analytics, pick one action that proves the visitor has progressed: an account was created successfully, a demo request was accepted, or a checkout completed. This walkthrough uses account creation. A click on the signup button is not the same action.

WhoVisited measures browser activity and same-session goals. It does not identify a person behind an anonymous visit, and a conversion report is not a substitute for your application database. Use your database to count accounts and analytics to understand the sessions that led to them.

2. Load one tracker in the shared root layout

In WhoVisited Settings, add your main HTTPS website address, save it, then expand the website card and copy its installation snippet. Replace YOUR_SITE_ID below with that website’s public site ID. The main address also covers its www version; add other subdomains separately.

tsx

// app/layout.tsx
import Script from "next/script";

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        {children}
        <Script
          src="https://whovisited.net/tracker.js"
          data-site-id="YOUR_SITE_ID"
          strategy="afterInteractive"
        />
      </body>
    </html>
  );
}

Next.js loads afterInteractive scripts after some hydration has occurred. Put the tracker in the shared layout so it is available across routes. WhoVisited observes browser history changes for single-page navigation; do not add a second page-view call or install another copy through Google Tag Manager.

Deploy the change and visit the public website before clicking Verify installation in Settings. An Integrated result means a tracking event was received; it does not prove every route or every consent state is working. Test the signup flow as well.

3. Record the event only after account creation succeeds

For a client-side signup flow, call the custom event after your own signup operation confirms success. The example below is a helper, not an authentication implementation. Replace the placeholder signup operation with your existing application logic and do not place it in a Server Component.

typescript

// app/signup/track-signup.ts
// Call from a Client Component after a confirmed successful signup.
type TrackingWindow = Window & {
  whovisited?: {
    track: (name: string, properties?: Record<string, string>) => void;
  };
};

export function trackCompletedSignup() {
  (window as TrackingWindow).whovisited?.track("signup_completed");
}

// In your existing submit handler:
// const result = await createAccount(formData);
// if (result.success) {
//   trackCompletedSignup();
//   router.push("/welcome");
// }

Optional chaining avoids breaking signup if a blocker prevents the tracker from loading. It does not queue an event while the script is unavailable. If your flow can complete before the script is ready, use a confirmed success-page goal instead, or explicitly coordinate script readiness in your client code.

Do not send email addresses, names, passwords, access tokens or submitted form values as event properties. A short event name is enough for this goal. Keep the handler from firing twice during duplicate submissions. WhoVisited counts a matching session once for a goal, but your account creation endpoint still needs its own duplicate protection.

4. Match the event in WhoVisited Settings

Create a conversion goal for the same website with the custom event name signup_completed. Names must match exactly. Then open Growth, select the website and date range, and compare sessions and goal conversions by source or campaign.

Alternatively, if successful signup always sends the user to a dedicated /welcome page, create an exact page-path goal for /welcome. Use a page that visitors reach only after success. An accessible generic landing page can inflate this count, and refreshing it is still browser activity rather than a new account.

Goals match retained events in the same session. They are not cross-device attribution or a promise that the first marketing touch caused the signup. A visitor who returns in another session can have a different source.

5. Test a campaign from landing page to success

url

https://example.com/?utm_source=newsletter&utm_medium=email&utm_campaign=launch

Use a tagged landing URL that you control, then complete a test signup in the same browser session. WhoVisited captures supported UTM source, medium and campaign values at the beginning of the session. Keep names consistent; newsletter and Newsletter make poor comparison labels.

Confirm the deployed page loads tracker.js with your site ID.
Check that the configured HTTPS origin matches the actual site or subdomain.
Complete one successful signup and verify signup_completed in the visitor journey.
Use a new session for a new campaign test; changing UTM parameters midway through an existing session is not a clean test.
Compare the Growth report with the test journey; allow ingestion and refresh time before treating a missing row as a failure.

Direct navigation can have no usable referrer. Privacy controls, blockers and collection settings can also prevent tracking. Treat Unknown as missing source information rather than proof that the visitor came from a particular channel.

6. Respect consent and diagnose missing events

If your site requires prior analytics consent, add data-consent="required" to the Script component. In your client-side consent manager, call window.whovisited.consent(true) after both tracker readiness and consent approval; call consent(false) when consent is withdrawn. Do not merely show a banner while collecting before approval.

WhoVisited also respects browser Do Not Track and Global Privacy Control signals. A consent call does not override those signals. If a test produces no event, check your browser privacy settings, content blockers, website collection toggle and subscription availability before changing the code.

A strict Content Security Policy must allow the tracker script and its required connections to whovisited.net. Review the browser console for blocked script or network requests and adjust your own policy narrowly. Do not disable your entire policy to get analytics working.

7. Use the result to choose a useful next experiment

Once the flow is reliable, compare sources using both session counts and conversions. A channel with one conversion from two sessions is too small to justify a budget decision. WhoVisited hides rates below 20 sessions; reaching that threshold is still not proof of statistical significance.

Keep a simple record of what you changed: campaign, landing page, date and goal. Change one major element at a time, then check whether more sessions reach the success event. If Search Console is connected, its clicks help explain search visibility, but they are a separate measurement from recorded website sessions.

The useful outcome is a repeatable question: which source brings sessions that complete signup? A trustworthy answer starts with a correctly placed tracker, a precise success event and a verified path through your actual application.