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

  • [アーティクル]

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

注:

階層のコンテキストでは、 顧客 は "マネージャー アカウント" とも呼ばれます。 AdvertiserAccount は、"アカウント" または "広告主アカウント" と呼ばれます。

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

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

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

ユーザー ロール

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

注:

アカウントのプライマリ連絡先として設定できるのは、Super 管理 ユーザーと Standard ユーザーのみです。 ユーザー ロールの詳細については、Microsoft Advertising アカウントへのアクセス権を付与操作方法に関するヘルプ トピックを参照してください。

ユーザー ロール 利用可能なサービス
広告主キャンペーン マネージャー このロールには、選択したアカウントを表示し、選択したアカウント内のキャンペーンを追加、編集、または削除するためのアクセス許可があります。 広告主キャンペーン マネージャーは支払い方法を表示できますが、請求および支払いタスクを管理することはできません。

すべてのサービスの読み取り操作を使用できます。

Customer Management サービスでの書き込み操作は一般に使用できません。 例外の 1 つは、広告主キャンペーン マネージャーが UpdateAccount 操作を使用して、AdvertiserAccount の AutoTagType 要素を更新できることです。
アグリゲーター DeleteCustomer を除くすべてのサービスの読み取りおよび書き込み操作を使用できます。
標準ユーザー このロールには、キャンペーンを管理し、選択したアカウントに対して一部の課金アクティビティを実行するためのアクセス許可があります。 このロールは、支払い方法を追加、編集、または削除できません。アカウントを追加または削除します。 標準ユーザーは広告主アカウントをリンクおよびリンク解除できますが、顧客レベルのクライアント リンクを管理することはできません。

Standard ユーザーは、アクセス権を持つアカウントの一部のユーザーを管理できます。 Standard ユーザーは、他の Standard ユーザー、広告主キャンペーン マネージャー、閲覧者を招待または削除し、現在の顧客のコンテキストですべてのユーザーに関する情報を表示できます。 ただし、Standard ユーザーはスーパー 管理を招待または削除することも、スーパー 管理のロールを編集することもできません。

共有されていない対象ユーザーまたは UET タグを所有する顧客の標準ユーザーは、説明や名前などのプロパティ (スコープ以外) を更新できます。 対象ユーザーまたは UET タグが共有されている間、Standard ユーザーはこれらのプロパティを更新できません。 詳細については、「 対象ユーザーと UET タグの共有 」テクニカル ガイドを参照してください。

すべてのサービスの読み取り操作を使用できます。

Customer Billing サービスと Customer Management サービスを使用した書き込み操作は一般に使用できません。 Standard ユーザーが使用できる操作の例外は、 AddInsertionOrder、 UpdateInsertionOrder、 UpdateAccount です。
スーパー 管理 このロールには、すべてのアカウントに対する完全なアクセス許可があります。 スーパー 管理では、課金と支払い、アカウントの詳細、およびその他のユーザー (他のスーパー管理者を含む) に関連するすべてのものを管理できます。 Super 管理では、他のユーザーがアクセスできるアカウントを指定できます。 新しい顧客としてサインアップする場合、最初のユーザーは Super 管理です。

対象ユーザーまたは UET タグを所有する顧客のスーパー 管理 ユーザーは、対象ユーザーまたは UET タグの顧客アカウント共有スコープを更新できます。 階層の親顧客のスーパー 管理 ユーザーは、スコープを更新することもできます。 説明や名前などの他の対象ユーザーまたは UET タグプロパティ (スコープ以外) は、対象ユーザーまたは UET タグを所有する顧客の Super 管理 ユーザーのみが更新できます。 階層の親顧客のスーパー 管理 ユーザーは、これらの詳細を更新できません。 詳細については、「 対象ユーザーと UET タグの共有 」テクニカル ガイドを参照してください。

DeleteCustomer を除く、すべてのサービスの読み取りおよび書き込み操作を使用できます
ビューアー このロールには、読み取り専用のアクセス許可があります。

すべてのサービスの読み取り操作を使用できます。

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

顧客リンクのアクセス許可

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

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

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

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

注:

ユーザーは、新しいアカウントにサインアップし、既存のアカウントへの招待を受け入れるときに、同じログイン資格情報を使用できます。 どちらの場合も、サインアップ ワークフローを完了するために同じ資格情報が使用されている場合、そのユーザーは マルチユーザー資格情報を持つと見なされます。 顧客スコープでユーザーを管理する各 Super 管理の観点から見ると、ユーザーのロール、アカウント アクセス、連絡先情報は一意です。 ユーザーが別の顧客のコンテキストで持っているアクセス許可は、現在の顧客のスコープ内で動作する場合には考慮されません。

スーパー 管理には、ユーザーの異なるアカウントへのアクセスを変更し、ユーザー ロール (ビューアーから 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 は、対応するアカウントまたはアカウントのセットにアクセスするときにユーザーが持つアクセス許可を表します。

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

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

Microsoft Advertising で初めてサインアップし、新しいアカウントを作成した場合、 GetUser 操作は 1 つの CustomerRole オブジェクトを 返します。

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

ヒント

Bing Ads API を使用してアクセス トークンを取得し、最初のサービス呼び出しを行うには、 クイック スタート ガイドを参照してください。

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 による認証」を参照) は、対応するユーザーとロールに制限されたアクセス許可を表します。

User 役割 アクセス許可
one@contoso.com ビューアー 顧客 A - すべてのアカウント
two@contoso.com スーパー 管理 顧客 B - すべてのアカウント
three@contoso.com ビューアー 顧客 C - アカウント A
four@contoso.com 標準ユーザー 顧客 B - すべてのアカウント

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

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

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

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

注:

TimeStamp は LastModifiedTime とは異なります。 TimeStamp 値はすべてユーザーごとに一意であり、 UpdateUser を呼び出すときは、対応するユーザーのタイムスタンプ (アドレス タイムスタンプを含む) を含める必要があります。

たとえば、 と を使用して統合する前から、 のone@contoso.comユーザー情報を更新していないとtwo@contoso.comthree@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

アカウント階層

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

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

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

エージェンシー階層

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

注:

階層のコンテキストでは、 顧客 は "マネージャー アカウント" とも呼ばれます。 AdvertiserAccount は、"アカウント" または "広告主アカウント" と呼ばれます。

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

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

注:

スーパー 管理または Standard 資格情報を持つユーザーのみが、広告主アカウントへのクライアント リンクを追加、更新、検索できます。 Super 管理 資格情報を持つユーザーのみが、顧客へのクライアント リンクを追加、更新、検索できます。

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

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

重要

広告主アカウントのクライアント リンクの場合、代理店は、クライアント リンク要求で IsBillToClient 要素を設定することで、クライアントまたは代理店が課金を担当するかどうかを指定する必要があります。

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

注:

クライアントは、Bing Ads API に基づいて構築されたアプリケーション、または Microsoft Advertising Web アプリケーションの [ アカウント & 課金 ] タブを使用して、同意または拒否できます。

クライアントは 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 つのアカウントにアクセスするようにプロビジョニングできます。 Super 管理は、各ユーザーのアクセスを使用可能なアカウントのサブセットに制限することを選択できます。

アグリゲーター階層

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

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

重要

SignupCustomer にはアグリゲーター ユーザー ロールが必要です。 初期資格情報のプロビジョニング後にスーパー 管理 ユーザーがアグリゲーターの顧客に追加された場合、既定では、アグリゲーターが管理するすべての顧客のデータを管理できます。 ユーザーは SignupCustomer を呼び出すことはできませんが、それ以外の場合はキャンペーン データへの読み取りと書き込みのアクセス権を持つことになります。

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

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

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

関連項目

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