Mapeamento de Valores de Conversão do SKAdNetwork: Automatizando Esquemas SKAN Dinâmicos

Como um MMP mapeia esquemas do SKAdNetwork automaticamente? Um Partner de Mensuração Móvel (MMP) ou backend de atribuição automatiza o mapeamento de esquemas do SKAdNetwork traduzindo eventos no aplicativo e faixas de receita em esquemas de configuração JSON dinâmicos e versionados em um console centralizado. O SDK móvel recupera essa configuração no lançamento e avalia as regras de conversão localmente em tempo de execução, permitindo que alterações compatíveis nas regras de conversão entrem em vigor sem exigir um novo lançamento de binário do aplicativo.

Um esquema de valor de conversão do SKAdNetwork é um conjunto de regras de nível de fornecedor ou de aplicativo que mapeia comportamentos do usuário no aplicativo — como transações de receita, marcos de integração ou engajamento com recursos — para os valores granulares de 6 bits da Apple (0 a 63) e valores de granulação grossa de 3 níveis (low, medium, high). Arquiteturas de mapeamento dinâmico distribuem arquivos de configuração versionados de um backend em nuvem para o SDK do cliente, eliminando a necessidade de codificar a lógica de conversão diretamente nos binários compilados de aplicativos iOS.

A Arquitetura do Mapeamento Automatizado de Valores de Conversão do SKAdNetwork

Delineando a Camada de Plataforma da Apple da Camada de Esquema do Forcedor

Para arquitetar um motor robusto de valor de conversão, as equipes de engenharia devem separar as regras do framework nativo da Apple das abstrações de esquema em nível de fornecedor:

• Camada de Plataforma da Apple: Regula as primitivas principais do sistema operacional, incluindo as três janelas de conversão sequenciais (Dia 0–2, Dia 3–7, Dia 8–35 após o primeiro lançamento), valores finos de 6 bits (0–63), valores grossos (low, medium, high), camadas de dados de postback e a API SKAdNetwork.updatePostbackConversionValue.
• Camada de Esquema do Forcedor: Abriga as regras de negócios definidas pelo aplicativo, tais como agrupamento de receita, progressões no funil de integração, alocações de flags bit a bit, sincronização remota de JSON e avaliação de regras no lado do cliente.

┌────────────────────────────────────────┐
│                           Vendor Schema Layer                                  │
│  [MMP / Analytics Console] ──► [Publishes Versioned JSON Configuration]     │
│                                              │                                │
│  [Client Mobile SDK]       ──► [Evaluates In-App Events Locally in Memory]  │
└──────────────────────────────────────┬─┘
                                       │ (Calculates Fine, Coarse, & Lock)
                                       ▼
┌────────────────────────────────────────┐
│                           Apple Platform Layer                                 │
│  [StoreKit Framework]      ──► [SKAdNetwork.updatePostbackConversionValue]  │
│  [Operating System]        ──► [Manages Conversion Windows & Timers]        │
│  [System]                  ──► [Prepares and Sends Signed Postback]         │
└────────────────────────────────────────┘

As Armadilhas da Lógica de Conversão Rígida (Hardcoded)

Inserir a lógica de conversão diretamente dentro de um target de aplicativo iOS cria limitações operacionais significativas:

• Dependência de Revisão da App Store: Qualquer modificação em limites de receita, pesos de eventos ou gatilhos de bloqueio de janela requer um ciclo completo de lançamento de binário.
• Fragrância de Versões: Várias versões históricas de aplicativos em produção transmitem semânticas de conversão conflitantes, corrompendo os modelos de relatórios subsequentes.
• Inflexibilidade de Otimização: As equipes de crescimento não podem ajustar as estratégias de conversão entre campanhas focadas em engajamento e focadas em monetização em resposta ao desempenho de marketing em tempo real.

O Pipeline de Entrega de Configuração Dinâmica

As arquiteturas de mapeamento automatizado desacoplam a lógica de conversão do binário compilado por meio de um pipeline em vários estágios:

1. Configuração no Console: Profissionais de marketing e analistas configuram pesos de eventos, camadas de moeda e regras de bloqueio de janela em um painel centralizado.
2. Versionamento e Fixação de Esquema: O backend publica um payload de configuração JSON versionado. Para evitar desvios semânticos durante o ciclo de vida de conversão de 35 dias do usuário, uma implementação robusta de fornecedor fixa a configuração de esquema ativa estabelecida durante a janela de conversão inicial, garantindo que as regras exatas de mapeamento permaneçam disponíveis mesmo após reinicializações do aplicativo.
3. Ingestão e Cache pelo Cliente: O SDK móvel baixa o esquema ativo na inicialização do aplicativo e armazena em cache tanto o payload de configuração quanto os metadados de versão no armazenamento local persistente.
4. Avaliação de Regras Locais: Quando ocorrem eventos no aplicativo, o SDK os avalia em relação ao conjunto de regras em cache localmente, sem adicionar uma solicitação síncrona de configuração remota ao caminho de execução do evento.

Veja Também: SKAdNetwork ──> Arquitetura de Atribuição Móvel

Criando Esquemas Dinâmicos de Valores de Conversão nas Janelas do SKAN 4.0

Particionamento de Esquema Multi-Janela

O SKAdNetwork 4.0 estrutura a mensuração de conversão em três janelas sequenciais ancoradas ao primeiro lançamento do aplicativo:

• Janela 1 (Dia 0–2): Primeiras 48 horas após o primeiro lançamento.
• Janela 2 (Dia 3–7): Horas 48 a 168 após o primeiro lançamento.
• Janela 3 (Dia 8–35): Horas 168 a 840 após o primeiro lançamento.

Um motor de esquema dinâmico particiona as regras entre essas janelas, executando cálculos de valores apropriados com base no tempo decorrido desde o lançamento inicial do aplicativo.

Janela 1 (Dia 0–2): Estruturando Valores Finos e Grossos

A Janela 1 é a única janela de conversão elegível para divulgar valores de conversão granulares (finos). A configuração para a Janela 1 define dois mapeamentos simultâneos:

• Mapeamento Fino (0–63): Regras de alta resolução que capturam patamares iniciais de monetização, marcos de integração ou pontuações compostas de engajamento.
• Mapeamento Grosso (low, medium, high): Estados de fallback de menor granulação divulgados quando a camada de dados de postback atribuída não permite relatórios detalhados.

Janelas 2 (Dia 3–7) e 3 (Dia 8–35): Rastreamento de Ciclo de Vida de Granulação Grossa

O segundo e o terceiro postbacks não expõem valores de conversão finos; para as camadas de dados elegíveis, eles divulgam apenas valores grossos.

Os esquemas para as Janelas 2 e 3 concentram-se na retenção de longo prazo e em marcos de monetização:

• Mapeamento Grosso da Janela 2: Avalia a retenção no meio do funil (por exemplo, low = Ativo no Dia 3–7; medium = Concluiu 3 sessões; high = Compra repetida ou teste convertido).
• Mapeamento Grosso da Janela 3: Avalia a retenção de longo prazo e renovações de assinatura (por exemplo, low = Retido no Dia 8–35; medium = Marco de nível alcançado; high = Assinante pago ativo).

Os desenvolvedores que configuram esquemas de conversão podem consultar a documentação de mapeamento de conversão SKAN para diretrizes técnicas sobre estruturas de regras em várias janelas.

Modelos de Codificação Definidos pelo Fornecedor: Agrupamento de Receita, Funis e Lógica Bitwise

Esses modelos de codificação representam padrões de design em nível de fornecedor e aplicativo, e não tipos de esquema prescritos pela Apple.

Esquemas Baseados em Receita

Os esquemas de receita alocam os valores finos disponíveis em montantes de compras cumulativas:

• Agrupamento Linear (Linear Bucketing): Divide uma faixa de receita em intervalos iguais (por exemplo, 64 compartimentos de incrementos de $1.50 até $96.00). Ideal para aplicativos com tamanhos de transação previsíveis.
• Agrupamento Logarítmico (Logarithmic Bucketing): Aloca buckets granulares para compras de baixo custo enquanto expande as faixas para transações de alto valor (por exemplo, Valores 1–20 cobrem $0.99–$19.99; Valores 21–50 cobrem $20.00–$100.00; Valores 51–63 cobrem $100.00–$1000.00+).
• Agrupamento Baseado em Percentil: Mapeia distribuições históricas de compras de usuários em segmentos de coorte com base em curvas empíricas de monetização.

Esquemas de Progressão de Funil e Direcionalidade de Valores

No SKAdNetwork 3 e anteriores, a Apple exigia que os valores de conversão aumentassem monotonicamente. No SKAdNetwork 4.0, a Apple removeu essa restrição, permitindo que os valores de conversão na Janela 1 aumentem ou diminuam em chamadas de API subsequentes.

No entanto, muitos esquemas de atribuição aplicam intencionalmente a progressão monotônica como uma convenção de design em nível de fornecedor para garantir que valores mais altos representem resultados comerciais progressivamente mais fortes:

• Valor 0: Aplicativo instalado e aberto.
• Valor 10: Cadastro concluído.
• Valor 20: Tutorial de integração concluído.
• Valor 30: Forma de pagamento adicionada.
• Valor 45: Item adicionado ao carrinho.
• Valor 63: Checkout inicial concluído.

Esquemas Categóricos Bitwise

Os esquemas bitwise tratam o inteiro de 6 bits ($2^6 = 64$) como seis flags booleanas independentes ($b_5 b_4 b_3 b_2 b_1 b_0$):

O payload JSON versionado abaixo ilustra um documento de configuração dinâmica multi-janela:

{
  "schema_version": "4.0.1",
  "app_id": "1234567890",
  "currency": "USD",
  "windows": {
    "window_1": {
      "mode": "hybrid_revenue_and_funnel",
      "fine_mapping": [
        { "event": "app_open", "min_revenue_cents": 0, "fine_value": 0, "lock": false },
        { "event": "registration_complete", "min_revenue_cents": 0, "fine_value": 10, "lock": false },
        { "event": "tutorial_complete", "min_revenue_cents": 0, "fine_value": 20, "lock": false },
        { "event": "purchase", "min_revenue_cents": 99, "fine_value": 30, "lock": false },
        { "event": "purchase", "min_revenue_cents": 999, "fine_value": 45, "lock": false },
        { "event": "purchase", "min_revenue_cents": 4999, "fine_value": 63, "lock": true }
      ],
      "coarse_mapping": {
        "low": { "events": ["app_open", "registration_complete"] },
        "medium": { "events": ["tutorial_complete"] },
        "high": { "events": ["purchase"] }
      }
    },
    "window_2": {
      "mode": "coarse_retention_and_monetization",
      "coarse_mapping": {
        "low": { "events": ["app_open"], "lock": false },
        "medium": { "events": ["session_milestone"], "lock": false },
        "high": { "events": ["repeat_purchase"], "lock": true }
      }
    },
    "window_3": {
      "mode": "coarse_long_tail_ltv",
      "coarse_mapping": {
        "low": { "events": ["app_open"], "lock": false },
        "medium": { "events": ["level_milestone"], "lock": false },
        "high": { "events": ["subscription_active"], "lock": true }
      }
    }
  }
}

Configuração Dinâmica de SDK: Ingestão e Avaliação de Configs Remotas em Tempo de Execução

Mecânica de Avaliação de Regras no Lado do Cliente

Os SDKs de atribuição avaliam as regras de conversão localmente no tempo de execução do aplicativo:

• Sem Busca Síncrona de Configuração Remota no Caminho do Evento: As ações no aplicativo acionam avaliações locais em memória em relação a um conjunto de regras ativo, chamando as APIs do StoreKit imediatamente sem bloquear a execução do aplicativo.
• Minimização de Dados: Para o caminho de atualização de conversão do SKAdNetwork mostrado aqui, os inputs de eventos brutos podem ser avaliados localmente e apenas os valores de conversão resultantes precisam ser repassados ao StoreKit. Isso por si só não descreve ou limita outros fluxos de dados analíticos implementados por um SDK.

Tratamento de Estado Offline e Persistência Local

Quando um aplicativo é iniciado offline ou em condições de rede degradadas:

1. O SDK inicializa a âncora de timestamp do primeiro lançamento independentemente na persistência local.
2. O SDK carrega o esquema de configuração fixado do armazenamento local persistente, verificando se o payload em cache corresponde à versão de esquema fixada.
3. Se ocorrerem eventos no aplicativo enquanto estiver offline, o SDK os avalia em relação ao conjunto de regras em cache e chama a API de atualização do StoreKit imediatamente.
4. A preparação e a entrega de postbacks permanecem gerenciadas pelo sistema e assíncronas; o aplicativo não precisa despachar postbacks por conta própria.

A implementação em Swift abaixo demonstra um motor de avaliação de esquema multi-janela que calcula valores finos e grossos, gerencia estados de bloqueio específicos de janela, persiste configurações de esquema fixadas e consolida atualizações de estado apenas após a execução bem-sucedida do StoreKit:

import Foundation
import StoreKit

// MARK: - Schema Configuration Models

struct SKANSchemaConfig: Codable {
    let schemaVersion: String
    let appId: String
    let currency: String
    let windows: SchemaWindows

    enum CodingKeys: String, CodingKey {
        case schemaVersion = "schema_version"
        case appId = "app_id"
        case currency, windows
    }
}

struct SchemaWindows: Codable {
    let window1: Window1Config
    let window2: WindowCoarseConfig
    let window3: WindowCoarseConfig

    enum CodingKeys: String, CodingKey {
        case window1 = "window_1"
        case window2 = "window_2"
        case window3 = "window_3"
    }
}

struct Window1Config: Codable {
    let mode: String
    let fineMapping: [FineRule]
    let coarseMapping: CoarseRuleGroup

    enum CodingKeys: String, CodingKey {
        case mode
        case fineMapping = "fine_mapping"
        case coarseMapping = "coarse_mapping"
    }
}

struct FineRule: Codable {
    let event: String
    let minRevenueCents: Int
    let fineValue: Int
    let lock: Bool

    enum CodingKeys: String, CodingKey {
        case event
        case minRevenueCents = "min_revenue_cents"
        case fineValue = "fine_value"
        case lock
    }
}

struct WindowCoarseConfig: Codable {
    let mode: String
    let coarseMapping: [String: CoarseRule]

    enum CodingKeys: String, CodingKey {
        case mode
        case coarseMapping = "coarse_mapping"
    }
}

struct CoarseRuleGroup: Codable {
    let low: CoarseRule
    let medium: CoarseRule
    let high: CoarseRule
}

struct CoarseRule: Codable {
    let events: [String]?
    let lock: Bool?
}

// MARK: - Multi-Window SKAN 4.0 Schema Engine

final class SKANSchemaEngine {

    static let shared = SKANSchemaEngine()
    private init() {}

    private var activeSchema: SKANSchemaConfig?
    private var firstLaunchDate: Date?
    private var lockedWindows = Set<Int>()
    private var lastRecordedFineValue: Int = 0
    private var pinnedSchemaVersion: String?

    /// Initializes the first-launch timestamp anchor independently of remote configuration fetches
    func initializeLifecycleAnchor() {
        let defaults = UserDefaults.standard
        if let storedLaunch = defaults.object(forKey: "skan_first_launch_date") as? Date {
            self.firstLaunchDate = storedLaunch
        } else {
            let now = Date()
            self.firstLaunchDate = now
            defaults.set(now, forKey: "skan_first_launch_date")
        }

        let lockedArray = defaults.array(forKey: "skan_locked_windows") as? [Int] ?? []
        self.lockedWindows = Set(lockedArray)
        self.lastRecordedFineValue = defaults.integer(forKey: "skan_last_fine_value")
        self.pinnedSchemaVersion = defaults.string(forKey: "skan_pinned_schema_version")

        // Restore previously cached schema payload if it matches the pinned version
        if let pinnedVersion = self.pinnedSchemaVersion,
           let cachedData = defaults.data(forKey: "skan_cached_schema_payload"),
           let cachedSchema = try? JSONDecoder().decode(SKANSchemaConfig.self, from: cachedData),
           cachedSchema.schemaVersion == pinnedVersion {
            self.activeSchema = cachedSchema
        }
    }

    /// Loads active schema, persisting the pinned payload to maintain consistency across the 35-day lifecycle
    func configure(schema: SKANSchemaConfig) {
        let defaults = UserDefaults.standard
        if let pinned = pinnedSchemaVersion {
            // If already pinned, accept only schemas matching the pinned version
            if pinned == schema.schemaVersion {
                self.activeSchema = schema
                if let data = try? JSONEncoder().encode(schema) {
                    defaults.set(data, forKey: "skan_cached_schema_payload")
                }
            }
        } else {
            // Pin the initial schema version for this lifecycle
            self.activeSchema = schema
            self.pinnedSchemaVersion = schema.schemaVersion
            defaults.set(schema.schemaVersion, forKey: "skan_pinned_schema_version")
            if let data = try? JSONEncoder().encode(schema) {
                defaults.set(data, forKey: "skan_cached_schema_payload")
            }
        }
    }

    /// Determines the active conversion window based on elapsed time from first launch
    private var currentWindowIndex: Int {
        guard let firstLaunch = firstLaunchDate else { return 0 }
        let elapsedHours = Date().timeIntervalSince(firstLaunch) / 3600.0

        switch elapsedHours {
        case 0.0..<48.0:
            return 1
        case 48.0..<168.0:
            return 2
        case 168.0...840.0:
            return 3
        default:
            return 0 // Window closed (>35 days)
        }
    }

    /// Evaluates an in-app event against the active schema for the current window
    func trackEvent(name: String, revenueCents: Int = 0) {
        guard #available(iOS 16.1, *),
              let schema = activeSchema else { return }

        let window = currentWindowIndex
        guard window >= 1 && window <= 3, !lockedWindows.contains(window) else { return }

        var targetFineValue: Int?
        var targetCoarseValue: SKAdNetwork.CoarseConversionValue?
        var shouldLock = false
        var matchedRule = false

        if window == 1 {
            // Window 1: Evaluate fine-grained rules with highest-threshold precedence
            let matchingFineRules = schema.windows.window1.fineMapping
                .filter { $0.event == name && revenueCents >= $0.minRevenueCents }
                .sorted { $0.minRevenueCents < $1.minRevenueCents }

            if let highestRule = matchingFineRules.last {
                targetFineValue = highestRule.fineValue
                if highestRule.lock { shouldLock = true }
                matchedRule = true
            }

            // Window 1: Evaluate coarse-grained rules explicitly
            if schema.windows.window1.coarseMapping.high.events?.contains(name) == true {
                targetCoarseValue = .high
                matchedRule = true
            } else if schema.windows.window1.coarseMapping.medium.events?.contains(name) == true {
                targetCoarseValue = .medium
                matchedRule = true
            } else if schema.windows.window1.coarseMapping.low.events?.contains(name) == true {
                targetCoarseValue = .low
                matchedRule = true
            }
        } else {
            // Windows 2 & 3: Evaluate coarse rules only
            let coarseConfig = (window == 2) ? schema.windows.window2 : schema.windows.window3
            
            if let highRule = coarseConfig.coarseMapping["high"], highRule.events?.contains(name) == true {
                targetCoarseValue = .high
                if highRule.lock == true { shouldLock = true }
                matchedRule = true
            } else if let medRule = coarseConfig.coarseMapping["medium"], medRule.events?.contains(name) == true {
                targetCoarseValue = .medium
                if medRule.lock == true { shouldLock = true }
                matchedRule = true
            } else if let lowRule = coarseConfig.coarseMapping["low"], lowRule.events?.contains(name) == true {
                targetCoarseValue = .low
                if lowRule.lock == true { shouldLock = true }
                matchedRule = true
            }
        }

        // If no explicit rule matched for this event, do not trigger a StoreKit update
        guard matchedRule else { return }

        let fineToSubmit = targetFineValue ?? (window == 1 ? lastRecordedFineValue : 0)
        let clampedFine = max(0, min(63, fineToSubmit))
        let coarseToSubmit = targetCoarseValue ?? .low

        // Dispatch StoreKit conversion update
        // Note: StoreKit ignores the fineValue parameter after Window 1
        SKAdNetwork.updatePostbackConversionValue(
            clampedFine,
            coarseValue: coarseToSubmit,
            lockWindow: shouldLock
        ) { [weak self] error in
            guard let self = self else { return }
            if let error = error {
                print("StoreKit conversion update failed: \(error.localizedDescription)")
            } else {
                // Commit local state only after StoreKit successfully accepts the update
                DispatchQueue.main.async {
                    if window == 1 {
                        self.lastRecordedFineValue = clampedFine
                        UserDefaults.standard.set(clampedFine, forKey: "skan_last_fine_value")
                    }
                    if shouldLock {
                        self.lockedWindows.insert(window)
                        UserDefaults.standard.set(Array(self.lockedWindows), forKey: "skan_locked_windows")
                    }
                    print("SKAN 4.0 update succeeded: Window=\(window), Fine=\(clampedFine), Coarse=\(coarseToSubmit.rawValue), Locked=\(shouldLock)")
                }
            }
        }
    }
}

Automatizando a Execução do lockWindow para Acelerar a Preparação de Postbacks

Mecânica Operacional do Parâmetro lockWindow

Quando um aplicativo chama updatePostbackConversionValue(_:coarseValue:lockWindow:) com lockWindow: true, a atualização se torna a atualização final do valor de conversão para a janela ativa. O sistema operacional prepara o postback imediatamente e ignora atualizações adicionais do valor de conversão pelo resto dessa janela.

Default Window 1 (No Lock):
[First Launch] ─────────────── 48 Hours Open ───────────────► [Closes] ──► Delay (24-48h) ──► Postback 1

Locked Window 1 (Purchase at Hour 6):
[First Launch] ── 6h (Lock: true) ──► [Conversion Locked / Postback Prepared] ──► Delay (24-48h) ──► Postback 1 Sent Sooner

Compromissos Estratégicos no Bloqueio Automatizado de Janelas

• Envio Acelerado de Postback: Finalizar uma conversão precocemente permite que o atraso randomizado de postback da Apple comece imediatamente, entregando os dados de conversão para as redes de anúncios mais rapidamente.
• Independência de Janela: Bloquear a janela atual não avança o início da próxima janela; a Janela 2 ainda começa no Dia 3, independentemente de quando a Janela 1 foi bloqueada.
• Troncamento de Observação: Uma vez que a janela é bloqueada, o sistema ignora chamadas subsequentes de atualização do valor de conversão pelo restante daquela janela de conversão. Eventos no aplicativo podem continuar a ocorrer, mas não podem mais alterar o estado de conversão SKAdNetwork daquela janela.

Coordenando Esquemas SKAN com o AdAttributionKit

A Pilha de Atribuição em Evolução da Apple

A Apple agora recomenda o AdAttributionKit para campanhas publicitárias de aplicativos na App Store e em marketplaces de aplicativos alternativos. O SKAdNetwork continua relevante para integrações existentes e interoperabilidade, portanto, os motores de mapeamento dinâmico devem manter sua camada de regras de negócios separada das APIs de conversão específicas do framework:

• Dimensões de Valores Compartilhadas: Ambos os frameworks avaliam valores finos de 6 bits (0 a 63) e valores grossos de 3 níveis (low, medium, high).
• Camadas de API Distintas: O SKAdNetwork usa SKAdNetwork.updatePostbackConversionValue, enquanto o AdAttributionKit usa Postback.updateConversionValue.
• Comportamento de Ponte (Bridging): Se uma integração suporta ambos os frameworks, a Apple recomenda chamar as APIs de atualização de conversão de ambos, contabilizando o comportamento documentado de ponte entre SKAdNetwork e AdAttributionKit.

Matriz de Decisão Comparativa: Lógica de Cliente Hardcoded versus Configuração Dinâmica

Resumo e Framework de Decisão

A automação do mapeamento de valores de conversão do SKAdNetwork desacopla a experimentação de crescimento dos ciclos de lançamento de binários móveis. Ao distribuir esquemas dinâmicos de um painel de atribuição centralizado e avaliá-los localmente dentro do SDK, as equipes de engenharia podem ajustar faixas de receita, otimizar marcos de funil e configurar bloqueios de janela automatizados, permitindo que alterações compatíveis nas regras de conversão entrem em vigor sem reenviar binários de aplicativos para a App Store Connect.

O roteamento de links profundos em nível de aplicativo pode operar em paralelo aos frameworks de atribuição com preservação de privacidade da Apple como uma camada separada de mensuração e integração. Plataformas como a OpoInstall fornecem infraestrutura para roteamento contextual proprietário e links profundos adiados (deferred deep linking), permitindo que as equipes preservem a intenção do usuário em funis de conversão de web para aplicativo.

Para saber mais sobre como configurar atribuição compatível com a privacidade e pipelines de links profundos, consulte a documentação da OpoInstall.

Materiais Relacionados

• Conceitos: Esquemas de Valores de Conversão, Mapeamento de Esquema Dinâmico, Agrupamento de Receita, Bloqueio de Janela, Monotonicidade

• Tecnologias: Apple SKAdNetwork, Apple AdAttributionKit, StoreKit Framework, SDK Móvel OpoInstall

• Padrões: Especificação JSON IETF RFC 8259

• APIs: API updatePostbackConversionValue do StoreKit, API Postback.updateConversionValue do AdAttributionKit

Documentação Oficial

• Documentação do Desenvolvedor Apple sobre Atualização de Valores de Conversão de Postback

• Documentação do Desenvolvedor Apple sobre o SKAdNetwork

• Documentação do Desenvolvedor Apple sobre o AdAttributionKit

• Documentação do Desenvolvedor Apple sobre Recepção de Postbacks em Múltiplas Janelas de Conversão

• Compreendendo a Interoperabilidade entre AdAttributionKit e SKAdNetwork