Pemetaan Nilai Penukaran SKAdNetwork: Automasi Skema SKAN Dinamik

Bagaimanakah MMP memetakan skema SKAdNetwork secara automatik? Rakan Ukuran Mudah Alih (MMP) atau enjin belakang atribusi mengautomasikan pemetaan skema SKAdNetwork dengan menterjemahkan peristiwa dalam apl dan peringkat hasil kepada skema konfigurasi JSON dinamik dan berversi pada konsol berpusat. SDK mudah alih mengambil konfigurasi ini semasa pelancaran dan menilai peraturan penukaran secara lokal pada masa jalan, membolehkan perubahan peraturan penukaran yang disokong mula berkuat kuasa tanpa memerlukan pelepasan binari apl baharu.

Skema nilai penukaran SKAdNetwork ialah set peraturan peringkat vendor atau aplikasi yang memetakan tingkah laku pengguna dalam apl—seperti transaksi hasil, pencapaian onboarding, atau penglibatan ciri—kepada nilai butiran halus 6-bit Apple (0 hingga 63) dan nilai butiran kasar 3 peringkat (low, medium, high). Seni bina pemetaan dinamik mengagihkan fail konfigurasi berversi daripada bahagian belakang awan ke SDK klien, menghapuskan keperluan untuk mengekod tegar logik penukaran dalam binari aplikasi iOS yang dikompilasi.

Seni Bina Pemetaan Nilai Penukaran SKAdNetwork Automatik

Membezakan Lapisan Platform Apple daripada Lapisan Skema Vendor

Untuk mereka bentuk enjin nilai penukaran yang kukuh, pasukan kejuruteraan mesti memisahkan peraturan rangka kerja asal Apple daripada abstraksi skema peringkat vendor:

Lapisan Platform Apple: Mengawal primitif sistem pengendalian teras, termasuk tiga tingkap penukaran bersiri (Hari 0–2, Hari 3–7, Hari 8–35 selepas pelancaran pertama), nilai halus 6-bit (0–63), nilai kasar (low, medium, high), peringkat data hantaran balik, dan API SKAdNetwork.updatePostbackConversionValue.
Lapisan Skema Vendor: Merangkumi peraturan perniagaan takbiran aplikasi, seperti pengkumpulan hasil, perkembangan corong onboarding, peruntukan bendera bitwise, penyegerakan JSON jauh, dan penilaian peraturan sebelah klien.

┌────────────────────────────────────────┐
│                           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]         │
└────────────────────────────────────────┘

Kelemahan Logik Penukaran Pengekodan Tegar (Hardcoded)

Mengekod tegak logik penukaran secara terus di dalam sasaran aplikasi iOS mewujudkan batasan operasi yang ketara:

• Bergantung kepada Semakan App Store: Sebarang pengubahsuaian pada ambang hasil, wajaran peristiwa, atau pencetus kunci tingkap memerlukan kitaran pelepasan binari yang lengkap.
Pemecahan Versi: Berbilang versi apl bersejarah dalam pengeluaran menghantar semantik penukaran yang bercanggah, merosakkan model pelaporan hiliran.
Ketidakfleksibelan Pengoptimuman: Pasukan pertumbuhan tidak dapat melaraskan strategi penukaran antara kempen yang berfokuskan penglibatan dan berfokuskan pengewangan sebagai tindak balas kepada prestasi pemasaran masa nyata.

Saluran Penghantaran Konfigurasi Dinamik

Seni bina pemetaan automatik memisahkan logik penukaran daripada binari yang dikompilasi melalui saluran berbilang peringkat:

1. Konfigurasi Konsol: Pemasar dan penganalisis mengkonfigurasi wajaran peristiwa, peringkat mata wang, dan peraturan kunci tingkap pada papan pemuka berpusat.
2. Penyarian Versi dan Pematuhan Skema: Bahagian belakang menerbitkan muatan konfigurasi JSON berversi. Untuk mengelakkan hanyutan semantik semasa kitaran hayat penukaran 35 hari pengguna, pelaksanaan vendor yang kukuh menyematkan konfigurasi skema aktif yang ditetapkan semasa tingkap penukaran awal, memastikan peraturan pemetaan tepat kekal tersedia walaupun merentas mula semula apl.
3. Penyubuan & Penyimpanan Cache Klien: SDK mudah alih memuat turun skema aktif apabila permulaan apl dan menyimpan cache kedua-dua muatan konfigurasi serta metadata versi dalam storan tempatan yang berterusan.
4. Penilaian Peraturan Tempatan: Apabila peristiwa dalam apl berlaku, SDK menilainya terhadap set peraturan yang disimpan dalam cache secara lokal, tanpa menambahkan permintaan konfigurasi jauh segerak pada laluan pelaksanaan peristiwa.

Lihat Juga: SKAdNetwork ──> Seni Bina Atribusi Mudah Alih

Reka Bentuk Skema Nilai Penukaran Dinamik merentas Tingkap SKAN 4.0

Pembahagian Skema Berbilang Tingkap

SKAdNetwork 4.0 menyusun pengukuran penukaran merentas tiga tingkap bersiri yang diikat pada pelancaran pertama apl:

• Tingkap 1 (Hari 0–2): 48 jam pertama selepas pelancaran pertama.
• Tingkap 2 (Hari 3–7): Jam 48 hingga 168 selepas pelancaran pertama.
• Tingkap 3 (Hari 8–35): Jam 168 hingga 840 selepas pelancaran pertama.

Enjin skema dinamik membahagikan peraturan merentas tingkap ini, melaksanakan pengiraan nilai yang sesuai berdasarkan masa berlalu sejak pelancaran aplikasi awal.

Tingkap 1 (Hari 0–2): Menyusun Nilai Halus dan Kasar

Tingkap 1 ialah satu-satunya tingkap penukaran yang layak mendedahkan nilai penukaran butiran halus. Konfigurasi untuk Tingkap 1 mentakrifkan dua pemetaan serentak:

• Pemetaan Butiran Halus (0–63): Peraturan resolusi tinggi yang menangkap peringkat pengewangan awal, pencapaian onboarding, atau skor penglibatan komposit.
• Pemetaan Butiran Kasar (low, medium, high): Keadaan sandaran butiran lebih rendah yang mendedahkan apabila peringkat data hantaran balik yang ditetapkan tidak membenarkan pelaporan butiran halus.

Tingkap 2 (Hari 3–7) dan 3 (Hari 8–35): Penjejakan Kitaran Hayat Butiran Kasar

Hantaran balik kedua dan ketiga tidak mendedahkan nilai penukaran butiran halus; untuk peringkat data yang layak, ia mendedahkan nilai kasar sahaja.

Skema untuk Tingkap 2 dan 3 memberi tumpuan kepada pengekalan jangka panjang dan pencapaian pengewangan:

• Pemetaan Kasar Tingkap 2: Menilai pengekalan corong pertengahan (cth., low = Aktif pada Hari 3–7; medium = Melengkapkan 3 sesi; high = Pembelian berulang atau percubaan ditukar).
• Pemetaan Kasar Tingkap 3: Menilai pengekalan ekor panjang dan pembaharuan langganan (cth., low = Dikekalkan Hari 8–35; medium = Pencapaian tahap dicapai; high = Langganan berbayar aktif).

Pembangun yang mengkonfigurasi skema penukaran boleh merujuk kepada dokumentasi pemetaan penukaran SKAN untuk garis panduan teknikal mengenai struktur peraturan berbilang tingkap.

Model Pengekodan Takbiran Vendor: Pengkumpulan Hasil, Corong, dan Logik Bitwise

Model pengekodan ini mewakili corak reka bentuk peringkat vendor dan aplikasi berbanding jenis skema yang ditetapkan oleh Apple.

Skema Berasaskan Hasil

Skema hasil memperuntukkan nilai butiran halus yang tersedia merentas jumlah pembelian kumulatif:

• Pengkumpulan Linear: Membahagikan julat hasil kepada selang yang sama (cth., 64 kumpulan kenaikan $1.50 sehingga $96.00). Sesuai untuk aplikasi dengan saiz transaksi yang boleh ramal.
• Pengkumpulan Logaritma: Memperuntukkan kumpulan berbutir kepada pembelian kos rendah sambil mengembangkan julat kumpulan untuk transaksi bernilai tinggi (cth., Nilai 1–20 merangkumi $0.99–$19.99; Nilai 21–50 merangkumi $20.00–$100.00; Nilai 51–63 merangkumi $100.00–$1000.00+).
• Pengkumpulan Berasaskan Persentil: Memetakan taburan pembelian pengguna sejarah ke dalam segmen kohort berdasarkan keluk pengewangan empirikal.

Skema Perkembangan Corong dan Kekompleksan Arah Nilai

Dalam SKAdNetwork 3 dan sebelumnya, Apple memerlukan nilai penukaran meningkat secara monotonik. Dalam SKAdNetwork 4.0, Apple membuang sekatan ini, membenarkan nilai penukaran dalam Tingkap 1 meningkat atau menurun merentas panggilan API seterusnya.

Walau bagaimanapun, banyak skema atribusi secara sengaja menguatkuasakan perkembangan monotonik sebagai konvensyen reka bentuk peringkat vendor untuk memastikan nilai yang lebih tinggi mewakili hasil komersial yang semakin kukuh:

Nilai 0: Apl dipasang dan dibuka.
Nilai 10: Pendaftaran selesai.
Nilai 20: Tutorial onboarding selesai.
Nilai 30: Kaedah pembayaran ditambah.
Nilai 45: Item ditambah ke troli.
Nilai 63: Daftar keluar awal selesai.

Skema Kategori Bitwise

Skema bitwise menganggap integer 6-bit ($2^6 = 64$) sebagai enam bendera boolean bebas ($b_5 b_4 b_3 b_2 b_1 b_0$):

Muatan JSON berversi di bawah menggambarkan dokumen konfigurasi dinamik berbilang tingkap:

{
  "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 }
      }
    }
  }
}

Konfigurasi SDK Dinamik: Menyubu dan Menilai Konfigurasi Jauh pada Masa Jalan

Mekanik Penilaian Peraturan Sebelah Klien

SDK atribusi menilai peraturan penukaran secara lokal dalam masa jalan aplikasi:

Tiada Pengambilan Konfigurasi Jauh Segerak pada Laluan Peristiwa: Tindakan dalam apl mencetuskan penilaian dalam memori tempatan terhadap set peraturan aktif, memanggil API StoreKit serta-merta tanpa menyekat pelaksanaan aplikasi.
Pengecilan Data: Untuk laluan kemas kini penukaran SKAdNetwork yang ditunjukkan di sini, input peristiwa mentah boleh dinilai secara lokal dan hanya nilai penukaran terhasil perlu diserahkan kepada StoreKit. Ini tidak dengan sendirinya menerangkan atau mengehadkan aliran data analitis lain yang dilaksanakan oleh SDK.

Mengendalikan Keadaan Luar Talian dan Ketekalan Tempatan

Apabila aplikasi dilancarkan semasa luar talian atau dalam keadaan rangkaian yang merosot:

1. SDK memulakan penanda waktu pelancaran pertama secara bebas dalam ketekalan tempatan.
2. SDK memuatkan skema konfigurasi tersemat daripada storan tempatan yang berterusan, mengesahkan bahawa muatan cache sepadan dengan versi skema tersemat.
Jika peristiwa dalam apl berlaku semasa luar talian, SDK menilainya terhadap set peraturan yang disimpan dalam cache dan memanggil API kemas kini StoreKit serta-merta.
Penyediaan dan penghantaran hantaran balik kekal diuruskan oleh sistem dan tidak segerak; apl tidak perlu menghantar hantaran balik itu sendiri.

Pelaksanaan Swift di bawah menunjukkan enjin penilaian skema berbilang tingkap yang mengira nilai halus dan kasar, mengurus keadaan kunci khusus tingkap, mengekalkan konfigurasi skema tersemat, dan mengesahkan kemas kini keadaan hanya apabila pelaksanaan StoreKit berjaya:

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)")
                }
            }
        }
    }
}

Mengautomasikan Pelaksanaan lockWindow untuk Mempercepatkan Penyediaan Hantaran Balik

Mekanik Operasi Parameter lockWindow

Apabila apl memanggil updatePostbackConversionValue(_:coarseValue:lockWindow:) dengan lockWindow: true, kemas kini tersebut menjadi kemas kini nilai penukaran akhir untuk tingkap aktif. Sistem pengendalian menyediakan hantaran balik serta-merta dan mengabaikan kemas kini nilai penukaran tambahan untuk baki tingkap tersebut.

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

Pertukaran Strategik dalam Penguncian Tingkap Automatik

Penghantaran Hantaran Balik Dipercepatkan: Memuktamadkan penukaran lebih awal membolehkan kelewatan hantaran balik rawak Apple bermula serta-merta, menyampaikan data penukaran kepada rangkaian iklan dengan lebih cepat.
Kebebasan Tingkap: Mengunci tingkap semasa tidak mengalihkan permulaan tingkap seterusnya ke hadapan; Tingkap 2 masih bermula pada Hari 3 tanpa kira apabila Tingkap 1 dikunci.
Pemotongan Pemerhatian: Sebaik sahaja tingkap dikunci, sistem mengabaikan panggilan kemas kini nilai penukaran seterusnya untuk baki tingkap penukaran tersebut. Peristiwa dalam apl mungkin terus berlaku, tetapi ia tidak lagi boleh mengubah keadaan penukaran SKAdNetwork bagi tingkap tersebut.

Menyelaras Skema SKAN dengan AdAttributionKit

Bertukar Stim Atribusi Apple yang Berkembang

Apple kini mengesyorkan AdAttributionKit untuk kempen pemasaran aplikasi merentas App Store dan pasaran aplikasi alternatif. SKAdNetwork kekal relevan untuk integrasi sedia ada dan kebolehoperasian, jadi enjin pemetaan dinamik harus memastikan lapisan peraturan perniagaan mereka terpisah daripada API penukaran khusus rangka kerja:

Dimensi Nilai Berkongsi: Kedua-dua rangka kerja menilai nilai butiran halus 6-bit (0 hingga 63) dan nilai butiran kasar 3 peringkat (low, medium, high).
Lapisan API Berbeza: SKAdNetwork menggunakan SKAdNetwork.updatePostbackConversionValue, manakala AdAttributionKit menggunakan Postback.updateConversionValue.
Tingkah Laku Penghubung: Jika integrasi menyokong kedua-dua rangka kerja, Apple mengesyorkan memanggil API kemas kini penukaran kedua-dua rangka kerja, sambil mengambil kira tingkah laku penghubung SKAdNetwork-ke-AdAttributionKit yang didokumenkan.

Matriks Keputusan Perbandingan: Logik Klien Pengekodan Tegar berbanding Konfigurasi Dinamik

Ringkasan dan Rangka Kerja Keputusan

Mengautomasikan pemetaan nilai penukaran SKAdNetwork memisahkan eksperimen pertumbuhan daripada kitaran pelepasan binari mudah alih. Dengan mengagihkan skema dinamik daripada papan pemuka atribusi berpusat dan menilainya secara lokal dalam SDK, pasukan kejuruteraan boleh menyelaraskan kumpulan hasil, mengoptimumkan pencapaian corong, dan mengkonfigurasi kunci tingkap automatik, membolehkan perubahan peraturan penukaran yang disokong mula berkuat kuasa tanpa menyerahkan semula binari aplikasi kepada App Store Connect.

Haluan pautan mendalam peringkat aplikasi boleh beroperasi bersama rangka kerja atribusi pemeliharaan privasi Apple sebagai lapisan pengukuran dan onboarding yang berasingan. Platform seperti OpoInstall menyediakan infrastruktur untuk haluan konteks pihak pertama dan pautan mendalam tertunda, membolehkan pasukan memelihara niat pengguna merentas corong penukaran web-ke-apl.

Untuk mengetahui lebih lanjut tentang mengkonfigurasi atribusi yang mematuhi privasi dan saluran pautan mendalam, semak dokumentasi OpoInstall.

Bahan Berkaitan

Konsep: Skema Nilai Penukaran, Pemetaan Skema Dinamik, Pengkumpulan Hasil, Penguncian Tingkap, Monotonisiti

Teknologi: Apple SKAdNetwork, Apple AdAttributionKit, Rangka Kerja StoreKit, SDK Mudah Alih OpoInstall

Piawaian: Spesifikasi JSON IETF RFC 8259

API: API StoreKit updatePostbackConversionValue, API AdAttributionKit Postback.updateConversionValue

Dokumentasi Rasmi

Dokumentasi Pembangun Apple mengenai Mengemas Kini Nilai Penukaran Hantaran Balik

Dokumentasi Pembangun Apple mengenai SKAdNetwork

Dokumentasi Pembangun Apple mengenai AdAttributionKit

Dokumentasi Pembangun Apple mengenai Penerimaan Hantaran Balik dalam Berbilang Tingkap Penukaran

Memahami Kebolehoperasian AdAttributionKit dan SKAdNetwork