Por que o Amplitude requer consentimento

O Amplitude Browser SDK padrão e os SDKs móveis do Amplitude fazem muito mais do que registar visualizações de páginas. Na inicialização, definem um identificador de dispositivo no armazenamento de primeira parte, geram um identificador de sessão, capturam o referenciador, analisam identificadores UTM e de clique do URL e começam a enfileirar eventos capturados automaticamente: visualizações de página, cliques em elementos, interações com formulários, transferências de ficheiros e — nas versões mais recentes — repetições de sessão. Também enriquecerão esses eventos com geolocalização derivada de IP, dados de dispositivo derivados do agente do utilizador e, se configurado, enriquecimento de terceiros de parceiros de dados.

Cada um desses passos envolve uma base legal de consentimento separada. O armazenamento de um identificador de dispositivo é uma operação de armazenamento e acesso ao abrigo do artigo 5.º, n.º 3, da Diretiva ePrivacy, que exige consentimento prévio, livre, específico, informado e inequívoco no Espaço Económico Europeu, no Reino Unido e em qualquer jurisdição que tenha importado o mesmo padrão. A captura de eventos comportamentais vinculados a esse identificador é o processamento de dados pessoais ao abrigo do GDPR. O enriquecimento com dados de terceiros introduz uma segunda relação de responsável pelo tratamento. O CCPA e o CPRA classificam o mesmo processamento como uma venda ou partilha, a menos que o editor tenha um contrato de prestador de serviços corretamente delimitado com o Amplitude — que está disponível, mas apenas se a integração estiver configurada para desativar funcionalidades de publicidade.

O que o Amplitude recolhe antes do consentimento — e o que deve ser suprimido

O erro de implementação mais comum é tratar o Amplitude como uma ferramenta de análise leve que pode ser executada ao lado do banner de cookies. Não pode. Numa chamada amplitude.init() predefinida, o SDK irá, na primeira renderização da página, escrever pelo menos uma entrada de cookie ou armazenamento local, enviar uma chamada identify e começar a armazenar em buffer eventos. Nada disso é permitido antes de um utilizador ter aceite afirmativamente a categoria de consentimento relevante.

Uma integração conforme deve, portanto, atrasar amplitude.init() até que o CMP tenha sinalizado que a categoria de consentimento de análise foi concedida. O SDK não deve ser carregado de todo a partir de uma tag <script> controlada por consentimento que depende do sinal de finalidade 8 (análise) ou finalidade 1 (armazenamento e acesso) do CMP, dependendo do enquadramento que o CMP expõe. Se o SDK tiver de ser carregado mais cedo — por exemplo, porque está incluído no código da aplicação e não pode ser obtido de forma lazy — a chamada de inicialização deve passar defaultTracking: false e optOut: true para que não sejam emitidos eventos até que o consentimento seja registado, e depois um evento de opt-in diferido deverá inverter esses indicadores.

Os cookies e o armazenamento que o Amplitude escreve

O Browser SDK 2.x escreve por predefinição um único cookie de primeira parte chamado AMP_{apiKey}, com uma validade de um ano, contendo o identificador de dispositivo e os metadados de sessão. Versões mais antigas também escreviam amplitude_id_{apiKey}. Os SDKs móveis persistem o mesmo identificador no armazenamento em sandbox da aplicação. A repetição de sessão adiciona um segundo cookie, AMP_MKTG_{apiKey}, e os parceiros de enriquecimento do Amplitude podem definir cookies de terceiros adicionais se os módulos de segmentação de experimentos ou de audiências estiverem ativados. Todos estes são não essenciais e requerem consentimento.

Mapeamento do Amplitude para enquadramentos de consentimento

O Amplitude não implementa nativamente o Google Consent Mode v2, o IAB TCF nem o IAB Global Privacy Platform. Isso não é um defeito — o Amplitude é uma plataforma de análise de primeira parte, não um fornecedor de tecnologia publicitária — mas significa que a responsabilidade de integração recai sobre o editor. O padrão que funciona na prática é tratar cada módulo do Amplitude como uma porta de consentimento separada e vinculá-lo a um sinal específico que o CMP já expõe.

• Eventos de análise principais vinculam-se à finalidade de análise. Em termos de TCF, isto é mais comummente a finalidade 8 (medir o desempenho de conteúdo) combinada com a finalidade 1 (armazenar e/ou aceder a informações). Para o Google Consent Mode isto mapeia para analytics_storage.
• A repetição de sessão deve estar atrás de um sinal mais rigoroso. A repetição captura o DOM renderizado, incluindo valores de formulários a não ser que estejam explicitamente mascarados, pelo que um opt-in separado de preferences ou functional é adequado, e a repetição deve ter como predefinição desativado, mesmo quando a análise é concedida.
• Audiências, coortes e enriquecimento de terceiros vinculam-se à finalidade de marketing. Em termos de TCF isto é a finalidade 7 (medir o desempenho de anúncios) ou a finalidade 9 (aplicar pesquisa de mercado). Para o Google Consent Mode isto mapeia para ad_storage e ad_user_data.
• Experimentação — O Amplitude Experiment pode ser executado com alocação anónima e efémera sob uma base de interesse legítimo, mas a alocação persistente vinculada a um identificador de utilizador requer o mesmo consentimento que a análise principal.

O padrão de integração que funciona

A implementação de referência que sobrevive à revisão de um regulador tem quatro partes móveis: um CMP que expõe um evento em tempo real quando o utilizador altera o consentimento, um carregador de SDK diferido que apenas obtém o Amplitude depois de esse evento ser acionado para a categoria relevante, um guarda a nível de sessão que respeita o opt-out sem perder o identificador de dispositivo anónimo anterior do utilizador onde a lei o permite, e uma ponte do lado do servidor para eventos que genuinamente requerem recolha independentemente do consentimento — como telemetria de segurança ou deteção de fraude — encaminhados através de um endpoint separado com a sua própria base legal.

Implementação web

Na web, o padrão mais limpo é expor o estado de consentimento do CMP através de um objeto window.__cmp_consent ou da callback __tcfapi padrão, e depois ter um pequeno script de bootstrap a subscrever alterações de consentimento. Quando o consentimento de análise muda de false para true, o bootstrap obtém o SDK do Amplitude a partir do CDN gerido pelo CMP, chama amplitude.init(apiKey, undefined, { defaultTracking: true }), e reproduz quaisquer eventos que estavam em fila de espera na memória enquanto o consentimento estava pendente. Quando o consentimento muda de volta para false, o bootstrap chama amplitude.setOptOut(true), limpa o cookie AMP_ através da expiração de document.cookie, e remove qualquer estado em memória. Criticamente, o bootstrap nunca deve inicializar o Amplitude de forma lazy no mesmo fluxo de pedido que a renderização do banner — o SDK deve aguardar uma concessão explícita.

Implementação móvel

No iOS, o equivalente é manter o framework do Amplitude importado mas diferir Amplitude.instance().initialize(apiKey: apiKey) até que o fluxo de consentimento na aplicação tenha devolvido um sinal de análise positivo. O prompt ATT é uma preocupação separada: o ATT rege o IDFA, enquanto o identificador do Amplitude é o UUID próprio do SDK armazenado na sandbox da aplicação. Ambos requerem consentimento no EEE, mas as bases legais e os prompts são distintos. No Android aplica-se a mesma lógica com Amplitude.getInstance().initializeApolloClient() ou o equivalente dependendo da versão do SDK.

Modo do lado do servidor

O Amplitude suporta ingestão do lado do servidor através da HTTP V2 API. Os eventos do lado do servidor não estão isentos de consentimento — a base legal segue os dados, não o transporte — mas a ingestão do lado do servidor dá ao editor controlo total sobre os campos que são enviados, tornando mais fácil respeitar o consentimento parcial. Um padrão comum é capturar um conjunto mínimo de eventos apenas essenciais do lado do servidor sob interesse legítimo, e apenas enriquecer esses eventos com detalhes comportamentais depois de o utilizador ter concedido consentimento de análise no cliente.

Validar a integração

O passo de validação é aquele que os editores mais frequentemente ignoram e que os reguladores mais frequentemente verificam. Uma implementação do Amplitude corretamente integrada deve passar em quatro verificações. Em primeiro lugar, um browser com o banner de consentimento mostrado mas sem escolha feita deve produzir zero pedidos para api.amplitude.com ou api.eu.amplitude.com e zero cookies AMP_ em document.cookie. Em segundo lugar, recusar a categoria de análise deve manter esse estado — sem eventos, sem cookies, sem entradas de armazenamento local com prefixo AMP_. Em terceiro lugar, aceitar a análise deve produzir um único identify seguido de tráfego de eventos, e o cookie AMP_ deve aparecer com um atributo SameSite consistente com a política do CMP do editor. Em quarto lugar, a retirada do consentimento após o facto deve imediatamente parar outros eventos e limpar os identificadores armazenados — uma limpeza demorada é uma constatação.

O rasto de auditoria é importante separadamente. Ao abrigo das orientações do banner de cookies da EDPB de 2023 e das prioridades renovadas do grupo de trabalho de 2026, os reguladores esperam que o editor seja capaz de provar, para qualquer evento no projeto Amplitude, que o utilizador que o gerou tinha dado consentimento válido no momento da captura. Isso requer que o registo de consentimento do CMP seja consultável por identificador de dispositivo ou identificador de sessão, e que o payload do evento do Amplitude inclua um campo de versão de consentimento que remeta para esse registo. Armazenar a cadeia de consentimento como uma propriedade de utilizador personalizada em cada evento é a forma mais simples de tornar essa ligação auditável.

Escolher a região certa e a residência de dados

O Amplitude opera duas regiões de produção: a EUA (api.amplitude.com) e a UE (api.eu.amplitude.com). Para o tráfego do EEE e do Reino Unido, a região da UE é a predefinição correta — mantém os dados dentro do EEE e reduz a superfície de risco de transferência que a decisão Schrems II e o Quadro de Privacidade de Dados UE-EUA tornaram central para qualquer revisão de análise. A mudança de região não é retroativa: os dados existentes permanecem onde foram inicialmente ingeridos. Para os editores que planeiam um lançamento de CMP, vale portanto a pena confirmar a região antes de escalar, e vale a pena documentar a escolha no aviso de privacidade para que a cadeia de base legal esteja limpa desde a recolha até ao armazenamento. Uma região corretamente escolhida, conjugada com um SDK corretamente controlado e um registo de consentimento consultável, é o que transforma uma implementação do Amplitude de um risco regulatório numa parte defensável da pilha de análise.