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 an IdentityLink (IDL), our anonymous, universal identifier. These files are delivered to you on a regular basis. 

See the “Setting 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 IDLs

  • IDFA file: A file that maps IDFAs (Identifier for Advertising, the mobile device ID for Apple/iOS devices) to IDLs

  • AAID file: A file that maps AAIDs (Android Advertising ID, the mobile device ID for Android devices) to IDLs

  • CID file: A file that maps your custom identifiers (CIDs) to IDLs

  • CTV file: A file that maps your connected TV IDs (CTV IDs) to IDLs

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. 

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 utilized 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

LiveRamp needs the following information to set up your mapping files:

  • The types of IdentityLinks (IDLs) you want to receive. 
  • Whether you want to include a “Last seen at” timestamp column.
  • The delivery frequency you want your mapping deliveries set at.
  • 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.

Can these be changed later? These configurations can be adjusted at any time.

The Types of IdentityLinks You Can Receive

You can choose to receive just maintained IDLs or you can choose to receive additional individual IDL types if a maintained IDL is not available. Feel free to select multiple or all options.

Most companies choose to receive maintained and derived IDLs, but consult with your LiveRamp rep to determine what makes the most sense for your use case.
  • Maintained IDLs: LiveRamp has a full understanding of this cookie or mobile device ID as an individual tied to multiple PII touchpoints. Maintained IDLs start with the prefix “XY” and are 49 characters long.

  • Derived IDLs: Derived IDLs are returned when a maintained IDL 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 IDL may become a maintained IDL when we build a more complete picture of the associated devices. Derived IDLs are start with the prefix “Xi” and are 70 characters long.

  • Placeholder IDLs: Placeholder IDLs can be returned when no maintained or derived IDL exists for the given device. LiveRamp has no PII associated with this device, but does have a LiveRamp cookie associated with your cookie. Placeholder IDLs allow you to track online events even when the cookie or mobile device ID is not associated with PII. Placeholder IDLs for cookies start with the prefix “Xc”. Placeholder IDLs for mobile devices start with “Xm”. Both types of Placeholder IDLs are 49 characters long.

Household IDLs

In addition to an individual IDL, you can choose to also receive a household IDL (if one is available) for any records with maintained individual IDLs.  Every maintained IDL in the graph 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 IDLs would be returned in a third column in the mapping file. Household IDLs start with the prefix “hY” and are 49 characters long.

Cookie Mapping File Example

Receiving Household IDLs will require an additional cost, unless it is already in your contract.

See our IdentityLink glossary definition 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.

Timestamps will be in Unix Epoch format. 

Cookie Mapping File Example

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 <> IDL 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. 

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 IdentityLinks.

  • Full refresh: Receive a full IdentityLink mapping file (daily, weekly, or monthly)

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.

When receiving incremental updates for Mapping Files that include “Last seen at” timestamps: Note that incremental deliveries only include net new cookie<>IDL and mobile device ID <>IDL 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 IdentityLinks You Can Receive

There are two options for the number of IdentityLinks (IDLs) you receive in your mapping files:

  • One IDL per identifier
  • Multiple IDLs per identifier

For cookie mapping files and mobile device ID mapping files, the default is to receive one IDL per cookie or mobile device ID. This is because cookies and mobile devices typically have one user, so receiving multiple IDLs does not usually provide much additional reach. In addition, receiving multiple IDLs for an online identifier might require complex decision making around assignments (such as how to “break the tie” between multiple IDLs).

For CTV (connected TV) mapping files and CID (Custom ID) mapping files, you can elect to receive all associated IDLs 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 IDLs 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.

CTV Mapping File Showing Multiple IDLs per Identifier

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.

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.

Your feedback is vital to improve our help content.

Updated 6/15/20.