Cross Device User Matching

Introduction

The Krux Data Management Platform (DMP) allows publishers and marketers to collect and organize all of their consumer web data in one central "big-data" warehouse. Using Krux DMP, organizations can consolidate and reconcile their first party "web-behavior" data that is generated by consumers as they engage with media and/or content with data from various third-party data providers like eXelate, DataLogix, Targus etc. Organizations can also integrate data from their user registration and subscription databases (hereon referred to as “first-party data”) into Krux DMP and join that data with web behavior and third-party data.

User data stored in Krux is keyed off a global Krux User Id. The Krux User Id is a third-party cookie and as such is specific to a browser (and correspondingly device too). On the other hand, first-party data that is ingested by the Krux platform is keyed off a first-party user ID that is provided to Krux by our clients. The first-party user ID typically comes from a user registration system and is the same across different browsers and devices for a given user. The client specific first-party user ID is mapped to the browser specific Krux User ID as part of the user matching and data loading process. As a result, it is possible to map and reconcile the browser specific Krux User Ids to an “Uber-ID’ using the client’s first-party, device-and-browser-agnostic user ID. This Uber-ID can then be used to build a profile of a user that spans browsers and devices.

In this document, we describe the user matching process between Krux and the client and provide details on the functionality and features enabled by the Uber-ID. The rest of this document is organized as follows: section 2 describes the user matching process, section 3 provides details on the functionality enabled by the cross-device Uber-ID and section 4 describes the steps required to configure and activate Cross-Device user matching in the Krux platform. 


User Matching

The User Matching process is facilitated by the Krux Control Tag and assumes that the first-party User ID is accessible to the Krux Control Tag JavaScript code. There are 2 possible options for the client to configure this:

  1. First-party User ID is present as a first-party cookie accessible to the Krux JavaScript code
  2. First-party User ID is available as a global JavaScript variable Krux will then configure a Data Transfer Code (DTC) that will create a User Attribute for the first-party user ID and the user ID will be passed to Krux’s data collection servers via the “pixel.gif” beacon call that sends data from the page to Krux for every page view. This User Attribute is marked by Krux as a special “User-ID” attribute and is not visible in Data Console via the Attributes report or in the Segment Builder. However, the First Party User Match Report (https://console.krux.com/audience/user_match_report) provides details on how many users have been matched over a rolling 90 and 30-day window.

The main output of the User Match process is a User Match table that maps the client’s first-party user ID to its corresponding Krux User ID for a given browser/device. This User Match table has 3 columns: 1. Client User ID: this is the client’s first-party user ID for the user 2. Krux User ID: this is the Krux User Id for the user 3. Browser Fingerprint: a unique signature that identifies the browser and device that the Krux User ID corresponds to

The User Match table is constructed in 2 steps:

  1. First, we create a daily user match table that has the following columns:
    1. Client User Id
    2. Krux User ID
    3. Browser Fingerprint
    4. Timestamp: this represents the latest time we saw a mapping from the client’s first-party user ID to the corresponding Krux User Id
  2. We then combine this daily data with the “current” user match table and pick out all the unique combinations of Client User Id, Krux User ID, and Browser Fingerprint. The current table will be empty for the first day and the data for day N will be constructed using the “current” table from day N – 1 and the daily data for day N


The Client User Id will have a one-to-many relationship with the Krux User ID in the User Match table. Note that there may be multiple Krux User Ids mapped to a given Client User Id for the same Browser Fingerprint because a user may clear their third-party cookies and Krux will assign a User Id to a user (browser) that doesn’t already have a Krux User ID and hasn’t Opted-out or enabled Do Not Track (DNT) (The DNT signal is ignored for IE10).


Cross-Device Uber-ID Features

Once the User Match table has been constructed, the client’s first-party user ID can be used as an “Uber-ID” to create a joint profile of user activity across different browsers and devices. This joint profile can then be used in the segment building process allowing Krux clients to build more comprehensive audience segments that can be leveraged across multiple devices. In this section, we will describe how that process works in detail.

We will use a fairly simple example to illustrate the functionality. First, let’s create a simple user match table for a user with a given first-party client User ID and 2 Krux User IDs – one from Chrome on the Desktop and another from Chrome on the user’s Android mobile device. This simple user match table looks like:
 

Client Uber ID

Krux User ID

Browser Fingerprint

CL1234

KX9999

Chrome_desktop

CL1234

KX8888

Chrome_mobile

 
Next, let’s assume that our client is called Acme Media Company and Acme has 2 sites: Site A and Site B and user CL1234 visits both sites using Desktop Chrome and Mobile Chrome. Specifically, let’s assume the following site traffic profile for user CL1234 (note that the site user profile is stored using the Krux User ID, not the Client User ID):
 

Client

Site

Day

Krux User ID

Pageviews

Acme

Site A

2018-01-05

KX9999

2

Acme

Site B

2018-01-06

KX9999

4

Acme

Site A

2018-01-07

KX8888

3

Acme

Site B

2018-01-08

KX8888

2

 
In other words, user KX9999 generated 2 page views on 2013-10-25 on Site A and 2 page views on 2013-10-26 on Site B. For the purposes of this example, let’s assume that this is the complete site traffic profile for users KX9999 and KX8888 respectively.

Finally, let’s assume that Acme Media Company has defined 2 segments:

  1. Site A Loyalists: Any user who has generated at least 5 page views in last 7 days on Site A 
  2. Site B Fanatics: Any user who has generated at least 10 page views in last 7 days on Site B

Based on the segment rules and the site traffic data above, neither KX9999 nor KX8888 will be assigned to either Site A Loyalists or Site B Fanatics when the segments are processed on 2013-10-27.

However, we know that KX9999 and KX8888 map to the same client user ID – CL 1234. By using the User Match table, we can rewrite the Site Traffic table like so:
 

Client

Site

Day

Uber ID

Pageviews

Acme

Site A

2018-01-05

CL1234

2

Acme

Site A

2018-01-06

CL1234

3

Acme

Site B

2018-01-07

CL1234

4

Acme

Site B

2018-01-08

CL1234

2


Using this site traffic table, we see that user CL1234 meets the rules for Site A Loyalists but not Site B Fanatics. By using the user match table and the Uber ID, we have created a joint profile for Krux Users KX9999 and KX8888 across Chrome Desktop and Chrome Mobile and put both users in a segment using their joint site traffic profile.

The next step in this process involves associating both KX9999 and KX8888 with the Site A Loyalists segment so that it is accessible to the Krux Control Tag for Interchange O&O in both Chrome Desktop and Chrome Mobile. In other words, if a campaign is targeted to the Site A Loyalists segment, Krux users KX9999 and KX8888 will both be eligible for that campaign via their association with the same client first party user ID, CL1234.

Finally, it is important to note that the Krux Segment Builder will count both KX9999 and KX8888 in the population count for Site A Loyalists. The Segment table in Data Console (http://dataconsole.kruxdigital.com/audience_data/segments) will be enhanced to show the “de-duplicated” population count in addition to the regular population count. In the example above, users KX9999 and KX8888 will be “deduped” to user CL1234 in the “de-duplicated” population count for the Site A Loyalists segment.


Configuration and Setup

Your Krux solutions team will work with you to activate the Data Transfer Code required to setup the user matching process. The team will also be responsible for activating the Cross-Device user-matching feature for your account in the Krux platform. Once the feature is enabled in the Krux platform all the backend processes for segment processing will automatically use the “Uber-ID’ versions of the various user level datasets: Site Hierarchy, Page/User Attributes, Event Pixels, Third-Party Data, etc. Please allow 7 days after activation for the feature to be live and fully configured.


Have more questions? Submit a request

0 Comments

Article is closed for comments.