Geração de relatórios de atribuição

Enviar feedback

Atualmente, é comum que as soluções de atribuição e de métricas de dispositivos móveis usem identificadores entre partes diferentes, como o ID de publicidade. A API Attribution Reporting foi projetada para melhorar a privacidade do usuário ao remover a dependência de identificadores do usuário entre diferentes partes, bem como oferecer suporte aos principais casos de uso para avaliação de métricas de conversão e atribuição em apps e na Web.

Essa API inclui os mecanismos estruturais abaixo que oferecem um framework para melhoria de privacidade, que vão ser apresentados em mais detalhes nas próximas seções deste documento:

Os mecanismos anteriores limitam a capacidade de estabelecer uma relação sobre a identidade do usuário entre dois apps ou domínios diferentes.

A API Attribution Reporting oferece suporte aos casos de uso abaixo:

  • Relatórios de conversão: ajudam os anunciantes a medir o desempenho das campanhas ao apresentar as métricas de conversões e os valores de conversões, ou seja, os acionadores, em diferentes dimensões, como por campanha, grupo de anúncios ou criativo de anúncio.
  • Otimização: gera relatórios a nível de evento que corroboram com a otimização dos gastos com publicidade, fornecendo dados de atribuição por impressão que podem ser usados para treinar modelos de ML.
  • Detecção de atividade inválida: gera relatórios que podem ser usados para detecção e análise de tráfego inválido e de fraudes de anúncios.

Em um nível mais alto, a API Attribution Reporting funciona das maneiras descritas abaixo, que serão apresentadas em mais detalhes nas próximas seções deste documento:

  1. A plataforma de tecnologias de publicidade realiza um processo de registro para usar a API Attribution Reporting.
  2. A plataforma de tecnologias de publicidade registra fontes de atribuição, que são cliques ou visualizações de anúncios, usando a API Attribution Reporting.
  3. A plataforma de tecnologias de publicidade registra os acionadores, que são conversões do usuário no app ou no site do anunciante, usando a API Attribution Reporting.
  4. A API Attribution Reporting estabelece a correspondência entre os acionadores e as fontes de atribuição, ou seja, uma atribuição de conversão. Em seguida, um ou mais acionadores são incluídos em relatórios a nível de evento e relatórios agregáveis, que são enviados do dispositivo para as plataformas de tecnologias de publicidade.

Registrar uma plataforma de tecnologias de publicidade

Para acessar a API Attribution Reporting e garantir que os mecanismos de privacidade funcionem conforme o esperado, todas as plataformas de tecnologias de publicidade, incluindo a do Google, precisam passar por um processo de registro simples. Os detalhes desse processo ainda estão em desenvolvimento e seu feedback é muito útil.

O processo de registro garante que as plataformas de tecnologias de publicidade não se dupliquem desnecessariamente para ter acesso a mais informações sobre as atividades de um usuário em apps ou sites. Por exemplo, a API Attribution Reporting limita a quantidade de rastreamento e informações que uma plataforma de tecnologias de publicidade consegue visualizar de um determinado acionador e fonte de atribuição. Mais detalhes sobre esses limites são apresentados na seção sobre como ver dados de medição em relatórios de atribuição mais adiante neste documento.

As empresas podem se registrar várias vezes, desde que haja uma necessidade comercial legítima, como a operação de várias linhas de produtos independentes, e que a empresa não combine dados de vários registros para contornar as restrições de privacidade.

Durante o processo de registro, as plataformas de tecnologias de publicidade fornecem informações como as abaixo:

  • Informações comerciais e de contato
  • URLs de postback usados para registrar fontes de atribuição, acionar a atribuição e receber relatórios a nível de evento e relatórios agregáveis
  • Casos de uso da API Attribution Reporting

Registrar uma fonte de atribuição (clique ou visualização)

A API Attribution Reporting se refere a visualizações e cliques em anúncios como fontes de atribuição. Para registrar um clique ou uma visualização de anúncio, chame registerAttributionSource(). Essa API espera receber os parâmetros abaixo:

  • URI da fonte de atribuição: a plataforma emite uma solicitação a esse URI para buscar metadados associados à fonte de atribuição.
  • Evento de entrada: um objeto InputEvent, para um evento de clique, ou null, para um evento de visualização.

Quando a API faz uma solicitação para o URI da fonte de atribuição, a plataforma de tecnologias de publicidade precisa responder com os metadados da fonte de atribuição em um novo cabeçalho HTTP Attribution-Reporting-Register-Source, incluindo os campos abaixo:

  • ID do evento da fonte: uma DOMString que codifica um número inteiro, sem assinatura, de 64 bits. Esse valor representa os dados a nível de evento associados a essa fonte de atribuição (clique ou visualização do anúncio).
  • Destino: uma origem com o nome de eTLD+1 ou do pacote do app em que acontece o evento acionador.
  • Validade (opcional): período de validade, em segundos, após o qual a fonte precisa ser excluída do dispositivo. O padrão é 30 dias, com um período mínimo de 2 dias e um período máximo de 30 dias. Esse número é arredondado para o dia mais próximo.
  • Prioridade de fonte (opcional): um número inteiro de 64 bits, assinado, usado para selecionar a fonte de atribuição a que um determinado acionador vai ser associado caso várias origens de atribuição possam ser associadas a esse acionador.

    Quando um acionador é recebido, a API encontra a fonte de atribuição correspondente com o valor de prioridade de fonte mais alto e gera um relatório. Cada plataforma de tecnologias de publicidade pode definir a própria estratégia de priorização.

    Quanto maior o valor, maior a prioridade.

  • Janelas de atribuição de instalação e pós-instalação (opcional): usadas para determinar a atribuição para eventos pós-instalação, descritos mais adiante neste documento.

A resposta de metadados da fonte de atribuição pode incluir outros dados nos cabeçalhos separados abaixo:

O snippet abaixo mostra o modelo atual dos dados de fonte de atribuição:

Attribution-Reporting-Register-Source: {
  "source_event_id": "[64 bit unsigned integer]",
  "destination": "[eTLD+1 or app package name]",
  "expiry": "[64 bit signed integer]",
  "source_priority": "[64 bit signed integer]"
}
Attribution-Reporting-Register-Aggregate-Source: <aggregation-key-data>
Attribution-Reporting-Redirects: "https://adtechpartner.example"

As etapas abaixo mostram um exemplo de fluxo de trabalho:

  1. O SDK de tecnologias de publicidade chama a API para iniciar o registro da fonte de atribuição:

    registerAttributionSource(
        Uri.parse("https://adtech.example/attribution_source?my_ad_click_id=123"),
        myClickEvent);
    
  2. A API faz uma solicitação para https://adtech.example/attribution_source?my_ad_click_id=123, usando este cabeçalho:

    Attribution-Reporting-Source-Info: navigation
    
  3. O servidor HTTPS dessa plataforma de tecnologias de publicidade responde com cabeçalhos que contém:

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "234",
        "expiry": "60000",
        "source_priority": "5"
    }
    Attribution-Reporting-Redirects: https://adtechpartner.example?their_ad_click_id=567
    Attribution-Reporting-Source-Info: navigation
    
  4. A API faz uma solicitação para cada URL especificado em Attribution-Reporting-Redirects. Neste exemplo, somente um URL é especificado, de modo que a API faz uma solicitação para https://adtechpartner.example?their_ad_click_id=567.

  5. O servidor HTTPS dessa plataforma de tecnologias de publicidade responde com cabeçalhos que contém:

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "789",
        "expiry": "120000",
        "source_priority": "2"
    }
    

Duas fontes de atribuição de navegação (cliques) são registradas com base nas solicitações apresentadas nas etapas anteriores.

Registrar um acionador (conversão)

As plataformas de tecnologias de publicidade podem registrar acionadores, que são conversões, como instalações ou eventos pós-instalação, usando o método triggerAttribution().

O método triggerAttribution() espera receber o parâmetro URI do acionador. A API emite uma solicitação a esse URI para buscar metadados associados ao acionador.

A API segue os redirecionamentos. A resposta do servidor de tecnologias de publicidade precisa incluir um cabeçalho HTTP com o nome Attribution-Reporting-Register-Event-Trigger, que representa as informações sobre um ou mais dos acionadores registrados. O conteúdo do cabeçalho precisa ser codificado em JSON (link em inglês) e incluir os campos abaixo:

  • Dados do acionador: dados para identificar o evento acionador (três bits para cliques, um bit para visualizações).
  • Prioridade do acionador (opcional): um número inteiro de 64 bits, assinado, que representa a prioridade do acionador em comparação a outros acionadores da mesma fonte de atribuição
  • Chave de eliminação de duplicação (opcional): número inteiro de 64 bits, assinado, que é usado para identificar casos em que o mesmo acionador é registrado várias vezes pela mesma plataforma de tecnologias de publicidade para a mesma fonte de atribuição

A resposta do servidor de tecnologias de publicidade pode incluir outros dados nos cabeçalhos abaixo:

Diferentes plataformas de tecnologias de publicidade podem registrar o mesmo evento acionador usando redirecionamentos no campo Attribution-Reporting-Redirects ou várias chamadas para o método triggerAttribution(). Recomendamos que você use o campo da chave de eliminação de duplicação para evitar incluir acionadores duplicados nos relatórios, caso uma mesma plataforma de tecnologias de publicidade forneça várias respostas para um único evento acionador.

O snippet abaixo mostra o modelo atual para dados do acionador:

Attribution-Reporting-Register-Event-Trigger: {
    "trigger_data": "[unsigned 64-bit integer]",
    "trigger_priority": "[signed 64-bit integer]",
    "deduplication_key": "[signed 64-bit integer]"
}
Attribution-Reporting-Aggregate-Trigger-Data: <aggregation-key-data>
Attribution-Reporting-Aggregate-Values: <aggregation-value-data>
Attribution-Reporting-Redirects: "https://adtechpartner.example"

As etapas abaixo mostram um exemplo de fluxo de trabalho:

  1. O SDK de tecnologias de publicidade chama a API para iniciar o registro do acionador:

    triggerAttribution(
        Uri.parse("https://adtech.example/attribution_trigger?app_install=123"));
    
  2. A API faz uma solicitação para https://adtech.example/attribution_trigger?app_install=123.

  3. O servidor HTTPS dessa plataforma de tecnologias de publicidade responde com cabeçalhos que contém:

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "1122",
        "trigger_priority": "3",
        "deduplication_key": "3344",
    }
    Attribution-Reporting-Redirects: https://adtechpartner.example?app_install=567
    
  4. A API faz uma solicitação para cada URL especificado em Attribution-Reporting-Redirects. Neste exemplo, somente um URL é especificado, de modo que a API faz uma solicitação para https://adtechpartner.example?app_install=567.

  5. O servidor HTTPS dessa plataforma de tecnologias de publicidade responde com cabeçalhos que contém:

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "5566",
        "trigger_priority": "3",
        "deduplication_key": "3344"
    }
    

    Dois acionadores são registrados com base nas solicitações das etapas anteriores.

Aplicação do algoritmo de atribuição com prioridade de fonte

A API Attribution Reporting usa um algoritmo de atribuição com prioridade de fonte para fazer a correspondência entre um acionador (conversão) e uma fonte de atribuição. Em casos em que várias plataformas de tecnologias de publicidade registram uma mesma fonte de atribuição, conforme descrito mais adiante neste documento, a atribuição ocorre de maneira independente para cada plataforma. Em cada plataforma de tecnologias de publicidade, a fonte de atribuição com maior prioridade é atribuída ao evento acionador. Caso haja várias fontes de atribuição com prioridade igual, a API vai escolher a última fonte de atribuição registrada. Qualquer outra fonte de atribuição que não for selecionada vai ser descartada e não poderá ser usada para atribuição a eventos acionadores futuros.

Atribuição após a instalação

Em alguns casos, após a instalação, é necessário atribuir acionadores à mesma fonte de atribuição que gerou a instalação, mesmo que haja outras fontes de atribuição qualificadas que tenham ocorrido mais recentemente.

A API oferece suporte para esse caso de uso, permitindo que as plataformas de tecnologias de publicidade definam um período de atribuição pós-instalação:

  • Ao registrar uma fonte de atribuição, especifique uma janela de atribuição para instalação durante a qual é esperado que as instalações ocorram. Esse período geralmente tem duração de dois a sete dias.
  • Ao registrar uma fonte de atribuição, especifique uma janela de atribuição pós-instalação em que todos os eventos acionadores pós-instalação vão ser associados à fonte de atribuição que gerou a instalação. Esse período geralmente tem duração de sete a trinta dias.
  • A API Attribution Reporting valida quando uma instalação do app acontece e atribui internamente a instalação à fonte de atribuição priorizada. No entanto, a instalação não é enviada a plataformas de tecnologias de publicidade e não é considerada nos respectivos limites de taxa.
  • Os acionadores futuros que ocorrerem na janela de atribuição pós-instalação vão ser atribuídos à mesma fonte de atribuição que a instalação validada, desde que essa fonte seja qualificada.

    Estamos procurando maneiras de oferecer suporte a casos de uso em que o usuário desinstala e reinstala o app.

No futuro, poderemos experimentar ampliar o modelo para oferecer suporte a modelos de atribuição mais avançados.

Suporte a todas as combinações de caminhos de acionadores baseados na Web e no app

A API Attribution Reporting permite a atribuição dos caminhos de acionadores abaixo em um único dispositivo Android:

  • De app para app: o usuário vê um anúncio em um app e faz uma conversão nele ou em outro app instalado.
  • De app para a Web: o usuário vê um anúncio em um app e faz uma conversão em um navegador para dispositivos móveis ou em um app de navegador.
  • Da Web para um app: o usuário vê um anúncio em um navegador para dispositivos móveis ou app de navegador e faz uma conversão em um app.
  • Da Web para a Web: o usuário vê um anúncio em um navegador para dispositivos móveis ou app de navegador e realiza uma conversão nesse navegador ou em outro no mesmo dispositivo.

Permitimos que navegadores da Web ofereçam suporte às novas funcionalidades expostas pela Web, como uma funcionalidade semelhante ao Sandbox de privacidade da API Attribution Reporting da Web (link em inglês), que pode chamar as APIs do Android para ativar a atribuição em apps e na Web.

Priorizar vários acionadores para uma única fonte de atribuição

Uma única fonte de atribuição pode levar a vários acionadores. Por exemplo, um fluxo de compra pode envolver um acionador de "instalação do app", um ou mais acionadores "adicionar ao carrinho" e um acionador "comprar". Cada acionador é atribuído a uma ou mais fontes de atribuição, de acordo com o algoritmo de atribuição com prioridade de fonte, descrito mais adiante neste documento.

Existem limites para quantos acionadores podem ser atribuídos a uma única fonte de atribuição. Para ver mais detalhes, leia a seção sobre como ver dados de medição em relatórios de atribuição mais adiante neste documento. Em casos em que existem vários acionadores excedentes a esses limites, é útil introduzir a lógica de priorização para extrair os acionadores mais importantes. Por exemplo, os desenvolvedores de uma plataforma de tecnologias de publicidade podem querer dar prioridade a acionadores "comprar" em relação a acionadores "adicionar ao carrinho".

Para oferecer suporte a essa lógica, um campo de prioridade separado pode ser definido para o acionador, de modo que os acionadores com maior prioridade sejam escolhidos antes da aplicação dos limites, dentro de uma determinada janela de geração de relatórios.

Permitir que várias plataformas de tecnologias de publicidade registrem acionadores ou fontes de atribuição

É comum que mais de uma plataforma de tecnologias de publicidade receba relatórios de atribuição. Portanto, a API permite que diferentes plataformas de tecnologias de publicidade registrem o mesmo acionador ou fonte de atribuição.

Fontes de atribuição

Os redirecionamentos da fonte de atribuição têm suporte do método registerAttributionSource():

  1. A plataforma de tecnologias de publicidade que chama o método registerAttributionSource() pode fornecer um campo Attribution-Reporting-Redirects extra na resposta, que representa o conjunto de URLs de redirecionamento da tecnologia de publicidade parceira.
  2. A API chama os URLs de redirecionamento para que a fonte de atribuição seja registrada pelas plataformas de tecnologias de publicidade parceiras.

Vários URLs da plataforma de tecnologias de publicidade parceira podem ser listados no campo Attribution-Reporting-Redirects. Contudo, essas plataformas não podem especificar o próprio campo Attribution-Reporting-Redirects.

A API também permite diferentes plataformas de tecnologias de publicidade para cada chamada registerAttributionSource().

Acionadores

O registro de acionadores de terceiros pode ser realizado de maneira semelhante: as plataformas de tecnologias de publicidade podem usar o campo Attribution-Reporting-Redirects extra ou chamar o método triggerAttribution().

Quando um anunciante usa várias plataformas de tecnologias de publicidade para registrar o mesmo evento acionador, é necessário usar uma chave de eliminação de duplicação. A chave de eliminação de duplicação serve para remover qualquer ambiguidade de relatórios repetidos sobre o mesmo evento. Se nenhuma chave de eliminação de duplicação for informada, é possível que acionadores duplicados sejam informados como eventos únicos para as plataformas.

Ver dados de medição em relatórios de atribuição

A API Attribution Reporting permite os tipos de relatórios apresentados abaixo, que são descritos em mais detalhes posteriormente neste documento:

  • Os relatórios de nível de evento associam uma fonte de atribuição específica (clique ou visualização) a bits limitados de dados de acionadores de alta fidelidade.
  • Os relatórios agregáveis não são necessariamente vinculados a uma fonte de atribuição específica. Esses relatórios fornecem dados de acionadores com mais informações e maior fidelidade que os relatórios a nível de evento. Contudo, esses dados só estão disponíveis de maneira agregada.

Esses dois tipos de relatório são complementares e podem ser usados simultaneamente.

Relatórios a nível de evento

Depois que um acionador é atribuído a uma fonte de atribuição, um relatório a nível de evento é gerado e armazenado no dispositivo até que ele possa ser enviado de volta ao URL de postback de cada plataforma de tecnologias de publicidade, durante uma das janelas de tempo para enviar relatórios descritas em mais detalhes posteriormente neste documento.

Os relatórios a nível de evento são úteis quando poucas informações são necessárias sobre o acionador. Os dados do acionador a nível de evento são limitados a três bits de dados para cliques, o que significa que um acionador pode ser atribuído a uma entre oito categorias, e um bit para visualizações. Além disso, os relatórios a nível de evento não oferecem suporte à codificação de dados do acionador de alta fidelidade, como um preço específico ou o momento de acionamento.

O relatório a nível de evento contém os dados abaixo:

  • Destino: nome do pacote do app do anunciante ou o eTLD+1 em que o acionamento ocorreu
  • ID de fonte de atribuição: o mesmo ID de fonte de atribuição usado para registrar uma fonte de atribuição.
  • Tipo de acionador: um ou três bits de dados de acionador de baixa fidelidade, dependendo do tipo de fonte de atribuição

Mecanismos de preservação de privacidade aplicados a relatórios a nível de evento

Fidelidade limitada dos dados do acionador

A API oferece um bit para acionadores de visualização completa e três bits para acionadores de clique. As fontes de atribuição continuam tendo suporte a 64 bits de metadados.

Avalie se é possível reduzir as informações expressas nos acionadores e como fazer isso para que eles funcionem com o número limitado de bits disponíveis nos relatórios a nível de evento.

Framework para ruídos de privacidade diferencial

Um dos objetivos dessa API é permitir que as métricas a nível de evento atendam aos requisitos de privacidade diferencial locais usando respostas k-aleatórias a fim de gerar um resultado com ruído para cada evento de fonte.

O ruído é aplicado caso um evento de atribuição de fonte seja relatado de maneira verdadeira. Uma fonte de atribuição é registrada no dispositivo com probabilidade $ p $ de que a fonte seja registrada normalmente e probabilidade de $ 1-p $ de que o dispositivo escolha aleatoriamente entre todos os estados resultantes possíveis da API, o que inclui não relatar nada ou gerar vários relatórios falsos.

A resposta k-aleatória é um algoritmo que é particular com diferencial de épsilon se a equação abaixo for atendida:

\[ p = \frac{k}{k + e^ε - 1} \]

Para valores de ε baixos, o resultado verdadeiro é protegido pelo mecanismo de resposta k-aleatória. Os parâmetros de ruído exatos estão em fase de desenvolvimento e estão sujeitos a mudanças com base nos feedbacks recebidos.

Limites de acionadores disponíveis (conversões)

Existem limites para o número de acionadores por fonte de atribuição. A proposta atual é esta:

  • De um a dois acionadores para fontes de atribuição de visualização de anúncios
  • Três acionadores para fontes de atribuição de cliques em anúncios

Esses limites são aplicados depois que as prioridades relacionadas às fontes de atribuição e aos acionadores são consideradas.

Limites para o número de plataformas de tecnologias de publicidade por fonte de atribuição

Existem limites para o número de plataformas de tecnologias de publicidade que podem ser associadas a uma única fonte de atribuição. Esses limites são aplicados depois que as prioridades relacionadas às fontes de atribuição e aos acionadores são consideradas.

Janelas de tempo específicas para enviar relatórios

Os relatórios sobre fontes de atribuição de visualização de anúncios são enviados uma hora após o vencimento da fonte. A validade pode ser configurada, mas não pode ser menor que dois dias nem maior que 30 dias.

Os relatórios sobre fontes de atribuição de cliques em anúncios não podem ser configurados e são enviados antes do fim da validade, em períodos específicos em relação ao momento em que a fonte foi registrada. O tempo entre o registro da fonte de atribuição e o vencimento é dividido em várias janelas de relatórios. Cada janela de relatórios tem um prazo, contado a partir do momento de registro da fonte de atribuição. Ao fim de cada janela de relatórios, o dispositivo coleta todos os acionadores que ocorreram desde a janela anterior e envia um relatório programado. A API oferece suporte às janelas de geração de relatórios abaixo:

  • Dois dias: o dispositivo coleta todos os acionadores que ocorreram dentro de um período de no máximo dois dias desde o registro da fonte de atribuição. O relatório é enviado dois dias e uma hora após o momento do registro da fonte de atribuição.
  • Sete dias: o dispositivo coleta todos os acionadores que ocorreram dentro de um período de dois a sete dias desde o registro da fonte de atribuição. O relatório é enviado sete dias e uma hora após o momento do registro da fonte de atribuição.
  • Duração personalizada, definida pelo atributo "validade" de uma fonte de atribuição. O relatório é enviado uma hora após o prazo de validade especificado. Esse valor não pode ser menor que dois dias nem maior que 30 dias.

Relatórios agregáveis

Relatórios agregáveis fornecem dados dos acionadores de maior fidelidade do dispositivo com mais rapidez, como complemento aos dados oferecidos pelos relatórios a nível de evento. Esses dados de maior fidelidade só podem ser observados de forma agregada e não ficam associados a um acionador ou usuário específico. As chaves de agregação têm até 128 bits, o que permite que os relatórios agregáveis ofereçam suporte a casos de uso de geração de relatórios, como estes:

  • Relatórios de valores de acionadores, como receita
  • Processamento de mais tipos de acionadores

Além disso, os relatórios agregáveis têm as características abaixo:

O modelo geral da maneira como a API Attribution Reporting prepara e envia relatórios agregáveis, apresentados na Figura 1, é este:

  1. O dispositivo envia relatórios agregáveis criptografados para a plataforma de tecnologias de publicidade.
  2. A plataforma de tecnologias de publicidade envia um lote de relatórios agregáveis para o serviço de agregação.
  3. O serviço de agregação lê um lote de relatórios agregáveis e, em seguida, descriptografa e agrega esses relatórios.
  4. Os dados agregados finais são enviados de volta à plataforma de tecnologias de publicidade.
Figura 1. Processo usado pela API Attribution Reporting para preparar e enviar relatórios agregados.

Os relatórios agregáveis contêm os dados abaixo relacionados às fontes de atribuição:

  • Fonte: o nome do pacote do app ou o URL da Web eTLD+1 em que o anúncio foi veiculado.
  • Destino: o nome do pacote do app ou o URL da Web eTLD+1 em que o acionador foi ativado.
  • Data: a data em que o evento representado pela fonte de atribuição ocorreu.
  • Payload: valores dos acionadores, coletados como pares de chave-valor criptografados, usados no serviço de agregação confiável para calcular as agregações.

Serviços de agregação

Os serviços apresentados abaixo oferecem funcionalidades de agregação e auxiliam na proteção contra o acesso indevido a dados de agregação.

Esses serviços são gerenciados por diferentes partes, que são descritas em mais detalhes posteriormente neste documento:

  • O serviço de agregação é o único que as plataformas de tecnologias de publicidade precisam implantar.
  • Os serviços de gerenciamento de chaves e orçamento de privacidade são executados por partes confiáveis, chamadas de verificadores. Esses verificadores atestam que o código que executa o serviço de agregação é o código disponibilizado publicamente pelo Google e que todos os usuários do serviço de agregação usam os mesmos serviços de gerenciamento de chaves e orçamento de privacidade.
Serviço de agregação

As plataformas de tecnologias de publicidade precisam implantar, antecipadamente, um serviço de agregação com base em binários fornecidos pelo Google.

Esse serviço de agregação opera em um ambiente de execução confiável (TEE), hospedado na nuvem. Um TEE oferece os benefícios de segurança abaixo:

  • Ele garante que o código que opera no TEE é o binário específico fornecido pelo Google. A menos que essa condição seja atendida, o serviço de agregação não vai poder acessar as chaves de descriptografia que precisa para operar.
  • Ele oferece segurança ao processo em execução, isolando o processo de monitoramento ou adulterações externas.

Esses benefícios deixam o ambiente mais seguro para que um serviço de agregação possa executar operações confidenciais, como o acesso a dados criptografados.

Para mais informações sobre considerações de design, fluxo de trabalho e segurança do serviço de agregação, consulte o documento do serviço de agregação (link em inglês) no GitHub.

Serviço de gerenciamento de chaves

Esse serviço verifica se um serviço de agregação está executando uma versão aprovada do binário e, em seguida, fornece o serviço de agregação na plataforma de tecnologias de publicidade usando as chaves de descriptografia corretas para os dados dos acionadores.

Serviço de orçamento de privacidade

Esse serviço acompanha a frequência com que o serviço de agregação de uma plataforma de tecnologias de publicidade acessa um acionador específico, que pode conter várias chaves de agregação, e limita o acesso ao número correto de descriptografias. É permitido executar uma descriptografia por acionador.

API Aggregatable Reports

A API para criar contribuições de relatórios agregáveis usa a mesma API base que é utilizada para registrar uma fonte de atribuição de relatórios a nível de evento. As seções abaixo descrevem as extensões da API:

Registrar os dados agregáveis da fonte de atribuição

Quando a API faz uma solicitação ao URI da fonte de atribuição, a plataforma de tecnologias de publicidade pode registrar uma lista de chaves de agregação ao responder com um novo cabeçalho HTTP Attribution-Reporting-Register-Aggregate-Source, incluindo os campos abaixo para cada chave de agregação da lista:

  • ID do evento da fonte: uma string com o nome da chave. Usado como chave de junção para combinar as chaves do lado do acionador e formar a chave final.
  • Parte da chave: um valor de bitstring da chave.
  • Deslocamento de chave: um valor inteiro de índice de deslocamento que combina essa parte da chave com a chave do acionador.

A chave final é uma combinação dessa parte e das partes do acionador, usando o campo de deslocamento de chave para concatenar as bitstrings. As chaves finais são restritas a um máximo de 128 bits. As chaves que excedem esse limite ficam truncadas.

No exemplo abaixo, uma plataforma de tecnologias de publicidade usa a API para coletar:

  • contagens de conversões agregadas em nível de campanha;
  • valores de compra agregados em nível de área geográfica.
Attribution-Reporting-Register-Aggregate-Source:
[{
  // Generates a "101011001" key prefix named "campaignCounts".
  "source_event_id": "campaignCounts",
  "key_piece": "101011001", // User saw ad from campaign 345 (out of 511).
  "key_offset": 0 // The first part of the key
                  // when combined with trigger-side keys.
},
{
  // Generates a "101" key prefix named "geoValue".
  "source_event_id": "geoValue",
  // Source-side geo region = 5 (US) but pad with 0s since the shop operates in
  // ~100 separate countries.
  "key_piece": "0000101",
  "key_offset": 0 // The first part of the key
                  // when combined with trigger-side keys.
}]

Registrar o acionador agregável

O registro de acionadores inclui outros dois cabeçalhos.

O primeiro cabeçalho é usado para registrar uma lista de chaves agregadas no lado do acionador. A plataforma de tecnologias de publicidade precisa responder com o cabeçalho HTTP Attribution-Reporting-Aggregate-Trigger-Data, incluindo os campos apresentados abaixo para cada chave agregada da lista:

  • Parte da chave: um valor de bitstring da chave.
  • Deslocamento de chave: um valor inteiro usado como índice de deslocamento ao combinar a parte da chave da fonte de atribuição com a parte da chave do acionador.
  • Chaves de fonte: uma lista de strings com os nomes das chaves da fonte de atribuição que vão ser combinadas com a chave de acionador para formar as chaves finais.

O snippet abaixo é uma continuação do exemplo sobre como registrar dados de fonte de atribuição agregados em relatórios agregáveis:

Attribution-Reporting-Aggregate-Trigger-Data:
[
  // Each dictionary independently adds pieces to multiple source keys.
  {
    "key_piece": "10",// Conversion type purchase = 2
    // Combine key piece at offset index 9 with attribution source key piece.
    "key_offset": 9,
    // Apply this suffix to:
    "source_keys": ["campaignCounts"]
  },
  {
    "key_piece": "10101",// Purchase category shirts = 21
    // Combine key piece at offset index 9 with attribution source key piece.
    "key_offset": 7,
    // Apply this suffix to:
    "source_keys": ["geoValue" ]
  }
]

O segundo cabeçalho é usado para registrar uma lista de valores que precisam contribuir com cada chave. A plataforma de tecnologias de publicidade precisa responder com o cabeçalho HTTP Attribution-Reporting-Aggregate-Values.

Cada acionador pode fazer várias contribuições para os relatórios agregáveis. O valor total das contribuições para qualquer fonte de atribuição é vinculado por um parâmetro $ L1 $, que é a soma máxima das contribuições (valores) em todas as chaves agregadas de uma determinada fonte de atribuição. Exceder esses limites faz com que as contribuições futuras diminuam silenciosamente. A proposta inicial é definir $ L1 $ como $ 2^{16} $ (65536). O ruído no serviço de agregação é ajustado proporcionalmente a esse parâmetro. Por isso, é recomendável ajustar corretamente os valores informados a uma determinada chave agregada, com base na parte do orçamento de privacidade de $ L1 $ alocada a essa chave. Essa abordagem ajuda a garantir que os relatórios agregados mantenham a maior fidelidade possível quando o ruído for aplicado. Esse mecanismo é altamente flexível e oferece suporte a diversas estratégias de agregação.

No exemplo abaixo, o orçamento de privacidade é dividido igualmente entre campaignCounts e geoValue, dividindo a contribuição de $ L1 $ para cada um:

Attribution-Reporting-Aggregate-Values:
{
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
    "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
    "geoValue": 1664
}

O exemplo anterior gera estas contagens agregadas:

[
  // campaignCounts:
  {
    // The attribution source key piece "101011001" (offset 0)
    // is concatenated with  "10" (offset 9) trigger key piece to form
    // the final key "10101100110" = 1382.
    "key": "1382",
    "value": 32768
  },
  // geoValue:
  {
    // The attribution source key piece "0000101" (offset 0)
    // is concatenated with  "10101" (offset 7) trigger key piece to form
    // the final key "000010110101" = 181.
    "key": "181",
    "value": "1664"
  }
]

Os fatores de escalonamento podem ser invertidos para alcançar os valores corretos do ruído aplicado:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

Privacidade diferencial

Um dos objetivos dessa API é ter um framework que ofereça suporte à medição agregada de privacidade diferencial. Para isso, adicione ruído proporcional ao orçamento de $ L1 $. Você pode escolher o ruído com esta distribuição:

\[ Laplace(\frac{ε}{L1}) \]

Considerações futuras e perguntas em aberto

A API Attribution Reporting está em fase de desenvolvimento. Também estamos explorando outros possíveis recursos para implementação futura, como modelos de atribuição que não são de último clique e casos de uso de medição entre dispositivos.

Além disso, gostaríamos de receber feedback da comunidade relacionado a algumas questões:

  1. Pretendemos permitir que várias plataformas de tecnologias de publicidade registrem fontes de atribuição e acionadores para permitir a avaliação de métricas por terceiros. Na proposta atual, apenas a plataforma de tecnologias de publicidade que originou as chamadas de API pode especificar uma lista de plataformas de tecnologias de publicidade de terceiros. Para simplificar o modelo da API, poderíamos permitir que plataformas de tecnologias de publicidade executassem redirecionamentos em cadeia, especificando apenas a próxima plataforma.
  2. Para habilitar a avaliação de medições entre apps, em casos em que o acionador pode ser ativado em um app ou na Web, as plataformas de tecnologias de publicidade precisam fornecer o mesmo campo de destino na fonte de atribuição e no registro do acionador. Estamos analisando se é possível usar Web eTLD+1 mesmo que o acionador seja ativado no app.
  3. Para evitar relatórios de acionamento duplicados, caso uma plataforma de tecnologias de publicidade registre o mesmo acionador várias vezes, recomendamos usar uma chave de eliminação de duplicação. Estamos avaliando se os apps podem transmitir essa chave de eliminação de duplicação para todas as plataformas de tecnologias de publicidade, incluindo plataformas de terceiros.