Quy trình S2S SKAdNetwork: Cách xác minh postback của mạng quảng cáo

DSPs xử lý postback SKAdNetwork như thế nào? Các Nền tảng phía cầu (DSP) và mạng quảng cáo xử lý postback SKAdNetwork bằng cách thiết lập các điểm cuối nhận HTTP POST bảo mật, xây dựng chuỗi thông điệp UTF-8 đã tuần tự hóa sử dụng dấu phân cách U+2063, xác minh chữ ký mã hóa ECDSA P-256 của Apple so với khóa công khai đã công bố của Apple, và ghi lại các ID giao dịch đã được xác minh để ngăn chặn việc xử lý trùng lặp trước khi cập nhật các mô hình đấu giá.

Postback xác thực lượt cài đặt SKAdNetwork là một thông báo HTTPS POST do Apple ký mà hệ điều hành gửi đến một mạng quảng cáo đủ điều kiện và, đối với các lượt phân bổ thành công, tùy chọn gửi đến điểm cuối sao chép đã cấu hình của nhà phát triển ứng dụng được quảng cáo. Để đảm bảo tính toàn vẹn dữ liệu, các hệ thống nhận backend phải xác minh chữ ký ECDSA P-256 của Apple, xác thực việc tuần tự hóa tham số và thực thi việc khử trùng lặp ở cấp độ giao dịch.

Kiến trúc tiếp nhận Postback SKAdNetwork dành cho DSP và mạng quảng cáo

Đường ống tiếp nhận kép: Phân phối trực tiếp qua mạng quảng cáo so với điểm cuối postback của nhà phát triển

Khi một lượt cài đặt ứng dụng iOS được phân bổ xảy ra, hệ thống con phân bổ của Apple sẽ gửi các postback xác thực lượt cài đặt qua HTTPS POST:

• Tiếp nhận qua Mạng quảng cáo: Thiết bị chuyển postback chiến thắng chính (did-win: true) trực tiếp đến URL máy chủ được đăng ký dưới ad-network-id tương ứng trong sổ đăng ký của Apple.
• Tiếp nhận qua Bản sao của Nhà phát triển: Nếu ứng dụng được quảng cáo chỉ định khóa NSAdvertisingAttributionReportEndpoint trong tệp Info.plist của nó, thiết bị đồng thời gửi một bản sao chính xác của postback chiến thắng trực tiếp đến máy chủ của nhà phát triển.
• Định tuyến Postback không chiến thắng: Bắt đầu từ SKAdNetwork 3.0, nếu nhiều mạng quảng cáo đủ điều kiện phân bổ nhưng không chiến thắng, thiết bị sẽ gửi tối đa năm postback không chiến thắng (did-win: false) trực tiếp đến các mạng quảng cáo đủ điều kiện phụ đó. Các postback không chiến thắng không được phân phối đến điểm cuối sao chép của nhà phát triển.

Các điểm cuối tiếp nhận backend nên phản hồi bằng HTTP 200 OK. Nếu thiết bị không nhận được phản hồi 200, thiết bị có thể thử gửi lại tối đa chín lần trong tổng thời gian tối đa chín ngày.

Vai trò của NSAdvertisingAttributionReportEndpoint trong việc kiểm toán của nhà phát triển

Khóa NSAdvertisingAttributionReportEndpoint cho phép các nhà phát triển ứng dụng nhận các bản sao trực tiếp của các postback chiến thắng một cách độc lập với việc chuyển tiếp của mạng quảng cáo:

• Kiểm toán độc lập: Nhà phát triển nhận được bản sao chính xác của tất cả các postback chiến thắng được tạo cho ứng dụng của họ, cho phép xác thực nội bộ các báo cáo từ mạng quảng cáo.
• Đường dẫn điểm cuối chuyên biệt: Máy chủ của nhà phát triển phải lưu trữ điểm cuối tại https://<domain>/.well-known/skadnetwork/report-attribution/.
• Phân biệt AdAttributionKit: Đối với AdAttributionKit, Apple định nghĩa một cấu hình định tuyến riêng đến https://<domain>/.well-known/appattribution/report-attribution/, sử dụng kiến trúc xác minh Chữ ký Web JSON (JWS).

Cách các MMP tiếp nhận, tổng hợp và chuẩn hóa các luồng sự kiện S2S đa mạng

Tùy thuộc vào các tích hợp thương mại, Đối tác Đo lường Di động (MMP) có thể tiếp nhận dữ liệu SKAdNetwork thông qua chuyển tiếp phía nhà phát triển, tích hợp mạng quảng cáo hoặc các luồng máy chủ đối tác tùy chỉnh:

• Tiếp nhận đa nguồn: Tiếp nhận dữ liệu postback đã xác minh được chuyển tiếp từ các điểm cuối của nhà phát triển bên cạnh các luồng báo cáo trực tiếp từ mạng quảng cáo.
• Khử trùng lặp giữa các luồng: Chuẩn hóa và khử trùng lặp các bản ghi bằng cách sử dụng transaction-id duy nhất trên cả các bản sao từ mạng quảng cáo và nhà phát triển.
• Chuẩn hóa BI hạ nguồn: Ánh xạ các giá trị chuyển đổi thô và chi tiết vào các mô hình doanh thu và sự kiện phễu do khách hàng định nghĩa.

Xem thêm: SKAdNetwork ──> Mô hình phân bổ di động

Xác minh mật mã: Kiểm tra chữ ký ECDSA P-256 của Apple

Hiểu về ngăn xếp mật mã: Đường cong NIST P-256 (secp256r1) với SHA-256

Mỗi postback SKAdNetwork bao gồm trường attribution-signature. Chữ ký mật mã này được Apple tạo ra bằng cách sử dụng Thuật toán Chữ ký số Đường cong Elliptic (ECDSA) với đường cong NIST P-256 (secp256r1) và hàm băm SHA-256.

Chữ ký xác thực hai thuộc tính bảo mật cốt lõi:

• Tính xác thực: Postback được tạo trực tiếp bởi hệ thống con nền tảng của Apple trên một thiết bị đã được xác minh, không phải do một client hoặc proxy giả mạo.
• Tính toàn vẹn: Các tham số nằm trong phạm vi được ký không bị thay đổi trong quá trình truyền tải.

Sử dụng khóa công khai SKAdNetwork đã công bố của Apple

Để xác minh chữ ký, máy chủ tiếp nhận phải tải khóa công khai chính thức của Apple. Đối với SKAdNetwork 2.1 trở lên, Apple công bố một khóa công khai NIST P-256 chuyên dụng trong tài liệu dành cho nhà phát triển của mình:

• Khởi tạo khóa: Khóa công khai được tải vào bộ nhớ dưới dạng một đối tượng khóa công khai X.509/DER tiêu chuẩn trong quá trình khởi tạo máy chủ.
• Kiểm tra chữ ký bất đối xứng: Công cụ xác minh tái tạo chuỗi thông điệp được tuần tự hóa theo định dạng UTF-8 chính xác, tính toán giá trị băm SHA-256, và xác minh attribution-signature đã được giải mã Base64 với thông điệp được tái tạo.

[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]

Tại sao chỉ dùng hàm băm là không đủ: Xác minh chữ ký bất đối xứng

Vì Apple ký payload bằng khóa riêng tư của mình và không phân phối khóa bí mật chung, nên không thể sử dụng phương pháp xác minh đối xứng (chẳng hạn như HMAC-SHA256). Các công cụ nhận phải triển khai tính năng xác minh chữ ký khóa công khai bất đối xứng bằng các thư viện mật mã tiêu chuẩn (như OpenSSL, crypto của Node.js, hoặc cryptography của Python).

Xây dựng chuỗi thông điệp để xác minh chữ ký

Giao thức tuần tự hóa nghiêm ngặt: Vai trò của dấu phân cách ẩn (\u2063)

Apple chỉ định định dạng tuần tự hóa byte UTF-8 chính xác để xây dựng chuỗi thông điệp dùng cho việc xác minh chữ ký. Các tham số phải được nối theo một thứ tự chính xác, được phân tách bằng ký tự Unicode ẩn \u2063 (Dấu phân cách ẩn U+2063, chuỗi byte UTF-8 0xE2 0x81 0xA3):

Việc thay thế bằng khoảng trắng, dấu câu tiêu chuẩn hoặc các dấu phân cách Unicode khác sẽ dẫn đến lỗi xác minh mật mã.

Thứ tự tham số theo phiên bản dành cho SKAN 4.0

Theo Tài liệu dành cho nhà phát triển của Apple về cách xác minh postback xác thực lượt cài đặt, các tham số cho postback SKAdNetwork 4.0 phải được tuần tự hóa theo đúng thứ tự sau:

1. version (ví dụ: "4.0")
2. ad-network-id (ví dụ: "example123.skadnetwork")
3. source-identifier (ví dụ: "4821")
4. app-id (ví dụ: 1234567890)
5. transaction-id (ví dụ: "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d")
6. redownload (ví dụ: "true" hoặc "false" dưới dạng chuỗi viết thường)
7. source-app-id (đối với quảng cáo ứng dụng-đến-ứng dụng) HOẶC source-domain (đối với quảng cáo web-đến-ứng dụng trên Safari), chỉ bao gồm nếu có trong postback
8. fidelity-type (ví dụ: 1 đối với quảng cáo do StoreKit hiển thị hoặc quảng cáo web được phân bổ qua SKAdNetwork; 0 đối với quảng cáo xem trước - view-through ads)
9. did-win (ví dụ: "true" hoặc "false" dưới dạng chuỗi viết thường)
10. postback-sequence-index (ví dụ: 0, 1, hoặc 2)

Thông số kỹ thuật quan trọng của SKAN 4: Giá trị chuyển đổi bị loại khỏi chữ ký

Trong SKAdNetwork 4.0, chữ ký của Apple không bao gồm conversion-value hoặc coarse-conversion-value, ngay cả khi một trong các trường đó có mặt trong payload JSON. Chuỗi đã tuần tự hóa cho SKAN 4 kết thúc bằng postback-sequence-index. Việc cố gắng nối thêm các giá trị chuyển đổi vào chuỗi thông điệp sẽ làm cho quá trình xác minh thất bại.

Payload JSON dưới đây minh họa một lược đồ postback SKAdNetwork 4.0 hoàn chỉnh. Chữ ký bên dưới là một trình giữ chỗ mang tính minh họa và sẽ không vượt qua được quá trình xác minh mật mã; để kiểm thử đơn vị (unit testing), hãy sử dụng các ví dụ có chữ ký của Apple từ tài liệu xác minh chính thức:

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

Xử lý payload SKAN 4.0 đa cửa sổ và các điểm cuối của nhà phát triển

Phân tích postback-sequence-index qua các cửa sổ chuyển đổi tuần tự

Trong SKAdNetwork 4.0, các lượt chuyển đổi tạo ra postbacks từ các cửa sổ chuyển đổi kéo dài đến 35 ngày sau lần khởi chạy ứng dụng đầu tiên, với thời gian phân phối thực tế diễn ra sau khoảng thời gian trễ ngẫu nhiên của Apple. Các hệ thống nhận backend phân tích trường postback-sequence-index để gán dữ liệu chuyển đổi vào đúng cửa sổ vòng đời:

• Chỉ mục 0 (Cửa sổ 1: Ngày 0–2): Chứa giá trị chuyển đổi chi tiết (0–63) hoặc giá trị chuyển đổi thô (low, medium, high), hoặc trường này vắng mặt.
• Chỉ mục 1 (Cửa sổ 2: Ngày 3–7): Đối với các bậc dữ liệu postback 1–3, có thể tiết lộ coarse-conversion-value (low, medium, high) khi được cung cấp; bậc 0 không đủ điều kiện nhận postback thứ hai hoặc thứ ba.
• Chỉ mục 2 (Cửa sổ 3: Ngày 8–35): Đối với các bậc dữ liệu postback 1–3, có thể tiết lộ coarse-conversion-value (low, medium, high) khi được cung cấp; bậc 0 không đủ điều kiện nhận postback thứ hai hoặc thứ ba.

Quản lý giá trị chuyển đổi chi tiết so với thô

Trình giải mã tiếp nhận phải tính đến tính biến đổi của payload:

• Tính loại trừ lẫn nhau: Apple quy định rằng một postback xác thực lượt cài đặt có thể chứa hoặc conversion-value hoặc coarse-conversion-value, nhưng không bao giờ chứa cả hai cùng lúc.
• Không có giá trị chuyển đổi: Nếu bậc dữ liệu postback được chỉ định là thấp (Bậc 0), các trường giá trị chuyển đổi sẽ bị lược bỏ khỏi payload JSON.

Phòng chống các cuộc tấn công phát lại (Replay Attacks) và Payload chuyển đổi giả mạo

Vai trò của transaction-id như một khóa khử trùng lặp

Mỗi postback SKAdNetwork chứa một UUID transaction-id duy nhất. Tài liệu của Apple khuyên người nhận nên sử dụng định danh này làm khóa bất biến để phát hiện và loại bỏ các postback chuyển đổi trùng lặp.

Vì các bộ lắng nghe postback là các điểm cuối HTTPS có thể truy cập công khai, các tác nhân độc hại có thể thực hiện các cuộc tấn công phát lại bằng cách chụp lại một postback hợp lệ và gửi lại nhiều lần để thổi phồng các chỉ số chuyển đổi một cách giả tạo.

Triển khai bộ nhớ đệm trong bộ nhớ phân tán và sổ cái bền vững

Apple không quy định thời gian lưu giữ khử trùng lặp phổ biến. Các hệ thống nhận vận hành nên duy trì một bản ghi tính bất biến bền vững cho các ID giao dịch đã xác minh theo yêu cầu đối chiếu và phòng chống phát lại của họ; Redis TTL có thể được sử dụng như một giải pháp tối ưu hóa bộ nhớ đệm nóng (hot-cache) thay vì là sổ cái trùng lặp có thẩm quyền duy nhất:

1. Xác minh mật mã trước tiên: Xác minh hoàn toàn chữ ký ECDSA với khóa công khai của Apple trước khi ghi ID giao dịch vào bộ nhớ.
2. Khử trùng lặp nguyên tử: Thực hiện thao tác ghi nguyên tử (ví dụ: Redis SET key value NX EX <seconds>) được hỗ trợ bởi một ràng buộc duy nhất trong cơ sở dữ liệu quan hệ hoặc tài liệu bền vững.
3. Phạm vi khử trùng lặp: Thiết lập một khoảng thời gian lưu trữ vận hành trong lớp bộ nhớ đệm bao gồm thời gian phân phối postback dự kiến, thời gian thử lại mạng (Apple thử lại các lần phân phối thất bại trong tối đa 9 ngày) và quá trình đối chiếu hạ nguồn.

Việc triển khai backend dưới đây minh họa tính năng xác minh chữ ký, xác minh lược đồ và khử trùng lặp nguyên tử bằng 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"]
    }

Nhập Postback vào các mô hình đấu giá thời gian thực và công cụ tối ưu hóa CPA

Tách biệt quá trình tiếp nhận ở biên (Edge Ingestion) khỏi quá trình xử lý bất đồng bộ

Các DSP lưu lượng lớn xử lý khối lượng postback đáng kể trong các giai đoạn chiến dịch cao điểm. Quá trình xử lý hạ nguồn đồng bộ có thể tạo ra các điểm nghẽn về độ trễ.

Kiến trúc doanh nghiệp triển khai một đường ống bất đồng bộ:

1. Bộ thu biên (Edge Receiver): Chấp nhận HTTP POST đến, xác minh tính chân thực của chữ ký, thực hiện khử trùng lặp nguyên tử trên transaction-id và ngay lập tức trả về HTTP 200 OK.
2. Hàng đợi sự kiện (Event Queue): Xuất bản payload đã xác minh lên một trình môi giới sự kiện phân tán (ví dụ: Apache Kafka hoặc AWS SQS).
3. Worker Đấu giá & Phân tích: Tiêu thụ luồng sự kiện, ánh xạ các giá trị chuyển đổi thành các chỉ số doanh thu và cập nhật các mô hình CPA mục tiêu trong Đấu giá thời gian thực (RTB).

Sử dụng Định danh nguồn phân cấp (Hierarchical Source Identifier)

Postback chiến thắng đầu tiên có thể để lộ hai, ba hoặc bốn chữ số của source-identifier phân cấp, tùy thuộc vào bậc dữ liệu postback. Ý nghĩa ngữ nghĩa của các chữ số đó được định nghĩa bởi chính phân loại định danh nguồn của mạng quảng cáo. Các hệ thống đấu giá nên phân giải định danh nguồn nhận được dựa trên siêu dữ liệu chiến dịch của riêng mạng thay vì giả định một phép ánh xạ phổ quát giữa độ dài chữ số và vị trí đặt quảng cáo hoặc độ chi tiết của nội dung sáng tạo cụ thể.

Ma trận so sánh: Phân phối trực tiếp của Apple so với Tiếp nhận S2S của MMP

Tóm tắt và Khung quyết định

Xử lý postback SKAdNetwork ở quy mô lớn đòi hỏi sự kết hợp giữa tiếp nhận ở biên có độ trễ thấp với việc xác minh mật mã nghiêm ngặt và khử trùng lặp ở cấp độ giao dịch. Vì postback của Apple ảnh hưởng trực tiếp đến việc phân bổ ngân sách và các thuật toán đấu giá, việc xác minh chữ ký ECDSA và thực thi tính bất biến của transaction-id giúp bảo vệ các đường ống tiếp nhận khỏi các postback bị giả mạo, can thiệp hoặc xử lý phát lại trùng lặp.

Để bổ sung cho báo cáo SKAdNetwork qua trung gian nền tảng bằng tính năng giới thiệu người dùng ở cấp độ vi mô và định tuyến deep link tức thì, các đội ngũ kỹ thuật triển khai các kiến trúc định tuyến bên thứ nhất song song với các API của nền tảng.

Để tìm hiểu thêm về việc cấu hình postback phân bổ phía máy chủ và đường ống deep link, hãy xem lại tài liệu OpoInstall.

Tài liệu liên quan

• Khái niệm: Postback S2S, Xác minh mật mã, ECDSA P-256, Phòng chống tấn công phát lại, Khử trùng lặp giao dịch

• Công nghệ: Apple SKAdNetwork, Apple AdAttributionKit, Bộ nhớ đệm trong bộ nhớ Redis, SDK di động OpoInstall

• Tiêu chuẩn: IETF RFC 8259 (Trao đổi dữ liệu JSON), RFC 5480 (Mật mã đường cong Elliptic)

• API: API StoreKit SKAdNetwork, Đặc tả phân phối Postback S2S của Apple, API S2S của OpoInstall

Tài liệu chính thức

• Tài liệu dành cho nhà phát triển Apple về cách xác minh postback xác thực lượt cài đặt

• Tài liệu dành cho nhà phát triển Apple về việc xác định các tham số trong postback xác thực lượt cài đặt

• Tài liệu dành cho nhà phát triển Apple về cách cấu hình một ứng dụng được quảng cáo

• Tài liệu dành cho nhà phát triển Apple về SKAdNetwork

• Tài liệu dành cho nhà phát triển Apple về AdAttributionKit