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.

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 seul utilisateur super administrateur 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 administrateur 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.

Les autorisations de super administrateur 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 des autorisations complètes de super administrateur 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 administrateur. Un super administrateur peut créer de nouveaux utilisateurs avec le rôle Gestionnaire de campagne de l’annonceur, Super Administrateur, 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 .

Un super administrateur 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.

• Le RoleId représente le rôle d’utilisateur , par exemple, 41 représente le rôle d’utilisateur super administrateur.
• 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 administrateur.
• CustomerId est l’identificateur du client approvisionné lorsque vous vous êtes inscrit.
• L’élément AccountIds est vide, car un super administrateur 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 administrateur du compte 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, par exemple, que l’un des utilisateurs super administrateurs du compte de gestionnaire L1 (ID client 111) (que vous ou un autre super administrateur) configurez une hiérarchie d’agence sous Compte de gestionnaire L1 (ID client 111) avec des liens client et client de compte d’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 Administrateur. 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 administrateur 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.

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

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.

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

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.

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.

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 vérifiez 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.

S’il existe un lien avec l’état Actif, 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 l’état 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 l’état du lien du client vers LinkPending.

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 .

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

• Si le client définit l’état sur LinkDeclined, le cycle de vie du lien 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’état sur LinkAccepted, l’état passe à LinkInProgress. Si le processus de liaison réussit, le service met à jour l’état du lien client 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 l’état du lien client 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’état 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 l’état du lien client est LinkPending, l’agence peut choisir d’annuler une demande de lien précédente.

Si l’état du lien client 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 l’état du lien client sur UnlinkRequested et appelle l’opération UpdateClientLinks . La mise à jour de l’état avec UnlinkRequested définit effectivement l’état sur UnlinkInProgress. Le service bascule immédiatement l’état du lien client 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 à l’état Actif. Si le processus de dissociation réussit, l’état passe à 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 l’état actuel 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 administrateur 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.

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