Понимание модели доступа к Google Ads

Существует два типа аккаунтов Google Рекламы: управляющие аккаунты Google Рекламы и аккаунты рекламодателей Google Рекламы (также известные как клиентские аккаунты). Управляющие аккаунты могут управлять другими управляющими аккаунтами Google Рекламы или аккаунтами рекламодателей Google Рекламы. Вы можете связать аккаунт рекламодателя с управляющим аккаунтом и затем управлять им через управляющий аккаунт. Общая связанная структура представляет собой направленный ациклический граф с аккаунтами рекламодателей на уровне конечных элементов.

Вы можете предоставить отдельным пользователям или сервисным аккаунтам доступ к аккаунтам Google Рекламы. Существует два способа предоставить пользователям доступ к аккаунту рекламодателя:

• Предоставьте пользователю прямой доступ к аккаунту рекламодателя, пригласив его в этот аккаунт.
• Предоставьте пользователю косвенный доступ к аккаунту рекламодателя, пригласив его в аккаунт менеджера , связанный с этим аккаунтом. Пользователь получает доступ к аккаунту рекламодателя, поскольку аккаунт менеджера имеет доступ ко всем связанным с ним аккаунтам.

Вы также можете назначать роли пользователям , когда приглашаете пользователя управлять учетной записью.

Рассмотрим следующую иерархию учётных записей. Предположим, что все пользователи имеют стандартный доступ.

В следующей таблице представлена ​​краткая информация о структуре счета.

Пользователь	Имеет прямой доступ к	Имеет косвенный доступ к
У1, СА1	М1	М2, А1, А2, А3
U2	М2, М3	А1, А2, А3, А4
У3	А4

Идентификатор клиента для входа

Пользователь может иметь доступ к нескольким иерархиям учётных записей. В таких случаях при выполнении вызова API необходимо указать учётную запись root, которая будет использоваться для корректного определения уровней авторизации и доступа к учётной записи. Это достигается путём указания заголовка login-customer-id в составе запроса API.

В следующей таблице используется иерархия учетных записей из предыдущего примера , чтобы показать, какие идентификаторы клиентов для входа вы можете использовать, а также соответствующий список учетных записей, на которые вы можете совершать звонки.

Пользователь	Войдите в систему, чтобы использовать идентификатор клиента.	Учетные записи для выполнения вызовов API
У1, СА1	М1	М1, М2, А1, А2, А3
U2	М2	М2, А1, А2, А3
U2	М3	М3, А1, А4
У3	А4	А4

Вы можете не указывать заголовок login-customer-id если у пользователя есть прямой доступ к аккаунту Google Ads, к которому вы совершаете вызовы. Например, вам не нужно указывать заголовок login-customer-id при использовании учётных данных U3 для вызова A4 , поскольку серверы Google Ads могут правильно определить уровень доступа по идентификатору клиента ( A4 ).

Если вы используете одну из наших клиентских библиотек, то используйте следующие настройки для указания заголовка login-customer-id .

Ява

Добавьте следующий параметр в файл ads.properties .

api.googleads.loginCustomerId=INSERT_LOGIN_CUSTOMER_ID_HERE

С#

Добавьте следующий параметр при инициализации объекта GoogleAdsConfig и используйте его для создания объекта GoogleAdsClient .

GoogleAdsConfig config = new GoogleAdsConfig()
{
    ...
    LoginCustomerId = ******
};
GoogleAdsClient client = new GoogleAdsClient(config);

PHP

Добавьте следующий параметр в файл google_ads_php.ini .

[GOOGLE_ADS]
loginCustomerId = "INSERT_LOGIN_CUSTOMER_ID_HERE"

Питон

Добавьте следующий параметр в файл google-ads.yaml .

login_customer_id: INSERT_LOGIN_CUSTOMER_ID_HERE

Руби

Добавьте следующий параметр в файл google_ads_config.rb .

Google::Ads::GoogleAds::Config.new do |c|
  c.login_customer_id = 'INSERT_LOGIN_CUSTOMER_ID_HERE'
end

Создайте экземпляр GoogleAdsClient , указав путь к месту хранения этого файла.

client = Google::Ads::GoogleAds::GoogleAdsClient.new('path/to/google_ads_config.rb')

Перл

Добавьте следующий параметр в файл googleads.properties .

loginCustomerId=INSERT_LOGIN_CUSTOMER_ID_HERE

завиток

При запуске команды curl укажите следующий аргумент командной строки.

-H "login-customer-id: LOGIN_CUSTOMER_ID"

Роли пользователей

API Google Ads не имеет собственной отдельной модели доступа и не использует отдельные области действия OAuth 2.0 для ограничения функциональности. Например, API Google Ads использует одни и те же области действия для операций «только чтение» и «чтение-запись». Вместо этого API Google Ads использует те же роли пользователей , что и Google Ads. Когда роль пользователя назначается аккаунту на уровне менеджера, она наследуется аккаунтами в иерархии. Если у пользователя есть конфликтующие роли в данном аккаунте, правильный уровень определяется по login-customer-id указанному в запросе API.

В следующей таблице используется иерархия учетных записей из предыдущего примера и показан эффект предоставления пользователям различных ролей.

Пользователь	Роль пользователя предоставлена	логин-идентификатор-клиента	Эффективный уровень доступа
СА1	Стандартный доступ по счету М1	М1	Стандартный доступ на M1, M2, A1, A2, A3
U2	Стандартный доступ по М2 Доступ только для чтения на M3	М2	Стандартный доступ на M2, A1, A2, A3
U2	Стандартный доступ по М2 Доступ только для чтения на M3	М3	Доступ только для чтения к M3, A1, A4