Implementing LiveRamp’s Real-Time Identity Service Tag
Integrations with LiveRamp are built around communicating via RampIDs, our people-based, cross-device identifiers. One way this process can be enabled is via the Real-Time Identity Service (RTIS), a tag that can track website visits and ad traffic. When the tag fires, LiveRamp will return a RampID to your server endpoint, providing you a people-based identifier that can be used for personalization and measurement use cases.
Integrations with LiveRamp are built around communicating via RampIDs, our people-based, cross-device identifiers. One way this process can be enabled is via the Real-Time Identity Service (RTIS), a tag that can track website visits and ad traffic. When the tag fires, LiveRamp will return a RampID to your server endpoint, providing you a people-based identifier that can be used for personalization and measurement use cases.
Note
If you'd like the RampIDs of your web visits to be returned directly back to the browser in a JSON object, talk to your Implementation manager about the RTIS API (rather than the RTIS pixel).
The LiveRamp tag is certified to run on a number of platforms, including Google AdX. There are some platforms where LiveRamp is not certified, such as Facebook or GDN. Contact your technical support representative to learn more.
If you are planning on sending data to LiveRamp for matching to other platforms, a cookie sync or proprietary platform ID sync is required.
Advantages of Integrating via the Real-Time Identity Service
Receiving RampIDs in real-time and using them to communicate with LiveRamp presents sizable benefits over standard cookie syncs. RampIDs are people-based IDs that you can use to identify customers across their devices, enabling the use cases listed below.
Enables People-Based, Real-Time Use Cases
By resolving website and ad impressions to people in real-time, you can access people-based data immediately at the time of impression for your own measurement and personalization products.
Recognize and Act On More Devices
Since disparate devices are matched to the same RampIDs, a device you don't recognize could be matched, through a RampID, to a known device, making that impression actionable and measurable.
Match to Offline and Third-Party Data
Offline and third-party data can be matched to the same people-based RampIDs as impressions. When firing the Real-Time Identity Service tag on a web visit, you can leverage offline and third-party data to make more informed decisions for that user.
Track and Measure More Data Over Time
With impressions matched to a persistent, people-based ID, data are stitched across devices and not lost over time with new cookies or phones.
Leverage LiveRamp Cookies
By leveraging LiveRamp cookies, the Real-Time Identity Service gives you direct access to the large scale of LiveRamp recognition, regardless of whether or not you have the user synced with LiveRamp or even if you have cookied the user.
Capture Custom Information with Custom Parameters
You can use the Real-Time Identity Service to pass arbitrary, URL-encoded string values to LiveRamp as custom parameters (CPARAMS) along with your pixel call, which we return as-is in the response and can be used to compile log files on your end in real-time.
Access LiveRamp's Identity Services
Integrating with LiveRamp via RampID gives you access to all of our identity services, enabling a wide variety of products and use cases.
Enable Onboarding Services in Your or LiveRamp's UI
Onboard offline marketer data, from customer records to transaction data, for CRM targeting and closed-loop measurement. Powered via your UI or ours.
Leverage Third-party Data via LiveRamp's Data Marketplace
With one contract, access third-party data from 100+ data owners, with flexible commercial terms for targeting, measurement, and scaling campaigns.
Integrate with Platforms
Deliver data to over 500 marketing platforms, or ingest their data into your platform.
For more information about the advantages of RampIDs, check out the Real-Time Identity Service 2-pager.
Use Case Examples
Measurement
The tag can be placed on-site or in ad creatives to build ad traffic logs keyed to RampIDs in real-time. When implemented as an impression/click tracker, the tag will fire and redirect to your endpoint, passing the RampID, as well as any metadata that is passed in the CPARAMs URL parameter.
Caution
Note that some publishers will block third-party tracking tags entirely, or only allow them to run some of their properties. Contact your LiveRamp representative to see if our tag is approved to track traffic on your target inventory.
Personalization
The tag can also be placed on a website to personalize content for your visitors. When implemented on your webpage, the tag will fire and redirect to your endpoint, passing the RampID, as well as any metadata passed in the CPARAMs URL parameter.
The RampID can then be used to look up segment data, or other known data on the individual for site-personalization.
Expected Recognition Rates
For our PII Onboarding workflows (where we're typically matching from PII to cookies), we often look at the "match rate" to determine how well we're able to match your input data to devices at a destination.
For the Real-Time Identity Service (RTIS) tag, because we're effectively matching from cookies to people (RampID s), we use the metric "recognition rate" instead to more accurately represent how well the data sent by a given tag is performing. This rate is often lower than typical PII Onboarding match rates because of the way these numbers are calculated.
Although the way we calculate the two metrics is similar, there are some key differences.
Generally, people have one email, one address, and one phone number. However, they usually have many cookies. When matching emails to cookies, we just need to match to one of a person's online devices to get a "match." However in RTIS, we're going from cookies to people (RampID s), so we need to be able to recognize all of their cookies to get a 100% rate.
For example, say a consumer has 5 cookies connected to them. If you sent us their email address via Onboarding and we matched to only one of their cookies at a destination, that's a 100% match rate: we matched 100% of the emails you sent us to at least one cookie.
However, if you sent us those same 5 cookies through a mechanism like RTIS and we matched to only one of them, that looks like a 20% match rate (1 cookie out of 5). So in each case, the exact same match is happening (1 cookie <-> 1 email), it just looks worse going from online devices -> real people (RampID s). There are just way more devices than there are people/PII, so it's much more challenging to match to all of them. This is why we use a recognition rate for this type of "matching."
There are also other factors that impact cookie matching that don't impact PII matching. For example, many cookies are dead within a few days, giving us very little opportunity to create a match. And there's also a massive amount of bot traffic out there. So the recognition rate is potentially deceptively low in that the denominator is often inflated with devices it's impossible to match.
Due to all of these factors, it is very hard to give estimated recognition rates and we suggest running a test to check what those recognition rates look like on your traffic.
Implement the Real-Time Identity Service Tag
The Real-Time Identity Service is implemented via a 1x1 image pixel with an optional flexible parameter that will accept any URL-encoded string and works anywhere LiveRamp has direct cookie access. You do not need to pass any form of an identifier to LiveRamp for the service to work.
The tag can be implemented via a web pixel or via JavaScript.
Implement via Web Pixel
Tell your LiveRamp rep what endpoint you want the tag to deliver data to (e.g., "www.yourdomain.com/endpoint").
LiveRamp configures and delivers the tag ID to you. An example of a request URL is "https://id.rlcdn.com/<TAG ID>.gif".
Note
The RTIS request URL can be implemented through an image pixel or iframe, depending on what you are most comfortable with. When using either image, iframe, or other implementation method, notify your LiveRamp representative so that they can make the appropriate edits on our end.
Set up CPARAMS, if desired (you can create as many configurations as desired without LiveRamp making additional changes).
Implement tag containing the tag ID on sites or in ad creatives.
If you are doing measurement for a specific ad campaign or brand, you can place campaign metadata into the CPARAMS section. CPARAMS inserted into the tag could look something like:
?cparams=brand_a_campaign_b_strategy_c_channel_d_300x250_impression
?cparams=brand_a_campaign_b_strategy_c_channel_d_300x250_click
Caution
All CPARAMS values must be URL encoded. See "How can I URL encode values that I want to include as CPARAMS?" for more information on URL encoding.
Caution
There is no limit on the number of CPARAMS you can pass through a request. However, be aware that there is a limit based on an HTTP URL’s maximum size, which is 2KB.
Implement via JavaScript
If you prefer, you may implement the RTIS pixel via JavaScript. However LiveRamp will be unable to assist you in troubleshooting your JavaScript creation and deployment. LiveRamp's Implementation team will only be able to check that the pixel is firing and redirecting properly.
Talk to your Implementation manager to find out more about implementing via JavaScript.
More Information About RampIDs
RampID s are LiveRamp’s people-based, cross-device identifiers that you’ll use to communicate with LiveRamp. A RampID is a privacy-safe, online representation of an individual, built by deterministically merging offline PII (personally identifiable information, such as email address, name, postal address, and phone number) and matching to cookies, mobile device IDs, and proprietary platform IDs.
See the articles below for more information about RampIDs:
"RampID Methodology" for information on how RampIDs are created, and how LiveRamp’s identity graph functions on the whole.
"Interpreting RampID, LiveRamp's People-Based Identifier for information on how to interpret the identifiers returned from the Real-Time Identity Service.
RampID's deterministic standards vs. probabilistic, cross-device matching
FAQs
See below for answers to some common FAQs.
What is the baseline recognition rate for users coming to my website?
LiveRamp cannot give estimates on a baseline recognition rate for your traffic because every client’s traffic differs in terms of demographics and size.
How can I URL encode values that I want to include as CPARAMS?
All letters (a-z, A-Z), numbers (0-9), dashes (-), underscores (_), dots (.), and tildes (~) can remain as is. Other symbols should be changed to their associated three-character string in the second row of the table below.
! | # | $ | % | & | ' | ( | ) | * | + | , | / | : | ; | = | ? | @ | [ | ] |
%21 | %23 | %24 | %25 | %26 | %27 | %28 | %29 | %2A | %2B | %2C | %2F | %3A | %3B | %3D | %3F | %40 | %5B | %5D |
Can I change the endpoint where RampIDs are being delivered?
Yes. Create a support case and include your RTIS tag ID, your current endpoint, and the updated endpoint. We will update the RTIS pixel workflow to reflect those changes in the redirect that is being made to your current endpoint.
Does LiveRamp support multiple RampIDs returned through RTIS?
No. LiveRamp cookies only store information associated with one RampID.
How do opt-outs work?
If a user has an opt-out cookie on their browser or has come directly to LiveRamp to opt themselves out of LiveRamp workflows, then RTIS will not work as expected. For the RTIS pixel, you will see Status Code 200 (because there is no redirect to your specified endpoint), rather than the expected Status Code 307. This is due to the RTIS pixel picking up the opt-out cookie or having matched to an opted-out RampID. Requests where a user is opted-out will not return a RampID or any placeholder identifier in its stead.
Why am I seeing a 451 error status when I try to call the tag?
LiveRamp’s pixel server returns a 451 status code when a request is made from a country on the country exclusion list for that tag. If you are serving traffic from the EU, there might be special paperwork required, so work with your account team to determine where you are allowed to use your tag if you believe this is necessary.
What happens when the RTIS pixel is fired in a non-cookieable environment (such as Safari)?
This depends on your specific configuration. By default, RTIS will return a blank value for the user's RampID. However, if you have placeholder RampIDs enabled you will get a returned RampID with the prefix “Xc”. This, of course, will not carry over to the user’s other sessions in non-cookieable browsers as the cookie being used to determine the RampID will change every session (this is true for all non-cookieable browsers).