# User Identity and Consent

> Current Froomle documentation · [View canonical page](https://docs.froomle.com/froomle-doc-main/v2/guide/topics/user-identity-consent.html)

User identity is the **"red thread"** that connects individual interactions into a cohesive journey. By consistently identifying users across sessions and devices, Froomle can discover deep patterns in behavior, leading to higher-relevance recommendations and more accurate performance insights.

<a id="_the_identity_duo"></a>

## The Identity Duo

Froomle uses two primary identifiers to maintain this thread while remaining privacy-safe.

-   **`device_id` (The Browser/App)**: Represents a specific installation or browser (e.g., a cookie ID or instance ID). It provides **continuity** across sessions even when a user is anonymous.
    
-   **`user_id` (The Person)**: Permanently identifies a known, logged-in user (e.g., a hashed account ID). This allows Froomle to recognize the same person across different devices.
    

Every event or recommendation request sent to Froomle should carry an actor identifier. For normal consented traffic this is a real `device_id`. For no-consent browser traffic, use the literal value `device_id: "no-consent"`. If the user is logged in and consent allows it, the `user_id` should also be provided alongside the `device_id`.

| User ID | Device ID | Effect |
| --- | --- | --- |
| **Yes** | **Yes** | Everything that was recorded for this user’s login, as well as everything registered under the device will be used as history to inform the user’s recommendations. |
| **No** | **Yes** | Everything that was recorded on this device will be used as history to inform the user’s recommendation. If a user previously browsed your website on other devices, this will not be taken into account as no `user_id` was passed. |
| **No** | **No** | No recommendations can be made. |

It should never happen that a single `device_id` is associated with multiple `user_ids` (within the same environment).

> **IMPORTANT:**
> 
> Never send personally identifiable information (PII) such as email addresses or plain names in these fields. Always use opaque, hashed, or uuid-style strings.

<a id="_the_identity_lifecycle"></a>

## The Identity Lifecycle

A typical user journey on Froomle follows a three-stage lifecycle:

1.  **Anonymous**: A new visitor arrives. You provide a `device_id`. Froomle keeps track of their **interaction history** to provide real-time relevance, without building a permanent secondary profile. This lasts until the device\_id expires.
    
2.  **Stitched**: The user logs in. You now provide both the `device_id` and the `user_id`. Froomle **automatically stitches** the previous anonymous history of that device to the known user profile.
    
3.  **Known**: The user returns on a different device (e.g., switching from web to app). By providing the same `user_id`, Froomle instantly recognizes them and serves personalized content based on their full history.
    

<a id="_consent_and_privacy"></a>

## Consent and Privacy

Froomle is designed to be privacy-first. You control how data is collected based on your users' consent status.

Apply these shared rules through your chosen implementation method:

-   [Frontend SDK identity and consent](https://docs.froomle.com/froomle-doc-main/v2/js_lib/jslib.html#Users)
    
-   [Manual event integration](https://docs.froomle.com/froomle-doc-main/v2/guide/manual-integration/events.html)
    
-   [Manual recommendation integration](https://docs.froomle.com/froomle-doc-main/v2/guide/manual-integration/recommendations.html)
    

<a id="_handling_no_consent"></a>

### Handling "No Consent"

For users who explicitly opt-out of tracking or cookies: \* **Recommendation Requests**: Send requests with `device_id: "no-consent"`. Froomle will return high-quality recommendations based on global trends (e.g., "Trending Now") without storing any history for that specific request. \* **Tracking Events**: Do not send tracking events for users without consent. \* **Benchmarks**: Keep requests anonymous while preserving only the benchmark routing fields required by the agreed assignment model. Follow the method-specific benchmark guide.

<a id="_gdpr_and_deletion_rtbf"></a>

### GDPR and Deletion (RTBF)

When a user exercises their "Right to be Forgotten," you can use the **Users API** to permanently delete their identity and all associated behavioral history from the Froomle platform.

<a id="_special_cases"></a>

## Special Cases

-   **Server-side only**: If your users cannot browse without logging in, you may use the same value for both `user_id` and `device_id`.
    
-   **Robot Filtering**: Froomle automatically detects and excludes most bot traffic from model training to ensure your analytics remain clean.
    

<a id="_related_topics"></a>

## Related Topics

-   [Event model and tracking contract](https://docs.froomle.com/froomle-doc-main/v2/guide/topics/tracking-events.html)
    
-   [Recommendation request model](https://docs.froomle.com/froomle-doc-main/v2/guide/topics/recommendation-requests.html)