Source: https://docs.amadalis.ai/privacy/counting-and-identity/ # 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](https://docs.amadalis.ai/reference/glossary/#visitor) browser, a [visit](https://docs.amadalis.ai/reference/glossary/#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](https://docs.amadalis.ai/developers/tracking-events/#link-a-signed-in-customer) for the method and its checks. Use [Visitor Data](https://docs.amadalis.ai/privacy/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](https://docs.amadalis.ai/privacy/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](https://docs.amadalis.ai/reference/copilot/audiences-and-targeting/#visitor-identity-settings). ## 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](https://docs.amadalis.ai/reference/glossary/#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](https://docs.amadalis.ai/trust/privacy-and-consent/) to understand that request policy. Use a separate approved erasure when data must be removed within its stated scope.