Conheça a prévia para desenvolvedores do Sandbox de privacidade do Android. Veja como começar e envie feedback.

API Attribution Reporting: medição entre apps e na Web

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Enviar feedback

Conforme descrito na proposta de design da API Attribution Reporting, a API permite a atribuição dos seguintes caminhos de acionadores 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 navegador e realiza uma conversão nesse navegador ou em outro no mesmo dispositivo.

Aqui, "Web" é definida como o conteúdo da Web mostrado em um app. Esse conteúdo pode ser mostrado no contexto de um app navegador para dispositivos móveis ou como sites incorporados mostrados em apps que não são de navegação.

Os caminhos de acionadores acima se traduzem nos seguintes requisitos:

  • Para plataformas de tecnologia de publicidade: atualizações em chamadas de API e relatórios para ativar os caminhos do app para a Web.
  • Para apps e navegadores: capacidade de transmitir o registro de fontes de atribuição e acionadores da Web para o Android.

Neste documento, explicamos como a API Attribution Reporting é estendida para oferecer suporte a caminhos de acionadores de app para a Web, da Web para app e da Web para a Web. Também descreve as mudanças que os apps e as plataformas de tecnologias de publicidade precisam fazer para atender aos requisitos de suporte para esses caminhos de acionadores.

Mudanças nas plataformas de tecnologias de publicidade

Registro das tecnologias de publicidade

As plataformas de tecnologias de publicidade vão precisar se registrar para usar a API Attribution Reporting. Os detalhes do processo de registro ainda estão em desenvolvimento, e seu feedback é muito importante.

Depois que o processo for finalizado, a API vai descartar o registro se uma chamada não registrada for recebida.

As plataformas de tecnologias de publicidade precisam garantir que estejam registrando todos os URLs de servidor que elas podem usar no app e na Web para registrar acionadores e fontes de atribuição. Há suporte a vários URLs de registro de servidor, mas para apenas uma origem de relatório. Essa origem é derivada do domínio de um dos URLs de registro de servidor.

Mudanças no registro e na atribuição

Ao registrar uma fonte de atribuição, as plataformas de tecnologias de publicidade especificam um campo de destino, que é o nome do pacote do app em que ocorre o evento acionador. Para ativar a medição de app para a Web, planejamos oferecer suporte a um campo de destino do app (nome do pacote do app) e a um campo de destino da Web (eTLD+1).

Ao registrar fontes ou acionadores de atribuição da Web, a API não oferece suporte para redirecionamentos, porque cada app que hospeda conteúdo da Web pode ter o próprio modelo de permissões. Cada app é responsável por seguir os redirecionamentos, se houver suporte, e chamar as APIs de contexto da Web para cada salto de redirecionamento.

Além disso, essa integração permite que as plataformas de tecnologias de publicidade usem a lógica de atribuição específica do app em fontes de atribuição da Web. Por exemplo, agora você pode especificar janelas de atribuição pós-instalação em uma fonte de atribuição da Web.

Como receber relatórios de apps e da Web

A API Attribution Reporting do Android pode enviar relatórios para conversões na Web e de app. Se as plataformas de tecnologias de publicidade não quiserem alinhar os dados do acionador e as chaves-valor de agregação nas superfícies do app e da Web, elas vão poder distinguir entre uma conversão na Web e de app:

  • Para relatórios no nível do evento, vamos aceitar um campo de destino que especifica se o acionador foi ativado na Web (o destino é um eTLD+1) ou no app (o destino é o nome de um pacote de app).
  • Para relatórios agregáveis, o destino vai ser enviado em texto não criptografado.

Implicações de medição da Web para a Web

Os apps escolhem quando transmitir o registro para a API Attribution Reporting. Há vários pontos a se considerar aqui:

  • A API Attribution Reporting está disponível no dispositivo? Vamos mostrar um novo indicador para os apps, que informa se a API Attribution Reporting está ou não disponível no dispositivo. Consulte a seção de mudanças para apps e veja mais detalhes sobre como os aplicativos podem transmitir o registro para a API Attribution Reporting.
  • Que parte dos acionadores e das fontes de atribuição precisa ser transmitida para a API? Essa decisão vai ser tomada por cada app ou pela plataforma de tecnologias de publicidade se o app permitir. Caso o app tenha a própria solução de métricas, o uso dela pode ser recomendado. Em última análise, transmitir todos os registros de acionador e fonte para a API Attribution Reporting do Android, quando disponível, permite a atribuição mais precisa em apps e na Web.

O exemplo a seguir mostra como os apps de navegador funcionam com a API Attribution Reporting para fornecer uma medição precisa quando o usuário clica em um anúncio em um app navegador e um que não é de navegação:

Exemplos de conversões e cliques do usuário em um período de três dias
Figura 1. Exemplo de registro de acionador e fonte em um navegador e um app.
  • No primeiro dia, o usuário clica em um anúncio no app navegador.
    • Esse app pode usar a própria solução de métricas ou transmitir o registro do clique no anúncio da Web para a API Attribution Reporting.
  • No segundo dia, o usuário clica em um anúncio em um app que não é de navegação.
    • O clique é registrado como uma fonte de atribuição com a API. O app navegador não tem visibilidade desse clique, porque o evento ocorreu em outro aplicativo.
  • No terceiro dia, o usuário faz a conversão no app navegador.
    • Se o app navegador registrar o clique e a conversão usando a própria solução de métricas e transmitir as informações para a API Attribution Reporting, é improvável que uma plataforma de tecnologias de publicidade consiga eliminar a duplicação dos relatórios de conversão nas soluções de métricas. Além disso, uma plataforma de tecnologias de publicidade pode consumir os limites de taxa do app navegador e da API Attribution Reporting. Por isso, recomendamos que os apps transmitam todos os eventos e conversões de anúncio que vão ser registrados na API, quando ela estiver disponível.

Mudanças para apps

Vamos oferecer suporte à atribuição entre as superfícies do app e da Web permitindo que os apps transmitam o registro de fontes de atribuição e acionadores da Web à API Attribution Reporting do Android usando um novo conjunto de chamadas da API de contexto da Web.

Depois de concluir as etapas de registro nas seções a seguir, os acionadores e as fontes de atribuição de apps e da Web são armazenados no dispositivo, e a API Attribution Reporting pode executar a atribuição de último toque priorizada pela fonte nas superfícies do app e da Web.

Registro de fonte de atribuição

Ao registrar uma fonte de atribuição, os apps podem chamar o método registerWebSource(), que precisa dos seguintes parâmetros:

  • URIs de fonte de atribuição: a plataforma emite uma solicitação para cada URI nesta lista de modo a buscar os metadados associados à fonte de atribuição.

    Cada URI precisa acompanhar uma sinalização Debug booleana para indicar se as chaves de depuração fornecidas pelas plataformas de tecnologias de publicidade precisam ou não ser incluídas no relatório.

  • Evento de entrada: um objeto InputEvent (para um evento de clique) ou null (para um evento de visualização).

  • Origem da fonte: origem em que a fonte ocorreu (site do editor).

  • Destino do SO: nome de um pacote de app em que ocorre o evento acionador.

  • Destino da Web: um eTLD+1 em que o evento acionador acontece.

  • Destino verificado: URI/intent de destino da Web ou do SO que foi usado para navegação após o clique do usuário.

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 cabeçalho HTTP Attribution-Reporting-Register-Source. Esse cabeçalho usa os mesmos campos do registro de fonte de atribuição de app a app, com algumas mudanças:

  • A API valida os destinos especificados pela plataforma de tecnologias de publicidade com os definidos pelo app. Se os destinos forem diferentes, a API vai descartar o registro da fonte de atribuição.

    O esperado é que os apps validem destinos da Web antes de chamar a API de contexto da Web. No caso dos cliques, os apps precisam verificar se o destino especificado corresponde àquele para o qual o usuário está navegando.

  • A API ignora todos os URIs de redirecionamento fornecidos em Attribution-Reporting-Redirects. Os apps precisam seguir redirecionamentos por conta própria e chamar o registerWebSource() para cada um deles, de modo que possam aplicar as próprias políticas de permissões conforme necessário.

Registro do acionador (conversão)

No registro do acionador, os apps podem chamar o registerWebTrigger(), que precisa dos seguintes parâmetros:

  • URIs de acionador: a plataforma emite uma solicitação para cada URI nesta lista de modo a buscar os metadados associados ao acionador.
  • Origem do destino: a origem em que o acionador foi ativado (site do anunciante).

Considerações sobre privacidade e segurança

Impacto nos mecanismos de preservação da privacidade aplicados aos relatórios

Conforme descrito na proposta de design principal, a API aplica limites de taxa de preservação da privacidade aos relatórios. Alguns limites são particionados entre apps de fonte e destino. Quando uma fonte ou um acionador de atribuição da Web é registrado, o limite de taxa é particionado pelo site de fonte ou destino em vez do app.

Caso o aplicativo mantivesse limites de taxa separados, um adversário poderia consumir os limites de taxa específicos do app, além dos limites de taxa da API. Para atenuar isso, os apps precisam garantir que uma determinada fonte de atribuição não esteja registrada na solução de métricas do app e na API Attribution Reporting do Android.

Como estabelecer a confiança no contexto da Web

Nas chamadas de API de contexto da Web, a API confia no app para detectar e especificar as origens de fonte e destino. Isso pode levar a possíveis considerações de privacidade e segurança:

  • Um adversário pode afirmar que hospeda sites próprios para tentar burlar limites de taxa em torno da quantidade de informações que qualquer fonte pode transferir.
  • Vários adversários podem colaborar para registrar fontes de atribuição diferentes, reivindicando o mesmo site de fonte. Isso pode fazer com que o site de fonte alcance os limites de taxa da plataforma de tecnologias de publicidade e pode impedir que o site real registre fontes de atribuição legítimas.

Estamos considerando possibilidades de mitigação para essas situações. Uma opção seria limitar a chamada de registerWebSource() a navegadores ou apps que atestem que o site de fonte usado no registro representa o site real que está sendo mostrado ao usuário. Também estamos analisando soluções técnicas para validar conteúdo da Web. Pedimos que você dê um feedback sobre os casos de uso e quais tipos de apps precisam chamar o registerWebSource().

Qualquer app pode chamar o registerWebTrigger(), porque as considerações de privacidade e segurança no lado do acionador não são aplicáveis sem a colusão do lado da fonte.

Controles de usuário

Os apps podem manter o suporte para as políticas de controles ou permissões do usuário, desde que a definição possa ser feita no momento do registro. Por exemplo, se os apps autorizarem permissões no nível do site ou do usuário, eles vão precisar avaliar essas permissões e determinar se as APIs de contexto da Web devem ser chamadas.

Além disso, vamos oferecer suporte para uma nova chamada de API por apps para excluir qualquer fonte de atribuição, acionadores e relatórios pendentes armazenados para esse app no dispositivo. Por exemplo, se o app permite que o usuário limpe o histórico de navegação, ele pode chamar a API para excluir as fontes de atribuição, os acionadores e os relatórios pendentes armazenados para esse app no dispositivo.

Considerações futuras e perguntas em aberto

A interoperabilidade do app para a Web da API Attribution Reporting está fase de desenvolvimento. Gostaríamos de receber feedback da comunidade quanto a algumas ideias:

  1. Em um dispositivo com suporte para o Sandbox de privacidade do Android, como você vai usar as solução de métricas do navegador com a API Attribution Reporting do Android? Você prefere transmitir tudo para o Android?
  2. Os limites de taxa propostos são razoáveis para tráfego de apps e da Web?
  3. Há alguma preocupação sobre o possível recebimento de dois pings para cada fonte e acionador de atribuição, um do navegador/app e outro da API Attribution Reporting?
  4. Você quer fornecer um endpoint de servidor diferente para os registros da API do Android, em vez de registros da API do navegador/app?
  5. Como podemos facilitar a depuração em diferentes APIs?
  6. No momento, a proposta não inclui a validação de que destinos da Web e de apps são afiliados. No futuro, vamos poder validar esses destinos verificando as associações com os Digital Asset Links. Isso bloquearia algum dos seus casos de uso? Faz sentido usar Digital Asset Links para essa validação?
  7. Para navegadores/apps, entre em contato se quiser registrar impressões da Web ou qualquer outra integração com a API Attribution Reporting do Sandbox de privacidade do Android.