Identity Resolution

Rather than processing identity resolution in scheduled runs (or partially scheduled runs), Teavaro handles it all in real-time per Info Ident request. This includes applying rules for profile merging and switching in real-time based on incoming identifiers, as well as identifiers retrieved from internal and external systems.

For example a user logging in providing a login identifier could have the following situation:

1. First party cookie finds an anonymous visitor profile.

2. Login identifier finds an already digitally active customer profile.

3. Login identifier also finds newly imported or retrieved (e.g. via API) CRM identifiers belonging to the same person or household.

As these identifiers could have been used before without association to other accounts, the application runs a check and merges already existing profiles as per defined merging rules.

The Unified Marketing Identifier (UMID), which is created for each profile will be maintained based on the following default logic:

1. Anonymous visitor profile UMID when merged into customer profile is no longer maintained but linked to keep historic data connected to profile.

2. Customer profile UMID remains stable as long as the profile is not deleted.

3. Multiple customer profile merges are based on rules to prevent multiple identifiers of the same name being combined, maintaining the oldest UMID, while keeping the other UMID(s) and associated events data so it can be linked through the merge event.

Identification Methods

Anonymous Visitor

Every consented user gets a visitor profile and UMID. The device is linked to this profile via first party cookie set with server response using HTTPOnly, secure, and optionally path access restrictions. The default cookie time to live (TTL) is 365 days.

The following APIs support visitor profile creation:

• Info Ident Track

• Cross-domain Ident

• Click Ident

Login Ident

Login identification can use any available login / customer identifier. This could be a hashed email, CRM ID, or any other string. We can also handle dynamically encrypted identifiers, i.e. PII encryption with a different value output every time, using server-side on-the-fly decryption to obtain the identifier for profile lookup. We also provide an API to handle this for clients that not have this capability but would like to make their PII more secure and privacy compliant. See Encryption API.

The login identifier can be obtained from local storage, cookie, data layer or any other location available to JavaScript or a first party domain request.

See Info Ident Track API.

Click Ident

Click Identification utilizes knowledge about a user's identity at one touchpoint to seamlessly transfer that identity to another touchpoint. This technology supports various use cases, including click-to-call (available only on mobile devices), click-to-page (such as transitioning from an email to a website, SMS to a website, or from a mobile app to mobile web), and click-to-app functionalities.

One practical application of Click Identification is within emails or app push notifications, where it enables a 1st-party cookie link for the user. When a user clicks on an enabled link, their identity is transferred through FunnelConnect to the intended destination, effectively creating a 1st-party cookie link to the visitor or customer profile. The identifier can be transmitted as a query string parameter, and we accommodate any string value, including encrypted values. FunnelConnect can decrypt these values on the fly to retrieve the lookup ID.

Click Identification offers fully configurable identity resolution, which includes consent checks, optional new profile creation, profile merging, and context switching.

While it has its own tracking capabilities, it can also be integrated with other conversion tracking solutions, such as Google’s Floodlight or channel-specific click tracking tools (e.g., Salesforce, HubSpot, Emarsys ClickTracking).

For those utilizing a Multi-Domain ID Graph, multiple domain redirects can be implemented to propagate identity via 1st-party cookies across all domains. We recommend limiting this to a maximum of three domains to maintain effectiveness.

Privacy Compliance

The data controller must obtain permission to enable links in channels utilizing Click Identification. When employing specific push channels, such as Email or Mobile Applications, explicit consent is required to communicate with the end user, either broadly (through a contract) or specifically for the channel being used. For Web to Web click identification, consent can be gathered through cookie consents. Activating links with click identification without obtaining consent may constitute a violation of GDPR regulations.

Consent Checks within FunnelConnect

Assuming that the data controller has obtained consent prior to activating the original link with a click identification link, all requests directed to the FunnelConnect click identification endpoint are duly processed.

FunnelConnect can be set up to conduct further privacy compliance checks and adhere to customizable rulesets that respect users' preferences and consent status.

Scenario A: When FunnelConnect is enabled to manage server-side profile-level consent information, it can determine whether to set a persistent cookie. The recommended configuration is to only establish a persistent 1st-party cookie if cookie consent has already been granted for the domain. Possible sub-scenarios are: the server-side profile includes:

1. A valid Opt-In that serves as the legal basis for setting a 1st-party cookie:

   • If no cookie exists for the target domain in the browser, a new persistent 1st-party cookie is created and linked to the profile.

   • If a 1st-party cookie already exists in the browser and profile merging/switching is enabled, the cookie is either merged or switched to the profile based on the merge and switch configuration.

2. A valid Opt-Out exists, which mandates that identification be prevented. In this case, the recommended action is to redirect the end user to the original destination without setting the 1st-party cookie or taking any further action.

3. If there is no valid status or no profile exists yet, indicating that no cookie consent was granted previously, a session cookie linked to the existing or new profile is set. This session cookie will be converted into a persistent cookie once cookie consent is granted on the landing page. If the user chooses to opt out, the cookie is deleted after the session, rendering it unusable for future digital identification.

Scenario B: When FunnelConnect is not enabled to manage server-side profile-level consent information, it lacks the basis to implement decision logic. Therefore only two sub-scenarios are applicable:

1. If no 1st party cookie exists in the browser, the recommended configuration is to set a session cookie and act according to the cookie consent collected on the page after the redirect. If cookie consent is granted for the domain, the session cookie is “upgraded” to a persistent long-lived 1st-party cookie.

2. If a cookie already exists in the browser, no new cookie should be set. Instead, redirect to the landing page while attaching the provided user ID as a query string parameter. Depending on the availability of consent on the page, the FunnelConnect Info Ident API can be called with the existing cookie and the user ID from the query string to follow the merge and switch rules that are enabled.

We support any query string parameter and string value as Click-Ident identifier.

See Click Ident API.

Cross-domain Ident

Using first party cookie. This service can be used to link the identity from another domain than the one visited or proparate the identity of the domain visited to another domain belonging to the same controller, as long as cross-domain cookie consent is permitted.

This cross-domain identification is not affected by ITP or Ad Blocker restrictions.

The first party cookie set as part of the cross-domain can be configured as session cookie to deal with cookie consent taking place afterwards, in case of new browser session.

See Cross-domain Ident API.

Declared Ident

Users might not have a login but like to sign up to an email newsletter. We can use this “declared” identifier information for IDR. We can also do that in combination with our Encryption API to ensure PII is handled securely.

The email (or encrypted email) can be used as lookup ID to check already existing profile association.

We can capture the submitted email from local storage or provide a JS to handle it as required.

We also provide a popup manager solution, which can be enabled via our Web SDK, for example to ask for newsletter or other information with customisable popup notification.

This popup notification can be data-driven using profile targeting information inlined by the Web SDK using the Info Ident Track API.

Please reach out to your account manager or helpdesk@teavaro.com to find out more.

Telco Network Ident

Teavaro’s IDR DNA stems from the work with telcos over the past 10 years. Hence our solution being the foundation of the Utiq platform. We support different forms of telco network IDR from header enrichment, secure API calls using IP/PORT (non-spoofable), to GSMA Open
Gateway. We can also support other custom integrations as needed.

See Info Ident Track API.

Identifier Types

Teavaro supports any identifier and maps them to defined identifier types or creates new identifier types if needed.

Identifier types enable pre-defined logic for example how identifiers are stored and profiles merged.

Here are some of the main identifier types described.

Personal Identifiers

Personal identifiers are identifiers usually linked to a single person like for example a login identifier, email, and mobile phone number.

As such these identifiers are used in customer profiles, for profile merges and profile switching.

Device Identifiers

Device identifiers are specific to a device and usually obtained from (e.g. Apple’s Identifier for Advertisers, Google’s Advertising ID) or created on a device. They can be used as profile lookup identifiers or for activation across systems also collecting the same identifier(s).

Group Identifiers

Group identifiers can be linked to more than one user / person. As such they can be used for household profiling, analytics, and targeting activation. They would not be used for profile merging.

Cookie Identifiers

Teavaro creates a server-side cookie called umdid, which it stored under the client’s first party domain with HTTPOnly, Secure, and optional path restrictions. The umdid cookie is used as anonymous and identified customer profile lookup also after logout and cross different sessions. With its mentioned characteristics and the optional but recommended use of A record (rather than CNAME) DNS setup using a client specific frontend and subdomain, it appears as an integral part of the website, rather than external tracker. In that regards, Teavaro will only operate as data processor, making good of that appearance.

Profile Merging & Switching

Teavaro profiles flexible profile merging rule sets and also provides a profile switching capability in case a device is used by multiple people using different logins to the same site.

Merging Rules

The following default merging rules are applied. Special rules can be configured using identifier types.

Housekeeping

Housekeeping is a key component of IDR to make sure data compliance and quality is preserved.

Housekeeping can be set up following client specific requirements, here some example configurations: