A proposta da Attribution Reporting passou por várias mudanças para atender a feedback da comunidade, desde alterações no mecanismo da API até novas funcionalidades.
Registro de alterações
- 7 de fevereiro de 2022: adição da seção sobre redirecionamento do acionador de cabeçalho.
- 27 de janeiro de 2022: primeira publicação do artigo.
Qual é o público desta postagem?
Esta postagem é para você:
- Se você já entende a API, por exemplo, se esteve observando ou participantes das discussões no repositório WICG e querem entender o lote de mudanças feitas na proposta em janeiro de 2022.
- Se você estiver usando a API Attribution Reporting em uma demonstração ou em um experimento na produção.
Se você está começando a usar essa API e/ou ainda não a testou, acesse diretamente ao introdução à API como alternativa.
Migração futura
Depois que essas mudanças forem implementadas no Chrome: se você usar relatórios de eventos da API Attribution Reporting em uma demonstração ou em um experimento em produção (teste de origem), será necessário editar o código para que a API continue funcionando. Considere também usar os novos recursos.
Este artigo também lista as mudanças nos relatórios agregáveis. No entanto, se implementadas, essas mudanças não vão exigir nenhuma ação ou migração, já que ainda não há implementação em navegador para relatórios agregáveis até o momento.
Alterações de nome
Relatórios de resumo e relatórios agregáveis
O que antes era chamado de relatórios agregados agora será chamado de como relatórios de resumo.
Os relatórios de resumo são o resultado final da agregação de vários relatórios agregáveis. antes chamados de "contribuições" ou "contribuições do histograma".
Mudanças no mecanismo da API
Registro de origem com base em cabeçalho (relatórios de eventos)
O que está mudando e por quê?
Quando o usuário visualiza ou clica em um anúncio, o navegador (localmente no dispositivo do usuário) registra esse evento.
junto com parâmetros específicos dos Relatórios de atribuição (como o
attributionsourceeventid, attributiondestination, attributionexpiry e outros parâmetros). A
os valores desses parâmetros são definidos pela adtech.
A forma como esses parâmetros são definidos está mudando.
Na proposta anterior, os parâmetros precisavam ser incluídos no lado do cliente: nas tags âncoras como atributos HTML ou como argumentos de uma chamada baseada em JS. Os parâmetros precisavam ser conhecidos ao clicar ou na visualização tempo de resposta.
Na nova proposta, o valor desses parâmetros é definido no servidor de adtechs.
Isso tem várias vantagens, especialmente em termos de segurança: o mecanismo de cabeçalho permite que os relatórios origem (normalmente uma adtech) controla diretamente se uma fonte de atribuição está registrada no do projeto. Isso reduz parcialmente as preocupações com fraudes, porque, com essa mudança, um navegador genuíno nunca registrar uma fonte sem a permissão da origem do relatório.
Como funciona o registro da fonte?
- Para um determinado anúncio, a adtech agora precisaria definir um atributo específico do lado do cliente
attributionsrc: O valor desse atributo é um URL para o qual o navegador enviará uma solicitação essa solicitação vai incluir um novo cabeçalho HTTPAttribution-Reporting-Source-Info, valor,navigationouevent,especifica se a origem foi um clique ou uma visualização, respectivamente. - Ao receber essa solicitação, o servidor de rastreamento de cliques/visualização deve responder com um
cabeçalho,
Attribution-Reporting-Register-Source, que contém a atribuição desejada parâmetros. A origem que retorna esse cabeçalho agora é a origem do relatório (anteriormente definida como
attributionreportto).Cabeçalho da resposta HTTP
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Saiba mais na explicação técnica
Registrar fontes de atribuição
Participe da discussão pública
Acionador de atribuição baseada em cabeçalho (relatórios de eventos)
O que está mudando e por quê?
Assim como o registro de cliques ou visualizações, a nova proposta altera o acionador de atribuição, quando um
a adtech instrui o navegador a registrar uma conversão, com uma abordagem baseada em cabeçalho.
Esse mecanismo está alinhado com o registro de origem baseado em cabeçalho e é mais
convencional do que o mecanismo de redirecionamento usado anteriormente.
Além disso, na nova proposta, o atributo attributionsrc é necessário na página de conversão.
A justificativa é uma questão de permissões: na proposta anterior, o site do acionamento — normalmente,
site de um anunciante, tinham controle geral sobre o recurso por meio de um cabeçalho Permissions-Policy, mas
não tinham controle granular em nível de elemento sobre a possibilidade de um elemento enviar uma solicitação a uma parte
isso acionaria uma atribuição. attributionsrc altera isto: este marcador obrigatório
permite ao anunciante monitorar e, assim, controlar quais elementos podem acionar uma
atribuição.
No lado da origem, normalmente, um site do editor, um controle de toda a página por meio do
Permissions-Policy, bem como um controle de todo o elemento via attributionsrc, estão presentes.
Como funciona o acionador de atribuição?
Ao receber uma solicitação de pixel e decidir que ele deve ser categorizado como uma conversão, uma adtech
deve responder com um novo HTTP
cabeçalho Attribution-Reporting-Register-Event-Trigger.
O valor desse cabeçalho especifica como tratar o evento acionador como um objeto JSON. Isto é igual informações que foram definidas como parâmetros de consulta na proposta anterior.
Cabeçalho da resposta HTTP Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
Redirecionamento (opcional)
Opcionalmente, o servidor de adtechs pode transformar a resposta que contém Attribution-Reporting-Register-Event-Trigger em uma resposta de redirecionamento.
Assim, terceiros podem observar o evento de conversão e instruir o navegador a atribuí-lo.
O redirecionamento é opcional. ela não será necessária quando uma adtech e um terceiro tiverem pixels na página.
Mais detalhes em Relatórios de terceiros.
Saiba mais na explicação técnica
Participe da discussão pública
Nenhum worklet (relatórios agregáveis)
O que está mudando e por quê?
Na proposta anterior para relatórios agregáveis, o acesso JavaScript era necessário para invocar uma worklet, um mecanismo baseado em JavaScript, que geraria esses relatórios.
Na nova proposta, nenhum worklet é necessário. Em vez disso, uma adtech define de forma declarativa (via HTTP). cabeçalhos: as regras que o navegador deve usar para gerar relatórios agregáveis.
A nova proposta oferece vários benefícios:
- Implementação do navegador:o novo design, ao contrário do design da worklet, é significativamente mais simples, porque não requer um novo ambiente de execução em navegadores.
- Experiência para desenvolvedores:o novo design conta com cabeçalhos, que são comumente usados amplamente conhecidas pelos desenvolvedores, ao contrário dos worklets. Ela também se alinha estreitamente à superfície da API para registro de origem, facilitando o aprendizado e o uso da API.
- Adoção: o novo design permite que mais sistemas de medição atuais usem dados agregáveis e detecção de ameaças. Muitas soluções de métricas são somente HTTP: elas dependem de solicitações de imagem — pixel que não exigem acesso ao JavaScript. Mas, como a abordagem do worklet exigiu acesso ao JavaScript, pode ter sido difícil migrar para alguns sistemas de medição atuais.
- Robustez:o novo design ajuda a reduzir a perda de dados porque é mais fácil de integrar.
com a semântica
keepalive, por exemplo, se um clique ou uma visualização for registrado quando um usuário estiver saindo uma página.
Como funciona o mecanismo sem worklet?
Esse mecanismo declarativo é baseado em cabeçalhos HTTP, assim como o registro de fonte no nível do evento e o cabeçalho do acionador de atribuição. Mais detalhes sobre isso nas próximas seções.
Participe da discussão pública
Registro de fonte com base em cabeçalho (relatórios agregáveis)
um novo mecanismo é proposto para registrar uma fonte de relatório agregável; que esse mecanismo O mesmo que o registro da origem no nível do evento.
Apenas o nome do cabeçalho é diferente: Attribution-Reporting-Register-Aggregatable-Source.
Saiba mais na explicação técnica
Registro da fonte de atribuição
Acionador de atribuição baseada em cabeçalho (relatórios agregáveis)
um novo mecanismo é proposto para registrar uma fonte de relatório agregável; que esse mecanismo Igual ao acionador de atribuição no nível do evento.
Apenas o nome do cabeçalho é diferente: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Saiba mais na explicação técnica
Registro do acionador de atribuição
Novos recursos
Relatórios de terceiros (relatórios agregáveis e de eventos)
O que está mudando e por quê?
Dois aspectos da nova proposta ajudam a oferecer melhor suporte aos casos de uso de relatórios de terceiros:
- As adtechs podem redirecionar solicitações de rede para outros servidores, o que permite essas outras adtechs façam o próprio registro de fonte e acionador. Essa é uma maneira comum são configuradas hoje. Isso torna a API mais fácil de adotar, entre outras sistemas de relatórios de terceiros.
- As origens dos relatórios, normalmente as adtechs, não compartilham mais a maioria dos limites de privacidade. Isso dá suporte ao uso casos em que várias adtechs trabalham com os mesmos editores ou anunciantes.
Como funcionam os relatórios de terceiros?
Na nova proposta, o registro e o acionador de origem com base em resposta dependem cabeçalhos HTTP. Uma adtech pode aproveitar os redirecionamentos HTTP para essas solicitações.
Se uma solicitação de clique/visualização no site de um editor (registro de origem) for redirecionada posteriormente para
várias partes, cada uma delas pode registrar essa visualização ou clicar (evento de origem).
Da mesma forma, uma adtech pode redirecionar uma solicitação de atribuição específica feita por um site de diversificação.
Permitir que várias outras partes registrem uma conversão (acionador de atribuição).
Cada parte pode acessar seus relatórios separados e configurá-los com dados diferentes.
Registrar vários acionadores sem redirecionamentos
Também é possível registrar vários acionadores de atribuição sem usar redirecionamentos. Para isso, adicione vários elementos de pixel no lado da conversão (um por acionador).
Participe da discussão pública
Medição de visualizações (relatórios de eventos e relatórios agregáveis)
O que está mudando e por quê?
Na nova proposta, a medição de visualizações e de cliques funciona de maneira unificada:
registerattributionsrc, o atributo específico da visualização que instruiu o navegador a visualizações com cliques, não faz mais parte da proposta.- Os mecanismos de privacidade agora estão unificados nos tipos de clique e visualização. Para isso, confira detalhes em Ruído e transparência.
A proposta dessa mudança será alinhada ao novo mecanismo de registro baseado em cabeçalho. Ele também simplifica a experiência do desenvolvedor quando pretende oferecer suporte a cliques e visualizações de medida.
Como funciona a medição de conversões de visualização?
A medição de visualizações e a medição de cliques dependem do registro baseado em cabeçalho.
Saiba mais na explicação técnica
Relatórios de eventos (para cliques e visualizações)
Participe da discussão pública
Depuração / análise de desempenho (relatórios de eventos e relatórios agregáveis)
O que está mudando e por quê?
Um mecanismo de depuração foi adicionado à proposta para ajudar os desenvolvedores a detectar bugs, bem como comparar a performance dos Relatórios de atribuição com as soluções de métricas atuais com base em cookies.
Como funciona a depuração?
Os registros de origem e acionador vão aceitar um novo parâmetro debug_key, um não assinado de 64 bits
inteiro (ou seja, um número grande).
Se um relatório for criado com chaves de depuração de origem e acionador e se um cookie Samesite=None ar_debug=1
estiver presente no cookie jar da origem do relatório no momento do registro da fonte e do acionador, um valor
relatório (JSON) serão enviados para um endpoint .well-known/attribution-reporting/debug:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Os relatórios agregáveis e de evento também incluirão esses dois novos parâmetros, para que possam ser associadas ao relatório de depuração correto.
Saiba mais na explicação técnica
Opcional: relatórios de depuração estendidos
Participe da discussão pública
Recursos de filtragem (relatórios de eventos e relatórios agregáveis)
O que está mudando e por quê?
Como eles oferecem suporte a casos de uso importantes no ecossistema de publicidade atual, vários casos de uso agora serão compatíveis com relatórios agregáveis e de evento:
- Filtragem de conversões:filtra uma conversão com base nas informações da origem. Para exemplo, selecione diferentes dados de acionadores (dados de conversão) para cliques em anúncios e visualizações.
- Incompatibilidade de atribuição:filtrar conversões que foram atribuídas incorretamente. este é um um tipo específico de filtro de conversão. Por exemplo, filtre as conversões que são correspondidas a a visualização/clique do anúncio errado devido ao escopo de destino etld+1 na API.
Como funcionam os recursos de filtragem? (para relatórios de eventos)
Um campo source_data opcional no objeto JSON da origem pode definir itens que serão
usada posteriormente pelo navegador no momento da conversão para aplicar a lógica de filtragem.
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
O registro do acionador agora vai aceitar um cabeçalho opcional Attribution-Reporting-Filters.
Cabeçalho de resposta HTTP Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
Como alternativa, o cabeçalho Attribution-Reporting-Register-Event-Trigger pode ser estendido com uma
filters para fazer filtragem seletiva e definir trigger_data com base em source_data.
Se as chaves nos filtros de chaves de correspondência JSON em source_data, o acionador será
será ignorada se a interseção estiver vazia.
Saiba mais na explicação técnica
Filtros de atribuição opcionais
Participe da discussão pública
Mudanças na proteção de privacidade
Ruído e transparência (relatórios de eventos e relatórios agregáveis)
O que está mudando e por quê?
Na nova proposta, um dos mecanismos de privacidade dos relatórios foi aprimorado: os relatórios são
sujeito a resposta aleatória.
Isso significa que algumas conversões reais serão informadas corretamente. e uma certa porcentagem
algumas conversões reais serão suprimidas ou algumas conversões falsas serão adicionadas.
Essa nova técnica tem alguns benefícios:
- Unifica o mecanismo de privacidade para cliques e visualizações.
- É mais simples pensar do que um mecanismo em que os dados do acionador (dados de conversão) e o ruído do link da origem do acionador seriam separados.
- Ela define uma estrutura de privacidade que pode, com as configurações corretas de ruído, garantir que nenhuma parte possa confiar na API para saber com certeza se um usuário individual fez uma conversão (ou não) para um determinado anúncio.
Esse novo mecanismo substitui o anterior, que aciona dados em 5% das vezes (dados de conversão) foi substituído por um valor aleatório.
Além disso, o valor da probabilidade de resposta aleatória foi incluído no corpo do relatório.
(campo randomized_trigger_rate). Este campo especifica a probabilidade (0 a 1) de uma fonte ser
sujeito a respostas aleatórias.
Isso tem dois benefícios principais:
- Ele torna o comportamento subjacente do navegador transparente às partes que receberão os relatórios. (geralmente, adtechs).
- Ela seria útil em um futuro em que a API tivesse suporte em todo navegadores: diferentes navegadores podem decidir aplicar diferentes níveis de ruído, dependendo do metas de privacidade, e as partes que vão lidar com o relatório precisam de visibilidade sobre isso.
Como o ruído funciona?
Na nova proposta, no momento em que uma origem é registrada (ou seja, um clique no anúncio ou uma visualização é registrado), o navegador decide aleatoriamente se vai atribuir conversões de verdade e enviar relatórios sobre isso clique/visualização do anúncio ou se ele vai gerar uma saída falsa.
A saída fictícia pode ser:
- Nenhum relatório, independentemente da conversão do usuário.
- Uma ou várias denúncias falsas, independentemente de o usuário realizar ou não uma conversão.
Em relatórios falsos, os dados do acionador (dados de conversão) são aleatórios: um valor aleatório de 3 bits para cliques (qualquer número entre 0 e 7) e um valor aleatório de 1 bit para visualizações (0 ou 1).
Assim como os relatórios reais, os relatórios falsos não são enviados imediatamente após a conversão do usuário. Eles são enviados o fim de uma janela de relatório aleatória.
Há três janelas de relatórios para cliques (2, 7 ou 30 dias após o clique). Cada item falso é atribuído aleatoriamente a uma das janelas de relatório.
Separadamente, como a proposta anterior já foi mencionada, a ordem dos relatórios dentro de uma janela é aleatória.
Saiba mais na explicação técnica
Exemplos de conversões falsas e com ruído
Participe da discussão pública
Limitações de relatórios (relatórios de eventos e relatórios agregáveis)
Relatórios de limites de origem
O que está mudando e por quê?
A nova proposta limita explicitamente quantas partes podem medir eventos entre dois sites.
- O número máximo de origens de relatórios únicas (geralmente adtechs) que podem ser registradas fontes por {publisher, anunciante} propõe-se que sejam limitadas a 100 por 30 dias. Isso será incrementado para cada clique ou visualização do anúncio (evento de origem), mesmo aqueles que não são atribuídas.
- O número máximo de origens de relatórios únicas (geralmente adtechs) que podem enviar relatórios por {publisher, anunciante} tem a proposta de limitar-se a 10 por 30 dias. Este contador será é incrementado para cada conversão atribuída.
Esses limites devem ser altos o suficiente para que não limitem a capacidade dos agentes de fazer medições. mas baixas o suficiente para reduzir algumas formas de abuso da API.
Período de espera para relatórios / limites de taxa
O que está mudando e por quê?
O período de espera de relatórios é um mecanismo de privacidade que limita a quantidade total de informações enviadas usando essa API em determinado período para um usuário.
Na nova proposta, 100 relatórios por {site de origem, destino, origem do relatório} (geralmente {publisher, anunciante, adtech}) podem ser programados para mais de 30 dias.
Além desse limite, o navegador deixará de programar relatórios que correspondam a este {site de origem, destino, geração de relatórios} (geralmente {editor, anunciante, adtech}), até o período de 30 dias a contagem de relatórios fica abaixo de 100 para esse {site de origem, destino, origem do relatório}.
Saiba mais na explicação técnica
Relatórios de período de espera / limites de taxa
Limite de destino (somente relatórios de eventos)
O que está mudando e por quê?
O limite de destino foi modificado para incluir a origem do relatório (geralmente, uma adtech) no escopo: 100 exclusivos destinos pendentes (normalmente, sites de anunciantes ou sites em que as conversões devem ocorrer) local) são permitidos por {publisher, adtech}.
Essa é uma proteção de privacidade para limitar a reconstrução do histórico de navegação.
Saiba mais na explicação técnica
Limitação do número de destinos exclusivos cobertos por origens pendentes
Todos os recursos
- Consulte API Attribution Reporting.
- Leia O que você precisa saber sobre a API.
A imagem do cabeçalho é de Diana Polekhina no Unsplash.