Authenticated Visitor (Cross Device Consent)

  • Updated on Oct 1, 2025
  • Published on Jul 17, 2025
  • 2 minute(s) read
  • Rodrigo Irarrazaval
  • Yossi Karp
  • DF
 Prev Next

Overview

The Authenticated Visitor or cross-device consent feature allows organizations to identify and manage consent for logged-in users. Unlike anonymous visitors, authenticated visitors can be uniquely recognized, enabling precise consent tracking across sessions and devices.

This is essential for organizations that need to:

  • Ensure accurate consent attribution for known users.

  • Synchronize consent preferences across multiple platforms.

  • Comply with privacy regulations by tying consent to user identity.

Example Use Case

  1. First Visit (Anonymous User)

    • A new visitor arrives at your website without being logged in.

    • The Consent Banner is displayed, and the visitor makes a choice (e.g., accepts or rejects certain cookies).

    • Their consent is stored anonymously and tied to a temporary visitor session ID.

  2. Login (Authenticated Visitor)

    • Later in the same session, the visitor logs in to their account.

    • At this moment, the anonymous consent record is linked to the authenticated visitor_id (their unique user ID).

    • This ensures that the preferences they selected before logging in are preserved and associated with their identity.

  3. Subsequent Visits (Returning User)

    • When the same user logs in again—on the same or a different device—the Consent Manager retrieves their saved consent preferences via the authenticated visitor_id.

    • The user does not need to reselect their choices unless new consent categories are introduced.

    • This prevents duplicate consent records and ensures compliance by maintaining a single, consistent consent profile across sessions and devices.​

Authenticated Visitor Flow

Prerequisites

Before enabling Authenticated Visitor, ensure the following:

  • A working Consent Banner is already configured.

  • Visitor authentication (e.g., login system, SSO, or ID provider) is implemented.

  • The visitor_id is available upon user authentication.

Configuration Steps

To do this, you simply need to call BigID's Website SDK "identify" method and pass the user ID you will be using.

  <head>
    <script>
      const logIn = () => {
        /* ... */
        const userId = /* extract the user ID once signed in */
        window.bigidcmp.identify(userId);
      }
    </script>
  </head>
  <body>
    <button onclick="window.logIn()">Log in</button>
  </body>

Once this is done, when the cookie banner is loaded on the website, it will first fetch the consent stored at BigID's server (if any). The user ID will be used as the fetching ID. Then, the widget will show the UI that corresponds:

  1. If the user did not give any previous consent, the banner will be shown

  2. If the user did give a previous consent, the icon or link will be shown to resurface the notice, if needed.

If permissions are changed, the updated version is sent back to BigID's server to sync it with any other device where the user is identified.

When the user logs out, you need to call BigID's Website SDK "removeIdentity" method to go back to anonymized consent mode that does not include any user ID whatsoever either locally or the server. Once again, the user's choices will not be cross-device.

  <head>
    <script>
      const logOut = () => {
        /* ... */
        window.bigidcmp.removeIdentity();
      }
    </script>
  </head>
  <body>
    <button onclick="window.logOut()">Log out</button>
  </body>