Gerenciamento de consentimento com o SDK da Singular: um framework de decisão

Seguir
Avatar
Jared Ornstead
Updated

Gerenciamento de consentimento com o SDK da Singular: um framework de decisão

Este artigo descreve os controles de privacidade que a Singular oferece e os padrões de implementação que observamos em nossa base de clientes, e apresenta um framework para combiná-los em uma arquitetura de consentimento. Cada controle é documentado em seu próprio artigo; esta página explica como eles funcionam em conjunto.

Antes de começar: Suas equipes jurídica e de privacidade controlam seu fluxo de consentimento e são responsáveis por decidir qual postura se aplica ao seu app em cada jurisdição. Este artigo descreve apenas o comportamento do produto e não constitui aconselhamento jurídico.

As duas decisões às quais todo fluxo de consentimento se reduz

Os controles de privacidade da Singular se organizam em torno de duas decisões independentes. Mantê-las separadas permite que um único aviso de consentimento conduza uma implementação em conformidade.

Decisão 1: Rastreamento. A Singular vê este usuário? Isso é controlado por se e quando você inicializa o SDK. A inicialização envia a primeira sessão, cria o registro de instalação e aciona o processamento de atribuição. Se o SDK nunca for inicializado, a Singular não recebe nada do dispositivo. Este é o controle mais restritivo disponível.

Decisão 2: Compartilhamento. Dado que a Singular vê o usuário, os dados dele podem ser compartilhados com os parceiros de publicidade? Isso é controlado pelo flag Limit Data Sharing (LDS). O LDS permite manter a análise primária (sessões, retenção, eventos, seus relatórios) enquanto restringe o que flui para os parceiros nos postbacks. Consulte o Limit Data Sharing FAQ para a semântica e o comportamento dos parceiros.

Se o seu framework de consentimento distingue o consentimento de medição do consentimento de publicidade ou retargeting (comum na EEA), o mapeamento é direto: o consentimento de medição condiciona a inicialização e o consentimento de publicidade define o LDS. Um único aviso, resolvido uma vez, aciona as duas alavancas.

Inventário de controles, do menos ao mais restritivo

Controle O que faz O que não faz
limitDataSharing (config ou em tempo de execução) Marca a preferência de compartilhamento do usuário; o comportamento dos postbacks dos parceiros segue a sua configuração por parceiro. Não impede que a Singular rastreie; não altera os postbacks a menos que restrições em nível de parceiro sejam configuradas.
Modo de identificadores limitados O SDK não coleta IDFA nem GAID; usa IDFV ou ASID em vez disso. Não interrompe o rastreamento nem o compartilhamento de identificadores não publicitários.
stopAllTracking() Interrompe toda a transmissão de forma imediata e persistente até que resumeAllTracking() seja chamado. Não desfaz a instalação nem os eventos já enviados; a inicialização já acionou a atribuição.
Nunca inicializar A Singular não recebe nem processa nada do dispositivo. Os deferred deep links e a atribuição não estão disponíveis para esses usuários.
trackingOptIn() Legado: registra apenas um evento de notificação de consentimento. Não tem efeito funcional sobre o rastreamento ou o tratamento de dados; não construa a lógica de consentimento sobre ele.

Três modelos de fluxo de consentimento

  • Desativação por padrão (inicializar primeiro): O SDK é inicializado ao abrir o app; o consentimento é apresentado durante o onboarding; uma recusa aciona stopAllTracking() ou define o LDS como true. Isso oferece fidelidade total de atribuição e postbacks rápidos para as SANs. O momento da instalação é capturado antes de o usuário responder, portanto este modelo exige uma postura legal que permita a coleta antes de uma escolha afirmativa. Comum para audiências dos EUA.
  • Ativação por padrão (consentimento primeiro): O SDK não é inicializado até que o usuário consinta afirmativamente. Nada é transmitido para usuários que não consentem. Padrão para audiências do GDPR. Persista a decisão e inicialize imediatamente nas execuções seguintes em todos os pontos de entrada do app.
  • Híbrido (inicializar imediatamente, resolver o LDS na inicialização): Resolva a tela de consentimento ao abrir o app e, em seguida, inicialize com limitDataSharing já definido no objeto de configuração. Cada registro, da instalação em diante, carrega o estado declarado pelo usuário, sem nenhuma janela em que a intenção exista mas não tenha sido aplicada. Este é o padrão que recomendamos aos clientes sensíveis à privacidade que podem exibir o consentimento na abertura.

A maioria dos apps multirregião executa mais de um modelo, selecionado em tempo de execução por jurisdição ou pelo CMP.

Consequências de tempo a planejar

  • A inicialização adiada não custa a instalação se ocorrer dentro da mesma sessão do app: o install referrer do Android persiste no dispositivo e a solicitação de atribuição é concluída normalmente.
  • As taxas de correspondência das SANs degradam quando a inicialização é atrasada por muito tempo (fluxos de consentimento de várias etapas, intervalos de vários dias). Mantenha as telas do primeiro início em uma única tela rápida.
  • Os postbacks do SKAdNetwork são gerados pelo sistema operacional no momento da instalação e não são afetados pelo momento da inicialização do SDK.
  • Os deferred deep links exigem que a inicialização e a atribuição sejam resolvidas. Em um modelo estrito de ativação, o deferred deep linking só está disponível para usuários que consentiram.
  • Não há callback de conclusão da inicialização. Se você criar um sequenciamento de eventos personalizado, capture o estado de consentimento no momento da inicialização.
  • O registro de instalação fixa o valor de LDS vigente na inicialização. As atualizações posteriores se aplicam apenas aos eventos seguintes, e os postbacks já enviados não são revogados. Não defina o LDS como true por padrão para usuários indecisos, a menos que a sua postura legal exija; resolva o consentimento primeiro ou deixe o LDS sem definição (unset) até o usuário responder.

Armadilhas comuns

  • Um LDS sem definição é tratado como não limitado. Uma integração que pretende restringir um usuário mas ainda não definiu o flag é, da perspectiva da Singular, um usuário sem restrições.
  • O LDS true não muda nada por si só. O comportamento dos postbacks para usuários com LDS é definido por parceiro e por app na sua configuração de parceiros (não enviar / enviar sem PII / enviar normalmente). Defina o flag e configure a aplicação.
  • O ATT não é um framework de consentimento. O ATT rege apenas a divulgação do IDFA. Se uma recusa de ATT também deve implicar LDS true é uma decisão de política da sua equipe de privacidade.
  • O apagamento do GDPR não é uma exclusão. A API do OpenDSR exclui os dados coletados; não impede que o SDK envie eventos futuros. Combine o apagamento com stopAllTracking() no mesmo fluxo de usuário.

Artigos relacionados