Freigeben über

Kontohierarchie und Benutzerberechtigungen

  • Artikel

Microsoft Advertising-Benutzer können dieselben Anmeldeinformationen verwenden, um auf mehrere Konten zuzugreifen, möglicherweise mit unterschiedlichen Berechtigungen für jedes Konto. Eine Agentur kann eine Hierarchie von Konten einrichten, um alle Benutzer und Konten von einem übergeordneten Konto aus zu verwalten, eine zentrale Brieftasche für alles zu verwenden und Kampagnenressourcen wie UET-Tags ( Universal Event Tracking ) und Remarketing-Listen kundenübergreifend zu teilen.

Hinweis

Im Kontext von Hierarchien wird ein Kunde auch als "Manager-Konto" bezeichnet. Ein AdvertiserAccount wird als "Konto" oder "Inserentenkonto" bezeichnet.

Weitere Informationen zur Kampagnenhierarchie innerhalb eines Kontos finden Sie unter Entitätsgrenzwerte .

Benutzerrollen und -berechtigungen

Ihre Anwendung muss möglicherweise nur einen Super admin-Benutzer in einem bekannten Konto unterstützen. Selbst bei einer solchen relativ einfachen Berechtigungsstruktur sollten Sie verstehen, welche Aktionen für jede Benutzerrolle verfügbar sind, wie Benutzer in einem Konto bereitgestellt werden , wie Sie ihre aktuellen Zugriffsrechte ermitteln und wie Sie mit der Bing Ads-API im Namen eines authentifizierten Microsoft Advertising-Benutzers handeln können.

Benutzerrollen

Die Benutzerrolle, die vom Superadministrator eines Kunden oder vom Microsoft Advertising-Systemadministrator gewährt wird, bestimmt die Dienstverfügbarkeit. Beispielsweise kann ein Benutzer mit der Rolle "Kampagnen-Manager für Inserenten" Kampagnen hinzufügen und aktualisieren, aber keine Benutzer erstellen oder aktualisieren. Sofern im Verweisinhalt pro Dienstvorgang nicht anders angegeben, werden in der folgenden Tabelle die Diensteinschränkungen pro Benutzerrolle auf hoher Ebene beschrieben.

Hinweis

Nur SuperAdministrator- und Standardbenutzer können als primärer Kontakt für ein Konto festgelegt werden. Weitere Informationen zu Benutzerrollen finden Sie im Hilfethema Wie gebe ich jemandem Zugriff auf mein Microsoft Advertising-Konto? .

Benutzerrolle Verfügbare Dienste
Advertiser Campaign Manager Diese Rolle verfügt über Berechtigungen zum Anzeigen ausgewählter Konten und zum Hinzufügen, Bearbeiten oder Löschen von Kampagnen innerhalb der ausgewählten Konten. Der Kampagnenmanager des Inserenten kann Zahlungsmethoden anzeigen, aber keine Abrechnungs- und Zahlungsaufgaben verwalten.

Lesevorgänge für alle Dienste sind verfügbar.

Schreibvorgänge mit dem Kundenverwaltungsdienst sind im Allgemeinen nicht verfügbar. Eine Ausnahme besteht darin, dass der Kampagnen-Manager für Werbetreibende das AutoTagType-Element eines AdvertiserAccount mithilfe des Vorgangs UpdateAccount aktualisieren kann.
Aggregator Lese- und Schreibvorgänge sind für alle Dienste mit Ausnahme von DeleteCustomer verfügbar.
Standardbenutzer Diese Rolle verfügt über Berechtigungen zum Verwalten von Kampagnen und zum Ausführen einiger Abrechnungsaktivitäten für ausgewählte Konten. Diese Rolle kann keine Zahlungsmethoden hinzufügen, bearbeiten oder löschen. Konten hinzufügen oder löschen. Standardbenutzer können Inserentenkonten verknüpfen und die Verknüpfung aufheben, aber keine Clientlinks auf Kundenebene verwalten.

Standardbenutzer können einige Benutzer in den Konten verwalten, auf die sie Zugriff haben. Ein Standardbenutzer kann andere Standardbenutzer, Werbetreibende Kampagnenmanager und Viewer einladen oder löschen und Informationen zu allen Benutzern im Kontext des aktuellen Kunden anzeigen. Standardbenutzer können jedoch weder einen Superadministrator einladen oder löschen noch die Rolle eines Superadministrators bearbeiten.

Standardbenutzer im Kunden, der eine nicht freigegebene Zielgruppe oder ein UET-Tag besitzt, können ihre Eigenschaften (außer Bereich) wie Beschreibung und Name aktualisieren. Während die Benutzergruppe oder das UET-Tag freigegeben ist, kann ein Standardbenutzer diese Eigenschaften nicht aktualisieren. Weitere Informationen finden Sie im technischen Leitfaden Freigeben von Zielgruppen und UET-Tags .

Lesevorgänge für alle Dienste sind verfügbar.

Schreibvorgänge mit dem Kundenabrechnungsdienst und dem Kundendienst sind im Allgemeinen nicht verfügbar. Ausnahmen von Vorgängen, die einem Standardbenutzer zur Verfügung stehen, sind AddInsertionOrder, UpdateInsertionOrder und UpdateAccount.
Superadministrator Diese Rolle verfügt über vollständige Berechtigungen für alle Konten. Ein Superadministrator kann alles im Zusammenhang mit Abrechnung und Zahlungen, Kontodetails und anderen Benutzern (einschließlich anderer Superadministratoren) verwalten. Der Superadministrator kann angeben, auf welche Konten andere Benutzer Zugriff haben. Wenn Sie sich als neuer Kunde registrieren, ist der erste Benutzer der Superadministrator.

Ein Superadministratorbenutzer im Kunden, der die Zielgruppe oder das UET-Tag besitzt, kann den Freigabebereich eines Kundenkontos einer Zielgruppe oder eines UET-Tags aktualisieren. Superadministratorbenutzer in übergeordneten Kunden der Hierarchie können den Bereich ebenfalls aktualisieren. Andere Zielgruppen- oder UET-Tageigenschaften (außer Bereich) wie Beschreibung und Name können nur von einem Superadministratorbenutzer im Kunden aktualisiert werden, dem die Zielgruppe oder das UET-Tag gehört. Superadministratorbenutzer in übergeordneten Kunden der Hierarchie können diese Details nicht aktualisieren. Weitere Informationen finden Sie im technischen Leitfaden Freigeben von Zielgruppen und UET-Tags .

Lese- und Schreibvorgänge für alle Dienste mit Ausnahme von DeleteCustomer
Viewer Diese Rolle verfügt über schreibgeschützte Berechtigungen.

Lesevorgänge für alle Dienste sind verfügbar.

Superadministratorberechtigungen für verknüpfte Kunden sind eingeschränkt, wenn die Linkberechtigung (CustomerLinkPermission) "Standard" lautet. Ihre Berechtigungen sind nicht eingeschränkt, wenn die Linkberechtigung "Administrator" lautet. Sie behalten auch vollständige Superadministratorberechtigungen für Kunden, auf die sie direkt zugreifen können, z. B. dort, wo sie sich registriert haben.

Customer Link Permission)

Beachten Sie auch, dass ein Benutzer einzeln die gleiche Rolle für die CustomerId, AccountIds und LinkedAccountIds für einen bestimmten CustomerRole hat. Wenn ein Benutzer jedoch über mehrere Kundenrollen verfügt, hängen die effektiven Berechtigungen von dem vollständigen Satz von CustomerRole-Objekten ab, die von GetUser zurückgegeben werden. Unter Abrufen von Benutzerrollen finden Sie mehrere Beispiele.

Zuweisen von Benutzerrollen

Wenn Sie sich für ein neues Konto in der Microsoft Advertising-Webanwendung registrieren, wird Ihnen die Benutzerrolle "Superadministrator" zugewiesen. Ein Superadministrator kann neue Benutzer mit der Rolle "Kampagnen-Manager", "Superadministrator", "Standard" oder "Anzeigender Benutzer" erstellen. Die Aggregatorrolle wird durch eine spezielle Anforderung über den Systemadministrator bereitgestellt. Weitere Informationen finden Sie unter Aggregatorhierarchie , und wenden Sie sich an Ihren Konto-Manager.

Technisch gesehen können keine neuen Nutzer programmgesteuert erstellt werden; Sie können jedoch den SendUserInvitation-Vorgang verwenden, um Personen zur Registrierung unter einem vorhandenen Microsoft Advertising-Konto einzuladen. Wenn Sie jemanden zu einem Konto oder einer Gruppe von Konten einladen, legen Sie auch die Benutzerrolle fest. Microsoft Advertising generiert eine E-Mail-Einladung, die an den eingeladenen Benutzer gesendet wird. Wenn Sie auf den Per E-Mail gesendeten Link klicken und den Microsoft Advertising-Registrierungsworkflow abschließen, akzeptieren sie die Einladung zum Verwalten von Konten mit der Benutzerrolle, die Sie in der SendUserInvitation-Anforderung bereitgestellt haben.

Hinweis

Eine Person kann die gleichen Anmeldeinformationen verwenden, wenn sie sich für neue Konten anmeldet und Einladungen zu vorhandenen Konten akzeptiert. In beiden Fällen, wenn die gleichen Anmeldeinformationen zum Abschließen des Registrierungsworkflows verwendet werden, wird davon ausgegangen, dass die Person über Mehrbenutzeranmeldeinformationen verfügt. Aus sicht jedes Superadministrators, der Benutzer in seinem Kundenbereich verwaltet, sind die Rolle, der Kontozugriff und die Kontaktinformationen des Benutzers eindeutig. Alle Berechtigungen, die der Benutzer im Kontext eines anderen Kunden hat, werden beim Handeln im Rahmen des aktuellen Kunden nicht berücksichtigt.

Ein Superadministrator hat die Möglichkeit, den Zugriff seiner Benutzer auf verschiedene Konten zu ändern und möglicherweise die Benutzerrolle zu ändern, z. B. von Viewer in Standard-Benutzer. Um die Rolle eines Benutzers zu aktualisieren, rufen Sie den Vorgang UpdateUserRoles auf .

Abrufen von Benutzerrollen

Um eine Liste der Benutzer abzurufen, die auf ein oder mehrere Konten eines Kunden zugreifen können, rufen Sie den Vorgang GetUsersInfo auf. Der Vorgang gibt ein Array von -Objekten zurück, das die E-Mail-Adresse und den Bezeichner der einzelnen Benutzer enthält. Anschließend können Sie die Details der einzelnen Benutzer in der Liste abrufen, z. B. die Rollen- und Kontoberechtigungen in Microsoft Advertising, und den GetUser-Vorgang aufrufen. Wenn Sie getUser aufrufen, wenn Sie das UserId-Element null belassen, enthält die Antwort Details für den aktuellen authentifizierten Benutzer, wie in den Anmeldeinformationen des Anforderungsheaders angegeben.

Hier sehen Sie ein Beispiel für ein CustomerRoles-Element , das vom GetUser-Vorgang zurückgegeben wird.

<CustomerRoles xmlns:e1335="https://bingads.microsoft.com/Customer/v13/Entities" d4p1:nil="false" xmlns:d4p1="http://www.w3.org/2001/XMLSchema-instance">
  <e1335:CustomerRole>
    <e1335:RoleId>ValueHere</e1335:RoleId>
    <e1335:CustomerId>ValueHere</e1335:CustomerId>
    <e1335:AccountIds d4p1:nil="false" xmlns:a1="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
      <a1:long>ValueHere</a1:long>
    </e1335:AccountIds>
    <e1335:LinkedAccountIds d4p1:nil="false" xmlns:a1="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
      <a1:long>ValueHere</a1:long>
    </e1335:LinkedAccountIds>
    <e1335:CustomerLinkPermission d4p1:nil="false">ValueHere</e1335:CustomerLinkPermission>
  </e1335:CustomerRole>
</CustomerRoles>

Jede CustomerRole stellt die Berechtigungen dar, die eine Person beim Zugriff auf das entsprechende Konto oder eine Gruppe von Konten hat.

Einzeln betrachtet, hat ein Benutzer dieselbe Rolle für die CustomerId, AccountIds und LinkedAccountIds für einen bestimmten CustomerRole. Wenn ein Benutzer jedoch über mehrere Kundenrollen verfügt, hängen die effektiven Berechtigungen von dem vollständigen Satz von CustomerRole-Objekten ab, die von GetUser zurückgegeben werden. Im Folgenden finden Sie einige Beispiele.

Rollenbeispiel für neuen Benutzer

Wenn Sie sich gerade zum ersten Mal bei Microsoft Advertising registriert und ein neues Konto erstellt haben, gibt der GetUser-Vorgang ein CustomerRole-Objekt zurück.

<CustomerRoles xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
	<a:CustomerRole>
	   <a:RoleId>41</a:RoleId>
	   <a:CustomerId>999</a:CustomerId>
	   <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
	   <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
	   <a:CustomerLinkPermission i:nil="true"/>
	</a:CustomerRole>
 </CustomerRoles>

Rollenbeispiel für Anmeldeinformationen mit mehreren Benutzern

Wenn Sie eine Einladung akzeptieren, ein Benutzer bei einem anderen Kunden mit Ihren vorhandenen Anmeldeinformationen aus dem vorherigen Beispiel zu sein, verfügen Sie über Mehrbenutzeranmeldeinformationen in Microsoft Advertising. Ihre Anmeldeinformationen, die den einzelnen Kunden-IDs direkt zugeordnet sind, und der GetUser-Vorgang gibt zwei CustomerRole-Objekte zurück. In diesem Beispiel sind die Elemente in jeder CustomerRole-Instanz mit Ausnahme der CustomerId äquivalent. Die RoleId hängt von der Rolle ab, die Ihnen zugewiesen wurde, als Ihnen der Superadministrator des Vorgesetztenkontos L1 (Kunden-ID 111) die Einladung gesendet hat.

<CustomerRoles xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>999</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:CustomerLinkPermission i:nil="true"/>
  </a:CustomerRole>
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>111</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:CustomerLinkPermission i:nil="true"/>
  </a:CustomerRole>
</CustomerRoles>

Rollenbeispiel für Die Kontohierarchie

Aufbauend auf dem Rollenbeispiel für Anmeldeinformationen für mehrere Benutzer (obwohl Anmeldeinformationen mit mehreren Benutzern nicht erforderlich sind, um eine Hierarchie zu erstellen), richten wir beispielsweise einer der Superadministratorbenutzer im Manager-Konto L1 (Kunden-ID 111) (ob Sie oder ein anderer Superadministrator) eine Agentur hierachy unter Dem Manager-Konto L1 (Kunden-ID 111) mit Clientlinks für Kunden- und Werbekundenkonto ein:

  • Das Vorgesetztekonto L1 (Kunden-ID 111) ist mit dem Vorgesetztenkonto L2 (Kunden-ID 222) mit einem Administratorlink verknüpft.
  • Vorgesetztes Konto L2 (Kunden-ID 222) mit einem Standardlink zu Vorgesetztenkonto L3 (Kunden-ID 333) verknüpft.
  • Manager-Konto L3 (Kunden-ID 333) links zu Anzeigenkonto 4A (Konto-ID 444111) mit einem Link auf Kontoebene. Ad Account 4A (Konto-ID 444111) befindet sich direkt unter Dem Vorgesetztenkonto L4 (Kunden-ID 444), das selbst nicht in der Hierarchie auf Kundenebene enthalten ist.

Sie haben weiterhin Zugriff auf den ursprünglichen Kunden, den Sie registriert haben, d. h. 999, und Sie sind weiterhin ein direkter Benutzer auf Dem Manager-Konto L1 (Kunden-ID 111). Der GetUser-Vorgang gibt nun zwei zusätzliche CustomerRole-Objekte zurück, d. h. eines für Manager Account L2 (Kunden-ID 222) und Manager-Konto L3 (Kunden-ID 333). Sie können auf alle AccountIds und LinkedAccountIds zugreifen, auf die über das Manager-Konto L2 (Kunden-ID 222) bzw. 333 zugegriffen werden kann. In diesem Beispiel können Sie über das Vorgesetztekonto L3 (Kunden-ID 333) auf Das Anzeigenkonto 4A (Konto-ID 444111) zugreifen. Wenn Sie also Dienstvorgänge aufrufen, die die Kunden-ID erfordern, müssen Sie das Vorgesetztekonto L3 (Kunden-ID 333) verwenden, um auf das Konto 444111 zuzugreifen.

<CustomerRoles xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>999</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:CustomerLinkPermission i:nil="true"/>
  </a:CustomerRole>
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>111</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:CustomerLinkPermission i:nil="true"/>
  </a:CustomerRole>
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>222</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:CustomerLinkPermission>Administrative</a:CustomerLinkPermission>
  </a:CustomerRole>
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>333</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
        <b:long>444111</b:long>
      </a:LinkedAccountIds>
      <a:CustomerLinkPermission>Standard</a:CustomerLinkPermission>
  </a:CustomerRole>
</CustomerRoles>

Die Kundenrollen informieren, auf welche Kunden Sie zugreifen können, beschreiben aber nicht immer, wie Sie den Zugriff erhalten haben. Der Vorgang GetLinkedAccountsAndCustomersInfo gibt die Kunden- und Kontohierarchie unter dem angegebenen Kunden zurück. Ausführliche Informationen und Beispiele finden Sie unter Anzeigen der Hierarchie.

Rollenbeispiel für Aggregatorhierarchie

Wenn Sie sich gerade zum ersten Mal bei Microsoft Advertising registriert haben, Aggregator-Anmeldeinformationen erhalten und über SignupCustomer ein neues Kunden- und Werbetreibendenkonto erstellt haben, gibt der GetUser-Vorgang zwei CustomerRole-Objekte zurück. Die Elemente in jeder CustomerRole-Instanz sind mit Ausnahme der RoleId äquivalent. Ein Aggregator verfügt in Microsoft Advertising über zwei Rollenbezeichner, d. h. 41 und 33.

<CustomerRoles xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <a:CustomerRole>
      <a:RoleId>33</a:RoleId>
      <a:CustomerId>111</a:CustomerId>
      <a:AccountIds i:nil="true" xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
        <b:long>111222</b:long>                  
      </a:LinkedAccountIds>
      <a:CustomerLinkPermission i:nil="true"/>
  </a:CustomerRole>
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>111</a:CustomerId>
      <a:AccountIds i:nil="true" xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
        <b:long>111222</b:long>                  
      </a:LinkedAccountIds>
      <a:CustomerLinkPermission i:nil="true"/>
  </a:CustomerRole>
</CustomerRoles>

Zugriffs- und Entwicklertoken

Um programmgesteuert im Namen eines Microsoft Advertising-Benutzers handeln zu können, müssen Sie deren Zustimmung einholen. Am Ende des Zustimmungsworkflows können Sie ein Zugriffstoken abrufen, das den Benutzer darstellt. Das Zugriffstoken verfügt über die gleichen Rollen und den gleichen Zugriff auf die gleichen Konten wie der Benutzer in der Microsoft Advertising-Webanwendung. Anders ausgedrückt: Die gleichen Konten und Benutzerrollenberechtigungen, die in der Microsoft Advertising-Webanwendung verfügbar sind, stehen dem Benutzer programmgesteuert über die API zur Verfügung. Informationen zum Abrufen eines Zugriffstokens, das im Namen eines Microsoft Advertising-Benutzers handelt, finden Sie unter Authentifizierung mit OAuth.

Außerdem benötigen Sie ein Entwicklertoken, das Ihre Anwendung eindeutig identifiziert. Durch das Abrufen eines Entwicklertokens für den API-Zugriff werden keine zusätzlichen Berechtigungen für Microsoft Advertising-Konten gewährt. Ein Entwicklertoken ermöglicht den programmgesteuerten Zugriff auf die Konten, die bereits für einen Benutzer bereitgestellt wurden. Weitere Informationen finden Sie unter Abrufen eines Entwicklertokens.

Tipp

Informationen zum Abrufen eines Zugriffstokens und zum ersten Dienstaufruf mithilfe der Bing Ads-API finden Sie im Schnellstarthandbuch .

Die Header AuthenticationToken und DeveloperToken müssen in jeder Anforderung über die Bing Ads-API festgelegt werden. Hier ist ein Beispielaufruf des GetUser-Vorgangs .

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v13="https://bingads.microsoft.com/Customer/v13">
  <soapenv:Header>
      <v13:DeveloperToken>DeveloperTokenGoesHere</v13:DeveloperToken>
      <v13:AuthenticationToken>AccessTokenGoesHere</v13:AuthenticationToken>
  </soapenv:Header>
  <soapenv:Body>
      <v13:GetUserRequest>
        <v13:UserId xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
      </v13:GetUserRequest>
  </soapenv:Body>
</soapenv:Envelope>

Anmeldeinformationen für mehrere Benutzer

Sie können einen Satz von Microsoft Advertising-Anmeldeinformationen für mehrere Benutzer verwenden, um kundenübergreifend auf Werbekundenkonten zuzugreifen, möglicherweise mit unterschiedlichen Benutzerrollen und Berechtigungen.

Es kann hilfreich sein, sich "Anmeldeinformationen mit mehreren Benutzern" als "mehrere Benutzerrollen" zu vorstellen, da Sie sich aus einer Perspektive nur mit einem Benutzernamen anmelden, um auf Multipe-Kunden mit unterschiedlichen Berechtigungen zuzugreifen. Die Anmeldeinformationen einer Person können mit mehreren unterschiedlichen Benutzerrollen agieren. Beispielsweise gewähren Ihnen Ihre Anmeldeinformationen für mehrere Benutzer Zugriff auf Kunde A und Kunde B. Ihre Benutzerrolle "Viewer" für Kunde A schränkt Sie jedoch davon ab, Änderungen an den Konten vorzunehmen, die zu Kunde A gehören. Als Superadministrator für Kunde B haben Sie jedoch die vollständige Kontrolle über die Konten dieses Kunden.

Wenn Sie bereits über mehrere Sätze von Anmeldeinformationen verfügen, können Sie die Unterstützung bitten, auf einen Satz von Anmeldeinformationen zu konsolidieren . Die Benutzerrolle und der Kontozugriff über jeden Kunden, den Sie vor der Konsolidierung hatten, werden beibehalten. Beachten Sie auch, dass die Anmeldeinformationen derselben Person separaten Gruppen von Benutzerkontaktinformationen zugeordnet werden können, d. h. eindeutigen Kontaktinformationen pro Kunde.

Weitere Informationen finden Sie im Microsoft Advertising-Hilfethema Verwalten Ihres Benutzernamens für den Zugriff auf mehrere Konten.

Mehrbenutzerkonsolidierung

Wenn Sie sich bereits mit mehreren Anmeldeinformationen anmelden, z. B. zwei E-Mail-Adressen, können Anmeldeinformationen für mehrere Benutzer manuell bereitgestellt werden. Wenden Sie sich an den Support oder Ihren Konto-Manager, um vorhandene Benutzernamen in einem einzelnen Benutzernamen zusammenzuführen. Eine weitere Möglichkeit besteht darin, ihnen von jedem Kunden, den Sie verwalten möchten, eine Einladung zu senden und dann jede Einladung mit den Anmeldeinformationen zu akzeptieren, die Sie behalten möchten. Diese Option ist entweder über die Microsoft Advertising-Webanwendung oder den SendUserInvitation-Dienstvorgang verfügbar. Nachdem Sie die Einladung mit vorhandenen Microsoft Advertising-Anmeldeinformationen angenommen haben, verfügen Sie über Anmeldeinformationen für mehrere Benutzer.

Betrachten wir die folgenden Benutzerrollen und Berechtigungen vor der Konsolidierung mit mehreren Benutzern. In der Microsoft Advertising-Webanwendung muss sich jeder Benutzer separat anmelden und verfügt während jeder angemeldeten Sitzung über unterschiedliche Berechtigungen. Ebenso stellt das Zugriffstoken jedes Benutzers (siehe Authentifizierung mit OAuth) über die API Berechtigungen dar, die auf den entsprechenden Benutzer und die entsprechende Rolle beschränkt sind.

Benutzer Rolle Berechtigungen
one@contoso.com Viewer Kunde A – Alle Konten
two@contoso.com Superadministrator Kunde B – Alle Konten
three@contoso.com Viewer Kunde C – Konto A
four@contoso.com Standardbenutzer Kunde B – Alle Konten

Beachten Sie zunächst, dass nur eine E-Mail-Adresse pro Kunde konsolidiert werden kann, sodass in diesem Beispiel two@contoso.com und four@contoso.com nicht zusammen konsolidiert werden können. Sehen wir uns nun an, was passiert, nachdem die drei wichtigsten Benutzer unter one@contoso.comkonsolidiert wurden.

  • Keine Änderungen für Benutzer four@contoso.com über die Microsoft Advertising-Webanwendung, den Microsoft Advertising-Editor oder die API.
  • Der Benutzer one@contoso.com kann sich über die Microsoft Advertising-Webanwendung und den Microsoft Advertising-Editor anmelden. Die konsolidierten Benutzer haben also keine Berechtigungen mehr, two@contoso.comthree@contoso.com sich über die Microsoft Advertising-Webanwendung oder den Microsoft Advertising-Editor anzumelden. Wenn Sie als one@contoso.comangemeldet sind, können Sie den Kontext zu den Kundenkonten mit den entsprechenden Benutzerrollen wechseln, die zuvor und three@contoso.comzugewiesen two@contoso.com wurden. Obwohl Sie auf mehrere Kunden zugreifen können, die mit den Anmeldeinformationen eines Benutzers (one@contoso.com) angemeldet sind, müssen Sie von Kunde zu Kunde wechseln, um die Konten zu verwalten, die mit eindeutigen Benutzerrollen verknüpft sind. Kunden und ihre zugehörigen Konten bleiben unterschiedlich. Weitere Informationen finden Sie im Microsoft Advertising-Hilfethema Verwalten Ihres Benutzernamens für den Zugriff auf mehrere Konten.
  • Nach der Konsolidierung mehrerer Benutzer stellt das Zugriffstoken für den Benutzer one@contoso.com Berechtigungen für die konsolidierte Liste (Obermenge) von Konten dar. Die in Kraft getretene Benutzerrolle hängt von den in der Serviceanforderung angegebenen Kunden- und Konto-IDs ab. Zugriffstoken für two@contoso.com und three@contoso.com werden nicht mehr akzeptiert, d. h., Fehler 120 – UserLoginAccessDenied wird zurückgegeben.

Kontaktinformationen für mehrere Benutzer

Eine Person mit Anmeldeinformationen für mehrere Benutzer wird durch mehrere Benutzerobjekte und entsprechende Benutzer-IDs dargestellt. Tatsächlich können die Anmeldeinformationen derselben Person separaten Gruppen von Benutzerkontaktinformationen zugeordnet werden, d. h. eindeutigen Kontaktinformationen pro Kunde.

Die GetUser-Antwort kann je nachdem, wer den Anruf tätigt, variieren, auch mit demselben Benutzerbezeichner. Angenommen, vor der Konsolidierung waren die Bezeichner für one@contoso.com, two@contoso.comund three@contoso.com 123, 456 bzw. 789. Jede Benutzer-ID ordnet eine Person effektiv einem bestimmten Kunden zu, z. B. wird der Bezeichner 123 dem ursprünglichen Kunden zugeordnet one@contoso.com , auf den die Person zugreifen konnte. In diesem Beispiel wird 123 als ursprünglicher Benutzerbezeichner bezeichnet.

  • Wenn das Zugriffstoken für one@contoso.com verwendet wird, um GetUser aufzurufen, und die UserId null oder UserId auf die ursprüngliche Benutzer-ID (z. B. 123) festgelegt ist, gibt der Vorgang CustomerRole-Objekte für alle Kunden zurück, auf die der Benutzer zugreifen kann.
  • Wenn das Zugriffstoken für one@contoso.com verwendet wird, um GetUser aufzurufen, und die UserId auf 456 oder 789 festgelegt ist, gibt der Vorgang nur ein CustomerRole-Objekt zurück, das diese Person einem bestimmten Kunden zuordnet.

Die Benutzereinstellungen Name, Lcid, JobTitle und ContactInfo für dieselbe Person werden automatisch mit allen Updates synchronisiert, die nach der Benutzerkonsolidierung auftreten. LastModifiedByUserId und LastModifiedTime sind auch für jedes zurückgegebene User-Objekt synchron, es sei denn, Sie hatten einen alten Benutzernamen zusammengeführt und haben seit der Konsolidierung keine Benutzereinstellungen aktualisiert.

Hinweis

Der TimeStamp unterscheidet sich von LastModifiedTime. Alle TimeStamp-Werte sind pro Benutzer eindeutig, und wenn Sie UpdateUser aufrufen, müssen Sie die Zeitstempel des entsprechenden Benutzers (einschließlich des Adresszeitstempels) einschließen.

Angenommen, Sie haben die Benutzerinformationen für one@contoso.com seit vor der Konsolidierung mit two@contoso.com und three@contoso.comnicht aktualisiert. Nach der Konsolidierung und bis die Benutzereinstellungen nach der Konsolidierung aktualisiert werden, beobachten Sie weiterhin eine eindeutige LastModifiedByUserId und LastModifiedTime innerhalb jedes zurückgegebenen User-Objekts .

User Id Kontaktinformations-ID Berechtigungen LastModifiedByUserId
123 234 Kunde A – Alle Konten 123
456 567 Kunde B – Alle Konten 456
789 890 Kunde C – Konto A 789

Nehmen wir nun an, dass one@contoso.com im Kontext von Kunde B handelt und seine Kontaktinformationen aktualisiert. Die aktualisierten Kontaktinformationen sowie die gleichen LastModifiedByUserId und LastModifiedTime werden jetzt für alle zurückgegebenen User-Objekte synchronisiert.

User Id Kontaktinformations-ID Berechtigungen LastModifiedByUserId
123 234 Kunde A – Alle Konten 456
456 567 Kunde B – Alle Konten 456
789 890 Kunde C – Konto A 456

Kontohierarchie

Suchwerbunternehmen orientieren sich in der Regel an einem oder mehreren der folgenden Kontoverwaltungsmodelle.

  • Ein direkter Werbetreibender erstellt eine Bing Ads-API-Anwendung für seine eigenen Werbekampagnen und wird für gültige Anzeigenklicks direkt von Microsoft in Rechnung gestellt.
  • Ein Toolanbieter erstellt eine Bing Ads-API-Anwendung für andere Unternehmen, um ihre Werbekampagnen zu verwalten, und wird nicht von Microsoft in Rechnung gestellt. Der Werbekundenbenutzer besitzt die Konten, wird für gültige Anzeigenklicks direkt von Microsoft in Rechnung gestellt und kann eine Gebühr an den Toolanbieter zahlen.
  • Eine Agentur erstellt eine Bing Ads-API-Anwendung für ihr Unternehmen, um die Kampagnen ihrer Werbekunden zu verwalten. Der Kunde der Agentur besitzt die Konten, wird für gültige Anzeigenklicks direkt von Microsoft in Rechnung gestellt und kann eine Gebühr an die Agentur zahlen.
  • Ein Aggregator oder Vertriebspartner erstellt eine Bing Ads-API-Anwendung, um die Kampagnen seiner Werbekunden zu verwalten, und wird für gültige Liveklicks direkt von Microsoft in Rechnung gestellt. Der Werbetreibende anmeldet sich nicht für Microsoft Advertising-Anmeldeinformationen und kann eine Gebühr an den Aggregator zahlen.

Unabhängig vom Geschäftsmodell sind die anfängliche Registrierung und die Bereitstellung von Benutzerrollen mehr oder weniger identisch. In den folgenden Abschnitten werden zusätzliche Schritte erläutert, die zum Einrichten von Agentur - und Aggregatorhierarchien erforderlich sind.

Agenturhierarchie

Eine Agentur erstellt eine Bing Ads-API-Anwendung für ihr Unternehmen, um die Kampagnen ihrer Werbekunden zu verwalten. Clientlinks ermöglichen es einer Agentur, einige oder alle Aspekte eines Werbekundenkontos zu verwalten. Die Clientlinkanforderung kann den Bereich auf einzelne Kundenkundenkonten oder alle Konten unter dem Kunden beschränken.

Hinweis

Im Kontext von Hierarchien wird ein Kunde auch als "Manager-Konto" bezeichnet. Ein AdvertiserAccount wird als "Konto" oder "Inserentenkonto" bezeichnet.

Es gibt keine festgelegte Grenze für die Anzahl von Kundenkonten, die mit einer Agentur verknüpft werden können; Allerdings werden nur 5 Tiefenebenen für Die Verknüpfungen zwischen Vorgesetztenkonto und Vorgesetztenkonto unterstützt. Auf jeder Ebene (L1, L2, L3, L4, L5) kann ein Manager-Konto mit einer beliebigen Anzahl von Manager-Konten und Anzeigenkonten verknüpft werden. Weitere Informationen zum Werden einer Agentur finden Sie im Hilfeartikel Verwalten Ihrer Kunden als Agentur in Microsoft Advertising oder Ressourcen für Agenturpartner.

Um eine Hierarchie zum Verwalten von Kundenkonten einzurichten, muss die Agentur eine Einladung an den Kunden senden, die dann von einem autorisierten Benutzer im Kunden akzeptiert werden muss. Um zu ermitteln, ob bereits ein Link vorhanden ist, rufen Sie den SearchClientLinks-Vorgang auf, und überprüfen Sie das Status-Element eines zurückgegebenen ClientLinks. Um nach einem einzelnen Konto zu suchen, legen Sie das Prädikatfeld auf ClientAccountId und den Prädikatwert auf den Kontobezeichner fest, den Sie suchen möchten.

Hinweis

Nur ein Benutzer mit Super Admin- oder Standard-Anmeldeinformationen kann Clientlinks zu Werbekundenkonten hinzufügen, aktualisieren und danach suchen. Nur ein Benutzer mit Super admin-Anmeldeinformationen kann Clientlinks zu Kunden hinzufügen, aktualisieren und danach suchen.

Wenn ein Link mit dem Status Aktiv, LinkAccepted, LinkInProgress, LinkPending, UnlinkInProgress oder UnlinkPending vorhanden ist, kann die Agentur keine doppelte Clientverknüpfung initiieren.

Wenn noch keine Clientverbindung mit dem angegebenen Konto vorhanden ist oder der Lebenszyklus eines vorhandenen Links mit dem Status Abgelaufen, LinkCanceled, LinkDeclined, LinkFailed oder Inactive beendet wurde, kann die Agentur eine neue Clientlinkeinladung initiieren, indem sie den AddClientLinks-Vorgang aufruft . Der Dienst überschreibt den Clientlinkstatus sofort in LinkPending.

Wichtig

Bei Kundenlinks für Werbekunden muss die Agentur angeben, ob der Kunde oder die Agentur für die Abrechnung verantwortlich ist, indem sie das IsBillToClient-Element in der Clientlinkanforderung festlegt.

Zum Aktualisieren einer Clientverknüpfung ist dessen TimeStamp-Element für die Überprüfung erforderlich. Daher müssen Sie zuerst den SearchClientLinks-Vorgang aufrufen, um das vorhandene ClientLink-Objekt abzurufen. Ändern Sie dann das Status-Element des zurückgegebenen ClientLinks, und schließen Sie das aktualisierte ClientLink-Objekt in einen nachfolgenden Aufruf des UpdateClientLinks-Vorgangs ein.

Hinweis

Der Client kann über eine Anwendung, die auf der Bing Ads-API basiert, oder über die Registerkarte Konten & Abrechnung in der Microsoft Advertising-Webanwendung akzeptieren oder ablehnen.

Der Client kann nur den UpdateClientLinks-Vorgang verwenden, um den Status als LinkAccepted oder LinkDeclined zu aktualisieren.

  • Wenn der Client den Status auf LinkDeclined festlegt, endet der Lebenszyklus von Clientlinks. Sie können einen abgelehnten Clientlink nicht aktualisieren, und Sie müssen eine neue Einladung senden, um das Clientkonto zu verwalten.
  • Wenn der Client den Status auf LinkAccepted festlegt, geht der Status in LinkInProgress über. Wenn der Linkprozess erfolgreich ist, aktualisiert der Dienst den Clientlinkstatus in Aktiv.

Wenn der Link beispielsweise aufgrund eines Abrechnungsübergangsfehlers nicht hergestellt werden kann, aktualisiert der Dienst den Clientlinkstatus in LinkFailed. Sie können einen fehlerhaften Clientlink nicht aktualisieren, und Sie müssen eine neue Einladung senden, um das Clientkonto zu verwalten. Wenn der Kunde oder die Agentur innerhalb von 30 Tagen keine Maßnahmen ergreift, legt der Dienst den Status auf LinkExpired fest, und der Lebenszyklus von Clientlinks endet. Sie können einen abgelaufenen Clientlink nicht aktualisieren, und Sie müssen eine neue Einladung senden, um das Clientkonto zu verwalten.

Link zum Clientlink

Wenn der Clientlinkstatus LinkPending lautet, kann die Agentur eine vorherige Linkanforderung abbrechen.

Wenn der Clientlinkstatus Aktiv ist, kann die Agentur die bestehende Beziehung mit dem Kunden beenden. Um den Vorgang zum Aufheben der Verknüpfung zu initiieren, legt die Agentur den Status der Clientverknüpfung auf UnlinkRequested fest und ruft den UpdateClientLinks-Vorgang auf . Beim Aktualisieren des Status mit UnlinkRequested wird der Status effektiv auf UnlinkInProgress festgelegt. Der Dienst übergibt den Clientverknüpfungsstatus sofort in Verknüpfung ausstehend und wartet dann, bis die Systemressourcen fortgesetzt werden. Der Zustand sollte schnell in UnlinkInProgress übergehen.

Wenn der Vorgang zum Aufheben der Verknüpfung beispielsweise aufgrund eines Abrechnungsübergangsfehlers fehlschlägt, wird der Clientlink mit dem Status Aktiv fortgesetzt. Wenn der Vorgang zum Aufheben der Verknüpfung erfolgreich ist, wird der Status in Inaktiv aktualisiert, und der Lebenszyklus der Clientverknüpfung endet. Sie können einen inaktiven Clientlink nicht aktualisieren, und Sie müssen eine neue Einladung senden, um das Clientkonto zu verwalten.

Aufheben der Verknüpfung mit Client Aufheben

Codebeispiele zum Hinzufügen und Aktualisieren einer Clientlink-Einladung finden Sie unter Codebeispiel für Clientlinks.

Anzeigen der Hierarchie

Eine Agentur hat mehrere Optionen zum Anzeigen der Kontenhierarchie.

  • Der GetUser-Vorgang gibt Benutzerrollen pro Kunde und verknüpften Konten zurück. Die Kundenrollen informieren, auf welche Kunden Sie zugreifen können, beschreiben aber nicht immer, wie Sie den Zugriff erhalten haben. Die Bestimmung der Benutzerrolle macht einen Unterschied zwischen Administrativen und Standardclientlinks aus. Beispiele für Kundenrollen finden Sie unter Abrufen von Benutzerrollen.
  • Der SearchClientLinks-Vorgang gibt Ihnen den aktuellen Status einer Clientverknüpfung an, wenn Sie bereits über die Bezeichner der Agentur und der Cliententität verfügen. Sie können z. B. suchen, indem Sie die Kunden-ID und entweder die Clientkonto-ID oder die Clientkunden-ID verwalten.
  • Der Vorgang GetLinkedAccountsAndCustomersInfo gibt die Kunden- und Kontohierarchie unter dem angegebenen Kunden zurück.

Angenommen, eine Agenturhierarchie wurde unter Manager Account L1 (Kunden-ID 111) mit Kunden- und Werbekundenkonto-Clientlinks eingerichtet:

  • Vor der Einrichtung der Hierarchie wurden vier separate Managerkonten bereitgestellt. Vorgesetztes Konto L1 enthält Anzeigenkonto 1A und Anzeigenkonto 1B. Vorgesetztes Konto L2 enthält Anzeigenkonto 2A und Anzeigenkonto 2B. Vorgesetztes Konto L3 enthält Anzeigenkonto 3A und Anzeigenkonto 3B. Vorgesetztes Konto L4 enthält Anzeigenkonto 4A und Anzeigenkonto 4B.
  • Das Vorgesetztekonto L1 (Kunden-ID 111) ist mit dem Vorgesetztenkonto L2 (Kunden-ID 222) mit einem Administratorlink verknüpft.
  • Vorgesetztes Konto L2 (Kunden-ID 222) mit einem Standardlink zu Vorgesetztenkonto L3 (Kunden-ID 333) verknüpft.
  • Manager-Konto L3 (Kunden-ID 333) links zu Anzeigenkonto 4A (Konto-ID 444111) mit einem Link auf Kontoebene. Ad Account 4A (Konto-ID 444111) befindet sich direkt unter Dem Vorgesetztenkonto L4 (Kunden-ID 444), das selbst nicht in der Hierarchie auf Kundenebene enthalten ist. In diesem Beispiel können Sie über das Vorgesetztekonto L3 (Kunden-ID 333) auf Das Anzeigenkonto 4A (Konto-ID 444111) zugreifen. Wenn Sie also Dienstvorgänge aufrufen, die die Kunden-ID erfordern, müssen Sie das Vorgesetztekonto L3 (Kunden-ID 333) verwenden, um auf das Konto 444111 zuzugreifen.

Ein Benutzer mit Zugriff auf die vollständige Hierarchie, der sich bei der Microsoft Advertising-Webanwendung unter Manager Account L1 (Kunden-ID 111) anmeldet, hat Zugriff auf die folgende Kontoansicht.

Manager-Konto mit

Wenn Sie nach Kunden-ID 111 suchen, enthält die GetLinkedAccountsAndCustomersInfo-Antwort das Anzeigenkonto 1A und das Anzeigenkonto 1B in AccountsInfo. Informationen zum Managerkonto L2 werden in CustomersInfo zurückgegeben.

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <s:Header>
      <h:TrackingId xmlns:h="https://bingads.microsoft.com/Customer/v13">f4f8d20a-e354-4bfc-b196-bef9d766d372</h:TrackingId>
   </s:Header>
   <s:Body>
      <GetLinkedAccountsAndCustomersInfoResponse xmlns="https://bingads.microsoft.com/Customer/v13">
         <AccountsInfo xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
            <a:AccountInfo>
               <a:Id>111111</a:Id>
               <a:Name>Ad Account 1A</a:Name>
               <a:Number>E101NUMB</a:Number>
               <a:AccountLifeCycleStatus>Pause</a:AccountLifeCycleStatus>
               <a:PauseReason>2</a:PauseReason>
            </a:AccountInfo>
            <a:AccountInfo>
               <a:Id>111222</a:Id>
               <a:Name>Ad Account 1B</a:Name>
               <a:Number>E102NUMB</a:Number>
               <a:AccountLifeCycleStatus>Pause</a:AccountLifeCycleStatus>
               <a:PauseReason>2</a:PauseReason>
            </a:AccountInfo>
         </AccountsInfo>
         <CustomersInfo xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
            <a:CustomerInfo>
               <a:Id>222</a:Id>
               <a:Name>Manager Account L2</a:Name>
            </a:CustomerInfo>
         </CustomersInfo>
      </GetLinkedAccountsAndCustomersInfoResponse>
   </s:Body>
</s:Envelope>

Ebenso, wenn Sie nach Kunden-ID 222 suchen, enthält die GetLinkedAccountsAndCustomersInfo-Antwort das Anzeigenkonto 2A und das Anzeigenkonto 2B in AccountsInfo. Informationen zum Vorgesetztenkonto L3 werden in CustomersInfo zurückgegeben.

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <s:Header>
      <h:TrackingId xmlns:h="https://bingads.microsoft.com/Customer/v13">f4f8d20a-e354-4bfc-b196-bef9d766d372</h:TrackingId>
   </s:Header>
   <s:Body>
      <GetLinkedAccountsAndCustomersInfoResponse xmlns="https://bingads.microsoft.com/Customer/v13">
         <AccountsInfo xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
            <a:AccountInfo>
               <a:Id>222111</a:Id>
               <a:Name>Ad Account 2A</a:Name>
               <a:Number>E201NUMB</a:Number>
               <a:AccountLifeCycleStatus>Pause</a:AccountLifeCycleStatus>
               <a:PauseReason>2</a:PauseReason>
            </a:AccountInfo>
            <a:AccountInfo>
               <a:Id>222222</a:Id>
               <a:Name>Ad Account 2B</a:Name>
               <a:Number>E202NUMB</a:Number>
               <a:AccountLifeCycleStatus>Pause</a:AccountLifeCycleStatus>
               <a:PauseReason>2</a:PauseReason>
            </a:AccountInfo>
         </AccountsInfo>
         <CustomersInfo xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
            <a:CustomerInfo>
               <a:Id>333</a:Id>
               <a:Name>Manager Account L3</a:Name>
            </a:CustomerInfo>
         </CustomersInfo>
      </GetLinkedAccountsAndCustomersInfoResponse>
   </s:Body>
</s:Envelope>

Wenn Sie nun nach Kunden-ID 333 suchen, enthält die GetLinkedAccountsAndCustomersInfo-Antwort Das Anzeigenkonto 3A, das Anzeigenkonto 3B und das Anzeigenkonto 4A in AccountsInfo. Unter CustomersInfo sind keine Vorgesetztenkonten aufgeführt.

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <s:Header>
      <h:TrackingId xmlns:h="https://bingads.microsoft.com/Customer/v13">e9ecedcc-720d-4ba4-a3e8-9bdef148dae2</h:TrackingId>
   </s:Header>
   <s:Body>
      <GetLinkedAccountsAndCustomersInfoResponse xmlns="https://bingads.microsoft.com/Customer/v13">
         <AccountsInfo xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
            <a:AccountInfo>
               <a:Id>333111</a:Id>
               <a:Name>Ad Account 3A</a:Name>
               <a:Number>E301NUMB</a:Number>
               <a:AccountLifeCycleStatus>Pause</a:AccountLifeCycleStatus>
               <a:PauseReason>2</a:PauseReason>
            </a:AccountInfo>
            <a:AccountInfo>
               <a:Id>333222</a:Id>
               <a:Name>Ad Account 3B</a:Name>
               <a:Number>E302NUMB</a:Number>
               <a:AccountLifeCycleStatus>Pause</a:AccountLifeCycleStatus>
               <a:PauseReason>2</a:PauseReason>
            </a:AccountInfo>
            <a:AccountInfo>
               <a:Id>444111</a:Id>
               <a:Name>Ad Account 4A</a:Name>
               <a:Number>E401NUMB</a:Number>
               <a:AccountLifeCycleStatus>Pause</a:AccountLifeCycleStatus>
               <a:PauseReason>2</a:PauseReason>
            </a:AccountInfo>
         </AccountsInfo>
         <CustomersInfo xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"/>
      </GetLinkedAccountsAndCustomersInfoResponse>
   </s:Body>
</s:Envelope>

Wenn Sie nun nach Kunden-ID 444 suchen, enthält die GetLinkedAccountsAndCustomersInfo-Antwort das Anzeigenkonto 4A und das Anzeigenkonto 4B in AccountsInfo. Unter CustomersInfo sind keine Vorgesetztenkonten aufgeführt.

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <s:Header>
      <h:TrackingId xmlns:h="https://bingads.microsoft.com/Customer/v13">e5799094-dad6-45b8-983b-4ace50efd86b</h:TrackingId>
   </s:Header>
   <s:Body>
      <GetLinkedAccountsAndCustomersInfoResponse xmlns="https://bingads.microsoft.com/Customer/v13">
         <AccountsInfo xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
            <a:AccountInfo>
               <a:Id>444111</a:Id>
               <a:Name>Ad Account 4A</a:Name>
               <a:Number>E401NUMB</a:Number>
               <a:AccountLifeCycleStatus>Pause</a:AccountLifeCycleStatus>
               <a:PauseReason>2</a:PauseReason>
            </a:AccountInfo>
            <a:AccountInfo>
               <a:Id>444222</a:Id>
               <a:Name>Ad Account 4B</a:Name>
               <a:Number>E402NUMB</a:Number>
               <a:AccountLifeCycleStatus>Pause</a:AccountLifeCycleStatus>
               <a:PauseReason>2</a:PauseReason>
            </a:AccountInfo>
         </AccountsInfo>
         <CustomersInfo xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"/>
      </GetLinkedAccountsAndCustomersInfoResponse>
   </s:Body>
</s:Envelope>

Hier sind einige wichtige Erkenntnisse aus den obigen Beispielantworten:

  • Obwohl GetLinkedAccountsAndCustomersInfo eine ähnliche Struktur zurückgibt, unabhängig davon, ob die Kunden-ID 111 oder 222 angefordert wird, gibt es einen bemerkenswerten Unterschied. Wie in der Einführung des Szenarios erwähnt, ist der Link von Mananger-Konto L1 zu Manager-Konto L2 ein Administratorlink, während der Link vom Manager-Konto L2 zum Vorgesetztenkonto L3 Standard ist. Die GetLinkedAccountsAndCustomersInfo-Antwort enthält keine Details zum Linktyp, d. h. Administrator oder Standard. Da der Linktyp die Berechtigung eines Benutzers abhängig von seiner Benutzerrolle weiter verfeinern kann, ist er in jeder CustomerRole enthalten, wenn Sie GetUser aufrufen.
  • Bei der Suche nach Kunden-ID 333 gibt es keinen offensichtlichen Unterschied zwischen Anzeigenkonto 3A, Anzeigenkonto 3B und Anzeigenkonto 4A. Wie in der Szenarioeinführung erwähnt, ist das Anzeigenkonto 4A über einen Clientlink für Das Werbekundenkonto zugänglich, während die anderen Konten direkt im Manager-Konto L3 enthalten sind. Wenn Sie den direkten Besitzer jedes Kontos ermitteln müssen, können Sie andere Dienstvorgänge aufrufen, z. B. GetAccount oder SearchAccounts.
  • In der aktuellen Hierarchie ist Ad Account 4B nur für Benutzer im Manager-Konto L4 verfügbar. Benutzer im Manager-Konto L3 können für den Zugriff auf 3 Konten bereitgestellt werden, Benutzer in Manager-Konto L2 können für den Zugriff auf 5 Konten und Benutzer im Manager-Konto L1 für den Zugriff auf 7 Konten bereitgestellt werden. Ein Superadministrator kann den Zugriff jedes Benutzers auf eine Teilmenge der verfügbaren Konten beschränken.

Aggregatorhierarchie

Die Aggregatorrolle wird einer begrenzten Gruppe von Partnern angeboten, die einer großen Anzahl von Werbetreibenden Suchmarketingtools und -dienste anbieten. Mit der Aggregatorrolle können Partner programmgesteuert neue Kundenkonten erstellen. Dem Aggregator werden alle Werbekosten, die seinen Kunden entstehen, per Rechnung abgerechnet. Der Werbetreibende anmeldet sich in der Regel nicht für Microsoft Advertising-Anmeldeinformationen und zahlt möglicherweise eine Gebühr an den Aggregator.

Ein Aggregatorbenutzer wird in der primären Kundenshell bereitgestellt. Wie unter Entitätsgrenzwerte beschrieben, werden alle Werbeaktivitäten nach Kunden organisiert, die über ein oder mehrere Konten verfügen können. Jedes Mal, wenn SignupCustomer vom Aggregatorbenutzer aufgerufen wird, wird ein neues Inserentenkonto innerhalb eines neuen Kunden erstellt.

Wichtig

Die Benutzerrolle Aggregator ist für SignupCustomer erforderlich. Wenn dem Aggregatorkunden ein Superadministratorbenutzer hinzugefügt wird, nachdem Ihre anfänglichen Anmeldeinformationen bereitgestellt wurden, kann der Benutzer standardmäßig die Daten aller Kunden verwalten, die der Aggregator verwaltet. Der Benutzer kann SignupCustomer nicht aufrufen, hat aber ansonsten Lese- und Schreibzugriff auf die Kampagnendaten.

Der SignupCustomer-Vorgang erfordert sowohl die Objekte Customer als auch AdvertiserAccount . Das Kundenobjekt umfasst den Namen des Kunden, die Adresse, an der sich der Kunde befindet, den Markt, in dem der Kunde tätig ist, und die Branche, an der der Kunde beteiligt ist. Obwohl es möglich ist, mehrere Kunden mit den gleichen Details hinzuzufügen, sollten Sie eindeutige Kundennamen verwenden, damit Benutzer auf einer Benutzeroberfläche problemlos zwischen Kunden unterscheiden können. Das Kontoobjekt muss den Namen des Kontos angeben. die Art der Währung, die zum Begleichen des Kontos verwendet werden soll; und der Zahlungsmethodenbezeichner, der auf NULL festgelegt werden muss. Der Vorgang generiert ein Rechnungskonto und legt den Bezeichner der Zahlungsmethode auf den Bezeichner fest, der der Rechnung des Aggregators zugeordnet ist. Für die Abrechnung wird ein Rollup zum Zahlungsmittel des Aggregators durchgeführt, und Aggregatoren werden alle Gebühren in Rechnung gestellt, die von den von ihnen verwalteten Kunden anfallen.

Abrufen von Aggregatoranmeldeinformationen

Wenn Sie Anmeldeinformationen für den Aggregator anfordern möchten, wenden Sie sich an das von Ihnen festgelegte Kontoverwaltungsteam, um Details zum Abrufen der Aggregatorrolle zu erhalten. Wenn Sie derzeit kein Aggregator sind, aber einer werden möchten, wechseln Sie zur Willkommensseite des Microsoft Advertising-Partnerprogramms .

Siehe auch

Referenz zum Kundendienst
Adressen des Bing Ads-API-Webdiensts