Track a sign-up button and form submit

When you finish, the click is an event you named, signup_click, the submit is the automatic event __form, and each has an event goal counting it.

Prerequisites

The site script is installed and your own visit shows in realtime. Changing automatic-event switches requires an owner or admin. Creating goals requires an analyst or above.

Steps

1. Turn on form collection

   Open ConsoleWeb analyticsConfigurationSDK code and turn on Form submits under Automatic events. The switch saves immediately. Then add data-forms="true" to the script tag on your page by hand. The install snippet does not include it. If either is missing, a submit is not counted.

2. Name the button click

   In the button's click handler, call webcount.track('signup_click', { id: 'hero-signup' }). The name must match the goal. If the script is not assigned yet, push the call onto window.__wcq.

3. Create event goals

   Open ConsoleWeb analyticsGoals and click New goal. Set Type to Event and the event name to signup_click. Event goals match the name exactly, so there is no match option. Create a second goal for __form. Property filters (optional) such as id=hero-signup count a conversion only when that property matches.

Verify

Open ConsoleWeb analyticsRealtime, filter to Events, and click the button. You should see signup_click. Submit the form and filter to Forms. You should see __form. Counts then increase on ConsoleWeb analyticsEvents and on the goals page.

Common failures

What you see	Why	What to do
No form event	The switch is off, or the script tag lacks data-forms="true"	Fix both
The goal stays at zero	The type is Page, or the name differs	Use Event and the same name as the first argument of track
The click is missing in realtime	The call ran before webcount existed and was not queued	Push it onto window.__wcq, or call after webcount exists

Next steps

For clicks you have not named yet, turn on autocapture and claim them later in the inbox. See Autocapture & definitions.

Avoid double counting with insert_id

Browser, mini-program, and app track calls never send insert_id. It only deduplicates server retries and does not cancel a client row against a server row, so report orders, sign-ups, and refunds once, from the server.

Prerequisites

You have an API key with Server track. The page can report the click; the payment result and the amount come only from your server.

Steps

1. Report the fact from the server only

   POST JSON to /api/v1/track and authorize with Bearer wck_…. Use your real event name, such as purchase.

2. Reuse the key on every retry

   insert_id is at most 36 characters. Use a stable value such as an order id, not a new random value each time. Duplicates inside one batch are dropped. A key that is already stored is not inserted again when the new event time is within one day before or after the stored time.

3. Do not send the same fact from the client

   If the browser also sends a purchase with the same name, you get a second row. Keep the amount on the server event only.

Verify

Submit twice with the same insert_id. The event is counted once. Both responses count the event as accepted, because deduplication happens at ingest, so check the reports.

Common failures

What you see	Why	What to do
A retry becomes two rows	The keys differ, or the second event time is outside the one-day window	Reuse the original key and event time
Front and back each count once	Client track does not send the key	Report the amount only from the server
An update returns missing_insert_id	track_update or track_overwrite has no key	Updates and overwrites require the original key

Claim inbox events into the tracking plan

When you finish, a name you confirmed is an event definition with status Live, and the tracking plan has a matching item. Accepting a candidate also backfills the last 90 days of autocapture in the background.

Prerequisites

You are an analyst or above. Autocapture candidates also require a plan that includes the inbox, and autocapture turned on for the site. Names you already send with track but have not registered do not depend on that switch.

Steps

1. Read the banner

   Open ConsoleAll-platform analyticsDataEvent inbox. If it says autocapture is off, new click candidates will not appear on Pending. The Unplanned events card still counts names that arrived from code without a definition.

2. Accept a candidate

   On Pending, open a row and click Accept. The event name is snake case, starts with a letter, and is at most 40 characters. Avoid renaming it later. Accepting creates a definition and backfills 90 days in the background, which can take a few minutes on a large site.

3. Register an unplanned name

   Open the Definitions tab. For a row with status Unplanned, click Register. The status becomes Live.

4. Add it to the tracking plan

   Open ConsoleAll-platform analyticsDataTracking plan and click Generate from definitions. Definitions not yet in the plan are added: Live definitions get plan status Live, the rest get Developing. Automatic events starting with __ and hidden definitions are skipped.

Verify

The name is under Accepted or Definitions, and a registered one has status Live. The tracking plan has an item with the same name and status Live.

Common failures

What you see	Why	What to do
Pending stays empty	Autocapture is off, or the plan has no inbox	Register names that were already sent, on Definitions
Analysis still lacks the event	Backfill is still running, or the name does not match code	Wait for backfill, and do not rename a key that is already stored
The plan item is Developing	The definition was not Live when the plan was generated	Register it first, then move the plan item to Live

Merge web, mini program and server events into one user

Three clients are three people until they send the same id type and the same string, which collapses them into one person on the identity map. Anonymous visitors are still counted only, and do not appear in the people list.

Prerequisites

The site is in identified mode: open ConsoleAll-platform analyticsUsersIdentity map and the anonymous-mode banner is gone. Identified mode requires the Pro plan or above, and it is not the tier control in ConsoleConfigurationPrivacy center; once it is on, the default tier is fixed at 3 · Cookie + identity. Use one id type on every client. The default is a login id; the other types are email, mobile, OpenID, UnionID, and custom.

Steps

1. Call login on the website after sign-in

   The identity extension loads only in identified mode. Call webcount.login('u_123', { $name: 'Ada' }). The call returns immediately when the site is not identified, the visitor's effective tier is below 3 (a region rule, consent required but not given, DNT, or GPC), or the id is blocked. If the extension is not loaded yet, queue it on window.__wcq.

2. Use the same string in the mini program or app

   After you have your own user id, call login('u_123', { $name: 'Ada' }, { type: 'login' }). The type must match the website. If you use OpenID, every client must use OpenID.

3. Send the same id from the server

   POST /api/v1/track with login_id set to u_123 and login_id_type set to login. The key needs Server track only. Authorize with Bearer wck_…, and do not commit the full key to a repository.

Verify

After one event from each client, find that id on the identity map as a single person. The profile shows events from more than one client. Ids such as anonymous, guest, all zeros, and -1 are rejected and show up in the page warnings.

Common failures

What you see	Why	What to do
The people list stays empty	The identity map still shows the anonymous banner, or the visitor's effective tier is below 3	Turn on identified mode, then check region rules and consent settings
You get two people	The string or the type differs	Use the same string and the same type on every client
The server event is someone else	login_id is missing, or the type differs	Send both login_id and login_id_type