Strategies for Customer Match List Replacement

[Sundaralingam Kethiri]

Hi,

I'm looking for guidance on robustly managing large Customer Match lists (millions of users) with daily updates, specifically concerning full list replacements and resilience.

We are considering two main approaches, and have questions about the risks involved:

Scenario 1: Full Replacement using remove_all then create operations

Our intended process is to:

1. Submit an OfflineUserDataJob that includes an OfflineUserDataJobOperation with remove_all: true.
2. Immediately after, include a batch of create operations for all the new users that should be on the list.

My primary concern here is:

• If the create operations fail (either partially or entirely) after the remove_all operation has successfully processed, will the entire transaction be rolled back? Or will we end up with an empty (or partially empty) Customer Match list? We want to understand the risk of inadvertently having an empty list.

Scenario 2: Using a shorter membership_life_span with daily "create" operations to avoid an empty list risk

As an alternative, if the remove_all approach carries too much risk of an empty list, we're considering this:

• Maintain one single UserList with its membership_life_span set to a very short duration (e.g., 3 days). We can accept eventual consistency.
• Daily, we would upload our entire, user list using OfflineUserDataJobService with only create operations (no remove_all).
• The goal here is that if our daily upload process fails for a few days, the 3-day membership_life_span would provide a buffer, preventing the list from becoming completely empty immediately. Users would remain active for up to 3 days from their last successful upload.

My questions for the group regarding Scenario 2 are:

• Is setting a short membership_life_span (e.g., 3 days) a good and recommended strategy to mitigate the risk of an empty list during consecutive upload failures for a continually updated audience?
• Are there any unforeseen negative consequences, performance issues, or significant trade-offs (beyond the conceptual mismatch of the list's definition) when relying on a short membership_life_span for this type of operational resilience?
  
• What will happen to the running campaigns during the ongoing replace operation?

Any insights into the atomicity of these operations, the effective use of membership_life_span for resilience, and best production-grade practices would be greatly appreciated.

Thanks in advance for your help!

Best regards,
S.Kethiri

[Google Ads API and AdWords API Forum]

Hi Kethiri,

Thank you for reaching out to the Google Ads API support team.

Note that when a remove_all operation is included, it must be the first operation in a job. If not, then running the job returns an INVALID_OPERATION_ORDER error. So, it is processed first and independently. The remove_all operation, when included in an OfflineUserDataJob, is designed to clear the entire customer list. If successful, it will effectively empty the list. If remove_all succeeds and create operations fail entirely or partially, You will indeed end up with an empty Customer Match list or partially empty Customer Match list. 

Please find the answers to your questions below:

> Is setting a short membership_life_span (e.g., 3 days) a good and recommended strategy to mitigate the risk of an empty list during consecutive upload failures for a continually updated audience?

• Yes, it is generally more efficient to manage membership expirations by setting membership_life_span rather than by using the OfflineUserDataJobOperation.remove_all field. Also, to update your lists with the latest data, it is generally more efficient to append or remove individual users, rather than removing all users from the list and uploading them from scratch.

> Are there any unforeseen negative consequences, performance issues, or significant trade-offs (beyond the conceptual mismatch of the list's definition) when relying on a short membership_life_span for this type of operational resilience?

• Since it can take up to 24 hours for a list to be populated with members, you might see an In Progress status in the Google Ads UI if you upload to an audience list more frequently than once every 12 hours. So, there will be a processing lag between when you submit the job and when the list is fully updated. Also, the list size might naturally fluctuate a bit more as memberships expire and new ones are added daily. However, with consistent daily uploads of your entire current list, the fluctuation should be minimal once the system stabilizes.

> What will happen to the running campaigns during the ongoing replace operation?

• There will be no interruption to campaign serving. Campaigns targeting the list will continue to serve ads. Google Ads audience matching happens asynchronously in the background. 

For more information, I recommend you refer to these guides on 'Get started with customer match' and 'Manage customer lists'.

Thanks,

Google Ads API Team