帳戶階層和用戶權力

發行項
11/13/2024

Microsoft Advertising 用戶可以使用相同的登入認證來存取多個帳戶，可能具有每個帳戶的不同許可權。機構可以設定帳戶階層來管理來自一個父帳戶的所有使用者和帳戶、使用一個中央貨幣包來支付所有專案，以及在客戶之間共用營銷活動資源，例如通用事件追蹤 (UET) 標籤和重新行銷清單。

使用者角色和許可權描述每個使用者角色可用的動作、如何在帳戶上布建使用者、如何探索其目前的訪問許可權，以及如何使用 Bing 廣告 API 代表已驗證的Microsoft Advertising 用戶採取行動。
多使用者認證說明如何使用一組Microsoft廣告認證，跨多個客戶存取廣告客戶帳戶，這些客戶可能具有不同的使用者角色和許可權。如果您已經有多組登入認證，您可以要求支持人員合併成一組認證。
帳戶階層描述如何為客戶中的一或多個使用者提供帳戶階層的存取權。實際上，您可以從一個父帳戶管理所有用戶和帳戶，並使用一個中央貨幣包來支付所有項目的費用。此外，透過階層，您可以在客戶之間共用行銷活動資源，例如通用事件追蹤 (UET) 標籤和重新行銷清單。

注意事項

在階層的內容中，客戶也稱為「管理員帳戶」。 PublisherAccount 稱為「帳戶」或「廣告商帳戶」。

如需帳戶內營銷活動階層的詳細資訊，請參閱實體限制。

使用者角色和許可權

您的應用程式可能只需要在已知帳戶上支援一位超級管理員使用者。即使有這種相對簡單的許可權結構，您還是想要瞭解每個使用者角色可用的動作、如何在帳戶上布建使用者、如何探索其目前的存取權，以及如何使用 Bing 廣告 API 代表已驗證的Microsoft廣告使用者採取行動。

使用者角色

客戶的超級管理員或 Microsoft Advertising 系統管理員所授與的使用者角色會決定服務可用性。例如，具有廣告營銷活動管理員角色的使用者可以新增和更新營銷活動，但無法建立或更新使用者。除非在每個服務作業的參考內容中另有註明，否則下表將概括說明每個使用者角色的服務限制。

注意事項

只有超級管理員和標準用戶可以設定為帳戶的主要聯繫人。如需使用者角色的詳細資訊，請參閱如何讓某人存取我的Microsoft Advertising 帳戶？幫助主題。

使用者角色	可用的服務
廣告營銷活動經理	此角色有權檢視選取的帳戶，以及在選取的帳戶內新增、編輯或刪除活動。廣告營銷活動經理可以檢視付款方式，但無法管理任何帳單和付款工作。所有服務的讀取作業皆可供使用。客戶管理服務的寫入作業通常無法使用。其中一個例外是，「廣告行銷活動管理員」可以使用UpdateAccount作業來更新PublisherAccount的 AutoTagType 元素。
聚合	所有服務的讀取和寫入作業都可供使用，但 DeleteCustomer 除外。
標準使用者	此角色有權管理活動，並在選取的帳戶上執行一些計費活動。此角色無法新增、編輯或刪除付款方式;新增或刪除帳戶。標準使用者可以連結和取消連結廣告客戶帳戶，但無法管理客戶對客戶層級的客戶端連結。標準用戶可以在他們有權存取的帳戶中管理某些使用者。標準使用者可以邀請或刪除其他標準使用者、廣告行銷活動經理和檢視者，以及檢視目前客戶內容中所有使用者的相關信息。不過，標準使用者無法邀請或刪除超級管理員，也無法編輯超級管理員的角色。在擁有未共享物件或 UET 標籤的客戶中，標準使用者可以更新其屬性 (範圍) 例如描述和名稱。共享物件或 UET 標籤時，標準使用者無法更新這些屬性。如需詳細資訊，請參閱共享物件和UET標籤技術指南。所有服務的讀取作業皆可供使用。客戶計費服務和客戶管理服務的寫入作業通常無法使用。標準使用者可用的作業例外是 AddInsertionOrder、 UpdateInsertionOrder 和 UpdateAccount。
超級系統管理員	此角色具有所有帳戶的完整許可權。超級系統管理員可以管理與帳單和付款、帳戶詳細數據和其他使用者相關的一切 (包括其他超級系統管理員) 。超級管理員可以指定其他使用者可以存取的帳戶。註冊為新客戶時，第一個用戶是超級管理員。擁有物件或 UET 標籤之客戶中的超級管理員使用者可以更新物件或 UET 標籤的客戶帳戶共用範圍。階層上層客戶中的超級管理員使用者也可以更新範圍。範圍) 以外的其他物件或 UET 標籤屬性 (，例如描述和名稱只能由擁有物件或 UET 標籤之客戶中的超級管理員使用者更新。階層上層客戶中的超級管理員用戶無法更新這些詳細數據。如需詳細資訊，請參閱共享物件和UET標籤技術指南。所有服務的讀取和寫入作業都可供使用，但 DeleteCustomer 除外
檢視者	此角色具有唯讀許可權。所有服務的讀取作業皆可供使用。

如果 CustomerLinkPermission) 的鏈接權限 (為「標準」，則會限制連結客戶的超級管理員許可權。如果鏈接許可權為「系統管理」，則不會限制其許可權。他們也會保留他們可直接存取之客戶的完整超級管理員許可權，例如註冊的位置。

客戶連結許可權

另請注意，針對指定的 CustomerRole，使用者在 CustomerId、AccountIds 和 LinkedAccountIds 上具有相同角色;不過，如果使用者有多個客戶角色，則有效許可權會視 GetUser 傳回的完整 CustomerRole 物件集合而定。取得使用者角色中提供數個範例。

指派使用者角色

在 Microsoft Advertising Web 應用程式中註冊新帳戶時，您將獲得超級管理員使用者角色。超級管理員可以使用廣告營銷活動管理員、超級管理員、標準或查看器角色來建立新的使用者。匯總工具角色是由系統管理員的特殊要求所布建。如需詳細資訊，請參閱匯總工具階層，並連絡您的帳戶管理員。

技術上無法以程序設計方式建立新使用者;不過，您可以使用 SendUserInvitation 作業來邀請人員在現有的 Microsoft Advertising 帳戶下註冊。當您邀請某人加入某個帳戶或一組帳戶時，您也會設定使用者角色。 Microsoft Advertising 會產生傳送給受邀者的電子郵件邀請。藉由單擊電子郵件連結並完成 Microsoft Advertising 註冊工作流程，他們會接受邀請來管理具有您在 SendUserInvitation 要求中布建之使用者角色的帳戶。

注意事項

註冊新帳戶並接受現有帳戶的邀請時，人員可以使用相同的登入認證。在使用相同的認證來完成註冊工作流程的任一情況下，都會將該人員視為具有多用戶認證。從管理其客戶範圍中使用者的每個超級管理員的觀點來看，使用者的角色、帳戶存取和聯繫人資訊都是唯一的。當使用者在另一個客戶的內容中擁有的任何許可權，在目前客戶的範圍內執行時，並不會納入考慮。

超級系統管理員可以選擇修改其使用者對不同帳戶的存取權，並可能修改使用者角色，例如，從查看器到標準使用者。若要更新使用者的角色，請呼叫 UpdateUserRoles 作業。

取得使用者角色

若要取得可存取客戶一或多個帳戶的使用者清單，請呼叫 GetUsersInfo 作業。此作業會傳回物件的陣列，其中包含每個使用者的電子郵件地址和標識碼中的記錄。然後，您可以取得清單中每個使用者的詳細數據，例如他們在 Microsoft Advertising 中的角色和帳戶許可權，呼叫 GetUser 作業。如果您將 UserId 元素保留為 nil，則呼叫 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、AccountIds 和 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 物件。在此範例中，除了 CustomerId 之外，每個 CustomerRole 內的元素都是相等的。 RoleId 取決於管理員帳戶 L1 的超級管理員 (客戶標識碼 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 中的其中一個超級管理員使用者 (客戶標識符 111) (不論您或另一個超級系統管理員) 在管理員帳戶 L1 下設定代理階層， (客戶標識碼 111) 客戶和用戶端客戶連結：

管理員帳戶 L1 (客戶識別碼 111) 連結至管理員帳戶 L2 (具有系統管理連結的客戶標識碼 222) 。
管理員帳戶 L2 (客戶識別碼 222) 連結至具有標準連結的客戶標識碼 333 (客戶標識碼 333) 。
管理員帳戶 L3 (客戶標識碼 333) 連結至具有帳戶層級連結的廣告帳戶 4A (帳戶標識碼444111) 。廣告帳戶 4A (帳戶標識碼444111) 直接在管理员帐户 L4 (客戶標識碼 444) 底下，這本身不包含在客戶層級階層中。

您仍然可以存取您註冊的原始客戶，也就是 999，而且您仍然是管理員帳戶 L1 (客戶標識碼 111) 的直接使用者。現在 GetUser 作業會傳回另外兩個 CustomerRole 物件，也就是每個物件分別用於管理員帳戶 L2 (客戶識別碼 222) 和管理員帳戶 L3 (客戶標識碼 333) 。您可以存取所有可透過管理員帳戶 L2 存取的 AccountId 和 LinkedAccountId ， (客戶識別碼 222) 和 333。在此範例中，您可以透過管理員帳戶 L3 (客戶識別碼 333) 存取廣告帳戶 4A (帳戶標識碼444111) ，也就是在呼叫需要客戶標識符的服務作業時，您必須使用管理員帳戶 L3 (客戶標識符 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 物件。除了 RoleId 之外，每個 CustomerRole 內的元素都是相等的。匯總工具在 Microsoft Advertising 中有兩個角色識別碼，也就是 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 Advertising 用戶採取行動，您必須取得其同意。在同意工作流程結束時，您可以取得代表使用者的存取令牌。存取令牌的角色和存取權與使用者在 Microsoft Advertising Web 應用程式中擁有的帳戶相同。換句話說，Microsoft Advertising Web 應用程式中可用的相同帳戶和使用者角色許可權，可透過 API 以程式設計方式提供給使用者。如需取得存取令牌以代表 Microsoft Advertising 用戶採取行動的相關信息，請參閱使用 OAuth 進行驗證。

您也需要可唯一識別應用程式的開發人員令牌。取得 API 存取的開發人員令牌不會將額外的許可權授與任何Microsoft Advertising 帳戶。開發人員令牌可讓您以程式設計方式存取已為使用者布建的帳戶。如需詳細資訊，請參閱取得開發人員令牌。

提示

若要取得存取令牌，並使用 Bing 廣告 API 進行您的第一個服務呼叫，請參閱快速入門指南。

您必須在每個要求中透過 Bing 廣告 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 的 Viewer 使用者角色會限制您對屬於客戶 A 的帳戶進行任何變更。但身為客戶 B 的超級管理員，您可以完全控制該客戶的帳戶。

如果您已經有多組登入認證，您可以要求支持人員合併成一組認證。系統會保留您在合併之前透過每個客戶存取的使用者角色和帳戶。另請注意，同一個人的認證可以與個別的用戶聯繫人資訊集相關聯，也就是每個客戶的唯一聯繫人資訊。

如需詳細資訊，請參閱 Microsoft Advertising 幫助主題管理您的使用者名稱以存取多個帳戶。

多用戶匯總

如果您已經使用多組認證登入，例如兩個電子郵件位址，則可以手動布建多用戶認證。請連絡支持人員或您的帳戶管理員，將現有的使用者名稱合併成單一用戶名稱。另一個選項是從您想要管理的每位客戶傳送邀請給您，然後使用您想要保留的登入認證來接受每個邀請。此選項可透過 Microsoft Advertising Web 應用程式或 SendUserInvitation 服務作業取得。一旦您接受具有現有廣告認證Microsoft邀請，您將會有「多用戶」認證。

讓我們先考慮下列使用者角色和許可權，再合併多使用者。在 Microsoft Advertising Web 應用程式中，每個使用者都必須個別登入，並在每個登入會話期間有不同的許可權。同樣地，透過 API，每個使用者的存取令牌 (請參閱使用 OAuth 進行驗證) 代表限於對應使用者和角色的許可權。

使用者	角色	權限
one@contoso.com	檢視者	客戶 A - 所有帳戶
two@contoso.com	超級系統管理員	客戶 B - 所有帳戶
three@contoso.com	檢視者	客戶 C - 帳戶 A
four@contoso.com	標準使用者	客戶 B - 所有帳戶

首先請注意，每個客戶只能合併一個電子郵件位址，因此在此範例 two@contoso.com 中和 four@contoso.com 無法合併在一起。現在讓我們看看在下合併 one@contoso.com前三名用戶之後會發生什麼情況。

不論是透過 Microsoft Advertising Web 應用程式、Microsoft Advertising Editor 或 API，使用者 four@contoso.com 都無任何變更。
用戶 one@contoso.com 可以透過 Microsoft Advertising Web 應用程式和 Microsoft Advertising 編輯器登入。合併的使用者， two@contoso.comthree@contoso.com 也就是，不再具有透過 Microsoft Advertising Web 應用程式或 Microsoft Advertising 編輯器登入的許可權。以身分one@contoso.com登入時，您可以使用先前指派給和three@contoso.com的對應使用者角色，將內容切換至two@contoso.com客戶帳戶。雖然您可以使用一個使用者的認證 () one@contoso.com 存取多個登入的客戶，但您必須從客戶切換到客戶，以管理與唯一使用者角色連結的帳戶。客戶及其相關帳戶會保持相異。如需詳細資訊，請參閱 Microsoft Advertising 幫助主題管理您的使用者名稱以存取多個帳戶。
在多用戶匯總之後，使用者 one@contoso.com 的存取令牌會代表帳戶超集 ( (合併清單的) 許可權。作用中的使用者角色將取決於服務要求中指定的客戶和帳戶標識碼。不再接受和 three@contoso.com 的two@contoso.com存取令牌，也就是錯誤 120 - 會傳回 UserLoginAccessDenied。

多用戶聯繫人資訊

具有多使用者認證的人員會以多個用戶對象和對應的使用者標識元表示。實際上，同一個人的認證可以與個別的用戶聯繫人資訊集相關聯，也就是每個客戶的唯一聯繫人資訊。

GetUser 回應可能會因撥打電話的人員而有所不同，即使具有相同的使用者標識碼也一樣。例如，假設在匯總之前，和 three@contoso.com 的one@contoso.comtwo@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 時，必須包含對應使用者的時間戳 (包括地址時間戳) 。

例如，假設您在使用 two@contoso.com 和three@contoso.com進行合併之前，尚未更新的用戶資訊one@contoso.com。匯總之後，直到使用者設定在匯總後更新為止，您會在每個傳回的 User 物件內繼續觀察不同的 LastModifiedByUserId 和 LastModifiedTime。

使用者識別碼	聯繫人資訊標識碼	權限	LastModifiedByUserId
123	234	客戶 A - 所有帳戶	123
456	567	客戶 B - 所有帳戶	456
789	890	客戶 C - 帳戶 A	789

現在假設這是 one@contoso.com 在客戶 B 的內容中執行，並更新其連絡資訊。更新的連絡資訊以及相同的 LastModifiedByUserId 和 LastModifiedTime 現在會同步處理所有傳回的 User 物件。

使用者識別碼	聯繫人資訊標識碼	權限	LastModifiedByUserId
123	234	客戶 A - 所有帳戶	456
456	567	客戶 B - 所有帳戶	456
789	890	客戶 C - 帳戶 A	456

帳戶階層

搜尋廣告業務通常會與下列一或多個帳戶管理模型一致。

直接廣告商會為自己的廣告營銷活動建置 Bing 廣告 API 應用程式，並由Microsoft直接收取有效的廣告點選費用。
工具提供者會為其他公司建置 Bing 廣告 API 應用程式來管理其廣告營銷活動，而不會由Microsoft計費。廣告使用者擁有帳戶、由Microsoft直接收取有效的廣告點擊費用，而且可能會向工具提供者支付費用。
某家機構為其公司建置 Bing 廣告 API 應用程式，以管理其廣告客戶的活動。代理商的用戶端擁有帳戶、由Microsoft直接收取有效的廣告點選費用，而且可能會向代理商支付費用。
匯總者或轉銷商會建置 Bing 廣告 API 應用程式來管理其廣告用戶端的活動，並由Microsoft直接收取有效的即時點擊費用。廣告商不會註冊 Microsoft Advertising 認證，而且可能會向匯總者支付費用。

不論商務模型為何，初始註冊和使用者角色布建都大致相同。下列各節討論設定機構和匯總工具階層所需的其他步驟。

機構階層

某家機構為其公司建置 Bing 廣告 API 應用程式，以管理其廣告客戶的活動。用戶端連結可讓機構管理廣告商帳戶的部分或所有層面。用戶端連結要求可以將範圍限制為個別用戶端客戶端帳戶或客戶下的所有帳戶。

注意事項

在階層的內容中，客戶也稱為「管理員帳戶」。 PublisherAccount 稱為「帳戶」或「廣告商帳戶」。

可以連結至代理商的用戶端帳戶數量沒有設定的限制;不過，管理員帳戶與管理員帳戶連結只支援5個深度層級。在每個層級 (L1、L2、L3、L4、L5) 管理員帳戶可以連結到任意數目的管理員帳戶和廣告帳戶。如需成為代理商的詳細資訊，請參閱為代理商合作夥伴管理用戶端做為Microsoft廣告或資源的代理商一文。

設定階層

若要設定階層來管理客戶端帳戶，代理商必須傳送邀請給用戶端，客戶客戶中的授權用戶必須接受該用戶端。若要判斷連結是否已經存在，請呼叫 SearchClientLinks 作業，並檢查任何傳回之 ClientLink 的 Status 元素。若要依個別帳戶搜尋，請將述詞字段設定為 ClientAccountId，並將述詞值設定為您想要尋找的帳戶標識碼。

注意事項

只有具有超級管理員或標準認證的使用者可以新增、更新及搜尋廣告客戶帳戶的客戶端連結。只有具有超級管理員認證的使用者可以新增、更新及搜尋客戶端連結。

如果存在狀態為 Active、LinkAccepted、LinkInProgress、LinkPending、UnlinkInProgress 或 UnlinkPending 的連結，代理程式就無法起始重複的客戶端連結。

如果指定帳戶的客戶端連結不存在，或現有連結的生命週期已結束，狀態為 Expired、LinkCanceled、LinkDeclined、LinkFailed 或 Inactive，則代理程式可以呼叫 AddClientLinks 作業來起始新的用戶端連結邀請。服務會立即將客戶端連結狀態轉換為 LinkPending。

重要事項

針對廣告用戶端連結，代理商必須在用戶端連結要求中設定 IsBillToClient 元素，以指定用戶端或代理商是否要負責計費。

若要更新用戶端連結，必須要有 TimeStamp 元素才能進行驗證，因此您必須先呼叫 SearchClientLinks 作業來取得現有的 ClientLink 物件。然後修改所傳回 ClientLink 的 Status 元素，並在 UpdateClientLinks 作業的後續呼叫中包含已更新的 ClientLink 物件。

注意事項

用戶端可以透過以 Bing 廣告 API 為基礎的應用程式，或透過 Microsoft Advertising Web 應用程式中的 [帳戶 & 帳單 ] 索引卷標來接受或拒絕。

用戶端只能使用 UpdateClientLinks 作業，將狀態更新為 LinkAccepted 或 LinkDeclined。

如果客戶端將狀態設定為 LinkDeclined，客戶端連結生命週期就會結束。您無法更新拒絕的用戶端連結，而且必須傳送新的邀請來管理客戶端帳戶。
如果客戶端將狀態設定為 LinkAccepted，狀態會轉換為 LinkInProgress。如果鏈接程式成功，服務會將用戶端鏈接狀態更新為 [作用中]。

例如，如果因為帳單轉換錯誤而無法建立連結，服務會將用戶端鏈接狀態更新為 LinkFailed。您無法更新失敗的客戶端連結，而且必須傳送新的邀請來管理客戶端帳戶。如果用戶端或代理商未在 30 天內採取動作，服務會將狀態設定為 LinkExpired，且客戶端連結生命週期結束。您無法更新過期的用戶端連結，而且必須傳送新的邀請來管理客戶端帳戶。

用戶端

如果客戶端連結狀態為 LinkPending，則代理程式可以選擇取消先前的連結要求。

如果客戶端連結狀態為 [作用中]，則代理程式可以選擇終止與客戶端的現有關聯性。若要起始取消連結程式，代理程式會將用戶端鏈接狀態設定為 UnlinkRequested，並呼叫 UpdateClientLinks 作業。使用 UnlinkRequested 更新狀態可有效地將狀態設定為 UnlinkInProgress。服務會立即將用戶端鏈接狀態轉換為 UnlinkPending，然後等候系統資源繼續進行。狀態應該會快速轉換為 UnlinkInProgress。

例如，如果取消連結程式因為帳單轉換錯誤而失敗，則用戶端鏈接會繼續為作用中狀態。如果取消連結程式成功，狀態將會更新為 [非使用中]，而用戶端連結生命週期會結束。您無法更新非使用中的用戶端連結，而且必須傳送新的邀請來管理客戶端帳戶。

從用戶端取消連結從客戶端

如需示範如何新增和更新用戶端連結邀請的程式碼範例，請參閱用戶端連結程式碼範例。

檢視階層

機構有數個選項可檢視帳戶階層。

GetUser 作業會傳回每個客戶和鏈接帳戶的使用者角色。客戶角色會通知您可以存取哪些客戶，但不一定會描述您取得存取權的方式。判斷使用者角色會在系統管理與標準用戶端連結之間產生差異。如需客戶角色範例，請參閱取得使用者角色。
如果您已經有代理程式和用戶端實體標識碼， SearchClientLinks 作業會提供用戶端連結的目前狀態。例如，您可以藉由管理客戶標識碼和用戶端帳戶標識碼或客戶識別碼來搜尋。
GetLinkedAccountsAndCustomersInfo 作業會傳回指定客戶下的客戶和帳戶階層。

例如，假設在 [管理員帳戶 L1] 下設定代理程序階層， (客戶標識碼 111) 客戶和廣告用戶端連結：

在設定階層之前，已布建四個不同的管理員帳戶。管理員帳戶 L1 包含廣告帳戶 1A 和廣告帳戶 1B。管理員帳戶 L2 包含廣告帳戶 2A 和廣告帳戶 2B。管理員帳戶 L3 包含廣告帳戶 3A 和廣告帳戶 3B。管理員帳戶 L4 包含廣告帳戶 4A 和廣告帳戶 4B。
管理員帳戶 L1 (客戶識別碼 111) 連結至管理員帳戶 L2 (具有系統管理連結的客戶標識碼 222) 。
管理員帳戶 L2 (客戶識別碼 222) 連結至具有標準連結的客戶標識碼 333 (客戶標識碼 333) 。
管理員帳戶 L3 (客戶標識碼 333) 連結至具有帳戶層級連結的廣告帳戶 4A (帳戶標識碼444111) 。廣告帳戶 4A (帳戶標識碼444111) 直接在管理员帐户 L4 (客戶標識碼 444) 底下，這本身不包含在客戶層級階層中。在此範例中，您可以透過管理員帳戶 L3 (客戶識別碼 333) 存取廣告帳戶 4A (帳戶標識碼444111) ，也就是在呼叫需要客戶標識符的服務作業時，您必須使用管理員帳戶 L3 (客戶標識符 333) 來存取帳戶444111。

具有完整階層存取權的使用者，如果登入 Microsoft Advertising Web 應用程式的管理員帳戶 L1 (客戶標識碼 111) 即可存取下列帳戶檢視。

具有階層管理員帳戶的管理員帳戶

如果您依客戶標識碼 111 搜尋，GetLinkedAccountsAndCustomersInfo 回應會在 AccountsInfo 中包含廣告帳戶 1A 和廣告帳戶 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>

同樣地，如果您依客戶標識碼 222 搜尋，GetLinkedAccountsAndCustomersInfo 回應會在 AccountsInfo 中包含 Ad 帳戶 2A 和廣告帳戶 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>

現在，如果您依客戶標識碼 333 搜尋，GetLinkedAccountsAndCustomersInfo 回應會在 AccountsInfo 中包含廣告帳戶 3A、廣告帳戶 3B 和廣告帳戶 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>

現在，如果您以客戶標識碼 444 搜尋，GetLinkedAccountsAndCustomersInfo 回應會在 AccountsInfo 中包含 Ad 帳戶 4A 和廣告帳戶 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>

以下是上述範例回應中值得注意的一些重點：

雖然 GetLinkedAccountsAndCustomersInfo 似乎會傳回類似的結構，無論客戶標識碼 111 或 222 要求，還是有顯著的差異。如案例中所述，從 Mananger 帳戶 L1 到管理員帳戶 L2 的連結是系統管理連結，而從管理員帳戶 L2 到管理員帳戶 L3 的連結是標準的。 GetLinkedAccountsAndCustomersInfo 回應不包含連結類型的詳細數據，例如系統管理或標準。因為連結類型可以根據使用者角色進一步精簡用戶的許可權，所以當您呼叫 GetUser 時，它會隨附於每個 CustomerRole。
依客戶標識碼 333 搜尋時，廣告帳戶 3A、廣告帳戶 3B 和廣告帳戶 4A 之間沒有明顯的差異。如案例中所述，Ad 帳戶 4A 簡介可透過廣告用戶端連結存取，而其他帳戶則由管理員帳戶 L3 直接包含。如果您需要判斷每個帳戶的直接擁有者，您可以呼叫其他服務作業，例如 GetAccount 或 SearchAccounts。
在目前的階層中，Ad 帳戶 4B 僅適用於管理員帳戶 L4 中的使用者。您可以布建管理員帳戶 L3 中的用戶來存取 3 個帳戶、將管理員帳戶 L2 中的使用者布建為存取 5 個帳戶，而管理員帳戶 L1 中的使用者則可布建以存取 7 個帳戶。超級系統管理員可以選擇限制每個使用者對可用帳戶子集的存取權。

匯總工具階層

匯總工具角色會提供給一組有限的合作夥伴，為大量廣告商提供搜尋行銷工具和服務。匯總工具角色可讓合作夥伴以程序設計方式建立新的客戶帳戶。匯總工具會依據其用戶端所產生的所有廣告成本，按發票計費。廣告商通常不會註冊 Microsoft Advertising 認證，而且可能會向匯總者支付費用。

匯總工具用戶會布建在主要客戶殼層中。如實體限制中所述，所有廣告活動都是由客戶組織，其中可以有一或多個帳戶。每當匯總工具使用者呼叫 SignupCustomer 時，就會在新客戶內建立新的廣告商帳戶。

重要事項

SignupCustomer 需要匯總工具使用者角色。如果在布建初始認證之後，將超級管理員使用者新增至匯總工具客戶，則根據預設，使用者可以管理匯總工具所管理之所有客戶的數據。使用者將無法呼叫 SignupCustomer，但將擁有行銷活動數據的讀取和寫入存取權。

SignupCustomer 作業需要 Customer 和 InsightAccount 物件。客戶物件包含客戶的名稱、客戶所在的地址、客戶所在的市場，以及客戶參與的產業。雖然可以新增具有相同詳細數據的多個客戶，但您應該使用唯一的客戶名稱，讓使用者可以輕鬆地區分使用者介面中的客戶。帳戶物件必須指定帳戶的名稱;用來結算帳戶的貨幣類型;和付款方式標識碼，必須設定為 null。作業會產生發票帳戶，並將付款方式標識符設定為與匯總工具發票相關聯的標識碼。計費會匯總到匯總者的付款方式，而匯總工具會針對其管理的客戶所產生的所有費用開立發票。

若要要求匯總工具認證，請連絡您指定的帳戶管理小組，以取得有關取得匯總工具角色的詳細數據。如果您目前不是匯總工具，但想要成為匯總工具，請移至 Microsoft Advertising Partner 計劃歡迎頁面。

另請參閱

客戶管理服務參考
 Bing 廣告 API Web 服務位址

共用方式為

帳戶階層和用戶權力

使用者角色和許可權

使用者角色

指派使用者角色

取得使用者角色

多用戶認證的角色範例

帳戶階層的角色範例

匯總工具階層的角色範例

存取和開發人員令牌

多用戶認證

多用戶匯總

多用戶聯繫人資訊

帳戶階層

機構階層

設定階層

檢視階層

匯總工具階層

另請參閱

意見反應

其他資源

共用方式為

帳戶階層和用戶權力

使用者角色和許可權

使用者角色

指派使用者角色

取得使用者角色

新使用者的角色範例

多用戶認證的角色範例

帳戶階層的角色範例

匯總工具階層的角色範例

存取和開發人員令牌

多用戶認證

多用戶匯總

多用戶聯繫人資訊

帳戶階層

機構階層

設定階層

檢視階層

匯總工具階層

如何取得匯總工具認證

另請參閱

意見反應

其他資源