আপনি যে পৃষ্ঠাটির জন্য অনুরোধ করেছেন সেটি বর্তমানে আপনার ভাষায় উপলভ্য নয়। আপনি পৃষ্ঠার নিচে অন্য কোনও ভাষা বেছে নিতে পারেন বা Google Chrome-এর বিল্ট-ইন অনুবাদ ফিচার ব্যবহার করে আপনার পছন্দের ভাষায় যেকোনও ওয়েবপৃষ্ঠা অবিলম্বে অনুবাদ করতে পারেন।

FAQs About the EU user consent policy for Customer Match upload partners

This article is for customers who use Customer Match partners to upload data for users in the European Economic Area (EEA).

As a part of Google’s ongoing commitment to a privacy-centric digital advertising ecosystem, we are strengthening the enforcement of our EU user consent policy (EU UCP).

If you are using a Customer Match partner to upload data for users in the EEA, you’ll need to work with your Customer Match partner to ensure you are passing the required consent signals to Google.

How it works

The Google Ads API v15 introduces the Consent object that specifies two distinct types of consent. In order to adhere to the EU user consent policy and continue using Customer Match for users in the EEA, Customer Match upload partners must integrate with the Google Ads API v15 and set the consent signals while uploading data for Customer Match.

If these consents are missing, then the consent value is determined as not consented. Data from unconsented EEA users will not be processed and cannot be used for ad personalization using Customer Match.

Starting in March 2024, for Customer Match lists to be used in EEA, both consent fields of ConsentStatus type must be set to “GRANTED” to indicate that you have received the required user consent. These consent fields are:

Name Type Description
ad_user_data ConsentStatus Sets consent for sending user data to Google for advertising purposes.
ad_personalization ConsentStatus Sets consent for ad personalization.

FAQs

1. How should the consent fields be interpreted? Do they apply to all user records in a job, or to only the ones in the EEA?

The consent setting applies to all users uploaded in a job and advertisers should use separate jobs to upload users with different consent signals.

This means if there are non-EEA and EEA user records in 1 job, and the consent status is sent as GRANTED, this GRANTED consent status is used for all records in that job.

2. Can a user list have members with different levels of consent? For example we have two jobs that update a single audience, the first sends identifiers with UNSPECIFIED consent, and the second sends identifiers with GRANTED consent.

The consent setting applies to all users uploaded in a job and advertisers should use separate jobs to upload users with different consent statuses. In the example provided you would use two jobs - one for uploading users with UNSPECIFIED consent status for the ad_user_data and ad_personalization parameters and another job for users that have GRANTED consent status for the two consent parameters.

3. If a user identifier is sent in two jobs, one with consent GRANTED (for ad_user_data and ad_personalization) and one with consent set to DENIED (ad_user_data and ad_personalization), how is this resolved? Is it based on the order jobs are started or is it based on the order it’s processed?

If you set the consent status as DENIED, you will get an error. Learn more about the behavior when setting denied in the Google Ads API. If the same user record is sent in 1 job with consent status GRANTED and in another job with the consent status DENIED, you will receive an error message for the second job that has the consent status of DENIED. The consent status is resolved in the order the job is processed.

4. How should the DENIED consent value be used by partners? How does this differ from removing members from an audience?

If you set the consent status as DENIED, you will get an error. Learn more about the behavior when setting denied in the Google Ads API. Sending DENIED consent for either of the ad_user_data or ad_personalization consent parameters means Customer Match will return an error message, and the data in the job cannot be used for ad personalization.

If the EEA user’s data was previously consented or existed prior to March 2024 then Customer Match will continue to use that data.

Removing the user record from the audience list means Customer Match cannot use that EEA user’s data that was previously consented or existed prior to March 2024.

5. How should Customer Match partners manage changes in consent? Should the user data be removed from an audience or can the Customer Match partner change the consent flag for individual users?

After an end user has been added to the audience list, if any of the two consents (ad_user_data or ad_personalization) are later retracted by the end user, the partners have an option to use the Customer Match APIs to remove the user from the existing audience lists OR replace the audience list without the unconsented user.

Note: If an EEA user previously provided consent for both ad_user_data and ad_personalization, that data will continue to be used for Customer Match until that list expires and/ or that data is explicitly removed by the advertiser/ partner.

6. What will happen to Audiences that are updated regularly by Customer Match partners, but that were created prior to March 2024? Will only new records added to those refreshed audiences need to upload consent?

The consent fields are required to be both set to GRANTED for any newly uploaded/updated EEA user’ data for Customer Match to continue to work for EEA users after March 2024.

Customer Match will continue to use the user-lists that were uploaded prior to March 2024 until they expire and/ or are explicitly removed by the advertiser/ partner. Such user-lists will continue to be used only with those Google services that were used prior to March 2024.

7. What happens if a partner sends "UNSPECIFIED" through as a default value for advertisers who don't provide consent info?

If the consent status is set to “UNSPECIFIED” it will be treated as missing consent, which means that the EEA user’s data cannot be used for ad personalization.

8. Do advertisers need to submit separate uploads jobs / files for different consent labels to use store sales data with Customer Match?

No, advertisers do not need to submit multiple upload files or jobs for different consent labels (applicable to both API and manual uploads) when uploading store sales data for EEA users. To ensure compliance with consent labels, we process store sales data and associated consent values at the individual row level within each uploaded file. This approach ensures that all consent labels are honored and that personal data is not processed for rows where consent is denied. Both Customer Match and store sales honor consent labels passed to Google.

9. Which consent parameters are required for using Customer Match with store sales data?

Advertisers must pass store sales data with consent values for both ad user data and ad personalization for EEA users to maintain access to customer match functionalities. Only data with granted values will be usable for customer match with store sales. See more on consent updates in the EEA here.

Was this helpful?

How can we improve it?
Search
Clear search
Close search
Main menu
3892881717575789047
true
Search Help Center
true
true
true
true
true
73067
false
false
false