Google Ads-Zugriffsmodell

Es gibt zwei Arten von Google Ads-Konten: Google Ads-Verwaltungskonten und Google Ads-Werbetreibendenkonten (auch als Kundenkonten bezeichnet). Mit Verwaltungskonten lassen sich andere Google Ads-Verwaltungskonten oder Google Ads-Werbekonten verwalten. Sie können ein Werbetreibendenkonto mit einem Verwaltungskonto verknüpfen und es dann über das Verwaltungskonto verwalten. Die gesamte verknüpfte Struktur ist ein gerichteter azyklischer Graph mit Werbetreibendenkonten auf Blattebene.

Sie können einzelnen Nutzern oder Dienstkonten Zugriff auf Google Ads-Konten gewähren. Es gibt zwei Möglichkeiten, Nutzern Zugriff auf ein Werbetreibendenkonto zu gewähren:

• Gewähren Sie dem Nutzer direkten Zugriff auf das Werbekonto, indem Sie ihn dazu einladen.
• Gewähren Sie dem Nutzer indirekten Zugriff auf das Werbekonto, indem Sie ihn in ein Verwaltungskonto einladen, das mit diesem Konto verknüpft ist. Der Nutzer erhält Zugriff auf das Werbetreibendenkonto, da das Verwaltungskonto Zugriff auf alle damit verknüpften Konten hat.

Sie können auch Nutzerrollen zuweisen, wenn Sie einen Nutzer einladen, ein Konto zu verwalten.

Sehen Sie sich die folgende Kontohierarchie an. Angenommen, alle Nutzer haben Standardzugriff.

In der folgenden Tabelle ist diese Kontostruktur zusammengefasst.

Nutzer	Hat direkten Zugriff auf	Hat indirekten Zugriff auf
U1, SA1	M1	M2, A1, A2, A3
U2	M2, M3	A1, A2, A3, A4
U3	A4

Kundennummer für die Anmeldung

Ein Nutzer kann Zugriff auf mehrere Kontohierarchien haben. Wenn Sie in solchen Fällen einen API-Aufruf durchführen, müssen Sie das zu verwendende Stammkonto angeben, um die Autorisierungs- und Konto-Zugriffsebenen richtig zu bestimmen. Dazu geben Sie in der API-Anfrage einen login-customer-id-Header an.

In der folgenden Tabelle wird die Kontohierarchie aus dem vorherigen Beispiel verwendet, um zu zeigen, welche Kunden-IDs für die Anmeldung Sie verwenden können und auf welche Konten Sie jeweils API-Aufrufe ausführen können.

Nutzer	Zu verwendende Kundennummer für die Anmeldung	Konten für API-Aufrufe
U1, SA1	M1	M1, M2, A1, A2, A3
U2	M2	M2, A1, A2, A3
U2	M3	M3, A1, A4
U3	A4	A4

Sie können den login-customer-id-Header weglassen, wenn der Nutzer direkten Zugriff auf das Google Ads-Konto hat, für das Sie Aufrufe ausführen. Wenn Sie beispielsweise U3-Anmeldedaten verwenden, um einen Aufruf an A4 zu senden, müssen Sie den login-customer-id-Header nicht angeben, da die Google Ads-Server die Zugriffsebene anhand der Kunden-ID (A4) korrekt ermitteln können.

Wenn Sie eine unserer Clientbibliotheken verwenden, geben Sie den login-customer-id-Header mit den folgenden Einstellungen an.

Java

Fügen Sie Ihrer ads.properties-Datei die folgende Einstellung hinzu.

api.googleads.loginCustomerId=INSERT_LOGIN_CUSTOMER_ID_HERE

C#

Fügen Sie die folgende Einstellung hinzu, wenn Sie das GoogleAdsConfig-Objekt initialisieren und damit ein GoogleAdsClient-Objekt erstellen.

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

PHP

Fügen Sie Ihrer google_ads_php.ini-Datei die folgende Einstellung hinzu.

[GOOGLE_ADS]
loginCustomerId = "INSERT_LOGIN_CUSTOMER_ID_HERE"

Python

Fügen Sie Ihrer google-ads.yaml-Datei die folgende Einstellung hinzu.

login_customer_id: INSERT_LOGIN_CUSTOMER_ID_HERE

Ruby

Fügen Sie Ihrer google_ads_config.rb-Datei die folgende Einstellung hinzu.

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

Erstellen Sie eine GoogleAdsClient-Instanz, indem Sie den Pfad zu dem Speicherort dieser Datei übergeben.

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

Perl

Fügen Sie Ihrer googleads.properties-Datei die folgende Einstellung hinzu.

loginCustomerId=INSERT_LOGIN_CUSTOMER_ID_HERE

curl

Geben Sie das folgende Befehlszeilenargument an, wenn Sie den Befehl curl ausführen.

-H "login-customer-id: LOGIN_CUSTOMER_ID"

Nutzerrollen

Für die Google Ads API gibt es kein eigenes Zugriffsmodell und es werden auch keine separaten OAuth 2.0-Bereiche verwendet, um die Funktionalität einzuschränken. In der Google Ads API werden beispielsweise dieselben Bereiche für Lese- und Lese-/Schreibvorgänge verwendet. Stattdessen werden in der Google Ads API dieselben Nutzerrollen verwendet, die in Google Ads unterstützt werden. Wenn einem Konto auf Verwaltungskontoebene eine Nutzerrolle zugewiesen wird, wird die Rolle von den Konten in der Hierarchie übernommen. Wenn ein Nutzer widersprüchliche Rollen für ein bestimmtes Konto hat, wird die richtige Ebene durch das in der API-Anfrage angegebene login-customer-id-Konto bestimmt.

In der folgenden Tabelle wird die Kontohierarchie aus dem vorherigen Beispiel verwendet, um die Auswirkungen der Zuweisung verschiedener Nutzerrollen zu veranschaulichen.

Nutzer	Nutzerrolle gewährt	login-customer-id	Effektive Zugriffsebene
SA1	Standardzugriff auf Konto M1	M1	Standardzugriff auf M1, M2, A1, A2, A3
U2	Standardzugriff auf M2 Lesezugriff auf M3	M2	Standardzugriff auf M2, A1, A2, A3
U2	Standardzugriff auf M2 Lesezugriff auf M3	M3	Schreibgeschützter Zugriff auf M3, A1, A4