workflows SKAdNetwork S2S: كيفية التحقق من إشعارات شبكات الإعلانات

كيف تتعامل منصات جانب الطلب (DSPs) مع إشعارات SKAdNetwork؟ تتعامل منصات جانب الطلب (DSPs) وشبكات الإعلانات مع إشعارات SKAdNetwork من خلال إنشاء نقاط نهاية آمنة لتلقي طلبات HTTP POST، وتكوين سلسلة رسائل UTF-8 المُسلسلة باستخدام فاصل U+2063، والتحقق من توقيع ECDSA P-256 المشفر الخاص بشركة Apple مقابل المفتاح العام المنشور لـ Apple، وتجهيز معرّفات المعاملات التي تم التحقق منها لمنع المعالجة المزدوجة قبل تحديث نماذج المزايدة.

إشعار التحقق من التثبيت في SKAdNetwork هو إشعار HTTPS POST موقع من Apple يرسله نظام التشغيل إلى شبكة إعلانات مؤهلة، وبالنسبة للإسنادات الفائزة، يرسل اختياريًا إلى نقطة نهاية النسخ المكوّنة لمطور التطبيق المُعلن عنه. لضمان سلامة البيانات، يجب أن تقوم أنظمة تلقي الواجهة الخلفية بالتحقق من توقيع ECDSA P-256 التابع لـ Apple، والتحقق من تسلسل المعلمات، وفرض إلغاء التكرار على مستوى المعاملة.

بنية تلقي إشعارات SKAdNetwork لمنصات جانب الطلب (DSPs) وشبكات الإعلانات

خط أنابيب التلقي المزدوج: التسليم المباشر لشبكة الإعلانات مقابل نقاط نهاية إشعارات المطورين

عند حدوث تثبيت لتطبيق iOS مُسند، يقوم نظام الإسناد الفرعي في Apple بإرسال إشعارات التحقق من التثبيت عبر بروتوكول HTTPS POST:

• تلقي شبكة الإعلانات: يقوم الجهاز بتسليم إشعار الفوز الأساسي (did-win: true) مباشرة إلى عنوان URL الخاص الخادم المسجل تحت ad-network-id المقابل في سجل Apple.
• تلقي نسخة المطور: إذا حدد التطبيق المعلن عنه مفتاح NSAdvertisingAttributionReportEndpoint في ملف Info.plist الخاص به، يقوم الجهاز في نفس الوقت بإرسال نسخة مطابقة تمامًا لإشعار الفوز مباشرة إلى خادم المطور.
• توجيه الإشعارات غير الفائزة: بدءًا من SKAdNetwork 3.0، إذا كانت شبكات إعلانات متعددة مؤهلة للاستناد ولكنها لم تفز، يرسل الجهاز ما يصل إلى خمسة إشعارات غير فائزة (did-win: false) مباشرة إلى شبكات الإعلانات الثانوية المؤهلة تلك. لا يتم تسليم الإشعارات غير الفائزة إلى نقطة نهاية نسخة المطور.

يجب أن تستجيب نقاط نهاية التلقي الخلفية برمز HTTP 200 OK. إذا لم يتلق الجهاز استجابة برمز 200، فقد يعيد محاولة التسليم حتى تسع مرات على مدار تسعة أيام كحد أقصى.

دور NSAdvertisingAttributionReportEndpoint في تدقيق المطورين

يمكّن مفتاح NSAdvertisingAttributionReportEndpoint مطوري التطبيقات من تلقي نسخ مباشرة من إشعارات الفوز بشكل مستقل عن إعادة توجيه شبكة الإعلانات:

• التدقيق المستقل: يتلقى المطورون نسخًا مطابقة تمامًا لجميع إشعارات الفوز المُنشأة لتطبيقهم، مما يتيح التحقق الداخلي من تقارير شبكات الإعلانات.
• مسار نقطة النهاية المخصصة: يجب أن يستضيف خادم المطور نقطة النهاية على الرابط https://<domain>/.well-known/skadnetwork/report-attribution/.
• التمييز عن AdAttributionKit: بالنسبة لـ AdAttributionKit، تحدد Apple تكوينًا منفصلاً يوجه إلى https://<domain>/.well-known/appattribution/report-attribution/، والذي يستفيد من بنية تحقق تعتمد على توقيع ويب JSON (JWS).

كيف تتلقى شركاء القياس الجوال (MMPs) وتدمج وتطبيع تدفقات أحداث S2S متعددة الشبكات

اعتمادًا على عمليات التكامل التجاري، قد تتلقى شركاء القياس الجوال (MMPs) بيانات SKAdNetwork من خلال إعادة التوجيه من جهة المطور، أو عمليات إ التكامل مع شبكات الإعلانات، أو تدفقات خوادم الشركاء المخصصة:

• التلقي من مصادر متعددة: تلقي بيانات الإشعارات التي تم التحقق منها والمُعاد توجيهها من نقاط نهاية المطورين جنبًا إلى جنب مع تدفقات تقارير شبكات الإعلانات المباشرة.
• إلغاء التكرار عبر التدفقات: تطبيع السجلات وإلغاء تكرارها باستخدام معرّف المعاملة الفريد transaction-id عبر شبكات الإعلانات المشتركة ونسخ المطورين.
• تطبيع ذكاء الأعمال (BI) في المراحل اللاحقة: تعيين قيم التحويل الإجمالية والمفصلة وفقًا لنماذج الإيرادات وأحداث مسار التحويل المحددة من قبل العميل.

راجع أيضاً: SKAdNetwork ──> نموذج إسناد الأجهزة المحمولة

التحقق التشفيري: التحقق من توقيع ECDSA P-256 الخاص بـ Apple

فهم حزم التشفير: منحنى NIST P-256 (secp256r1) مع SHA-256

يتضمن كل إشعار من إشعارات SKAdNetwork حقل attribution-signature. يتم إنشاء هذا التوقيع التشفيري بواسطة Apple باستخدام خوارزمية توقيع المنحنى الإهليلجي الرقمي (ECDSA) مع منحنى NIST P-256 (secp256r1) وخلاصة SHA-256.

يتحقق التوقيع من خاصيتين أساسيتين للأمان:

• الأصالة: تم إنشاء الإشعار مباشرة بواسطة النظام الفرعي لمنصة Apple على جهاز تم التحقق منه، وليس مزورًا بواسطة عميل ضار أو وسيط.
• النزاهة: لم يتم تغيير المعلمات التي يغطيها التوقيع أثناء النقل.

استخدام المفتاح العام الرسمي لـ SKAdNetwork من Apple

لتحقق التوقيع، يجب على خادم التلقي تحميل المفتاح العام الرسمي لـ Apple. بالنسبة لـ SKAdNetwork 2.1 والأحدث، تنشر Apple مفتاحًا عامًا مخصصًا لـ NIST P-256 في وثائق المطورين الخاصة بها:

• تهيئة المفتاح: يتم تحميل المفتاح العام في الذاكرة ككائن مفتاح عام قياسي X.509/DER أثناء تهيئة الخادم.
• فحص التوقيع غير المتماثل: يقوم محرك التحقق بإعادة بناء سلسلة رسائل UTF-8 المُسلسلة بدقة، وحساب تجزئة SHA-256، والتحقق من توقيع attribution-signature المفكوك التشفير بترميز Base64 مقابل الرسالة المُعاد بناؤها.

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

لماذا تكون التجزئة وحدها غير كافية: التحقق من التوقيع غير المتماثل

نظرًا لأن Apple تقوم بتوقيع الحمولة باستخدام مفتاحها الخاص ولا توزع سرًا مشتركًا، فلا يمكن استخدام التحقق المتماثل (مثل HMAC-SHA256). يجب على محركات التلقي تنفيذ التحقق القياسي غير المتماثل لمفاتيح التوقيع العامة باستخدام مكتبات تشفير قياسية (مثل OpenSSL أو crypto في Node.js أو cryptography في Python).

إنشاء سلسلة الرسائل للتحقق من التوقيع

بروتوكول التسلسل الصارم: دور الفاصل غير المرئي (\u2063)

تحدد Apple تنسيق تسلسل بايت UTF-8 دقيق لإنشاء سلسلة الرسائل للتحقق من التوقيع. يجب دمج المعلمات بترتيب دقيق، مفصولة بحرف يونيكود غير المرئي \u2063 (فاصل غير مرئي U+2063، تسلسل بايتات UTF-8 0xE2 0x81 0xA3):

سيؤدي استبدال المسافات البيضاء أو علامات الترقيم القياسية أو فواصل اليونيكود البديلة إلى فشل التحقق التشفيري.

ترتيب المعلمات الخاص بإصدار SKAN 4.0

وفقًا لـ وثائق مطوري Apple حول التحقق من إشعار التحقق من التثبيت، يجب تسلسل معلمات إشعارات SKAdNetwork 4.0 بالترتيب الدقيق التالي:

1. version (على سبيل المثال، "4.0")
2. ad-network-id (على سبيل المثال، "example123.skadnetwork")
3. source-identifier (على سبيل المثال، "4821")
4. app-id (على سبيل المثال، 1234567890)
5. transaction-id (على سبيل المثال، "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d")
6. redownload (على سبيل المثال، "true" أو "false" كسلسلة نصية بحروف صغيرة)
7. source-app-id (لإعلانات التطبيق إلى التطبيق) أو source-domain (لإعلانات الويب إلى التطبيق في متصفح Safari)، ويتم تضمينه فقط إذا كان موجودًا في الإشعار
8. fidelity-type (على سبيل المثال، 1 للإعلانات المعروضة عبر StoreKit أو إعلانات الويب المُسندة إلى SKAdNetwork؛ 0 للإعلانات عبر المشاهدة)
9. did-win (على سبيل المثال، "true" أو "false" كسلسلة نصية بحروف صغيرة)
10. postback-sequence-index (على سبيل المثال، 0 أو 1 أو 2)

مواصفات SKAN 4 الهامة: استبعاد قيم التحويل من التوقيع

في SKAdNetwork 4.0، توقيع Apple لا يتضمن conversion-value أو coarse-conversion-value، حتى لو كان أحد هذين الحقلين موجودًا في حمولة JSON. تنتهي سلسلة التسلسل لـ SKAN 4 بحقل postback-sequence-index. سيؤدي محاولة إلحاق قيم التحويل بسلسلة الرسائل إلى فشل التحقق.

توضح حمولة JSON أدناه مخطط إشعار SKAdNetwork 4.0 مكتمل. التوقيع أدناه هو عنصر نائب توضيحي ولن ينجح في التحقق التشفيري؛ للاختبار المبدئي، استخدم أمثلة Apple الموقعة من وثائق التحقق الرسمية:

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

التعامل مع حمولات SKAN 4.0 متعددة النوافذ ونقاط نهاية المطورين

تحليل مؤشر تسلسل الإشعارات (postback-sequence-index) عبر نوافذ التحويل المتتالية

في SKAdNetwork 4.0، تولد التحويلات إشعارات من نوافذ تحويل تمتد حتى 35 يومًا بعد التشغيل الأول للتطبيق، مع حدوث التسليم الفعلي بعد تأخيرات ما بعد النافذة العشوائية الخاصة بـ Apple. تقوم أنظمة التلقي في الواجهة الخلفية بتحليل حقل postback-sequence-index لتعيين بيانات التحويل إلى نافذة دورة الحياة الصحيحة:

• المؤشر 0 (النافذة 1: اليوم 0–2): يحتوي إما على قيمة تحويل دقيقة (0–63) أو قيمة تحويل إجمالية (low أو medium أو high)، أو يكون الحقل غائبًا.
• المؤشر 1 (النافذة 2: اليوم 3–7): بالنسبة لمستويات بيانات الإشعار 1–3، قد يفصح عن قيمة تحويل إجمالية (coarse-conversion-value) (low أو medium أو high) عند توفرها؛ ولا يكون المستوى 0 مؤهلاً للحصول على الإشعارات الثانية أو الثالثة.
• المؤشر 2 (النافذة 3: اليوم 8–35): بالنسبة لمستويات بيانات الإشعار 1–3، قد يفصح عن قيمة تحويل إجمالية (coarse-conversion-value) (low أو medium أو high) عند توفرها؛ ولا يكون المستوى 0 مؤهلاً للحصول على الإشعارات الثانية أو الثالثة.

إدارة قيم التحويل الدقيقة مقابل الإجمالية

يجب أن تأخذ فواكه فك التشفير في الاعتبار تباين الحمولة:

الحصرية المتبادلة: تحدد Apple أن إشعار التحقق من التثبيت قد يحتوي إما على conversion-value أو coarse-conversion-value، ولكن ليس كلاهما في نفس الوقت أبدًا.
• قيم التحويل الغائبة: إذا كان مستوى بيانات الإشعار المُعيّن منخفضًا (المستوى 0)، يتم حذف حقول قيمة التحويل من حمولة JSON.

الحماية ضد هجمات الإعادة وحمولات التحويل المزيفة

دور معرّف المعاملة (transaction-id) كمفتاح لإلغاء التكرار

يحتوي كل إشعار SKAdNetwork على معرّف فريد UUID من نوع transaction-id. تنصح وثائق Apple الجهات المستقبلة باستخدام هذا المعرّف كمفتاح عدم تأثر (idempotency key) لاكتشاف والتخلص من إشعارات التحويل المكررة.

نظرًا لأن مستمعي الإشعارات هم نقاط نهاية HTTPS متاحة للعامة، يمكن للجهات الضارة محاولة شن هجمات إعادة عن طريق التقاط إشعار صحيح وإعادة إرساله بشكل متكرر لتضخيم مقاييس التحويل بشكل مصطنع.

تنفيذ التخزين المؤقت الموزع في الذاكرة وسجلات الدفاتر المستمرة

لا تفرض Apple فترة احتفاظ عالمية لإلغاء التكرار. يجب على الجهات المستقبلة في بيئة الإنتاج الاحتفاظ بسجل عدم تأثر دائم لمعرّفات المعاملات التي تم التحقق منها وفقًا لمتطلبات التسوية والدفاع ضد الإعادة؛ ويمكن استخدام التخزين المؤقت السريع لـ Redis كتحسين للتخزين المؤقت السريع بدلاً من اعتباره سجل التكرار الموثوق الوحيد:

1. التحقق التشفيري أولاً: التحقق الكامل من توقيع ECDSA مقابل المفتاح العام لـ Apple قبل حفظ معرّف المعاملة في التخزين.
2. إلغاء التكرار الذري: إجراء عملية كتابة ذرية (مثل أمر Redis SET key value NX EX <seconds>) مدعومة بقيد فريد لقاعدة بيانات علائقية أو مستندات دائمة.
3. أفق إلغاء التكرار: تعيين نافذة احتفاظ تشغيلية في طبقة الذاكرة المؤقتة تغطي تسليم الإشعارات المتوقع، وإعادة محاولات الشبكة (تعيد Apple محاولة التسليم الفاشل لمدة تصل إلى 9 أيام)، والتسوية اللاحقة.

يوضح تنفيذ الواجهة الخلفية أدناه التحقق من التوقيع، والتحقق من المخطط، وإلغاء التكرار الذري باستخدام لغة 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"]
    }

تلقي الإشعارات في نماذج المزايدة في الوقت الفعلي ومُحسّنات تكلفة الإجراء (CPA)

فصل التلقي على الحافة عن المعالجة غير المتزامنة

تعالج منصات جانب الطلب (DSPs) ذات الحجم الكبير كميات كبيرة من الإشعارات أثناء فترات الحملات الذروة. يمكن أن تؤدي المعالجة المتزامنة في المراحل اللاحقة إلى حدوث اختناقات في وقت الاستجابة.

تنفذ بنيات المؤسسات خط أنابيب غير متزامن:

1. مستقبل الحافة: يقبل طلب HTTP POST القادم، ويتحقق من أصالة التوقيع، وينفذ إلغاء التكرار الذري على transaction-id، ويعيد فورًا استجابة HTTP 200 OK.
2. قناة الأحداث: تنشر الحمولة التي تم التحقق منها إلى وسيط أحداث موزّع (مثل Apache Kafka أو AWS SQS).
3. عاملوا المزايدة والتحليلات: يستهلكون تدفق الأحداث، ويوجهون قيم التحويل إلى مقاييس الإيرادات، ويحدثون نماذج تكلفة الإجراء المستهدفة للمزايدة في الوقت الفعلي (RTB).

استخدام معرّف المصدر الهرمي

قد يكشف إشعار الفوز الأول عن رقمين أو ثلاثة أو أربعة أرقام من source-identifier الهرمي، اعتمادًا على مستوى بيانات الإشعار. يتم تحديد المعنى الدلالي لتلك الأرقام بواسطة تصنيف معرّف المصدر الخاص بشبكة الإعلانات نفسها. يجب أن تقوم أنظمة المزايدة بمطابقة معرّف المصدر المستلم مع البيانات التعريفية للحملة الخاصة بالشبكة بدلاً من افتراض وجود تعيين عالمي بين طول الأرقام وموضع معين أو تفاصيل الإبداع.

مصفوفة المقارنة: التسليم المباشر من Apple مقابل تلقي S2S عبر شركاء القياس الجوال (MMP)

الملخص وإطار القرار

يتطلب التعامل مع إشعارات SKAdNetwork على نطاق واسع الجمع بين تلقي الحافة منخفض زمن الانتقال والتحقق التشفيري الصارم وإلغاء التكرار على مستوى المعاملة. نظرًا لأن إشعارات Apple تؤثر بشكل مباشر على تخصيص الميزانية وخوارزميات المزايدة، فإن التحقق من توقيعات ECDSA وفرض عدم التأثر لمعرّف المعاملة transaction-id يحمي خطوط أنابيب التلقي من الإشعارات المزيفة أو المتلاعب بها ومن معالجة الإعادة المكررة.

لاستكمال تقارير SKAdNetwork التي بوساطة المنصة مع تهيئة المستخدم على المستوى الدقيق وتوجيه الروابط العميقة الفوري، تنشر فرق الهندسة بنيات توجيه الطرف الأول جنباً إلى جنب مع واجهات برمجة التطبيقات للمنصة.

لمعرفة المزيد حول تكوين إشعارات إسناد جانب الخادم وخطوط أنابيب الروابط العميقة، راجع وثائق OpoInstall.

المواد ذات الصلة

• المفاهيم: إشعارات S2S، التحقق التشفيري، ECDSA P-256، الدفاع ضد هجمات الإعادة، إلغاء تكرار المعاملات

• التقنيات: Apple SKAdNetwork، وApple AdAttributionKit، والتخزين المؤقت في الذاكرة Redis، ومجموعة تطوير البرامج للجوال OpoInstall Mobile SDK

• المعايير: IETF RFC 8259 (تبادل بيانات JSON)، وRFC 5480 (تشفير المنحنى الإهليلجي)

• واجهات برمجة التطبيقات (APIs): StoreKit SKAdNetwork API، ومواصفات تسليم إشعارات S2S من Apple، وOpoInstall S2S API

الوثائق الرسمية

• وثائق مطوري Apple حول التحقق من إشعار التحقق من التثبيت

• وثائق مطوري Apple حول تحديد المعلمات في إشعارات التحقق من التثبيت

• وثائق مطوري Apple حول تكوين تطبيق مُعلن عنه

• وثائق مطوري Apple حول SKAdNetwork

• وثائق مطوري Apple حول AdAttributionKit