Hiérarchie de compte et autorisations utilisateur

Les utilisateurs de Microsoft Advertising peuvent utiliser les mêmes informations d’identification de connexion pour accéder à plusieurs comptes, potentiellement avec des autorisations différentes sur chaque compte. Une agence peut configurer une hiérarchie de comptes pour gérer tous les utilisateurs et comptes d’un compte parent, utiliser un portefeuille central pour tout payer et partager des ressources de campagne telles que les étiquettes de suivi des événements universels (UET) et les listes de remarketing entre les clients.

• Rôles et autorisations d’utilisateur décrit les actions disponibles pour chaque rôle d’utilisateur, la façon dont les utilisateurs sont approvisionnés sur un compte, comment vous pouvez découvrir leurs droits d’accès actuels et comment vous pouvez agir au nom d’un utilisateur Microsoft Advertising authentifié avec l’API Bing Ads.
• Les informations d’identification multi-utilisateur décrivent comment vous pouvez utiliser un ensemble d’informations d’identification Microsoft Advertising pour accéder à des comptes d’annonceur sur plusieurs clients, potentiellement avec des rôles d’utilisateur et des autorisations différents. Si vous disposez déjà de plusieurs ensembles d’informations d’identification de connexion, vous pouvez demander au support de regrouper en un ensemble d’informations d’identification.
• La hiérarchie des comptes décrit comment vous pouvez fournir l’accès à une hiérarchie de comptes pour un ou plusieurs utilisateurs d’un client. En effet, vous pouvez gérer tous les utilisateurs et comptes à partir d’un compte parent, et utiliser un portefeuille central pour tout payer. En outre, avec les hiérarchies, vous pouvez partager des ressources de campagne telles que des étiquettes de suivi des événements universels (UET) et des listes de remarketing entre les clients.

Remarque

Dans le contexte des hiérarchies, un client est également appelé « compte de responsable ». Un AdvertiserAccount est appelé « Compte » ou « Compte annonceur ».

Pour plus d’informations sur la hiérarchie de campagne au sein d’un compte, consultez Limites d’entité.

Rôles et autorisations d’utilisateur

Votre application n’a peut-être besoin de prendre en charge qu’un utilisateur Super Administration sur un compte connu. Même avec une structure d’autorisation relativement simple, vous souhaiterez comprendre les actions disponibles pour chaque rôle d’utilisateur, comment les utilisateurs sont provisionnés sur un compte, comment vous pouvez découvrir leurs droits d’accès actuels et comment vous pouvez agir au nom d’un utilisateur Microsoft Advertising authentifié avec l’API Bing Ads.

Rôles d’utilisateur

Le rôle d’utilisateur accordé par le Super Administration d’un client ou l’administrateur système Microsoft Advertising détermine la disponibilité du service. Par exemple, un utilisateur disposant du rôle Gestionnaire de campagnes annonceur peut ajouter et mettre à jour des campagnes, mais ne peut pas créer ou mettre à jour des utilisateurs. Sauf indication contraire dans le contenu de référence par opération de service, le tableau suivant décrit à un niveau élevé les restrictions de service par rôle d’utilisateur.

Remarque

Seuls les utilisateurs Super Administration et Standard peuvent être définis comme contact principal d’un compte. Pour plus d’informations sur les rôles d’utilisateur, consultez la rubrique d’aide Comment faire accorder à quelqu’un l’accès à mon compte Microsoft Advertising ? .

Rôle d’utilisateur	Services disponibles
Gestionnaire de campagne de l’annonceur	Ce rôle dispose des autorisations nécessaires pour afficher les comptes sélectionnés et ajouter, modifier ou supprimer des campagnes dans les comptes sélectionnés. Le gestionnaire de campagne de l’annonceur peut afficher les modes de paiement, mais ne peut pas gérer les tâches de facturation et de paiement. Des opérations de lecture pour tous les services sont disponibles. Les opérations d’écriture avec le service Gestion des clients ne sont généralement pas disponibles. Une exception est que le Gestionnaire de campagne de l’annonceur peut mettre à jour l’élément AutoTagType d’un AdvertiserAccount à l’aide de l’opération UpdateAccount .
Agrégateur	Les opérations de lecture et d’écriture pour tous les services sont disponibles, à l’exception de DeleteCustomer.
Utilisateur standard	Ce rôle dispose des autorisations nécessaires pour gérer les campagnes et effectuer certaines activités de facturation sur les comptes sélectionnés. Ce rôle ne peut pas ajouter, modifier ou supprimer des modes de paiement ; ajouter ou supprimer des comptes. Les utilisateurs standard peuvent lier et dissocier des comptes d’annonceur, mais ne peuvent pas gérer les liens client au niveau client. Les utilisateurs standard peuvent gérer certains utilisateurs dans les comptes auxquels ils ont accès. Un utilisateur Standard peut inviter ou supprimer d’autres utilisateurs Standard, responsables de campagne d’annonceurs et visionneuses, et afficher des informations sur tous les utilisateurs dans le contexte du client actuel. Toutefois, les utilisateurs Standard ne peuvent pas inviter ou supprimer un Super Administration, ni modifier le rôle d’un Super Administration. Les utilisateurs standard du client qui possède une audience non partagée ou une balise de suivi des conversions peuvent mettre à jour leurs propriétés (autres que l’étendue), telles que la description et le nom. Bien que l’audience ou la balise de suivi des conversions soit partagée, un utilisateur Standard ne peut pas mettre à jour ces propriétés. Pour plus d’informations, consultez le guide technique Partager les audiences et les balises de suivi des conversions. Des opérations de lecture pour tous les services sont disponibles. Les opérations d’écriture avec le service De facturation client et le service Gestion des clients ne sont généralement pas disponibles. Les exceptions des opérations disponibles pour un utilisateur Standard sont AddInsertionOrder, UpdateInsertionOrder et UpdateAccount.
Super Administration	Ce rôle dispose d’autorisations complètes pour tous les comptes. Un Super Administration peut gérer tout ce qui concerne la facturation et les paiements, les détails du compte et d’autres utilisateurs (y compris d’autres super administrateurs). Le Super Administration peut spécifier les comptes auxquels d’autres utilisateurs ont accès. Lors de l’inscription en tant que nouveau client, le premier utilisateur est le Super Administration. Un utilisateur Super Administration dans le client qui possède l’audience ou la balise de suivi des conversions peut mettre à jour l’étendue de partage de compte client d’une audience ou d’une balise de suivi des conversions. Les utilisateurs super Administration dans les clients parents de la hiérarchie peuvent également mettre à jour l’étendue. Les autres propriétés d’audience ou de balise de suivi des conversions (autres que l’étendue), telles que la description et le nom, peuvent uniquement être mises à jour par un utilisateur Super Administration dans le client propriétaire de l’audience ou de la balise de suivi des conversions. Les utilisateurs super Administration dans les clients parents de la hiérarchie ne peuvent pas mettre à jour ces détails. Pour plus d’informations, consultez le guide technique Partager les audiences et les balises de suivi des conversions. Les opérations de lecture et d’écriture pour tous les services sont disponibles, à l’exception de DeleteCustomer
Visionneuse	Ce rôle dispose d’autorisations en lecture seule. Des opérations de lecture pour tous les services sont disponibles.

Les autorisations super Administration sur les clients liés sont limitées si l’autorisation de lien (CustomerLinkPermission) est « Standard ». Leurs autorisations ne sont pas limitées si l’autorisation de lien est « Administrative ». Ils conservent également toutes les autorisations Super Administration sur les clients auxquels ils peuvent accéder directement, par exemple, là où ils se sont inscrits.

Notez également que, pris individuellement, un utilisateur a le même rôle sur les CustomerId, AccountIds et LinkedAccountIds pour un CustomerRole donné ; Toutefois, si un utilisateur a plusieurs rôles de client, les autorisations effectives dépendent de l’ensemble complet d’objets CustomerRole retournés par GetUser. Plusieurs exemples sont fournis dans Obtenir des rôles d’utilisateur.

Attribuer des rôles d’utilisateur

Lors de l’inscription à un nouveau compte dans l’application web Microsoft Advertising, vous disposez du rôle d’utilisateur Super Administration. Un Super Administration peut créer de nouveaux utilisateurs avec le rôle Gestionnaire de campagne de l’annonceur, Super Administration, Standard ou Visionneuse. Le rôle Aggregator est approvisionné par demande spéciale par le biais de l’administrateur système. Pour plus d’informations, consultez Hiérarchie d’agrégation et contactez votre responsable de compte.

Techniquement, de nouveaux utilisateurs ne peuvent pas être créés par programmation ; Toutefois, vous pouvez utiliser l’opération SendUserInvitation pour inviter des personnes à s’inscrire sous un compte Microsoft Advertising existant. Lorsque vous invitez une personne à un compte ou à un ensemble de comptes, vous définissez également le rôle d’utilisateur. Microsoft Advertising génère une invitation par e-mail qui est envoyée à l’invité. En cliquant sur le lien envoyé par e-mail et en terminant le flux de travail d’inscription à Microsoft Advertising, ils acceptent l’invitation à gérer les comptes avec le rôle d’utilisateur que vous avez provisionné dans la demande SendUserInvitation .

Remarque

Une personne peut utiliser les mêmes informations d’identification de connexion lors de l’inscription de nouveaux comptes et de l’acceptation d’invitations à des comptes existants. Dans les deux cas, lorsque les mêmes informations d’identification sont utilisées pour terminer le flux de travail d’inscription, la personne est considérée comme ayant des informations d’identification multi-utilisateur. Du point de vue de chaque Super Administration la gestion des utilisateurs dans leur étendue client, le rôle de l’utilisateur, l’accès au compte et les informations de contact sont uniques. Les autorisations dont dispose l’utilisateur dans le contexte d’un autre client ne sont pas prises en compte lorsqu’il agit dans le cadre du client actuel.

Un Super Administration a la possibilité de modifier l’accès de ses utilisateurs à différents comptes et éventuellement de modifier le rôle d’utilisateur, par exemple, de Visionneuse à Utilisateur Standard. Pour mettre à jour le rôle d’un utilisateur, appelez l’opération UpdateUserRoles .

Obtenir des rôles d’utilisateur

Pour obtenir la liste des utilisateurs qui peuvent accéder à un ou plusieurs comptes d’un client, appelez l’opération GetUsersInfo . L’opération retourne un tableau d’objets qui contient l’adresse e-mail de connexion et l’identificateur de chaque utilisateur. Vous pouvez ensuite obtenir les détails de chaque utilisateur dans la liste, tels que son rôle et ses autorisations de compte dans Microsoft Advertising, appeler l’opération GetUser . Lorsque vous appelez GetUser si vous laissez l’élément UserId zéro, la réponse inclut les détails de l’utilisateur authentifié actuel, comme spécifié par les informations d’identification de l’en-tête de requête.

Voici un exemple d’élément CustomerRoles retourné par l’opération GetUser .

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

Chaque CustomerRole représente les autorisations dont dispose une personne lors de l’accès au compte ou à l’ensemble de comptes correspondant.

• RoleId représente le rôle d’utilisateur, par exemple, 41 représente le rôle d’utilisateur Super Administration.
• CustomerId est l’identificateur du client dans lequel l’utilisateur s’est inscrit ou a une relation de hiérarchie de compte.
• L’élément AccountIds contient des identificateurs de comptes d’annonceur auxquels l’utilisateur peut accéder dans le contexte du CustomerId.
• L’élément LinkedAccountIds contient les identificateurs des comptes d’annonceur liés auxquels l’utilisateur peut accéder dans le contexte du CustomerId.
• CustomerLinkPermission peut limiter le rôle d’utilisateur en fonction de la relation de hiérarchie de compte dans le contexte du CustomerId.

Pris individuellement, un utilisateur a le même rôle sur les CustomerId, AccountIds et LinkedAccountIds pour un CustomerRole donné ; Toutefois, si un utilisateur a plusieurs rôles de client, les autorisations effectives dépendent de l’ensemble complet d’objets CustomerRole retournés par GetUser. Plusieurs exemples sont fournis ci-dessous.

Exemple de rôles pour un nouvel utilisateur

Si vous venez de vous inscrire pour la première fois auprès de Microsoft Advertising et que vous avez créé un compte, l’opération GetUser renvoie un objet CustomerRole .

• RoleId est 41, car le premier utilisateur d’un nouveau compte a le rôle d’utilisateur Super Administration.
• CustomerId est l’identificateur du client approvisionné lorsque vous vous êtes inscrit.
• L’élément AccountIds est vide, car un Super Administration peut toujours accéder à tous les comptes d’annonceur dans le client avec l’identificateur CustomerId.
• L’élément LinkedAccountIds est vide, car vous n’avez pas encore lié à des comptes annonceurs clients.
• CustomerLinkPermission est vide, car vous pouvez accéder aux comptes d’annonceur directement via le CustomerId attribué.

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

Exemples de rôles pour les informations d’identification multi-utilisateur

Si vous acceptez une invitation à être un utilisateur d’un autre client avec vos informations d’identification de connexion existantes de l’exemple précédent, vous disposez d’informations d’identification multi-utilisateur dans Microsoft Advertising. Vos informations d’identification de connexion directement associées à chacun des identificateurs du client et l’opération GetUser retourne deux objets CustomerRole . Dans cet exemple, les éléments de chaque CustomerRole sont équivalents, à l’exception de CustomerId. Le RoleId dépend du rôle attribué lorsque le Super Administration du compte de gestionnaire L1 (ID client 111) vous a envoyé l’invitation.

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

Exemple de rôles pour la hiérarchie de comptes

En vous appuyant sur l’exemple de rôles pour les informations d’identification multi-utilisateur (bien que les informations d’identification multi-utilisateur ne soient pas nécessaires pour créer une hiérarchie), supposons que l’un des utilisateurs Super Administration dans le compte de gestionnaire L1 (ID client 111) (que vous ou un autre Super Administration) configurez une hiérarchie d’agence sous Compte de gestionnaire L1 (ID client 111) avec les liens client client et compte annonceur :

• Le compte de responsable L1 (ID client 111) est lié au compte de responsable L2 (ID client 222) avec un lien d’administration.
• Le compte de responsable L2 (ID client 222) est lié au compte de responsable L3 (ID client 333) avec un lien Standard.
• Le compte de responsable L3 (ID client 333) est lié au compte publicitaire 4A (ID de compte 444111) avec un lien au niveau du compte. Le compte ad 4A (ID de compte 444111) se trouve directement sous Compte de gestionnaire L4 (ID client 444), qui n’est pas lui-même inclus dans la hiérarchie au niveau du client.

Vous avez toujours accès au client d’origine que vous avez inscrit, par exemple, 999, et vous êtes toujours un utilisateur direct sur le compte de gestionnaire L1 (ID client 111). À présent, l’opération GetUser retourne deux objets CustomerRole supplémentaires, c’est-à-dire un pour le compte de gestionnaire L2 (ID client 222) et le compte de responsable L3 (ID client 333). Vous pouvez accéder à tous les AccountIds et LinkedAccountIds accessibles via le compte de gestionnaire L2 (ID client 222) et 333, respectivement. Dans cet exemple, vous pouvez accéder au compte publicitaire 4A (ID de compte 444111) par le biais du compte de responsable L3 (ID client 333), c’est-à-dire, lorsque vous appelez des opérations de service qui nécessitent l’identificateur du client, vous devez utiliser le compte de responsable L3 (ID client 333) pour accéder aux 444111 de compte.

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

Les rôles de client informent les clients auxquels vous pouvez accéder, mais ne décrivent pas toujours comment vous avez obtenu l’accès. L’opération GetLinkedAccountsAndCustomersInfo retourne la hiérarchie du client et du compte sous le client spécifié. Pour plus d’informations et d’exemples, consultez Afficher la hiérarchie.

Exemple de rôles pour la hiérarchie d’agrégation

Si vous venez de vous inscrire pour la première fois auprès de Microsoft Advertising, que vous avez obtenu des informations d’identification Aggregator et que vous avez créé un compte client et annonceur via SignupCustomer, l’opération GetUser renvoie deux objets CustomerRole . Les éléments de chaque CustomerRole sont équivalents, à l’exception du RoleId. Un agrégateur a deux identificateurs de rôle dans Microsoft Advertising : 41 et 33.

• Le RoleId dans l’un des objets CustomerRole est 41, car le premier utilisateur d’un nouveau compte a le rôle d’utilisateur Super Administration. Le RoleId dans un autre des objets CustomerRole est 33, qui représente le rôle d’utilisateur Aggregator.
• CustomerId est l’identificateur du client approvisionné lorsque vous vous êtes inscrit.
• L’élément AccountIds est vide, car un Super Administration peut toujours accéder à tous les comptes d’annonceur dans le client avec l’identificateur CustomerId.
• L’élément LinkedAccountIds contient l’identificateur du compte d’annonceur dans le client enfant que vous avez créé via SignupCustomer. L’identificateur de client enfant n’est pas représenté dans l’objet CustomerRole . Vous pouvez appeler GetAccount pour obtenir les détails du compte de l’annonceur, comme son ParentCustomerId. Notez également que vous pouvez supprimer des comptes d’agrégation via DeleteAccount, mais que vous ne pouvez pas les dissocier via UpdateClientLinks. Appelez l’opération SearchClientLinks pour déterminer quels comptes peuvent être dissociés.
• CustomerLinkPermission est vide, car vous pouvez accéder aux comptes d’annonceur directement via le CustomerId attribué.

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

Jetons d’accès et de développeur

Pour agir par programmation au nom d’un utilisateur Microsoft Advertising, vous devez obtenir son consentement. À la fin du workflow de consentement, vous pouvez obtenir un jeton d’accès qui représente l’utilisateur. Le jeton d’accès a les mêmes rôles et les mêmes accès aux mêmes comptes que l’utilisateur dans l’application web Microsoft Advertising. En d’autres termes, les mêmes comptes et autorisations de rôle utilisateur disponibles dans l’application web Microsoft Advertising sont disponibles pour l’utilisateur par programme via l’API. Pour plus d’informations sur l’obtention d’un jeton d’accès pour agir au nom d’un utilisateur Microsoft Advertising, consultez Authentification avec OAuth.

Vous aurez également besoin d’un jeton de développeur qui identifie de manière unique votre application. L’obtention d’un jeton de développeur pour l’accès à l’API n’accorde pas d’autorisations supplémentaires aux comptes Microsoft Advertising. Un jeton de développeur permet d’accéder par programmation aux comptes déjà provisionnés pour un utilisateur. Pour plus d’informations, consultez Obtenir un jeton de développeur.

Conseil

Pour obtenir un jeton d’accès et effectuer votre premier appel de service à l’aide de l’API Bing Ads, consultez le guide de démarrage rapide .

Les en-têtes AuthenticationToken et DeveloperToken doivent être définis dans chaque requête via l’API Bing Ads. Voici un exemple d’appel à l’opération 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>

Informations d’identification multi-utilisateur

Vous pouvez utiliser un ensemble d’informations d’identification multi-utilisateur Microsoft Advertising pour accéder aux comptes d’annonceur sur plusieurs clients, potentiellement avec des rôles d’utilisateur et des autorisations différents.

Il peut être utile de penser que les informations d’identification « multi-utilisateur » signifient « plusieurs rôles d’utilisateur », car d’un point de vue, vous ne vous connectez qu’avec un seul nom d’utilisateur pour accéder aux clients multipe avec des autorisations différentes. Les informations d’identification d’une personne peuvent agir avec plusieurs rôles d’utilisateur distincts. Par exemple, vos informations d’identification multi-utilisateur vous accordent l’accès au client A et au client B. Toutefois, votre rôle d’utilisateur Visionneuse pour le client A vous empêche d’apporter des modifications sur les comptes qui appartiennent au client A. Mais en tant que Super Administration pour le client B, vous disposez d’un contrôle total sur les comptes de ce client.

Si vous disposez déjà de plusieurs ensembles d’informations d’identification de connexion, vous pouvez demander au support de regrouper en un ensemble d’informations d’identification. Le rôle d’utilisateur et l’accès au compte via chaque client que vous aviez avant la consolidation sont conservés. Notez également que les informations d’identification de la même personne peuvent être associées à des ensembles distincts d’informations de contact utilisateur, c’est-à-dire des informations de contact uniques par client.

Pour plus d’informations, consultez la rubrique d’aide Microsoft Advertising Gestion de votre nom d’utilisateur pour accéder à plusieurs comptes.

Consolidation multi-utilisateur

Si vous vous connectez déjà avec plusieurs ensembles d’informations d’identification, par exemple, deux adresses e-mail, les informations d’identification multi-utilisateur peuvent être configurées manuellement. Contactez le support technique ou votre responsable de compte pour fusionner les noms d’utilisateur existants en un seul nom d’utilisateur. Une autre option consiste à vous envoyer une invitation à partir de chaque client que vous souhaitez gérer, puis à accepter chaque invitation à l’aide des informations d’identification de connexion que vous souhaitez conserver. Cette option est disponible via l’application web Microsoft Advertising ou l’opération du service SendUserInvitation . Une fois que vous avez accepté l’invitation avec des informations d’identification Microsoft Advertising existantes, vous disposez d’informations d’identification « multi-utilisateur ».

Examinons les rôles et autorisations d’utilisateur suivants avant la consolidation multi-utilisateur. Dans l’application web Microsoft Advertising, chaque utilisateur doit se connecter séparément et dispose d’autorisations différentes au cours de chaque session connectée. De même, via l’API, le jeton d’accès de chaque utilisateur (voir Authentification avec OAuth) représente des autorisations limitées à l’utilisateur et au rôle correspondants.

Utilisateur	Role	Autorisations
one@contoso.com	Visionneuse	Client A - Tous les comptes
two@contoso.com	Super Administration	Client B - Tous les comptes
three@contoso.com	Visionneuse	Client C - Compte A
four@contoso.com	Utilisateur standard	Client B - Tous les comptes

Tout d’abord, notez qu’une seule adresse e-mail par client peut être consolidée, donc dans cet exemple two@contoso.com et four@contoso.com ne peut pas être consolidée ensemble. Voyons maintenant ce qui se passe une fois que les trois principaux utilisateurs sont regroupés sous one@contoso.com.

• Aucune modification pour l’utilisateur four@contoso.com , que ce soit via l’application web Microsoft Advertising, l’éditeur Microsoft Advertising ou l’API.
• L’utilisateur one@contoso.com peut se connecter via l’application web Microsoft Advertising et Microsoft Advertising Editor. Les utilisateurs consolidés, c’est-à-dire, two@contoso.com ne three@contoso.com disposent plus des autorisations nécessaires pour se connecter via l’application web Microsoft Advertising ou Microsoft Advertising Editor. Lorsque vous êtes connecté en tant que one@contoso.com, vous pouvez basculer le contexte vers les comptes clients avec les rôles d’utilisateur correspondants précédemment attribués à two@contoso.com et three@contoso.com. Bien que vous puissiez accéder à plusieurs clients connectés avec les informations d’identification d’un utilisateur (one@contoso.com), vous devez passer d’un client à un autre pour gérer les comptes liés avec des rôles d’utilisateur uniques. Les clients et leurs comptes associés restent distincts. Pour plus d’informations, consultez la rubrique d’aide Microsoft Advertising Gestion de votre nom d’utilisateur pour accéder à plusieurs comptes.
• Après la consolidation multi-utilisateur, le jeton d’accès de l’utilisateur one@contoso.com représente les autorisations pour la liste consolidée (sur-ensemble) de comptes. Le rôle d’utilisateur en vigueur dépend des identificateurs de client et de compte spécifiés dans la demande de service. Les jetons d’accès pour two@contoso.com et three@contoso.com ne seront plus acceptés, c’est-à-dire que l’erreur 120 - UserLoginAccessDenied sera retournée.

Informations de contact multi-utilisateur

Une personne avec des informations d’identification multi-utilisateur est représentée par plusieurs objets Utilisateur et les identificateurs d’utilisateur correspondants. En effet, les informations d’identification de la même personne peuvent être associées à des ensembles distincts d’informations de contact utilisateur, c’est-à-dire des informations de contact uniques par client.

La réponse GetUser peut varier en fonction de la personne qui effectue l’appel, même avec le même identificateur d’utilisateur. Supposons, par exemple, qu’avant la consolidation, les identificateurs pour one@contoso.com, two@contoso.comet three@contoso.com étaient respectivement 123, 456 et 789. Chaque identificateur d’utilisateur mappe effectivement une personne à un client spécifique, par exemple, l’identificateur 123 correspond one@contoso.com au client d’origine auquel la personne a pu accéder. Dans cet exemple, nous faisons référence à 123 comme identificateur d’utilisateur d’origine.

• Si le jeton d’accès pour one@contoso.com est utilisé pour appeler GetUser, et que l’Id d’utilisateur est nul ou que UserId est défini sur l’identificateur utilisateur d’origine (par exemple, 123), l’opération renvoie des objets CustomerRole pour tous les clients auxquels l’utilisateur peut accéder.
• Si le jeton d’accès pour one@contoso.com est utilisé pour appeler GetUser et que l’UserId est défini sur 456 ou 789, l’opération renvoie un seul objet CustomerRole qui mappe cette personne à un client spécifique.

Les paramètres utilisateur Name, Lcid, JobTitle et ContactInfo pour la même personne sont automatiquement synchronisés avec toutes les mises à jour qui se produisent après la consolidation de l’utilisateur. LastModifiedByUserId et LastModifiedTime sont également synchronisés sur chaque objet User retourné, sauf si vous aviez un ancien nom d’utilisateur fusionné et que vous n’avez pas mis à jour les paramètres utilisateur depuis la consolidation.

Remarque

L’objet TimeStamp diffère du LastModifiedTime. Toutes les valeurs TimeStamp sont uniques par utilisateur et lorsque vous appelez UpdateUser , vous devez inclure les horodatages de l’utilisateur correspondant (y compris l’horodatage de l’adresse).

Par exemple, supposons que vous n’avez pas mis à jour les informations utilisateur pour one@contoso.com depuis avant la consolidation avec two@contoso.com et three@contoso.com. Après la consolidation et jusqu’à ce que les paramètres utilisateur soient mis à jour après la consolidation, vous continuerez à observer un LastModifiedByUserId et un LastModifiedTime distincts dans chaque objet User retourné.

User Id	ID des informations de contact	Autorisations	LastModifiedByUserId
123	234	Client A - Tous les comptes	123
456	567	Client B - Tous les comptes	456
789	890	Client C - Compte A	789

Supposons maintenant que cela one@contoso.com agit dans le contexte du client B et met à jour ses informations de contact. Les informations de contact mises à jour ainsi que les mêmes LastModifiedByUserId et LastModifiedTime sont désormais synchronisées sur tous les objets User retournés.

User Id	ID des informations de contact	Autorisations	LastModifiedByUserId
123	234	Client A - Tous les comptes	456
456	567	Client B - Tous les comptes	456
789	890	Client C - Compte A	456

Hiérarchie des comptes

Les entreprises de publicité de recherche s’alignent généralement sur un ou plusieurs des modèles de gestion de compte suivants.

• Un annonceur direct crée une application API Bing Ads pour ses propres campagnes publicitaires et est facturé directement par Microsoft pour les clics publicitaires valides.
• Un fournisseur d’outils crée une application API Bing Ads pour que d’autres entreprises gèrent leurs campagnes publicitaires et n’est pas facturé par Microsoft. L’utilisateur annonceur est propriétaire des comptes, est facturé directement par Microsoft pour les clics publicitaires valides et peut payer des frais au fournisseur d’outils.
• Une agence crée une application API Bing Ads pour son entreprise afin de gérer les campagnes de ses clients publicitaires. Le client de l’agence est propriétaire des comptes, est facturé directement par Microsoft pour les clics publicitaires valides et peut payer des frais à l’agence.
• Un agrégateur ou un revendeur crée une application API Bing Ads pour gérer les campagnes de ses clients publicitaires, et est facturé directement par Microsoft pour des clics en direct valides. L’annonceur ne s’inscrit pas aux informations d’identification Microsoft Advertising et peut payer des frais à l’agrégateur.

Quel que soit le modèle métier, l’inscription initiale et l’attribution de rôles d’utilisateur sont plus ou moins identiques. Les sections ci-dessous décrivent les étapes supplémentaires nécessaires à la configuration des hiérarchies d’agences et d’agrégateurs .

Hiérarchie de l’agence

Une agence crée une application API Bing Ads pour son entreprise afin de gérer les campagnes de ses clients publicitaires. Les liens client permettent à une agence de gérer certains ou tous les aspects d’un compte d’annonceur. La demande de lien client peut limiter l’étendue à des comptes annonceurs clients individuels ou à tous les comptes sous le client.

Remarque

Dans le contexte des hiérarchies, un client est également appelé « compte de responsable ». Un AdvertiserAccount est appelé « Compte » ou « Compte annonceur ».

Il n’existe aucune limite définie au nombre de comptes clients pouvant être liés à une agence ; Toutefois, seuls 5 niveaux de profondeur sont pris en charge pour les liens de compte de responsable à compte de responsable. À chaque niveau (L1, L2, L3, L4, L5), un compte de gestionnaire peut être lié à n’importe quel nombre de comptes de gestionnaire et de comptes publicitaires. Pour plus d’informations sur la façon de devenir une agence, consultez l’article d’aide Gestion de vos clients en tant qu’agence sur Microsoft Advertising ou ressources pour les partenaires de l’agence.

Configurer la hiérarchie

Pour configurer une hiérarchie afin de gérer les comptes clients, l’agence doit envoyer une invitation au client, qui doit ensuite être acceptée par un utilisateur autorisé dans le client client. Pour déterminer si un lien existe déjà, appelez l’opération SearchClientLinks et case activée l’élément Status de tout ClientLink retourné. Pour effectuer une recherche par compte individuel, définissez le champ de prédicat sur ClientAccountId et définissez la valeur du prédicat sur l’identificateur de compte que vous souhaitez rechercher.

Remarque

Seul un utilisateur disposant d’informations d’identification Super Administration ou Standard peut ajouter, mettre à jour et rechercher des liens client vers des comptes d’annonceur. Seul un utilisateur disposant d’informations d’identification Super Administration peut ajouter, mettre à jour et rechercher des liens client vers des clients.

S’il existe un lien avec status Active, LinkAccepted, LinkInProgress, LinkPending, UnlinkInProgress ou UnlinkPending, l’agence ne peut pas lancer un lien client en double.

Si un lien client vers le compte spécifié n’existe pas encore, ou si le cycle de vie d’un lien existant s’est terminé avec status expiré, LinkCanceled, LinkDeclined, LinkFailed ou Inactif, l’agence peut lancer une nouvelle invitation de lien client en appelant l’opération AddClientLinks. Le service transfère immédiatement le lien client status vers LinkPending.

Importante

Pour les liens client de compte d’annonceur, l’agence doit spécifier si le client ou l’agence sera responsable de la facturation en définissant l’élément IsBillToClient dans la demande de lien client.

Pour mettre à jour un lien client, son élément TimeStamp est requis pour la validation. Vous devez donc d’abord appeler l’opération SearchClientLinks pour obtenir l’objet ClientLink existant. Modifiez ensuite l’élément Status du ClientLink retourné et incluez l’objet ClientLink mis à jour dans un appel ultérieur à l’opération UpdateClientLinks .

Remarque

Le client peut accepter ou refuser via une application basée sur l’API Bing Ads, ou via l’onglet Comptes & facturation dans l’application web Microsoft Advertising.

Le client peut uniquement utiliser l’opération UpdateClientLinks pour mettre à jour le status en tant que LinkAccepted ou LinkDeclined.

• Si le client définit l’status sur LinkDeclined, le cycle de vie de la liaison client se termine. Vous ne pouvez pas mettre à jour un lien client refusé et vous devez envoyer une nouvelle invitation pour gérer le compte client.
• Si le client définit l’status sur LinkAccepted, le status passe à LinkInProgress. Si le processus de liaison réussit, le service met à jour le lien client status sur Actif.

Si le lien ne peut pas être établi, par exemple, en raison d’une erreur de transition de facturation, le service met à jour le lien client status sur LinkFailed. Vous ne pouvez pas mettre à jour un lien client ayant échoué et vous devez envoyer une nouvelle invitation pour gérer le compte client. Si le client ou l’agence n’effectue aucune action dans les 30 jours, le service définit l’status sur LinkExpired et le cycle de vie du lien client se termine. Vous ne pouvez pas mettre à jour un lien client expiré et vous devez envoyer une nouvelle invitation pour gérer le compte client.

Si le lien client status est LinkPending, l’agence peut choisir d’annuler une demande de lien précédente.

Si le lien client status est Actif, l’agence peut choisir de mettre fin à la relation existante avec le client. Pour lancer le processus de dissociation, l’agence définit le lien client status sur UnlinkRequested et appelle l’opération UpdateClientLinks. La mise à jour de la status avec UnlinkRequested définit effectivement le status sur UnlinkInProgress. Le service effectue immédiatement la transition du lien client status vers UnlinkPending, puis attend que les ressources système continuent. L’état doit passer rapidement à UnlinkInProgress.

Si le processus de dissociation échoue, par exemple, en raison d’une erreur de transition de facturation, le lien client reprend vers Active status. Si le processus de dissociation réussit, le status est mis à jour sur Inactif, et le cycle de vie de la liaison client se termine. Vous ne pouvez pas mettre à jour un lien client inactif et vous devez envoyer une nouvelle invitation pour gérer le compte client.

Pour obtenir des exemples de code qui montrent comment ajouter et mettre à jour une invitation de lien client, consultez Exemple de code de liens client.

Afficher la hiérarchie

Une agence dispose de plusieurs options pour afficher la hiérarchie des comptes.

• L’opération GetUser retourne des rôles d’utilisateur par client et par compte lié. Les rôles de client informent les clients auxquels vous pouvez accéder, mais ne décrivent pas toujours comment vous avez obtenu l’accès. La détermination du rôle d’utilisateur fait une différence entre les liens client Administratif et Standard. Pour obtenir des exemples de rôles client, consultez Obtenir des rôles d’utilisateur.
• L’opération SearchClientLinks vous donne la status actuelle d’un lien client si vous disposez déjà des identificateurs d’agence et d’entité client. Par exemple, vous pouvez effectuer une recherche en gérant l’ID client et l’ID de compte client ou l’ID client client.
• L’opération GetLinkedAccountsAndCustomersInfo retourne la hiérarchie du client et du compte sous le client spécifié.

Supposons, par exemple, qu’une hiérarchie d’agence a été configurée sous Compte du responsable L1 (ID client 111) avec des liens client client et compte annonceur :

• Avant la configuration de la hiérarchie, quatre comptes de gestionnaire distincts avaient été provisionnés. Le compte de gestionnaire L1 contient le compte publicitaire 1A et le compte publicitaire 1B. Le compte de gestionnaire L2 contient le compte publicitaire 2A et le compte publicitaire 2B. Le compte de gestionnaire L3 contient le compte publicitaire 3A et le compte publicitaire 3B. Le compte de gestionnaire L4 contient le compte publicitaire 4A et le compte publicitaire 4B.
• Le compte de responsable L1 (ID client 111) est lié au compte de responsable L2 (ID client 222) avec un lien d’administration.
• Le compte de responsable L2 (ID client 222) est lié au compte de responsable L3 (ID client 333) avec un lien Standard.
• Le compte de responsable L3 (ID client 333) est lié au compte publicitaire 4A (ID de compte 444111) avec un lien au niveau du compte. Le compte ad 4A (ID de compte 444111) se trouve directement sous Compte de gestionnaire L4 (ID client 444), qui n’est pas lui-même inclus dans la hiérarchie au niveau du client. Dans cet exemple, vous pouvez accéder au compte publicitaire 4A (ID de compte 444111) par le biais du compte de responsable L3 (ID client 333), c’est-à-dire, lorsque vous appelez des opérations de service qui nécessitent l’identificateur du client, vous devez utiliser le compte de responsable L3 (ID client 333) pour accéder aux 444111 de compte.

Un utilisateur ayant accès à la hiérarchie complète qui se connecte à l’application web Microsoft Advertising sur le compte du gestionnaire L1 (ID client 111) a accès à la vue de compte suivante.

Si vous recherchez par ID de client 111, la réponse GetLinkedAccountsAndCustomersInfo inclut le compte publicitaire 1A et le compte publicitaire 1B dans AccountsInfo. Les informations sur le compte de gestionnaire L2 sont retournées dans 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>

De même, si vous recherchez par ID de client 222, la réponse GetLinkedAccountsAndCustomersInfo inclut le compte publicitaire 2A et le compte publicitaire 2B dans AccountsInfo. Les informations sur le compte de gestionnaire L3 sont retournées dans 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>

À présent, si vous recherchez par id client 333, la réponse GetLinkedAccountsAndCustomersInfo inclut le compte publicitaire 3A, le compte publicitaire 3B et le compte publicitaire 4A dans AccountsInfo. Aucun compte de responsable n’est répertorié dans 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>

Maintenant, si vous recherchez par ID de client 444, la réponse GetLinkedAccountsAndCustomersInfo inclut le compte publicitaire 4A et le compte publicitaire 4B dans AccountsInfo. Aucun compte de responsable n’est répertorié dans 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>

Voici quelques points notables à retenir des exemples de réponses ci-dessus :

• Bien que GetLinkedAccountsAndCustomersInfo semble retourner une structure similaire, qu’elle soit demandée par l’ID client 111 ou 222, il existe une différence notable. Comme mentionné dans l’introduction du scénario, le lien entre le compte Mananger L1 et le compte de gestionnaire L2 est un lien d’administration, tandis que le lien entre le compte de gestionnaire L2 et le compte de gestionnaire L3 est Standard. La réponse GetLinkedAccountsAndCustomersInfo n’inclut pas de détails sur le type de lien, c’est-à-dire Administratif ou Standard. Étant donné que le type de lien peut affiner davantage l’autorisation d’un utilisateur en fonction de son rôle d’utilisateur, il est inclus avec chaque rôle CustomerRole lorsque vous appelez GetUser.
• Lors de la recherche par ID de client 333, il n’existe aucune différence apparente entre le compte publicitaire 3A, le compte publicitaire 3B et le compte publicitaire 4A. Comme mentionné dans l’introduction du scénario, le compte publicitaire 4A est accessible via un lien client de compte d’annonceur, tandis que les autres comptes sont directement contenus dans le compte de gestionnaire L3. Si vous devez déterminer le propriétaire direct de chaque compte, vous pouvez appeler d’autres opérations de service, par exemple GetAccount ou SearchAccounts.
• Dans la hiérarchie actuelle, le compte publicitaire 4B n’est disponible que pour les utilisateurs du compte de gestionnaire L4. Les utilisateurs du compte de gestionnaire L3 peuvent être provisionnés pour accéder à 3 comptes, les utilisateurs du compte de gestionnaire L2 peuvent être approvisionnés pour accéder à 5 comptes et les utilisateurs du compte de gestionnaire L1 peuvent être approvisionnés pour accéder à 7 comptes. Un Super Administration peut choisir de limiter l’accès de chaque utilisateur à un sous-ensemble des comptes disponibles.

Hiérarchie de l’agrégateur

Le rôle d’agrégateur est offert à un ensemble limité de partenaires qui offrent des outils et des services de recherche-marketing à un grand nombre d’annonceurs. Le rôle d’agrégateur permet aux partenaires de créer par programmation de nouveaux comptes clients. L’agrégateur est facturé par facture pour tous les coûts publicitaires engagés par ses clients. L’annonceur ne s’inscrit généralement pas aux informations d’identification Microsoft Advertising et peut payer des frais à l’agrégateur.

Un utilisateur Aggregator est approvisionné dans l’interpréteur de commandes principal du client. Comme décrit dans Limites d’entité , toutes les activités publicitaires sont organisées par client, qui peut avoir un ou plusieurs comptes. Chaque fois que SignupCustomer est appelé par l’utilisateur Aggregator, un nouveau compte d’annonceur est créé au sein d’un nouveau client.

Importante

Le rôle d’utilisateur Aggregator est requis pour SignupCustomer. Si un utilisateur Super Administration est ajouté au client d’agrégateur après l’approvisionnement de vos informations d’identification initiales, par défaut, l’utilisateur peut gérer les données de tous les clients gérés par l’agrégateur. L’utilisateur ne pourra pas appeler SignupCustomer, mais aura autrement un accès en lecture et en écriture aux données de campagne.

L’opération SignupCustomer nécessite les objets Customer et AdvertiserAccount. L’objet client inclut le nom du client, l’adresse où se trouve le client, le marché dans lequel le client opère et le secteur d’activité auquel le client participe. Bien qu’il soit possible d’ajouter plusieurs clients avec les mêmes détails, vous devez utiliser des noms de clients uniques afin que les utilisateurs puissent facilement faire la distinction entre les clients dans une interface utilisateur. L’objet de compte doit spécifier le nom du compte ; le type de devise à utiliser pour régler le compte ; et l’identificateur du mode de paiement, qui doit être défini sur null. L’opération génère un compte de facture et définit l’identificateur du mode de paiement sur l’identificateur associé à la facture de l’agrégateur. La facturation se cumule sur l’instrument de paiement de l’agrégateur, et les agrégateurs sont facturés pour tous les frais encourus par les clients qu’ils gèrent.

Comment obtenir les informations d’identification de l’agrégateur

Pour demander des informations d’identification d’agrégateur, contactez votre équipe de gestion de compte désignée pour plus d’informations sur l’obtention du rôle Agrégateur. Si vous n’êtes pas actuellement un agrégateur, mais que vous souhaitez en devenir un, accédez à la page d’accueil du programme Microsoft Advertising Partner .

Voir aussi

Informations de référence sur le service de gestion des clients
Adresses du service web de l’API Bing Ads