Aliran Kerja S2S SKAdNetwork: Cara Menverified Postback Rangkaian Iklan

Bagaimanakah DSP mengendalikan postback SKAdNetwork? Platform Sebelah Permintaan (DSP) dan rangkaian iklan mengendalikan postback SKAdNetwork dengan menyediakan titik akhir pengambilan HTTP POST yang selamat, membina rentetan mesej UTF-8 bersiri menggunakan pembatas U+2063, mengesahkan tandatangan kriptografi ECDSA P-256 Apple berbanding kunci awam yang diterbitkan oleh Apple, dan merekodkan ID transaksi yang disahkan untuk mengelakkan pemprosesan duplikasi sebelum mengemas kini model pembidaan.

Postback pengesahan pemasangan SKAdNetwork ialah pemberitahuan HTTPS POST yang ditandatangani oleh Apple yang dihantar oleh sistem pengendalian kepada rangkaian iklan yang layak dan, untuk atribusi yang berjaya, secara pilihan kepada titik akhir salinan yang dikonajurasikan oleh pembangun aplikasi yang diiklankan. Untuk memastikan integriti data, sistem pengambilan bahagian belakang mesti mengesahkan tandatangan ECDSA P-256 Apple, mengesahkan penyerIatan parameter, dan menguatkuasakan penyahduplikasi peringkat transaksi.

Seni Bina Pengambilan Postback SKAdNetwork untuk DSP dan Rangkaian Iklan

Saluran Paip Pengambilan Dwi: Penghantaran Rangkaian Iklan Terus vs Titik Akhir Postback Pembangun

Apabila pemasangan aplikasi iOS yang diatribusikan berlaku, subsistem atribusi Apple menghantar postback pengesahan pemasangan melalui HTTPS POST:

• Pengambilan Rangkaian Iklan: Peranti menghantar postback kemenangan utama (did-win: true) terus ke URL pelayan yang didaftarkan di bawah ad-network-id yang sepadan dalam pendaftaran Apple.
• Pengambilan Salinan Pembangun: Jika aplikasi yang diiklankan menentukan kekunci NSAdvertisingAttributionReportEndpoint dalam Info.plistnya, peranti secara serentak menghantar salinan tepat postback kemenangan itu terus kepada pelayan pembangun.
• Penghalaan Postback Bukan Kemenangan: Bermula dalam SKAdNetwork 3.0, jika berbilang rangkaian iklan layak untuk atribusi tetapi tidak menang, peranti menghantar sehingga lima postback bukan kemenangan (did-win: false) terus kepada rangkaian iklan kelayakan sekunder tersebut. Postback bukan kemenangan tidak dihantar ke titik akhir salinan pembangun.

Titik akhir pengambilan bahagian belakang harus membalas dengan HTTP 200 OK. Jika peranti tidak menerima respons 200, ia mungkin mencuba semula penghantaran sehingga sembilan kali dalam tempoh maksimum sembilan hari.

Peranan NSAdvertisingAttributionReportEndpoint dalam Pengauditan Pembangun

NSAdvertisingAttributionReportEndpoint membolehkan pembangun aplikasi menerima salinan terus postback kemenangan secara bebas daripada pemajuan rangkaian iklan:

• Pengauditan Bebas: Pembangun menerima salinan tepat semua postback kemenangan yang dihasilkan untuk aplikasi mereka, membolehkan pengesahan dalaman pelaporan rangkaian iklan.
• Laluan Titik Akhir Khusus: Pelayan pembangun mesti mengehoskan titik akhir pada https://<domain>/.well-known/skadnetwork/report-attribution/.
• Perbezaan AdAttributionKit: Untuk AdAttributionKit, Apple mentakrifkan konfigurasi berasingan yang menghala ke https://<domain>/.well-known/appattribution/report-attribution/, yang menggunakan seni bina pengesahan Tandatangan Web JSON (JWS).

Bagaimana MMP Mengambil, Mengagregat, dan Menormalkan Strim Acara S2S Berbilang Rangkaian

Bergantung pada integrasi komersial, Rakan Kongsi Pengukuran Mudah Alih (MMP) boleh mengambil data SKAdNetwork melalui pemajuan sebelah pembangun, integrasi rangkaian iklan, atau aliran pelayan rakan kongsi tersuai:

• Pengambilan Berbilang Sumber: Mengambil data postback yang disahkan yang dimajukan dari titik akhir pembangun di samping strim pelaporan rangkaian iklan terus.
• Penyahduplikasi Merentas Strim: Menormalkan dan menyahduplikasi rekod menggunakan transaction-id yang unik merentas salinan rangkaian iklan berkongsi dan pembangun.
• Pemetaan BI Hiliran: Memetakan nilai penukaran kasar dan halus kepada model hasil yang ditentukan oleh pelanggan dan acara corong.

Lihat Juga: SKAdNetwork ──> Model Atribusi Mudah Alih

Pengesahan Kriptografi: Mengesahkan Tandatangan ECDSA P-256 Apple

Memahami Timbunan Kriptografi: Lengkung NIST P-256 (secp256r1) dengan SHA-256

Setiap postback SKAdNetwork merangkumi medan attribution-signature. Tandatangan kriptografi ini dihasilkan oleh Apple menggunakan Algoritma Tandatangan Digital Lengkung Elips (ECDSA) dengan lengkung NIST P-256 (secp256r1) dan cincangan SHA-256.

Tandatangan mengesahkan dua sifat keselamatan asas:

• Keaslian: Postback dijana secara langsung oleh subsistem platform Apple pada peranti yang disahkan, bukan dipalsukan oleh klien atau proksi berniat jahat.
• Integriti: Parameter yang dilindungi oleh tandatangan belum diubah semasa transit.

Menggunakan Kunci Awam SKAdNetwork yang Diterbitkan oleh Apple

Untuk mengesahkan tandatangan, pelayan pengambilan mesti memuatkan kunci awam rasmi Apple. Untuk SKAdNetwork 2.1 dan seterusnya, Apple menerbitkan kunci awam NIST P-256 khusus dalam dokumentasi pembangunnya:

• Permulaan Kekunci: Kunci awam dimuatkan ke dalam memori sebagai objek kunci awam X.509/DER standard semasa permulaan pelayan.
• Semakan Tandatangan Asimetrik: Enjin pengesahan membina semula rentetan mesej bersiri UTF-8 yang tepat, mengira cincangan SHA-256, dan mengesahkan attribution-signature yang dinyahkod Base64 berbanding mesej yang dibina semula.

[Device / Subsystem] ──► [Dispatches Signed JSON Postback]
                                     │
                                     ▼
                  [DSP / Ad Network Ingestion Endpoint]
                  (HTTPS POST to registered postback URL)
                                     │
                                     ▼
                  [Parse JSON & Reconstruct Message String]
                  (Concatenate UTF-8 fields with \u2063)
                                     │
                                     ▼
                  [ECDSA P-256 Public Key Signature Verification]
                                     │
                      ┌──────────────┴──────────────┐
                      ▼                                                          ▼
               [Signature Valid]                                         [Signature Invalid]
                      │                                                          │
                      ▼                                                          ▼
            [Atomic Deduplication]                                       [Log Error & Discard]
            (Check transaction-id)
                      │
                      ▼
            [Process Attribution]

Mengapa Cincangan Sahaja Tidak Mencukupi: Pengesahan Tandatangan Asimetrik

Oleh kerana Apple menandatangani muatan menggunakan kunci peribadinya dan tidak mengedarkan rahsia berkongsi, pengesahan simetri (seperti HMAC-SHA256) tidak boleh digunakan. Enjin pengambilan mesti melaksanakan pengesahan tandatangan kunci awam asimetrik standard menggunakan perpustakaan kriptografi standard (seperti OpenSSL, crypto Node.js, atau cryptography Python).

Membina Rentetan Mesej untuk Pengesahan Tandatangan

Protokol PenyerIatan Ketat: Peranan Pemisah Tidak Kelihatan (\u2063)

Apple menentukan format penyerIatan bait UTF-8 yang tepat untuk membina rentetan mesej bagi pengesahan tandatangan. Parameter mesti digabungkan dalam urutan yang tepat, dipisahkan oleh aksara Unicode yang tidak kelihatan \u2063 (Pemisah Tidak Kelihatan U+2063, urutan bait UTF-8 0xE2 0x81 0xA3):

Menggantikan ruang putih, tanda baca standard, atau pemisah Unicode alternatif akan mengakibatkan kegagalan pengesahan kriptografi.

Susunan Parameter Khusus Versi untuk SKAN 4.0

Menurut Dokumentasi Pembangun Apple mengenai Pengesahan Postback Pengesahan Pemasangan, parameter untuk postback SKAdNetwork 4.0 mesti diseriatkan dalam urutan tepat berikut:

1. version (cth., "4.0")
2. ad-network-id (cth., "example123.skadnetwork")
3. source-identifier (cth., "4821")
4. app-id (cth., 1234567890)
5. transaction-id (cth., "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d")
6. redownload (cth., "true" atau "false" sebagai rentetan huruf kecil)
7. source-app-id (untuk iklan apl ke apl) ATAU source-domain (untuk iklan web ke apl dalam Safari), disertakan hanya jika ada dalam postback
8. fidelity-type (cth., 1 untuk iklan yang dirender StoreKit atau iklan web yang diatribusikan SKAdNetwork; 0 untuk iklan paparan)
9. did-win (cth., "true" atau "false" sebagai rentetan huruf kecil)
10. postback-sequence-index (cth., 0, 1, atau 2)

Spesifikasi SKAN 4 Penting: Nilai Penukaran Dikecualikan daripada Tandatangan

Dalam SKAdNetwork 4.0, tandatangan Apple tidak merangkumi conversion-value atau coarse-conversion-value, walaupun salah satu medan tersebut hadir dalam muatan JSON. Rentetan bersiri untuk SKAN 4 berakhir dengan postback-sequence-index. Percubaan untuk menambah nilai penukaran pada rentetan mesej akan menyebabkan pengesahan gagal.

Muatan JSON di bawah menggambarkan skema postback SKAdNetwork 4.0 yang lengkap. Tandatangan di bawah ialah pemegang tempat ilustrasi dan tidak akan lulus pengesahan kriptografi; untuk ujian unit, gunakan contoh yang ditandatangani Apple daripada dokumentasi pengesahan rasmi:

{
  "version": "4.0",
  "ad-network-id": "example123.skadnetwork",
  "source-identifier": "4821",
  "app-id": 1234567890,
  "transaction-id": "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d",
  "redownload": false,
  "source-app-id": 9876543210,
  "fidelity-type": 1,
  "did-win": true,
  "postback-sequence-index": 0,
  "conversion-value": 47,
  "attribution-signature": "MEQCIFz8...SAMPLE_CRYPTOGRAPHIC_SIGNATURE...=="
}

Mengendalikan Muatan SKAN 4.0 Berbilang Tingkap dan Titik Akhir Pembangun

Menghuraikan postback-sequence-index Merentas Tingkap Penukaran Berjujukan

Dalam SKAdNetwork 4.0, penukaran menjana postback daripada tingkap penukaran yang merangkumi sehingga 35 hari selepas pelancaran aplikasi pertama, dengan penghantaran sebenar berlaku selepas kelewatan pasca-tingkap rawak Apple. Sistem pengambilan bahagian belakang menghuraikan medan postback-sequence-index untuk menetapkan data penukaran kepada tingkap kitaran hayat yang betul:

• Indeks 0 (Tingkap 1: Hari 0–2): Mengandungi sama ada nilai penukaran halus (0–63) atau nilai penukaran kasar (low, medium, high), atau medan tersebut tiada.
• Indeks 1 (Tingkap 2: Hari 3–7): Untuk peringkat data postback 1–3, mungkin mendedahkan coarse-conversion-value (low, medium, high) apabila disediakan; peringkat 0 tidak layak untuk postback kedua atau ketiga.
• Indeks 2 (Tingkap 3: Hari 8–35): Untuk peringkat data postback 1–3, mungkin mendedahkan coarse-conversion-value (low, medium, high) apabila disediakan; peringkat 0 tidak layak untuk postback kedua atau ketiga.

Mengurus Nilai Penukaran Halus vs Kasar

Penyahkod pengambilan mesti mengambil kira kebolehubahan muatan:

• Kecualian Bersifat Saling (Mutual Exclusivity): Apple menentukan bahawa postback pengesahan pemasangan mungkin mengandungi sama ada conversion-value atau coarse-conversion-value, tetapi tidak pernah kedua-duanya secara serentak.
• Nilai Penukaran Tidak Hadir: Jika peringkat data postback yang ditetapkan adalah rendah (Peringkat 0), medan nilai penukaran ditinggalkan daripada muatan JSON.

Mempertahankan Diri Terhadap Serangan Main Semula dan Muatan Penukaran Palsu

Peranan transaction-id sebagai Kunci Penyahduplikasi

Setiap postback SKAdNetwork mengandungi UUID transaction-id yang unik. Dokumentasi Apple menyarankan penerima menggunakan pengecam ini sebagai kunci idempotensi untuk mengesan dan melupuskan postback penukaran duplikasi.

Oleh kerana pendengar postback ialah titik akhir HTTPS yang boleh diakses secara terbuka, pelaku berniat jahat boleh mencuba serangan main semula dengan menangkap postback yang sah dan menyerahkannya semula berulang kali untuk menaikkan metrik penukaran secara tiruan.

Melaksanakan Pemcincangan Dalam Memori Teragih dan Lejar Berterusan

Apple tidak menetapkan tempoh pengekalan penyahduplikasi universal. Penerima pengeluaran harus mengekalkan rekod idempotensi yang tahan lama untuk ID transaksi yang disahkan mengikut keperluan penyelarasan dan pertahanan main semula mereka; TTL Redis boleh digunakan sebagai pengoptimuman cache panas berbanding lejar duplikasi berwibawa tunggal:

1. Pengesahan Kriptografi Diutamakan: Sahkan sepenuhnya tandatangan ECDSA berbanding kunci awam Apple sebelum menyerahkan ID transaksi kepada storan.
2. Penyahduplikasi Atom: Laksanakan operasi tulis atom (cth., Redis SET key value NX EX <seconds>) yang disokong oleh kekangan unik pangkalan data hubungan atau dokumen yang berterusan.
3. Cakrawala Penyahduplikasi: Tetapkan tingkap pengekalan operasi dalam lapisan cache yang merangkumi penghantaran postback yang dijangkakan, percubaan semula rangkaian (Apple mencuba semula penghantaran yang gagal selama sehingga 9 hari), dan penyelarasan hiliran.

Pelaksanaan bahagian belakang di bawah menunjukkan pengesahan tandatangan, pengesahan skema, dan penyahduplikasi atom dalam Python:

import base64
import json
import redis
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.serialization import load_der_public_key
from cryptography.exceptions import InvalidSignature

# Initialize Redis client for hot-cache transaction deduplication
redis_client = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)

# Official Apple SKAdNetwork 2.1+ Public Key (Base64 DER encoded, published by Apple)
APPLE_SKAN_PUBLIC_KEY_B64 = (
    "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWdp8GPcGqmhgzEFj9Z2nSpQVdday"
    "aPe4FMzqM9wib1+aHaaIzoHoLN9zW4K8y4SPykE3YVK3sVqW6Af0lfx3gg=="
)

# Exact Apple-specified invisible separator: U+2063 INVISIBLE SEPARATOR (UTF-8: 0xE2 0x81 0xA3)
SEPARATOR = "\u2063"

def construct_skan4_message_bytes(payload: dict) -> bytes:
    """
    Constructs the serialized UTF-8 message string for SKAN 4.0 signature verification.
    Apple specification explicitly EXCLUDES conversion-value and coarse-conversion-value from the signature.
    """
    parts = [
        str(payload["version"]),
        str(payload["ad-network-id"]),
        str(payload["source-identifier"]),
        str(payload["app-id"]),
        str(payload["transaction-id"]),
        "true" if payload["redownload"] is True else "false"
    ]

    # Include source-app-id (app ad) OR source-domain (web ad) if present
    if payload.get("source-app-id") is not None:
        parts.append(str(payload["source-app-id"]))
    elif payload.get("source-domain") is not None:
        parts.append(str(payload["source-domain"]))

    parts.append(str(payload["fidelity-type"]))
    parts.append("true" if payload["did-win"] is True else "false")
    parts.append(str(payload["postback-sequence-index"]))

    # Join with U+2063 separator and encode to UTF-8
    message_string = SEPARATOR.join(parts)
    return message_string.encode('utf-8')

def verify_and_ingest_skan4_postback(postback_json_str: str) -> dict:
    """
    Validates payload schema, verifies the ECDSA P-256 signature against Apple's public key,
    and performs atomic transaction-id deduplication.
    """
    try:
        payload = json.loads(postback_json_str)
    except Exception:
        return {"status": "REJECTED", "reason": "INVALID_JSON_FORMAT"}

    # Version Gate: Enforce SKAN 4.0 payload handling
    if payload.get("version") != "4.0":
        return {"status": "REJECTED", "reason": "UNSUPPORTED_SKAN_VERSION"}

    # Schema Validation: Required fields for SKAN 4.0
    required_fields = [
        "version", "ad-network-id", "source-identifier", "app-id",
        "transaction-id", "redownload", "fidelity-type", "did-win",
        "postback-sequence-index", "attribution-signature"
    ]
    for field in required_fields:
        if field not in payload:
            return {"status": "REJECTED", "reason": f"MISSING_REQUIRED_FIELD_{field.upper()}"}

    # Strict Type Validation
    if not isinstance(payload["redownload"], bool):
        return {"status": "REJECTED", "reason": "INVALID_TYPE_REDOWNLOAD"}
    if not isinstance(payload["did-win"], bool):
        return {"status": "REJECTED", "reason": "INVALID_TYPE_DID_WIN"}
    if payload["postback-sequence-index"] not in (0, 1, 2):
        return {"status": "REJECTED", "reason": "INVALID_SEQUENCE_INDEX"}
    if payload["fidelity-type"] not in (0, 1):
        return {"status": "REJECTED", "reason": "INVALID_FIDELITY_TYPE"}

    # Enforce mutual exclusivity between source-app-id and source-domain
    has_source_app = payload.get("source-app-id") is not None
    has_source_domain = payload.get("source-domain") is not None
    if has_source_app and has_source_domain:
        return {"status": "REJECTED", "reason": "CONFLICTING_SOURCE_FIELDS"}

    signature_b64 = payload["attribution-signature"]
    transaction_id = payload["transaction-id"]

    try:
        # Step 1: Reconstruct the exact UTF-8 serialized message
        message_bytes = construct_skan4_message_bytes(payload)
        signature_der = base64.b64decode(signature_b64, validate=True)

        # Step 2: Verify ECDSA P-256 / SHA-256 signature using Apple's published public key
        apple_public_key = load_der_public_key(base64.b64decode(APPLE_SKAN_PUBLIC_KEY_B64))
        apple_public_key.verify(
            signature_der,
            message_bytes,
            ec.ECDSA(hashes.SHA256())
        )
    except InvalidSignature:
        return {"status": "REJECTED", "reason": "INVALID_CRYPTOGRAPHIC_SIGNATURE"}
    except Exception as e:
        return {"status": "ERROR", "reason": f"VERIFICATION_FAILED: {str(e)}"}

    # Step 3: Atomic Deduplication via Redis (Hot cache layer)
    # Note: In production, pair this hot cache with a persistent unique database constraint.
    # 14-day TTL (1,209,600 seconds) serves as an illustrative receiver cache policy covering retries.
    is_new = redis_client.set(f"skan_tx:{transaction_id}", "1", nx=True, ex=1209600)
    if not is_new:
        return {"status": "DUPLICATE", "reason": "TRANSACTION_ALREADY_PROCESSED"}

    return {
        "status": "VERIFIED",
        "transaction_id": transaction_id,
        "sequence_index": payload["postback-sequence-index"],
        "did_win": payload["did-win"]
    }

Mengambil Postback ke dalam Model Pembidaan Masa Nyata dan Pengoptimum CPA

Menyahgandingkan Pengambilan Tepi daripada Pemprosesan Asynchronous

DSP volum tinggi memproses volum postback yang besar semasa tempoh kempen puncak. Pemprosesan hiliran segerak boleh memperkenalkan kesesakan pendam.

Seni bina perusahaan melaksanakan saluran paip asynchronous:

1. Penerima Tepi: Menerima HTTP POST yang masuk, mengesahkan keaslian tandatangan, melaksanakan penyahduplikasi atom pada transaction-id, dan serta-merta membalas HTTP 200 OK.
2. Bar Giliran Acara: Menerbitkan muatan yang disahkan kepada broker acara teragih (cth., Apache Kafka atau AWS SQS).
3. Pekerja Pembidaan & Analitis: Mengambil strim acara, memetakan nilai penukaran kepada metrik hasil, dan mengemas kini model CPA sasaran Pembidaan Masa Nyata (RTB).

Menggunakan Pengecam Sumber Berhierarki

Postback kemenangan pertama mungkin mendedahkan dua, tiga, atau empat digit source-identifier berhierarki, bergantung pada peringkat data postback. Maksud semantik digit tersebut ditakrifkan oleh taksonomi pengecam sumber rangkaian iklan itu sendiri. Sistem pembidaan harus menyelesaikan pengecam sumber yang diterima berbanding metadata kempen rangkaian itu sendiri, bukan menganggap pemetaan universal antara panjang digit dan penempatan tertentu atau kekangan kreatif.

Matriks Perbandingan: Penghantaran Terus Apple berbanding Pengambilan S2S MMP

Ringkasan dan Rangka Kerja Keputusan

Mengendalikan postback SKAdNetwork pada skala besar memerlukan gabungan pengambilan tepi pendaman rendah dengan pengesahan kriptografi yang ketat dan penyahduplikasi peringkat transaksi. Kerana postback Apple mempengaruhi peruntukan bajet dan algoritma pembidaan secara langsung, mengesahkan tandatangan ECDSA dan menguatkuasakan idempotensi transaction-id melindungi saluran pengambilan daripada postback yang dipalsukan atau diubah suai serta pemprosesan main semula duplikasi.

Untuk melengkapkan pelaporan SKAdNetwork yang dimediasi platform dengan penyertaan pengguna peringkat mikro dan penghalaan pautan dalam segera, pasukan kejuruteraan menyelaraskan seni bina penghalaan pihak pertama di samping API platform.

Untuk mengetahui lebih lanjut mengenai pengkonfigurasian postback atribusi sebelah pelayan dan saluran paip pautan dalam, semak dokumentasi OpoInstall.

Bahan Berkaitan

• Konsep: Postback S2S, Pengesahan Kriptografi, ECDSA P-256, Pertahanan Serangan Main Semula, Penyahduplikasi Transaksi

• Teknologi: Apple SKAdNetwork, Apple AdAttributionKit, Cache Dalam Memori Redis, SDK Mudah Alih OpoInstall

• Piawaian: IETF RFC 8259 (Pertukaran Data JSON), RFC 5480 (Kriptografi Lengkung Elips)

• API: API StoreKit SKAdNetwork, Spesifikasi Penghantaran Postback S2S Apple, API S2S OpoInstall

Dokumentasi Rasmi

• Dokumentasi Pembangun Apple mengenai Pengesahan Postback Pengesahan Pemasangan

• Dokumentasi Pembangun Apple mengenai Mengenal pasti Parameter dalam Postback Pengesahan Pemasangan

• Dokumentasi Pembangun Apple mengenai Mengkonfigurasi Aplikasi yang Diiklankan

• Dokumentasi Pembangun Apple mengenai SKAdNetwork

• Dokumentasi Pembangun Apple mengenai AdAttributionKit