Troubleshooting Common Issues
For help with troubleshooting common issues with file ingestion, data management, and segment distribution, see the information below. If that information does not solve your problem, create a support case.
Note
For answers to other common questions, see "FAQs".
Files Stuck in Ingestion Processing
The cause of file ingestion failure or delay is often because the file does not have the same file formatting as the original seed file that was used to set up that audience.
To avoid ingestion issues, be sure to always keep the same file formatting as the original seed file that was set up so that your files could ingest automatically. For more information on the automation configuration process, see "The Ingestion Automation Process for File Uploads".
Note
If you’re unsure what formatting the audience has been set up for, create a support case and we can send you an example template.
This could be because of one or more of the following issues:
The headers for the fields (columns in a column-based file) are different fom the original file (headers must match exactly and are case sensitive).
An identifier field that’s being used as the audience key for deduplication in that audience has not been included (for example, if the audience has been set up to use email address as the audience key and you upload a file that does not contain that same email address field, the file will not ingest).
The identifier field that’s being used as the audience key has a low fill rate (such as 75% or lower).
Note
For other common reasons why a file might get stuck in ingestion processing, see “Avoiding File Ingestion Failure”.
If file ingestion shows as being paused or failed when you check the ingestion status, check the pause reason or given on the Files page, correct the file, and upload it again. For more information, see "Troubleshoot File Ingestion Issues".
Distributions to Facebook Getting Stuck
Distributions of first-party segments to Facebook through the Direct Integration often get stuck because LiveRamp has not been added as a partner in Facebook for that Facebook Ad Account before the segments were distributed. These segments will remain in a “Queued” status in the Delivery Job Status UI.
For segments to deliver successfully to Facebook through the Direct Integration, you must perform the following actions before distributing segments:
Follow these instructions to add LiveRamp as a partner with the ability to manage campaigns within your Facebook Ad Accounts.
Create a support case to have LiveRamp complete the configuration.
For more information, see “Distribute First-Party Data to Facebook” and "View Delivery Status".
Distributions to Google Customer Match Getting Stuck
Distributions of first-party segments to Google Customer Match (GCM) often get stuck in the "queued" status because you have attempted to distribute segments that are not based on PII. Because GCM is a Passthrough Activation destination (where LiveRamp passes through hashed PII without performing matching (or any leveraging of our Identity Graph), all data being distributed to GCM must be based on PII. For GCM, this could either be plaintext PII or RampIDs that have been generated from PII (not generated from online identifiers).
For example, if you send cookie-based segments or RampID-based segments where the RampIDs have been generated from online identifiers, the distribution will get stuck in the "queued" status. For more information, see "Distribute Data to Google Customer Match".
Distributions to Google Failing
Distributions of first-party segments to Google often fail because LiveRamp has not been granted access to deliver data to the appropriate Google account before the destination account was activated in Connect. These segments will remain in a “Failed” status in the Delivery Job Status UI.
This access is provided differently, depending on which type of destination account integration you’re going to activate:
For a Google Customer Match destination account: Before activating a Google Customer Match destination account (either a Google Customer Match or a Google Customer Match - DV360 destination account), you must complete the self-service LiveRamp account linking process for Customer Match within the Google Ads UI to map the LiveRamp CMU account 637-789-1275 to your Google Ads advertiser account. Follow these instructions to provide access via Google’s UI.
For a Google Display & Video 360 (DV360) destination account: Contact your Google account representative and have them map the LiveRamp DMP account 750-013-0530 to your Google DV360 account. For complete instructions, see "Providing Access to LiveRamp".
For a Google Display & Video 360 (DV360) destination account: Contact your Google account representative and have them map the LiveRamp DMP account 750-013-0530 to your Google DV360 account. For complete instructions, see "Providing Access to LiveRamp".
For more information, see “Distribute Data to Google” and "View Delivery Status".
Note
Before creating a support ticket, confirm that you’ve granted LiveRamp access and that your Google account ID listed in the destination account is correct. Once those have been connected, you can resend the active segments or wait until the next delivery.
Data Marketplace Distributions to The Trade Desk Getting Stuck
Often Data Marketplace distributions to The Trade Desk (TTD) get stuck because TTD’s required pricing information was not been included. These segments will remain in a “Queued” status in the Delivery Job Status UI.
For Data Marketplace segments with a programmatic standard CPM of less than $5, TTD uses a “programmatic hybrid” pricing model that consists of a percentage of media (PoM) rate ("programmatic percentage of media") and a CPM cap. If this pricing information is not included, segment distribution will get stuck in “Queued”.
If a delivery job is in the "Queued" status for more than 24 hours, check the pricing fields to see if the segment has a Programmatic PoM and CPM cap. If it does not, create a support case following these instructions to have the pricing fields corrected.
For more information, see “Distribute Data Marketplace Data to The Trade Desk” and "View Delivery Status".
Seeing Two Fields with the Same Name in Connect
If you’re seeing two separate fields with the same name in Connect, this is likely because the number of distinct values for the original enumerated field has accumulated over time and turned that field into a raw field in an audience where you’re using the “incremental” update option (enumerated fields become raw fields when the number of distinct values for the field is more than 250).
Note
This issue is only possible if the audience is using the "incremental" update option, where data from subsequent files is used to add to any previously-onboarded fields contained in the file. This issue cannot occur if the audience uses either the "segment refresh" or "full refresh" update option. For more information on audience update methods, see "Ways to Update an Existing Audience".
You might also notice this issue if you’ve attempted to distribute the raw field and the distribution has failed.
For example, if the first imported file for a given field has 175 distinct values, we will enumerate those values. But then if a second imported file has that same field with 85 new distinct values (now a total of 260 distinct values), that field will be passed as raw in the second import rather than enumerated. This would then cause there to be two fields with the same name in Connect.
When you look at these two fields in Connect, it’s likely that only one will show the field values (the enumerated field from the first import) and the duplicate field will not show any enumerated values to activate on because it’s the newer raw field created from subsequent file imports.
Note
The duplicate raw field will display the message "This field has no configured values to display.".
If the original enumerated field is being distributed, that field will not get refreshed with the new data. If this occurs, you can create a support case to try to remove any unused values or have LiveRamp perform a segment refresh to change the overall number of distinct values.
Seeing Higher or Lower Match Rates Than Expected
The way LiveRamp calculates matched reach stats and identifiers delivered stats might differ from how your destination platform calculates the same stats, and Connect might show higher or lower device counts for a given segment.
Here are a general few reasons why matched reach counts might differ between Connect and some platforms:
Time window differences: Different platforms use different time windows to report the number of devices they see on their network. Some only count the number of devices they've seen in the past 30 days; others use a longer range.
Filtering mechanisms: Some platforms filter out any browsers that refuse third-party cookies from their counts. Another common filter is for a platform not to count devices they've only seen once on their network. These sorts of filtering mechanisms can affect reach statistics.
Unit of measurement: We report devices synced to your destination via the Connect dashboard, but not all platforms use this metric.
If you’re seeing higher match rates than expected at the destination platform, it might also be due to one or more of the following reasons:
Our graph is constantly being updated and refreshed with new connections, so the number of devices associated with a given record might increase.
Because of the quality of our integrations with our partners, we often are able to match more than one downstream identifier at the platform to an input row. This results in an expansion in the number of identifiers when comparing input records to downstream platform volume, especially if the input record is an offline identifier and the downstream platform identifier pool consists of cookies AND mobile IDs, for example.
Since we are continually sending net new connections and data downstream, and since each platform has different policies for when they expire older data, there might be some outdated data in the segment.
If the distribution is made at the household precision level, this will expand the number of consumers in the segment well beyond the number of individuals that was onboarded to all the individuals in those households.
For more information on why match rates might vary, see “Why LiveRamp's Stats Might Differ From Your Destination's Stats” and “Why Match Rates Vary”.
If you still have questions about a match rate that seems unexpectedly low or high at the destination platform, first check with the platform to see if it's an issue on their end. If nothing is found, or if the issue is solely with stats within Connect, use either the High/Low Match Rate Investigation (Activation) quick case or the High/Low Match Rate Investigation (Measurement Enablement) quick case to create a support case to investigate the issue.