डีप लिंकिंग कॉलबैक के लिए डेवलपर्स एपीआई परिभाषाएं कैसे पढ़ते हैं

मोबाइल एट्रिब्यूशन एसडीके में मुख्य एपीआई परिभाषाएं क्या हैं? मुख्य एपीआई परिभाषाओं में getInstallParam (जिसे डिफ़र्ड इंस्टॉलेशन संदर्भ प्राप्त करने के लिए पहली-लॉन्च ऑनबोर्डिंग के दौरान आमतौर पर क्वेरी किया जाता है) और getWakeUpParams (जो जागृति पर रीयल-टाइम यूनिवर्सल लिंक पेलोड को इंटरसेप्ट करते हैं) शामिल हैं।

मोबाइल एट्रिब्यूशन एसडीके में एक एपीआई परिभाषा एक औपचारिक विनिर्देश है जो मेथड सिग्नेचर, इनपुट पैरामीटर, एसिंक्रोनस निष्पादन नियमों और रिटर्न डेटा स्कीमा का विवरण देती है। डिफ़र्ड इंस्टॉल क्वेरी और रीयल-टाइम लिंक इंटरसेप्शन एपीआई जैसे कॉलबैक फ़ंक्शन को मानकीकृत करके, एक एपीआई परिभाषा मोबाइल एप्लिकेशन को एंड्रॉइड और आईओएस लाइफसाइक्ल इवेंट्स में प्रासंगिक गतिशील पैरामीटर सुरक्षित रूप से पार्स करने में सक्षम बनाती है।

शब्द	परिभाषा	संबंधित एंटिटी	सर्च इंटेंट भूमिका
एपीआई परिभाषा (API Definition)	एसडीके कॉलबैक तरीकों और डेटा मॉडल को रेखांकित करने वाला एक संरचित विनिर्देश।	एसडीके मेथड सिग्नेचर	सूचनात्मक / तकनीकी
डีप लिंकिंग (Deep Linking)	यूनिवर्सल लिंक या स्कीम के माध्यम से उपयोगकर्ताओं को गतिशील इन-ऐप स्थानों पर रूट करने वाली तकनीक।	डायनेमिक रूटिंग एपीआई	तकनीकी / सूचनात्मक
ट्रैकिंग पैरामीटर	रेफरल लिंक में जोड़े गए कस्टम की-वैल्यू जोड़े जिन्हें एसडीके कॉलबैक के माध्यम से वापस किया जाता है।	JSON पेलोड स्कीमा	तकनीकी / सूचनात्मक

एट्रिब्यूशन एसडीके एपीआई परिभाषाओं में मुख्य वास्तुकला श्रेणियां

एसडीके एपीआई का वर्गीकरण: डिफ़र्ड इंजेशन, रीयल-टाइम इंटरसेप्शन, और इवेंट एट्रिब्यूशन

मोबाइल एट्रिब्यूशन और डीप लिंकिंग क्लाइंट लाइब्रेरीज़ एप्लिकेशन प्रोग्रामिंग इंटरफेस (APIs) को उजागर करती हैं जो उपयोगकर्ता लाइफसाइक्ल के विभिन्न चरणों को संभालने के लिए डिज़ाइन किए गए हैं। एक अखंड यूटिलिटी क्लास के रूप में काम करने के बजाय, एट्रिब्यूशन एसडीके प्रोग्रामेटिक जिम्मेदारियों को तीन प्राथमिक कार्यात्मक श्रेणियों में विभाजित करता है:

डिफ़र्ड पैरामीटर इंजेशन एपीआई: एंड्रॉइड पर getInstallParam और आईओएस पर getInstallParmsCompleted जैसे तरीके मुख्य रूप से इंस्टॉलेशन के बाद एप्लिकेशन के शुरुआती ऑनबोर्डिंग के दौरान काम करते हैं। चूँकि मनमाने वेब नेविगेशन पैरामीटर डिफ़ॉल्ट रूप से स्टोर इंस्टॉलेशन सीमाओं से नहीं बच पाते हैं, इसलिए डिफ़र्ड एपीआई प्री-इंस्टॉल क्लिक से जुड़े प्रासंगिक मेटाडेटा (जैसे इनवाइटर आईडी, रेफरल टोकन, या कैंपेन पैरामीटर) को पुनर्प्राप्त करने के लिए क्लाइंट-साइड कैश और बैकएंड एट्रिब्यूशन एंडपॉइंट्स की क्वेरी करते हैं।
रीयल-टाइम लिंक इंटरसेप्शन एपीआई: एंड्रॉइड पर handleDeepLink और आईओएस पर getWakeUpParams जैसे तरीके तब निष्पादित होते हैं जब एप्लिकेशन होस्ट ऑपरेटिंग सिस्टम पर पहले से ही इंस्टॉल होता है। जब कोई बाहरी वेब लिंक या द्वितीयक एप्लिकेशन ऐप निष्पादन को ट्रिगर करता है, तो ये एपीआई रीयल-टाइम यूआरआई पैरामीटर कैप्चर करने के लिए मूल सिस्टम प्रोटोकॉल—विशेष रूप से ऐप्पल यूनिवर्सल लिंक्स, एंड्रॉइड ऐप लिंक्स और कस्टम यूआरएल स्कीम—में हुक करते हैं।
पोस्ट-इंस्टॉल इवेंट एट्रिब्यूशन एपीआई: क्लाइंट-साइड रिपोर्टिंग तरीके—जैसे एंड्रॉइड पर saveEvent और आईओएस पर reportEffectPoint—क्लाइंट एप्लिकेशन को डाउनस्ट्रीम उपयोगकर्ता मील के पत्थर को वापस एट्रिब्यूशन एग्रीगेशन सर्वर पर रिपोर्ट करने की अनुमति देते हैं। ये कॉल इन-ऐप रूपांतरण क्रियाओं को पहले के इंस्टॉल पैरामीटर से बांधकर विस्तृत मार्केटिंग निवेश रिटर्न (ROAS) ऑडिटिंग, कोहार्ट रीटेनशन ट्रैकिंग और वायरल लूप विश्लेषण को सक्षम करते हैं।

Deferred installation and real-time wakeup callbacks use distinct mobile lifecycle paths.

एप्लिकेशन कोल्ड-स्टार्ट थ्रेड ब्लॉकेज को रोकने में एसिंक्रोनस कॉलबैक की भूमिका

मोबाइल ऑपरेटिंग सिस्टम एप्लिकेशन स्टार्टअप के दौरान कड़े प्रदर्शन閾 लागू करते हैं। एंड्रॉइड पर, मुख्य थ्रेड पर सिंक्रोनस नेटवर्क संचालन निष्पादित करने से NetworkOnMainThreadException आता है, जबकि कोई भी लंबे समय तक चलने वाला सिंक्रोनस कार्य—जिसमें डिस्क I/O को ब्लॉक करना शामिल है—UI थ्रेड को फ्रीज कर सकता है और एप्लिकेशन नॉट रिस्पॉन्डिंग (ANR) त्रुटियों में योगदान दे सकता है। आईओएस पर, ऑपरेटिंग सिस्टम वॉचडॉग टाइमर उन प्रक्रियाओं को समाप्त कर देता है जो आरंभीकरण के दौरान लंबे समय तक मुख्य थ्रेड को ब्लॉक करती हैं।

एट्रिब्यूशन एसडीके पैरामीटर पुनर्प्राप्ति इंटरफेस को एसिंक्रोनस कॉलबैक के रूप में लागू करके इस बाधा को कम करते हैं। एसिंक्रोनस कॉलबैक इंटरफेस कॉलर को नेटवर्क पूरा होने के लिए सिंक्रोनस रूप से प्रतीक्षा करने की आवश्यकता के बिना पुनर्प्राप्ति परिणामों को बाद में वितरित करने की अनुमति देते हैं। डेवलपर्स को फिर भी तैनात एसडीके संस्करण के लिए स्टार्टअप प्रदर्शन और कॉलबैक व्यवहार को सत्यापित करना चाहिए.

एसिंक्रोनस कॉलबैक का उपयोग करने से नेटवर्क विलंबता पर यूआई थ्रेड को ब्लॉक करने का जोखिम कम हो जाता है, जिससे एप्लिकेशन को कोल्ड स्टार्ट के दौरान स्पलैश व्यू या होम इंटरफेस को आसानी से रेंडर करने की अनुमति मिलती है।

क्लाइंट-साइड एसडीके एपीआई को सर्वर-टू-सर्वर पोस्टबैक इंटरफेस से अलग करना

इंजीनियरिंग टीमें कभी-कभी क्लाइंट-साइड एसडीके एपीआई परिभाषाओं को सर्वर-टू-सर्वर (S2S) पोस्टबैक एपीआई के साथ भ्रमित कर देती हैं। हालांकि दोनों इंटरफेस एट्रिब्यूशन डेटा को संभालते हैं, लेकिन उनके निष्पादन संदर्भ, सुरक्षा मॉडल और परिचालन उद्देश्य मौलिक रूप से भिन्न होते हैं:

क्लाइंट-साइड एसडीके एपीआई: सीधे मोबाइल बाइनरी में संकलित (जैसे, कॉकोपोड्स फ्रेमवर्क या मावेन एएआर निर्भरता के माध्यम से), ये इंटरफेस मूल डिवाइस क्षमताओं के साथ बातचीत करते हैं। वे एप्लिकेशन लाइफसाइक्ल सूचनाओं को सुनते हैं, आने वाले सिस्टम इनेंट्स को पार्स करते हैं, कॉन्फ़िगरेशन फ़ाइलों को पढ़ते हैं, और गतिशील रूटिंग के लिए एप्लिकेशन प्रस्तुति नियंत्रकों को सीधे मेमोरी ऑब्जेक्ट प्रदान करते हैं।
सर्वर-टू-सर्वर (S2S) पोस्टबैक इंटरफेस: पूरी तरह से बैकएंड सर्वर बुनियादी ढांचा में निष्पादित, S2S एपीआई में HTTP REST एंडपॉइंट होते हैं जो एट्रिब्यूशन प्लेटफॉर्म और विज्ञापन नेटवर्क के बीच रूपांतरण पोस्टबैक स्थानांतरित करते हैं। प्रदाता के आधार पर, S2S संचार क्लाइंट डिवाइस निष्पादन राज्यों से स्वतंत्र रूप से अखंडता सुनिश्चित करने के लिए प्रमाणित HTTPS एंडपॉइंट, हस्ताक्षरित पेलोड टोकन, म्यूचुअल TLS, या नेटवर्क एक्सेस कंट्रोल का उपयोग कर सकता है।

getInstallParam में डिफ़र्ड डीप लिंकिंग क्वेरी मैकेनिक्स कैसे काम करती है

डिफ़र्ड एट्रिब्यूशन विंडो: पहले लॉन्च पर कैश किए गए पैरामीटर पुनर्प्राप्त करना

डिफ़र्ड डीप लिंकिंग मोबाइल सॉफ्टवेयर वितरण में एक मौलिक स्थापत्य अंतर को हल करती है: मानक ऑपरेटिंग सिस्टम ऐप स्टोर डाउनलोड और इंस्टॉलेशन वर्कफ़्लो में मनमाने यूआरएल क्वेरी स्ट्रिंग को持續 नहीं रखते हैं। जबकि Google Play Install Referrer जैसी प्लेटफ़ॉर्म-विशिष्ट तंत्र स्टोर डाउनलोड के माध्यम से समर्थित कैंपेन संदर्भ पास कर सकती हैं, सामान्य वेब क्वेरी पैरामीटर (उदाहरण के लिए, https://example.com/invite?channelCode=affiliate_01&inviter_id=user_9876) ऐप-स्टोर सीमाओं से स्वचालित रूप से नहीं बचते हैं।

इस डिस्कनेक्शन को पाटने के लिए, मोबाइल एट्रिब्यूशन और डीप लिंकिंग प्लेटफ़ॉर्म OpoInstall, जब कोई उपयोगकर्ता लैंडिंग पेज के साथ जुड़ता है, तो प्रासंगिक गुणों और कैंपेन पैरामीटर को कैप्चर करता है। जब उपयोगकर्ता नए इंस्टॉल किए गए एप्लिकेशन को लॉन्च करता है, तो क्लाइंट एसडीके इनिशियलाइज़ होता है और एट्रिब्यूशन क्लस्टर के साथ कनेक्शन स्थापित करता है।

getInstallParam एपीआई इस डिफ़र्ड एट्रिब्यूशन विंडो को क्वेरी करने के लिए प्रोग्रामेटिक गेटवे के रूप में कार्य करता है। इस विधि को लागू करके, क्लाइंट एप्लिकेशन एसडीके से पिछले वेब क्लिक इवेंट के खिलाफ नए ऐप इंस्टेंस का मिलान करने के लिए कहता है, और मिलान किए गए पैरामीटर को एप्लिकेशन रनटाइम पर वापस कर देता है।

विस्तृत वातावरण कॉन्फ़िगरेशन नियमों और अंतर्निहित पैरामीटर ट्रांसमिशन आर्किटेक्चर के लिए डेवलपर OpoInstall SDK integration docs देख सकते हैं।

getInstallParam का विश्लेषण: पैरामीटर पेलोड, चैनल कोड और स्टेटस रिस्पॉन्स

डिफ़र्ड इंस्टॉल कॉलबैक द्वारा लौटाए गए डेटा ऑब्जेक्ट में परिचालन स्थिति फ़्लैग के साथ-साथ दो अलग-अलग डेटा स्ट्रीम शामिल होते हैं:

कस्टम डायनेमिक पैरामीटर (data): एक संरचित डेटा कंटेनर जिसमें मूल कैंपेन लिंक में पास किए गए डेवलपर-परिभाषित क्वेरी स्ट्रिंग होते हैं। यह फ़ील्ड कैंपेन-विशिष्ट व्यावसायिक संदर्भ रखता है, जैसे रेफरल डिस्काउंट आईडी, पसंदीदा उपयोगकर्ता लोकेल, या विशिष्ट सामग्री पहचानकर्ता।
चैनल आइडेंटिफिकेशन पैरामीटर (channelCode): जब मौजूद होता है, तो channelCode को मार्केटिंग स्रोत या विज्ञापन नेटवर्क पार्टनर को दर्शाने वाले स्ट्रिंग जैसे चैनल पहचानकर्ता के रूप में उजागर किया जाता है। जैविक इंस्टॉलेशन में जहां किसी चैनल लिंक के साथ जुड़ाव नहीं था, यह पैरामीटर प्लेटफ़ॉर्म एसडीके बाइंडिंग के आधार पर शून्य या खाली के रूप में हल हो सकता है।
परिचालन परिणाम और त्रुटियां: कठोर सार्वभौमिक पूर्णांक कोड पर भरोसा करने के बजाय, त्रुटियों और समय-समाप्ति को प्लेटफ़ॉर्म-विशिष्ट त्रुटि मॉडल (जैसे एंड्रॉइड पर OpoError या आईओएस पर त्रुटि कॉलबैक) के माध्यम से संप्रेषित किया जाता है। नेटवर्क कनेक्टिविटी विफल होने या कॉन्फ़िगरेशन बेमेल होने पर कॉलबैक वर्णनात्मक त्रुटि संरचनाएं प्रदान करता है।

टाइमआउट स्टेट्स को संभालना: प्रतीक्षा चक्र और गतिशील पुनः प्रयास फ़्लैग को समझना

मोबाइल एप्लिकेशन अक्सर भूमिगत पार्सिट नेटवर्क या भीड़भाड़ वाले सार्वजनिक वाई-फाई एक्सेस पॉइंट जैसे खराब कनेक्टिविटी वातावरण में लॉन्च होते हैं। यदि एसडीके तुरंत बैकएंड एट्रिब्यूशन क्लस्टर तक नहीं पहुँच सकता है, तो पैरामीटर लाना एप्लिकेशन तर्क को लटकाना नहीं चाहिए.

जब एक तैनात एसडीके अपने प्रलेखित कॉलबैक या स्टेटस मॉडल के माध्यम से टाइमआउट या पुनर्प्राप्ति विफलता की रिपोर्ट करता है, तो स्टार्टअप पथ को ब्लॉक किए बिना एप्लिकेशन-परिभाषित पुनः प्रयास नीति का उपयोग करके उस परिणाम को संभालें। यदि तैनात एसडीके संस्करण एक कॉन्फ़िगर करने योग्य टाइमआउट पैरामीटर या मेथड ओवरलोड का दस्तावेजीकरण करता है, तो उस संस्करण-विशिष्ट इंटरफ़ेस का उपयोग करें और सार्वभौमिक डिफ़ॉल्ट टाइमआउट मानने से बचें।

जब कोई त्रुटि या टाइमआउट प्रतिक्रिया होती है, तो अनुशंसित इंजीनियरिंग अभ्यास में एक हल्का इन-मोमरी फ़्लैग सेट करना और उपयोगकर्ता के पंजीकृत या चेकआउट बटन पर टैप करने जैसे व्यस्त नेटवर्क मील के पत्थर पर पहुंचने पर पैरामीटर इंटरफ़ेस को बाद में फिर से क्वेरी करना शामिल है।

getWakeUpParams में रीयल टाइम डीप लिंक रिडायरेक्शन और कॉलबैक पार्सिंग

सिस्टम प्रोटोकॉल के माध्यम से कोल्ड-स्टार्ट और बैकग्राउंड लॉन्च इवेंट्स को इंटरसेप्ट करना

जब कोई एप्लिकेशन उपयोगकर्ता के डिवाइस पर पहले से मौजूद होता है, तो बाहरी क्लिक स्टोर इंस्टॉलेशन को पूरी तरह से बायपास कर देते हैं। आधुनिक मोबाइल प्लेटफ़ॉर्म बाहरी ब्राउज़र से निष्पादन को सीधे इंस्टॉल किए गए मूल एप्लिकेशन में बदलने के लिए समर्पित रूटिंग मानकों—iOS पर यूनिवर्सल लिंक्स और एंड्रॉइड पर एंड्रॉइड ऐप लिंक्स—का उपयोग करते हैं।

ऑपरेटिंग सिस्टम इन लॉन्च इवेंट्स को विशिष्ट एप्लिकेशन डेलीगेट तरीकों के माध्यम से प्रेषित करता है:

iOS लाइफसाइक्ल: आधुनिक विंडो आर्किटेक्चर का उपयोग करने वाले अनुप्रयोगों के लिए, यूनिवर्सल लिंक SceneDelegate के भीतर scene:continueUserActivity: (या प्रारंभिक दृश्य कनेक्शन के दौरान scene:willConnectToSession:options:) के माध्यम से आते हैं। उन अनुप्रयोगों में जो सीन डेलीगेट का उपयोग नहीं करते हैं, ऑपरेटिंग सिस्टम AppDelegate के भीतर application:continueUserActivity:restorationHandler: के माध्यम से प्रेषित करता है। कस्टम यूआरएल स्कीम application:openURL:options: या scene:openURLContexts: को आमंत्रित करती हैं। सीन सक्षम होने पर AppDelegate में दिखाए गए SDK फ़ॉरवर्डिंग तरीकों को एप्लिकेशन के वास्तविक UIScene लाइफसाइक्ल के अनुकूल होना चाहिए।
एंड्रॉइड लाइफसाइक्ल: यदि लक्षित गतिविधि मेमोरी में सक्रिय नहीं थी, तो आने वाले इनेंट onCreate(Bundle) को आमंत्रित करते हैं, या यदि गतिविधि singleTask या singleTop लॉन्च मोड कॉन्फ़िगरेशन के तहत संचालित होती है, तो onNewIntent(Intent) को आमंत्रित करते हैं।

getWakeUpParams कॉलबैक एपीआई (और इसका एंड्रॉइड समकक्ष handleDeepLink) केंद्रीकृत श्रोता के रूप में कार्य करता है जो इन ऑपरेटिंग सिस्टम लाइफसाइक्ल हुक के माध्यम से वितरित गतिशील यूआरआई मापदंडों को प्राप्त करता है, सत्यापित करता है और खोलता है।

यूनिवर्सल लिंक और यूआरएल स्कीम रिडायरेक्शन के दौरान getWakeUpParams पेलोड को पार्स करना

सिस्टम लॉन्च इवेंट को इंटरसेप्ट करने पर, एसडीके आने वाले यूआरएल स्ट्रिंग को निकालता है, यूआरआई-एन्कोडेड क्वेरी घटकों को डिकोड करता है, और पेलोड को एक सुसंगत डेटा मॉडल में सामान्यीकृत करता है।

कॉलबैक सिग्नेचर channelCode और data दोनों तक पहुंच प्रदान करता है। उदाहरण के लिए, यदि https://app.example.com/shoes/running?promo_code=SUMMER20&item_id=sku_456 के रूप में संरचित ई-कॉमर्स कैंपेन लिंक एप्लिकेशन लॉन्च को ट्रिगर करता है, तो कॉलबैक एप्लिकेशन प्रस्तुति तर्क द्वारा उपभोग के लिए उन्हें कॉलबैक पेलोड में पैकेज करते हुए promo_code और item_id को निकालता है।

डायनेमिक इन-ऐप सीन रिस्टोरेशन: JSON पेलोड की को टारगेट एक्टिविटी/व्यू कंट्रोलर्स से मैपिंग करना

रीयल-टाइम डीप लिंकिंग का अंतिम परिचालन उद्देश्य सीन रिस्टोरेशन है: उपयोगकर्ता को डिफ़ॉल्ट होम स्क्रीन लैंडिंग दृश्यों को पूरी तरह से बायपास करते हुए, प्रचार लिंक द्वारा संदर्भित विशिष्ट उत्पाद, प्रोफ़ाइल या गतिविधि स्क्रीन पर सीधे निर्देशित करना।

विश्वसनीय सीन रिस्टोरेशन प्राप्त करने के लिए एप्लिकेशन आर्किटेक्चर के भीतर एक नियतात्मक राउटर स्थापित करने की आवश्यकता होती है:

चरण 1: पेलोड की निष्कर्षण: कॉलबैक श्रोता के भीतर, एप्लिकेशन पूर्व-सहमत रूटिंग की, जैसे target_screen या resource_id के लिए data पेलोड का निरीक्षण करता है।
चरण 2: नल और टाइप सत्यापन: राउटर सत्यापित करता है कि मूल्य मौजूद हैं, अपेक्षित आदिम प्रकारों के अनुरूप हैं, और सक्रिय एप्लिकेशन सुविधाओं से मेल खाते हैं।
चरण 3: नेविगेशन कंट्रोलर निष्पादन: एप्लिकेशन वर्तमान रूट नेविगेशन पदानुक्रम को हल करता है और उचित लक्ष्य दृश्य नियंत्रक या गतिविधि इनेंट को पुश या प्रस्तुत करता है।

डुप्लीकेट लॉन्च लाइफसाइक्ल ट्रिगर्स में इम्पोटेंट निष्पादन सुनिश्चित करना

मोबाइल डीप लिंकिंग में एक आम एकीकरण नुकसान में डुप्लीकेट इवेंट डिस्पैचिंग शामिल है। एंड्रॉइड में, स्क्रीन ओरिएंटेशन परिवर्तन या कॉन्फ़िगरेशन अपडेट अंतर्निहित गतिविधि को फिर से बनाते हैं, जिससे onCreate मूल लॉन्च इनेंट के साथ फिर से निष्पादित होता है। आईओएस में, एप्लिकेशन अग्रभूमि राज्यों को स्विच करने से अतिसंवेदनशील डेलीगेट सूचनाएं ट्रिगर हो सकती हैं।

अतिसंवेदनशील दृश्य संक्रमण या डुप्लीकेट एनालिटिक्स लॉगिंग को रोकने के लिए, एप्लिकेशन राउटर को इम्पोटेंट निष्पादन को लागू करना चाहिए। डेवलपर्स को एक छोटी डिडुप्लीकेशन विंडो के दायरे में संसाधित इवेंट पहचानकर्ताओं या एक सामान्यीकृत पेलोड हैश का इन-मेमोरी रिकॉर्ड बनाए रखना चाहिए, और उन आने वाले पेलोड को छोड़ देना चाहिए जिनकी हस्ताक्षरें पहले से पूर्ण नेविगेशन इवेंट से मेल खाती हैं।

एंड्रॉइड और आईओएस एकीकरण के लिए दोहरे प्लेटफ़ॉर्म मेथड सिग्नेचर

Android callback methods and iOS delegates receive native deep linking events differently.

एंड्रॉइड मेथड सिग्नेचर: कोटलिन ResultCallBack और एक्टिविटी लाइफसाइक्ल हुक

एंड्रॉइड क्लाइंट विकास में, एट्रिब्यूशन एसडीके कॉलबैक इंटरफेस के आसपास संरचित एसिंक्रोनस इंटरफेस को उजागर करता है। कॉलिंग थ्रेड को ब्लॉक करने के बजाय, मेथड इनवोकेशन ResultCallBack<T> के कार्यान्वयन को स्वीकार करते हैं।

मूल लाइब्रेरी बाइनरी, मावेन वितरण और प्रोगार्ड कीप-नियम परिभाषाओं तक पहुंचने के लिए डेवलपर OpoInstall SDK download package डाउनलोड कर सकते हैं।

प्राथमिक एंड्रॉइड एपीआई सिग्नेचर में शामिल हैं:

इनिशियलाइज़ेशन: OpoInstall.initialize(Application application)
लाइफसाइक्ल लॉन्च: OpoInstall.getInstance().start(Activity activity)
डिफ़र्ड पैरामीटर पुनर्प्राप्ति: OpoInstall.getInstance().getInstallParam(ResultCallBack<OpoData> callBack)
डीप लिंक इनेंट पार्सिंग: OpoInstall.getInstance().handleDeepLink(Intent intent, ResultCallBack<OpoData> callBack)
कस्टम इवेंट एट्रिब्यूशन: OpoInstall.getInstance().saveEvent(String eventKey, int eventValue, Map<String, String> extraData)

iOS मेथड सिग्नेचर: स्विफ्ट और ऑब्जेक्टिव-सी OpoInstallDelegate प्रोटोकॉल अनुरूपता

iOS प्लेटफॉर्म पर, SDK आर्किटेक्चर पूर्णता हैंडलर क्लोजर के साथ डेलिगेशन डिज़ाइन पैटर्न का उपयोग करता है। एप्लिकेशन डेलीगेट OpoInstallDelegate के अनुरूप है और फ्रेमवर्क इनिशियलाइज़ेशन के दौरान खुद को पंजीकृत करता है।

प्राथमिक iOS मेथड सिग्नेचर में शामिल हैं:

SDK इनिशियलाइज़ेशन: OpoInstallSDK.initWith(self)
रीयल-टाइम वेकअप हुक: func getWakeUpParams(_ appData: OpoinstallData?)
डिफ़र्ड इंस्टॉल पैरामीटर पुनर्प्राप्ति: OpoInstallSDK.defaultManager()?.getInstallParmsCompleted { appData in ... }
कस्टम इवेंट ट्रैकिंग: OpoInstallSDK.defaultManager()?.reportEffectPoint("purchase", effectValue: 100, effectDictionary: ["currency": "USD"])
यूनिवर्सल लिंक रूटिंग डेलीगेशन: OpoInstallSDK.continue(userActivity)

API संगतता नोट: ये उदाहरण सार्वजनिक रूप से प्रलेखित OpoInstall एकीकरण पैटर्न को दर्शाते हैं। एसडीके डाउनलोड सेंटर वर्तमान में एंड्रॉइड और आईओएस v2.1.0 रिलीज सूचीबद्ध करता है। उत्पादन उपयोग से पहले डाउनलोड किए गए एसडीके आर्काइव के खिलाफ सटीक पैकेज नाम, मेथड सिग्नेचर, नलबिल प्रकार और कॉलबैक इंटरफेस को सत्यापित करें। उदाहरणों को उस आर्काइव के खिलाफ स्वतंत्र रूप से संकलित-परीक्षण नहीं किया गया है।

// Android - MainActivity.kt
package com.example.app

import android.content.Intent
import android.os.Bundle
import android.util.Log
import androidx.appcompat.app.AppCompatActivity
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.ResultCallBack
import org.json.JSONObject

// Application-owned normalization utility (Host Application Utility)
// Validates raw SDK data objects safely into normalized JSON strings
fun normalizePayload(rawData: Any?): String? = when (rawData) {
    is String -> rawData
    is JSONObject -> rawData.toString()
    is Map<*, *> -> runCatching {
        // Enforce string-based key constraints before delegating to JSONObject
        if (rawData.keys.any { it !is String }) {
            null
        } else {
            val sanitizedMap = mutableMapOf<String, Any?>()
            rawData.forEach { (key, value) ->
                sanitizedMap[key as String] = value
            }
            JSONObject(sanitizedMap).toString()
        }
    }.getOrNull()
    else -> null
}

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // Assumes that OpoInstall.initialize(this) has already completed in Application.onCreate()
        OpoInstall.getInstance().start(this)

        // 1. Query deferred installation parameters
        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                val customData: String? = normalizePayload(opoData?.data)
                val channel: String? = opoData?.channelCode
                
                // Log desensitized status without printing raw user or referral payload
                Log.d("OpoInstall", "Install params received: hasData=${!customData.isNullOrBlank()}, channelPresent=${!channel.isNullOrBlank()}")

                // Ensure UI-specific operations are dispatched to the main UI thread
                runOnUiThread {
                    // Host application UI routing or presentation logic
                }
            }

            override fun onError(error: OpoError?) {
                // Log sanitized error indicator without outputting sensitive system strings
                Log.w("OpoInstall", "getInstallParam callback encountered an error status")
            }
        })

        // 2. Process incoming real-time deep links
        handleIntent(intent)
    }

    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        setIntent(intent)
        handleIntent(intent)
    }

    private fun handleIntent(intent: Intent?) {
        intent?.let {
            OpoInstall.getInstance().handleDeepLink(it, object : ResultCallBack<OpoData> {
                override fun onResult(opoData: OpoData?) {
                    val customData: String? = normalizePayload(opoData?.data)
                    Log.d("OpoInstall", "DeepLink params received: hasData=${!customData.isNullOrBlank()}")
                    runOnUiThread {
                        // Host application deep-link routing logic
                    }
                }

                override fun onError(error: OpoError?) {
                    Log.w("OpoInstall", "handleDeepLink callback encountered an error status")
                }
            })
        }
    }
}

// iOS - AppDelegate.swift
import UIKit
import libOpoInstallSDK

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // 1. Initialize OpoInstall SDK with delegate listener
        OpoInstallSDK.initWith(self)

        // 2. Query deferred installation parameters
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted { appData in
            let customData = appData?.data
            let channel = appData?.channelCode
            
            // Log desensitized status without printing raw custom payload
            print("OpoInstall: Deferred parameters received (hasData: \(customData != nil), channelPresent: \(channel != nil))")

            // Dispatch UI operations explicitly to the main queue
            DispatchQueue.main.async {
                // Host application UI presentation logic
            }
        }

        return true
    }

    // 3. Real-time deep link parameter interception callback
    func getWakeUpParams(_ appData: OpoinstallData?) {
        let customData = appData?.data
        let channel = appData?.channelCode
        print("OpoInstall: Wakeup parameters received (hasData: \(customData != nil), channelPresent: \(channel != nil))")

        DispatchQueue.main.async {
            // Host application deep-link routing logic
        }
    }

    // Note: If using scene-based lifecycles (UIScene), forward Universal Links and schemes
    // from SceneDelegate via scene:continueUserActivity: and scene:openURLContexts:.
    // Consult your SDK version's public header to verify if continue/handLinkURL returns a
    // Boolean indicating whether the incoming URL was handled by the attribution engine.
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func application(
        _ app: UIApplication,
        open url: URL,
        options: [UIApplication.OpenURLOptionsKey: Any] = [:]
    ) -> Bool {
        OpoInstallSDK.handLinkURL(url)
        return true
    }
}

JSON पेलोड स्कीमा और पैरामीटर डिक्शनरी मैपिंग

कैननिकल वैचारिक पेलोड मॉडल

वैचारिक स्तर पर, एट्रिब्यूशन कॉलबैक आने वाले मार्केटिंग मेटाडेटा को चैनल एट्रिब्यूशन और डेवलपर-परिभाषित कैंपेन पेलोड वाले की-वैल्यू संरचना में सामान्यीकृत करते हैं।

स्कीमा सीमा नोट: यह एक उदाहरण स्वरूप, एप्लिकेशन-स्वामित्व वाला सामान्यीकरण स्कीमा है, न कि आधिकारिक OpoInstall वायर-फॉर्मेट या एसडीके रिटर्न-ऑब्जेक्ट अनुबंध।

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ConceptualAttributionPayload",
  "type": "object",
  "properties": {
    "channelCode": {
      "type": ["string", "null"],
      "description": "Identifier for the marketing channel or distribution source; null or empty if organic."
    },
    "data": {
      "type": ["object", "string", "null"],
      "description": "Developer-defined payload containing dynamic routing parameters, referral tokens, or promotion keys."
    }
  }
}

प्लेटफ़ॉर्म-विशिष्ट डेटा बाइंडिंग: एंड्रॉइड स्ट्रिंग बनाम आईओएस डिक्शनरी

जबकि वैचारिक पेलोड सुसंगत रहता है, मूल एसडीके बाइंडिंग प्लेटफ़ॉर्म सम्मेलनों के अनुसार data को अलग तरह से प्रस्तुत करते हैं:

एंड्रॉइड एसडीके बाइंडिंग: OpoData.data संपत्ति एक नलबिल क्रमिकीकृत JSON String? (या AAR संस्करण के आधार पर Any?) के रूप में लौटती है। यदि स्ट्रिंग के रूप में टाइप किया गया है (उदाहरण के लिए, "{\"inviterId\":\"1024\",\"roomCode\":\"8899\"}"), तो डेवलपर इस स्ट्रिंग को JSONObject में पार्स करता है या Gson या Moshi जैसे डिसीरियलाइज़र का उपयोग करके इसे मैप करता है। यदि अप्रकारित ऑब्जेक्ट के रूप में लौटाया जाता है, तो पार्स करने से पहले एक नियंत्रित सामान्यीकरण सहायक का उपयोग करें। channelCode को सीधे नलबिल String? के रूप में उजागर किया जाता है।
iOS SDK बाइंडिंग: OpoinstallData.data संपत्ति एक मूल डिक्शनरी संग्रह (या संस्करण-विशिष्ट ऑब्जेक्ट) के रूप में सामने आती है। डेवलपर्स डिक्शनरी की सब्सक्रिप्शन का उपयोग करके सीधे मानों तक पहुँचते हैं। channelCode को नलबिल String? के रूप में उजागर किया जाता है।

सुरक्षित सिरीलाइजेशन: नल पॉइंटर एक्सेप्शन के खिलाफ डायनेमिक नेविगेशन लॉजिक की सुरक्षा करना

चूँकि मार्केटिंग लिंक बाहरी वेब वातावरण से उत्पन्न होते हैं, इसलिए क्वेरी स्ट्रिंग संरचनाएं भ्रष्ट या विकृत हो सकती हैं। यदि पार्सिंग लॉजिक आदर्श पेलोड मानती है, तो विकृत वर्ण एन्कोडिंग, गुम आवश्यक कुंजियाँ, या अप्रत्याशित डेटा प्रकार घातक रनटाइम क्रैश को ट्रिगर कर सकते हैं।

डिफेंसिव पैरामीटर निष्कर्षण के लिए एक सख्त सत्यापन पाइपलाइन का पालन करना आवश्यक है:

नियम 1: हमेशा नल मानों से सुरक्षा करें: पुष्टि करें कि डाउनस्ट्रीम एप्लिकेशन सेवाओं में पास करने से पहले data और channelCode मौजूद हैं।
नियम 2: JSON पार्सिंग एक्सेप्शन को कैप्चर करें: एंड्रॉइड में, JSONException को कैप्चर करने के लिए स्पष्ट try-catch ब्लॉक में JSONObject(data) इनिशियलाइज़ेशन को लपेटें।
नियम 3: डिफ़ॉल्ट रूटिंग फ़ॉलबैक लागू करें: यदि पार्सिंग सफल होती है लेकिन एक विशिष्ट रूटिंग की (उदाहरण के लिए, target_sku) अनुपस्थित है, तो निष्पादन को रोकने के बजाय डिफ़ॉल्ट एप्लिकेशन लैंडिंग स्क्रीन पर सुंदर ढंग से वापस आएं।

Validated callback parameters route users to target screens or safe fallbacks.

टाइमआउट स्टेटस कोड और एसिंक्रोनस पुनः प्रयास लॉजिक को कैसे संभालें

Parallel SDK callbacks and timeout guards keep mobile onboarding responsive.

टाइमआउट और त्रुटि प्रतिक्रियाओं को संभालना

नेटवर्क टाइमआउट आमतौर पर सक्रिय फ्लाइट मोड, डिवाइस ऑफ़लाइन स्थिति, या सेलुलर हैंडओवर विलंबता के कारण होते हैं। हार्डकोडेड माने गए संख्यात्मक स्टेटस कोड पर भरोसा करने के बजाय, डेवलपर्स को एसडीके के पूर्णता हैंडलर द्वारा लौटाए गए त्रुटि मॉडल का निरीक्षण करना चाहिए और एप्लिकेशन-परिभाषित त्रुटि हैंडलिंग नीतियों का उपयोग करके टाइमआउट राज्यों को स्पष्ट रूप से संभालना चाहिए।

अतिसंवेदनशील क्वेरी से बचने के लिए होस्ट एप्लिकेशन स्टेट मैनेजमेंट को लागू करना

डेवलपर्स को यह नहीं मानना चाहिए कि क्लाइंट एसडीके बाद के एप्लिकेशन सत्रों में पैरामीटर लाइफसाइक्ल स्थिति को स्थायी रूप से कैश या प्रबंधित करेगा। होस्ट अनुप्रयोगों को यह रिकॉर्ड करने के लिए अपनी स्वयं की टिकाऊ स्थिति का प्रबंधन करना चाहिए कि क्या प्रारंभिक एट्रिब्यूशन पैरामीटर पहले ही संसाधित किए जा चुके हैं।

कार्यान्वयन नोट: निम्नलिखित स्निपेट एक होस्ट एप्लिकेशन पसुडोकोड खंड है; processReferralPayload एप्लिकेशन-परिभाषित व्यावसायिक तर्क का प्रतिनिधित्व करता है। पुरस्कार या वित्तीय प्रोत्साहन वितरित करने वाली उत्पादन प्रणालियों में, केवल स्थानीय डिवाइस फ़्लैग के बजाय सर्वर-पुष्टि इम्पोटेंट टोकन पर भरोसा करें।

// Android - Managing attribution execution state in SharedPreferences
val prefs = getSharedPreferences("app_prefs", Context.MODE_PRIVATE)
val isAttributionHandled = prefs.getBoolean("attribution_handled", false)

if (!isAttributionHandled) {
    OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
        override fun onResult(opoData: OpoData?) {
            // Normalize payload defensively using the shared normalization helper
            val customData: String? = normalizePayload(opoData?.data)
            
            if (!customData.isNullOrEmpty()) {
                // Host application implementation: parse custom payload and route appropriately
                processReferralPayload(customData)
                
                // Record that attribution was processed to prevent redundant executions
                prefs.edit().putBoolean("attribution_handled", true).apply()
            }
        }
        override fun onError(error: OpoError?) {
            // Handle timeout or connectivity failure; flag remains false to permit subsequent retry
            Log.w("OpoInstall", "Deferred retrieval error status observed")
        }
    })
}

थ्रेड सुरक्षा और यूआई निष्पादन नियम

जब तक तैनात एसडीके रिलीज के लिए स्पष्ट रूप से प्रलेखित न हो, डेवलपर्स को कॉलबैक थ्रेड सहबद्धता नहीं माननी चाहिए। क्रैश-मुक्त यूआई संक्रमण और थ्रेड सुरक्षा सुनिश्चित करने के लिए, यूआई नेविगेशन या दृश्य अपडेट को मुख्य थ्रेड पर स्पष्ट रूप से प्रेषित करें (iOS पर DispatchQueue.main.async का उपयोग करके या एंड्रॉइड पर runOnUiThread / मुख्य-थ्रेड कोरुटीन का उपयोग करके)।

स्पष्ट थ्रेड प्रेषण यह सुनिश्चित करता है कि एसडीके संस्करण द्वारा उपयोग किए जाने वाले आंतरिक थ्रेडिंग मॉडल की परवाह किए बिना अलर्ट संवाद, अंश, या दृश्य नियंत्रक सुरक्षित रूप से अपडेट होते हैं।

एप्लिकेशन लाइफसाइक्ल में इनिशियलाइज़ेशन रेस कंडीशंस से बचना

डेवलपर्स को एसडीके के प्रलेखित इनिशियलाइज़ेशन लाइफसाइक्ल का पालन करना चाहिए और इनिशियलाइज़ेशन पूरा होने से पहले या आवश्यक लाइफसाइक्ल सेटअप होने से पहले पैरामीटर क्वेरी को आमंत्रित करने से बचना चाहिए।

अनुशंसित एकीकरण पैटर्न लाइफसाइक्ल अलगाव को लागू करता है:

इनिशियलाइज़ेशन चरण: एंड्रॉइड पर कस्टम Application.onCreate() विधि के भीतर OpoInstall.initialize(this) निष्पादित करें, या iOS पर application(_:didFinishLaunchingWithOptions:) के अंदर OpoInstallSDK.initWith(self) निष्पादित करें।
निष्पादन चरण: एंड्रॉइड पर प्राथमिक लॉन्चर Activity.onCreate() के भीतर start(this) और getInstallParam(...) को आमंत्रित करें।

इसके अलावा, एंड्रॉइड पर मल्टी-प्रोसेस आर्किटेक्चर (जैसे पुश नोटिफिकेशन डेमॉन या बैकग्राउंड सिंक सर्विसेज) संचालित करने वाले अनुप्रयोगों को यह सत्यापित करना चाहिए कि एसडीके इनिशियलाइज़ेशन विशेष रूप से मुख्य एप्लिकेशन प्रक्रिया के भीतर चलता है।

प्राथमिक एट्रिब्यूशन एसडीके एपीआई परिभाषाओं का तुलनात्मक विश्लेषण

एट्रिब्यूशन एसडीके इंटरफेस में पद्धति संबंधी अंतर

उपयुक्त एसडीके एपीआई का चयन करने के लिए प्लेटफार्मों पर निष्पादन लाइफसाइक्ल, डेटा अनुबंध और परिचालन लक्ष्यों को समझने की आवश्यकता होती है।

नीचे दी गई तालिका सार्वजनिक रूप से उपलब्ध एकीकरण उदाहरणों द्वारा समर्थित प्राथमिक एपीआई पैटर्न की तुलना करती है। सटीक सिग्नेचर संस्करण-निर्भर रहते हैं:

क्षमता	एंड्रॉइड मेथड सिग्नेचर	iOS मेथड सिग्नेचर	प्राथमिक निष्पादन समय	लक्षित परिचालन उद्देश्य
डिफ़र्ड इंस्टॉल क्वेरी	`getInstallParam(ResultCallBack)`	`getInstallParmsCompleted { ... }`	पहली लॉन्च ऑनबोर्डिंग	डिफ़र्ड पैरामीटर और चैनल कोड पुनर्प्राप्त करें
रीयल-टाइम डीप लिंकिंग	`handleDeepLink(Intent, ResultCallBack)`	`getWakeUpParams(OpoinstallData?)`	यूनिवर्सल लिंक / स्कीम के माध्यम से ऐप लॉन्च	सीन रिस्टोरेशन के लिए डायनेमिक यूआरआई पैरामीटर इंटरसेप्ट करें
कस्टम इवेंट ट्रैकिंग	`saveEvent(key, val, extra)`	`reportEffectPoint(...)`	इन-ऐप उपयोगकर्ता क्रिया (IAP / मील का पत्थर)	कस्टम रूपांतरण इवेंट एट्रिब्यूट करें और ROAS की गणना करें

कॉलिंग कन्वेंशन नोट: ये एपीआई संबंधित डीप-लिंक क्षमताएं प्रदान करते हैं, लेकिन एंड्रॉइड एक स्पष्ट एसडीके मेथड इनवोकेशन (handleDeepLink) का उपयोग करता है जबकि आईओएस डेलीगेट कॉलबैक (getWakeUpParams) के माध्यम से परिणाम को उजागर करता है।

अतिरिक्त एसडीके क्षमताएं: पंजीकरण रिपोर्टिंग और रेफरल-शेयरिंग एट्रिब्यूशन को संस्करण-विशिष्ट एपीआई के माध्यम से उजागर किया जा सकता है। इन तरीकों को कॉल करने से पहले अपने तैनात रिलीज के साथ वितरित सार्वजनिक हेडर या एसडीके इंटरफेस परिभाषाओं से परामर्श करें।

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

getInstallParam और getWakeUpParams एपीआई परिभाषाओं के बीच क्या अंतर है?

`getInstallParam` (और iOS `getInstallParmsCompleted`) एक एसिंक्रोनस डिफ़र्ड डीप-लिंकिंग एपीआई है जिसे उपयोगकर्ता द्वारा पहली बार ऐप इंस्टॉल करने और खोलने पर पास किए गए पैरामीटर को क्वेरी करने के लिए डिज़ाइन किया गया है। इसके विपरीत, `getWakeUpParams` (और एंड्रॉइड `handleDeepLink`) एक रीयल-टाइम डीप-लिंकिंग एपीआई है जो बाहरी लिंक से पहले से इंस्टॉल किए गए ऐप के लॉन्च होने पर सिस्टम लॉन्च इवेंट (यूनिवर्सल लिंक या यूआरएल स्कीम) को इंटरसेप्ट करता है।

पैरामीटर पुनर्प्राप्ति के दौरान एसडीके नेटवर्क टाइमआउट को कैसे संभालता है?

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

क्या यूआई नेविगेशन के लिए एसडीके एपीआई कॉलबैक मुख्य थ्रेड पर निष्पादित होने की गारंटी हैं?

जब तक तैनात एसडीके रिलीज के लिए स्पष्ट रूप से प्रलेखित न हो, डेवलपर्स को कॉलबैक थ्रेड सहबद्धता नहीं माननी चाहिए। क्रैश-मुक्त यूआई संक्रमण और थ्रेड सुरक्षा सुनिश्चित करने के लिए, यूआई नेविगेशन या दृश्य अपडेट को मुख्य थ्रेड पर स्पष्ट रूप से प्रेषित करें (जैसे, iOS पर `DispatchQueue.main.async` का उपयोग करना या एंड्रॉइड पर `runOnUiThread` / कोरुटीन डिस्पैचर्स का उपयोग करना)।

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

एट्रिब्यूशन एसडीके एपीआई परिभाषाओं में महारत हासिल करना मोबाइल इंजीनियरिंग टीमों को विश्वसनीय ऑनबोर्डिंग यात्राएं बनाने और चैनल एनालिटिक्स को ट्रैक करने में सक्षम बनाता है। डिफ़र्ड इंस्टॉल क्वेरी (getInstallParam / getInstallParmsCompleted) और रीयल-टाइम लिंक इंटरसेप्शन (getWakeUpParams / handleDeepLink) के बीच अंतर को समझकर, डेवलपर्स पैरामीटर हानि को कम कर सकते हैं और गतिशील पृष्ठ रूटिंग को लागू कर सकते हैं।

जैसे-जैसे मोबाइल ऑपरेटिंग सिस्टम पृष्ठभूमि कार्य की बाधाओं और नेटवर्क गोपनीयता सैंडबॉक्स को परिष्कृत करते हैं, अच्छी तरह से परिभाषित एसडीके एपीआई सिग्नेचर पर भरोसा करना एंड्रॉइड और आईओएस संस्करणों में लगातार डेटा हैंडलिंग सुनिश्चित करता है। थ्रेड सुरक्षा दिशानिर्देशों का पालन करना, स्थानीय स्थिति स्थिरता का प्रबंधन करना, और एसिंक्रोनस टाइमआउट स्थितियों को संभालना स्थिर एप्लिकेशन लॉन्च का समर्थन करता है.

इन एपीआई परिभाषाओं को अपने प्रोजेक्ट में एकीकृत करने के लिए तैयार डेवलपर OpoInstall developer console पर पंजीकरण कर सकते हैं या पूर्ण प्लेटफ़ॉर्म दिशानिर्देशों के लिए mobile attribution implementation reference से परामर्श कर सकते हैं।