Atribuição Móvel Sem GAID: Atribua Instalações Sem Identificadores de Publicidade

Como lidar com a atribuição de aplicativos móveis sem acesso ao identificador de publicidade? É possível atribuir instalações de aplicativos sem GAID ou IDFA, mas a arquitetura subjacente muda: em vez de depender de um identificador de publicidade persistente, os fluxos modernos combinam frameworks de atribuição mediados pela plataforma, o Google Play Install Referrer, o roteamento de parâmetros contextuais primários e a validação do lado do servidor.

Um Identificador de Publicidade é um identificador de software reajustável fornecido pela plataforma móvel para fins de publicidade e medição. No Android, este é o Identificador de Publicidade fornecido pelos serviços do Google Play; nas plataformas da Apple, o acesso ao IDFA é regido pelo framework App Tracking Transparency.

Resumo: Atribuição Móvel Sem Identificadores

O Google Advertising ID não é substituído por um único identificador direto. Em vez disso, a atribuição é dividida em primitivas distintas e dedicadas:

• Relatório de Campanhas de Anúncios Pagos (Android): Use a API Google Play Install Referrer para recuperação de parâmetros de campanha mediados pela loja em instalações distribuídas pelo Google Play.

• Relatório de Campanhas de Anúncios Pagos (iOS): Use o Apple AdAttributionKit e o SKAdNetwork para postbacks assinados pela plataforma que preservam a privacidade.

• Integração Web-to-App e Indicações: Use uma camada de restauração de contexto de instalação primária (como OpoInstall) para recuperar códigos promocionais, IDs de salas e tokens de quem indicou no primeiro acesso.

• Retargeting Entre Aplicativos: Requer um identificador ou mecanismo de medição autorizado e suportado pela plataforma, além de conformidade com as políticas aplicáveis da plataforma, controles de usuário e requisitos de consentimento.

Matriz de Decisão de Arquitetura: Escolhendo a Primitiva de Atribuição Correta

Para determinar o mecanismo técnico adequado para sua aplicação, avalie seus requisitos operacionais específicos em relação aos recursos da plataforma:

Substituição do GAID: O Que Realmente Funciona

Quando as equipes de engenharia buscam uma “substituição para o GAID”, elas geralmente estão tentando resolver vários problemas operacionais desconectados com uma única ferramenta. Em produção, as arquiteturas dependentes de GAID devem ser desconstruídas em quatro soluções independentes:

                        Fluxos Legados de GAID
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     │                           │                           │
     ▼                           ▼                           ▼
ROI de Campanha Paga        Roteamento Web-to-App       Vínculo de Indicação
     │                           │                           │
     ▼                           ▼                           ▼
Play Install Referrer /     Contexto Primário           Restauração de Token
AdAttributionKit            Roteamento de Parâmetros    de Indicação Primária

• Substituição da Recuperação de Contexto de Instalação Baseada em GAID: Use o Google Play Install Referrer quando aplicável para instalações distribuídas pelo Google Play, juntamente com integrações de redes de anúncios e APIs de atribuição suportadas pela plataforma. Esses frameworks fornecem contexto de origem da instalação sem expor identificadores persistentes de hardware ou de publicidade.

• Substituição do GAID para Integração e Deep Linking: Implante uma camada de restauração de contexto de instalação primária (como OpoInstall). Em vez de consultar um ID de anúncio para cruzar registros de cliques, passe parâmetros dinâmicos por URLs de campanha próprias e restaure-os na primeira inicialização do aplicativo por meio do SDK do cliente.

• Substituição do GAID para Identidade de Usuário: Use sistemas de contas primárias autenticadas (como OAuth ou UUIDs de usuário internos) em vez de chaves de publicidade em nível de dispositivo.

Taxonomia Arquitetural Principal: O Que as Diferentes Primitivas Fornecem

GAID vs Install Referrer vs Restauração de Parâmetros Primários

Alternativas ao GAID para Atribuição de Aplicativos Android

Ao operar em dispositivos Android sem acesso ao Google Advertising ID, as equipes de engenharia implantam mecanismos alternativos adaptados a canais de campanha específicos:

Como as Plataformas de Atribuição Móvel e MMPs Lidam com a Medição Sem GAID

Os Mobile Measurement Partners (MMPs), como AppsFlyer, Adjust, Singular e Branch, ajustaram suas arquiteturas técnicas para dar suporte à medição quando os identificadores de publicidade estão ausentes:

Ao parear um MMP para relatórios de redes de anúncios em macro escala com uma camada de roteamento contextual primário para personalização de micro integração, as equipes de engenharia podem estabelecer uma pilha complementar de medição e integração sem violar os sandboxes de privacidade do sistema operacional.

Por Que as Restrições ao Identificador de Publicidade Interferem na Atribuição Móvel Determinística

A Dependência Histórica de Identificadores de Publicidade Persistentes

Durante mais de uma década, a publicidade de desempenho móvel dependeu de correspondências determinísticas em nível de dispositivo alimentadas por identificadores de publicidade da plataforma: o Google Advertising ID (GAID) no Android e o Identificador para Anunciantes (IDFA) no iOS. Nesse fluxo de trabalho tradicional, as redes de anúncios capturavam o identificador de publicidade do usuário no momento da impressão ou clique no anúncio. Quando o aplicativo era subsequentemente instalado e aberto, o SDK de atribuição integrado consultava o sistema operacional do dispositivo para recuperar o identificador de publicidade correspondente.

Uma busca de igualdade simples no lado do servidor ($GAID*{\\text{click}} == GAID*{\\text{install}}$) estabelecia um vínculo inequívoco entre o investimento em marketing e a instalação do aplicativo. Esse mecanismo permitia a atribuição determinística entre várias redes, o perfilamento entre editores e o retargeting automatizado sem exigir estado de sessão em tempo real ou transporte de parâmetros contextuais.

O Mecanismo de Zeragem de Identificadores e Restrições de Plataforma

As arquiteturas de sistemas operacionais móveis evoluíram para restringir o rastreamento de dispositivos entre aplicativos sem o consentimento explícito do usuário.

Nas plataformas da Apple, as diretrizes do Apple App Tracking Transparency exigem que os aplicativos solicitem autorização de rastreamento por meio de ATTrackingManager.requestTrackingAuthorization. Quando a autorização está ausente, o sistema operacional oculta o IDFA. Os aplicativos devem tratar os estados denied (negado), restricted (restrito) e notDetermined (não determinado) adequadamente, sem assumir que um identificador de publicidade esteja acessível.

No Android, de acordo com a documentação de alterações de comportamento do Android 13, o Google introduziu controles de permissão explícitos nos serviços do Google Play. Para aplicativos voltados para o Android 13 (nível de API 33) ou superior, os desenvolvedores devem declarar a permissão com.google.android.gms.permission.AD_ID em seu manifesto para acessar o Identificador de Publicidade. Quando essa permissão é omitida, ou quando um usuário limita o rastreamento de anúncios ou exclui seu Identificador de Publicidade, os serviços do Google Play podem retornar um identificador zerado (00000000-0000-0000-0000-000000000000) ou indicar que o identificador está indisponível, dependendo do estado do dispositivo e do comportamento dos serviços do Google Play.

A Falha dos Pipelines de Atribuição de Anúncios Determinísticos

Quando o identificador de publicidade está indisponível ou zerado, um pipeline de atribuição que depende da igualdade de identificadores não consegue mais realizar correspondências confiáveis em nível de usuário. Um identificador de publicidade zerado ou indisponível não pode fornecer uma chave exclusiva para distinguir jornadas de conversão individuais.

Para manter a medição de campanhas e o rastreamento de conversões, as equipes de engenharia devem se afastar das dependências de IDs de publicidade. As arquiteturas modernas desacoplam a atribuição de instalações de identificadores de dispositivos persistentes, contando com roteamento contextual primário e frameworks de medição fornecidos pela plataforma.

Nessa arquitetura, o OpoInstall é apresentado como uma camada primária de restauração de contexto de instalação / deep linking diferido, e não como um substituto universal para o Google Play Install Referrer, AdAttributionKit, SKAdNetwork ou outros sistemas de atribuição de publicidade mediados por plataformas.

Como as Permissões de ID de Publicidade do Android e o ATT da Apple Afetam a Atribuição

Políticas de Permissão AD_ID do Google Play no Android 13 e Superior

O Google Play impõe uma governança de política granular sobre a extração de identificadores de publicidade:

• Requisito de Declaração no Manifesto: Aplicativos voltados para o Android 13 (nível de API 33) ou superior devem declarar <uses-permission android:name="com.google.android.gms.permission.AD_ID"/> em seu manifesto. Se omitido, as chamadas para AdvertisingIdClient.getAdvertisingIdInfo(context) retornam zeros ou indicam um estado indisponível.

• Controles de Privacidade do Usuário: Quando um usuário limita o rastreamento de anúncios ou exclui seu Identificador de Publicidade, os serviços do Google Play retornam zeros ou um estado indisponível. As políticas de desenvolvedor do Google Play proíbem explicitamente a conexão ou reconstrução do Identificador de Publicidade redefinido usando outros identificadores de dispositivo persistentes.

• Exclusões de Política para Aplicativos Sensíveis: As políticas do Google Play proíbem a declaração da permissão AD_ID em aplicativos voltados para crianças ou sujeitos a restrições de políticas familiares, exigindo que os desenvolvedores adotem fluxos de medição sem IDs.

Framework Apple AppTrackingTransparency e Estados de Autorização

No iOS, o acesso a identificadores é regido pelo estado de sistema ATTrackingManager.AuthorizationStatus:

• notDetermined (0): O usuário ainda não respondeu à solicitação de autorização do ATT. O aplicativo não deve assumir que o acesso ao IDFA está disponível.

• restricted (1): O dispositivo está restrito por controles parentais ou perfis de gerenciamento de dispositivos; o rastreamento está desativado em todo o sistema.

• denied (2): O usuário selecionou explicitamente “Pedir ao Aplicativo para não Rastrear” no aviso ou desativou as solicitações de rastreamento globalmente nas configurações de privacidade do iOS. O aplicativo não deve depender do IDFA.

• authorized (3): O usuário concedeu permissão explicitamente para rastrear em aplicativos e sites de terceiros, permitindo o acesso ao IDFA sujeito às políticas da plataforma Apple.

Declaração de Limite Arquitetural Importante

Distinção importante: Remover o GAID ou o IDFA de uma arquitetura de atribuição não torna automaticamente todas as técnicas de rastreamento alternativas seguras em termos de privacidade ou compatíveis com políticas. De acordo com as diretrizes do framework App Tracking Transparency da Apple, a Apple define rastreamento como o vínculo de dados de usuários ou dispositivos coletados em seu aplicativo com dados de terceiros para publicidade direcionada ou medição, ou o compartilhamento de dados com um corretor de dados. Se um pipeline de engenharia coleta características de dispositivos para reconstruir uma identidade persistente entre aplicativos, ele permanece sujeito às políticas de rastreamento da plataforma, independentemente de um Identificador de Publicidade ter sido acessado. O roteamento de parâmetros primários deve permanecer restrito ao contexto imediato de integração e conversão da jornada iniciada pelo usuário.

O Que a Atribuição Sem IDs Não Significa

Atribuição sem IDs não significa análises sem identificadores. Os aplicativos ainda podem processar identificadores de contas, tokens de sessão primários ou parâmetros de deep linking necessários para a funcionalidade interna do produto. O objetivo arquitetônico é eliminar a dependência de identificadores de publicidade persistentes entre aplicativos para a correspondência de instalações, em vez de afirmar que todos os dados de atribuição são totalmente anônimos.

Três Problemas de Atribuição Que Não Devem Ser Confundidos

Ao projetar a atribuição móvel sem identificadores de publicidade, as equipes de engenharia devem diferenciar três objetivos operacionais distintos:

Um mecanismo de roteamento primário pode resolver o deep linking diferido e a atribuição de indicação sem exigir GAID ou IDFA, mas não deve ser apresentado como um substituto universal para a atribuição de publicidade mediada pela plataforma.

Quando as Equipes de Crescimento Devem Implantar uma Camada de Atribuição Primária?

A implantação de uma camada de atribuição primária independente é recomendada para aplicativos que operam fluxos de produtos específicos:

• Aplicativos de SaaS e Assinatura: Plataformas B2B onde o tráfego de marketing começa na web desktop ou móvel e se converte em contas de aplicativos nativos que exigem restauração de sessão pré-autenticada.

• Aplicativos de Jogos: Jogos multiplayer ou sociais onde novos jogadores devem entrar automaticamente na partida, guilda ou sala de quem os convidou no primeiro acesso, sem códigos de sala manuais.

• Plataformas de E-commerce: Aplicativos de compras que oferecem descontos de boas-vindas personalizados ou restauram estados ativos de carrinhos de compras de campanhas da web móvel diretamente para as visualizações de checkout nativas.

• Plataformas de Indicação e Fidelidade: Produtos que impulsionam ciclos virais orgânicos que exigem o vínculo confiável de tokens entre quem indicou e quem foi convidado, sem forçar os usuários a copiar e colar strings de cupons.

Blueprint Arquitetural para Roteamento de Parâmetros Primários Sem IDs

Desacoplando a Atribuição de Identificadores de Dispositivos Persistentes

Neste artigo, usamos o roteamento de parâmetros contextuais (também conhecido como atribuição diferida primária ou restauração de contexto de instalação) para descrever a transmissão primária de contexto de campanha ou indicação por meio de uma jornada web-to-app iniciada pelo usuário.

As arquiteturas de atribuição modernas concentram-se no contexto transacional do engajamento de marketing, em vez de tentar rastrear o dispositivo físico. Quando um potencial usuário clica em um link de campanha, a interação recebe um payload de roteamento transitório contendo metadados de campanha, tokens de canal e parâmetros de roteamento de aplicativos.

Esse payload viaja através do funil de conversão juntamente com a jornada do usuário, permitindo que o aplicativo móvel restaure a intenção contextual na inicialização sem consultar IDs de publicidade em nível de sistema.

Uma Arquitetura de Atribuição de Duas Camadas

Uma arquitetura de atribuição corporativa separa o deep linking direto dos fluxos de instalação mediados pela loja:

                Interação de Marketing do Usuário
                          │
         ┌────────────────┴────────────────┐
         │                                       │
   Link de App Direto                     Fluxo de Loja / Anúncio
         │                                       │
 Links Universais /               ┌──────┴───────┐
    App Links                     │                           │
         │                     Android                       Apple
         │                   Play Install                   Atribuição
         │                      Referrer                    de Anúncios
         │                            │                              │
         └──────────────┬────────┴──────┬───────┘
                                       │                              │
                                         Sinais de Atribuição / Roteamento
                                                        │
                                            Validação no Lado do Servidor
                                                        │
                                    ┌─────────┴─────────┐
                                    │                                      │
                              Contexto Encontrado                     Sem Sinal
                                   │                                      │
                             Rotear / Vincular                        Orgânico /
                             Primário                             Fallback Gracioso

Mecânicas Técnicas do Roteamento de Parâmetros Contextuais e Fallbacks

O Papel do Transporte de Parâmetros Primários

O transporte de parâmetros primários depende da análise padrão de consultas da web e do cache de sessão seguro no lado do servidor. Os desenvolvedores podem consultar a documentação do SDK do OpoInstall para obter especificações técnicas sobre modelos de vinculação de parâmetros.

O roteamento de parâmetros primários usado exclusivamente para integração direta não requer necessariamente o ATT quando a implementação não atende à definição de rastreamento da Apple; as equipes devem avaliar o fluxo de dados real e a finalidade em relação às políticas atuais da Apple.

Fallbacks de Atribuição de Instalação Específicos da Plataforma

Quando deep links diretos são interrompidos pela instalação na loja, as primitivas específicas da plataforma fornecem dados de atribuição estruturados:

• Android (Google Play Install Referrer): O guia da API Google Play Install Referrer expõe informações de referência associadas à instalação na Play Store e fornece carimbos de data/hora de clique e instalação. A documentação da API especifica uma janela de disponibilidade de 90 dias para dados de referência. Os aplicativos devem persistir e processar esse valor de acordo com suas próprias regras de atribuição e tratamento de reinstalação, em vez de tratá-lo como um identificador de instalação permanente. Observe que os parâmetros devem ser passados explicitamente pelo Google Play; parâmetros de consulta arbitrários de páginas de destino não preenchem automaticamente esta API.

• Atribuição na Plataforma Apple: A pilha moderna de atribuição de aplicativos da Apple inclui o framework Apple AdAttributionKit, juntamente com a interoperabilidade com o SKAdNetwork para fluxos de trabalho de publicidade suportados. O AdAttributionKit em si não exige um aviso de autorização do ATT; no entanto, outros fluxos de dados no mesmo aplicativo ainda podem constituir rastreamento e, portanto, exigir a autorização do ATT. O AdAttributionKit opera dentro do framework de anúncios assinados da Apple com redes de publicidade elegíveis registradas nos frameworks de atribuição da Apple.

Por Que a Atribuição Baseada em Área de Transferência Não Deve Ser a Principal Estratégia

A transferência por área de transferência ou colar deve geralmente ser tratada como um mecanismo de fallback excepcional, e não como um design de atribuição principal. O acesso à área de transferência introduz notificações de privacidade visíveis ao usuário, restrições de plataforma e disponibilidade inconsistente entre as versões do sistema operacional. Ao avaliar o armazenamento na área de transferência:

• Escopo Explícito: Os payloads devem ter curta duração e ser limitados aos dados mínimos específicos do aplicativo exigidos para o fluxo primário pretendido. Valores confidenciais devem ser protegidos adequadamente em trânsito e em repouso.

• Limpeza Imediata: Os aplicativos devem limpar ou substituir prontamente os tokens de parâmetros temporários assim que forem consumidos durante a sequência inicial de inicialização.

• Conformidade com Políticas: Use mecanismos de área de transferência apenas onde houver um fluxo de usuário primário claramente definido e após a revisão da política de plataforma aplicável.

Fallback Gracioso e Estados Sem Atribuição

Uma arquitetura de privacidade resiliente não tenta forçar correspondências de atribuição por meio de impressões digitais de dispositivos invasivas:

• Link de App Direto / Link Universal: Ativação instantânea do aplicativo nativo quando o aplicativo já está instalado no dispositivo.

• Passagem de Parâmetros Mediada pela Loja: Recuperação de parâmetros de campanha por meio de APIs da plataforma (como o Google Play Install Referrer) quando disponíveis.

• Restauração de Parâmetros Primários: Correspondência de novas sessões de instalação com interações ativas em páginas de destino da web dentro de uma janela de tempo estreita.

• Sem Sinal (Sem Atribuição): Quando as condições de rede mudam, as sessões expiram ou não existe contexto correspondente, o aplicativo decai com segurança para um estado padrão limpo sem interromper a experiência de integração do usuário.

Exemplo de Cenário de Implementação: Restauração de Contexto com OpoInstall

Para entender como essas primitivas operam em produção, considere um aplicativo de jogos móveis multiplataforma que executa dois canais de aquisição simultâneos:

• Canal A (Anúncios Programáticos Pagos): Uma campanha de anúncios executada em redes de anúncios externas redirecionando para a App Store e o Google Play.

• Canal B (Compartilhamento Viral de Usuários): Jogadores existentes compartilhando links de convite personalizados (https://game.example.com/join?room=9876&inviter=usr_432) por meio de aplicativos de mensagens sociais.

*   

[Canal A: Anúncio Pago] ──> [Download na Loja] ──> [Play Referrer / AdAttributionKit] ──> [ROI de Anúncio Agregado]
[Canal B: Convite]     ──> [Landing Page Web] ──> [Restauração de Token Primário]        ──> [Entrada Automática na Sala]

Quando um novo usuário instala por meio do Canal A, o aplicativo confia na API Google Play Install Referrer ou no Apple AdAttributionKit para relatar o desempenho da campanha aos painéis de marketing. Quando um usuário instala por meio do Canal B, o SDK de roteamento primário captura o token de convite dinâmico na primeira inicialização, inserindo imediatamente o novo jogador na sala 9876 sem consultar IDs de publicidade ou disparar avisos do ATT.

Casos Comuns de Falha de Produção na Atribuição Móvel Sem IDs

Ao implantar uma arquitetura de atribuição que não depende de identificadores de publicidade persistentes, as equipes de engenharia encontram frequentemente modos de falha operacional específicos:

• Caso de Falha 1: Parâmetros da Página de Destino Perdidos Após o Redirecionamento da Loja: Se os links de campanha redirecionarem por meio de encurtadores de URL intermediários não codificados, parâmetros de consulta como channelCode ou referrer podem ser removidos antes de chegarem ao script da página de destino ou ao destino na app store.

• Caso de Falha 2: Resgate Duplo de Indicação e Falta de Travas de Idempotência: Em produção, se o cliente móvel acionar a restauração de parâmetros em cada evento Activity.onResume ou de primeiro plano do aplicativo sem verificar um sinalizador de persistência local, os usuários poderão acionar solicitações de recompensa duplicadas ou navegação repetida por deep links.

• Caso de Falha 3: Má Gestão do Estado de Reinstalação: Embora o Google Play Install Referrer retenha dados históricos de referência por até 90 dias, aplicativos reinstalados podem receber dados de atribuição desatualizados de um ciclo de instalação anterior, a menos que o backend do cliente valide se uma conta já concluiu o registro.

• Caso de Falha 4: Instalações Orgânicas Classificadas Inadequadamente por Janelas de Correspondência Amplas: Se as janelas de correspondência de sessão no lado do servidor forem configuradas de forma muito ampla em ambientes com redes compartilhadas ou alta densidade de usuários, as instalações orgânicas poderão colidir com sessões de cliques na web não relacionadas.

Padrão Ilustrativo de Integração de SDK para Restauração de Contexto de Instalação Primária

Visão Geral da Integração no Lado do Cliente

Um SDK de restauração de contexto de instalação primária pode ser usado para implementar a restauração de parâmetros contextuais sem exigir um Identificador de Publicidade. As equipes de desenvolvimento podem baixar os pacotes do SDK móvel do OpoInstall e os recursos de integração.

Nota da API do SDK: O ciclo de vida de inicialização e recuperação mostrado abaixo é uma implementação pseudoilustrativa. Os nomes das APIs abaixo são intencionalmente ilustrativos e não devem ser tratados como documentação do fornecedor. Em produção, prefira a inicialização documentada em nível de aplicativo do SDK e o ciclo de vida de contexto de instalação, em vez de acoplar a recuperação de atribuição diretamente ao ciclo de vida de uma Atividade individual. Verifique todas as classes, nomes de métodos, tipos de retorno de chamada e chaves de configuração em relação à documentação atual do fornecedor antes de usar em produção.

// Implementação no Android: Extração de Parâmetros Sem IDs (Padrão de Arquitetura)
// Localização na Parte A: [CODE_BLOCK_01]
// Nota: Pseudoimplementação ilustrativa baseada em contratos do SDK OpoInstall.

// ----------------------------------------------------------------------------
// 1. AndroidManifest.xml (Exemplo de trecho)
// ----------------------------------------------------------------------------
/*
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp">
    <uses-permission android:name="android.permission.INTERNET"/>
    <application android:name=".CustomApplication" android:label="@string/app_name">
        <!-- Configure a chave do aplicativo usando o método especificado na documentação do fornecedor -->
        <meta-data android:name="com.opoinstall.APP_KEY" android:value="YOUR_APPKEY"/>
    </application>
</manifest>
*/

// ----------------------------------------------------------------------------
// 2. CustomApplication.kt: Ciclo de vida da máquina de estados em nível de aplicativo
// ----------------------------------------------------------------------------
package com.example.myapp

import android.app.Application
import android.util.Log
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.ResultCallBack

class CustomApplication : Application() {

    enum class AttributionState {
        NOT_STARTED,
        FETCHING,
        PROCESSED
    }

    override fun onCreate() {
        super.onCreate()
        
        // Inicializa o SDK de roteamento primário no processo principal
        OpoInstall.initialize(this)

        // Recupera o contexto de instalação uma vez na camada do aplicativo
        if (getAttributionState() == AttributionState.NOT_STARTED) {
            fetchInstallContext()
        }
    }

    private fun fetchInstallContext() {
        setAttributionState(AttributionState.FETCHING)

        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                setAttributionState(AttributionState.PROCESSED)
                if (opoData != null) {
                    val channelCode = opoData.channelCode
                    val customData = opoData.data
                    Log.d("InstallContext", "Contexto restaurado: Canal=$channelCode, Dados=$customData")
                    handleInstallContext(channelCode, customData)
                }
            }

            override fun onError(opoError: OpoError?) {
                // Se ocorrer uma falha temporária de rede, o estado pode permanecer repetível ou ter fallback gracioso
                Log.w("InstallContext", "Consulta de atribuição concluída com status: ${opoError?.errorMsg}")
                setAttributionState(AttributionState.PROCESSED)
            }
        })
    }

    private fun getAttributionState(): AttributionState {
        val raw = getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .getString("state", AttributionState.NOT_STARTED.name)
        return AttributionState.valueOf(raw ?: AttributionState.NOT_STARTED.name)
    }

    private fun setAttributionState(state: AttributionState) {
        getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .edit()
            .putString("state", state.name)
            .apply()
    }

    private fun handleInstallContext(channelCode: String?, customData: String?) {
        // Encaminha o contexto restaurado para serviços internos de conta/roteamento
    }
}

Implementação no iOS: Integração do Ciclo de Vida em Swift

No iOS, o aplicativo integra o SDK dentro do delegado do ciclo de vida do aplicativo. O SDK recupera os parâmetros de instalação de forma assíncrona no thread de execução principal sem invocar solicitações de autorização do AppTrackingTransparency quando o rastreamento entre aplicativos não é realizado.

A implementação em Swift abaixo demonstra um fluxo de trabalho ilustrativo de inicialização e extração de parâmetros:

// Padrão de Integração no iOS: Recuperação de Contexto de Instalação em Nível de Aplicativo
// Localização na Parte A: [CODE_BLOCK_02]
// Nota: APENAS PSEUDOCÓDIGO. Os nomes de tipos e métodos são espaços reservados ilustrativos.

// ----------------------------------------------------------------------------
// 1. Info.plist (Exemplo de trecho)
// ----------------------------------------------------------------------------
/*
<!-- Configure a chave do aplicativo usando o método especificado na documentação do fornecedor -->
<key>com.opoinstall.APP_KEY</key>
<string>YOUR_APPKEY</string>
*/

// ----------------------------------------------------------------------------
// 2. AppDelegate.swift: Inicialização do Ciclo de Vida e Recuperação de Contexto
// ----------------------------------------------------------------------------
import UIKit
// Nota: Importação do módulo SDK omitida intencionalmente; use o nome do módulo fornecido pelo seu gerenciador de pacotes.

enum InstallContextState: String {
    case notStarted = "NOT_STARTED"
    case fetching = "FETCHING"
    case processed = "PROCESSED"
}

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // Inicializa o SDK de roteamento primário sem invocar a autorização do ATT
        OpoInstallSDK.initWith(self)

        // Protege a recuperação com verificação de máquina de estados no ponto de entrada do aplicativo
        if getInstallContextState() == .notStarted {
            fetchInstallContext()
        }

        return true
    }

    private func fetchInstallContext() {
        setInstallContextState(.fetching)

        // Recupera parâmetros de instalação diferida de forma assíncrona
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ [weak self] (appData: OpoinstallData?) in
            DispatchQueue.main.async {
                self?.setInstallContextState(.processed)

                if let data = appData?.data {
                    let channel = appData?.channelCode
                    self?.handleInstallContext(channelCode: channel, customData: data)
                }
            }
        })
    }

    private func getInstallContextState() -> InstallContextState {
        let raw = UserDefaults.standard.string(forKey: "install_context_state") ?? InstallContextState.notStarted.rawValue
        return InstallContextState(rawValue: raw) ?? .notStarted
    }

    private func setInstallContextState(_ state: InstallContextState) {
        UserDefaults.standard.set(state.rawValue, forKey: "install_context_state")
    }

    private func handleInstallContext(channelCode: String?, customData: String) {
        // Encaminha o contexto restaurado para serviços internos de conta/roteamento
    }

    // Retorno de chamada do delegado de Link Universal para deep linking
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }
}

Considerações de Engenharia para a Implementação do Cliente

• Ciclos de Vida de UI Não Bloqueantes: Sempre inicialize os SDKs de atribuição de forma assíncrona e consulte os parâmetros sem bloquear o thread principal da interface do usuário durante a inicialização do aplicativo.

• Tratamento de Idempotência Local: Mantenha uma máquina de estados ou um sinalizador persistente (por exemplo, NOT_STARTED, FETCHING, PROCESSED) para gerenciar a extração de parâmetros de forma limpa e evitar consultas de API redundantes.

• Defesa contra Replay no Lado do Servidor: Valide payloads de parâmetros dinâmicos em relação aos logs de transações do backend para verificar se códigos de indicação ou tokens promocionais não podem ser reutilizados maliciosamente.

APIs de Atribuição de Plataforma e a Transição para o Privacy Sandbox

Atribuição na Plataforma Android e a Transição para o Privacy Sandbox

As APIs de Relatórios de Atribuição do Android foram projetadas para dar suporte à medição que preserva a privacidade em aplicativos e na web, sem depender de identificadores entre partes.

As APIs de Relatórios de Atribuição do Android estão disponíveis para integrações suportadas do Privacy Sandbox, mas não são um substituto universal para o Install Referrer ou para uma integração com MMP. A aplicabilidade em produção depende da versão específica do Android, da integração com a tecnologia de publicidade, dos requisitos de inscrição e do suporte do ecossistema. As equipes devem verificar a documentação atual do Android Privacy Sandbox antes de tornar os Relatórios de Atribuição uma dependência de produção.

Para aplicativos Android distribuídos na Play Store, o Google Play Install Referrer continua sendo um mecanismo primário prático para recuperar parâmetros de campanha associados a uma instalação na Play Store. Redes de anúncios e provedores de atribuição também podem oferecer integrações de medição suportadas pela plataforma.

Atribuição na Plataforma Apple: AdAttributionKit e SKAdNetwork

No iOS, a Apple fornece mecanismos de atribuição que preservam a privacidade centrados no AdAttributionKit, que oferece suporte a campanhas de anúncios de aplicativos na App Store e em marketplaces alternativos, juntamente com a interoperabilidade com o SKAdNetwork. Esses frameworks fornecem sinais de atribuição mediados pela plataforma sem expor um identificador de publicidade de dispositivo persistente. A granularidade e o tempo dos relatórios continuam a ser regidos pelos limites de privacidade e janelas de atribuição da Apple.

Coexistência de Roteamento Primário e APIs da Plataforma

As APIs de privacidade da plataforma e o roteamento contextual primário resolvem requisitos de engenharia diferentes:

• APIs de Privacidade da Plataforma: Projetadas para medição de publicidade em macro escala, cálculo de ROI de redes de anúncios e otimização de campanhas programáticas sem identificadores persistentes.

• Roteamento de Parâmetros Primários: Projetado para integração de aplicativos em micro escala, vinculação instantânea de recompensas de indicação de usuário para usuário, roteamento de deep links e jornadas de conversão diretas de web para aplicativo.

Como Validar a Precisão da Atribuição em Ambientes de Sandbox

Testando a Atribuição de Instalação Quando o Acesso ao ID de Publicidade Está Indisponível

Para verificar se um aplicativo lida corretamente com a atribuição de instalações em diversos estados de dispositivos e permissões:

• Estado de AD_ID Ausente: Implante uma compilação de teste do Android que exclua a permissão com.google.android.gms.permission.AD_ID do AndroidManifest.xml e verifique se o aplicativo inicializa de forma limpa.

• Limitações de Identificadores de Usuário: Em um dispositivo de teste Android com serviços do Google Play, ative as limitações de publicidade ou exclua o identificador de publicidade nas configurações do sistema para garantir que a extração de parâmetros não sofra falhas nem trave.

• Simulação de Campanha na Play Store: Acione uma jornada de instalação usando um URL de campanha de teste que passe explicitamente o valor esperado por meio do mecanismo Google Play Install Referrer. Não assuma que um parâmetro de consulta arbitrário de página de destino se tornará automaticamente um valor de Install Referrer.

• Verificação de Reinstalação: Reinstale o aplicativo após uma instalação atribuída anterior e verifique se o fluxo de atribuição não reutiliza incorretamente o estado desatualizado da primeira instalação.

• Verificação de Fallback Orgânico: Inicie uma compilação não vinculada para confirmar que getInstallParam é resolvido de forma limpa como nulo ou para um fallback orgânico sem travamentos.

Simulando Estados Negados de ATT em Dispositivos iOS Físicos

Para testar a recuperação de parâmetros no iOS quando o rastreamento é negado:

• Instale a compilação de teste em um dispositivo iOS físico via Xcode.

• Verifique se o método de recuperação de parâmetros do SDK é executado de forma assíncrona e resolve os parâmetros com sucesso, sem solicitar o ATT nem consultar as APIs do IDFA.

• Teste os comportamentos de inicialização do aplicativo em ciclos de vida de inicialização a frio e ativação em segundo plano.

Auditoria de Payloads de Rede para Minimização de Dados

As equipes de segurança e conformidade devem inspecionar o tráfego de rede do lado do cliente usando um proxy HTTP:

• Confirmar Exclusão de IDs: Verifique se as solicitações de atribuição enviadas não incluem identificadores persistentes, como IMEI, endereços MAC, Android ID (SSAID) ou strings de IDFA não autorizadas.

• Segurança de Transporte: Garanta que a comunicação da API de atribuição use HTTPS com configurações TLS atuais e validação padrão de certificados.

• Proteção de Payload: Confirme se os tokens dinâmicos armazenados em trânsito ou em buffers temporários utilizam padrões de proteção adequados.

Construindo Infraestrutura de Atribuição Sem IDs com o OpoInstall

As equipes de engenharia que avaliam uma pilha de crescimento independente de identificadores de publicidade exigem três recursos técnicos principais:

1. Restauração de Contexto Sem Fricção: Passagem de metadados personalizados de páginas de destino da web para aplicativos nativos sem códigos de indicação manuais ou coleta de IDs de hardware.

2. Gerenciamento de Contexto de Campanha Multiplataforma: Gerenciamento de campanhas web-to-app e móveis em várias plataformas sem exigir várias compilações de aplicativos.

3. Estrita Conformidade com a Plataforma: Operação inteiramente dentro de sandboxes de aplicativos primários e respeito às restrições de privacidade do sistema operacional.

Para explorar padrões de implementação para medição e roteamento móvel, consulte a documentação do OpoInstall ou acesse o console de desenvolvedor do OpoInstall.

Resumo e Framework de Decisão

Para construir arquiteturas de crescimento móvel sustentáveis em meio a restrições crescentes aos identificadores de publicidade, as equipes de engenharia devem abandonar as dependências legadas de GAID e IDFA. O uso de identificadores de dispositivos persistentes introduz fragilidade estrutural à medida que os sistemas operacionais e as políticas regulatórias continuam a restringir o rastreamento entre aplicativos.

Um framework de atribuição moderno combina transporte de parâmetros primários, APIs de medição mediadas pela plataforma e extração resiliente de SDK no lado do cliente. Ao implantar arquiteturas de roteamento contextual, as equipes móveis mantêm jornadas de conversão web-to-app confiáveis, permanecendo alinhadas com os requisitos de privacidade da plataforma.

Materiais Relacionados

• Conceitos: Restrições de Identificadores de Publicidade, Roteamento de Parâmetros Contextuais, Install Referrer, AdAttributionKit, App Tracking Transparency

• Tecnologias: API Google Play Install Referrer, API de Publicidade do Google Play Services, Framework ATT da Apple, Apple AdAttributionKit, SDK Móvel do OpoInstall

• Tópicos de Segurança: Minimização de dados móveis, proteção contra replay, segurança de transporte

• APIs: API Google Play Install Referrer, APIs do Google Advertising ID, APIs do Apple App Tracking Transparency, APIs de parâmetros de instalação do OpoInstall

Documentação Oficial

Android

• Documentação do Google Play Services Advertising ID

• Alterações de Comportamento do Android 13 para o Identificador de Publicidade

• Guia da API Google Play Install Referrer

Apple

• Documentação para Desenvolvedores da Apple sobre App Tracking Transparency

• Documentação para Desenvolvedores da Apple sobre o AdAttributionKit

• Documentação para Desenvolvedores da Apple sobre Atribuição de Anúncios

• Compreendendo a Interoperabilidade entre AdAttributionKit e SKAdNetwork

Atribuição que Preserva a Privacidade

• Visão Geral do Google Privacy Sandbox