帐户层次结构和用户权限

项目
11/13/2024

Microsoft广告用户可以使用相同的登录凭据来访问多个帐户，每个帐户可能具有不同的权限。代理可以设置帐户层次结构来管理一个父帐户中的所有用户和帐户，使用一个中央钱包支付所有费用，并在客户之间共享通用事件跟踪 (UET) 标记和再营销列表等市场活动资源。

用户角色和权限介绍了可用于每个用户角色的操作、如何在帐户上预配用户、如何发现其当前访问权限，以及如何使用必应广告 API 代表经过身份验证的Microsoft广告用户进行操作。
多用户凭据介绍了如何使用一组Microsoft广告凭据访问跨多个客户（可能具有不同用户角色和权限）的广告客户帐户。如果已有多个登录凭据集，可以请求支持人员合并到一组凭据。
帐户层次结构介绍了如何为客户中的一个或多个用户提供对帐户层次结构的访问权限。实际上，可以从一个父帐户管理所有用户和帐户，并使用一个中央钱包支付所有费用。此外，还可以通过层次结构在客户之间共享市场活动资源，例如通用事件跟踪 (UET) 标记和再营销列表。

注意

在层次结构上下文中，客户也称为“经理帐户”。广告客户帐户称为“帐户”或“广告客户帐户”。

有关帐户中的市场活动层次结构的详细信息，请参阅实体限制。

用户角色和权限

应用程序可能只需要在已知帐户上支持一个超级管理员用户。即使使用这种相对简单的权限结构，你也希望了解每个用户角色可用的操作、如何在帐户上预配用户、如何发现其当前访问权限，以及如何使用必应广告 API 代表经过身份验证的Microsoft广告用户进行操作。

用户角色

由客户的超级管理员或Microsoft广告系统管理员授予的用户角色确定服务可用性。例如，具有广告客户市场活动经理角色的用户可以添加和更新市场活动，但无法创建或更新用户。除非在“按服务引用内容”操作中另有说明，否则下表大致描述了每个用户角色的服务限制。

注意

只能将超级管理员和标准用户设置为帐户的主要联系人。有关用户角色的更多详细信息，请参阅如何向某人授予对我的Microsoft广告帐户的访问权限？帮助主题。

用户角色	可用服务
广告客户市场活动管理器	此角色有权查看所选帐户，以及添加、编辑或删除所选帐户中的市场活动。广告客户市场活动经理可以查看付款方式，但无法管理任何计费和付款任务。所有服务的读取操作都可用。客户管理服务的写入操作通常不可用。一个例外是，广告客户市场活动经理可以使用 UpdateAccount 操作更新广告商帐户的 AutoTagType 元素。
聚合	除 DeleteCustomer 外，所有服务的读取和写入操作都可用。
标准用户	此角色有权管理市场活动，并在所选帐户上执行某些计费活动。此角色无法添加、编辑或删除付款方式;添加或删除帐户。标准用户可以链接和取消链接广告客户帐户，但不能管理客户到客户级别的客户端链接。标准用户可以管理他们有权访问的帐户中的某些用户。标准用户可以邀请或删除其他标准用户、广告客户市场活动经理和查看者，并在当前客户的上下文中查看有关所有用户的信息。但是，标准用户无法邀请或删除超级管理员，也不能编辑超级管理员的角色。拥有非共享受众或 UET 标记的客户中的标准用户可以更新其属性 (范围) （例如说明和名称）以外的其他属性。共享访问群体或 UET 标记时，标准用户无法更新这些属性。有关详细信息，请参阅共享访问群体和 UET 标记技术指南。所有服务的读取操作都可用。使用客户计费服务和客户管理服务的写入操作通常不可用。标准用户可用的操作例外包括 AddInsertionOrder、 UpdateInsertionOrder 和 UpdateAccount。
超级管理员	此角色对所有帐户具有完全权限。超级管理员可以管理与计费和付款、帐户详细信息以及其他用户相关的一切， (包括其他超级管理员) 。超级管理员可以指定其他用户有权访问的帐户。注册为新客户时，第一个用户是超级管理员。拥有访问群体或 UET 标记的客户中的超级管理员用户可以更新访问群体或 UET 标记的客户帐户共享范围。层次结构父客户中的超级管理员用户还可以更新范围。 (范围) （如说明和名称）以外的其他访问群体或 UET 标记属性只能由拥有访问群体或 UET 标记的客户中的超级管理员用户进行更新。层次结构父客户中的超级管理员用户无法更新这些详细信息。有关详细信息，请参阅共享访问群体和 UET 标记技术指南。除 DeleteCustomer 外，所有服务的读取和写入操作都可用
查看器	此角色具有只读权限。所有服务的读取操作都可用。

如果 CustomerLinkPermission) 链接权限 (，则链接客户的超级管理员权限将受到限制。如果链接权限为“管理”，则不会限制其权限。他们还保留客户的完整超级管理员权限，他们可以直接访问，例如，他们注册的位置。

客户链接权限

另请注意，单个用户对给定 CustomerRole 的 CustomerId、AccountId 和 LinkedAccountId 具有相同的角色;但是，如果用户具有多个客户角色，则作为一个整体采取有效权限取决于 GetUser 返回的完整 CustomerRole 对象集。获取用户角色中提供了几个示例。

分配用户角色

在 Microsoft Advertising Web 应用程序中注册新帐户时，你将被授予超级管理员用户角色。超级管理员可以创建具有广告客户市场活动经理、超级管理员、标准或查看者角色的新用户。聚合器角色是通过系统管理员根据特殊请求预配的。有关详细信息，请参阅聚合器层次结构并联系客户经理。

从技术上讲，无法以编程方式创建新用户;但是，可以使用 SendUserInvitation 操作邀请用户通过现有Microsoft广告帐户进行注册。邀请某人加入帐户或帐户集时，还将设置用户角色。 Microsoft广告会生成发送给被邀请者的电子邮件邀请。通过单击电子邮件链接并完成Microsoft广告注册工作流，他们将接受邀请，以管理你在 SendUserInvitation 请求中预配的用户角色的帐户。

注意

在注册新帐户和接受现有帐户邀请时，用户可以使用相同的登录凭据。在任一情况下，使用相同的凭据完成注册工作流时，该人员都被视为拥有多用户凭据。从每个管理客户范围内的用户的超级管理员的角度来看，用户的角色、帐户访问权限和联系信息都是唯一的。在当前客户范围内采取行动时，不会考虑用户在另一个客户上下文中拥有的任何权限。

超级管理员可以选择修改其用户对不同帐户的访问权限，并可能修改用户角色，例如，从“查看者”更改为“标准”用户。若要更新用户的角色，请调用 UpdateUserRoles 操作。

获取用户角色

若要获取可以访问客户的一个或多个帐户的用户列表，请调用 GetUsersInfo 操作。该操作返回一个对象数组，其中包含每个用户的登录电子邮件地址和标识符。然后，可以获取列表中每个用户的详细信息，例如他们在Microsoft广告中的角色和帐户权限，调用 GetUser 操作。如果使 UserId 元素保持为零，则调用 GetUser 时，响应将包括请求标头凭据指定的当前经过身份验证的用户的详细信息。

下面是 GetUser 操作返回的示例 CustomerRoles 元素。

<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>

每个 CustomerRole 表示用户访问相应帐户或帐户集时拥有的权限。

RoleId 表示用户角色，例如，41 表示超级管理员用户角色。
CustomerId 是用户已注册或具有某种帐户层次结构关系的客户的标识符。
AccountIds 元素包含用户可以在 CustomerId 上下文中访问的广告客户帐户的标识符。
LinkedAccountIds 元素包含用户可以在 CustomerId 上下文中访问的链接广告客户帐户的标识符。
CustomerLinkPermission 可能会根据 CustomerId 上下文中的帐户层次结构关系来限制用户角色。

单独来说，用户对给定 CustomerRole 的 CustomerId、AccountId 和 LinkedAccountIds 具有相同的角色;但是，如果用户具有多个客户角色，则作为一个整体采取有效权限取决于 GetUser 返回的完整 CustomerRole 对象集。下面提供了几个示例。

如果首次使用 Microsoft Advertising 注册并创建了一个新帐户，则 GetUser 操作将返回一个 CustomerRole 对象。

RoleId 为 41，因为新帐户的第一个用户具有超级管理员用户角色。
CustomerId 是在注册时预配的客户标识符。
AccountIds 元素为空，因为超级管理员始终可以使用 CustomerId 标识符访问客户中的所有广告客户帐户。
LinkedAccountIds 元素为空，因为你尚未链接到任何客户广告客户帐户。
CustomerLinkPermission 为空，因为可以通过分配的 CustomerId 直接访问广告客户帐户。

<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>

多用户凭据的角色示例

如果你接受邀请成为另一个客户中的用户，并具有上一示例中的现有登录凭据，则你在 Microsoft Advertising 中具有多用户凭据。与每个客户标识符和 GetUser 操作直接关联的登录凭据将返回两个 CustomerRole 对象。在此示例中，每个 CustomerRole 中的元素都是等效的，但 CustomerId 除外。 RoleId 取决于经理帐户 L1 的超级管理员 (客户 ID 111) 向你发送邀请时分配的角色。

<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>

帐户层次结构的角色示例

基于多用户凭据的角色示例 (尽管不需要多用户凭据来构建层次结构) ，例如，经理帐户 L1 中的一个超级管理员用户 (客户 ID 111) (无论你还是另一个超级管理员) 在经理帐户 L1 (客户 ID 111) 下设置代理层次结构，同时包含客户和广告客户帐户客户端链接：

经理帐户 L1 (客户 ID 111) 链接到经理帐户 L2 (客户 ID 222) 以及管理链接。
经理帐户 L2 (客户 ID 222) 链接到经理帐户 L3 (客户 ID 333) 与标准链接。
经理帐户 L3 (客户 ID 333) 链接到 Ad 帐户 4A (帐户 ID 444111) 帐户级别链接。 Ad 帐户 4A (帐户 ID 444111) 直接位于经理帐户 L4 (客户 ID 444) 下，该 ID 本身未包含在客户级别层次结构中。

你仍有权访问注册的原始客户（即 999），并且你仍然是经理帐户 L1 (客户 ID 111) 的直接用户。现在，GetUser 操作将返回另外两个 CustomerRole 对象，即经理帐户 L2 (客户 ID 222) 和经理帐户 L3 (客户 ID 333) 各返回一个。可以分别访问通过经理帐户 L2 访问的所有 AccountId 和 LinkedAccountIds ， (客户 ID 222) 和 333。在此示例中，可以通过经理帐户 L3 (客户 ID 333 444111) 访问 Ad Account 4A (帐户 ID) 即，调用需要客户标识符的服务操作时，必须使用经理帐户 L3 (客户 ID 333) 来访问帐户444111。

<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>

客户角色告知可以访问哪些客户，但不总是描述你如何获取访问权限。 GetLinkedAccountsAndCustomersInfo 操作返回指定客户下的客户和帐户层次结构。有关详细信息和示例，请参阅查看层次结构。

聚合器层次结构的角色示例

如果首次使用 Microsoft Advertising 注册，获取了聚合器凭据，并通过 SignupCustomer 创建了一个新的客户和广告客户帐户，则 GetUser 操作将返回两个 CustomerRole 对象。每个 CustomerRole 中的元素都是等效的， RoleId 除外。聚合器在Microsoft广告中具有两个角色标识符，即 41 和 33。

其中一个 CustomerRole 对象中的 RoleId 为 41，因为新帐户的第一个用户具有超级管理员用户角色。另一个 CustomerRole 对象中的 RoleId 为 33，表示聚合器用户角色。
CustomerId 是在注册时预配的客户标识符。
AccountIds 元素为空，因为超级管理员始终可以使用 CustomerId 标识符访问客户中的所有广告客户帐户。
LinkedAccountIds 元素包含通过 SignupCustomer 创建的子客户中广告客户帐户的标识符。 CustomerRole 对象中不表示子客户标识符。可以调用 GetAccount 来获取广告客户帐户详细信息，例如其 ParentCustomerId。另请注意，可以通过 DeleteAccount 删除聚合帐户，但不能通过 UpdateClientLinks 取消链接这些帐户。调用 SearchClientLinks 操作以帮助确定哪些帐户可以取消链接。
CustomerLinkPermission 为空，因为可以通过分配的 CustomerId 直接访问广告客户帐户。

<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>

访问和开发人员令牌

若要以编程方式代表Microsoft广告用户采取行动，必须获得他们的同意。在同意工作流结束时，可以获取表示用户的访问令牌。访问令牌具有与用户在 Microsoft Advertising Web 应用程序中相同的角色和对相同帐户的访问权限。换句话说，Microsoft广告 Web 应用程序中提供的相同帐户和用户角色权限通过 API 以编程方式提供给用户。有关获取访问令牌以代表 Microsoft Advertising 用户进行操作的信息，请参阅使用 OAuth 进行身份验证。

还需要一个唯一标识应用程序的开发人员令牌。获取用于 API 访问的开发人员令牌不会向任何Microsoft广告帐户授予其他权限。开发人员令牌允许以编程方式访问已为用户预配的帐户。有关信息，请参阅获取开发人员令牌。

提示

若要获取访问令牌并使用必应广告 API 进行首次服务调用，请参阅快速入门指南。

必须在每个请求中通过必应广告 API 设置 AuthenticationToken 和 DeveloperToken 标头。下面是对 GetUser 操作的示例调用。

<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>

多用户凭据

可以使用一组Microsoft广告多用户凭据访问跨多个客户（可能具有不同用户角色和权限）的广告客户帐户。

将“多用户”凭据视为“多个用户角色”可能会有所帮助，因为从一个角度来看，你只能使用一个用户名登录，才能访问具有不同权限的多用户客户。一个人的凭据可以具有多个不同的用户角色。例如，多用户凭据授予你对客户 A 和客户 B 的访问权限。但是，客户 A 的查看者用户角色会限制你对属于客户 A 的帐户进行任何更改。但作为客户 B 的超级管理员，你可以完全控制该客户的帐户。

如果已有多个登录凭据集，可以请求支持人员合并到一组凭据。保留合并前每个客户的用户角色和帐户访问权限。另请注意，同一人的凭据可以与单独的用户联系信息集相关联，即每个客户的唯一联系信息。

有关详细信息，请参阅Microsoft广告帮助主题管理用户名以访问多个帐户。

多用户合并

如果已使用多个凭据集（例如两个电子邮件地址）登录，则可以手动预配多用户凭据。请联系支持人员或帐户管理员，将现有用户名合并为单个用户名。另一个选项是从要管理的每个客户向你发送邀请，然后使用要保留的登录凭据接受每个邀请。此选项可通过 Microsoft Advertising Web 应用程序或 SendUserInvitation 服务操作使用。使用现有Microsoft广告凭据接受邀请后，你将拥有“多用户”凭据。

让我们在多用户合并之前考虑以下用户角色和权限。在 Microsoft广告 Web 应用程序中，每个用户必须单独登录，并在每个登录会话期间具有不同的权限。同样，通过 API，每个用户的访问令牌 (请参阅使用 OAuth 进行身份验证) 表示权限仅限于相应用户和角色。

用户	Role	权限
one@contoso.com	查看器	客户 A - 所有帐户
two@contoso.com	超级管理员	客户 B - 所有帐户
three@contoso.com	查看器	客户 C - 帐户 A
four@contoso.com	标准用户	客户 B - 所有帐户

首先请注意，每个客户只能合并一个电子邮件地址，因此在此示例中two@contoso.comfour@contoso.com，和不能合并在一起。现在，让我们看看在下 one@contoso.com合并前三个用户后会发生什么情况。

无论是通过Microsoft广告 Web 应用程序、Microsoft广告编辑器还是 API，用户 four@contoso.com 都没有更改。
用户 one@contoso.com 可以通过Microsoft广告 Web 应用程序和Microsoft广告编辑器登录。合并用户即 two@contoso.com ，不再 three@contoso.com 有权通过Microsoft广告 Web 应用程序或Microsoft广告编辑器登录。以登录时 one@contoso.com，可以将上下文切换到具有之前已分配给 two@contoso.com 和 three@contoso.com的相应用户角色的客户帐户。尽管可以使用一个用户的凭据 () one@contoso.com 访问多个登录的客户，但需要从客户切换到客户来管理与唯一用户角色关联的帐户。客户及其相关帐户保持不变。有关详细信息，请参阅Microsoft广告帮助主题管理用户名以访问多个帐户。
多用户合并后，用户的 one@contoso.com 访问令牌将表示对合并列表的权限， (帐户的超集) 。有效的用户角色将取决于服务请求中指定的客户和帐户标识符。将不再接受和 three@contoso.com 的访问令牌two@contoso.com，例如，将返回错误 120 - UserLoginAccessDenied。

多用户联系人信息

具有多用户凭据的人员由多个 User 对象和相应的用户标识符表示。实际上，同一人的凭据可以与单独的用户联系信息集相关联，即每个客户的唯一联系信息。

即使具有相同的用户标识符， GetUser 响应也会因调用者而异。例如，在合并之前，、 two@contoso.com和 three@contoso.com 的one@contoso.com标识符分别为 123、456 和 789。每个用户标识符有效地将人员映射到特定客户，例如，标识符 123 映射到 one@contoso.com 该用户可以访问的原始客户。在此示例中，我们将 123 称为原始用户标识符。

如果使用的访问 one@contoso.com 令牌调用 GetUser，并且 UserId 为 nil 或 UserId 设置为原始用户标识符 (例如 123) ，则操作将为用户可以访问的所有客户返回 CustomerRole 对象。
如果使用的访问 one@contoso.com 令牌调用 GetUser，并且 UserId 设置为 456 或 789，则操作将仅返回一个将此人映射到特定客户的 CustomerRole 对象。

同一人员的 Name、Lcid、JobTitle 和 ContactInfo 用户设置将自动与用户合并后发生的任何更新同步。 LastModifiedByUserId 和 LastModifiedTime 也会在每个返回的 User 对象之间同步，除非你合并了旧用户名，并且自合并以来未更新任何用户设置。

注意

TimeStamp 不同于 LastModifiedTime。所有 TimeStamp 值对于每个用户都是唯一的，调用 UpdateUser 时，必须包括相应用户的时间戳 (包括地址时间戳) 。

例如，假设在使用和 three@contoso.com合并two@contoso.com之前，你尚未更新用户信息one@contoso.com。合并后和用户设置在合并后更新之前，将继续在每个返回的 User 对象中观察不同的 LastModifiedByUserId 和 LastModifiedTime。

User Id	联系人信息 ID	权限	LastModifiedByUserId
123	234	客户 A - 所有帐户	123
456	567	客户 B - 所有帐户	456
789	890	客户 C - 帐户 A	789

现在，假设在 one@contoso.com 客户 B 的上下文中执行操作并更新其联系信息。更新的联系信息以及相同的 LastModifiedByUserId 和 LastModifiedTime 现在在所有返回的 User 对象之间同步。

User Id	联系人信息 ID	权限	LastModifiedByUserId
123	234	客户 A - 所有帐户	456
456	567	客户 B - 所有帐户	456
789	890	客户 C - 帐户 A	456

帐户层次结构

搜索广告业务通常与以下一个或多个帐户管理模型保持一致。

直接广告客户为其自己的广告活动构建必应广告 API 应用程序，并通过Microsoft直接计费，以获取有效的广告点击次数。
工具提供商为其他公司构建了一个必应广告 API 应用程序来管理其广告活动，并且不会由Microsoft计费。广告客户用户拥有这些帐户，由Microsoft直接收取有效广告点击费用，并可能向工具提供商支付费用。
一家代理为其公司构建了一个必应广告 API 应用程序，用于管理其广告客户的市场活动。代理的客户拥有这些帐户，直接由Microsoft收取有效广告点击费用，并可能向代理支付费用。
聚合器或经销商生成必应广告 API 应用程序来管理其广告客户的市场活动，并直接由Microsoft收取有效实时点击费用。广告客户不注册Microsoft广告凭据，并且可能会向聚合器支付费用。

无论业务模式如何，初始注册和用户角色预配都大致相同。以下各节讨论设置代理和聚合器层次结构所需的其他步骤。

机构层次结构

一家代理为其公司构建了一个必应广告 API 应用程序，用于管理其广告客户的市场活动。客户链接使代理机构能够管理广告客户帐户的部分或所有方面。客户端链接请求可将范围限制为单个客户广告客户帐户或客户下的所有帐户。

注意

在层次结构上下文中，客户也称为“经理帐户”。广告客户帐户称为“帐户”或“广告客户帐户”。

可以链接到代理的客户帐户数量没有设置限制：但是，经理帐户到经理帐户链接仅支持 5 个深度级别。在每个级别 (L1、L2、L3、L4、L5) 经理帐户可以链接到任意数量的经理帐户和广告帐户。有关成为代理机构的详细信息，请参阅帮助文章将客户作为代理管理Microsoft广告或代理合作伙伴资源。

设置层次结构

若要设置层次结构来管理客户帐户，代理必须向客户端发送邀请，然后必须由客户客户中的授权用户接受邀请。若要确定链接是否已存在，请调用 SearchClientLinks 操作并检查任何返回的 ClientLink 的 Status 元素。若要按个人帐户搜索，请将谓词字段设置为 ClientAccountId，并将谓词值设置为要查找的帐户标识符。

注意

只有具有超级管理员或标准凭据的用户才能添加、更新和搜索指向广告客户帐户的客户端链接。只有具有超级管理员凭据的用户才能添加、更新和搜索指向客户的客户端链接。

如果存在状态为 Active、LinkAccepted、LinkInProgress、LinkPending、UnlinkInProgress 或 UnlinkPending 的链接，则代理无法启动重复的客户端链接。

如果指向指定帐户的客户端链接尚不存在，或者现有链接的生命周期已结束，状态为“已过期”、“LinkCanceled”、“LinkDeclined”、“LinkFailed”或“非活动”，则代理可以通过调用 AddClientLinks 操作来启动新的客户端链接邀请。该服务会立即将客户端链接状态转换为 LinkPending。

重要

对于广告客户帐户客户链接，代理必须通过在客户端链接请求中设置 IsBillToClient 元素来指定客户或代理公司是否负责计费。

若要更新客户端链接，需要其 TimeStamp 元素才能进行验证，因此必须首先调用 SearchClientLinks 操作才能获取现有的 ClientLink 对象。然后修改返回的 ClientLink 的 Status 元素，并在后续调用 UpdateClientLinks 操作时包括更新的 ClientLink 对象。

注意

客户端可以通过基于必应广告 API 构建的应用程序，或通过Microsoft广告 Web 应用程序中的 “帐户 & 计费 ”选项卡接受或拒绝。

客户端只能使用 UpdateClientLinks 操作将状态更新为 LinkAccepted 或 LinkDeclined。

如果客户端将状态设置为 LinkDeclined，则客户端链接生命周期结束。无法更新被拒绝的客户端链接，并且必须发送新邀请来管理客户端帐户。
如果客户端将状态设置为 LinkAccepted，则状态将转换为 LinkInProgress。如果链接过程成功，服务会将客户端链接状态更新为“活动”。

例如，如果由于计费转换错误而无法建立链接，则服务会将客户端链接状态更新为 LinkFailed。无法更新失败的客户端链接，并且必须发送新邀请来管理客户端帐户。如果客户端或代理在 30 天内未采取措施，则服务会将状态设置为 LinkExpired，客户端链接生命周期结束。无法更新过期的客户端链接，并且必须发送新邀请来管理客户端帐户。

指向客户端的链接指向

如果客户端链接状态为 LinkPending，则代理可以选择取消先前的链接请求。

如果客户端链接状态为“活动”，则代理可以选择终止与客户端的现有关系。为了启动取消链接过程，代理将客户端链接状态设置为 UnlinkRequested 并调用 UpdateClientLinks 操作。使用 UnlinkRequested 更新状态实际上会将状态设置为 UnlinkInProgress。该服务立即将客户端链接状态转换为“取消链接”，然后等待系统资源继续。状态应快速转换为 UnlinkInProgress。

例如，如果取消链接过程由于计费转换错误而失败，客户端链接将恢复为“活动”状态。如果取消链接过程成功，状态将更新为“非活动”，客户端链接生命周期结束。无法更新非活动客户端链接，并且必须发送新邀请来管理客户端帐户。

从客户端取消链接

有关演示如何添加和更新客户端链接邀请的代码示例，请参阅客户端链接代码示例。

查看层次结构

代理有多个选项可用于查看帐户层次结构。

GetUser 操作返回每个客户和链接帐户的用户角色。客户角色告知可以访问哪些客户，但不总是描述你如何获取访问权限。确定用户角色将在“管理”和“标准”客户端链接之间产生差异。有关客户角色示例，请参阅获取用户角色。
如果已有代理和客户端实体标识符， SearchClientLinks 操作将提供客户端链接的当前状态。例如，可以通过管理客户 ID 和客户端帐户 ID 或客户端客户 ID 进行搜索。
GetLinkedAccountsAndCustomersInfo 操作返回指定客户下的客户和帐户层次结构。

例如，假设在经理帐户 L1 下设置了代理层次结构， (客户 ID 111) 同时包含客户和广告客户帐户客户链接：

在设置层次结构之前，已预配了四个单独的经理帐户。经理帐户 L1 包含广告帐户 1A 和广告帐户 1B。经理帐户 L2 包含广告帐户 2A 和广告帐户 2B。经理帐户 L3 包含 Ad 帐户 3A 和 Ad 帐户 3B。经理帐户 L4 包含 Ad 帐户 4A 和 Ad 帐户 4B。
经理帐户 L1 (客户 ID 111) 链接到经理帐户 L2 (客户 ID 222) 以及管理链接。
经理帐户 L2 (客户 ID 222) 链接到经理帐户 L3 (客户 ID 333) 与标准链接。
经理帐户 L3 (客户 ID 333) 链接到 Ad 帐户 4A (帐户 ID 444111) 帐户级别链接。 Ad 帐户 4A (帐户 ID 444111) 直接位于经理帐户 L4 (客户 ID 444) 下，该 ID 本身未包含在客户级别层次结构中。在此示例中，可以通过经理帐户 L3 (客户 ID 333 444111) 访问 Ad Account 4A (帐户 ID) 即，调用需要客户标识符的服务操作时，必须使用经理帐户 L3 (客户 ID 333) 来访问帐户444111。

有权访问完整层次结构的用户登录到经理帐户 L1 上的Microsoft广告 Web 应用程序， (客户 ID 111) 将有权访问以下帐户视图。

具有层次结构

如果按客户 ID 111 搜索，则 GetLinkedAccountsAndCustomersInfo 响应包括 AccountsInfo 中的 Ad Account 1A 和 Ad Account 1B。有关经理帐户 L2 的信息在 CustomersInfo 中返回。

<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>

同样，如果按客户 ID 222 搜索，则 GetLinkedAccountsAndCustomersInfo 响应包括 AccountsInfo 中的 Ad Account 2A 和 Ad Account 2B。有关经理帐户 L3 的信息在 CustomersInfo 中返回。

<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>

现在，如果按客户 ID 333 搜索，则 GetLinkedAccountsAndCustomersInfo 响应包括 AccountsInfo 中的 Ad Account 3A、Ad Account 3B 和 Ad Account 4A。 CustomersInfo 中未列出任何经理帐户。

<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>

现在，如果按客户 ID 444 搜索，则 GetLinkedAccountsAndCustomersInfo 响应包括 AccountsInfo 中的 Ad Account 4A 和 Ad Account 4B。 CustomersInfo 中未列出任何经理帐户。

<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>

下面是上述示例响应中的一些值得注意的要点：

尽管无论客户 ID 111 还是 222 请求，GetLinkedAccountsAndCustomersInfo 似乎都返回了类似的结构，但存在明显的差异。如方案简介中所述，从经理帐户 L1 到经理帐户 L2 的链接是管理链接，而从经理帐户 L2 到经理帐户 L3 的链接是标准。 GetLinkedAccountsAndCustomersInfo 响应不包括有关链接类型（即“管理”或“标准”）的详细信息。由于链接类型可以根据用户的用户角色进一步优化用户的权限，因此在调用 GetUser 时，它包含在每个 CustomerRole 中。
按客户 ID 333 进行搜索时，Ad 帐户 3A、Ad 帐户 3B 和 Ad 帐户 4A 之间没有明显差异。如方案简介中所述，广告帐户 4A 可通过广告客户帐户客户端链接访问，而其他帐户由经理帐户 L3 直接包含。如果要求确定每个帐户的直接所有者，可以调用其他服务操作，例如 GetAccount 或 SearchAccounts。
在当前层次结构中，Ad 帐户 4B 仅适用于经理帐户 L4 中的用户。可将经理帐户 L3 中的用户预配为访问 3 个帐户，可将经理帐户 L2 中的用户预配为访问 5 个帐户，将经理帐户 L1 中的用户预配为访问 7 个帐户。超级管理员可以选择限制每个用户对可用帐户子集的访问权限。

聚合器层次结构

聚合者角色提供给一组有限的合作伙伴，这些合作伙伴向大量广告商提供搜索营销工具和服务。聚合器角色允许合作伙伴以编程方式创建新的客户帐户。聚合器按发票为其客户产生的所有广告成本计费。广告客户通常不会注册Microsoft广告凭据，并且可能会向聚合器支付费用。

聚合器用户是在主要客户 shell 中预配的。如实体限制中所述，所有广告活动都由客户组织，客户可以拥有一个或多个帐户。每次聚合器用户调用 SignupCustomer 时，都会在新客户中创建新的广告客户帐户。

重要

SignupCustomer 需要聚合器用户角色。如果在预配初始凭据后将超级管理员用户添加到聚合器客户，则默认情况下，用户可以管理聚合器管理的所有客户的数据。用户将无法调用 SignupCustomer，但对市场活动数据具有读取和写入权限。

SignupCustomer 操作需要 Customer 和 AdvertiserAccount 对象。客户对象包括客户名称、客户所在地址、客户经营的市场以及客户参与的行业。尽管可以添加具有相同详细信息的多个客户，但应使用唯一的客户名称，以便用户可以在用户界面中轻松区分客户。帐户对象必须指定帐户的名称;用于结算帐户的货币类型;和付款方式标识符，必须设置为 null。该操作将生成发票帐户，并将付款方式标识符设置为与聚合器的发票关联的标识符。计费汇总到聚合器的付款方式，聚合器将为其管理的客户产生的所有费用开具发票。

若要请求聚合器凭据，请联系指定的帐户管理团队，了解有关获取聚合器角色的详细信息。如果你目前不是聚合器，但想要成为一个聚合者，请转到 Microsoft广告合作伙伴计划欢迎页面。

另请参阅

客户管理服务参考
 必应广告 API Web 服务地址

通过

帐户层次结构和用户权限

用户角色和权限

用户角色

分配用户角色

获取用户角色

多用户凭据的角色示例

帐户层次结构的角色示例

聚合器层次结构的角色示例

访问和开发人员令牌

多用户凭据

多用户合并

多用户联系人信息

帐户层次结构

机构层次结构

设置层次结构

查看层次结构

聚合器层次结构

另请参阅

反馈

其他资源

通过

帐户层次结构和用户权限

用户角色和权限

用户角色

分配用户角色

获取用户角色

新用户的角色示例

多用户凭据的角色示例

帐户层次结构的角色示例

聚合器层次结构的角色示例

访问和开发人员令牌

多用户凭据

多用户合并

多用户联系人信息

帐户层次结构

机构层次结构

设置层次结构

查看层次结构

聚合器层次结构

如何获取聚合器凭据

另请参阅

反馈

其他资源