Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# MediaTailor tracciamento e reportistica degli annunci sul lato server
AWS Elemental MediaTailor utilizza come impostazione predefinita il reporting lato server per il monitoraggio e la misurazione completi degli annunci. Con questa opzione, quando il lettore richiede un URL di annuncio dal manifest, il servizio invia un report sull’uso degli annunci pubblicitari direttamente all’URL di tracciamento degli annunci. Dopo che il lettore ha inizializzato una sessione di riproduzione con MediaTailor, non è necessario alcun ulteriore input da parte dell'utente o del lettore per eseguire la segnalazione lato server. Quando ogni annuncio viene riprodotto, MediaTailor invia dei beacon all'ad server per segnalare la parte dell'annuncio che è stata visualizzata. MediaTailor invia beacon per l'inizio dell'annuncio e per la progressione dell'annuncio in quartili: primo quartile, punto intermedio, terzo quartile e completamento dell'annuncio.
**Per eseguire il reporting degli annunci sul lato server**
+ Dal lettore, inizializzate una nuova sessione di MediaTailor riproduzione utilizzando una richiesta in uno dei seguenti formati, in base al protocollo in uso:
+ Esempio: formato HLS
```
GET /v1/master///?ads.&
```
+ Esempio: formato DASH
```
GET /v1/dash///?ads.&
```
Le coppie chiave-valore sono parametri di targeting dinamici per il tracciamento degli annunci. Per informazioni sull'aggiunta di parametri alla richiesta, consulta [MediaTailor variabili pubblicitarie dinamiche per le richieste ADS](variables.md).
AWS Elemental MediaTailor risponde alla richiesta con l'URL del manifesto. Il manifesto contiene URLs i manifesti multimediali. I manifest multimediali contengono collegamenti incorporati per le richieste del segmento di annunci.
**Nota**
Quando MediaTailor incontra una doppia barra (//) in un URL di tracciamento, la comprime a una (/).
Quando il player richiede la riproduzione dall'URL (`/v1/segment`percorso) di un segmento pubblicitario, AWS Elemental MediaTailor invia il beacon appropriato all'ad server tramite il tracciamento degli annunci. URLs Allo stesso tempo, il servizio emette un reindirizzamento al segmento di annunci `*.ts` effettivo. Il segmento pubblicitario si trova nella CloudFront distribuzione Amazon, dove MediaTailor archivia gli annunci transcodificati, o nella rete di distribuzione dei contenuti (CDN) in cui hai memorizzato l'annuncio nella cache.
Nelle sezioni seguenti vengono fornite ulteriori informazioni sull'utilizzo del tracciamento degli annunci sul lato server di. MediaTailor
**Topics**
+ [Tracciamento lato server SGAI](ad-reporting-server-side-sgai.md)
+ [Glossario Beacon](ad-reporting-server-side-beacon-glossary.md)
+ [Tempistica e comportamento di memorizzazione nella cache](ad-reporting-server-side-timing-behavior.md)
+ [Funzionalità di tracciamento](ad-reporting-server-side-features.md)
# Tracciamento lato server con inserimento di annunci guidato dal server (SGAI)
*Quando utilizzi l'inserimento di annunci guidato dal server (SGAI), il tracciamento lato server utilizza un meccanismo di beaconing senza sessione che differisce dall'approccio in modalità stitched-mode descritto sopra.* Invece di unire i segmenti degli annunci MediaTailor nel manifesto dei contenuti (dove tiene traccia delle `/v1/segment` richieste), SGAI restituisce i riferimenti agli annunci come playlist separate in una risposta all'elenco di risorse con metadati beacon incorporati nell'annuncio. URIs
## Come funziona il beaconing lato server senza sessioni
I passaggi seguenti descrivono come funziona il beaconing lato server per le sessioni SGAI:
1. **Inizializzazione della sessione**: il giocatore richiede la playlist multivariante HLS con. `aws.insertionMode=GUIDED` Il reporting lato server è l'impostazione predefinita (non è necessario alcun parametro). `aws.reportingMode` *A differenza della modalità stitched, la risposta di inizializzazione della sessione non include un.* `trackingUrl`
1. Manifesto **inseribile nella cache: MediaTailor restituisce un manifesto** memorizzabile nella cache contenente `EXT-X-DATERANGE` tag `CLASS="com.apple.hls.interstitial"` e `X-ASSET-LIST` attributi che puntano all'endpoint dell'elenco di risorse interstiziali. MediaTailor
1. **Elenco delle risorse con metadati beacon**: quando il giocatore incontra un'interruzione pubblicitaria, recupera l'elenco delle risorse. MediaTailorrestituisce una risposta JSON in cui ogni URI dell'annuncio include metadati beacon crittografati:
```
{
"ASSETS": [
{
"DURATION": 30.0,
"URI": "https://cdn.example.com/ad/master.m3u8?awsBeaconData=&awsBeaconDomain=&awsConfigurationName="
}
]
}
```
*Quando il reporting lato server è attivo, la risposta non include una sezione.* `TRACKING` L'annuncio contiene tutti i URIs dati dei beacon.
1. **Sostituzione variabile HLS**: il giocatore recupera la playlist multivariante dell'annuncio. Il manifesto dell'annuncio utilizza le `#EXT-X-DEFINE:QUERYPARAM` direttive per passare i parametri del beacon dalla stringa di query URI al segmento tramite la sostituzione di variabili HLS: URLs
```
#EXTM3U
#EXT-X-DEFINE:QUERYPARAM="awsBeaconData"
#EXT-X-DEFINE:QUERYPARAM="awsBeaconDomain"
#EXT-X-DEFINE:QUERYPARAM="awsConfigurationName"
#EXTINF:5.0,
{$awsBeaconDomain}/segment/hash/{$awsConfigurationName}/{$awsBeaconData}/0/0?aws.segmentRelativePath=asset_00001.ts
```
Il player risolve le `{$awsConfigurationName}` variabili `{$awsBeaconData}``{$awsBeaconDomain}`, e utilizzando i valori della stringa di query URI del manifesto dell'annuncio, quindi richiede l'utilizzo di ogni segmento dell'annuncio. MediaTailor
1. **Beacon si attiva su richiesta del segmento**: quando il giocatore richiede ogni segmento pubblicitario, la richiesta viene inoltrata. MediaTailor Il servizio decrittografa i dati del beacon, determina la posizione del segmento all'interno dell'annuncio (impressione, primo quartile, punto intermedio, terzo quartile o completo) e invia il beacon di tracciamento VAST appropriato all'ad server. MediaTailor quindi reindirizza il giocatore al segmento di contenuto pubblicitario effettivo.
## Requisiti del giocatore per il beaconing lato server SGAI
Per utilizzare il beaconing lato server con SGAI, il giocatore deve soddisfare i seguenti requisiti:
+ HLS versione 11 o successiva
+ Support per `EXT-X-DATERANGE` con `CLASS` attributo per HLS Interstitials
+ Support per la sostituzione di `#EXT-X-DEFINE:QUERYPARAM` variabili (RFC 8216bis). Il giocatore deve decodificare in percentuale i valori dei parametri di interrogazione prima di sostituirli nel segmento. URLs
**Nota**
Il beaconing lato server SGAI è attualmente supportato solo per HLS. DASH non è ancora supportato per il beaconing lato server SGAI.
## Confronto con il tracciamento lato server in modalità cucita
La tabella seguente riassume in che modo il tracciamento lato server differisce tra l'inserimento di annunci cucito e quello guidato dal server:
| Aspetto | Cucito (SSAI) | Guidato dal server (SGAI) |
| --- | --- | --- |
| Memorizzabilità nella cache del manifesto | Per sessione, non memorizzabile nella cache | Memorizzabile nella cache, condiviso tra gli spettatori |
| Routing dei segmenti di annunci | Tramite /v1/segment/ l'utilizzo dell'ID di sessione | Tramite /v1/segment/ l'utilizzo di un blob di dati beacon crittografato |
| Stato della sessione per i beacon | Memorizzato per sessione in MediaTailor | Senza sessione: tutto lo stato viene memorizzato nel parametro crittografato awsBeaconData |
| URL di tracciamento all'inizio della sessione | Restituito nella risposta di inizializzazione della sessione | Non fornito: i dati del beacon sono incorporati nell'annuncio URIs in ogni risposta all'elenco di risorse |
| Supporto per DASH | Supportata | Non ancora supportato |
**Nota**
Per le sessioni SGAI live, puoi abilitare il prefetching degli annunci basato su manifesti utilizzando. `aws.guidedPrefetchMode=MANIFEST` È separata dall'API di prefetch basata sulla pianificazione utilizzata con le sessioni stitched (SSAI). Per informazioni dettagliate, vedi [Prefetch guidato con battito cardiaco manifesto](sgai-guided-prefetch.md).
# Glossario dei beacon di tracciamento lato server
MediaTailor Il tracciamento lato server utilizza un set standardizzato di beacon per segnalare lo stato di avanzamento della visualizzazione degli annunci ai server pubblicitari e ai servizi di verifica. Questi beacon sono in linea con gli standard dell'Interactive Advertising Bureau (IAB) per la misurazione degli annunci video e forniscono report accurati sulle impressioni pubblicitarie e sui tassi di completamento.
**Tipi di beacon di tracciamento lato server**
| Tipo di beacon | Quando licenziato | Scopo | Dettagli sulla tempistica |
| --- | --- | --- | --- |
| Impressione | Quando il giocatore richiede il primo segmento pubblicitario | Indica che il contenuto dell'annuncio ha iniziato a caricarsi e sta per essere visualizzato allo spettatore | Attivato alla prima /v1/segment richiesta di annuncio. È conforme alle linee guida IAB che richiedono che il contenuto degli annunci inizi a caricarsi prima di contare le impressioni. Vedi [Flusso di lavoro di tracciamento lato server](ad-reporting-server-side-timing-behavior.md#ad-reporting-server-side-timing-behavior-workflow) per la sequenza completa. |
| Start (Avvio) | Quando il giocatore inizia a visualizzare il contenuto dell'annuncio | Conferma che la riproduzione dell'annuncio è effettivamente iniziata | In genere viene attivato contemporaneamente all'impression beacon sulla richiesta del primo segmento, ma rappresenta l'inizio effettivo del rendering dell'annuncio. Questa distinzione è importante per i servizi di verifica che tengono traccia separatamente degli eventi di impressione e avvio. |
| Primo quartile | Quando il giocatore raggiunge il 25% della durata dell'annuncio | Misura la continuazione della visualizzazione dell'annuncio durante il primo trimestre dell'annuncio | Attivato quando il giocatore richiede il segmento contenente il 25% della durata dell'annuncio. Ad esempio, in un annuncio di 20 secondi con segmenti di 2 secondi, in genere si attiva sulla richiesta per il terzo segmento (a circa 4-6 secondi dall'inizio dell'annuncio). |
| Punto medio | Quando il giocatore raggiunge il 50% della durata dell'annuncio | Misura la visualizzazione continua dell'annuncio per metà dell'annuncio | Attivato quando il giocatore richiede il segmento contenente il 50% della durata dell'annuncio. Ad esempio, in un annuncio di 20 secondi con segmenti di 2 secondi, in genere si attiva sulla richiesta per il quinto segmento (a circa 8-10 secondi dall'inizio dell'annuncio). |
| Terzo quartile | Quando il giocatore raggiunge il 75% della durata dell'annuncio | Misura la visualizzazione continua dell'annuncio per tre quarti dell'annuncio | Attivato quando il giocatore richiede il segmento che contiene il 75% della durata dell'annuncio. Ad esempio, in un annuncio di 20 secondi con segmenti di 2 secondi, in genere si attiva sulla richiesta per l'ottavo segmento (a circa 14-16 secondi dall'inizio dell'annuncio). |
| Completa | Quando il giocatore raggiunge la fine dell'annuncio | Conferma che l'intero annuncio è stato inviato allo spettatore | Attivato quando il giocatore richiede l'ultimo segmento dell'annuncio. Ciò indica che lo spettatore ha potenzialmente visto l'intero contenuto dell'annuncio. Ad esempio, in un annuncio di 20 secondi con segmenti di 2 secondi, in genere ciò si attiva sulla richiesta per il decimo segmento (a circa 18-20 secondi dall'inizio dell'annuncio). |
**Nota**
L'orario esatto di attivazione del beacon dipende dalla durata del segmento e dalla lunghezza dell'annuncio. MediaTailor calcola la richiesta di segmento appropriata che corrisponde a ciascuna posizione del quartile in base alla durata specifica dell'annuncio e alla struttura del segmento.
# Tempi di tracciamento e comportamento di memorizzazione nella cache sul lato server
Nei report lato server, MediaTailor attiva gli eventi di tracciamento in base alle effettive richieste di segmento da parte del player e non alle attività di analisi del manifesto o di precaricamento. Questo approccio garantisce un conteggio accurato delle impressioni in linea con gli standard di settore per la misurazione degli annunci video.
## Principi chiave in materia di tempistica
MediaTailor il tracciamento lato server segue questi principi temporali fondamentali:
+ **Gli eventi di tracciamento si attivano sulle richieste effettive dei segmenti**: i beacon vengono inviati solo quando il giocatore effettua richieste HTTP a `/v1/segment` URLs, non durante l'analisi o la memorizzazione nella cache del manifesto.
+ La **memorizzazione nella cache e il precaricamento dei manifesti da parte dei giocatori NON attivano eventi**: i giocatori possono analizzare, memorizzare nella cache o precaricare le informazioni del manifesto senza generare eventi di tracciamento.
+ Il **precaricamento dei segmenti *attiverà* degli eventi: se i giocatori recuperano** in anticipo i segmenti degli annunci effettivi prima della riproduzione, ciò segue il comportamento standard del settore in cui le richieste di segmenti costituiscono impressioni valide.
+ **Ogni richiesta /v1/segment attiva il beacon appropriato**: l'evento di tracciamento specifico (impressione, quartile, completamento) è determinato dalla posizione dell'annuncio e dal segmento richiesti.
+ La **tempistica è conforme agli standard IAB: l'approccio segue le** linee guida dell'Interactive Advertising Bureau per la misurazione degli annunci video e il conteggio delle impressioni.
## Flusso di lavoro di tracciamento lato server
I seguenti diagrammi illustrano l'intero flusso di lavoro di tracciamento lato server, che mostra quando gli eventi di tracciamento vengono attivati in relazione alle richieste dei giocatori:
**Fase 1: inizializzazione della sessione**
Il giocatore richiede un manifesto da MediaTailor, che restituisce un manifesto personalizzato contenente un segmento URLs pubblicitario:
![\[Fase di inizializzazione della sessione che mostra il giocatore che richiede un manifesto MediaTailor e riceve un manifesto personalizzato con segmento pubblicitario. URLs\]](http://docs.aws.amazon.com/it_it/mediatailor/latest/ug/images/ss-track-phase1.png)
**Fase 2: monitoraggio delle richieste di annunci e delle impressioni**
Quando il giocatore richiede il primo segmento pubblicitario, invia impressioni e avvia MediaTailor i beacon sia sull'Ad Decision Server che sui servizi di verifica degli annunci:
![\[Fase di tracciamento delle impressioni degli annunci, che mostra l' MediaTailor invio di beacon di impressioni e di avvio ad Ad Decision Server e Ad Verification Services quando il giocatore richiede il primo segmento di annuncio.\]](http://docs.aws.amazon.com/it_it/mediatailor/latest/ug/images/ss-track-phase2.png)
**Fase 3: tracciamento del quartile**
MediaTailor attiva fari quartili (primo quartile, punto medio, terzo quartile, completamento) in base alle successive richieste di segmento:
![\[fase di tracciamento quartile che mostra l'invio di beacon quartili sia ad Ad Decision Server che ad Ad Verification Services man MediaTailor mano che il giocatore richiede segmenti pubblicitari successivi.\]](http://docs.aws.amazon.com/it_it/mediatailor/latest/ug/images/ss-track-phase3.png)
**Fase 4: distribuzione dei segmenti**
Dopo aver attivato i beacon di tracciamento, MediaTailor reindirizza al segmento pubblicitario effettivo di Amazon o del tuo CDN: CloudFront
![\[Fase di distribuzione dei segmenti che mostra il MediaTailor reindirizzamento del giocatore al segmento pubblicitario effettivo del nostro CDN dopo aver attivato i beacon di tracciamento. CloudFront\]](http://docs.aws.amazon.com/it_it/mediatailor/latest/ug/images/ss-track-phase4.png)
Il flusso di lavoro di tracciamento lato server include i seguenti comportamenti di temporizzazione chiave:
1. **Inizializzazione della sessione**: il giocatore richiede un manifesto da. MediaTailor MediaTailor restituisce un manifesto personalizzato contenente un segmento di annunci URLs con il `/v1/segment` percorso.
1. **Analisi e memorizzazione nella cache del manifesto**: il lettore analizza il manifesto e può precaricare o memorizzare nella cache le informazioni sui segmenti. **Durante questa fase non viene attivato alcun evento di tracciamento**, indipendentemente dal comportamento di memorizzazione nella cache del giocatore.
1. **Richiesta di segmenti di annunci e monitoraggio delle impressioni**: quando il giocatore richiede effettivamente il primo segmento di annuncio (in genere per la riproduzione), MediaTailor attiva il beacon delle impressioni e inizia a tracciare l'evento sia sull'Ad Decision Server che sui Servizi di verifica degli annunci. Ciò si verifica sulla richiesta HTTP effettiva all'`/v1/segment`URL, non quando il manifesto viene analizzato.
1. **Tracciamento quartile basato sulle richieste dei segmenti**: invia beacon MediaTailor quartili (primo quartile, punto intermedio, terzo quartile, completamento) sia ad Ad Decision Server che ad Ad Verification Services in base alle richieste di segmento successive che corrispondono alle posizioni del quartile calcolate entro la durata dell'annuncio.
1. **Distribuzione a segmenti**: dopo aver attivato il beacon di tracciamento appropriato, MediaTailor invia un reindirizzamento HTTP al segmento pubblicitario effettivo (da Amazon CloudFront o dal tuo CDN).
## Considerazioni sulla memorizzazione nella cache e sul precaricamento dei giocatori
MediaTailor Il tracciamento lato server è progettato per essere compatibile con varie strategie di memorizzazione nella cache e precaricamento dei giocatori, pur mantenendo una misurazione accurata delle impressioni:
+ **Precaricamento del manifesto: i giocatori che precaricano** o memorizzano nella cache le informazioni del manifesto non attivano gli eventi di tracciamento. Gli eventi di tracciamento vengono attivati solo quando vengono effettuate richieste effettive di segmenti.
+ **Pre-acquisizione dei segmenti: se un giocatore precarica segmenti di annunci prima della riproduzione, gli eventi di tracciamento si attivano** quando tali segmenti vengono richiesti, potenzialmente prima del tempo di riproduzione effettivo. Questo comportamento è in linea con gli standard di settore che considerano le richieste di segmenti come impressioni valide.
+ **Buffering dei giocatori**: il comportamento standard di buffering dei giocatori (richiesta dei segmenti leggermente prima della riproduzione) attiverà gli eventi di tracciamento nei momenti appropriati in base allo schema di richiesta del segmento.
## Risoluzione dei problemi relativi alle discrepanze di tracciamento
Se noti discrepanze tra il monitoraggio MediaTailor lato server e le metriche di terze parti, considera i seguenti fattori:
+ **Differenze nel comportamento dei giocatori**: giocatori diversi possono avere strategie di pre-fetching e buffering diverse che influiscono sul momento in cui vengono effettuate le richieste di segmenti.
+ **Condizioni di rete: condizioni** di rete scadenti possono indurre i giocatori a richiedere segmenti più volte o a intervalli diversi dal previsto.
+ **Configurazione CDN**: una memorizzazione errata nella cache CDN delle `/v1/segment` richieste può portare a eventi di tracciamento mancati o duplicati.
+ **Gestione della sessione**: assicuratevi che ogni sessione di riproduzione utilizzi un identificatore di sessione univoco per prevenire il tracciamento dei conflitti di eventi.
Per una guida dettagliata alla risoluzione dei problemi, consulta. [Risoluzione dei problemi comuni](monitoring-and-troubleshooting.md#troubleshooting-common-issues)
# MediaTailor caratteristiche e funzionalità di tracciamento lato server
AWS Elemental MediaTailor applica automaticamente queste funzionalità integrate di tracciamento lato server per ottimizzare l'accuratezza e l'affidabilità delle misurazioni degli annunci. Il sistema previene la duplicazione dei beacon, gestisce il traffico durante i periodi ad alto volume, mantiene il corretto sequenziamento degli eventi e fornisce un monitoraggio completo delle prestazioni senza richiedere alcuna configurazione da parte dell'utente. Devi solo assicurarti che il tuo Ad Decision Server (ADS) fornisca i beacon di tracciamento nella risposta VAST.
**Nota**
Queste funzionalità sono disponibili per i nuovi clienti a partire dal 30 settembre 2025. I clienti esistenti potranno accedervi per tutto il 2025 nell'ambito dei continui miglioramenti del servizio. Se desideri accedere immediatamente a queste funzionalità, contatta [AWS Support](https://aws.amazon.com/premiumsupport/).
**Nota**
Queste funzionalità si applicano sia ai metodi di inserimento degli annunci cuciti (SSAI) che guidati dal server (SGAI). I tipi e la tempistica dei beacon sono gli stessi in entrambe le modalità. Differiscono nel modo in cui MediaTailor attivano i beacon: vedi [Tracciamento lato server con inserimento di annunci guidato dal server (SGAI)](ad-reporting-server-side-sgai.md) per i dettagli sul beaconing lato server SGAI.
## Deduplicazione beacon
MediaTailor impedisce l'attivazione di beacon duplicati per eventi pubblicitari identici. Il sistema di tracciamento lato server invia ogni impressione, quartile e faro di completamento solo una volta per sessione di visualizzazione degli annunci. Quando i lettori video richiedono lo stesso segmento pubblicitario più volte a causa delle condizioni della rete, delle variazioni del bitrate o delle strategie di buffering, MediaTailor rileva i beacon attivati e blocca le trasmissioni ridondanti.
La deduplicazione risolve automaticamente gli scenari più comuni che causano un aumento del numero di beacon:
+ **Streaming adattivo con bitrate**: quando i giocatori scaricano varianti di qualità diverse dello stesso segmento pubblicitario
+ **Scenari di riprova in rete**: quando i giocatori richiedono nuovamente i segmenti a causa di problemi di rete o timeout
+ **Strategie di buffering dei giocatori**: quando i giocatori recuperano o recuperano nuovamente segmenti per scopi di buffering
Il sistema è progettato per attivare i fari di impressione una sola volta, anche quando i giocatori passano da un livello di qualità all'altro.
## Throttling adattivo e nuovi tentativi di beacon
MediaTailor gestisce automaticamente i tassi di traffico beacon in base agli indicatori di risposta del server. Il sistema monitora i modelli di risposta HTTP, i timeout di connessione e i codici di errore per rilevare la congestione, quindi regola i tassi di traffico di conseguenza. Quando il sistema identifica gli indicatori di stress del server, riduce i tassi di traffico per il dominio interessato e aumenta automaticamente i tassi quando i server dimostrano una maggiore capacità.
Il sistema monitora lo stato del server utilizzando questi indicatori:
+ **Timeout di connessione HTTP**: quando le piattaforme di misurazione non rispondono entro i tempi previsti
+ **Codici di risposta agli errori**: risposte 503, 504 e 507 che indicano un sovraccarico del server. Il tuo server pubblicitario deve inoltre supportare questi codici di errore per garantire la piena compatibilità.
+ **Modelli di risposta**: modifiche delle prestazioni della piattaforma di misurazione che indicano problemi di capacità
Retry Behaviour tenta automaticamente la consegna per un massimo di 1 ora con un ritardo minimo di 30 secondi tra un tentativo e l'altro. Questo comportamento tra tentativi non può essere configurato.
## Gestione del traffico beacon al secondo
Puoi impostare i limiti TPS per controllare le tariffe di consegna dei beacon. Questa è l'unica impostazione configurabile per le funzionalità di tracciamento lato server. I limiti a livello di account limitano il numero totale di richieste di tracciamento degli annunci inviate a tutti i partner di misurazione. MediaTailor impone un limite TPS minimo di 10.000 per fornire una capacità sufficiente per le operazioni su scala aziendale.
Invia un ticket di AWS assistenza per stabilire i limiti TPS con le seguenti informazioni:
+ **ID account AWS**: l'identificatore specifico del tuo account
+ **Regione di destinazione**: la regione AWS in cui desideri applicare il limite TPS
+ **Soglia TPS desiderata**: il limite richiesto di transazioni al secondo (minimo 10.000)
Per impostazione predefinita, non esiste un limite TPS. Puoi richiedere un limite TPS se il tuo Ad Decision Server (ADS) lo richiede, ma il limite deve essere superiore a 10.000 TPS. MediaTailor non supererà il limite specificato, ma non garantisce un throughput costante fino a tale limite. Il tuo ad decision server ti dirà quali limiti TPS è in grado di supportare.
## Beaconing in ordine
MediaTailor mantiene automaticamente la distribuzione sequenziale degli eventi di tracciamento degli annunci. Il sistema mantiene l'ordine dei beacon anche in caso di problemi di rete, nuovi tentativi o gestione del traffico. Ciò garantisce che i partner di misurazione ricevano gli eventi nell'ordine corretto per un'analisi accurata.
Il sistema segue la sequenza di segnali standard del settore:
1. **Avvia eventi**: si attiva quando inizia la riproduzione dell'annuncio
1. **Eventi del primo quartile**: attivati al 25% dopo il completamento
1. **Eventi intermedi**: sparati al 50% dopo il completamento
1. **Eventi del terzo quartile**: Incendio al 75% dopo il completamento
1. **Eventi di completamento**: si attivano al termine degli annunci
Queste funzionalità interagiscono automaticamente:
+ I beacon vengono bloccati durante il throttling per mantenere l'ordine corretto
+ Ogni dominio partner di misurazione dispone di code di eventi separate per evitare interruzioni durante gli aggiustamenti delle tariffe
+ La deduplicazione tiene traccia del tipo di evento e della posizione della sequenza temporale mantenendo l'ordine cronologico