Hierarquia de Contas e Permissões de Utilizador

  • Artigo

Os utilizadores do Microsoft Advertising podem utilizar as mesmas credenciais de início de sessão para aceder a várias contas, potencialmente com permissões diferentes em cada conta. Uma agência pode configurar uma hierarquia de contas para gerir todos os utilizadores e contas a partir de uma conta principal, utilizar uma carteira central para pagar tudo e partilhar recursos de campanha, como etiquetas de Controlo de Eventos Universais (UET) e listas de remarketing entre clientes.

Nota

No contexto das hierarquias, um Cliente também é conhecido como "Conta de gestor". Uma AdvertiserAccount é referida como uma "Conta" ou "Conta do Anunciante".

Veja Limites de Entidades para obter mais informações sobre a hierarquia de campanha numa conta.

Funções e Permissões de Utilizador

A sua aplicação só poderá ter de suportar um super Administração utilizador numa conta conhecida. Mesmo com uma estrutura de permissões relativamente simples, vai querer compreender as ações disponíveis para cada função de utilizador, como os utilizadores são aprovisionados numa conta, como pode descobrir os seus direitos de acesso atuais e como pode agir em nome de um utilizador autenticado do Microsoft Advertising com a API de Anúncios do Bing.

Funções de Utilizador

A função de utilizador concedida pelo Super Administração de um cliente ou pelo administrador do sistema de Publicidade da Microsoft determina a disponibilidade do serviço. Por exemplo, um utilizador com a função Gestor de Campanha do Anunciante pode adicionar e atualizar campanhas, mas não pode criar ou atualizar utilizadores. Salvo indicação em contrário na operação de conteúdo de referência por serviço, a tabela seguinte descreve a um nível elevado as restrições de serviço por função de utilizador.

Nota

Apenas os utilizadores do Super Administração e Standard podem ser definidos como o contacto principal de uma conta. Para obter mais detalhes sobre as funções de utilizador, consulte o tópico de ajuda Como devo proceder para conceder a alguém acesso à minha conta microsoft Advertising?.

Função de Utilizador Serviços Disponíveis
Gestor de Campanha do Anunciante Esta função tem permissões para ver contas selecionadas e adicionar, editar ou eliminar campanhas nas contas selecionadas. O Gestor de Campanha do Anunciante pode ver métodos de pagamento, mas não pode gerir tarefas de faturação e pagamento.

Estão disponíveis operações de leitura para todos os serviços.

Geralmente, as operações de escrita com o serviço de Gestão de Clientes não estão disponíveis. Uma exceção é que o Gestor de Campanha do Anunciante pode atualizar o elemento AutoTagType de uma AdvertiserAccount através da operação UpdateAccount .
Agregador Estão disponíveis operações de leitura e escrita para todos os serviços, exceto DeleteCustomer.
Utilizador padrão Esta função tem permissões para gerir campanhas e realizar algumas atividades de faturação em contas selecionadas. Esta função não pode adicionar, editar ou eliminar métodos de pagamento; adicionar ou eliminar contas. Os utilizadores padrão podem ligar e desassociar contas de anunciantes, mas não podem gerir as ligações de cliente ao nível do cliente.

Os utilizadores padrão podem gerir alguns utilizadores nas contas às quais têm acesso. Um utilizador Standard pode convidar ou eliminar outros utilizadores Padrão, Gestores de Campanha de Anunciantes e Visualizadores, e ver informações sobre todos os utilizadores no contexto do cliente atual. No entanto, os utilizadores standard não podem convidar ou eliminar um Super Administração, nem podem editar a função de um Super Administração.

Os utilizadores padrão no cliente que possua uma audiência não partilhada ou uma etiqueta UET podem atualizar as respetivas propriedades (para além do âmbito), como a descrição e o nome. Enquanto a audiência ou a etiqueta UET são partilhadas, um utilizador Standard não pode atualizar estas propriedades. Para obter mais detalhes, consulte o guia técnico Partilhar Audiências e Etiquetas UET .

Estão disponíveis operações de leitura para todos os serviços.

Geralmente, as operações de escrita com o Serviço de Faturação do Cliente e o Serviço de Gestão de Clientes não estão disponíveis. As exceções das operações disponíveis para um utilizador Standard são AddInsertionOrder, UpdateInsertionOrder e UpdateAccount.
Super Administração Esta função tem permissões completas para todas as contas. Um Super Administração pode gerir tudo o que está relacionado com faturação e pagamentos, detalhes da conta e outros utilizadores (incluindo outros Super Admins). O Super Administração pode especificar a que contas os outros utilizadores têm acesso. Ao inscrever-se como um novo cliente, o primeiro utilizador é o Super Administração.

Um utilizador do Super Administração no cliente que detém a audiência ou a etiqueta UET pode atualizar o âmbito de partilha da conta de cliente de uma audiência ou etiqueta UET. Os utilizadores super Administração em clientes principais da hierarquia também podem atualizar o âmbito. Outras propriedades de audiência ou etiqueta UET (para além do âmbito), como a descrição e o nome, só podem ser atualizadas por um utilizador de Super Administração no cliente que detém a audiência ou a etiqueta UET. Os utilizadores super Administração em clientes principais da hierarquia não podem atualizar estes detalhes. Para obter mais detalhes, consulte o guia técnico Partilhar Audiências e Etiquetas UET .

Estão disponíveis operações de leitura e escrita para todos os serviços, exceto DeleteCustomer
Visualizador Esta função tem permissões só de leitura.

Estão disponíveis operações de leitura para todos os serviços.

As permissões de super Administração em clientes ligados são restritas se a permissão de ligação (CustomerLinkPermission) for "Standard". As respetivas permissões não são restritas se a permissão de ligação for "Administrativa". Também retêm permissões completas de Super Administração aos clientes aos quais podem aceder diretamente, por exemplo, onde se inscreveram.

Permissão de Ligação do

Tenha também em atenção que, individualmente, um utilizador tem a mesma função em CustomerId, AccountIds e LinkedAccountIds para um determinado CustomerRole; no entanto, se um utilizador tiver múltiplas funções de cliente, as permissões efetivas dependem do conjunto completo de objetos CustomerRoledevolvidos pelo GetUser. São fornecidos vários exemplos em Obter Funções de Utilizador.

Atribuir Funções de Utilizador

Ao inscrever-se numa nova conta na aplicação Web Microsoft Advertising, ser-lhe-á concedida a função de utilizador Super Administração. Um Super Administração pode criar novos utilizadores com a função Gestor de Campanha do Anunciante, Super Administração, Standard ou Visualizador. A função Agregador é aprovisionada por pedido especial através do Administrador de Sistema. Para obter mais informações, veja Hierarquia do Agregador e contacte o gestor de conta.

Tecnicamente, não é possível criar utilizadores novos programaticamente; no entanto, pode utilizar a operação SendUserInvitation para convidar pessoas para se inscreverem numa conta Microsoft Advertising existente. Quando convida alguém para uma conta ou conjunto de contas, também definirá a função de utilizador. O Microsoft Advertising gera um convite por e-mail que é enviado para o convidado. Ao clicar na ligação enviada por e-mail e ao concluir o fluxo de trabalho de inscrição do Microsoft Advertising, estão a aceitar o convite para gerir contas com a função de utilizador que aprovisionou no pedido SendUserInvitation .

Nota

Uma pessoa pode utilizar as mesmas credenciais de início de sessão ao inscrever-se em novas contas e aceitar convites para contas existentes. Em ambos os casos, quando são utilizadas as mesmas credenciais para concluir o fluxo de trabalho de inscrição, considera-se que a pessoa tem Credenciais de Vários Utilizadores. Do ponto de vista de cada Super Administração gerir utilizadores no âmbito do cliente, a função do utilizador, o acesso à conta e as informações de contacto são exclusivos. Quaisquer permissões que o utilizador tenha no contexto de outro cliente não são tidas em conta ao agir no âmbito do cliente atual.

Um Super Administração tem a opção de modificar o acesso dos utilizadores a diferentes contas e potencialmente modificar a função de utilizador, por exemplo, do Visualizador para o utilizador Standard. Para atualizar a função de um utilizador, chame a operação UpdateUserRoles .

Obter Funções de Utilizador

Para obter uma lista dos utilizadores que podem aceder a uma ou mais contas de um cliente, chame a operação GetUsersInfo . A operação devolve uma matriz de objetos que contém o endereço de e-mail de início de sessão e o identificador de cada utilizador. Em seguida, pode obter os detalhes de cada utilizador na lista, como as respetivas permissões de função e conta no Microsoft Advertising, chamar a operação GetUser . Ao chamar GetUser se deixar o elemento UserId nul, a resposta incluirá detalhes para o utilizador autenticado atual, conforme especificado pelas credenciais do cabeçalho do pedido.

Eis um exemplo do elemento CustomerRoles devolvido pela operação 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 as permissões que uma pessoa tem ao aceder à conta ou conjunto de contas correspondente.

Individualmente, um utilizador tem a mesma função nos CustomerId, AccountIds e LinkedAccountIds para um determinado CustomerRole; no entanto, se um utilizador tiver múltiplas funções de cliente, as permissões efetivas dependem do conjunto completo de objetos CustomerRoledevolvidos pelo GetUser. São fornecidos vários exemplos abaixo.

Exemplo de Funções para Novo Utilizador

Se se inscreveu pela primeira vez com o Microsoft Advertising e criou uma nova conta, a operação GetUser devolverá um objeto CustomerRole .

  • O RoleId é 41 porque o primeiro utilizador de uma nova conta tem a função de utilizador Super Administração.
  • O CustomerId é o identificador do cliente aprovisionado quando se inscreveu.
  • O elemento AccountIds está vazio porque um Super Administração pode sempre aceder a todas as contas de anunciantes no cliente com o identificador CustomerId.
  • O elemento LinkedAccountIds está vazio porque ainda não está ligado a contas de anunciante cliente.
  • O CustomerLinkPermission está vazio porque pode aceder diretamente às contas do anunciante através do CustomerId atribuído.
<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>

Exemplo de Funções para Credenciais multiutilizador

Se aceitar um convite para ser um utilizador noutro cliente com as suas credenciais de início de sessão existentes do exemplo anterior, terá Credenciais multiutilizador no Microsoft Advertising. As credenciais de início de sessão associadas diretamente a cada um dos identificadores do cliente e à operação GetUser devolverão dois objetos CustomerRole . Neste exemplo, os elementos dentro de cada CustomerRole são equivalentes, exceto customerId. O RoleId depende da função atribuída quando o Super Administração da Conta de Gestor L1 (ID do cliente 111) lhe enviou o convite.

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

Exemplo de Funções para Hierarquia de Conta

Com base no Exemplo de Funções para Credenciais multiutilizador (embora as Credenciais multiutilizador não sejam necessárias para criar uma hierarquia), digamos, por exemplo, um dos utilizadores do Super Administração na Conta de Gestor L1 (ID do cliente 111) (quer o utilizador ou outro Super Administração) configure uma Agência Hierachy na Conta de Gestor L1 (ID do cliente 111) com ligações de cliente de conta de cliente e anunciante:

  • A Conta de Gestor L1 (ID do cliente 111) liga à Conta de Gestor L2 (ID do cliente 222) com uma ligação Administrativa.
  • A Conta de Gestor L2 (ID do cliente 222) liga à Conta de Gestor L3 (ID do cliente 333) com uma ligação Standard.
  • A Conta de Gestor L3 (ID do cliente 333) liga à Conta de Anúncio 4A (ID da conta 444111) com uma ligação ao nível da conta. A Conta de Anúncio 4A (ID da conta 444111) está diretamente na Conta de Gestor L4 (ID do cliente 444), que não está incluída na hierarquia ao nível do cliente.

Ainda tem acesso ao cliente original que inscreveu, ou seja, 999, e continua a ser um utilizador direto na Conta de Gestor L1 (ID do cliente 111). Agora, a operação GetUser irá devolver dois objetos CustomerRole adicionais, ou seja, um para a Conta de Gestor L2 (ID do cliente 222) e a Conta de Gestor L3 (ID do cliente 333). Pode aceder a todos os AccountIds e LinkedAccountIds acessíveis através da Conta de Gestor L2 (ID do cliente 222) e 333, respetivamente. Neste exemplo, pode aceder à Conta de Anúncio 4A (ID da conta 444111) através da Conta de Gestor L3 (ID do cliente 333), ou seja, ao chamar operações de serviço que exijam o identificador do cliente, tem de utilizar a Conta de Gestor L3 (ID do cliente 333) para aceder à conta 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>

As funções de cliente informam os clientes aos quais pode aceder, mas nem sempre descrevem como obteve o acesso. A operação GetLinkedAccountsAndCustomersInfo devolve a hierarquia do cliente e da conta no cliente especificado. Para obter detalhes e exemplos, veja Ver a Hierarquia.

Exemplo de Funções para Hierarquia de Agregador

Se se inscreveu pela primeira vez com o Microsoft Advertising, obteve as credenciais do Agregador e criou uma nova conta de cliente e anunciante através de SignupCustomer, a operação GetUser devolverá dois objetos CustomerRole . Os elementos dentro de cada CustomerRole são equivalentes, exceto o RoleId. Um Agregador tem dois identificadores de função no Microsoft Advertising, ou seja, 41 e 33.

<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 do Access e do Programador

Para agir programaticamente em nome de um utilizador do Microsoft Advertising, tem de obter o seu consentimento. No final do fluxo de trabalho de consentimento, pode obter um token de acesso que representa o utilizador. O token de acesso tem as mesmas funções e acesso às mesmas contas que o utilizador tem na aplicação Web Microsoft Advertising. Por outras palavras, as mesmas contas e permissões de função de utilizador disponíveis na aplicação Web Microsoft Advertising estão disponíveis para o utilizador através de programação através da API. Para obter informações sobre como obter um token de acesso para agir em nome de um utilizador do Microsoft Advertising, consulte Autenticação com o OAuth.

Também precisará de um token de programador que identifique exclusivamente a sua aplicação. A obtenção de um token de programador para acesso à API não concede permissões adicionais a quaisquer contas do Microsoft Advertising. Um token de programador permite o acesso programático às contas já aprovisionadas para um utilizador. Para obter informações, veja Obter um Token de Programador.

Sugestão

Para obter um token de acesso e fazer a sua primeira chamada de serviço com a API de Anúncios do Bing, veja o Guia de Introdução .

Os cabeçalhos AuthenticationToken e DeveloperToken têm de ser definidos em todos os pedidos através da API de Anúncios do Bing. Eis uma chamada de exemplo para a operação 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>

Credenciais de Vários Utilizadores

Pode utilizar um conjunto de credenciais multiutilizador do Microsoft Advertising para aceder a contas de anunciantes em vários clientes, potencialmente com diferentes funções e permissões de utilizador.

Pode ajudar pensar nas credenciais "multiutilizador" para significar "múltiplas funções de utilizador", uma vez que, numa perspetiva, só inicia sessão com um nome de utilizador para aceder a clientes multipessoais com permissões variadas. As credenciais de uma pessoa podem agir com múltiplas funções de utilizador distintas. Por exemplo, as credenciais de vários utilizadores concedem-lhe acesso ao Cliente A e ao Cliente B. No entanto, a função de utilizador visualizador do Cliente A limita-o a fazer alterações nas contas que pertencem ao Cliente A. No entanto, enquanto Super Administração para o Cliente B, tem controlo total sobre as contas desse cliente.

Se já tiver vários conjuntos de credenciais de início de sessão, pode pedir suporte para consolidar num conjunto de credenciais. A função de utilizador e o acesso à conta através de cada cliente que tinha antes da consolidação são mantidos. Tenha também em atenção que as credenciais da mesma pessoa podem ser associadas a conjuntos separados de informações de contacto do utilizador, ou seja, informações de contacto exclusivas por cliente.

Para obter mais detalhes, consulte o tópico ajuda do Microsoft Advertising Gerir o seu nome de utilizador para aceder a várias contas.

Consolidação multiutilizador

Se já iniciar sessão com vários conjuntos de credenciais, por exemplo, dois endereços de e-mail, as credenciais de vários utilizadores podem ser aprovisionadas manualmente. Contacte o suporte ou o gestor de conta para intercalar nomes de utilizador existentes num único nome de utilizador. Outra opção é enviar-lhe um convite de cada cliente que pretende gerir e, em seguida, aceitar cada convite com as credenciais de início de sessão que pretende manter. Esta opção está disponível através da aplicação Web Microsoft Advertising ou da operação do serviço SendUserInvitation . Depois de aceitar o convite com as credenciais existentes do Microsoft Advertising, terá credenciais de "vários utilizadores".

Vamos considerar as seguintes funções e permissões de utilizador antes da consolidação de vários utilizadores. Na aplicação Web Microsoft Advertising, cada utilizador tem de iniciar sessão separadamente e tem permissões diferentes durante cada sessão iniciada. Da mesma forma, através da API, o token de acesso de cada utilizador (veja Autenticação com OAuth) representa permissões limitadas ao utilizador e à função correspondentes.

Utilizador Função Permissões
one@contoso.com Visualizador Cliente A - Todas as Contas
two@contoso.com Super Administração Cliente B - Todas as Contas
three@contoso.com Visualizador Cliente C - Conta A
four@contoso.com Utilizador padrão Cliente B - Todas as Contas

Em primeiro lugar, tenha em atenção que apenas um endereço de e-mail por cliente pode ser consolidado, pelo que, neste exemplo two@contoso.com , four@contoso.com não pode ser consolidado em conjunto. Agora, vamos ver o que acontece depois de os três principais utilizadores serem consolidados em one@contoso.com.

  • Não existem alterações para o utilizador four@contoso.com , seja através da aplicação Web Microsoft Advertising, do Microsoft Advertising Editor ou da API.
  • O utilizador one@contoso.com pode iniciar sessão através da aplicação Web Microsoft Advertising e do Microsoft Advertising Editor. Os utilizadores consolidados, ou seja, two@contoso.comthree@contoso.com já não têm permissões para iniciar sessão através da aplicação Web Microsoft Advertising ou do Microsoft Advertising Editor. Com sessão iniciada como one@contoso.com, pode mudar o contexto para as contas de cliente com funções de utilizador correspondentes que tinham sido atribuídas anteriormente a two@contoso.com e three@contoso.com. Embora possa aceder a vários clientes com sessão iniciada com as credenciais de um utilizador (one@contoso.com), terá de mudar de cliente para cliente para gerir as contas associadas a funções de utilizador exclusivas. Os clientes e as respetivas contas relacionadas permanecem distintos. Para obter mais detalhes, consulte o tópico ajuda do Microsoft Advertising Gerir o seu nome de utilizador para aceder a várias contas.
  • Após a consolidação de vários utilizadores, o token de acesso do utilizador one@contoso.com representará permissões para a lista consolidada (superconjunto) de contas. A função de utilizador em vigor dependerá dos identificadores do cliente e da conta especificados no pedido de serviço. Tokens de acesso para two@contoso.com e three@contoso.com deixarão de ser aceites, ou seja, o erro 120 – UserLoginAccessDenied será devolvido.

Informações de Contacto de Vários Utilizadores

Uma pessoa com credenciais de vários utilizadores é representada por vários objetos de Utilizador e identificadores de utilizador correspondentes. Com efeito, as credenciais da mesma pessoa podem ser associadas a conjuntos separados de informações de contacto do utilizador, ou seja, informações de contacto exclusivas por cliente.

A resposta GetUser pode variar consoante quem efetua a chamada, mesmo com o mesmo identificador de utilizador. Digamos, por exemplo, que antes da consolidação dos identificadores para one@contoso.com, two@contoso.come three@contoso.com eram 123, 456 e 789, respetivamente. Cada identificador de utilizador mapeia efetivamente uma pessoa para um cliente específico, por exemplo, o identificador 123 mapeia one@contoso.com para o cliente original ao qual a pessoa poderia aceder. Neste exemplo, referimo-nos a 123 como o identificador de utilizador original.

  • Se o token de acesso para one@contoso.com for utilizado para chamar GetUser e o UserId for nulo ou UserId estiver definido para o identificador de utilizador original (por exemplo, 123), a operação devolverá objetos CustomerRole para todos os clientes a que o utilizador possa aceder.
  • Se o token de acesso para one@contoso.com for utilizado para chamar GetUser e o UserId estiver definido como 456 ou 789, a operação só devolverá um objeto CustomerRole que mapeie esta pessoa a um cliente específico.

As definições de utilizador Nome, Lcid, JobTitle e ContactInfo para a mesma pessoa serão automaticamente sincronizadas com quaisquer atualizações que ocorram após a consolidação do utilizador. O LastModifiedByUserId e o LastModifiedTime também estão sincronizados em cada objeto de Utilizador devolvido, a menos que tenha um nome de utilizador antigo intercalado e não tenha atualizado as definições de utilizador desde a consolidação.

Nota

O Carimbo de Data/Hora difere de LastModifiedTime. Todos os valores de Carimbo de Data/Hora são exclusivos por Utilizador e, quando chama UpdateUser , tem de incluir os carimbos de data/hora do utilizador correspondentes (incluindo o carimbo de data/hora do endereço).

Por exemplo, digamos que não atualizou as informações one@contoso.com do utilizador desde antes da consolidação com two@contoso.com e three@contoso.com. Após a consolidação e até que as definições do utilizador sejam atualizadas após a consolidação, continuará a observar um LastModifiedByUserId e LastModifiedTime distintos em cada objeto de Utilizador devolvido.

ID de Utilizador ID de Informações de Contacto Permissões LastModifiedByUserId
123 234 Cliente A - Todas as Contas 123
456 567 Cliente B - Todas as Contas 456
789 890 Cliente C - Conta A 789

Vamos agora supor que one@contoso.com está a agir no contexto do Cliente B e atualiza as respetivas informações de contacto. As informações de contacto atualizadas, bem como os mesmos LastModifiedByUserId e LastModifiedTime, são agora sincronizadas em todos os objetos de Utilizador devolvidos.

ID de Utilizador ID de Informações de Contacto Permissões LastModifiedByUserId
123 234 Cliente A - Todas as Contas 456
456 567 Cliente B - Todas as Contas 456
789 890 Cliente C - Conta A 456

Hierarquia de Contas

Normalmente, as empresas de publicidade de pesquisa alinham-se com um ou mais dos seguintes modelos de gestão de contas.

  • Um anunciante direto cria uma aplicação de API de Anúncios do Bing para as suas próprias campanhas publicitárias e é faturado diretamente pela Microsoft para cliques de anúncios válidos.
  • Um fornecedor de ferramentas cria uma aplicação de API de Anúncios do Bing para outras empresas gerirem as suas campanhas publicitárias e não é faturada pela Microsoft. O utilizador anunciante é proprietário das contas, é faturado diretamente pela Microsoft para cliques de anúncios válidos e pode pagar uma taxa ao fornecedor de ferramentas.
  • Uma agência cria uma aplicação de API de Anúncios do Bing para a sua empresa gerir as campanhas dos seus clientes publicitários. O cliente da agência é proprietário das contas, é faturado diretamente pela Microsoft para cliques de anúncios válidos e pode pagar uma taxa à agência.
  • Um agregador ou revendedor cria uma aplicação API de Anúncios do Bing para gerir as campanhas dos seus clientes de publicidade e é faturado diretamente pela Microsoft para cliques em direto válidos. O anunciante não se inscreve nas credenciais do Microsoft Advertising e pode pagar uma taxa ao agregador.

Independentemente do modelo de negócio, a inscrição inicial e o aprovisionamento de funções de utilizador são mais ou menos iguais. As secções abaixo abordam os passos adicionais necessários para configurar hierarquias de agências e agregadores .

Hierarquia da Agência

Uma agência cria uma aplicação de API de Anúncios do Bing para a sua empresa gerir as campanhas dos seus clientes publicitários. As ligações de cliente permitem a uma agência gerir alguns ou todos os aspetos de uma conta de anunciante. O pedido de ligação do cliente pode limitar o âmbito a contas individuais de anunciantes cliente ou a todas as contas no cliente.

Nota

No contexto das hierarquias, um Cliente também é conhecido como "Conta de gestor". Uma AdvertiserAccount é referida como uma "Conta" ou "Conta do Anunciante".

Não existe um limite definido para a quantidade de contas de cliente que podem ser associadas a uma agência; no entanto, apenas são suportados 5 níveis de profundidade para as ligações da conta de gestor para a conta de gestor. Em cada nível (L1, L2, L3, L4, L5), uma conta de gestor pode ligar a qualquer número de contas de gestor e contas de anúncios. Para obter mais informações sobre como se tornar uma agência, consulte o artigo de ajuda Gerir os seus clientes como uma agência no Microsoft Advertising ou Recursos para parceiros de agência.

Para configurar uma hierarquia para gerir contas de cliente, a agência tem de enviar um convite para o cliente, que tem de ser aceite por um utilizador autorizado no cliente cliente. Para determinar se já existe uma ligação, chame a operação SearchClientLinks e verifique o elemento Estado de qualquer ClientLink devolvido. Para procurar por conta individual, defina o campo de predicado como ClientAccountId e defina o valor de predicado para o identificador de conta que pretende localizar.

Nota

Apenas um utilizador com credenciais Super Administração ou Standard pode adicionar, atualizar e procurar ligações de cliente para contas de anunciante. Apenas um utilizador com credenciais de Super Administração pode adicionar, atualizar e procurar ligações de cliente para os clientes.

Se existir uma ligação com o estado Ativo, LinkAccepted, LinkInProgress, LinkPending, UnlinkInProgress ou UnlinkPending, a agência não pode iniciar uma ligação de cliente duplicada.

Se uma ligação de cliente para a conta especificada ainda não existir ou se o ciclo de vida de uma ligação existente tiver terminado com o estado Expirado, LinkCanceled, LinkDeclined, LinkFailed ou Inativo, a agência pode iniciar um novo convite de ligação de cliente ao chamar a operação AddClientLinks . O serviço faz a transição do estado da ligação do cliente para LinkPending imediatamente.

Importante

Para ligações de cliente de conta de anunciante, a agência tem de especificar se o cliente ou a agência será responsável pela faturação ao definir o elemento IsBillToClient no pedido de ligação do cliente.

Para atualizar uma ligação de cliente, o respetivo elemento TimeStamp é necessário para validação, pelo que primeiro tem de chamar a operação SearchClientLinks para obter o objeto ClientLink existente. Em seguida, modifique o elemento Estado da ClientLink devolvida e inclua o objeto ClientLink atualizado numa chamada subsequente para a operação UpdateClientLinks .

Nota

O cliente pode aceitar ou recusar através de uma aplicação criada na API de Anúncios do Bing ou através do separador Contas & Faturação na aplicação Web Microsoft Advertising.

O cliente só pode utilizar a operação UpdateClientLinks para atualizar o estado como LinkAccepted ou LinkDeclined.

  • Se o cliente definir o estado como LinkDeclined, o ciclo de vida da ligação do cliente termina. Não pode atualizar uma ligação de cliente recusada e tem de enviar um novo convite para gerir a conta de cliente.
  • Se o cliente definir o estado como LinkAccepted, o estado transita para LinkInProgress. Se o processo de ligação for bem-sucedido, o serviço atualiza o estado da ligação do cliente para Ativo.

Se não for possível estabelecer a ligação, por exemplo, devido a um erro de transição de faturação, o serviço atualiza o estado da ligação do cliente para LinkFailed. Não é possível atualizar uma ligação de cliente com falha e tem de enviar um novo convite para gerir a conta de cliente. Se o cliente ou a agência não tomar medidas no prazo de 30 dias, o serviço define o estado como LinkExpired e o ciclo de vida da ligação do cliente termina. Não é possível atualizar uma ligação de cliente expirada e tem de enviar um novo convite para gerir a conta de cliente.

Ligar ao Cliente

Se o estado da ligação do cliente for LinkPending, a agência pode optar por cancelar um pedido de ligação anterior.

Se o estado da ligação do cliente for Ativo, a agência pode optar por terminar a relação existente com o cliente. Para iniciar o processo de desassociação, a agência define o estado da ligação do cliente como UnlinkRequested e chama a operação UpdateClientLinks . Atualizar o estado com UnlinkRequested define eficazmente o estado como UnlinkInProgress. O serviço faz a transição do estado da ligação do cliente para UnlinkPending imediatamente e, em seguida, aguarda que os recursos do sistema prossigam. O estado deve transitar rapidamente para UnlinkInProgress.

Se o processo de desassociação falhar, por exemplo, devido a um erro de transição de faturação, a ligação do cliente será retomada para Estado ativo. Se o processo de desassociação for bem-sucedido, o estado será atualizado para Inativo e o ciclo de vida da ligação do cliente termina. Não é possível atualizar uma ligação de cliente inativa e tem de enviar um novo convite para gerir a conta de cliente.

Desassociar do Cliente

Para obter exemplos de código que mostram como adicionar e atualizar um convite de ligação de cliente, veja Exemplo de Código de Ligações de Cliente.

Ver a Hierarquia

Uma agência tem várias opções para ver a hierarquia de contas.

  • A operação GetUser devolve funções de utilizador por cliente e contas associadas. As funções de cliente informam os clientes aos quais pode aceder, mas nem sempre descrevem como obteve o acesso. Determinar a função de utilizador fará a diferença entre as ligações de cliente Administrativa e Standard. Para obter exemplos de função de cliente, veja Obter Funções de Utilizador.
  • A operação SearchClientLinks irá fornecer-lhe o estado atual de uma ligação de cliente se já tiver os identificadores de entidade de cliente e agência. Por exemplo, pode procurar ao gerir o ID do cliente e o ID da conta de cliente ou o ID do cliente do cliente.
  • A operação GetLinkedAccountsAndCustomersInfo devolve a hierarquia do cliente e da conta no cliente especificado.

Digamos, por exemplo, que uma hierarquia de agência foi configurada em Conta de Gestor L1 (ID do cliente 111) com ligações de cliente de conta de cliente e anunciante:

  • Antes da configuração da hierarquia, tinham sido aprovisionadas quatro contas de gestor separadas. A Conta de Gestor L1 contém a Conta do Ad 1A e a Conta de Anúncio 1B. A Conta de Gestor L2 contém a Conta de Anúncios 2A e a Conta de Anúncio 2B. A Conta de Gestor L3 contém a Conta de Anúncios 3A e a Conta de Anúncio 3B. A Conta de Gestor L4 contém a Conta do Ad 4A e a Conta de Anúncio 4B.
  • A Conta de Gestor L1 (ID do cliente 111) liga à Conta de Gestor L2 (ID do cliente 222) com uma ligação Administrativa.
  • A Conta de Gestor L2 (ID do cliente 222) liga à Conta de Gestor L3 (ID do cliente 333) com uma ligação Standard.
  • A Conta de Gestor L3 (ID do cliente 333) liga à Conta de Anúncio 4A (ID da conta 444111) com uma ligação ao nível da conta. A Conta de Anúncio 4A (ID da conta 444111) está diretamente na Conta de Gestor L4 (ID do cliente 444), que não está incluída na hierarquia ao nível do cliente. Neste exemplo, pode aceder à Conta de Anúncio 4A (ID da conta 444111) através da Conta de Gestor L3 (ID do cliente 333), ou seja, ao chamar operações de serviço que exijam o identificador do cliente, tem de utilizar a Conta de Gestor L3 (ID do cliente 333) para aceder à conta 444111.

Um utilizador com acesso à hierarquia completa que inicie sessão na aplicação Web Microsoft Advertising na Conta de Gestor L1 (ID do cliente 111) teria acesso à seguinte vista de conta.

Conta de Gestor com

Se procurar pelo ID de cliente 111, a resposta GetLinkedAccountsAndCustomersInfo inclui a Conta de Anúncios 1A e a Conta de Anúncio 1B em AccountsInfo. As informações sobre a Conta de Gestor L2 são devolvidas em 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>

Da mesma forma, se procurar pelo ID de cliente 222, a resposta GetLinkedAccountsAndCustomersInfo inclui a Conta de Anúncio 2A e a Conta de Anúncio 2B em AccountsInfo. As informações sobre a Conta de Gestor L3 são devolvidas em 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>

Agora, se pesquisar pelo ID de cliente 333, a resposta GetLinkedAccountsAndCustomersInfo inclui a Conta do AD 3A, a Conta de Anúncios 3B e a Conta de Anúncio 4A em AccountsInfo. Não existem contas de gestor listadas em 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>

Agora, se pesquisar pelo ID de cliente 444, a resposta GetLinkedAccountsAndCustomersInfo inclui a Conta do Ad 4A e a Conta de Anúncio 4B em AccountsInfo. Não existem contas de gestor listadas em 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>

Seguem-se algumas conclusões importantes das respostas de exemplo acima:

  • Embora GetLinkedAccountsAndCustomersInfo pareça devolver uma estrutura semelhante, quer seja pedida pelo ID de cliente 111 ou 222, existe uma diferença notável. Conforme mencionado no cenário, a ligação da Conta De Mananger L1 para a Conta de Gestor L2 é uma ligação Administrativa, ao passo que a ligação da Conta de Gestor L2 para a Conta de Gestor L3 é Standard. A resposta GetLinkedAccountsAndCustomersInfo não inclui detalhes sobre o tipo de ligação, ou seja, Administrativo ou Standard. Uma vez que o tipo de ligação pode refinar ainda mais a permissão de um utilizador consoante a respetiva função de utilizador, este é incluído em cada CustomerRole quando chama GetUser.
  • Ao procurar pelo ID de cliente 333, não existe nenhuma diferença aparente entre a Conta de Anúncios 3A, a Conta de Anúncio 3B e a Conta de Anúncio 4A. Conforme mencionado no cenário, a Ad Account 4A está acessível através de uma ligação de cliente de conta de anunciante, enquanto as outras contas estão diretamente contidas pela Conta de Gestor L3. Se tiver um requisito para determinar o proprietário direto de cada conta, pode chamar outras operações de serviço, por exemplo, GetAccount ou SearchAccounts.
  • Na hierarquia atual, a Conta de Anúncios 4B só está disponível para utilizadores na Conta de Gestor L4. Os utilizadores na Conta de Gestor L3 podem ser aprovisionados para aceder a 3 contas, os utilizadores na Conta de Gestor L2 podem ser aprovisionados para aceder a 5 contas e os utilizadores na Conta de Gestor L1 podem ser aprovisionados para aceder a 7 contas. Um Super Administração pode optar por limitar o acesso de cada utilizador a um subconjunto das contas disponíveis.

Hierarquia do Agregador

A função de agregador é oferecida a um conjunto limitado de parceiros que oferecem ferramentas e serviços de marketing de pesquisa a um grande número de anunciantes. A função de agregador permite que os parceiros criem programaticamente novas contas de clientes. O agregador é faturado por fatura de todos os custos de publicidade incorridos pelos clientes. Normalmente, o anunciante não se inscreve nas credenciais do Microsoft Advertising e pode pagar uma taxa ao agregador.

Um utilizador agregador é aprovisionado na shell do cliente principal. Conforme descrito em Limites de Entidade, toda a atividade de publicidade é organizada pelo cliente, que pode ter uma ou mais contas. Sempre que SignupCustomer é chamado pelo utilizador agregador, é criada uma nova conta de anunciante num novo cliente.

Importante

A função de utilizador Agregador é necessária para SignupCustomer. Se um utilizador do Super Administração for adicionado ao cliente agregador após as credenciais iniciais serem aprovisionadas, por predefinição, o utilizador pode gerir os dados de todos os clientes que o agregador gere. O utilizador não poderá chamar SignupCustomer, mas terá acesso de leitura e escrita aos dados da campanha.

A operação SignupCustomer requer os objetos Customer e AdvertiserAccount . O objeto do cliente inclui o nome do cliente, o endereço onde o cliente está localizado, o mercado no qual o cliente opera e o setor no qual o cliente participa. Embora seja possível adicionar vários clientes com os mesmos detalhes, deve utilizar nomes de clientes exclusivos para que os utilizadores possam distinguir facilmente entre clientes numa interface de utilizador. O objeto de conta tem de especificar o nome da conta; o tipo de moeda a utilizar para liquidar a conta; e o identificador do método de pagamento, que tem de ser definido como nulo. A operação gera uma conta de fatura e define o identificador do método de pagamento para o identificador associado à fatura do agregador. A faturação é acumulada no instrumento de pagamento do agregador e os agregadores são faturados por todos os custos incorridos pelos clientes que gerem.

Como Obter Credenciais do Agregador

Para pedir credenciais de agregador, contacte a equipa de gestão de conta designada para obter detalhes sobre como obter a função de Agregador. Se não for atualmente um agregador, mas quiser tornar-se um, aceda à página de boas-vindas do Programa de Parceiros de Publicidade da Microsoft .

See Also

Referência do Serviço de Gestão de Clientes
Endereços do Serviço Web da API de Anúncios do Bing