SKAdNetwork S2S वर्कफ़्लो: विज्ञापन नेटवर्क पोस्टबैक को कैसे सत्यापित करें

DSPs SKAdNetwork पोस्टबैक को कैसे संभालते हैं? डिमांड-साइड प्लेटफॉर्म (DSPs) और विज्ञापन नेटवर्क, सुरक्षित HTTP POST इनजेशन एंडपॉइंट्स स्थापित करके, U+2063 डिलीमीटर का उपयोग करके सीरियलाइज़्ड UTF-8 संदेश स्ट्रिंग का निर्माण करके, Apple के प्रकाशित सार्वजनिक कुंजी के मुकाबले Apple के क्रिप्टोग्राफिक ECDSA P-256 हस्ताक्षर को सत्यापित करके, और बिडिंग मॉडल को अपडेट करने से पहले डुप्लीकेट प्रोसेसिंग को रोकने के लिए सत्यापित ट्रांजैक्शन आईडी को रिकॉर्ड करके SKAdNetwork पोस्टबैक को संभालते हैं।

एक SKAdNetwork इंस्टॉल-वैलिडेशन पोस्टबैक Apple द्वारा हस्ताक्षरित HTTPS POST सूचना है जिसे ऑपरेटिंग सिस्टम एक योग्य विज्ञापन नेटवर्क को और, जीतने वाले एट्रिब्यूशन के लिए, वैकल्पिक रूप से विज्ञापित ऐप डेवलपर के कॉन्फ़िगर किए गए कॉपी एंडपॉइंट को भेजता है। डेटा की अखंडता सुनिश्चित करने के लिए, बैकएंड इनजेशन सिस्टम को Apple के ECDSA P-256 हस्ताक्षर को सत्यापित करना चाहिए, पैरामीटर सिरीलाइज़ेशन को मान्य करना चाहिए, और ट्रांजैक्शन-स्तरीय डुप्लीकेशन नियंत्रण लागू करना चाहिए।

शब्द	परिभाषा
SKAdNetwork	गोपनीयता-संरक्षण विज्ञापन अभियान एट्रिब्यूशन के लिए Apple का प्लेटफ़ॉर्म-स्तरीय फ्रेमवर्क।
इंस्टॉल-वैलिडेशन पोस्टबैक	योग्य विज्ञापन रूपांतरण के बाद इंस्टॉल-वैलिडेशन और एट्रिब्यूशन मेटाडेटा युक्त Apple द्वारा हस्ताक्षरित JSON पेलोड।
ECDSA P-256	इंस्टॉल-वैलिडेशन पोस्टबैक पर हस्ताक्षर करने के लिए Apple द्वारा उपयोग किया जाने वाला इलिप्टिक कर्व क्रिप्टोग्राफिक एल्गोरिदम।
ट्रांजैक्शन आईडी	एक अनूठी सत्यापन पहचानकर्ता जिसका उपयोग रिसीवर डुप्लीकेट पहचान के लिए आइडपोटेंसी कुंजी के रूप में करते हैं।

DSPs और विज्ञापन नेटवर्क के लिए SKAdNetwork पोस्टबैक इनजेशन की वास्तुकला

डुअल इनजेशन पाइपलाइन: प्रत्यक्ष विज्ञापन नेटवर्क डिलीवरी बनाम डेवलपर पोस्टबैक एंडपॉइंट्स

जब किसी एट्रिब्यूटेड iOS एप्लिकेशन का इंस्टॉल होता है, तो Apple का एट्रिब्यूशन सबसिस्टम HTTPS POST के माध्यम से इंस्टॉल-वैलिडेशन पोस्टबैक प्रेषित करता है:

विज्ञापन नेटवर्क इनजेशन: डिवाइस प्राथमिक विजयी पोस्टबैक (did-win: true) को सीधे Apple की रजिस्ट्री में संबंधित ad-network-id के तहत पंजीकृत सर्वर URL पर डिलीवर करता है।
डेवलपर कॉपी इनजेशन: यदि विज्ञापित ऐप अपने Info.plist में NSAdvertisingAttributionReportEndpoint कुंजी निर्दिष्ट करता है, तो डिवाइस समवर्ती रूप से विजयी पोस्टबैक की एक सटीक प्रति सीधे डेवलपर के सर्वर पर प्रेषित करता है।
नॉनविनिंग पोस्टबैक रूटिंग: SKAdNetwork 3.0 से शुरू करते हुए, यदि कई विज्ञापन नेटवर्क एट्रिब्यूशन के लिए योग्य थे लेकिन जीते नहीं, तो डिवाइस उन माध्यमिक योग्य विज्ञापन नेटवर्क को सीधे पांच नॉनविनिंग पोस्टबैक (did-win: false) तक भेजता है। नॉनविनिंग पोस्टबैक डेवलपर कॉपी एंडपॉइंट पर डिलीवर नहीं किए जाते हैं।

बैकएंड इनजेशन एंडपॉइंट्स को HTTP 200 OK के साथ प्रतिक्रिया देनी चाहिए। यदि डिवाइस को 200 प्रतिक्रिया प्राप्त नहीं होती है, तो यह अधिकतम नौ दिनों में नौ बार तक डिलीवरी का पुनः प्रयास कर सकता है।

SKAdNetwork पोस्टबैक इनजेशन और सत्यापन वर्कफ़्लो

डेवलपर ऑडिटिंग में 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 ──> मोबाइल एट्रिब्यूशन मॉडल

क्रिप्टोग्राफिक सत्यापन: Apple के ECDSA P-256 हस्ताक्षर को मान्य करना

क्रिप्टोग्राफिक स्टैक को समझना: SHA-256 के साथ NIST कर्व P-256 (secp256r1)

प्रत्येक SKAdNetwork पोस्टबैक में एक attribution-signature फ़ील्ड शामिल होता है। यह क्रिप्टोग्राफिक हस्ताक्षर Apple द्वारा NIST P-256 (secp256r1) कर्व और SHA-256 डाइजेस्ट के साथ इलिप्टिक कर्व डिजिटल सिग्नेचर एल्गोरिदम (ECDSA) का उपयोग करके उत्पन्न किया जाता है।

हस्ताक्षर दो बुनियादी सुरक्षा गुणों को मान्य करता है:

प्रामाणिकता: पोस्टबैक किसी विरोधी क्लाइंट या प्रॉक्सी द्वारा偽造 नहीं किया गया था, बल्कि एक सत्यापित डिवाइस पर सीधे Apple के प्लेटफ़ॉर्म सबसिस्टम द्वारा उत्पन्न किया गया था।
अखंडता: हस्ताक्षर द्वारा कवर किए गए पैरामीटर पारगमन में बदले नहीं गए हैं।

Apple की प्रकाशित SKAdNetwork सार्वजनिक कुंजी का उपयोग करना

हस्ताक्षर को सत्यापित करने के लिए, इनजेशन सर्वर को Apple की आधिकारिक सार्वजनिक कुंजी लोड करनी होगी। SKAdNetwork 2.1 और बाद के संस्करणों के लिए, Apple अपने डेवलपर दस्तावेज़ में एक समर्पित NIST P-256 सार्वजनिक कुंजी प्रकाशित करता है:

कुंजी आरंभीकरण: सर्वर आरंभीकरण के दौरान सार्वजनिक कुंजी को मानक X.509/DER सार्वजनिक कुंजी ऑब्जेक्ट के रूप में मेमोरी में लोड किया जाता है।
असममित हस्ताक्षर जांच: सत्यापन इंजन सटीक UTF-8 सीरियलाइज़्ड संदेश स्ट्रिंग का पुनर्निर्माण करता है, SHA-256 हैश की गणना करता है, और पुनर्निर्माण किए गए संदेश के विरुद्ध Base64-डिकोड किए गए attribution-signature को सत्यापित करता है।

[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, Node.js crypto, या Python cryptography) का उपयोग करके मानक असममित सार्वजनिक-कुंजी हस्ताक्षर सत्यापन लागू करना होगा।

हस्ताक्षर सत्यापन के लिए संदेश स्ट्रिंग का निर्माण

सख्त सिरीलाइज़ेशन प्रोटोकॉल: अदृश्य विभाजक (\u2063) की भूमिका

Apple हस्ताक्षर सत्यापन के लिए संदेश स्ट्रिंग का निर्माण करने के लिए एक सटीक UTF-8 बाइट सिरीलाइज़ेशन प्रारूप निर्दिष्ट करता है। मापदंडों को एक सटीक क्रम में संयोजित किया जाना चाहिए, जो अदृश्य यूनिकोड वर्ण \u2063 (U+2063 इनविजिबल सेपरेटर, UTF-8 बाइट अनुक्रम 0xE2 0x81 0xA3) द्वारा अलग किया गया हो:

\text{Message} = \text{Param}_1 \;\|\; \text{"\u2063"} \;\|\; \text{Param}_2 \;\|\; \text{"\u2063"} \dots \|\; \text{Param}_n

व्हाइटस्पेस, मानक विराम चिह्न, या वैकल्पिक यूनिकोड विभाजकों को प्रतिस्थापित करने से क्रिप्टोग्राफिक सत्यापन विफलता होगी।

SKAN 4.0 के लिए संस्करण-विशिष्ट पैरामीटर क्रम

इंस्टॉल-वैलिडेशन पोस्टबैक को सत्यापित करने पर Apple डेवलपर दस्तावेज़ के अनुसार, SKAdNetwork 4.0 पोस्टबैक के लिए मापदंडों को निम्नलिखित सटीक क्रम में सीरियलाइज़ किया जाना चाहिए:

version (उदा. "4.0")
ad-network-id (उदा. "example123.skadnetwork")
source-identifier (उदा. "4821")
app-id (उदा. 1234567890)
transaction-id (उदा. "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d")
redownload (लोअरकेस स्ट्रिंग के रूप में उदा. "true" या "false")
source-app-id (ऐप-टू-ऐप विज्ञापनों के लिए) या source-domain (सफारी में वेब-टू-ऐप विज्ञापनों के लिए), केवल तभी शामिल किया जाता है जब पोस्टबैक में मौजूद हो
fidelity-type (उदा. StoreKit-रेंडर किए गए विज्ञापनों या SKAdNetwork-एट्रिब्यूटेड वेब विज्ञापनों के लिए 1; व्यू-थ्रू विज्ञापनों के लिए 0)
did-win (लोअरकेस स्ट्रिंग के रूप में उदा. "true" या "false")
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 पोस्टबैक में एक अद्वितीय transaction-id UUID होता है। Apple दस्तावेज़ रिसीवदों को डुप्लिकेट रूपांतरण पोस्टबैक का पता लगाने और उन्हें त्यागने के लिए इस पहचानकर्ता को आइडपोटेंसी कुंजी के रूप में उपयोग करने की सलाह देते हैं।

चूंकि पोस्टबैक लिसनर सार्वजनिक रूप से पहुंच योग्य HTTPS एंडपॉइंट हैं, इसलिए दुर्भावनापूर्ण अभिनेता रूपांतरण मेट्रिक्स को कृत्रिम रूप से बढ़ाने के लिए वैध पोस्टबैक को कैप्चर करके और बार-बार सबमिट करके रिप्ले हमलों का प्रयास कर सकते हैं।

वितरित इन-मेमोरी कैशिंग और लगातार लेजर लागू करना

Apple एक सार्वभौमिक डुप्लीकेशन प्रतिधारण अवधि निर्धारित नहीं करता है। उत्पादन रिसीवदों को अपनी सुलह और रिप्ले-डिफेंस आवश्यकताओं के अनुसार सत्यापित ट्रांजैक्शन आईडी के लिए एक टिकाऊ आइडपोटेंसी रिकॉर्ड बनाए रखना चाहिए; Redis TTL को एकमात्र आधिकारिक डुप्लीकेट लेजर के बजाय हॉट-कैश अनुकूलन के रूप में उपयोग किया जा सकता है:

पहले क्रिप्टोग्राफिक सत्यापन: स्टोरेज में ट्रांजैक्शन आईडी को प्रतिबद्ध करने से पहले Apple की सार्वजनिक कुंजी के मुकाबले ECDSA हस्ताक्षर को पूरी तरह से सत्यापित करें।
परमाणु डुप्लीकेशन (Atomic Deduplication): एक परमाणु लेखन ऑपरेशन (उदा. Redis SET key value NX EX <seconds>) निष्पादित करें जो एक लगातार रिलेशनल या दस्तावेज़ डेटाबेस अद्वितीय बाधा द्वारा समर्थित हो।
डुप्लीकेशन होराइजन: कैश लेयर में एक परिचालन प्रतिधारण विंडो सेट करें जो अपेक्षित पोस्टबैक डिलीवरी, नेटवर्क पुनः प्रयास (Apple 9 दिनों तक असफल डिलीवरी का पुनः प्रयास करता है), और डाउनस्ट्रीम सुलह को कवर करती है।

SKAdNetwork रिप्ले डिफेंस और डुप्लीकेशन पाइपलाइन

नीचे दिया गया बैकएंड कार्यान्वयन 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 पीक कैंपेन अवधि के दौरान पर्याप्त पोस्टबैक वॉल्यूम को प्रोसेस करते हैं। सिंक्रोनस डाउनस्ट्रीम प्रोसेसिंग विलंबता बाधाएं पेश कर सकती है।

एंटरप्राइज़ आर्किटेक्चर एक एसिंक्रोनस पाइपलाइन लागू करते हैं:

एज रिसीवर: आने वाले HTTP POST को स्वीकार करता है, हस्ताक्षर प्रामाणिकता को सत्यापित करता है, transaction-id पर परमाणु डुप्लीकेशन निष्पादित करता है, और तुरंत HTTP 200 OK लौटाता है।
इवेंट कतार: सत्यापित पेलोड को एक वितरित इवेंट ब्रोकर (उदा. Apache Kafka या AWS SQS) पर प्रकाशित करता है।
बिडिंग और एनालिटिक्स वर्कर्स: इवेंट स्ट्रीम का उपभोग करता है, रूपांतरण मानों को राजस्व मेट्रिक्स पर मैप करता है, और रियल-टाइम बिडिंग (RTB) लक्ष्य CPA मॉडल को अपडेट करता है।

पदानुक्रमित स्रोत पहचानकर्ता (Hierarchical Source Identifier) का उपयोग करना

पोस्टबैक डेटा टियर के आधार पर पहला विजयी पोस्टबैक पदानुक्रमित source-identifier के दो, तीन, या चार अंकों को उजागर कर सकता है। उन अंकों का शब्दार्थ अर्थ विज्ञापन नेटवर्क की अपनी स्रोत-पहचानकर्ता वर्गीकरण द्वारा परिभाषित किया जाता है। बिडिंग सिस्टम को अंकों की लंबाई और विशिष्ट प्लेसमेंट या रचनात्मक ग्रैनुलेरिटी के बीच एक सार्वभौमिक मैपिंग मानने के बजाय नेटवर्क के अपने कैंपेन मेटाडेटा के मुकाबले प्राप्त स्रोत-पहचानकर्ता को हल करना चाहिए।

तुलनात्मक मैट्रिक्स: प्रत्यक्ष Apple डिलीवरी बनाम MMP S2S इनजेशन

कार्यात्मक आयाम	प्रत्यक्ष Apple डिलीवरी (विज्ञापन नेटवर्क)	डेवलपर एंडपॉइंट (`NSAdvertising...`)	MMP S2S इनजेशन पाइपलाइन
प्राप्तकर्ता	पंजीकृत विज्ञापन नेटवर्क	विज्ञापित ऐप डेवलपर	मोबाइल मेजरमेंट पार्टनर
एट्रिब्यूशन दायरा	उस नेटवर्क के लिए विजयी पोस्टबैक	ऐप के लिए विजयी पोस्टबैक की प्रति	मल्टी-नेटवर्क समेकित दृश्य
हस्ताक्षर सत्यापन	विज्ञापन नेटवर्क बैकएंड द्वारा निष्पादित	डेवलपर बैकएंड द्वारा निष्पादित	कार्यान्वयन-निर्भर (पार्टनर प्रवाह)
नॉनविनिंग पोस्टबैक	योग्य होने पर प्राप्त होता है (`did-win: false`)	डेवलपर एंडपॉइंट पर डिलीवर नहीं किया जाता	पार्टनर प्रवाह के माध्यम से उपलब्ध हो सकता है
प्राथमिक उपयोग का मामला	प्रत्यक्ष बिडर और लक्ष्य CPA ऑप्टिमाइज़ेशन	आंतरिक वेयरहाउस ऑडिटिंग और सत्यापन	क्रॉस-चैनल प्रदर्शन डैशबोर्ड

अक्सर पूछे जाने वाले प्रश्न (FAQ)

Apple के पोस्टबैक हस्ताक्षर को सत्यापित करने के लिए किस सार्वजनिक कुंजी का उपयोग किया जाता है?

Apple अपने डेवलपर दस्तावेज़ में SKAdNetwork 2.1+ इंस्टॉल सत्यापन के लिए उपयोग की जाने वाली आधिकारिक NIST P-256 सार्वजनिक कुंजी प्रकाशित करता है। इनजेशन सर्वर आने वाले हस्ताक्षरों को सत्यापित करने के लिए इस सार्वजनिक कुंजी को X.509/DER प्रारूप में लोड करते हैं।

एक वैध SKAdNetwork पोस्टबैक हस्ताक्षर सत्यापन में विफल क्यों होता है?

हस्ताक्षर सत्यापन विफलताएं आमतौर पर सिरीलाइज़ेशन त्रुटियों के कारण होती हैं: गलत विभाजक वर्ण का उपयोग करना (`\u2063` के बजाय `\u2060` का उपयोग करना), गलत पैरामीटर क्रम, SKAN 4 संदेश स्ट्रिंग में गलती से रूपांतरण मान जोड़ना, या बूलियन स्ट्रिंग एनकोडिंग (`"true"` बनाम `"false"`) को गलत तरीके से संभालना।

क्या विज्ञापित ऐप का डेवलपर एंडपॉइंट नॉनविनिंग SKAdNetwork पोस्टबैक प्राप्त कर सकता है?

नहीं। कॉन्फ़िगर किए जाने पर डेवलपर कॉपी एंडपॉइंट विजयी इंस्टॉल-वैलिडेशन पोस्टबैक की प्रतियां प्राप्त करता है। पांच नॉनविनिंग पोस्टबैक (`did-win: false`) तक सीधे अन्य योग्य विज्ञापन नेटवर्क को भेजे जाते हैं, डेवलपर कॉपी एंडपॉइंट को नहीं।

सारांश और निर्णय ढांचा

पैमाने पर SKAdNetwork पोस्टबैक को संभालने के लिए कम विलंबता वाले एज इनजेशन को कठोर क्रिप्टोग्राफिक सत्यापन और ट्रांजैक्शन-स्तरीय डुप्लीकेशन के साथ संयोजित करने की आवश्यकता होती है। चूंकि Apple पोस्टबैक सीधे बजट आवंटन और बिडिंग एल्गोरिदम को प्रभावित करते हैं, इसलिए ECDSA हस्ताक्षरों को सत्यापित करना और transaction-id आइडपोटेंसी को लागू करना इनजेशन पाइपलाइनों को偽造 या छेड़छाड़ किए गए पोस्टबैक और डुप्लिकेट रिप्ले प्रोसेसिंग से बचाता है।

प्लेटफ़ॉर्म-मध्यस्थता वाले SKAdNetwork रिपोर्टिंग को माइक्रो-स्तरीय उपयोगकर्ता ऑनबोर्डिंग और त्वरित डीप लिंक रूटिंग के साथ पूरक करने के लिए, इंजीनियरिंग टीमें प्लेटफ़ॉर्म API के साथ-साथ प्रथम-पक्ष रूटिंग आर्किटेक्चर तैनात करती हैं।

सर्वर-साइड एट्रिब्यूशन पोस्टबैक और डीप लिंकिंग पाइपलाइनों को कॉन्फ़िगर करने के बारे में अधिक जानने के लिए, OpoInstall दस्तावेज़ की समीक्षा करें।