As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# MediaTailor Rastreamento e relatórios de anúncios do lado do servidor
AWS Elemental MediaTailor usa como padrão os relatórios do lado do servidor para rastreamento e medição abrangentes de anúncios. Com os relatórios no lado do servidor, quando o player solicita um URL de anúncio no manifesto, o serviço reporta o consumo de anúncios diretamente para o URL de rastreamento de anúncios. Depois que o player inicializa uma sessão de reprodução com MediaTailor, nenhuma outra entrada é necessária de você ou do player para realizar relatórios do lado do servidor. À medida que cada anúncio é reproduzido, MediaTailor envia beacons ao servidor de anúncios para informar quanto do anúncio foi visualizado. MediaTailor envia beacons para o início do anúncio e para a progressão do anúncio em quartis: primeiro quartil, ponto médio, terceiro quartil e conclusão do anúncio.
**Para realizar a geração de relatórios de anúncios no lado do servidor**
+ No player, inicialize uma nova sessão de MediaTailor reprodução usando uma solicitação em um dos seguintes formatos, de acordo com seu protocolo:
+ Exemplo: formato HLS
```
GET /v1/master///?ads.&
```
+ Exemplo: formato DASH
```
GET /v1/dash///?ads.&
```
Os pares de chave/valor são os parâmetros dinâmicos de direcionamento para rastreamento de anúncios. Para obter informações sobre como adicionar parâmetros à solicitação, consulte [MediaTailor variáveis dinâmicas de anúncios para solicitações de ADS](variables.md).
AWS Elemental MediaTailor responde à solicitação com o URL do manifesto. O manifesto contém URLs para os manifestos de mídia. Os manifestos de mídia contêm links para solicitações de segmento de anúncios.
**nota**
Quando MediaTailor encontra uma barra dupla (//) em um URL de rastreamento, ela reduz as barras para uma (/).
Quando o player solicita a reprodução de um URL (`/v1/segment`caminho) do segmento de anúncio, AWS Elemental MediaTailor envia o beacon apropriado para o servidor de anúncios por meio do rastreamento de anúncios. URLs Ao mesmo tempo, o serviço emite um redirecionamento para o segmento de anúncio `*.ts` real. O segmento de anúncios está na CloudFront distribuição da Amazon, onde MediaTailor armazena anúncios transcodificados, ou na rede de entrega de conteúdo (CDN), onde você armazenou o anúncio em cache.
As seções a seguir fornecem mais informações sobre como trabalhar com o rastreamento de anúncios do lado do servidor a partir de. MediaTailor
**Topics**
+ [Rastreamento do lado do servidor SGAI](ad-reporting-server-side-sgai.md)
+ [Glossário do Beacon](ad-reporting-server-side-beacon-glossary.md)
+ [Comportamento de temporização e armazenamento em cache](ad-reporting-server-side-timing-behavior.md)
+ [Recursos de rastreamento](ad-reporting-server-side-features.md)
# Rastreamento do lado do servidor com inserção de anúncios guiada pelo servidor (SGAI)
Quando você usa a inserção de anúncios guiada pelo servidor (SGAI), o rastreamento do lado do servidor usa um mecanismo de sinalização *sem sessão que difere da abordagem de modo combinado descrita* acima. Em vez de MediaTailor unir segmentos de anúncios ao manifesto de conteúdo (onde rastreia `/v1/segment` solicitações), o SGAI retorna referências de anúncios como playlists separadas em uma resposta da lista de ativos com metadados de beacon incorporados ao anúncio. URIs
## Como funciona o beaconing do lado do servidor sem sessão
As etapas a seguir descrevem como o beaconing do lado do servidor funciona nas sessões do SGAI:
1. **Inicialização da sessão**: o player solicita a playlist multivariante HLS com. `aws.insertionMode=GUIDED` Os relatórios do lado do servidor são o padrão (nenhum `aws.reportingMode` parâmetro é necessário). Ao contrário do modo costurado, a resposta de inicialização da sessão *não* inclui um. `trackingUrl`
1. Manifesto **armazenável em cache: MediaTailor retorna um manifesto** armazenável em cache contendo `EXT-X-DATERANGE` tags `CLASS="com.apple.hls.interstitial"` e `X-ASSET-LIST` atributos apontando para o endpoint da lista de ativos MediaTailor intersticiais.
1. **Lista de ativos com metadados de beacon**: quando o jogador encontra uma pausa no anúncio, ele busca a lista de ativos. MediaTailorretorna uma resposta JSON em que cada URI do anúncio inclui metadados de beacon criptografados:
```
{
"ASSETS": [
{
"DURATION": 30.0,
"URI": "https://cdn.example.com/ad/master.m3u8?awsBeaconData=&awsBeaconDomain=&awsConfigurationName="
}
]
}
```
Quando os relatórios do lado do servidor estão ativos, a resposta *não* inclui uma seção. `TRACKING` O anúncio URIs carrega todos os dados do beacon.
1. **Substituição da variável HLS**: o player busca a playlist multivariante do anúncio. O manifesto publicitário usa `#EXT-X-DEFINE:QUERYPARAM` diretivas para transmitir os parâmetros do beacon da string de consulta do URI para o segmento URLs por meio da substituição da variável HLS:
```
#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
```
O player resolve as `{$awsConfigurationName}` variáveis`{$awsBeaconData}`,`{$awsBeaconDomain}`, e usando os valores da string de consulta do URI do manifesto do anúncio e, em seguida, solicita cada segmento do anúncio por meio MediaTailor de.
1. **Sinalizador acionado por solicitação de segmento**: à medida que o player solicita cada segmento de anúncio, a solicitação é encaminhada. MediaTailor O serviço decifra os dados do beacon, determina a posição do segmento no anúncio (impressão, primeiro quartil, ponto médio, terceiro quartil ou completo) e dispara o farol de rastreamento VAST apropriado para o servidor de anúncios. MediaTailor em seguida, redireciona o player para o segmento real do conteúdo do anúncio.
## Requisitos do jogador para beaconing do lado do servidor SGAI
Para usar o beaconing do lado do servidor com o SGAI, seu player deve atender aos seguintes requisitos:
+ HLS versão 11 ou posterior
+ Support for `EXT-X-DATERANGE` with `CLASS` attribute for HLS Interstitials
+ Support para substituição de `#EXT-X-DEFINE:QUERYPARAM` variáveis (RFC 8216bis). O jogador deve decodificar por cento os valores dos parâmetros de consulta antes de substituí-los em um segmento. URLs
**nota**
Atualmente, o beaconing do lado do servidor SGAI é compatível somente com HLS. O DASH ainda não é compatível com o beaconing do lado do servidor SGAI.
## Comparação com o rastreamento do lado do servidor em modo combinado
A tabela a seguir resume como o rastreamento do lado do servidor difere entre a inserção de anúncios agrupados e a inserção guiada pelo servidor:
| Aspecto | Costurado (SSAI) | Guiado pelo servidor (SGAI) |
| --- | --- | --- |
| Capacidade de armazenamento em cache do manifesto | Por sessão, não armazenável em cache | Armazenável em cache, compartilhado entre os espectadores |
| Roteamento de segmentos de anúncios | Por meio do /v1/segment/ uso do ID da sessão | /v1/segment/Usando um blob de dados de beacon criptografado |
| Estado da sessão para beacons | Armazenado por sessão em MediaTailor | Sem sessão — todo o estado é transmitido no parâmetro criptografado awsBeaconData |
| URL de rastreamento no início da sessão | Retornado na resposta de inicialização da sessão | Não fornecido — os dados do beacon são incorporados ao anúncio URIs em cada resposta da lista de ativos |
| Suporte para DASH | Compatível | Sem suporte no momento |
**nota**
Para sessões ao vivo do SGAI, você pode ativar a pré-busca de anúncios baseada em manifestos usando. `aws.guidedPrefetchMode=MANIFEST` Isso é separado da API de pré-busca baseada em agendamento usada com sessões agrupadas (SSAI). Para obter detalhes, consulte [Pré-busca guiada com batimento cardíaco manifesto](sgai-guided-prefetch.md).
# Glossário de beacons de rastreamento do lado do servidor
MediaTailor o rastreamento do lado do servidor usa um conjunto padronizado de beacons para relatar o progresso da visualização de anúncios aos servidores de anúncios e serviços de verificação. Esses beacons se alinham aos padrões do Interactive Advertising Bureau (IAB) para medição de anúncios em vídeo e fornecem relatórios precisos sobre impressões de anúncios e taxas de conclusão.
**Tipos de beacons de rastreamento do lado do servidor**
| Tipo de farol | Quando demitido | Finalidade | Detalhes de cronometragem |
| --- | --- | --- | --- |
| Impressão | Quando o player solicita o primeiro segmento de anúncio | Indica que o conteúdo do anúncio começou a ser carregado e está prestes a ser exibido para o espectador | Acionado na primeira /v1/segment solicitação de um anúncio. Está alinhado às diretrizes do IAB que exigem que o conteúdo do anúncio comece a ser carregado antes de contar uma impressão. Veja [Fluxo de trabalho de rastreamento do lado do servidor](ad-reporting-server-side-timing-behavior.md#ad-reporting-server-side-timing-behavior-workflow) a sequência completa. |
| Início | Quando o player começa a renderizar o conteúdo do anúncio | Confirma que a reprodução do anúncio foi realmente iniciada | Normalmente é acionado simultaneamente com o farol de impressão na primeira solicitação de segmento, mas representa o início real da renderização do anúncio. Essa distinção é importante para serviços de verificação que rastreiam os eventos de impressão e de início separadamente. |
| Primeiro quartil | Quando o jogador atinge 25% da duração do anúncio | Mede a visualização contínua do anúncio durante o primeiro trimestre do anúncio | Acionado quando o jogador solicita o segmento que contém o ponto de 25% da duração do anúncio. Por exemplo, em um anúncio de 20 segundos com segmentos de 2 segundos, isso normalmente seria acionado na solicitação do terceiro segmento (aproximadamente 4 a 6 segundos após o início do anúncio). |
| Ponto médio | Quando o jogador atinge 50% da duração do anúncio | Mede a visualização contínua do anúncio em metade do anúncio | Acionado quando o jogador solicita o segmento que contém o ponto de 50% da duração do anúncio. Por exemplo, em um anúncio de 20 segundos com segmentos de 2 segundos, isso normalmente seria acionado na solicitação do 5º segmento (aproximadamente 8 a 10 segundos após o início do anúncio). |
| Terceiro quartil | Quando o jogador atinge 75% da duração do anúncio | Mede a visualização contínua de anúncios em três quartos do anúncio | Acionado quando o jogador solicita o segmento que contém o ponto de 75% da duração do anúncio. Por exemplo, em um anúncio de 20 segundos com segmentos de 2 segundos, isso normalmente seria acionado na solicitação do 8º segmento (aproximadamente 14 a 16 segundos após o início do anúncio). |
| Concluído | Quando o jogador chega ao final do anúncio | Confirma que todo o anúncio foi entregue ao espectador | Acionado quando o jogador solicita o segmento final do anúncio. Isso indica que o espectador potencialmente viu todo o conteúdo do anúncio. Por exemplo, em um anúncio de 20 segundos com segmentos de 2 segundos, isso normalmente seria acionado na solicitação do 10º segmento (aproximadamente 18 a 20 segundos após o início do anúncio). |
**nota**
O momento exato do disparo do farol depende da duração do segmento e da duração do anúncio. MediaTailor calcula a solicitação de segmento apropriada que corresponde a cada posição do quartil com base na duração específica do anúncio e na estrutura do segmento.
# Tempo de rastreamento do lado do servidor e comportamento de armazenamento em cache
Nos relatórios do lado do servidor, MediaTailor aciona eventos de rastreamento com base nas solicitações reais do segmento do player, não na análise do manifesto ou nas atividades de pré-carregamento. Essa abordagem garante uma contagem precisa de impressões que se alinha aos padrões do setor para medição de anúncios em vídeo.
## Princípios-chave de temporização
MediaTailor o rastreamento do lado do servidor segue esses princípios fundamentais de temporização:
+ **Os eventos de rastreamento são acionados em solicitações reais de segmentos** - os beacons são enviados somente quando o player faz solicitações HTTP `/v1/segment` URLs, não durante a análise ou o armazenamento em cache do manifesto.
+ O armazenamento em **cache e o pré-carregamento de manifestos pelo jogador NÃO acionam eventos** - Os jogadores podem analisar, armazenar em cache ou pré-carregar informações do manifesto sem gerar nenhum evento de rastreamento.
+ A **pré-busca de segmentos *acionará* eventos**. Se os jogadores pré-buscarem segmentos de anúncios reais antes da reprodução, isso segue o comportamento padrão do setor, em que as solicitações de segmentos constituem impressões válidas.
+ **Cada solicitação /v1/segment aciona o beacon apropriado**. O evento de rastreamento específico (impressão, quartil, conclusão) é determinado pela posição do anúncio e pelo segmento que está sendo solicitado.
+ **O tempo está alinhado aos padrões do IAB** — a abordagem segue as diretrizes do Interactive Advertising Bureau para medição de anúncios em vídeo e contagem de impressões.
## Fluxo de trabalho de rastreamento do lado do servidor
Os diagramas a seguir ilustram o fluxo de trabalho completo de rastreamento do lado do servidor, mostrando quando os eventos de rastreamento são acionados em relação às solicitações dos jogadores:
**Fase 1: Inicialização da sessão**
O player solicita um manifesto de MediaTailor, que retorna um manifesto personalizado contendo um segmento de anúncio URLs:
![\[Fase de inicialização da sessão mostrando o jogador solicitando um manifesto MediaTailor e recebendo um manifesto personalizado com um segmento de anúncio. URLs\]](http://docs.aws.amazon.com/pt_br/mediatailor/latest/ug/images/ss-track-phase1.png)
**Fase 2: Rastreamento de solicitações de anúncios e impressões**
Quando o player solicita o primeiro segmento do anúncio, MediaTailor dispara os beacons de impressão e de início para o Ad Decision Server e para os Ad Verification Services:
![\[Fase de rastreamento de impressões de anúncios que mostra o MediaTailor envio de beacons de impressão e de início para o Ad Decision Server e os Ad Verification Services quando o jogador solicita o primeiro segmento do anúncio.\]](http://docs.aws.amazon.com/pt_br/mediatailor/latest/ug/images/ss-track-phase2.png)
**Fase 3: Rastreamento de quartis**
MediaTailor dispara faróis de quartil (primeiro quartil, ponto médio, terceiro quartil, conclusão) com base nas solicitações subsequentes do segmento:
![\[Fase de rastreamento de quartis mostrando o MediaTailor disparo de beacons de quartil para o Ad Decision Server e os Ad Verification Services à medida que o jogador solicita segmentos de anúncios subsequentes.\]](http://docs.aws.amazon.com/pt_br/mediatailor/latest/ug/images/ss-track-phase3.png)
**Fase 4: Entrega por segmento**
Depois de disparar os beacons de rastreamento, MediaTailor redireciona para o segmento de anúncio real da Amazon ou do seu CDN: CloudFront
![\[Fase de entrega do segmento mostrando o MediaTailor redirecionamento do player para o segmento de anúncio real de CloudFront ou CDN após disparar beacons de rastreamento.\]](http://docs.aws.amazon.com/pt_br/mediatailor/latest/ug/images/ss-track-phase4.png)
O fluxo de trabalho de rastreamento do lado do servidor inclui os seguintes principais comportamentos de temporização:
1. **Inicialização da sessão** - O jogador solicita um manifesto de MediaTailor. MediaTailor retorna um manifesto personalizado contendo um segmento de anúncio URLs com o `/v1/segment` caminho.
1. Análise **e armazenamento em cache do manifesto** - O player analisa o manifesto e pode pré-carregar ou armazenar em cache as informações do segmento. **Nenhum evento de rastreamento é acionado durante essa fase**, independentemente do comportamento de cache do jogador.
1. **Solicitação de segmento de anúncio e rastreamento de impressões**: quando o player realmente solicita o primeiro segmento de anúncio (normalmente para reprodução), MediaTailor dispara o sinal de impressão e inicia o rastreamento do evento no Ad Decision Server e nos Serviços de Verificação de Anúncios. Isso ocorre na solicitação HTTP real para o `/v1/segment` URL, não quando o manifesto é analisado.
1. **Rastreamento de quartil com base nas solicitações do segmento**: MediaTailor dispara beacons de quartil (primeiro quartil, ponto médio, terceiro quartil, conclusão) para o Ad Decision Server e para os Ad Verification Services com base nas solicitações subsequentes do segmento que correspondem às posições calculadas do quartil dentro da duração do anúncio.
1. **Entrega por segmento** - Depois de acionar o sinalizador de rastreamento apropriado, MediaTailor emite um redirecionamento HTTP para o segmento real do anúncio (da Amazon CloudFront ou da sua CDN).
## Considerações sobre armazenamento em cache e pré-carregamento do player
MediaTailor o rastreamento do lado do servidor foi projetado para ser compatível com várias estratégias de armazenamento em cache e pré-carregamento do player, mantendo a medição precisa das impressões:
+ **Pré-carregamento do manifesto** - Jogadores que pré-carregam ou armazenam em cache as informações do manifesto não acionam eventos de rastreamento. Os eventos de rastreamento só são acionados quando solicitações reais de segmento são feitas.
+ **Pré-busca de segmentos** - Se um player pré-buscar segmentos de anúncios antes da reprodução, os eventos de rastreamento serão acionados quando esses segmentos forem solicitados, potencialmente antes do tempo real de reprodução. Esse comportamento está alinhado aos padrões do setor que consideram as solicitações de segmentos como impressões válidas.
+ **Armazenamento em buffer** do player - O comportamento padrão do buffer do player (solicitando segmentos um pouco antes da reprodução) acionará eventos de rastreamento nos momentos apropriados, com base no padrão de solicitação do segmento.
## Solução de problemas de discrepâncias de rastreamento
Se você observar discrepâncias entre o rastreamento do MediaTailor lado do servidor e as métricas de terceiros, considere os seguintes fatores:
+ **Diferenças de comportamento do jogador** - jogadores diferentes podem ter estratégias variadas de pré-busca e armazenamento em buffer que afetam o momento em que as solicitações de segmentos são feitas.
+ **Condições de rede** - Condições de rede ruins podem fazer com que os jogadores solicitem segmentos várias vezes ou em intervalos diferentes do esperado.
+ **Configuração de CDN** - O armazenamento incorreto de `/v1/segment` solicitações na CDN pode levar a eventos de rastreamento perdidos ou duplicados.
+ **Gerenciamento de sessão** - Certifique-se de que cada sessão de reprodução use um identificador de sessão exclusivo para evitar conflitos de eventos de rastreamento.
Para obter orientações detalhadas sobre solução de problemas, consulte[Solução de problemas comuns do](monitoring-and-troubleshooting.md#troubleshooting-common-issues).
# MediaTailor recursos e capacidades de rastreamento do lado do servidor
AWS Elemental MediaTailor aplica automaticamente esses recursos integrados de rastreamento do lado do servidor para otimizar a precisão e a confiabilidade da medição de anúncios. O sistema evita a duplicação de beacons, gerencia o tráfego durante períodos de alto volume, mantém o sequenciamento adequado de eventos e fornece monitoramento abrangente do desempenho sem exigir nenhuma configuração de sua parte. Você só precisa garantir que seu servidor de decisão de anúncio (ADS) forneça os beacons de rastreamento na resposta do VAST.
**nota**
Esses recursos estão disponíveis para novos clientes a partir de 30 de setembro de 2025. Os clientes existentes terão acesso ao longo de 2025 como parte das melhorias contínuas do serviço. Se você quiser acesso imediato a esses recursos, entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
**nota**
Esses recursos se aplicam aos métodos de inserção de anúncios costurados (SSAI) e guiados pelo servidor (SGAI). Os tipos de farol e o tempo são os mesmos nos dois modos. Eles diferem na forma como MediaTailor acionam os beacons — consulte [Rastreamento do lado do servidor com inserção de anúncios guiada pelo servidor (SGAI)](ad-reporting-server-side-sgai.md) para obter detalhes sobre os beacons do lado do servidor SGAI.
## Desduplicação de beacons
MediaTailor impede o disparo de faróis duplicados para eventos publicitários idênticos. O sistema de rastreamento do lado do servidor envia cada sinal de impressão, quartil e conclusão somente uma vez por sessão de visualização do anúncio. Quando os players de vídeo solicitam o mesmo segmento de anúncio várias vezes devido às condições da rede, alterações na taxa de bits ou estratégias de buffer, MediaTailor rastreiam os beacons disparados e bloqueiam transmissões redundantes.
A desduplicação resolve automaticamente cenários comuns que causam um aumento no número de beacons:
+ **Streaming de taxa de bits adaptável**: quando os jogadores baixam diferentes variantes de qualidade do mesmo segmento de anúncio
+ **Cenários de repetição de rede** - Quando os jogadores solicitam segmentos novamente devido a problemas de rede ou tempos limite
+ **Estratégias de buffer de jogadores** - Quando os jogadores pré-buscam ou rebuscam segmentos para fins de buffer
O sistema foi projetado para disparar faróis de impressão apenas uma vez, mesmo quando os jogadores alternam entre diferentes níveis de qualidade.
## Limitação adaptativa e novas tentativas de beacon
MediaTailor gerencia automaticamente as taxas de tráfego do beacon com base nos indicadores de resposta do servidor. O sistema monitora os padrões de resposta HTTP, os tempos limite de conexão e os códigos de erro para detectar o congestionamento e, em seguida, ajusta as taxas de tráfego adequadamente. Quando o sistema identifica indicadores de estresse do servidor, ele reduz as taxas de tráfego para o domínio afetado e aumenta automaticamente as taxas quando os servidores demonstram capacidade aprimorada.
O sistema monitora a integridade do servidor usando estes indicadores:
+ Tempos **limite de conexão HTTP** - Quando as plataformas de medição não respondem dentro dos prazos esperados
+ **Códigos de resposta de erro** - respostas 503, 504 e 507 que indicam sobrecarga do servidor. Seu servidor de anúncios também deve oferecer suporte a esses códigos de erro para obter compatibilidade total.
+ **Padrões de resposta** - mudanças no desempenho da plataforma de medição que indicam problemas de capacidade
O comportamento de repetição tenta automaticamente a entrega por até 1 hora, com atrasos mínimos de 30 segundos entre as tentativas. Esse comportamento de nova tentativa não pode ser configurado.
## Gerenciamento de tráfego de beacon por segundo
Você pode definir limites de TPS para controlar as taxas de entrega de beacons. Essa é a única configuração configurável para recursos de rastreamento do lado do servidor. Os limites no nível da conta limitam o número total de solicitações de rastreamento de anúncios enviadas por todos os parceiros de medição. MediaTailor impõe um limite mínimo de TPS de 10.000 para fornecer capacidade suficiente para operações em escala empresarial.
Envie um ticket de AWS suporte para estabelecer limites de TPS com as seguintes informações:
+ **ID da conta da AWS** — Seu identificador de conta específico
+ **Região de destino** - A região da AWS em que você deseja aplicar o limite de TPS
+ Limite de **TPS desejado - Seu limite** necessário de transações por segundo (mínimo de 10.000)
Por padrão, não há limite de TPS. Você pode solicitar um limite de TPS se seu servidor de decisão de anúncios (ADS) exigir, mas o limite deve ser maior que 10.000 TPS. MediaTailor não excederá o limite especificado, mas não garantirá uma taxa de transferência consistente até esse limite. Seu servidor de decisão de anúncios informará quais limites de TPS ele pode suportar.
## Sinalização em ordem
MediaTailor mantém automaticamente a entrega sequencial de eventos de rastreamento de anúncios. O sistema preserva a ordem dos beacons mesmo quando ocorrem problemas de rede, novas tentativas ou gerenciamento de tráfego. Isso garante que os parceiros de medição recebam os eventos na ordem correta para análises precisas.
O sistema segue a sequência de faróis padrão da indústria:
1. **Iniciar eventos - Acione** quando a reprodução do anúncio começar
1. **Eventos do primeiro quartil** - Disparem com 25% da conclusão
1. **Eventos de ponto médio - Atire** a 50% da conclusão
1. **Eventos do terceiro quartil - Atire** com 75% da conclusão
1. **Eventos de conclusão - Acione** quando os anúncios terminarem
Esses recursos funcionam juntos automaticamente:
+ Os faróis são mantidos durante a aceleração para manter a ordem correta
+ Cada domínio do parceiro de medição tem filas de eventos separadas para evitar interrupções durante os ajustes de taxa
+ A desduplicação rastreia o tipo de evento e a posição do cronograma, mantendo a ordem cronológica