Skip to end of metadata
Go to start of metadata

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 Header Tag Wrapper

When an RTI adapter is enabled in the publisher's Header Tag Wrapper UI, the following process occurs:

  1. On page load, the Wrapper 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 Wrapper 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 Wrapper.

    2. If there is no RTI partner cached, the Wrapper 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 Wrapper instance (page load) to the RTB adapter(s) that are active in the Wrapper and configured to collect the RTI partner identifer.

    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 Wrapper adapters for this page load will not have an identifier to include on their bid request volume.


Verifying Presence of a Cached localStorage 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 Wrapper. 

Managing Timeouts with RTI

Some Wrapper publishers might be concerned that enabling RTI adapters would result in a degraded monetization environment because the Wrapper 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 Wrapper.

Presence vs Priority Design

The Wrapper 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 Wrapper 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. 

Wrapper Start vs Display Start

There are several "start times" within the IX Header Tag Wrapper: There is the page load start, the wrapper start, and the demand start. While page load and wrapper load are self explanatory, it might not be immediately obvious what a demand start is. In short, demand start is when the wrapper 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 wrapper start and demand start (variable across publishers, wrapper implementations and pages)

  • A conditional 50 ms pause built into the RTB adapter process (demand start + 50 ms)

Note: 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 wrapper 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 wrapper 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 Wrapper Timeout Data: To review timeout data related to adapters within the Header Tag Wrapper, users can review the Wrapper Pulse data located within the Index Exchange 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. 

Feedback

  • No labels