アカウントの階層とユーザーのアクセス許可

Microsoft Advertising ユーザーは、同じログイン資格情報を使用して複数のアカウントにアクセスできます。場合によっては、各アカウントに対して異なるアクセス許可を持つ可能性があります。 ある機関は、アカウントの階層を設定して、1 つの親アカウントからすべてのユーザーとアカウントを管理し、1 つの中央ウォレットを使用してすべてを支払い、 ユニバーサル イベント追跡 (UET) タグやリマーケティング リストなどのキャンペーン リソースを顧客間で共有できます。

• ユーザー ロールとアクセス許可 には、各 ユーザー ロールで使用できるアクション、アカウントで ユーザーをプロビジョニング する方法、 現在のアクセス権を検出する方法、および Bing Ads API を使用して 認証された Microsoft Advertising ユーザーに代わって行動 する方法が記述されています。
• マルチユーザー資格情報 では、1 つの Microsoft Advertising 資格情報セットを使用して、複数の顧客間の広告主アカウントにアクセスする方法について説明します。ユーザー ロールとアクセス許可が異なる可能性があります。 ログイン資格情報のセットが既に複数ある場合は、1 つの資格情報セットに 統合 するようにサポートに依頼できます。
• アカウント階層 では、顧客内の 1 人以上のユーザーに対してアカウントの階層へのアクセスを提供する方法について説明します。 効果的に、1 つの親アカウントからすべてのユーザーとアカウントを管理し、1 つの中央ウォレットを使用してすべてを支払うことができます。 階層を使用して、 ユニバーサル イベント トラッキング (UET) タグやリマーケティング リストなどのキャンペーン リソースを顧客間で共有することもできます。

アカウント内のキャンペーン階層の詳細については、「 エンティティの制限」 を参照してください。

ユーザー ロールとアクセス許可

アプリケーションでは、既知のアカウントで 1 人のスーパー管理者ユーザーのみをサポートする必要がある場合があります。 このような比較的単純なアクセス許可構造を使用する場合でも、 各ユーザー ロールで使用できるアクション、アカウントで ユーザーをプロビジョニング する方法、 現在のアクセス権を検出する方法、Bing Ads API を使用して 認証された Microsoft Advertising ユーザーに代わって行動 する方法を理解する必要があります。

ユーザー ロール

顧客のスーパー管理者または Microsoft Advertising システム管理者によって付与されたユーザー ロールによって、サービスの可用性が決定されます。 たとえば、広告主キャンペーン マネージャーロールを持つユーザーはキャンペーンを追加および更新できますが、ユーザーを作成または更新することはできません。 サービス操作ごとの参照コンテンツに特に記載がない限り、次の表では、ユーザー ロールごとのサービス制限について大まかに説明します。

リンクされた顧客に対するスーパー管理者のアクセス許可は、リンクアクセス許可 (CustomerLinkPermission) が "Standard" である場合に制限されます。 リンクのアクセス許可が "管理" の場合、アクセス許可は制限されません。 また、直接アクセスできる顧客に対する完全なスーパー管理者アクセス許可 (サインアップ場所など) も保持されます。

また、個別に取得したユーザーは、特定の CustomerRole の CustomerId、AccountId、LinkedAccountIds に対して同じロールを持ちます。ただし、ユーザーに複数の顧客ロールがある場合、有効なアクセス許可は、GetUser によって返される CustomerRole オブジェクトの完全なセットに依存します。 [ ユーザー ロールの取得] には、いくつかの例が示されています。

ユーザー ロールの割り当て

Microsoft Advertising Web アプリケーションで新しいアカウントにサインアップすると、スーパー管理者 ユーザー ロールが付与されます。 スーパー管理者は、広告主キャンペーン マネージャー、スーパー管理者、Standard、またはビューアーロールを使用して新しいユーザーを作成できます。 アグリゲーター ロールは、システム管理者による特別な要求によってプロビジョニングされます。 詳細については、「 アグリゲーター階層 」を参照し、アカウント マネージャーにお問い合わせください。

技術的に新しいユーザーをプログラムで作成することはできません。ただし、 SendUserInvitation 操作を使用して、既存の Microsoft Advertising アカウントでサインアップするようにユーザーを招待できます。 ユーザーをアカウントまたはアカウントのセットに招待すると、 ユーザー ロールも設定されます。 Microsoft Advertising では、招待者に送信される電子メールの招待が生成されます。 電子メールで送信されたリンクをクリックし、Microsoft Advertising サインアップ ワークフローを完了すると、 SendUserInvitation 要求でプロビジョニングしたユーザー ロールを持つアカウントを管理するための招待を受け入れます。

スーパー管理者は、ユーザーの異なるアカウントへのアクセスを変更し、ユーザー ロール (ビューアーから Standard ユーザー など) を変更するオプションがあります。 ユーザーのロールを更新するには、 UpdateUserRoles 操作を呼び出します。

ユーザー ロールを取得する

顧客の 1 つ以上のアカウントにアクセスできるユーザーの一覧を取得するには、 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、AccountId、LinkedAccountIds で同じロールを持ちます。ただし、ユーザーに複数の顧客ロールがある場合、有効なアクセス許可は、GetUser によって返される CustomerRole オブジェクトの完全なセットに依存します。 いくつかの例を以下に示します。

新しいユーザーのロールの例

Microsoft Advertising で初めてサインアップし、新しいアカウントを作成した場合、 GetUser 操作は 1 つの 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 操作は、2 つの CustomerRole オブジェクトを 返します。 この例では、CustomerId を除き、各 CustomerRole 内の要素は同等です。 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>

アカウント階層のロールの例

複数ユーザー資格情報のロールの例 (ただし、階層を構築するためにマルチユーザー資格情報は必要ありません) に基づいて、たとえば、Manager アカウント L1 のスーパー管理者ユーザー (ユーザー ID 111) の 1 人 (ユーザーまたは別のスーパー管理者) が、顧客と広告主アカウントの両方のクライアント リンクを持つマネージャー アカウント L1 (顧客 ID 111) の下に機関 Hierachy を設定するとします。

• Manager アカウント L1 (顧客 ID 111) は、管理者リンクを含む Manager アカウント L2 (顧客 ID 222) にリンクします。
• Manager アカウント L2 (顧客 ID 222) は、標準リンクを使用して Manager アカウント L3 (顧客 ID 333) にリンクします。
• Manager アカウント L3 (顧客 ID 333) は、アカウント レベルのリンクを含む広告アカウント 4A (アカウント ID 444111) にリンクします。 広告アカウント 4A (アカウント ID 444111) は、MCC アカウント L4 (顧客 ID 444) のすぐ下にあります。これは、それ自体が顧客レベル階層に含まれていません。

サインアップした元の顧客 (999) に引き続きアクセスでき、MCC アカウント L1 (顧客 ID 111) の直接ユーザーです。 GetUser 操作では、2 つの追加の CustomerRole オブジェクト 、つまり、それぞれ Manager アカウント L2 (顧客 ID 222) とマネージャー アカウント L3 (顧客 ID 333) が返されます。 Manager アカウント L2 (顧客 ID 222) と 333 からアクセスできる AccountId と LinkedAccountId にそれぞれアクセスできます。 この例では、Manager アカウント L3 (顧客 ID 333) を介して Ad アカウント 4A (アカウント ID 444111) にアクセスできます。つまり、顧客 ID を必要とするサービス操作を呼び出す場合は、アカウント 444111にアクセスするために Manager アカウント L3 (顧客 ID 333) を使用する必要があります。

<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 を使用して 1 つの新しい顧客と広告主アカウントを作成した場合、 GetUser 操作は 2 つの CustomerRole オブジェクトを 返します。 各 CustomerRole 内の要素は、 RoleId を除いて同等です。 アグリゲーターには、Microsoft Advertising の 2 つのロール識別子 (41 と 33) があります。

• CustomerRole オブジェクトの 1 つの RoleId は、新しいアカウントの最初のユーザーにスーパー管理者ユーザー ロールがあるため、41 です。 CustomerRole オブジェクトの別の RoleId は、アグリゲーター ユーザー ロールを表す 33 です。
• CustomerId は、サインアップ時にプロビジョニングされた顧客識別子です。
• AccountIds 要素は空です。これは、スーパー管理者が CustomerId 識別子を持つ顧客のすべての広告主アカウントに常にアクセスできるためです。
• LinkedAccountIds 要素には、SignupCustomer を使用して作成した子顧客の広告主アカウントの identifer が含まれています。 子顧客識別子は 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 アカウントに追加のアクセス許可は付与されません。 開発者トークンを使用すると、ユーザー用に既にプロビジョニングされているアカウントにプログラムでアクセスできます。 詳細については、「 開発者トークンを取得する」を参照してください。

AuthenticationToken ヘッダーと DeveloperToken ヘッダーは、Bing Ads API を介してすべての要求で設定する必要があります。 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>

マルチユーザー資格情報

1 つの Microsoft Advertising マルチユーザー資格情報セットを使用して、複数の顧客間の広告主アカウントにアクセスできます。ユーザー ロールとアクセス許可が異なる可能性があります。

"マルチユーザー" 資格情報は"複数のユーザー ロール" を意味すると考えるのに役立つ場合があります。1 つの観点からは、さまざまなアクセス許可を持つマルチペ顧客にアクセスするには 1 人のユーザー名でログインするだけで済むためです。 1 人のユーザーの資格情報は、複数の個別のユーザー ロールで動作できます。 たとえば、マルチユーザー資格情報を使用すると、顧客 A と顧客 B へのアクセスが許可されます。ただし、顧客 A の閲覧者ユーザー ロールは、顧客 A に属するアカウントに対して変更を加えるのを制限します。ただし、顧客 B のスーパー管理者は、その顧客のアカウントを完全に制御できます。

ログイン資格情報のセットが既に複数ある場合は、1 つの資格情報セットに 統合 するようにサポートに依頼できます。 統合前に持っていた各顧客を通じたユーザー ロールとアカウント アクセスは保持されます。 また、同じユーザーの資格情報を、個別のユーザー連絡先情報 (顧客ごとの一意の 連絡先情報 ) に関連付けることができます。

詳細については、Microsoft Advertising のヘルプ トピック「 複数のアカウントにアクセスするためのユーザー名の管理」を参照してください。

マルチユーザー統合

複数の資格情報セットで既にログインしている場合 (たとえば、2 つのメール アドレス)、マルチユーザー資格情報を手動でプロビジョニングできます。 既存のユーザー名を 1 つのユーザー名にマージするには、サポートまたはアカウント マネージャーに問い合わせてください。 もう 1 つのオプションは、管理する各顧客から招待を送信し、保持するログイン資格情報を使用して各招待を承諾することです。 このオプションは、Microsoft Advertising Web アプリケーションまたは SendUserInvitation サービス操作を通じて使用できます。 既存の Microsoft Advertising 資格情報を使用して招待を承諾すると、"マルチユーザー" の資格情報が得られます。

マルチユーザー統合の前に、次のユーザー ロールとアクセス許可について考えてみましょう。 Microsoft Advertising Web アプリケーションでは、各ユーザーは個別にログインする必要があり、ログイン セッションごとに異なるアクセス許可を持っている必要があります。 同様に、API を介した各ユーザーのアクセス トークン ( 「OAuth による認証」を参照) は、対応するユーザーとロールに制限されたアクセス許可を表します。

最初に、顧客ごとに 1 つのメール アドレスのみを統合できることに注意してください。そのため、この例では、 two@contoso.com と four@contoso.com を一緒に統合することはできません。 次に、上位 3 人のユーザーが one@contoso.com で統合された後の動作を見てみましょう。

• Microsoft Advertising Web アプリケーション、Microsoft Advertising Editor、API のいずれを使用しても、ユーザーの four@contoso.com は変更されません。
• ユーザー one@contoso.com は、Microsoft Advertising Web アプリケーションと Microsoft Advertising Editor を使用してログインできます。 統合されたユーザー( two@contoso.com と three@contoso.com は、Microsoft Advertising Web アプリケーションまたは Microsoft Advertising Editor を使用してサインインするためのアクセス許可を持たなくなりました。 one@contoso.comとしてサインインしているときに、以前にtwo@contoso.comとthree@contoso.comに割り当てられていた対応するユーザー ロールを持つ顧客アカウントにコンテキストを切り替えることができます。 1 人のユーザーの資格情報 (one@contoso.com) でサインインしている複数の顧客にアクセスできますが、一意のユーザー ロールにリンクされているアカウントを管理するには、顧客から顧客に切り替える必要があります。 顧客とその関連アカウントは引き続き異なります。 詳細については、Microsoft Advertising のヘルプ トピック「 複数のアカウントにアクセスするためのユーザー名の管理」を参照してください。
• マルチユーザー統合後、ユーザー one@contoso.com のアクセス トークンは、アカウントの統合リスト (スーパーセット) へのアクセス許可を表します。 有効なユーザー ロールは、サービス要求で指定された顧客とアカウントの識別子によって異なります。 two@contoso.comとthree@contoso.comのアクセス トークンは受け入れられなくなります。つまり、エラー 120 - UserLoginAccessDenied が返されます。

複数ユーザーの連絡先情報

マルチユーザー資格情報を持つユーザーは、複数の ユーザー オブジェクトと対応するユーザー識別子で表されます。 実際には、同じユーザーの資格情報を個別のユーザー連絡先情報 (顧客ごとの一意の連絡先情報) に関連付けることができます。

GetUser 応答は、同じユーザー識別子を持つ場合でも、呼び出しを行うユーザーによって異なる場合があります。 たとえば、統合する前に、 one@contoso.com、 two@contoso.com、 three@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 オブジェクトの 1 つだけです。

同じユーザーの名前、Lcid、JobTitle、ContactInfo の各ユーザー設定は、ユーザー統合後に発生した更新プログラムと自動的に同期されます。 LastModifiedByUserId と LastModifiedTime は、古いユーザー名をマージし、統合以降にユーザー設定を更新していない限り、返された各 User オブジェクト間でも同期されます。

たとえば、two@contoso.comとthree@contoso.comを統合する前から、one@contoso.comのユーザー情報を更新していないとします。 統合後、およびユーザー設定が統合後に更新されるまで、返された各 User オブジェクト内で個別の LastModifiedByUserId と LastModifiedTime が表示されます。

次に、 one@contoso.com が顧客 B のコンテキストで動作し、連絡先情報を更新しているとします。 更新された連絡先情報と同じ LastModifiedByUserId と LastModifiedTime が、返されたすべての User オブジェクト間で同期されるようになりました。

アカウント階層

通常、検索広告ビジネスは、次のアカウント管理モデルの 1 つ以上と一致します。

• 直接広告主は、独自の広告キャンペーン用のBing広告 API アプリケーションを構築し、有効な広告クリックに対して Microsoft から直接請求されます。
• ツール プロバイダーは、他の企業が広告キャンペーンを管理するためのBing広告 API アプリケーションを構築し、Microsoft から課金されません。 広告主ユーザーはアカウントを所有しており、有効な広告クリックに対して Microsoft によって直接請求され、ツール プロバイダーに料金を支払う場合があります。
• ある代理店は、広告クライアントのキャンペーンを管理するために、会社のBing広告 API アプリケーションを構築します。 代理店のクライアントがアカウントを所有し、有効な広告クリックに対して Microsoft によって直接請求され、代理店に料金を支払う場合があります。
• アグリゲーターまたはリセラーは、広告クライアントのキャンペーンを管理するためのBing広告 API アプリケーションを構築し、有効なライブ クリックに対して Microsoft から直接請求されます。 広告主は Microsoft Advertising の資格情報にサインアップせず、アグリゲーターに料金を支払う場合があります。

ビジネス モデルに関係なく、初期サインアップと ユーザー ロール のプロビジョニングは多かれ少なかれ同じです。 以下のセクションでは、 エージェンシー と アグリゲーター の階層を設定するために必要な追加の手順について説明します。

エージェンシー階層

ある代理店は、広告クライアントのキャンペーンを管理するために、会社のBing広告 API アプリケーションを構築します。 クライアント リンクを使用すると、代理店は広告主アカウントの一部またはすべての側面を管理できます。 クライアント リンク要求では、対象範囲を個々のクライアント広告主アカウントまたは顧客のすべてのアカウントに制限できます。

代理店にリンクできるクライアント アカウントの量に制限はありません。ただし、マネージャー アカウントからマネージャー アカウントへのリンクでは、5 レベルの深さのみがサポートされています。 各レベル (L1、L2、L3、L4、L5) では、マネージャー アカウントが任意の数のマネージャー アカウントと広告アカウントにリンクできます。 代理店になる方法の詳細については、Microsoft 広告または代理店パートナー向けリソースに関する代理店としてのクライアントの管理に関するヘルプ記事を参照してください。

階層の設定

クライアント アカウントを管理するための階層を設定するには、機関がクライアントに招待を送信する必要があります。その後、クライアント顧客の承認されたユーザーが受け入れる必要があります。 リンクが既に存在するかどうかを判断するには、 SearchClientLinks 操作を呼び出し、返された ClientLink の Status 要素を確認します。 個々のアカウントで検索するには、述語フィールドを ClientAccountId に設定し、述語値を検索するアカウント識別子に設定します。

Active、LinkAccepted、LinkInProgress、LinkPending、UnlinkInProgress、または UnlinkPending のいずれかの状態のリンクが存在する場合、機関は重複するクライアント リンクを開始できません。

指定したアカウントへのクライアント リンクがまだ存在しない場合、または既存のリンクのライフサイクルが [期限切れ]、[LinkCanceled]、[LinkDeclined]、[LinkFailed]、または [非アクティブ] の状態で終了した場合、機関は AddClientLinks 操作を呼び出して新しいクライアント リンクの招待を開始できます。 サービスは、クライアント リンクの状態を直ちに LinkPending に切り替えます。

クライアント リンクを更新するには、検証に TimeStamp 要素が必要であるため、まず SearchClientLinks 操作を呼び出して既存 の ClientLink オブジェクトを取得する必要があります。 次に、返された ClientLink の Status 要素を変更し、UpdateClientLinks 操作の後続の呼び出しに更新された ClientLink オブジェクトを含めます。

クライアントは UpdateClientLinks 操作のみを使用して、状態を LinkAccepted または LinkDeclined として更新できます。

• クライアントが状態を LinkDeclined に設定すると、クライアント リンク ライフサイクルは終了します。 拒否されたクライアント リンクを更新することはできません。また、クライアント アカウントを管理するための新しい招待を送信する必要があります。
• クライアントが状態を LinkAccepted に設定すると、状態は LinkInProgress に遷移します。 リンク プロセスが成功すると、サービスはクライアント リンクの状態を [アクティブ] に更新します。

たとえば、課金切り替えエラーが原因でリンクを確立できない場合、サービスはクライアント リンクの状態を LinkFailed に更新します。 失敗したクライアント リンクを更新することはできません。クライアント アカウントを管理するには、新しい招待を送信する必要があります。 クライアントまたはエージェンシーが 30 日以内にアクションを実行しない場合、サービスは状態を LinkExpired に設定し、クライアント リンクライフサイクルが終了します。 期限切れのクライアント リンクを更新することはできません。クライアント アカウントを管理するには、新しい招待を送信する必要があります。

クライアント リンクの状態が LinkPending の場合、エージェンシーは以前のリンク要求を取り消すことができます。

クライアント リンクの状態が [アクティブ] の場合、エージェンシーはクライアントとの既存の関係を終了することを選択できます。 リンク解除プロセスを開始するために、エージェンシーはクライアント リンクの状態を UnlinkRequested に設定し、 UpdateClientLinks 操作を呼び出します。 UnlinkRequested で状態を更新すると、実質的に状態が UnlinkInProgress に設定されます。 サービスは、クライアント リンクの状態を直ちに UnlinkPending に切り替え、システム リソースの続行を待機します。 状態はすぐに UnlinkInProgress に移行する必要があります。

たとえば、課金切り替えエラーが原因でリンク解除プロセスが失敗した場合、クライアント リンクはアクティブ状態に再開されます。 リンク解除プロセスが成功した場合、状態は非アクティブに更新され、クライアント リンク ライフサイクルは終了します。 非アクティブなクライアント リンクを更新することはできません。クライアント アカウントを管理するには、新しい招待を送信する必要があります。

クライアント リンクの招待を追加および更新する方法を示すコード例については、「 クライアント リンクのコード例」を参照してください。

階層を表示する

代理店には、アカウント階層を表示するためのオプションがいくつかあります。

• GetUser 操作は、顧客とリンクされたアカウントごとのユーザー ロールを返します。 顧客ロールは、アクセスできる顧客を通知しますが、アクセスを取得した方法を常に説明するとは限りません。 ユーザー ロールを決定すると、管理と標準のクライアント リンクの違いが生じます。 顧客ロールの例については、「 ユーザー ロールの取得」を参照してください。
• SearchClientLinks 操作では、機関とクライアント エンティティ識別子が既にある場合、クライアント リンクの現在の状態が表示されます。 たとえば、顧客 ID とクライアント アカウント ID またはクライアント顧客 ID を管理して検索できます。
• GetLinkedAccountsAndCustomersInfo 操作は、指定した顧客の顧客とアカウント階層を返します。

たとえば、顧客と広告主アカウントの両方のクライアント リンクを持つ MCC アカウント L1 (顧客 ID 111) の下に代理店階層が設定されたとします。

• 階層がセットアップされる前に、4 つの個別のマネージャー アカウントがプロビジョニングされていました。 Manager アカウント L1 には、広告アカウント 1A と広告アカウント 1B が含まれています。 Manager アカウント L2 には、広告アカウント 2A と広告アカウント 2B が含まれています。 Manager アカウント L3 には、広告アカウント 3A と広告アカウント 3B が含まれています。 Manager アカウント L4 には、広告アカウント 4A と広告アカウント 4B が含まれています。
• Manager アカウント L1 (顧客 ID 111) は、管理者リンクを含む Manager アカウント L2 (顧客 ID 222) にリンクします。
• Manager アカウント L2 (顧客 ID 222) は、標準リンクを使用して Manager アカウント L3 (顧客 ID 333) にリンクします。
• Manager アカウント L3 (顧客 ID 333) は、アカウント レベルのリンクを含む広告アカウント 4A (アカウント ID 444111) にリンクします。 広告アカウント 4A (アカウント ID 444111) は、MCC アカウント L4 (顧客 ID 444) のすぐ下にあります。これは、それ自体が顧客レベル階層に含まれていません。 この例では、Manager アカウント L3 (顧客 ID 333) を介して Ad アカウント 4A (アカウント ID 444111) にアクセスできます。つまり、顧客 ID を必要とするサービス操作を呼び出す場合は、アカウント 444111にアクセスするために Manager アカウント L3 (顧客 ID 333) を使用する必要があります。

Manager アカウント L1 (顧客 ID 111) で Microsoft Advertising Web アプリケーションにサインインする完全な階層にアクセスできるユーザーは、次のアカウント ビューにアクセスできます。

顧客 ID 111 で検索した場合、 GetLinkedAccountsAndCustomersInfo 応答には AccountsInfo 内の Ad Account 1A と Ad Account 1B が含まれます。 Manager アカウント 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 が含まれます。 Manager アカウント 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 アカウント 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>

これで、顧客 ID 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 は、顧客 ID 111 または 222 によって要求された場合でも同様の構造を返すように見えますが、顕著な違いがあります。 シナリオの概要で説明したように、Mananger アカウント L1 から Manager アカウント L2 へのリンクは管理リンクですが、Manager アカウント L2 から Manager アカウント L3 へのリンクは Standard です。 GetLinkedAccountsAndCustomersInfo 応答には、リンクの種類 (管理または標準) に関する詳細は含まれません。 リンクの種類は、ユーザー ロールに応じてユーザーのアクセス許可をさらに絞り込む可能性があるため、GetUser を呼び出すときに各 CustomerRole に含まれます。
• 顧客 ID 333 で検索する場合、広告アカウント 3A、広告アカウント 3B、および広告アカウント 4A に明らかな違いはありません。 シナリオの概要で説明したように、広告アカウント 4A には広告主アカウント のクライアント リンクからアクセスできます。一方、他のアカウントは MCC アカウント L3 に直接含まれています。 各アカウントの直接所有者を決定する必要がある場合は、他のサービス操作 (GetAccount や SearchAccounts など) を呼び出すことができます。
• 現在の階層の広告アカウント 4B は、MCC アカウント L4 のユーザーのみが使用できます。 Manager アカウント L3 のユーザーは 3 つのアカウントにアクセスするようにプロビジョニングでき、Manager アカウント L2 のユーザーは 5 つのアカウントにアクセスするようにプロビジョニングでき、Manager アカウント L1 のユーザーは 7 つのアカウントにアクセスするようにプロビジョニングできます。 スーパー管理者は、各ユーザーのアクセスを使用可能なアカウントのサブセットに制限することを選択できます。

アグリゲーター階層

アグリゲーターロールは、多数の広告主に検索マーケティングツールとサービスを提供する限られたパートナーセットに提供されます。 アグリゲーター ロールを使用すると、パートナーはプログラムによって新しい顧客アカウントを作成できます。 アグリゲーターは、クライアントによって発生したすべての広告コストに対して請求書で請求されます。 広告主は通常、Microsoft Advertising の資格情報にサインアップせず、アグリゲーターに料金を支払う場合があります。

アグリゲーター ユーザーは、プライマリ カスタマー シェルでプロビジョニングされます。 「 エンティティの制限」 で説明されているように、すべての広告アクティビティは顧客によって編成され、1 つ以上のアカウントを持つことができます。 アグリゲーター ユーザーによって SignupCustomer が呼び出されるたびに、新しい顧客内に新しい広告主アカウントが作成されます。

SignupCustomer 操作には、Customer オブジェクトと AdvertiserAccount オブジェクトの両方が必要です。 顧客オブジェクトには、顧客の名前、顧客が配置されている住所、顧客が運営する市場、顧客が参加する業界が含まれます。 同じ詳細を持つ複数の顧客を追加することはできますが、ユーザーインターフェイスでユーザーが顧客を簡単に区別できるように、一意の顧客名を使用する必要があります。 account オブジェクトは、アカウントの名前を指定する必要があります。口座決済に使用する通貨の種類。と支払い方法識別子を null に設定する必要があります。 操作によって請求書アカウントが生成され、支払方法識別子がアグリゲーターの請求書に関連付けられている識別子に設定されます。 課金はアグリゲーターの支払い方法にロールアップされ、アグリゲーターは、管理する顧客によって発生したすべての料金に対して請求されます。

アグリゲーター資格情報を取得する方法

アグリゲーターの資格情報を要求するには、アグリゲーター ロールの取得の詳細については、指定されたアカウント管理チームにお問い合わせください。 現在アグリゲーターではないが、1 つになりたい場合は、 Microsoft Advertising Partner Program のウェルカム ページに移動します。

関連項目

カスタマー マネジメント サービス リファレンス
Bing 広告 API Web サービス アドレス