> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corbado.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Observe Privacy and GDPR Data Policies
> How Corbado Observe protects personal data, which purposes it supports and how data policies set retention per purpose.
Corbado Observe lets you send submitted identifiers and user IDs in clear text or as hashes. **Data policies** control when Observe hashes stored values and when it deletes their references. Hashing preserves matching and user relationships; deletion removes the corresponding links while retained journeys remain available for analysis. Observe does not capture credentials.
## 1. Built-in protections
* **Control over account references:** choose independently whether to send the submitted identifier and your user ID in clear text or already hashed. Hash before sending when Corbado should never receive the clear value. Data policies can hash clear values later and delete references when their retention ends. See [how to choose](/corbado-observe/overview/users-and-identifiers#2-choose-how-identifiers-and-user-ids-are-stored).
* **No credentials or field values by default:** Observe does not capture passwords, one-time codes or other input values. Input interaction tracking records how a field was used, for example focus, paste, autofill and changes in length. It does not read the clipboard. The submitted account identifier is the one exception and is sent only when your integration passes it with a subflow step.
* **Protected passkey telemetry:** Autocapture removes user names, display names, assertion signatures and PRF outputs from WebAuthn telemetry. Credential and authenticator metadata such as AAGUID, transports and backup state remain available for analysis. For custom events, the web SDK provides the same sanitization functions. Their optional [user identifier projector](/corbado-observe/tracking/subflows#control-webauthn-user-identifiers) can transform or omit creation `user.id` and response `userHandle` from custom-event telemetry. It does not redact credential IDs or identifiers inside encoded blobs.
* **Masked URL queries:** the web SDK replaces query values in reported page URLs with `*` and does not report URL fragments. Paths are reported as they are, so keep personal data out of them. See [data handling](/corbado-observe/overview/constraints#4-data-handling) for allowlisting.
* **No IP addresses in the data model:** Observe does not store client IP addresses or derive locations from them. Dimensions such as country come from [tags](/corbado-observe/tracking/tags) your integration sets.
* **Password-manager evidence:** when browser-extension detection is enabled, the web SDK reports detected manager names, without the detector's optional sign-in flag. Recognized passkeys can also establish manager sightings. See [password-manager evidence](/corbado-observe/overview/constraints#password-manager-evidence) for the collection limits.
* **First-party storage:** SDK storage is scoped to your origin and project. The device identity is a random value. Observe stores no advertising identifiers and does no cross-site tracking.
* **Aggregated KPIs without user reference:** time series, funnels and trends contain no user reference.
If your policy requires that Corbado never receives client IP addresses, route event delivery through your own proxy and remove them there. The SDKs send to a configurable API base URL. Forward the browser's `Origin` header unchanged so origin checks continue to work.
## 2. Purposes and retention
Authentication telemetry serves several purposes, each with its own retention needs:
| Purpose | Typical questions | Data needed |
| - | - | - |
| **Authentication security and reliability** | Did a release or platform update break a login method? Are bots, credential stuffing or account enumeration hitting the login? | Recent journeys with identifiers and user IDs for investigation |
| **Extended journey analysis** | How do returning users adopt passkeys? How do methods perform for the same users over months? | Journeys connected to the same user through a stable hashed user ID |
| **Aggregated reporting** | How do success rates, funnels and methods develop? | No user reference |
For a standard setup, send both values in clear text, hash submitted identifiers after 30 days and retain user IDs according to the project's default policy. Readable identifiers help support recognize typos and corrections during recent investigations. Sensitive values can be hashed before sending instead. See [users and identifiers](/corbado-observe/overview/users-and-identifiers#2-choose-how-identifiers-and-user-ids-are-stored).
Data policies let you keep each type of data for as long as its purpose requires. A common setup bases the default policy on the legitimate interest in secure and reliable authentication (Art. 6(1)(f) GDPR) and selects an extended policy based on the user's privacy choices. As the controller, you decide the legal basis and describe it in your privacy notice.
## 3. Data policies
A data policy has a numeric code and periods counted in days from capture. Hashing and deletion have different outcomes:
* **Hashing:** replaces clear values with stable hashes, also called pseudonymization through hashing. The same user can still be recognized across journeys. Hashing does not remove user relationships or verify ownership of a submitted identifier.
* **Deletion:** deletes the stored identifier or user ID references, removing the corresponding links. This is also called unlinking. Retained journeys remain available without those references.
Configure the hashing period and deletion period independently for each value. Values already hashed before sending keep their supplied representation; they do not need a second hashing step.
| Policy action | When the period ends |
| - | - |
| **Hash identifiers** | Clear submitted identifiers are replaced by stable hashes; identifier matching remains available |
| **Hash user IDs** | Clear user IDs are replaced by stable hashes; user lookup and analysis across journeys remain available |
| **Delete identifiers** | Stored identifier references and their links are deleted; retained attempts remain without them |
| **Delete user ID references** | Stored user ID references and their links to flows and subflows are deleted; retained journeys remain without them |
| **Delete tracking data** | Raw events, batches, tags, user references and device information of the session are deleted |
| **Delete flows** | Flows and the records derived from them are deleted |
A retention period of `0` means no automatic deletion for that setting. Hashing preserves references until their deletion period ends; it does not extend retention. Aggregated KPIs contain no user reference, so hashing or deleting these references does not change them.
Code `0` is the project default and applies to every session that has not selected another policy. Configure policies in the management console under [**Observe → Settings → Data policies**](https://app.corbado.com/observe/settings/data-policies). A code keeps its meaning once created, because stored sessions reference it. You can rename a policy and adjust its periods at any time.
### Example configuration
Both example policies receive clear-text identifiers and user IDs:
| Policy | Submitted identifiers | User IDs |
| - | - | - |
| **Security and reliability** (`0`, default) | Hash after 30 days | Keep clear text during security retention |
| **Extended journey analysis** (`1`, with analytical consent) | Hash after the investigation period | Hash after the investigation period |
Under either policy, delete both references when the retention period for that purpose ends. Hashing both values under the extended policy preserves long-term user analysis until then. The retained journeys continue to count in KPIs, funnels and trends. Configure periods appropriate to your needs.
## 4. Select a policy per session
Your integration selects the policy for each session. Create the policy in the management console before your integration selects its code.
Available from web SDK 0.16.6. Pass the code at initialization and update it when the user's privacy choices change:
```javascript theme={null}
import { init } from "@corbado/observe";
const tracker = init({
projectId: "",
apiBaseUrl: "",
dataPolicy: 0,
});
// After the user's privacy choices change
tracker.setDataPolicy(1);
```
The SDK stores the selected code per project in the browser and sends it with every batch, across page loads and new sessions. Call `setDataPolicy()` again whenever the choice changes, including a return to `0`.
Corbado configures how your bundle selects the policy, for example from the state of your consent management platform. Agree the codes and the source of the user's choice when your integration is configured.
The iOS and Android SDKs select the policy the same way as the web SDK. Pass the code when initializing the tracker and call `setDataPolicy()` when the user's privacy choices change. The SDK stores the selected code in the app and sends it with every batch.
Observe applies the most recent code it receives for a session to the whole session, including events recorded before the change.
## 5. Processing, hosting and access
* **Roles:** you are the controller. Corbado processes Observe data on your behalf under a data processing agreement. [Contact us](mailto:support@corbado.com) for the agreement and the technical and organisational measures. The list of subprocessors is in the [Corbado Trust Center](https://trust.corbado.com).
* **Hosting:** Observe runs on Corbado's public cloud by default. Dedicated instances in a chosen region are available for enterprise deployments. See [projects, environments and hosting](/corbado-observe/overview/constraints#8-projects-environments-and-hosting).
* **Transport:** SDKs and API clients communicate with Observe over HTTPS.
* **Access:** API keys carry operation-specific permissions, can be restricted to IP addresses and expire. See [API authentication](/api-reference/observe/authentication).
Certifications, encryption and access control are summarized in [security and compliance](/corbado-observe/security/overview).
## 6. Requests from individual users
Export or delete the Observe data of a user using the current stored form of their external user ID, including any hashing. A user-data deletion request is separate from a policy that deletes account references while keeping journeys. Copies you have loaded into your own systems follow your own deletion process. See [user data export and deletion](/api-reference/observe/user-data).
What Observe collects, storage and hosting.
API, exports and security of data outside the console.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.