Jerarquía de cuentas y permisos de usuario

Los usuarios de Microsoft Advertising pueden usar las mismas credenciales de inicio de sesión para acceder a varias cuentas, potencialmente con permisos diferentes en cada cuenta. Una agencia puede configurar una jerarquía de cuentas para administrar todos los usuarios y cuentas de una cuenta primaria, usar una cartera central para pagarlo todo y compartir recursos de campaña, como etiquetas de Seguimiento universal de eventos (UET) y listas de remarketing entre clientes.

• Roles de usuario y permisos describe las acciones disponibles para cada rol de usuario, cómo se aprovisionan los usuarios en una cuenta, cómo puede detectar sus derechos de acceso actuales y cómo puede actuar en nombre de un usuario autenticado de Microsoft Advertising con bing ads API.
• Credenciales de varios usuarios describe cómo puede usar un conjunto de credenciales de Microsoft Advertising para acceder a las cuentas de anunciantes entre varios clientes, potencialmente con diferentes roles de usuario y permisos. Si ya tiene varios conjuntos de credenciales de inicio de sesión, puede pedir al soporte técnico que consolide un conjunto de credenciales.
• Jerarquía de cuentas describe cómo puede proporcionar acceso a una jerarquía de cuentas para uno o varios usuarios de un cliente. De forma eficaz, puede administrar todos los usuarios y cuentas de una cuenta primaria y usar una cartera central para pagar por todo. También con jerarquías, puede compartir recursos de campaña, como etiquetas de Seguimiento universal de eventos (UET) y listas de remarketing entre clientes.

Nota:

En el contexto de las jerarquías, un cliente también se conoce como "cuenta de administrador". Una cuenta de anunciante se conoce como "Cuenta" o "Cuenta de anunciante".

Consulta Límites de entidad para obtener más información sobre la jerarquía de campañas dentro de una cuenta.

Roles y permisos de usuario

Es posible que la aplicación solo necesite admitir un usuario superadministrador en una cuenta conocida. Incluso con una estructura de permisos relativamente sencilla, querrá comprender las acciones disponibles para cada rol de usuario, cómo se aprovisionan los usuarios en una cuenta, cómo puede detectar sus derechos de acceso actuales y cómo puede actuar en nombre de un usuario autenticado de Microsoft Advertising con bing Ads API.

Roles de usuario

El rol de usuario concedido por el superadministrador de un cliente o el administrador del sistema de Microsoft Advertising determina la disponibilidad del servicio. Por ejemplo, un usuario con el rol Administrador de campañas de anunciantes puede agregar y actualizar campañas, pero no puede crear ni actualizar usuarios. A menos que se indique lo contrario en el contenido de referencia por operación de servicio, en la tabla siguiente se describen en un nivel alto las restricciones de servicio por rol de usuario.

Nota:

Solo los usuarios superadministrador y estándar se pueden establecer como contacto principal de una cuenta. Para obtener más información sobre los roles de usuario, consulte el tema de ayuda ¿Cómo puedo conceder acceso a alguien a mi cuenta de Microsoft Advertising?

Rol de usuario	Servicios disponibles
Administrador de campañas de anunciantes	Este rol tiene permisos para ver las cuentas seleccionadas y agregar, editar o eliminar campañas dentro de las cuentas seleccionadas. El Administrador de campañas de anunciantes puede ver los métodos de pago, pero no puede administrar ninguna tarea de facturación y pago. Hay disponibles operaciones de lectura para todos los servicios. Las operaciones de escritura con el servicio customer management no están disponibles con carácter general. Una excepción es que el Administrador de campañas de anunciantes puede actualizar el elemento AutoTagType de un anuncianteAccount mediante la operación UpdateAccount .
Agregador	Hay disponibles operaciones de lectura y escritura para todos los servicios, excepto DeleteCustomer.
Usuario estándar	Este rol tiene permisos para administrar campañas y realizar algunas actividades de facturación en cuentas seleccionadas. Este rol no puede agregar, editar ni eliminar métodos de pago; agregar o eliminar cuentas. Los usuarios estándar pueden vincular y desvincular cuentas de anunciantes, pero no pueden administrar vínculos de cliente a nivel de cliente. Los usuarios estándar pueden administrar algunos usuarios en las cuentas a las que tienen acceso. Un usuario estándar puede invitar o eliminar a otros usuarios estándar, administradores de campañas de anunciantes y visores, y ver información sobre todos los usuarios en el contexto del cliente actual. Sin embargo, los usuarios estándar no pueden invitar ni eliminar un superadministrador, ni tampoco pueden editar el rol de un superadministrador. Los usuarios estándar del cliente propietario de una audiencia no compartida o una etiqueta de UET pueden actualizar sus propiedades (distintas del ámbito), como la descripción y el nombre. Mientras se comparte la etiqueta audience o UET, un usuario estándar no puede actualizar estas propiedades. Para obtener más información, consulte la guía técnica Compartir audiencias y etiquetas de UET . Hay disponibles operaciones de lectura para todos los servicios. Las operaciones de escritura con el servicio de facturación del cliente y el servicio de administración de clientes no están disponibles con carácter general. Las excepciones de las operaciones disponibles para un usuario estándar son AddInsertionOrder, UpdateInsertionOrder y UpdateAccount.
Superadministrador	Este rol tiene permisos completos para todas las cuentas. Un superadministrador puede administrar todo lo relacionado con la facturación y los pagos, los detalles de la cuenta y otros usuarios (incluidos otros superadministrador). El superadministrador puede especificar a qué cuentas tienen acceso otros usuarios. Al registrarse como nuevo cliente, el primer usuario es el superadministrador. Un usuario superadministrador del cliente propietario de la audiencia o la etiqueta UET puede actualizar el ámbito de uso compartido de la cuenta de cliente de una audiencia o etiqueta de UET. Los usuarios superadministrador de los clientes primarios de la jerarquía también pueden actualizar el ámbito. Un usuario superadministrador del cliente propietario de la audiencia o la etiqueta UET solo puede actualizar otras propiedades de audiencia o etiqueta de UET (que no sean de ámbito), como la descripción y el nombre. Los usuarios superadministrador de los clientes primarios de la jerarquía no pueden actualizar estos detalles. Para obtener más información, consulte la guía técnica Compartir audiencias y etiquetas de UET . Las operaciones de lectura y escritura para todos los servicios están disponibles, excepto DeleteCustomer.
Visor	Este rol tiene permisos de solo lectura. Hay disponibles operaciones de lectura para todos los servicios.

Los permisos de superadministrador en clientes vinculados están restringidos si el permiso de vínculo (CustomerLinkPermission) es "Estándar". Sus permisos no están restringidos si el permiso de vínculo es "Administrativo". También conservan permisos de superadministrador completos en los clientes a los que pueden acceder directamente, por ejemplo, donde se registraron.

Tenga en cuenta también que, tomado de forma individual, un usuario tiene el mismo rol en CustomerId, AccountIds y LinkedAccountIds para un customerrole determinado; sin embargo, si un usuario tiene varios roles de cliente, los permisos efectivos dependen del conjunto completo de objetos CustomerRole devueltos por GetUser. Se proporcionan varios ejemplos en Obtener roles de usuario.

Asignar roles de usuario

Al registrarse para obtener una nueva cuenta en la aplicación web de Microsoft Advertising, se le concederá el rol de usuario Superadministrador. Un superadministrador puede crear nuevos usuarios con el rol Administrador de campañas de anunciantes, Superadministrador, Estándar o Visor. El rol agregador se aprovisiona mediante una solicitud especial a través del administrador del sistema. Para obtener más información, consulte Jerarquía de agregador y póngase en contacto con el administrador de cuentas.

Técnicamente no se pueden crear nuevos usuarios mediante programación; sin embargo, puede usar la operación SendUserInvitation para invitar a los usuarios a registrarse en una cuenta de Microsoft Advertising existente. Al invitar a alguien a una cuenta o un conjunto de cuentas, también establecerá el rol de usuario. Microsoft Advertising genera una invitación por correo electrónico que se envía al invitado. Al hacer clic en el vínculo enviado por correo electrónico y completar el flujo de trabajo de registro de Microsoft Advertising, aceptan la invitación para administrar cuentas con el rol de usuario que aprovisionó en la solicitud SendUserInvitation .

Nota:

Una persona puede usar las mismas credenciales de inicio de sesión al registrarse para nuevas cuentas y aceptar invitaciones a cuentas existentes. En cualquier caso, cuando se usan las mismas credenciales para completar el flujo de trabajo de registro, se considera que la persona tiene credenciales de varios usuarios. Desde la perspectiva de cada superadministrador que administra usuarios en su ámbito de cliente, el rol del usuario, el acceso a la cuenta y la información de contacto son únicos. Los permisos que el usuario tiene en el contexto de otro cliente no se tienen en cuenta al actuar dentro del ámbito del cliente actual.

Un superadministrador tiene la opción de modificar el acceso de sus usuarios a distintas cuentas y modificar potencialmente el rol de usuario , por ejemplo, del visor al usuario estándar. Para actualizar el rol de un usuario, llame a la operación UpdateUserRoles .

Obtener roles de usuario

Para obtener una lista de los usuarios que pueden acceder a una o varias cuentas de un cliente, llame a la operación GetUsersInfo . La operación devuelve una matriz de objetos que contiene la dirección de correo electrónico de inicio de sesión y el identificador de cada usuario. A continuación, puede obtener los detalles de cada usuario de la lista, como sus permisos de rol y cuenta en Microsoft Advertising, llame a la operación GetUser . Al llamar a GetUser si deja el elemento UserId nil, la respuesta incluirá los detalles del usuario autenticado actual, tal como se especifica en las credenciales del encabezado de solicitud.

Este es un elemento CustomerRoles de ejemplo devuelto por la operación 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>

Cada CustomerRole representa los permisos que tiene una persona al acceder a la cuenta o conjunto de cuentas correspondientes.

• RoleId representa el rol de usuario, por ejemplo, 41 representa el rol de usuario superadministrador.
• CustomerId es el identificador del cliente donde el usuario se ha registrado o tiene alguna relación de jerarquía de cuentas.
• El elemento AccountIds contiene identificadores de cuentas de anunciante a las que el usuario puede acceder en el contexto del CustomerId.
• El elemento LinkedAccountIds contiene identificadores de cuentas de anunciante vinculadas a las que el usuario puede acceder en el contexto del CustomerId.
• CustomerLinkPermission puede limitar el rol de usuario en función de la relación de jerarquía de cuentas en el contexto del CustomerId.

Tomado de forma individual, un usuario tiene el mismo rol en customerid, accountids y linkedaccountids para un determinado CustomerRole; sin embargo, si un usuario tiene varios roles de cliente, los permisos efectivos dependen del conjunto completo de objetos CustomerRole devueltos por GetUser. A continuación se proporcionan varios ejemplos.

Ejemplo de roles para nuevo usuario

Si acaba de registrarse por primera vez con Microsoft Advertising y ha creado una nueva cuenta, la operación GetUser devolverá un objeto CustomerRole .

• RoleId es 41 porque el primer usuario de una nueva cuenta tiene el rol de usuario Superadministrador.
• CustomerId es el identificador de cliente aprovisionado al registrarse.
• El elemento AccountIds está vacío porque un superadministrador siempre puede acceder a todas las cuentas de anunciante del cliente con el identificador CustomerId .
• El elemento LinkedAccountIds está vacío porque aún no se ha vinculado a ninguna cuenta de anunciante cliente.
• CustomerLinkPermission está vacío porque puede acceder a las cuentas de anunciante directamente a través del CustomerId asignado.

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

Ejemplo de roles para credenciales de varios usuarios

Si acepta una invitación para ser un usuario de otro cliente con las credenciales de inicio de sesión existentes del ejemplo anterior, tiene credenciales de varios usuarios en Microsoft Advertising. Las credenciales de inicio de sesión asociadas directamente con cada uno de los identificadores de cliente y la operación GetUser devolverán dos objetos CustomerRole . En este ejemplo, los elementos de cada CustomerRole son equivalentes, excepto customerid. RoleId depende del rol asignado cuando el superadministrador de la cuenta de administrador L1 (id. de cliente 111) le envió la invitación.

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

Ejemplo de roles para la jerarquía de cuentas

Basándose en el ejemplo de roles para credenciales de varios usuarios (aunque no se requieren credenciales de varios usuarios para crear una jerarquía), supongamos, por ejemplo, uno de los usuarios superadministrador de la cuenta de administrador L1 (id. de cliente 111) (ya sea usted u otro superadministrador) configure una agencia Hierachy en Cuenta de administrador L1 (id. de cliente 111) con vínculos de cliente de cuenta de cliente y anunciante:

• La cuenta de administrador L1 (id. de cliente 111) se vincula a la cuenta de administrador L2 (id. de cliente 222) con un vínculo Administrativo.
• La cuenta de administrador L2 (id. de cliente 222) se vincula a la cuenta de administrador L3 (id. de cliente 333) con un vínculo Estándar.
• Los vínculos de la cuenta de administrador L3 (id. de cliente 333) a ad account 4A (id. de cuenta 444111) con un vínculo de nivel de cuenta. La cuenta de anuncio 4A (id. de cuenta 444111) está directamente en cuenta de administrador L4 (id. de cliente 444), que no se incluye en la jerarquía de nivel de cliente.

Todavía tiene acceso al cliente original al que se registró, es decir, 999, y sigue siendo un usuario directo en la cuenta de administrador L1 (id. de cliente 111). Ahora, la operación GetUser devolverá dos objetos CustomerRole adicionales, es decir, uno para la cuenta de administrador L2 (id. de cliente 222) y la cuenta de administrador L3 (id. de cliente 333). Puede acceder a todos los AccountIds y LinkedAccountIds a los que se puede acceder a través de la cuenta de administrador L2 (id. de cliente 222) y 333 respectivamente. En este ejemplo puede acceder a la cuenta de ad 4A (id. de cuenta 444111) a través de la cuenta de administrador L3 (id. de cliente 333), es decir, al llamar a operaciones de servicio que requieren el identificador de cliente, debe usar la cuenta de administrador L3 (id. de cliente 333) para acceder a la cuenta 444111.

<CustomerRoles xmlns:a="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>999</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:CustomerLinkPermission i:nil="true"/>
  </a:CustomerRole>
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>111</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:CustomerLinkPermission i:nil="true"/>
  </a:CustomerRole>
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>222</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:CustomerLinkPermission>Administrative</a:CustomerLinkPermission>
  </a:CustomerRole>
  <a:CustomerRole>
      <a:RoleId>41</a:RoleId>
      <a:CustomerId>333</a:CustomerId>
      <a:AccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
      <a:LinkedAccountIds xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
        <b:long>444111</b:long>
      </a:LinkedAccountIds>
      <a:CustomerLinkPermission>Standard</a:CustomerLinkPermission>
  </a:CustomerRole>
</CustomerRoles>

Los roles de cliente informan a los clientes a los que puede acceder, pero no siempre describen cómo obtuvo el acceso. La operación GetLinkedAccountsAndCustomersInfo devuelve la jerarquía de clientes y cuentas en el cliente especificado. Para obtener más información y ejemplos, vea Ver la jerarquía.

Ejemplo de roles para la jerarquía de agregador

Si acaba de registrarse por primera vez con Microsoft Advertising, ha obtenido credenciales de agregador y ha creado una nueva cuenta de cliente y anunciante a través de SignupCustomer, la operación GetUser devolverá dos objetos CustomerRole . Los elementos dentro de cada CustomerRole son equivalentes, excepto el RoleId. Un agregador tiene dos identificadores de rol en Microsoft Advertising, es decir, 41 y 33.

• RoleId en uno de los objetos CustomerRole es 41 porque el primer usuario de una nueva cuenta tiene el rol de usuario SuperAdministrador. RoleId en otro de los objetos CustomerRole es 33, que representa el rol de usuario agregador.
• CustomerId es el identificador de cliente aprovisionado al registrarse.
• El elemento AccountIds está vacío porque un superadministrador siempre puede acceder a todas las cuentas de anunciante del cliente con el identificador CustomerId .
• El elemento LinkedAccountIds contiene el identificador de la cuenta de anunciante en el cliente secundario que creó a través de SignupCustomer. El identificador de cliente secundario no está representado en el objeto CustomerRole . Puede llamar a GetAccount para obtener los detalles de la cuenta del anunciante, como parentCustomerId. Tenga en cuenta también que puede eliminar cuentas agregadas a través de DeleteAccount, pero no puede desvincularlas a través de UpdateClientLinks. Llame a la operación SearchClientLinks para ayudar a determinar qué cuentas se pueden desvincular.
• CustomerLinkPermission está vacío porque puede acceder a las cuentas de anunciante directamente a través del CustomerId asignado.

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

Tokens de acceso y desarrollador

Para actuar mediante programación en nombre de un usuario de Microsoft Advertising, debe obtener su consentimiento. Al final del flujo de trabajo de consentimiento, puede obtener un token de acceso que represente al usuario. El token de acceso tiene los mismos roles y acceso a las mismas cuentas que el usuario tiene en la aplicación web de Microsoft Advertising. Es decir, las mismas cuentas y permisos de rol de usuario disponibles en la aplicación web de Microsoft Advertising están disponibles para el usuario mediante programación a través de la API. Para obtener información sobre cómo obtener un token de acceso para que actúe en nombre de un usuario de Microsoft Advertising, consulte Autenticación con OAuth.

También necesitará un token de desarrollador que identifique de forma única la aplicación. La obtención de un token de desarrollador para el acceso a la API no concede permisos adicionales a ninguna cuenta de Microsoft Advertising. Un token de desarrollador permite el acceso mediante programación a las cuentas ya aprovisionadas para un usuario. Para obtener información, consulte Obtención de un token de desarrollador.

Sugerencia

Para obtener un token de acceso y realizar la primera llamada de servicio mediante bing ads API, consulte la guía de inicio rápido .

Los encabezados AuthenticationToken y DeveloperToken deben establecerse en cada solicitud a través de la API de Bing Ads. Esta es una llamada de ejemplo a la operación 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>

Credenciales de varios usuarios

Puede usar un conjunto de credenciales de varios usuarios de Microsoft Advertising para acceder a las cuentas de anunciantes entre varios clientes, potencialmente con diferentes roles de usuario y permisos.

Puede resultar útil pensar en las credenciales de "varios usuarios" para significar "varios roles de usuario", ya que desde una perspectiva solo se inicia sesión con un nombre de usuario para acceder a clientes multiusuario con permisos variables. Las credenciales de una persona pueden actuar con varios roles de usuario distintos. Por ejemplo, las credenciales de varios usuarios le conceden acceso al cliente A y al cliente B. Sin embargo, el rol de usuario Visor del cliente A le impide realizar cambios en las cuentas que pertenecen al cliente A. Pero como superadministrador para el cliente B, tiene control total sobre las cuentas de ese cliente.

Si ya tiene varios conjuntos de credenciales de inicio de sesión, puede pedir al soporte técnico que consolide un conjunto de credenciales. El rol de usuario y el acceso a la cuenta a través de cada cliente que tenía antes de la consolidación se conservan. Tenga en cuenta también que las credenciales de la misma persona se pueden asociar a conjuntos independientes de información de contacto del usuario, es decir, información de contacto única por cliente.

Para obtener más información, consulte el tema de ayuda de Microsoft Advertising Administración del nombre de usuario para acceder a varias cuentas.

Consolidación de varios usuarios

Si ya inicia sesión con varios conjuntos de credenciales, por ejemplo, dos direcciones de correo electrónico, las credenciales de varios usuarios se pueden aprovisionar manualmente. Póngase en contacto con el soporte técnico o con el administrador de cuentas para combinar los nombres de usuario existentes en un único nombre de usuario. Otra opción consiste en que se le envíe una invitación de cada cliente que quiera administrar y, a continuación, aceptar cada invitación con las credenciales de inicio de sesión que desea conservar. Esta opción está disponible a través de la aplicación web Microsoft Advertising o la operación de servicio SendUserInvitation . Una vez que acepte la invitación con las credenciales existentes de Microsoft Advertising, tendrá credenciales de "varios usuarios".

Veamos los siguientes roles y permisos de usuario antes de la consolidación de varios usuarios. En la aplicación web de Microsoft Advertising, cada usuario debe iniciar sesión por separado y tiene permisos diferentes durante cada sesión iniciada. Del mismo modo, a través de la API, el token de acceso de cada usuario (consulte Autenticación con OAuth) representa permisos limitados al usuario y rol correspondientes.

Usuario	Role	Permissions
one@contoso.com	Visor	Cliente A: todas las cuentas
two@contoso.com	Superadministrador	Cliente B: todas las cuentas
three@contoso.com	Visor	Cliente C: cuenta A
four@contoso.com	Usuario estándar	Cliente B: todas las cuentas

En primer lugar, tenga en cuenta que solo se puede consolidar una dirección de correo electrónico por cliente, por lo que en este ejemplo two@contoso.com y four@contoso.com no se puede consolidar conjuntamente. Ahora vamos a ver lo que sucede después de que los tres primeros usuarios se consoliden en one@contoso.com.

• No hay cambios para el usuario four@contoso.com , ya sea a través de la aplicación web microsoft Advertising, el Editor de Microsoft Advertising o la API.
• El usuario one@contoso.com puede iniciar sesión a través de la aplicación web Microsoft Advertising y el Editor de Microsoft Advertising. Los usuarios consolidados, es decir, two@contoso.com ya three@contoso.com no tienen permisos para iniciar sesión a través de la aplicación web microsoft Advertising o el Editor de Microsoft Advertising. Mientras ha iniciado sesión como one@contoso.com, puede cambiar el contexto a las cuentas de cliente con los roles de usuario correspondientes asignados anteriormente a two@contoso.com y three@contoso.com. Aunque puede acceder a varios clientes que han iniciado sesión con las credenciales de un usuario (one@contoso.com), deberá cambiar de cliente a cliente para administrar las cuentas vinculadas con roles de usuario únicos. Los clientes y sus cuentas relacionadas siguen siendo distintos. Para obtener más información, consulte el tema de ayuda de Microsoft Advertising Administración del nombre de usuario para acceder a varias cuentas.
• Después de la consolidación de varios usuarios, el token de acceso para el usuario one@contoso.com representará permisos para la lista consolidada (superconjunto) de cuentas. El rol de usuario en vigor dependerá de los identificadores de cliente y cuenta especificados en la solicitud de servicio. Los tokens de acceso para two@contoso.com y three@contoso.com ya no se aceptarán, es decir, se devolverá el error 120: UserLoginAccessDenied.

Información de contacto de varios usuarios

Una persona con credenciales de varios usuarios se representa mediante varios objetos User y los identificadores de usuario correspondientes. De hecho, las credenciales de la misma persona se pueden asociar a conjuntos independientes de información de contacto del usuario, es decir, información de contacto única por cliente.

La respuesta GetUser puede variar en función de quién realice la llamada, incluso con el mismo identificador de usuario. Supongamos, por ejemplo, que antes de consolidar los identificadores de one@contoso.com, two@contoso.comy three@contoso.com eran 123, 456 y 789 respectivamente. Cada identificador de usuario asigna eficazmente una persona a un cliente específico, por ejemplo, el identificador 123 se asigna one@contoso.com al cliente original al que la persona podría acceder. En este ejemplo, nos referimos a 123 como identificador de usuario original.

• Si el token de acceso para one@contoso.com se usa para llamar a GetUser y userId es nil o UserId se establece en el identificador de usuario original (por ejemplo, 123), la operación devolverá objetos CustomerRole para todos los clientes a los que el usuario pueda acceder.
• Si el token de acceso para one@contoso.com se usa para llamar a GetUser y userId se establece en 456 o 789, la operación solo devolverá un objeto CustomerRole que asigne a esta persona a un cliente específico.

La configuración de usuario Name, Lcid, JobTitle y ContactInfo para la misma persona se sincronizará automáticamente con las actualizaciones que se produzcan después de la consolidación del usuario. LastModifiedByUserId y LastModifiedTime también están sincronizados en cada objeto User devuelto, a menos que haya combinado un nombre de usuario antiguo y no haya actualizado ninguna configuración de usuario desde la consolidación.

Nota:

TimeStamp difiere de LastModifiedTime. Todos los valores de TimeStamp son únicos por usuario y, al llamar a UpdateUser , debe incluir las marcas de tiempo del usuario correspondiente (incluida la marca de tiempo de la dirección).

Por ejemplo, supongamos que no ha actualizado la información del usuario desde one@contoso.com antes de la consolidación con two@contoso.com y three@contoso.com. Después de la consolidación y hasta que la configuración del usuario se actualice después de la consolidación, seguirá observando un LastModifiedByUserId y LastModifiedTime distintos dentro de cada objeto User devuelto.

User Id	Identificador de información de contacto	Permissions	LastModifiedByUserId
123	234	Cliente A: todas las cuentas	123
456	567	Cliente B: todas las cuentas	456
789	890	Cliente C: cuenta A	789

Ahora supongamos que one@contoso.com actúa en el contexto del cliente B y actualiza su información de contacto. La información de contacto actualizada, así como los mismos LastModifiedByUserId y LastModifiedTime ahora se sincronizan en todos los objetos User devueltos.

User Id	Identificador de información de contacto	Permissions	LastModifiedByUserId
123	234	Cliente A: todas las cuentas	456
456	567	Cliente B: todas las cuentas	456
789	890	Cliente C: cuenta A	456

Jerarquía de cuentas

Las empresas de publicidad de búsqueda suelen alinearse con uno o varios de los siguientes modelos de administración de cuentas.

• Un anunciante directo crea una aplicación de API de Bing Ads para sus propias campañas publicitarias y Microsoft factura directamente los clics de anuncios válidos.
• Un proveedor de herramientas crea una aplicación de API de Bing Ads para que otras empresas administren sus campañas publicitarias y Microsoft no las factura. El usuario anunciante es el propietario de las cuentas, Microsoft factura directamente por los clics de anuncios válidos y puede pagar una cuota al proveedor de herramientas.
• Una agencia crea una aplicación de API de Bing Ads para que su empresa administre las campañas de sus clientes de publicidad. El cliente de la agencia posee las cuentas, Microsoft factura directamente por los clics de anuncios válidos y puede pagar una cuota a la agencia.
• Un agregador o revendedor crea una aplicación de API de Bing Ads para administrar las campañas de sus clientes de publicidad y Microsoft factura directamente los clics en directo válidos. El anunciante no se registra para obtener las credenciales de Microsoft Advertising y puede pagar una cuota al agregador.

Independientemente del modelo de negocio, el registro inicial y el aprovisionamiento de roles de usuario son más o menos iguales. En las secciones siguientes se describen los pasos adicionales necesarios para configurar jerarquías de agencia y agregador .

Jerarquía de agencia

Una agencia crea una aplicación de API de Bing Ads para que su empresa administre las campañas de sus clientes de publicidad. Los vínculos de cliente permiten a una agencia administrar algunos o todos los aspectos de una cuenta de anunciante. La solicitud de vínculo de cliente puede limitar el ámbito a cuentas de anunciantes de cliente individuales o a todas las cuentas del cliente.

Nota:

En el contexto de las jerarquías, un cliente también se conoce como "cuenta de administrador". Una cuenta de anunciante se conoce como "Cuenta" o "Cuenta de anunciante".

No hay ningún límite establecido para la cantidad de cuentas de cliente que se pueden vincular a una agencia; sin embargo, solo se admiten 5 niveles de profundidad para los vínculos de cuenta de administrador a cuenta de administrador. En cada nivel (L1, L2, L3, L4, L5) una cuenta de administrador podría vincularse a cualquier número de cuentas de administrador y cuentas publicitarias. Para obtener más información sobre cómo convertirse en una agencia, consulte el artículo de ayuda Administración de clientes como una agencia en Microsoft Advertising o Recursos para asociados de la agencia.

Configuración de la jerarquía

Para configurar una jerarquía para administrar las cuentas de cliente, la agencia debe enviar una invitación al cliente, que debe ser aceptada por un usuario autorizado en el cliente. Para determinar si ya existe un vínculo, llame a la operación SearchClientLinks y compruebe el elemento Status de cualquier ClientLink devuelto. Para buscar por cuenta individual, establezca el campo de predicado en ClientAccountId y establezca el valor del predicado en el identificador de cuenta que desea buscar.

Nota:

Solo un usuario con credenciales superadministrador o estándar puede agregar, actualizar y buscar vínculos de cliente a cuentas de anunciante. Solo un usuario con credenciales de superadministrador puede agregar, actualizar y buscar vínculos de cliente a los clientes.

Si existe un vínculo con el estado Active, LinkAccepted, LinkInProgress, LinkPending, UnlinkInProgress o UnlinkPending, la agencia no puede iniciar un vínculo de cliente duplicado.

Si aún no existe un vínculo de cliente a la cuenta especificada o si el ciclo de vida de un vínculo existente ha finalizado con el estado Expired, LinkCanceled, LinkDeclined, LinkFailed o Inactive, la agencia puede iniciar una nueva invitación de vínculo de cliente llamando a la operación AddClientLinks . El servicio pasa el estado del vínculo de cliente a LinkPending inmediatamente.

Importante

En el caso de los vínculos de cliente de la cuenta de anunciante, la agencia debe especificar si el cliente o la agencia serán responsables de la facturación estableciendo el elemento IsBillToClient en la solicitud de vínculo de cliente.

Para actualizar un vínculo de cliente, su elemento TimeStamp es necesario para la validación, por lo que primero debe llamar a la operación SearchClientLinks para obtener el objeto ClientLink existente. A continuación, modifique el elemento Status del ClientLink devuelto e incluya el objeto ClientLink actualizado en una llamada posterior a la operación UpdateClientLinks .

Nota:

El cliente puede aceptar o rechazar a través de una aplicación basada en la API de Bing Ads o a través de la pestaña Cuentas & facturación de la aplicación web microsoft Advertising.

El cliente solo puede usar la operación UpdateClientLinks para actualizar el estado como LinkAccepted o LinkDeclined.

• Si el cliente establece el estado en LinkDeclined, finaliza el ciclo de vida del vínculo de cliente. No se puede actualizar un vínculo de cliente rechazado y debe enviar una nueva invitación para administrar la cuenta de cliente.
• Si el cliente establece el estado en LinkAccepted, el estado pasa a LinkInProgress. Si el proceso de vínculo se realiza correctamente, el servicio actualiza el estado del vínculo de cliente a Activo.

Si el vínculo no se puede establecer, por ejemplo, debido a un error de transición de facturación, el servicio actualiza el estado del vínculo de cliente a LinkFailed. No se puede actualizar un vínculo de cliente con errores y debe enviar una nueva invitación para administrar la cuenta de cliente. Si el cliente o la agencia no toman medidas en un plazo de 30 días, el servicio establece el estado en LinkExpired y finaliza el ciclo de vida del vínculo de cliente. No puede actualizar un vínculo de cliente expirado y debe enviar una nueva invitación para administrar la cuenta de cliente.

Si el estado del vínculo de cliente es LinkPending, la agencia puede optar por cancelar una solicitud de vínculo anterior.

Si el estado del vínculo de cliente es Activo, la agencia puede optar por finalizar la relación existente con el cliente. Para iniciar el proceso de desvinculación, la agencia establece el estado del vínculo de cliente en UnlinkRequested y llama a la operación UpdateClientLinks . Al actualizar el estado con UnlinkRequested, el estado se establece de forma eficaz en UnlinkInProgress. El servicio pasa el estado del vínculo de cliente a UnlinkPending inmediatamente y, a continuación, espera a que los recursos del sistema continúen. El estado debe realizar la transición rápidamente a UnlinkInProgress.

Si se produce un error en el proceso de desvinculación, por ejemplo, debido a un error de transición de facturación, el vínculo de cliente se reanuda al estado Activo. Si el proceso de desvinculación se realiza correctamente, el estado se actualizará a Inactivo y el ciclo de vida del vínculo de cliente finaliza. No puede actualizar un vínculo de cliente inactivo y debe enviar una nueva invitación para administrar la cuenta de cliente.

Para ver ejemplos de código que muestran cómo agregar y actualizar una invitación de vínculo de cliente, vea Ejemplo de código de vínculos de cliente.

Ver la jerarquía

Una agencia tiene varias opciones para ver la jerarquía de cuentas.

• La operación GetUser devuelve roles de usuario por cliente y cuentas vinculadas. Los roles de cliente informan a los clientes a los que puede acceder, pero no siempre describen cómo obtuvo el acceso. La determinación del rol de usuario marcará una diferencia entre los vínculos de cliente administrativo y estándar. Para ver ejemplos de roles de cliente, consulte Obtención de roles de usuario.
• La operación SearchClientLinks le proporcionará el estado actual de un vínculo de cliente si ya tiene los identificadores de entidad de cliente y agencia. Por ejemplo, puede buscar administrando el identificador de cliente y el identificador de cuenta de cliente o el identificador de cliente.
• La operación GetLinkedAccountsAndCustomersInfo devuelve la jerarquía de clientes y cuentas en el cliente especificado.

Supongamos, por ejemplo, que se configuró una jerarquía de agencia en cuenta de administrador L1 (id. de cliente 111) con vínculos de cliente de cuenta de cliente y anunciante:

• Antes de configurar la jerarquía, se habían aprovisionado cuatro cuentas de administrador independientes. La cuenta de administrador L1 contiene la cuenta de anuncio 1A y la cuenta de anuncio 1B. La cuenta de administrador L2 contiene la cuenta de anuncio 2A y la cuenta de anuncio 2B. La cuenta de administrador L3 contiene la cuenta de anuncio 3A y la cuenta de anuncio 3B. La cuenta de administrador L4 contiene la cuenta de anuncio 4A y la cuenta de anuncio 4B.
• La cuenta de administrador L1 (id. de cliente 111) se vincula a la cuenta de administrador L2 (id. de cliente 222) con un vínculo Administrativo.
• La cuenta de administrador L2 (id. de cliente 222) se vincula a la cuenta de administrador L3 (id. de cliente 333) con un vínculo Estándar.
• Los vínculos de la cuenta de administrador L3 (id. de cliente 333) a ad account 4A (id. de cuenta 444111) con un vínculo de nivel de cuenta. La cuenta de anuncio 4A (id. de cuenta 444111) está directamente en cuenta de administrador L4 (id. de cliente 444), que no se incluye en la jerarquía de nivel de cliente. En este ejemplo puede acceder a la cuenta de ad 4A (id. de cuenta 444111) a través de la cuenta de administrador L3 (id. de cliente 333), es decir, al llamar a operaciones de servicio que requieren el identificador de cliente, debe usar la cuenta de administrador L3 (id. de cliente 333) para acceder a la cuenta 444111.

Un usuario con acceso a la jerarquía completa que inicie sesión en la aplicación web de Microsoft Advertising en la cuenta de administrador L1 (id. de cliente 111) tendría acceso a la siguiente vista de cuenta.

Si busca por id. de cliente 111, la respuesta GetLinkedAccountsAndCustomersInfo incluye la cuenta de anuncio 1A y la cuenta de anuncio 1B en AccountsInfo. La información sobre la cuenta de administrador L2 se devuelve en 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>

Del mismo modo, si busca por id. de cliente 222, la respuesta GetLinkedAccountsAndCustomersInfo incluye la cuenta de anuncio 2A y la cuenta de anuncio 2B en AccountsInfo. La información sobre la cuenta de administrador L3 se devuelve en 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>

Ahora, si busca por id. de cliente 333, la respuesta GetLinkedAccountsAndCustomersInfo incluye la cuenta de anuncio 3A, la cuenta de anuncio 3B y la cuenta de anuncio 4A en AccountsInfo. No se muestran cuentas de administrador en 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>

Ahora, si busca por id. de cliente 444, la respuesta GetLinkedAccountsAndCustomersInfo incluye la cuenta de anuncio 4A y la cuenta de anuncio 4B en AccountsInfo. No se muestran cuentas de administrador en 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>

Estos son algunos aspectos destacados de las respuestas de ejemplo anteriores:

• Aunque GetLinkedAccountsAndCustomersInfo parece devolver una estructura similar, ya sea solicitada por el identificador de cliente 111 o 222, hay una diferencia notable. Como se mencionó en la introducción del escenario, el vínculo de la cuenta de Mananger L1 a la cuenta de administrador L2 es un vínculo administrativo, mientras que el vínculo de la cuenta del administrador L2 a la cuenta del administrador L3 es estándar. La respuesta GetLinkedAccountsAndCustomersInfo no incluye detalles sobre el tipo de vínculo, es decir, Administrativo o Estándar. Dado que el tipo de vínculo puede refinar aún más el permiso de un usuario en función de su rol de usuario, se incluye con cada CustomerRole cuando se llama a GetUser.
• Al buscar por id. de cliente 333, no hay ninguna diferencia aparente entre la cuenta de anuncios 3A, la cuenta de anuncios 3B y la cuenta de anuncios 4A. Como se mencionó en la introducción del escenario, ad account 4A es accesible a través de un vínculo de cliente de la cuenta de anunciante, mientras que las otras cuentas están directamente contenidas por la cuenta de administrador L3. Si tiene un requisito para determinar el propietario directo de cada cuenta, puede llamar a otras operaciones de servicio, como GetAccount o SearchAccounts.
• En la jerarquía actual, la cuenta de anuncio 4B solo está disponible para los usuarios de la cuenta de administrador L4. Los usuarios de la cuenta de administrador L3 se pueden aprovisionar para acceder a 3 cuentas, los usuarios de la cuenta de administrador L2 se pueden aprovisionar para acceder a 5 cuentas y los usuarios de la cuenta de administrador L1 se pueden aprovisionar para acceder a 7 cuentas. Un superadministrador puede optar por limitar el acceso de cada usuario a un subconjunto de las cuentas disponibles.

Jerarquía de agregador

El rol de agregador se ofrece a un conjunto limitado de asociados que ofrecen herramientas y servicios de marketing de búsqueda a un gran número de anunciantes. El rol de agregador permite a los asociados crear cuentas de cliente mediante programación. El agregador se factura por factura por todos los costos de publicidad incurridos por sus clientes. Normalmente, el anunciante no se registra para obtener credenciales de Microsoft Advertising y puede pagar una cuota al agregador.

Un usuario agregador se aprovisiona en el shell de cliente principal. Como se describe en Límites de entidad , toda la actividad publicitaria está organizada por el cliente, que puede tener una o varias cuentas. Cada vez que el usuario agregador llama a SignupCustomer , se crea una nueva cuenta de anunciante dentro de un nuevo cliente.

Importante

El rol de usuario agregador es necesario para SignupCustomer. Si se agrega un usuario superadministrador al cliente agregador después de aprovisionar las credenciales iniciales, el usuario puede administrar de forma predeterminada los datos de todos los clientes que administra el agregador. El usuario no podrá llamar a SignupCustomer, pero, de lo contrario, tendrá acceso de lectura y escritura a los datos de la campaña.

La operación SignupCustomer requiere los objetos Customer y AdvertiserAccount . El objeto customer incluye el nombre del cliente, la dirección donde se encuentra el cliente, el mercado en el que opera el cliente y el sector en el que participa el cliente. Aunque es posible agregar varios clientes con los mismos detalles, debe usar nombres de cliente únicos para que los usuarios puedan distinguir fácilmente entre los clientes de una interfaz de usuario. El objeto account debe especificar el nombre de la cuenta; el tipo de moneda que se va a usar para liquidar la cuenta; y el identificador del método de pago, que debe establecerse en null. La operación genera una cuenta de factura y establece el identificador del método de pago en el identificador asociado a la factura del agregador. La facturación se acumula en el instrumento de pago del agregador y los agregadores se facturan por todos los cargos incurridos por los clientes que administran.

Obtención de credenciales de agregador

Para solicitar credenciales de agregador, póngase en contacto con el equipo de administración de cuentas designado para obtener más información sobre cómo obtener el rol agregador. Si actualmente no es agregador, pero desea convertirse en uno, vaya a la página de bienvenida del Programa de partners de Microsoft Advertising .

Consulta también

Referencia del servicio de administración de clientes
Direcciones del servicio web de la API de Bing Ads