Back to User ID Module

LiveIntent nonID

LiveIntent offers audience resolution by leveraging our next-generation identity solutions. The LiveIntent identity graph is built around a people-based set of data that is authenticated daily through active engagements with email newsletters and media across the web. The LiveIntent nonID is a user identifier tied to an active, encrypted email in our graph and functions in cookie-challenged environments and browsers.

Build your Prebid.js package to include the LiveIntent nonID using the standard version which allows publishers to include the module with full functionalities, like hashing email addresses and identity resolution.

Add the full LiveIntent Identity module to your Prebid.js package with:

gulp build –modules=userId,liveIntentIdSystem

The request.userId.lipb object would look like:

{
  "lipbid": "T7JiRRvsRAmh88",
  "segments": ["999"]
}

The adapters can be implemented to use the lipbid as the identifier and segments to which that identifier is associated with. To enable identity resolution for a specific publisher, LiveIntent builds a model on the backend with data collected via an additional call issued on each page load.

LiveIntent ID Registration

Please register with us if you’re not already a LiveIntent customer: https://www.liveintent.com/prebid-registration/

LiveIntent’s privacy policies for the services rendered can be found at https://www.liveintent.com/services-privacy-policy/

How does LiveIntent ID work

The LiveIntent ID sub-module resolves the identity of audiences by connecting impression opportunities to a stable identifier - the nonID. In order to provide resolution one or more first-party cookies are used to create a stable identifier.

How does LiveIntent ID sub-module decide, which first-party cookies to use:

1. By default LiveIntent ID sub-module generates its own first-party identifier on the publisher’s domain. Publishers have the option to disable the cookie generation when configuring the LiveIntent ID sub-module.
2. A publisher can also define in the configuration which additional first-party cookies should be used. These can be used in a combination with the LiveIntent first-party cookie.

The LiveIntent ID sub-module sends the defined identifiers to the identity graph, which processes them and creates a nonID. The parameters being sent are described here

For the identity resolution the LiveIntent ID sub-module makes a request to LiveIntent’s identity resolution API, which returns a nonID and the audience segment(s) a user belongs to. The nonID and the segment ID are then exposed by the Prebid User ID Module to Prebid adapters to be sent out in a bid request. An SSP can then make the impression opportunity available to any buyers targeting the segment.

The first-party cookie generation and identity resolution functionality is provided by the LiveConnect JS library, included within the LiveIntent ID sub-module. LiveIntent has created a shared library that is open source, available at https://www.npmjs.com/package/live-connect-js.

The LiveIntent ID sub-module follows the standard Prebid.js initialization based on the GDPR consumer opt-out choices. With regard to CCPA, the LiveConnect JS receives a us_privacy string from the Prebid US Privacy Consent Management Module and respects opt-outs.

Configuring requested attributes

Attributes other than the nonID can be requested using the requestedAttributesOverrides configuration option.

For example, with the configuration below, the nonID as well as ‘uid2’, the ‘medianet’ id and the ‘bidswitch’ id will be requested:

pbjs.setConfig({
    userSync: {
        userIds: [{
            "name": "liveIntentId",
            "params": {
                "publisherId": "12432415",
                "requestedAttributesOverrides": {'uid2': true, 'medianet': true, 'bidswitch': true},
            },
        }]
    }
});

Multiple user ids

The attributes ‘uid2’, ‘medianet’ or ‘bidswitch’ are treated specially by LiveIntent’s user id sub-module. Each of these three attributes will result in a separate id returned by the sub-module.

For example, in case ‘uid2’ is configured to be requested - additionally to the nonID - the request.userId object would look like this:

```
{
    ...
    "lipb" : {
        "lipbid": "sample-nonid-value",
        "segments": ["999"],
        "uid2" : "sample-uid2-value"
    },
    "uid2" : {
        "id" : "sample-uid2-value"
    }
    ...
}
```

Note that ‘uid2’ is exposed as part of ‘lipb’ as well as separately as ‘uid2’. ‘medianet’ and ‘bidswitch’ behave the same way.

For the attributes ‘lipbid’ (nonID), ‘uid2’, ‘medianet’ and ‘bidswitch’ there is also support for their conversion into OpenRTB EIDS format. Please refer to userId.md for more information on conversion and eids.md for output format examples.

Requesting uid2

An attribute that requires special mention here is ‘uid2’. If this attribute is resolved by the id sub-module, it will be exposed in the same format as from the Unified ID 2.0 user id module. If both the LiveIntent module and the uid2 module manage to resolve an uid2, the one from the uid2 module will be used. Enabling this option in addition to the uid2 module is an easy way to increase your uid2 resolution rates. Example configuration to enable uid2 resolution:

pbjs.setConfig({
    userSync: {
        userIds: [{
            "name": "liveIntentId",
            "params": {
                "publisherId": "12432415",
                "requestedAttributesOverrides": {'uid2': true},
            },
        }]
    }
});

LiveIntent ID configuration

NOTE: For optimal performance, the LiveIntent ID module should be called at every opportunity. It is best not to use params.storage with this module as the module has its own optimal caching mechanism.

LiveIntent ID examples

1. To receive the LiveIntent ID, the setup looks like this.

   pbjs.setConfig({
    userSync: {
        userIds: [{
            name: "liveIntentId",
            params: {
              publisherId: "9896876"
            },
            storage: {
            type: “cookie”,
            name: “pbjs_li_nonid”,    //create a cookie with this name
            expires: 1                // cookie is stored for 1 day
            }
        }]
    }
   })
   

2. If you are passing additional identifiers that you want to resolve to the LiveIntent ID, add those under the identifiersToResolve array in the configuration parameters.

   pbjs.setConfig({
    userSync: {
        userIds: [{
            name: "liveIntentId",
            params: {
              publisherId: "9896876",
              identifiersToResolve: ["my-own-cookie"]
            },
            storage: {
            type: “cookie”,
            name: “pbjs_li_nonid”,    //create a cookie with this name
            expires: 1                // cookie is stored for 1 day
            }
        }]
    }
   })
   

3. If all the supported configuration params are passed, then the setup looks like this.

   pbjs.setConfig({
    userSync: {
        userIds: [{
            name: "liveIntentId",
            params: {
              publisherId: "9896876",
              identifiersToResolve: ["my-own-cookie"],
              url: "https://publisher.liveintent.com/idex",
              partner: "prebid",
              ajaxTimeout: 1000,
              liCollectConfig: {
                fpiStorageStrategy: "cookie",
                fpiExpirationDays: 730,
                collectorUrl: "https://rp.liadm.com",
                appId: "a-0012"
              }
            },
            storage: {
            type: “cookie”,
            name: “pbjs_li_nonid”,    //create a cookie with this name
            expires: 1                // cookie is stored for 1 day
            }
        }]
    }
   })
   

Back to User ID Module