RampID Mapping Files
Mapping files are flat files that allow you to see a mapping between an external identifier (such as a cookie, mobile device ID, connected TV ID, or custom ID) and a RampID, our pseudonymous, universal identifier. These files are delivered to you on a regular basis.
Note
For EU and UK customers, these types of files are referred to as “conversion files”.
RampID mapping files are not available in APAC markets.
See the “Set Up Mapping File Deliveries” section of this article when you’re ready to get started with Mapping Files.
Mapping File Types
The available file types include the following mappings:
Cookie file: A file that maps your cookies to RampIDs
IDFA file: A file that maps IDFAs (Identifier for Advertising, the mobile device ID for Apple/iOS devices) to RampIDs
AAID file: A file that maps AAIDs (Android Advertising ID, the mobile device ID for Android devices) to RampIDs
CID file: A file that maps your custom identifiers (CIDs) to RampIDs
CTV file: A file that maps your connected TV IDs (CTV IDs) to RampIDs
A cookie mapping file is generated by collecting site traffic. You enable this by implementing a cookie sync with us through the use of a pixel.
Note
The lookback window for cookies is 90 days.
Mobile device ID mapping files (for IDFA and AAID) are built from our mobile device mapping pool, which is powered by the site traffic from our entire match partner network.
Mapping File Uses
Mapping files can be used in a large number of use cases and workflows. Typical uses include:
Powering targeting and measurement for your application/platform users.
Recognizing non-logged in users on your website for site personalization.
Improving monetization by expanding the device reach of your segments.
Set Up Mapping File Deliveries
To set up a new mapping file, contact your account team and provide the following information:
Note
To request changes to an existing mapping file, create a support case.
The types of RampIDs you want to receive.
Whether you want to include a “Last seen at” timestamp column.
Note
"Last seen at" timestamps cannot be added to CTV or CID mapping files.
The delivery frequency you want your mapping deliveries set at: daily, weekly, monthly, or quarterly.
The delivery location where you want these mapping files delivered to (this is usually an S3 or SFTP endpoint).
See the sections below for more information.
Note
These configurations can be adjusted at any time.
The delivery date for the mapping files is determined by the initial mapping file creation date. For example, if you select a monthly cadence and the first mapping file is created on the 10th of the month, all subsequent deliveries will occur on the 10th.
By default, we split files into multiple 5GB parts before delivery, but this size can be changed if you prefer to receive a different size.
The Types of RampIDs You Can Receive
You can choose to receive just maintained RampIDs or you can choose to receive additional individual RampID types if a maintained RampID is not available. Feel free to select multiple or all options.
Note
Most companies choose to receive maintained and derived RampIDs, but consult with your LiveRamp rep to determine what makes the most sense for your use case.
Maintained RampIDs: LiveRamp has a full understanding of this cookie or mobile device ID as an individual tied to multiple PII touchpoints. Maintained RampIDs start with the prefix “XY” and are 49 characters long.
Derived RampIDs: Derived RampIDs are returned when a maintained RampID does not exist in our graph for the given device. LiveRamp has associated PII with this cookie or mobile device ID, but it is not complete. A derived RampID may become a maintained RampID when we build a more complete picture of the associated devices. Derived RampIDs start with the prefix “Xi” and are 70 characters long.
Placeholder RampIDs: Placeholder RampIDs can be returned when no maintained or derived RampID exists for the given device. LiveRamp has no PII associated with this device but does have a LiveRamp cookie associated with your cookie. Placeholder RampIDs allow you to track online events even when the cookie or mobile device ID is not associated with PII. Placeholder RampIDs for cookies start with the prefix “Xc”. Placeholder RampIDs for mobile devices start with “Xm”. Both types of Placeholder RampIDs are 49 characters long.
Household RampIDs
In addition to an individual RampID, you can choose to also receive a household RampID (if one is available) for any records with maintained individual RampIDs. Every maintained RampID in the graph that's associated with a postal address is placed into a household of one or more people. LiveRamp creates households based on an algorithm that takes into account factors like current address, last name, and history of moving together. Any household RampIDs would be returned in a third column in the mapping file. Household RampIDs start with the prefix “hY” and are 49 characters long.
Cookie Mapping File Example
Caution
Receiving Household RampIDs will require an additional cost, unless it is already in your contract.
Tip
See "Identity and Identifier Terms and Concepts" for more information.
“Last seen at” Timestamps
You have the option to include a “Last_seen_at” timestamp column in cookie or mobile device ID mapping files. These timestamps would be returned in an additional column in the mapping file.
Note
"Last seen at" timestamps cannot be added to CTV or CID mapping files.
Timestamps will be in Unix Epoch format.
Cookie Mapping File Example
Note
For any rows where the consumer has opted out of data collection, the "Last_seen_at" column value will be "null."
Timestamps for Mobile Devices IDs
For mobile device IDs, the “Last seen at” timestamp is the most recent timestamp associated with that mobile device ID from our feed of mobile data. In other words, it's the most recent appearance of that mobile device ID <> RampID linkage across our network of mobile match providers.
Timestamps for Cookies
For cookies, the “Last seen at” timestamp is the last sync date with LiveRamp.
Note
For cookies it's important to note that the last sync date corresponds to that of the LiveRamp cookie associated with your cookie, not your cookie itself. This means that if we see the LiveRamp cookie we've associated with your cookie active elsewhere on our network of match providers, the timestamp will remain current even if you haven't sent your cookie to us for a sync. Since you already know on your end when you last saw your own cookie, you benefit from additional information on whether the user is still active across LiveRamp’s massive footprint.
Delivery Frequency Options
Mapping files can be delivered and updated in the following ways:
Daily incremental updates: Receive daily updates that contain only the updates.
Daily backlog delivery: Receive 1/Nth of all 90 days of users LiveRamp has in sync with your platform, where N is the number of days in the given month. The backlog will consist of previously synced RampIDs.
Full refresh: Receive a full RampID mapping file (daily, weekly, or monthly)
Note
LiveRamp recommends that you only select one delivery option per mapping file type (cookie, IDFA, AAID, etc.).
Note
Cookie lookback: LiveRamp only stores cookies on our end for 90 days. If you need to be able to look back further than 90 days, you'll need to get incremental updates so that you can build a mapping on your end.
Caution
When receiving incremental updates for Mapping Files that include “Last seen at” timestamps: Note that incremental deliveries only include net new cookie<>RampID and mobile device ID<>RampID linkages, or changes to existing linkages. Because “Last seen at” timestamps are treated as metadata associated with each linkage, a change to only the timestamp for a linkage will not cause that linkage to be included in an incremental delivery. Only changes to the underlying linkage cause that linkage to be included in an incremental delivery.
If this poses an issue for your workflow, talk to your account representative about receiving a full refresh of your mapping periodically to keep all timestamps up to date.
Delivery Location Options
Typically, clients choose to have us send these mapping files to either their Amazon Web Services (AWS) S3 bucket or SFTP. See “Set Up LiveRamp File Deliveries” for a list of all available delivery options and the information required to set up deliveries for each option.
The Number of RampIDs You Can Receive
There are two options for the number of RampIDs you receive in your mapping files:
One RampID per identifier
Multiple RampIDs per identifier
For cookie mapping files and mobile device ID mapping files, the default is to receive one RampID per cookie or mobile device ID. This is because cookies and mobile devices typically have one user, so receiving multiple RampIDs does not usually provide much additional reach. In addition, receiving multiple RampIDs for an online identifier might require complex decision-making around assignments (such as how to “break the tie” between multiple RampIDs).
Note
While there is one RampID per cookie or MAID, a RampID could have multiple MAIDs or cookies associated with it (a 1:many relationship).
For CTV (connected TV) mapping files and CID (Custom ID) mapping files, you can elect to receive all associated RampIDs for each identifier. This can be helpful if the identifiers you’re working with are expected to be associated with multiple users, but can also be beneficial when working with people-based CIDs. Receiving multiple RampIDs in these cases can help maximize reach and accuracy.
For CTV mapping files, this is because connected TVs are typically used by multiple users.
For CID mapping files, this is because these destinations develop their own definition of a person based on offline data that could differ from that of LiveRamp due to the type of data they source and their methodology for resolving identity.
Note
There is a many:many relationship between CTV IDs or CIDs and RampIDs: not only might a given CTV ID or CID have multiple RampIDs associated with it, but each RampID might have multiple CTV IDs or CIDs associated with it.
CTV Mapping File Showing Multiple RampIDs per Identifier
Note
If the RampID value returned for a particular row is "0", that represents a user that has opted out.
Contact your account team for more info on changing the default option if that makes the most sense for your specific use case.
File Naming
Your files will be named in the following format:
{Partner Name}_{Mapping Type}_Mapping_ID-{{ID}_{datetime}.txt.{backfill type}_part{part number}}
Example File Name: Acme_Cookie_ID-1234567_20181101T113041+0800_0.txt.full_part000
Partner Name: Your company name.
Mapping Type: The type of mapping in the file (cookie, IDFA, AAID, or CID).
ID: The mapping configuration ID.
Note
Provide the mapping configuration ID when contacting LiveRamp support about mapping file issues.
Datetime: The data and time in PST.
Backfill type: The type of backfill (incremental or full).
Part number: The part number of the file. If we've split your file into multiple parts, each part will have a distinct part number, starting with "part000" and with subsequent parts for "part001" and so on. If we haven't split your file into multiple parts, you will receive one file with "part000" in the file name.