This approach involves sending the user's actual, readable identifiers (like email or phone number) directly to the Zeotap SDK. It's often the simplest method as you don't handle hashing yourself; Zeotap's backend takes care of processing.
**Implementation Steps:** 1. **Configure the SDK Initialization:** To use this scenario, you **must** explicitly tell the SDK *not* to perform hashing itself and confirm that the data you will provide is *not* already hashed. This is done during the `init` call: ```jsx title="SDK Initialization for Raw Identifiers" theme={null} window.zeotap.init("YOUR_WRITE_KEY", { // --- Configuration for Scenario 1 --- hashIdentities: false, // Crucial: Tells the SDK *NOT* to hash the values itself. areIdentitiesHashed: false // Crucial: Confirms the values you'll provide are *NOT* already hashed. }); ``` *This configuration ensures the SDK passes the raw values you provide directly to the Zeotap backend without attempting client-side hashing.* 2. **Send Identifiers Using Standard Keys and Raw Values:** Once the SDK is initialized correctly for this scenario, call `setUserIdentities`. Use the standard, recognized keys for PII (like `email`, `cellno`, `fpuid`, `loginid`) and provide the **actual, raw user data** as the values. You can also include any custom identifiers.To send the user's raw email address in Scenario 1:
email.To send the user's raw cell phone number in Scenario 1:
cellno.'\[code] \[number]' (e.g., '1 5551234567'). While the SDK sends the raw value in this scenario, this format ensures the best processing and matching on the Zeotap backend.Note: The cellno\_cc key is deprecated. Always use cellno for raw phone numbers. See Cellno Handling Details for more information on formatting implications, especially for other scenarios.
To send the user's raw login ID in Scenario 1:
loginid.In this scenario, your application (e.g., server-side or separate client-side logic) hashes PII *before* sending it to the SDK. You must use specific keys corresponding to the hash type you generated.
**Implementation Steps:** 1. **Configure the SDK Initialization:** Tell the SDK *not* to hash again and that the values you provide *are* already hashed. ```jsx title="SDK Initialization for Pre-Hashed Identifiers" theme={null} window.zeotap.init("YOUR_WRITE_KEY", { // --- Configuration for Scenario 2 --- hashIdentities: false, // Optional but good practice: Tell SDK NOT to hash again. areIdentitiesHashed: true // Crucial: Tells the SDK the values ARE pre-hashed. }); ``` *This configuration ensures the SDK expects hashed keys and values.* 2. **Send Identifiers using `setUserIdentities`:** Use the specific **hashed keys** that match your hashing algorithm and format, providing the pre-computed hash value. Expand the relevant PII type below:To send a pre-hashed email address in Scenario 2:
email\_sha256\_lowercase, email\_md5\_uppercase).Supported hash types: SHA-256, MD5, SHA-1 (lowercase/uppercase variants).
**Implementation Example:** ```jsx title="Sending Pre-Hashed Email (SHA-256 Lowercase)" theme={null} // Assume 'hashedEmailValue' contains the SHA-256 hash of the lowercase email const hashedEmailValue = 'a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2'; window.zeotap.setUserIdentities({ email_sha256_lowercase: hashedEmailValue }); ``` The specific hashed email key and value will be passed in the payload of the `https://spl.zeotap.com/fp?` call: ```jsxon title="Identities in payload" {8-8} theme={null} "events": [ { { /* ... */ }, "user": { "zs": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "zi": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "zi_domain": ".zeotap.com", "email": { "sha256_lowercase": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2" } // Hashed key/value sent }, { /* ... */ }, } ] ``` **Verification:** After calling `setUserIdentities` with the pre-hashed email: 1. **Network Call:** * Open Developer Tools (F12) -> **Network** tab. * Trigger an event. Find the request to the Zeotap endpoint (e.g., `spl/fp?`). * Inspect the **Payload**. Look for the `user` object. You should see the specific PII key (e.g., `"email"`) and the corresponding hash value you provided. 2. **Browser Storage:** * Go to the **Application** tab -> **Local Storage** or **Cookies** (based on `persistenceInCookieStorage`). * Find the Zeotap storage key (e.g., `zpstorage*...*identities`). * Inspect the stored value (decode if needed). You should find the specific hashed key (e.g., `email_sha256_lowercase`) and its hash value persisted.To send a pre-hashed cell phone number in Scenario 2:
cellno\_with\_country\_code\_sha256, cellno\_without\_country\_code\_md5).It's crucial to use the key that reflects your hashing source (with/without country code, E.164) and algorithm (SHA-256, MD5, SHA-1). See Cellno Handling Details.
**Implementation Example:** ```jsx title="Sending Pre-Hashed Cell Phone (SHA-256 with Country Code)" theme={null} // Assume 'hashedPhoneValue' contains the SHA-256 hash of the phone including country code (e.g., '15551234567') const hashedPhoneValue = 'f6e5d4c3b2a1a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4'; window.zeotap.setUserIdentities({ cellno_with_country_code_sha256: hashedPhoneValue }); ``` The specific hashed cell phone key and value will be passed in the payload: ```jsxon title="Identities in payload" {8-8} theme={null} "events": [ { { /* ... */ }, "user": { "zs": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "zi": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "zi_domain": ".zeotap.com", "cellno_with_country_code": {"sha256": "f6e5d4c3b2a1a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4"} // Hashed key/value sent }, { /* ... */ }, } ] ``` **Verification:** 1. **Network Call:** Check the payload for the specific PII key (e.g., `"cellno_with_country_code"`) and the hash value. 2. **Browser Storage:** Check the persisted identity profile for the specific hashed key and value.To send a pre-hashed login ID in Scenario 2:
loginid\_sha256\_lowercase, loginid\_md5\_uppercase).Supported hash types: SHA-256, MD5, SHA-1 (lowercase/uppercase variants).
**Implementation Example:** ```jsx title="Sending Pre-Hashed Login ID (SHA-256 Lowercase)" theme={null} // Assume 'hashedLoginIdValue' contains the SHA-256 hash of the lowercase login ID const hashedLoginIdValue = 'g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6a7b8c9d0e1f2a3b4c5d6e7f8'; window.zeotap.setUserIdentities({ loginid_sha256_lowercase: hashedLoginIdValue }); ``` The specific hashed login ID key and value will be passed in the payload: ```jsxon title="Identities in payload" {7-7} theme={null} "events": [ { /* ... */ }, "user": { "zs": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "zi": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "zi_domain": ".zeotap.com", {"loginid":{"sha256_lowercase":"g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6a7b8c9d0e1f2a3b4c5d6e7f8"}} // Hashed key/value sent }, { /* ... */ } ] ``` **Verification:** 1. **Network Call:** Check the payload for the specific PII key (e.g., `"loginide"`) and the hash value. 2. **Browser Storage:** Check the persisted profile for the specific hashed key and value.In this scenario, you provide raw PII to the SDK function, but configure the SDK to hash these values *before* sending the data over the network. This enhances privacy by preventing raw PII from leaving the browser via SDK network requests.
**Implementation Steps:** 1. **Configure the SDK Initialization:** Enable the SDK's built-in hashing and confirm that the values you will provide are raw. ```jsx title="SDK Initialization for SDK Hashing" theme={null} window.zeotap.init("YOUR_WRITE_KEY", { // --- Configuration for Scenario 3 --- hashIdentities: true, // Crucial: Tells the SDK TO perform hashing. areIdentitiesHashed: false // Crucial: Confirms the values you'll provide are RAW. }); ``` *This configuration activates the SDK's internal hashing mechanism for specific PII keys.* 2. **Send Identifiers using `setUserIdentities`:** Use the standard, recognized **raw keys** for PII and provide the **actual, raw user data**. The SDK will hash `email`, `cellno`, and `loginid` internally before sending. Expand the relevant PII type below:To have the SDK hash the user's email address in Scenario 3:
email.To have the SDK hash the user's cell phone number in Scenario 3:
cellno.'\[code] \[number]' (e.g., '1 5551234567'). This specific format is **essential** for the SDK to correctly identify the country code and national number, enabling it to generate multiple required hash types accurately.Using other formats (like `1555...` or just `555...`) will lead to incorrect or incomplete hashes being generated by the SDK. See Cellno Handling Details.
**Implementation Example:** ```jsx title="Sending Raw Cell Phone (SDK will hash - Format is CRITICAL)" theme={null} window.zeotap.setUserIdentities({ cellno: '1 5551234567' // Provide RAW phone in '[code] [number]' format }); ``` The SDK will generate multiple hashes (SHA-256, MD5, SHA-1) for each representation (without country code, with country code, E.164) based on the correctly formatted input and send them in the payload: ```jsxon title="Identities in payload (SDK Hashed - Cellno Complete Example)" {8-22} theme={null} "events": [ { { /* ... */ }, "user": { "zs": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "zi": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", "zi_domain": ".zeotap.com", "cellno_without_country_code": { // Hashes of '5551234567' "sha256": "sha256_hash_of_5551234567", "md5": "md5_hash_of_5551234567", "sha1": "sha1_hash_of_5551234567" }, "cellno_with_country_code": { // Hashes of '15551234567' "sha256": "sha256_hash_of_15551234567", "md5": "md5_hash_of_15551234567", "sha1": "sha1_hash_of_15551234567" }, "cellphone_number_e164": { // Hashes of '15551234567' "sha256": "sha256_hash_of_15551234567", "md5": "md5_hash_of_15551234567", "sha1": "sha1_hash_of_15551234567" } }, { /* ... */ } } ] ``` *(Note: Hash values shown are placeholders representing the different hashes generated by the SDK from '1 5551234567').* **Verification:** 1. **Network Call:** * Check the **Payload** of the Zeotap network request (e.g., `spl/fp?`). * Look for the `user` object. You should see the keys for each representation (`"cellno_without_country_code"`, `"cellno_with_country_code"`, `"cellphone_number_e164"`). Each of these should contain a nested object with keys for `"sha256"`, `"md5"`, and `"sha1"` and their corresponding hash values, as highlighted above. You should **not** see the raw phone number (`1 5551234567`) in the payload for these keys. 2. **Browser Storage:** * Check the persisted identity profile in **Local Storage** / **Cookies** (based on `persistenceInCookieStorage`). * You should find the **raw** `cellno` key and value (`"1 5551234567"`) stored.To have the SDK hash the user's login ID in Scenario 3:
loginid.