Counting people and linking browsers

Use Copilot to review a proposed identity policy and Privacy & Data > Visitor Data in the site admin to inspect recorded browser activity. This guide explains how those records relate to people.

Checked against the product’s code on 7 November 2026.

Praxis distinguishes a visitor browser, a visit and a person linked across known browsers. Analytics cannot recognize a person across every device without an identity link.

Review the counting policy

An Admin can ask the copilot to explain the site’s current counting policy. A change to its identity policy pauses for approval.

1. Ask the copilot to explain the current policy.
2. Review whether counting is narrowed by site.
3. Review whether an external customer identifier is retained.

Read any proposed change before approving it.

Each site keeps its own visitor records. A person known on one of your sites is not linked to the same person on another, so compare totals across sites with care.

Link or detach deliberately

Your site’s developer can post to /api/dxp/identity/link after the customer signs in, and /api/dxp/identity/detach when they sign out. These link and detach the browser for counting; they do not sign someone into their customer account. The page’s capture script now installs identity helpers. For the site’s own signed-in shopper, an eligible page can submit a signed identity link using a secret held by that site. If that secret cannot be read, the link is refused. A site that has never created a secret still accepts its earlier unsigned links. Follow Link a signed in customer for the method and its checks.

Use Visitor Data to find the intended browser record first.

1. Open that record.
2. Open Identity to inspect its joined browsers.

Detaching a browser removes its link to that person; it does not erase the browser’s events. Use Visitor Data for the exact record scope.

Choose external identifier names

An Admin can reserve names for external analytics identifiers, such as ga4 or adobe. This imports nothing, calls no vendor and reads no vendor cookie. Only identifiers your own site tag hands over can be saved, for visitors who consented to analytics, once per visitor. Check that your own privacy notice explains this before enabling it; the visitor consent dialog does not name this collection.

1. Ask the copilot: “Which external analytics identifier namespaces does this site allow?”
2. Review the current list.
3. Ask it to set that list to the complete names you intend to keep.
4. Read Change which external analytics ids this site records? and the proposed additions and removals.
5. Choose Approve & change only if the list is right.
6. Read the receipt.

An empty list turns this collection off. Its Undo restores the prior setting; previously stored identifiers remain until erased through the visitor’s erasure path. This setting is separate from linking a person across browsers or connecting an analytics service. See External identity requests.

Keep consent and erasure distinct

Consent and counting policy affect whether identity details can be saved. Refusing a purpose is not erasure of details already held. A browser that sends Global Privacy Control is not personalized and adds no new identity details. The signal does not delete identity details already saved; erase the record for that.

Global Privacy Control still governs the server’s permitted experience purposes. Use Privacy and consent to understand that request policy. Use a separate approved erasure when data must be removed within its stated scope.