Ao agrupar relatórios agregáveis, é importante otimizar as estratégias de agrupamento para que os limites de privacidade não sejam excedidos. Confira a seguir algumas estratégias recomendadas para enviar lotes de relatórios ao serviço de agregação.
Coletar relatórios
Ao coletar relatórios para incluir em um lote, lembre-se do seguinte:
Tentar novamente o upload do relatório
Observação:os critérios de nova tentativa estão sujeitos a mudanças. Nesse caso, as informações nesta seção serão atualizadas.
Nas plataformas da Web e do SO, uma plataforma vai tentar enviar o relatório três vezes, mas, se o
relatório não for enviado após a terceira tentativa, ele não será enviado. O valor original
scheduled_report_time é preservado, não importa quando o relatório possa ser enviado. O cronograma de novas tentativas varia de acordo com a plataforma:
- Um navegador da Web enviará relatórios quando estiver on-line. Se o envio do relatório falhar, ele vai esperar cinco minutos para a segunda tentativa e 15 minutos para a terceira. Se o navegador ficar off-line, a próxima tentativa será um minuto depois que ele ficar on-line novamente. Não há atraso máximo no envio de relatórios na Web. Isso significa que, se o navegador ficar off-line, não importa há quanto tempo o relatório foi gerado, quando o navegador voltar on-line, ele vai tentar enviar o relatório de acordo com a política de nova tentativa.
- Um smartphone Android tem uma conexão de rede consistente. Assim, o job será executado para enviar relatórios uma vez por hora. Isso significa que, se um relatório falhar, ele será tentado novamente na próxima hora e na hora seguinte. Se o dispositivo não tiver uma conexão, ele vai tentar enviar o relatório novamente com o próximo job de geração de relatórios que será executado depois que o dispositivo se conectar à rede novamente. O atraso máximo é de 28 dias, o que significa que o dispositivo não vai enviar um relatório gerado há mais de 28 dias.
Aguardar relatórios
Recomendamos aguardar os relatórios que chegam com atraso ao coletar relatórios para agrupamento. Os relatórios atrasados podem ser determinados verificando o valor scheduled_report_time em relação ao momento em que o relatório foi recebido. A diferença de tempo entre esses relatórios vai ajudar a determinar por quanto tempo você pode esperar por relatórios atrasados. Por exemplo, à medida que os relatórios atrasados forem coletados, verifique o
campo scheduled_report_time e observe o atraso em horas à medida que 90%, 95% e 99% dos relatórios são
recebidos. Esses dados podem ser usados para determinar o tempo de espera para os relatórios que chegam atrasados.
Os relatórios agregados instantâneos
podem ser usados para reduzir a chance de atrasos.
A imagem a seguir mostra os relatórios que chegam com atraso sendo armazenados nos lotes apropriados de acordo com o horário programado do relatório. O lote T representa scheduled_report_time, e T+X representa o tempo de espera
para relatórios atrasados. Isso resulta em um relatório de resumo que inclui a maioria dos relatórios incluídos no lote que corresponde ao horário programado.
Contabilização de relatórios agregáveis
O serviço de agregação mantém uma regra de"sem duplicatas". Essa regra garante que todos os relatórios agregáveis com o mesmo ID compartilhado sejam incluídos no mesmo lote.
Depois que os relatórios forem coletados, eles precisam ser agrupados de forma que todos os relatórios com o mesmo ID compartilhado façam parte de um lote.
Se uma denúncia já tiver sido processada em outro lote, isso poderá resultar em um erro de orçamento de privacidade esgotado. O agrupamento correto de relatórios ajuda a evitar que os lotes sejam rejeitados devido à regra "sem duplicatas".
Um ID compartilhado é uma chave gerada para cada relatório para acompanhar a contabilidade de relatórios agregáveis. O ID compartilhado garante que os relatórios com o mesmo ID compartilhado contribuam para apenas um relatório de resumo. Isso significa que os relatórios que são mapeados para um ID compartilhado precisam ser incluídos em um único lote. Por exemplo, se os Relatórios X e Y tiverem o mesmo ID compartilhado, eles precisarão ser incluídos no mesmo lote para evitar que os relatórios sejam descartados por duplicação.
A imagem a seguir demonstra os componentes shared_info que são hashados juntos para gerar um ID compartilhado.
A imagem a seguir demonstra como dois relatórios diferentes podem ter o mesmo ID compartilhado:
Observação:scheduled_report_time é truncado por hora, e source_registration_time é truncado por
dia. Além disso, report_id não é usado na criação de IDs compartilhados. A granularidade do tempo pode ser atualizada no futuro.
Relatórios duplicados em lotes
O campo shared_info em um relatório agregável contém um UUID no campo report_id, que é
usado para identificar relatórios duplicados em um lote. Se houver mais de um relatório com o mesmo report_id em um lote, somente o primeiro relatório será agregado, e os outros serão considerados duplicados e descartados silenciosamente. A agregação continuará normalmente e nenhum erro será enviado.
Embora não seja obrigatório, a adtech pode esperar alguns ganhos de performance ao filtrar os
relatórios duplicados com os mesmos IDs antes da agregação.
O report_id é exclusivo para cada relatório.
Relatórios duplicados em vários lotes
Cada relatório recebe um ID compartilhado, que é um ID gerado a partir de pontos de dados combinados que vêm do campo shared_info do relatório. Vários relatórios podem ter o mesmo ID compartilhado, e cada lote
pode conter vários IDs compartilhados. Todos os relatórios com o mesmo ID compartilhado precisam estar no mesmo lote. Se
relatórios com o mesmo ID compartilhado forem enviados em vários lotes, apenas o primeiro lote será aceito,
e os outros serão rejeitados como duplicatas. Para evitar isso,
os lotes precisam ser criados de maneira adequada.
A imagem a seguir mostra um exemplo em que relatórios com o mesmo ID compartilhado entre lotes podem causar
falha no lote posterior. Na imagem, é possível ver que dois ou mais relatórios com o mesmo ID compartilhado e679aa são agrupados em lotes diferentes, 1 e 2. Como o orçamento de todos os relatórios com ID compartilhado
e679aa é consumido durante a geração do relatório de resumo do lote 1, o lote 2 não é permitido e falha com
um erro.
Relatórios em lote
Confira a seguir as maneiras recomendadas de agrupar relatórios para evitar duplicações e otimizar a contabilidade de relatórios agregados.
Batch por anunciante
Observação:essa estratégia é recomendada apenas para agregação de Relatórios de atribuição.
A agregação particular não tem um campo attribution_destination, que é o anunciante. É
recomendado agrupar por anunciante, ou seja, incluir relatórios que pertencem a um único anunciante no
mesmo lote para evitar atingir o limite de conta de relatório agregável para cada lote. O anunciante é um campo considerado na geração de IDs compartilhados. Portanto, os relatórios com o mesmo anunciante também podem ter o mesmo ID compartilhado, o que exigiria que eles estivessem no mesmo lote para evitar erros.
Lote por tempo
Recomendamos considerar o horário programado do relatório
(shared_info.scheduled_report_time) ao fazer o agrupamento. O horário do relatório programado é truncado para a hora
na geração de ID compartilhado. Portanto, no mínimo, os relatórios precisam ser agrupados em intervalos de uma hora, ou seja,
todos os relatórios com horário programado na mesma hora precisam ir para o mesmo lote para evitar
que relatórios com o mesmo ID compartilhado sejam incluídos em vários lotes, o que vai gerar erros de job.
Ruído e frequência do lote
É recomendável considerar o impacto do ruído na frequência de processamento dos relatórios agregáveis. Se os relatórios agregáveis forem agrupados com mais frequência (por exemplo, se os relatórios forem processados uma vez por hora), menos eventos de conversão serão incluídos e o ruído terá um impacto relativo maior. Se a frequência for reduzida e os relatórios forem processados uma vez por semana, o ruído terá um impacto relativo menor. Para entender melhor o impacto do ruído nos lotes, faça testes com o Noise Lab.