Real Time Identity via IX Library

To date, Index Exchange (IX) offers Real Time Identity (RTI) solutions with the following RTI partners:

Real Time Identity (RTI) Framework

The Real Time Identity (RTI) framework allows publishers to collect only the identifiers they need and to suppress unnecessary network calls for an ID they already have. An RTI adapter uses the Real Time Identity (RTI) framework to intelligently call, cache, and expose identifiers for partners in our ecosystem.

RTI Functionality Within the IX Library

When an RTI adapter is enabled in the publisher's IX Library™ UI, the following process occurs:

  1. On page load, the IX Library checks to see if a cached value for the RTI partner ID is stored locally.
    1. If a cached value is found (stored within the IXWRAPPERAdserverOrgIp object within a user's localStorage/HTML 5 cookie) the IX Library considers there to be an active, cached identifier. As a result, it makes no additional network calls and proceeds to launch the respective network calls for RTB adapters in the IX Library.
    2. If there is no RTI partner cached, the IX Library holds the RTB adapters calls for up to 50 ms, giving the RTI partner endpoint time to respond with a user ID.
  2. If the RTI partner endpoint response time is:
    1. Under 50 ms: this ID is written locally and participating adapters can then read and include it in the bid requests sent from this IX Library instance (page load) to the RTB adapter(s) that are active in the IX Library and configured to collect the RTI partner identifier.
    2. Longer than 50 ms beyond demand start time: the RTI partner ID is stored locally, so that subsequent page loads will have a cached ID (step 1A), eliminating the need for a network call. Bid requests issued from IX Library adapters for this page load will not have an identifier to include on their bid request volume.

Verifying Presence of a Cached Local Storage Object

Type localStorage.IXWRAPPERAdserverOrgIp into the console within Chrome developer tools, and you should see the following code if the RTI partner ID was set correctly. This will be cached for seven days, at which time it will be reset via a fresh call. This value is stored uniquely per IX Library.

An example of a successul response to the localStorage.IXWRAPPERAdserverOrgIp call.

Managing Timeouts with RTI

Some IX Library publishers might be concerned that enabling RTI adapters would result in a degraded monetization environment because the IX Library is now "holding" RTB calls up to 50 ms, giving RTB adapters less time to respond with valid bids. However, this concern is mitigated via an intelligent design that is native to the IX Library.

Presence vs Priority Design

The IX Library generates a network request only in the absence of an RTI partner user ID. If the ID is present, the RTB stage is triggered immediately. Historically, most client-side user matching (also referred to as user syncing) is done on a system of priority: the platform that drops the pixel does so based on a historical, server-side priority. By moving to a presence-based design, the IX Library only generates a call (and therefore, imposes an RTI timeout window) when there is no ID present.

In testing, this has resulted in 85% less "user syncing" network calls when moving to a presence-based design, resulting in faster webpages and a short, conditional timeout window.

IX Library Start vs Display Start

There are several "start times" within the IX Library. There is the page load start, the IX Library start, and the demand start. While page load and IX Library load are self explanatory, it might not be immediately obvious what a demand start is. In short, demand start is when the IX Library has enough information about the opportunities on the page (ad slots) in order to generate bid requests for RTB adapters.

If a network call to an RTI partner is deemed necessary, the RTI adapter has both:

  • The time between IX Library start and demand start (variable across publishers, IX Library implementations and pages)
  • A conditional 50 ms pause built into the RTB adapter process (demand start + 50 ms)


If a Consent Management Platform (CMP) is configured, demand start will occur after CMP responded or timed out.

Ultimately, there ends up being a small, variable amount of time between IX Library start and demand start.

Thus, in practice, an RTI adapter has significantly more than 50 ms to respond with their identifier, and the conditional 50 ms is only ever triggered on the fastest, most low-latency pages on the internet. In the majority of cases, the RTI partner is able to respond in the time between IX Library start and demand start, resulting in a real-time ingestion of the RTI partner identifier without any impact to latency and timeouts of RTB adapters.

Measuring Timeout Impact

Index Exchange publishers can measure for themselves the impact of enabling RTI. In testing, preloading and the presence-based design has not resulted in any demonstrable impact to publisher revenue and bidding activity. Of course, all publisher implementations are unique, and if a publisher wants to check the impact of enabling RTI, they can do so in two locations:

  1. For IX Library Timeout Data: To review timeout data related to adapters within the IX Library, users can review the Library Pulse data located within the IX app or within a publisher's IX Domo environment.
  2. For DSP Timeout Data: Publishers can review DSP-specific timeout data via their Domo environment, specifically focusing on visualizations and datasets that contain DSP timeout data.

Timeouts continue to be a key area of focus for publishers and Index Exchange, but our testing indicates that the design of RTI adapters doesn't appear to have an impact on publisher revenue.

Was this page helpful?

You are invited to take a 1-minute survey to help us improve this site.