Gerarchia account e autorizzazioni utente

Gli utenti di Microsoft Advertising possono usare le stesse credenziali di accesso per accedere a più account, potenzialmente con autorizzazioni diverse per ogni account. Un'agenzia può configurare una gerarchia di account per gestire tutti gli utenti e gli account da un account padre, usare un portafoglio centrale per pagare tutto e condividere risorse della campagna, ad esempio tag UET ( Universal Event Tracking ) e elenchi di remarketing tra i clienti.

• Ruoli utente e autorizzazioni descrive le azioni disponibili per ogni ruolo utente, il provisioning degli utenti in un account, come è possibile individuare i diritti di accesso correnti e come agire per conto di un utente autenticato di Microsoft Advertising con l'API Bing Ads.
• Credenziali multiutenti descrive come usare un set di credenziali di Microsoft Advertising per accedere agli account degli inserzionisti tra più clienti, potenzialmente con ruoli utente e autorizzazioni diversi. Se si dispone già di più set di credenziali di accesso, è possibile chiedere al supporto di consolidare un set di credenziali.
• Gerarchia account descrive come è possibile fornire l'accesso a una gerarchia di account per uno o più utenti di un cliente. In modo efficace è possibile gestire tutti gli utenti e gli account da un account padre e usare un portafoglio centrale per pagare tutto. Inoltre, con le gerarchie, è possibile condividere le risorse della campagna, ad esempio tag UET ( Universal Event Tracking ) ed elenchi di remarketing tra i clienti.

Per altre informazioni sulla gerarchia della campagna all'interno di un account, vedere Limiti di entità .

Ruoli utente e autorizzazioni

L'applicazione potrebbe dover supportare solo un utente amministratore con privilegi avanzati in un account noto. Anche con una struttura di autorizzazione relativamente semplice, è consigliabile comprendere le azioni disponibili per ogni ruolo utente, come viene effettuato il provisioning degli utenti in un account, come è possibile individuare i diritti di accesso correnti e come agire per conto di un utente di Microsoft Advertising autenticato con l'API Bing Ads.

Ruoli utente

Il ruolo utente concesso dal superamministratore di un cliente o dall'amministratore del sistema Microsoft Advertising determina la disponibilità del servizio. Ad esempio, un utente con il ruolo Advertiser Campaign Manager può aggiungere e aggiornare le campagne, ma non può creare o aggiornare gli utenti. Se non diversamente indicato nell'operazione relativa al contenuto di riferimento per servizio, la tabella seguente descrive a livello generale le restrizioni del servizio per ogni ruolo utente.

Le autorizzazioni di amministratore con privilegi avanzati per i clienti collegati sono limitate se l'autorizzazione di collegamento (CustomerLinkPermission) è "Standard". Le relative autorizzazioni non sono limitate se l'autorizzazione di collegamento è "Amministrativa". Mantengono anche le autorizzazioni superamministratore complete per i clienti a cui possono accedere direttamente, ad esempio, dove si sono registrati.

Si noti anche che, singolarmente, un utente ha lo stesso ruolo in CustomerId, AccountIds e LinkedAccountIds per un determinato CustomerRole; Tuttavia, se un utente ha più ruoli cliente, le autorizzazioni effettive dipendono dall'intero set di oggetti CustomerRole restituito da GetUser. In Recupera ruoli utente sono disponibili diversi esempi.

Assegnare ruoli utente

Quando ti iscrivi per un nuovo account nell'applicazione Web Microsoft Advertising, ti verrà concesso il ruolo utente Super Admin. Un amministratore con privilegi avanzati può creare nuovi utenti con il ruolo Advertiser Campaign Manager, Super Admin, Standard o Viewer. Il provisioning del ruolo Aggregator viene eseguito tramite richiesta speciale tramite l'amministratore di sistema. Per altre informazioni, vedere Gerarchia aggregatore e contattare il responsabile dell'account.

Tecnicamente non è possibile creare nuovi utenti a livello di codice; tuttavia, è possibile usare l'operazione SendUserInvitation per invitare gli utenti a iscriversi con un account Microsoft Advertising esistente. Quando si invita un utente a un account o a un set di account, si imposterà anche il ruolo utente. Microsoft Advertising genera un invito tramite posta elettronica inviato all'invitato. Facendo clic sul collegamento inviato tramite posta elettronica e completando il flusso di lavoro di iscrizione a Microsoft Advertising, accettano l'invito a gestire gli account con il ruolo utente di cui è stato effettuato il provisioning nella richiesta SendUserInvitation .

Un amministratore con privilegi avanzati ha la possibilità di modificare l'accesso degli utenti a account diversi e potenzialmente modificare il ruolo utente , ad esempio dal Visualizzatore all'utente Standard. Per aggiornare il ruolo di un utente, chiamare l'operazione UpdateUserRoles .

Ottenere ruoli utente

Per ottenere un elenco degli utenti che possono accedere a uno o più account di un cliente, chiamare l'operazione GetUsersInfo . L'operazione restituisce una matrice di oggetti che contiene l'indirizzo di posta elettronica di accesso e l'identificatore di ogni utente. È quindi possibile ottenere i dettagli di ogni utente nell'elenco, ad esempio il ruolo e le autorizzazioni dell'account in Microsoft Advertising, chiamare l'operazione GetUser . Quando si chiama GetUser se si lascia l'elemento UserId nil, la risposta includerà i dettagli per l'utente autenticato corrente, come specificato dalle credenziali dell'intestazione della richiesta.

Di seguito è riportato un esempio di elemento CustomerRoles restituito dall'operazione 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>

Ogni CustomerRole rappresenta le autorizzazioni di una persona quando accede all'account o al set di account corrispondente.

• RoleId rappresenta il ruolo utente, ad esempio 41 rappresenta il ruolo utente Super Admin.
• CustomerId è l'identificatore del cliente in cui l'utente ha effettuato l'iscrizione o ha una relazione di gerarchia dell'account.
• L'elemento AccountIds contiene gli identificatori degli account dell'inserzionista a cui l'utente può accedere nel contesto di CustomerId.
• L'elemento LinkedAccountIds contiene gli identificatori degli account dell'inserzionista collegato a cui l'utente può accedere nel contesto di CustomerId.
• CustomerLinkPermission può limitare il ruolo utente a seconda della relazione di gerarchia dell'account nel contesto di CustomerId.

Preso singolarmente, un utente ha lo stesso ruolo in CustomerId, AccountIds e LinkedAccountIds per un determinato CustomerRole; Tuttavia, se un utente ha più ruoli cliente, le autorizzazioni effettive dipendono dall'intero set di oggetti CustomerRole restituito da GetUser. Di seguito sono riportati alcuni esempi.

Esempio di ruoli per il nuovo utente

Se ti sei appena iscritto per la prima volta a Microsoft Advertising e hai creato un nuovo account, l'operazione GetUser restituirà un oggetto CustomerRole .

• RoleId è 41 perché il primo utente di un nuovo account ha il ruolo utente Super Admin.
• CustomerId è l'identificatore del cliente di cui è stato effettuato il provisioning al momento dell'iscrizione.
• L'elemento AccountIds è vuoto perché un amministratore con privilegi avanzati può sempre accedere a tutti gli account dell'inserzionista nel cliente con l'identificatore CustomerId .
• L'elemento LinkedAccountIds è vuoto perché non è ancora stato collegato ad alcun account dell'inserzionista client.
• CustomerLinkPermission è vuoto perché è possibile accedere agli account dell'inserzionista direttamente tramite il CustomerId assegnato.

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

Esempio di ruoli per le credenziali con più utenti

Se si accetta un invito a essere un utente di un altro cliente con le credenziali di accesso esistenti dell'esempio precedente, si dispone di credenziali multiutente in Microsoft Advertising. Le credenziali di accesso direttamente associate a ognuno degli identificatori del cliente e l'operazione GetUser restituiscono due oggetti CustomerRole . In questo esempio gli elementi all'interno di ogni CustomerRole sono equivalenti ad eccezione di CustomerId. Il RoleId dipende dal ruolo assegnato quando l'account L1 super amministratore di Manager (ID cliente 111) ha inviato l'invito.

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

Esempio di ruoli per la gerarchia di account

Sulla base dell'esempio di ruoli per le credenziali multiutente (anche se le credenziali multiutente non sono necessarie per creare una gerarchia), si supponga, ad esempio, che uno degli utenti superamministratore nell'account manager L1 (ID cliente 111) (se l'utente o un altro superamministratore) abbia configurato un account Hierachy dell'agenzia in Account manager L1 (ID cliente 111) con i collegamenti client dell'account cliente e inserzionista:

• Account manager L1 (ID cliente 111) collegamenti all'account manager L2 (ID cliente 222) con un collegamento amministrativo.
• L'account manager L2 (ID cliente 222) si collega all'account manager L3 (ID cliente 333) con un collegamento Standard.
• L'account manager L3 (ID cliente 333) si collega all'account pubblicitario 4A (ID account 444111) con un collegamento a livello di account. L'account pubblicitario 4A (ID account 444111) si trova direttamente nell'account manager L4 (ID cliente 444), che a sua volta non è incluso nella gerarchia a livello di cliente.

Si ha comunque accesso al cliente originale registrato, ad esempio 999, e si è ancora un utente diretto nell'account manager L1 (ID cliente 111). Ora l'operazione GetUser restituirà due oggetti CustomerRole aggiuntivi, ad esempio uno per l'account manager L2 (ID cliente 222) e l'account manager L3 (ID cliente 333). È possibile accedere a tutti gli AccountId e LinkedAccountId accessibili rispettivamente tramite l'account manager L2 (ID cliente 222) e 333. In questo esempio è possibile accedere all'account ad 4A (ID account 444111) tramite l'account di gestione L3 (ID cliente 333), ad esempio quando si chiamano operazioni di servizio che richiedono l'identificatore del cliente, è necessario usare l'account manager L3 (ID cliente 333) per accedere all'account 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>

I ruoli dei clienti informano a quali clienti è possibile accedere, ma non sempre descrivono come è stato ottenuto l'accesso. L'operazione GetLinkedAccountsAndCustomersInfo restituisce il cliente e la gerarchia dell'account sotto il cliente specificato. Per informazioni dettagliate ed esempi, vedere Visualizzare la gerarchia.

Esempio di ruoli per la gerarchia di aggregatori

Se ti sei appena iscritto per la prima volta a Microsoft Advertising, hai ottenuto le credenziali di Aggregator e hai creato un nuovo cliente e un nuovo account inserzionista tramite SignupCustomer, l'operazione GetUser restituirà due oggetti CustomerRole . Gli elementi all'interno di ogni CustomerRole sono equivalenti ad eccezione di RoleId. Un aggregatore ha due identificatori di ruolo in Microsoft Advertising, ad esempio 41 e 33.

• RoleId in uno degli oggetti CustomerRole è 41 perché il primo utente di un nuovo account ha il ruolo utente Super Admin. Il RoleId in un altro oggetto CustomerRole è 33, che rappresenta il ruolo utente aggregatore.
• CustomerId è l'identificatore del cliente di cui è stato effettuato il provisioning al momento dell'iscrizione.
• L'elemento AccountIds è vuoto perché un amministratore con privilegi avanzati può sempre accedere a tutti gli account dell'inserzionista nel cliente con l'identificatore CustomerId .
• L'elemento LinkedAccountIds contiene l'identifer dell'account dell'inserzionista nel cliente figlio creato tramite SignupCustomer. L'identificatore del cliente figlio non è rappresentato nell'oggetto CustomerRole . Puoi chiamare GetAccount per ottenere i dettagli dell'account dell'inserzionista, ad esempio parentCustomerId. Si noti anche che è possibile eliminare gli account aggregati tramite DeleteAccount, ma non è possibile scollegarli tramite UpdateClientLinks. Chiamare l'operazione SearchClientLinks per determinare quali account possono essere scollegati.
• CustomerLinkPermission è vuoto perché è possibile accedere agli account dell'inserzionista direttamente tramite il CustomerId assegnato.

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

Token di accesso e sviluppo

Per agire a livello di codice per conto di un utente di Microsoft Advertising, è necessario ottenere il consenso. Alla fine del flusso di lavoro di consenso è possibile ottenere un token di accesso che rappresenta l'utente. Il token di accesso ha gli stessi ruoli e gli stessi account dell'utente nell'applicazione Web Microsoft Advertising. In altre parole, gli stessi account e le stesse autorizzazioni del ruolo utente disponibili nell'applicazione Web Microsoft Advertising sono disponibili per l'utente a livello di codice tramite l'API. Per informazioni su come ottenere un token di accesso per agire per conto di un utente di Microsoft Advertising, vedere Autenticazione con OAuth.

Sarà anche necessario un token per sviluppatori che identifichi in modo univoco l'applicazione. Il recupero di un token di sviluppo per l'accesso api non concede autorizzazioni aggiuntive ad alcun account Microsoft Advertising. Un token per sviluppatori consente l'accesso a livello di codice agli account di cui è già stato effettuato il provisioning per un utente. Per informazioni, vedere Ottenere un token per sviluppatori.

Le intestazioni AuthenticationToken e DeveloperToken devono essere impostate in ogni richiesta tramite l'API Bing Ads. Di seguito è riportato un esempio di chiamata all'operazione 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>

Credenziali per più utenti

È possibile usare un set di credenziali multi-utente di Microsoft Advertising per accedere agli account degli inserzionisti tra più clienti, potenzialmente con ruoli utente e autorizzazioni diversi.

Può essere utile pensare alle credenziali "multiutete" per indicare "più ruoli utente", poiché da un punto di vista si accede con un solo nome utente per accedere a clienti multiplo con autorizzazioni diverse. Le credenziali di una persona possono agire con più ruoli utente distinti. Ad esempio, le credenziali multi-utente consentono di accedere al cliente A e al cliente B. Tuttavia, il ruolo utente Visualizzatore per il cliente A impedisce di apportare modifiche agli account appartenenti al cliente A. Tuttavia, in qualità di amministratore con privilegi avanzati per il cliente B, si ha il controllo completo sugli account del cliente.

Se si dispone già di più set di credenziali di accesso, è possibile chiedere al supporto di consolidare un set di credenziali. Il ruolo utente e l'accesso all'account tramite ogni cliente che si aveva prima del consolidamento vengono conservati. Si noti inoltre che le credenziali della stessa persona possono essere associate a set separati di informazioni di contatto utente, ad esempio informazioni di contatto univoche per cliente.

Per altri dettagli, vedere l'argomento della Guida di Microsoft Advertising Gestione del nome utente per accedere a più account.

Consolidamento di più utenti

Se si esegue già l'accesso con più set di credenziali, ad esempio due indirizzi di posta elettronica, è possibile effettuare manualmente il provisioning delle credenziali multiutenza. Contattare il supporto tecnico o il gestore account per unire i nomi utente esistenti in un singolo nome utente. Un'altra opzione consiste nell'inviare un invito da ogni cliente che si vuole gestire e quindi accettare ogni invito usando le credenziali di accesso che si desidera mantenere. Questa opzione è disponibile tramite l'applicazione Web Microsoft Advertising o l'operazione del servizio SendUserInvitation . Dopo aver accettato l'invito con le credenziali di Microsoft Advertising esistenti, si avranno le credenziali "multi-utente".

Prima di consolidare più utenti, si considerino i ruoli utente e le autorizzazioni seguenti. Nell'applicazione Web Microsoft Advertising ogni utente deve accedere separatamente e dispone di autorizzazioni diverse durante ogni sessione di accesso. Analogamente, tramite l'API, il token di accesso di ogni utente (vedere Autenticazione con OAuth) rappresenta autorizzazioni limitate all'utente e al ruolo corrispondenti.

Si noti innanzitutto che è possibile consolidare un solo indirizzo di posta elettronica per cliente, quindi in questo esempio two@contoso.com non four@contoso.com è possibile consolidare insieme. Ora vediamo cosa accade dopo che i primi tre utenti sono stati consolidati in one@contoso.com.

• Nessuna modifica per l'utente four@contoso.com tramite l'applicazione Web Microsoft Advertising, Microsoft Advertising Editor o l'API.
• L'utente one@contoso.com può accedere tramite l'applicazione Web Microsoft Advertising e Microsoft Advertising Editor. Gli utenti consolidati, ad esempio, two@contoso.com e three@contoso.com non hanno più le autorizzazioni per accedere tramite l'applicazione Web Microsoft Advertising o Microsoft Advertising Editor. Durante l'accesso come one@contoso.com, è possibile passare il contesto agli account del cliente con i ruoli utente corrispondenti assegnati in precedenza a two@contoso.com e three@contoso.com. Anche se è possibile accedere a più clienti connessi con le credenziali di un utente (one@contoso.com), è necessario passare dal cliente al cliente per gestire gli account collegati con ruoli utente univoci. I clienti e i relativi account rimangono distinti. Per altri dettagli, vedere l'argomento della Guida di Microsoft Advertising Gestione del nome utente per accedere a più account.
• Dopo il consolidamento multiutente, il token di accesso per l'utente one@contoso.com rappresenterà le autorizzazioni per l'elenco consolidato (superset) di account. Il ruolo utente in vigore dipenderà dagli identificatori del cliente e dell'account specificati nella richiesta di servizio. I token di accesso per two@contoso.com e three@contoso.com non verranno più accettati, ad esempio, verrà restituito l'errore 120 - UserLoginAccessDenied.

Informazioni di contatto per più utenti

Una persona con credenziali multiutente è rappresentata da più oggetti User e dagli identificatori utente corrispondenti. In effetti, le credenziali della stessa persona possono essere associate a set separati di informazioni di contatto utente, ad esempio informazioni di contatto univoche per cliente.

La risposta GetUser può variare a seconda di chi effettua la chiamata, anche con lo stesso identificatore utente. Si supponga, ad esempio, che prima di consolidare gli identificatori per one@contoso.com, two@contoso.come three@contoso.com fossero rispettivamente 123, 456 e 789. Ogni identificatore utente esegue il mapping di una persona a un cliente specifico, ad esempio l'identificatore 123 viene mappato one@contoso.com al cliente originale a cui la persona potrebbe accedere. In questo esempio si fa riferimento a 123 come identificatore utente originale.

• Se il token di accesso per viene usato per one@contoso.com chiamare GetUser e UserId è nil o UserId è impostato sull'identificatore utente originale (ad esempio, 123), l'operazione restituirà oggetti CustomerRole per tutti i clienti a cui l'utente può accedere.
• Se il token di accesso per viene usato per one@contoso.com chiamare GetUser e UserId è impostato su 456 o 789, l'operazione restituirà solo un oggetto CustomerRole che esegue il mapping di questa persona a un cliente specifico.

Le impostazioni utente Name, Lcid, JobTitle e ContactInfo per la stessa persona verranno sincronizzate automaticamente con tutti gli aggiornamenti che si verificano dopo il consolidamento degli utenti. Anche LastModifiedByUserId e LastModifiedTime sono sincronizzati tra ogni oggetto User restituito, a meno che non sia stato unito un nome utente precedente e non siano state aggiornate le impostazioni utente dopo il consolidamento.

Si supponga, ad esempio, di non aver aggiornato le informazioni utente da one@contoso.com prima del consolidamento con two@contoso.com e three@contoso.com. Dopo il consolidamento e fino a quando le impostazioni utente non vengono aggiornate dopo il consolidamento, si continuerà a osservare un oggetto LastModifiedByUserId e LastModifiedTime distinti all'interno di ogni oggetto User restituito.

Si supponga ora che one@contoso.com funzioni nel contesto del cliente B e aggiorni le informazioni di contatto. Le informazioni di contatto aggiornate e gli stessi LastModifiedByUserId e LastModifiedTime vengono ora sincronizzati tra tutti gli oggetti User restituiti.

Gerarchia account

Le attività di ricerca pubblicitaria sono in genere allineate a uno o più dei modelli di gestione degli account seguenti.

• Un inserzionista diretto crea un'applicazione API Bing Ads per le proprie campagne pubblicitarie e viene fatturato direttamente da Microsoft per i clic sugli annunci validi.
• Un provider di strumenti crea un'applicazione API Bing Ads per consentire ad altre aziende di gestire le campagne pubblicitarie e non viene fatturato da Microsoft. L'utente dell'inserzionista è proprietario degli account, viene fatturato direttamente da Microsoft per i clic sugli annunci validi e può pagare una tariffa al provider di strumenti.
• Un'agenzia crea un'applicazione API Bing Ads per consentire all'azienda di gestire le campagne dei propri clienti pubblicitari. Il cliente dell'agenzia possiede gli account, viene fatturato direttamente da Microsoft per clic pubblicitari validi e può pagare una tariffa all'agenzia.
• Un aggregatore o un rivenditore crea un'applicazione API Bing Ads per gestire le campagne dei client pubblicitari e viene fatturata direttamente da Microsoft per i clic live validi. L'inserzionista non si iscrive alle credenziali di Microsoft Advertising e può pagare una tariffa all'aggregatore.

Indipendentemente dal modello di business, l'iscrizione iniziale e il provisioning dei ruoli utente sono più o meno uguali. Le sezioni seguenti illustrano i passaggi aggiuntivi necessari per configurare le gerarchie di agenzie e aggregatori .

Gerarchia dell'agenzia

Un'agenzia crea un'applicazione API Bing Ads per consentire all'azienda di gestire le campagne dei propri clienti pubblicitari. I collegamenti client consentono a un'agenzia di gestire alcuni o tutti gli aspetti di un account inserzionista. La richiesta di collegamento client può limitare l'ambito ai singoli account dell'inserzionista client o a tutti gli account del cliente.

Non è previsto alcun limite per la quantità di account client che possono essere collegati a un'agenzia; tuttavia, solo 5 livelli di profondità sono supportati per i collegamenti account manager a account manager. A ogni livello (L1, L2, L3, L4, L5) un account manager potrebbe collegarsi a un numero qualsiasi di account manager e di annunci. Per altre informazioni su come diventare un'agenzia, vedere l'articolo della Guida Gestione dei clienti come agenzia su Microsoft Advertising o Risorse per i partner dell'agenzia.

Configurare la gerarchia

Per configurare una gerarchia per gestire gli account client, l'agenzia deve inviare un invito al client, che deve quindi essere accettato da un utente autorizzato nel cliente client. Per determinare se esiste già un collegamento, chiamare l'operazione SearchClientLinks e controllare l'elemento Status di qualsiasi oggetto ClientLink restituito. Per eseguire la ricerca per singolo account, impostare il campo predicato su ClientAccountId e impostare il valore del predicato sull'identificatore dell'account che si desidera trovare.

Se esiste un collegamento con stato Attivo, LinkAccepted, LinkInProgress, LinkPending, UnlinkInProgress o UnlinkPending, l'agenzia non può avviare un collegamento client duplicato.

Se un collegamento client all'account specificato non esiste ancora o se il ciclo di vita di un collegamento esistente è terminato con lo stato Scaduto, LinkCanceled, LinkDeclined, LinkFailed o Inactive, l'agenzia può avviare un nuovo invito al collegamento client chiamando l'operazione AddClientLinks . Il servizio esegue immediatamente la transizione dello stato del collegamento client a LinkPending.

Per aggiornare un collegamento client, il relativo elemento TimeStamp è necessario per la convalida, quindi è necessario chiamare prima l'operazione SearchClientLinks per ottenere l'oggetto ClientLink esistente. Modificare quindi l'elemento Status dell'oggetto ClientLink restituito e includere l'oggetto ClientLink aggiornato in una chiamata successiva all'operazione UpdateClientLinks .

Il client può usare solo l'operazione UpdateClientLinks per aggiornare lo stato come LinkAccepted o LinkDeclined.

• Se il client imposta lo stato su LinkDeclined, il ciclo di vita del collegamento client termina. Non è possibile aggiornare un collegamento client rifiutato ed è necessario inviare un nuovo invito per gestire l'account client.
• Se il client imposta lo stato su LinkAccepted, lo stato passa a LinkInProgress. Se il processo di collegamento ha esito positivo, il servizio aggiorna lo stato del collegamento client in Attivo.

Se non è possibile stabilire il collegamento, ad esempio a causa di un errore di transizione della fatturazione, il servizio aggiorna lo stato del collegamento client a LinkFailed. Non è possibile aggiornare un collegamento client non riuscito ed è necessario inviare un nuovo invito per gestire l'account client. Se il client o l'agenzia non interviene entro 30 giorni, il servizio imposta lo stato su LinkExpired e termina il ciclo di vita del collegamento client. Non è possibile aggiornare un collegamento client scaduto ed è necessario inviare un nuovo invito per gestire l'account client.

Se lo stato del collegamento client è LinkPending, l'agenzia può scegliere di annullare una richiesta di collegamento precedente.

Se lo stato del collegamento client è Attivo, l'agenzia può scegliere di terminare la relazione esistente con il client. Per avviare il processo di scollegamento, l'agenzia imposta lo stato del collegamento client su UnlinkRequested e chiama l'operazione UpdateClientLinks . L'aggiornamento dello stato con UnlinkRequested imposta in modo efficace lo stato su UnlinkInProgress. Il servizio passa immediatamente lo stato del collegamento client a UnlinkPending e quindi attende che le risorse di sistema procedano. Lo stato deve passare rapidamente a UnlinkInProgress.

Se ad esempio il processo di scollegazione ha esito negativo, a causa di un errore di transizione della fatturazione, il collegamento client riprende allo stato Attivo. Se il processo di scollegazione ha esito positivo, lo stato verrà aggiornato in Inattivo e il ciclo di vita del collegamento client termina. Non è possibile aggiornare un collegamento client inattivo ed è necessario inviare un nuovo invito per gestire l'account client.

Per esempi di codice che illustrano come aggiungere e aggiornare un invito al collegamento client, vedere Esempio di codice dei collegamenti client.

Visualizzare la gerarchia

Un'agenzia ha diverse opzioni per visualizzare la gerarchia degli account.

• L'operazione GetUser restituisce ruoli utente per cliente e account collegati. I ruoli dei clienti informano a quali clienti è possibile accedere, ma non sempre descrivono come è stato ottenuto l'accesso. La determinazione del ruolo utente farà la differenza tra i collegamenti client amministrativi e standard. Per esempi di ruolo del cliente, vedere Ottenere i ruoli utente.
• L'operazione SearchClientLinks fornirà lo stato corrente di un collegamento client se sono già presenti gli identificatori di entità dell'agenzia e del client. Ad esempio, è possibile eseguire ricerche gestendo l'ID cliente e l'ID account client o l'ID cliente client.
• L'operazione GetLinkedAccountsAndCustomersInfo restituisce il cliente e la gerarchia dell'account sotto il cliente specificato.

Si supponga, ad esempio, che una gerarchia dell'agenzia sia stata configurata nell'account manager L1 (ID cliente 111) con i collegamenti client dell'account cliente e dell'inserzionista:

• Prima dell'installazione della gerarchia, era stato effettuato il provisioning di quattro account manager separati. L'account manager L1 contiene l'account pubblicitario 1A e l'account pubblicitario 1B. L'account manager L2 contiene l'account pubblicitario 2A e l'account pubblicitario 2B. L'account manager L3 contiene l'account pubblicitario 3A e l'account pubblicitario 3B. L'account manager L4 contiene l'account pubblicitario 4A e l'account pubblicitario 4B.
• Account manager L1 (ID cliente 111) collegamenti all'account manager L2 (ID cliente 222) con un collegamento amministrativo.
• L'account manager L2 (ID cliente 222) si collega all'account manager L3 (ID cliente 333) con un collegamento Standard.
• L'account manager L3 (ID cliente 333) si collega all'account pubblicitario 4A (ID account 444111) con un collegamento a livello di account. L'account pubblicitario 4A (ID account 444111) si trova direttamente nell'account manager L4 (ID cliente 444), che a sua volta non è incluso nella gerarchia a livello di cliente. In questo esempio è possibile accedere all'account ad 4A (ID account 444111) tramite l'account di gestione L3 (ID cliente 333), ad esempio quando si chiamano operazioni di servizio che richiedono l'identificatore del cliente, è necessario usare l'account manager L3 (ID cliente 333) per accedere all'account 444111.

Un utente con accesso alla gerarchia completa che accede all'applicazione Web Microsoft Advertising nell'account manager L1 (ID cliente 111) avrà accesso alla visualizzazione account seguente.

Se si esegue una ricerca in base all'ID cliente 111, la risposta GetLinkedAccountsAndCustomersInfo include l'account ad 1A e l'account pubblicitario 1B in AccountsInfo. Le informazioni sull'account manager L2 vengono restituite all'interno di 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>

Analogamente, se si esegue una ricerca in base all'ID cliente 222, la risposta GetLinkedAccountsAndCustomersInfo include l'account ad 2A e l'account pubblicitario 2B in AccountsInfo. Le informazioni sull'account manager L3 vengono restituite all'interno di 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>

Se si esegue la ricerca in base all'ID cliente 333, la risposta GetLinkedAccountsAndCustomersInfo include l'account ad 3A, l'account pubblicitario 3B e l'account ad 4A all'interno di AccountsInfo. All'interno di CustomersInfo non sono elencati account di gestione.

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

Se si esegue la ricerca in base all'ID cliente 444, la risposta GetLinkedAccountsAndCustomersInfo include l'account Ad 4A e l'account pubblicitario 4B in AccountsInfo. All'interno di CustomersInfo non sono elencati account di gestione.

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

Di seguito sono riportati alcuni esempi degni di nota delle risposte di esempio precedenti:

• Anche se GetLinkedAccountsAndCustomersInfo sembra restituire una struttura simile, richiesta dall'ID cliente 111 o 222, esiste una differenza notevole. Come indicato nell'introduzione allo scenario, il collegamento da Mananger Account L1 a Manager Account L2 è un collegamento amministrativo, mentre il collegamento da Manager Account L2 a Manager Account L3 è Standard. La risposta GetLinkedAccountsAndCustomersInfo non include dettagli sul tipo di collegamento, ad esempio Administrative o Standard. Poiché il tipo di collegamento può perfezionare ulteriormente l'autorizzazione di un utente a seconda del ruolo utente, viene incluso in ogni CustomerRole quando si chiama GetUser.
• Quando si esegue una ricerca in base all'ID cliente 333, non esiste alcuna differenza apparente tra l'account pubblicitario 3A, l'account pubblicitario 3B e l'account pubblicitario 4A. Come indicato nell'introduzione allo scenario, l'account pubblicitario 4A è accessibile tramite un collegamento client dell'account inserzionista, mentre gli altri account sono direttamente contenuti dall'account manager L3. Se è necessario determinare il proprietario diretto di ogni account, è possibile chiamare altre operazioni del servizio, ad esempio GetAccount o SearchAccounts.
• Nella gerarchia corrente l'account pubblicitario 4B è disponibile solo per gli utenti nell'account manager L4. È possibile effettuare il provisioning degli utenti nell'account manager L3 per accedere a 3 account, è possibile effettuare il provisioning degli utenti nell'account manager L2 per accedere a 5 account e il provisioning degli utenti nell'account manager L1 per accedere a 7 account. Un amministratore con privilegi avanzati può scegliere di limitare l'accesso di ogni utente a un subset degli account disponibili.

Gerarchia aggregatore

Il ruolo aggregatore è offerto a un set limitato di partner che offrono strumenti e servizi di ricerca-marketing a un gran numero di inserzionisti. Il ruolo aggregatore consente ai partner di creare nuovi account dei clienti a livello di codice. L'aggregatore viene fatturato tramite fattura per tutti i costi pubblicitari sostenuti dai clienti. L'inserzionista in genere non si iscrive alle credenziali di Microsoft Advertising e può pagare una tariffa all'aggregatore.

Viene effettuato il provisioning di un utente aggregatore nella shell del cliente principale. Come descritto in Limiti di entità , tutte le attività pubblicitarie sono organizzate per cliente, che può avere uno o più account. Ogni volta che SignupCustomer viene chiamato dall'utente aggregatore, viene creato un nuovo account inserzionista all'interno di un nuovo cliente.

L'operazione SignupCustomer richiede sia gli oggetti Customer che AdvertiserAccount . L'oggetto cliente include il nome del cliente, l'indirizzo in cui si trova il cliente, il mercato in cui opera il cliente e il settore in cui il cliente partecipa. Anche se è possibile aggiungere più clienti con gli stessi dettagli, è consigliabile usare nomi di clienti univoci in modo che gli utenti possano distinguere facilmente tra i clienti in un'interfaccia utente. L'oggetto account deve specificare il nome dell'account; il tipo di valuta da utilizzare per liquidare il conto; e l'identificatore del metodo di pagamento, che deve essere impostato su Null. L'operazione genera un account fattura e imposta l'identificatore del metodo di pagamento sull'identificatore associato alla fattura dell'aggregatore. La fatturazione viene eseguita fino allo strumento di pagamento dell'aggregatore e gli aggregatori vengono fatturati per tutti gli addebiti sostenuti dai clienti gestiti.

Come ottenere le credenziali dell'aggregatore

Per richiedere le credenziali dell'aggregatore, contattare il team di gestione degli account designato per informazioni dettagliate su come ottenere il ruolo Aggregatore. Se attualmente non si è aggregatori ma si vuole diventarne uno, passare alla pagina di benvenuto del Programma Microsoft Advertising Partner .

Vedere anche

Informazioni di riferimento sul servizio di gestione dei clienti
Indirizzi del servizio Web dell'API Bing Ads