Tray, ई-कॉमर्स कॉन्टेंट मैनेजमेंट सिस्टम (सीएमएस) की सेवा देने वाली कंपनी है. इसे ब्राज़ील के रीटेल मार्केट में 20 से ज़्यादा सालों से सेवा देने का अनुभव है. व्यापारी/कंपनी/कारोबारी, Tray's इन्फ़्रास्ट्रक्चर पर ऑनलाइन स्टोर चलाते हैं. यह इन्फ़्रास्ट्रक्चर, कारोबार की लॉजिस्टिक, पेमेंट, प्रमोशन, और रिपोर्टिंग को मैनेज करने के लिए सेवाएं और इंटिग्रेशन भी उपलब्ध कराता है.
Tray, LWSA ग्रुप का सदस्य है और ई-कॉमर्स क्षेत्र में एक अहम भूमिका निभाता है. Tray पर 1,80, 000 से ज़्यादा ग्राहक भरोसा करते हैं. इन ग्राहकों ने साल 2024 की पहली तिमाही में, 3 अरब डॉलर से ज़्यादा का जीएमवी जनरेट किया.
तीसरे पक्ष की कुकी पर निर्भरता
Tray's तकनीकी आर्किटेक्चर में तीसरे पक्ष की कुकी (3PC) का इस्तेमाल किया जाता है, ताकि व्यापारी/कंपनी/कारोबारी की साइटों पर तीसरे पक्ष की सुविधाएं उपलब्ध कराई जा सकें. खास तौर पर, स्टोर मैनेजमेंट के लिए इस्तेमाल किए जाने वाले व्यापारी/कंपनी/कारोबारी के बैकऑफ़िस एडमिनिस्ट्रेशन पैनल के लिए. ये कुकी, तीसरे पक्ष के उन ऐप्लिकेशन से दिखाए जाने वाले कॉन्टेंट को रेंडर करने के लिए ज़रूरी हैं जो कारोबारी या कंपनी के डोमेन के अलावा किसी दूसरे डोमेन पर होस्ट किए जाते हैं. Tray's की रिसर्च से पता चला है कि ब्राउज़र में 3PC को मैनेज करने के तरीके में किए गए बदलावों की वजह से, इस सुविधा में रुकावट आ सकती है. Tray, कई ऑनलाइन खुदरा दुकानदारों के लिए ज़रूरी इन्फ़्रास्ट्रक्चर के तौर पर काम करता है. इसलिए, यह ज़रूरी है कि कारोबार पहले की तरह ही चलता रहे. भले ही, Chrome और दूसरे ब्राउज़र में 3PC को मैनेज करने के तरीके में बड़े बदलाव किए जा रहे हों.
इस केस स्टडी में, Tray's संभावित रुकावटों का पता लगाने, संभावित समाधानों का आकलन करने, और साइटों को 3PC में होने वाले बदलावों के लिए तैयार करने के लिए, लागू किए गए समाधान के बारे में बताया गया है.
तकनीकी आर्किटेक्चर
Microservices
Tray अपने डोमेन, tray.com.br पर सभी स्टोरफ़्रंट और बैक-ऑफ़िस ऐप्लिकेशन होस्ट करता है. व्यापारी/कंपनी/कारोबारी, अपने कस्टम डोमेन से इन ऐप्लिकेशन को दिखाने के लिए, CNAME का इस्तेमाल कर सकते हैं. इस सेटअप के साथ, खरीदारों को सिर्फ़ स्टोर का डोमेन दिखेगा, जैसे कि merchant.example. Tray, सुविधाएं और क्षमताएं देने के लिए, माइक्रोसर्विस आर्किटेक्चर का इस्तेमाल करता है. इस तरीके में, अलग-अलग ऐप्लिकेशन का इस्तेमाल किया जाता है. हर ऐप्लिकेशन किसी खास फ़ंक्शन पर फ़ोकस करता है. इसके बाद, इन माइक्रोसर्विस को उनके फ़ंक्शन के आधार पर स्कोप में बांटा जाता है:
- स्टोर: इसमें ऐसे ऐप्लिकेशन शामिल होते हैं जो स्टोरफ़्रंट की सुविधाओं के लिए ज़िम्मेदार होते हैं. जैसे, प्रॉडक्ट डिसप्ले, खोज, और थीम मैनेजमेंट.
- परचेज़ फ़्लो: यह खरीदारी के दौरान, शॉपिंग कार्ट, चेकआउट की प्रोसेस, और खरीदार के इंटरैक्शन को मैनेज करता है.
- स्टोर मैनेजमेंट: यह एडमिन, रिपोर्टिंग, और डेटा इंपोर्ट जैसे टास्क के लिए, बैक-ऑफ़िस ऐप्लिकेशन उपलब्ध कराता है.
- इंटिग्रेशन: इसकी मदद से, बाहरी प्लैटफ़ॉर्म से कनेक्ट किया जा सकता है. इससे, अलग-अलग मार्केटप्लेस पर लिस्टिंग दिखाने, लॉजिस्टिक मैनेज करने वगैरह की सुविधा मिलती है.
बैकऑफ़िस ऐप्लिकेशन
Backoffice, स्टोर मैनेजमेंट का मुख्य ऐप्लिकेशन है. यह Tray पर सेलर के वर्चुअल स्टोर के लिए, मुख्य एडमिन पैनल के तौर पर काम करता है. इस पैनल की मदद से, सेलर ये काम कर सकते हैं:
- प्रॉडक्ट रजिस्टर करना
- शिपिंग और पेमेंट के तरीके कॉन्फ़िगर करना
- प्रमोशन बनाना
- लाइव ब्रॉडकास्ट मैनेज करना
- ऑर्डर फ़्लो को मॉनिटर करना
- बिक्री की रिपोर्ट मॉनिटर करना
Backoffice में कई माइक्रोसर्विस एक ही इंटरफ़ेस में काम करती हैं. इनमें से कुछ Tray और कुछ तीसरे पक्ष के हैं. इसलिए, तीसरे पक्ष की कुकी को मैनेज करने के तरीके में हुए बदलावों की वजह से, Backoffice में रुकावटें आ सकती हैं.
कारोबारी या कंपनी के हिसाब से कस्टमाइज़ेशन के लिए CNAME
Tray, स्टोरफ़्रंट को आसानी से इंटिग्रेट करने के लिए, CNAME रिकॉर्ड का इस्तेमाल करता है.
नया स्टोर सेट अप करते समय, कारोबारी या कंपनियां Tray's डोमेन, tray.com.br पर होस्ट किए गए ऐप्लिकेशन पर अनुरोध भेजने के लिए, CNAME सेट अप कर सकती हैं. इसका मतलब है कि जब कोई खरीदार कारोबारी या कंपनी की वेबसाइट (जैसे, example.com) पर जाता है, तो CNAME रिकॉर्ड उसे Tray's डोमेन पर रीडायरेक्ट करता है. हालांकि, पता बार में कारोबारी या कंपनी का यूआरएल बना रहता है. इससे उपयोगकर्ता को बेहतर अनुभव मिलता है, क्योंकि कॉन्टेंट सीधे व्यापारी/कंपनी/कारोबारी की वेबसाइट से दिखता है.
CNAME के बारे में जानकारी
CNAME रिकॉर्ड, फ़ोन पर कॉल फ़ॉरवर्ड करने की सुविधा की तरह ही काम करते हैं. मान लें कि आपने अपने किसी दोस्त को 555-0199 पर कॉल किया, लेकिन उसने जवाब नहीं दिया. हो सकता है कि कॉल को किसी दूसरे नंबर पर, जैसे कि 555-0100 पर वॉइसमेल पर फ़ॉरवर्ड कर दिया जाए. हालांकि, कॉल करने वाले व्यक्ति को इस रीडायरेक्ट के बारे में कोई जानकारी नहीं होती. फ़ोन आसानी से कनेक्ट हो जाता है और आपके दोस्त के वॉइसमेल में अब भी उसका ओरिजनल नंबर (555-0199) दिखता है.
CNAME रिकॉर्ड, वेबसाइटों के लिए भी इसी तरह काम करते हैं. जब कोई उपयोगकर्ता किसी व्यापारी/कंपनी/कारोबारी की वेबसाइट (जैसे, example.com) पर जाता है, तो CNAME रिकॉर्ड उसके अनुरोध को चुपचाप किसी दूसरे सर्वर पर रीडायरेक्ट कर सकता है. जैसे, assets.example.com. हालांकि, उपयोगकर्ता और ब्राउज़र के नज़रिए से, सब कुछ example.com पर होता है. पता बार में, कारोबारी/कंपनी/कारोबारी की वेबसाइट का यूआरएल दिखता है. साथ ही, उपयोगकर्ता वेबसाइट से ऐसे इंटरैक्ट करता है जैसे कि कॉन्टेंट सीधे उस डोमेन से आया हो.
संभावित रुकावटों का आकलन करना
Tray's 3PC हैंडलिंग में किए जाने वाले बदलावों के विश्लेषण से, बैकऑफ़िस ऐप्लिकेशन में रुकावटों का पता चला. जब 3PC ब्लॉक किए गए थे, तो बैकएंड पेजों में एम्बेड किए गए iframe में, अलग-अलग डोमेन से पेज लोड करते समय समस्याएं आ रही थीं. यह उन इंटरनल डोमेन पर लागू होता है जो कंपनी की अपनी सेवाओं से जुड़े होते हैं. साथ ही, यह उन बाहरी पार्टनर पर भी लागू होता है जो Tray के एपीआई का इस्तेमाल करके, उससे इंटिग्रेट होने वाले ऐप्लिकेशन डेवलप करते हैं.
उदाहरण के लिए, backoffice.merchant.example पर मौजूद एक ऐसे पेज की कल्पना करें जिसमें tray.com.br और तीसरे पक्ष के अन्य लोगों या कंपनियों का होस्ट किया गया कॉन्टेंट एम्बेड किया गया हो.
ब्राउज़र, डोमेन के अंतर की वजह से, एम्बेड किए गए इस कॉन्टेंट को तीसरे पक्ष के तौर पर लेते हैं. इस वजह से, इस कॉन्टेंट पर तीसरे पक्ष से जुड़ी पाबंदियां लागू हो सकती हैं.
इस सेटअप की वजह से कई समस्याएं हो सकती हैं:
- सेशन बंद होना: ब्लॉक किए गए 3PC की वजह से, जिन सेशन पर असर पड़ा है वे बंद हो सकते हैं. इससे उपयोगकर्ताओं को कई बार साइन इन करना पड़ता है और उन्हें खराब अनुभव मिलता है. इसके अलावा, iframes के काम न करने की वजह से, Backoffice पेजों में रुकावट आ सकती है या उनमें अंतर हो सकता है.
- इंटिग्रेशन से जुड़ी चुनौतियां: Tray's के एपीआई का इस्तेमाल करके, उसके बैकएंड के साथ इंटिग्रेट करने वाले पार्टनर ऐप्लिकेशन और इंटरनल सेवाओं को, तीसरे पक्ष की पाबंदियों की वजह से ऐसी ही समस्याओं का सामना करना पड़ सकता है.
इस स्थिति को नीचे दिए गए इलस्ट्रेशन में दिखाया गया है:
- कोई उपयोगकर्ता,
merchant.exampleपर होस्ट किए गए Backoffice ऐप्लिकेशन को ऐक्सेस करता है. - एम्बेड किए गए ऐप्लिकेशन अलग-अलग डोमेन पर मौजूद होते हैं. कुछ
tray.com.brपर मौजूद होते हैं, जिसका मालिकाना हक Tray के पास होता है. वहीं, कुछ तीसरे पक्ष के वेंडर के डोमेन (third-party.example) पर मौजूद होते हैं. - डोमेन में अंतर होने की वजह से, 3PC से जुड़ी पाबंदियां ट्रिगर होती हैं. इससे, एम्बेड किए गए ऐप्लिकेशन में समस्याएं आ सकती हैं.
तीसरे पक्ष की कुकी की डिपेंडेंसी और उनके समाधानों का विश्लेषण करना
क्रिटिकल यूज़र जर्नी की जांच करना
Tray's टेस्टिंग और विश्लेषण का मकसद, वेबसाइट की परफ़ॉर्मेंस और उपयोगकर्ता अनुभव को बेहतर बनाना था. साथ ही, तीसरे पक्ष के इंटिग्रेशन पर फ़ोकस किया गया था. साथ ही, आने वाले समय में 3PC के बिना ब्राउज़ करने वाले कई उपयोगकर्ताओं के लिए तैयारी की गई थी.
Tray ने Privacy Sandbox विश्लेषण टूल (PSAT) और Chrome DevTools का इस्तेमाल करके, ग्राहकों और व्यापारियों/कंपनियों के लिए मुख्य उपयोगकर्ता फ़्लो का विश्लेषण किया. इसमें, iframe में पेज लोड होने की जांच करना, यह देखना कि उपयोगकर्ता के सेशन मान्य हैं या नहीं, और यह पक्का करना शामिल था कि तीसरे पक्ष के ऐप्लिकेशन उम्मीद के मुताबिक काम करते रहे. टेस्टिंग में, अलग-अलग उपयोगकर्ता भूमिकाओं, डिवाइसों, और ब्राउज़र (इनमें Chrome, Firefox, और Safari शामिल हैं) का इस्तेमाल किया गया. इससे, अलग-अलग ब्राउज़र के साथ काम करने से जुड़ी संभावित समस्याओं का पता लगाया जा सका. Tray ने कुकी को अलग-अलग कैटगरी में बांटने और उपयोगकर्ता अनुभव पर उनके असर का आकलन करने के लिए, PSAT और Chrome डेवलपर टूल का इस्तेमाल किया.
यह विश्लेषण, उपयोगकर्ताओं को बेहतर अनुभव देने के लिए एक अहम कदम था. इससे आने वाले समय में, तीसरे पक्ष की कुकी के सीमित या उपलब्ध न होने की स्थिति में भी, उपयोगकर्ताओं को बेहतर अनुभव दिया जा सकेगा.
Privacy Sandbox के समाधानों का विश्लेषण करना
Storage Access API
स्टोरेज ऐक्सेस एपीआई (एसएए) से Tray's से जुड़ी रुकावटों को ठीक किया जा सकता है. साथ ही, यह सभी मुख्य ब्राउज़र पर काम करता है. हालांकि, यह कारोबार के लिए दो मुख्य वजहों से सबसे सही नहीं था:
- एम्बेड किए गए कॉन्टेंट को सिर्फ़ उस ऑरिजिन पर कुकी ऐक्सेस करने की ज़रूरत होती है जहां इसे एम्बेड किया गया था, न कि एक से ज़्यादा साइटों पर एक ही कुकी ऐक्सेस करने के लिए.
- एसएए से जुड़े ब्राउज़र प्रॉम्प्ट सही नहीं थे. खास तौर पर, इसलिए, क्योंकि सभी साइटों पर उपयोगकर्ताओं को ट्रैक करने के लिए कुकी का इस्तेमाल नहीं किया जा रहा था.
सीएचआईपीएस
CHIPS ने क्रॉस-साइट एम्बेड के लिए, बेहतरीन उपयोगकर्ता अनुभव के साथ एक बेहतरीन समाधान दिया. Partitioned एट्रिब्यूट को लागू करना आसान था. साथ ही, Chrome में उपयोगकर्ताओं के इंटरैक्शन पर इसका कोई असर नहीं पड़ा. जब Tray अपनी सेवा में बदलाव कर रहा था, तब अन्य मुख्य ब्राउज़र में CHIPS काम नहीं करता था. इसलिए, उन्होंने अपने मालिकाना हक वाले और मैनेज किए जा रहे एम्बेड को, टॉप-लेवल ऐप्लिकेशन के तौर पर एक ही साइट पर ले जाने का विकल्प चुना, ताकि सभी ब्राउज़र पर एक जैसा अनुभव दिया जा सके. तीसरे पक्ष का एम्बेड किया गया कॉन्टेंट, Chrome में CHIPS पर निर्भर करता है. साथ ही, यह अन्य ब्राउज़र में नई विंडो (पहले पक्ष का कॉन्टेक्स्ट) खोलता है. हालांकि, Tray's के शुरुआती लागू होने के बाद, Firefox ने पुष्टि की है कि वह जल्द ही CHIPS को लॉन्च करेगा. साथ ही, Safari ने टेक्नोलॉजी की झलक के साथ, Partitioned एट्रिब्यूट के लिए सहायता जोड़ना शुरू कर दिया है.
हमें लगता है कि CHIPS एक बेहतरीन सलूशन है. हमें यह देखकर खुशी हो रही है कि इसे कई ब्राउज़र में अपनाया जा रहा है. हमने पहले पक्ष की साइटों पर ट्रैकिंग को माइग्रेट करने के साथ-साथ, सीएचआईपीएस का समाधान भी जारी रखने का फ़ैसला लिया है. इससे, हम सभी ब्राउज़र के लिए, सीएचआईपीएस को अपनाने से पहले ही काम कर पाएंगे.
— ताकाशी तनाका, Tray के सीटीओ
ब्राउज़र के साथ काम करना, W3C, और स्टैंडर्ड
Chrome, स्टैंडर्ड कम्यूनिटी में अहम भूमिका निभाता है. W3C के वर्किंग ग्रुप और PrivacyCG जैसे कम्यूनिटी ग्रुप में सक्रिय तौर पर हिस्सा लेना ज़रूरी है. इससे, ब्राउज़र के बड़े नेटवर्क को नई वेब टेक्नोलॉजी अपनाने के लिए बढ़ावा मिलता है.
Privacy Sandbox, वेब नेटवर्क के साथ काम करता है. इससे, इंडस्ट्री के सुझावों और यूज़र ऐक्टिविटी के आधार पर, CHIPS जैसे एपीआई को लगातार बेहतर बनाया जा सकता है. पारदर्शी और स्टैंडर्ड के हिसाब से तैयार किए गए इस तरीके की मदद से, CHIPS को अन्य मुख्य ब्राउज़र में अपनाने में मदद मिली है.
तीसरे पक्ष की कुकी पर निर्भरता को हमेशा के लिए हल करना
Tray, व्यापारियों/कंपनियों/कारोबारियों और उनके ग्राहकों को सभी तरह के डिवाइसों और ब्राउज़र पर काम करता है. सिर्फ़ CHIPS पर आधारित तरीके को प्राथमिकता दी जाती, लेकिन उस समय CHIPS के साथ काम न करने वाले अन्य ब्राउज़र के साथ काम करने के लिए, कुछ और बदलाव भी किए गए थे.
Tray's के ज़रिए, तीन पीसी के उपलब्ध न होने पर होने वाली रुकावटों को ठीक करने के लिए, दो मुख्य रणनीतियों का इस्तेमाल किया गया.
1. इंटरनल ऐप्लिकेशन
पूरी तरह से काम करने वाली Tray माइक्रोसर्विस को अपडेट किया गया है. इनमें लाइव शॉप, ड्रॉपशिपिंग, और इनवॉइस जारी करने वाली सेवा शामिल है. ऐसा इसलिए किया गया है, ताकि एम्बेड किए गए कॉन्टेंट के सोर्स को व्यापारी/कंपनी/कारोबारी के सेट अप किए गए CNAME को इनहेरिट किया जा सके. आसान शब्दों में कहें, तो एम्बेड किए गए कॉन्टेंट को पहले पक्ष के तौर पर अपडेट किया गया था. ऐसा इसलिए किया गया, ताकि तीसरे पक्ष की कुकी में हुए बदलावों की वजह से कोई रुकावट न आए.
2. तीसरे पक्ष के ऐप्लिकेशन
Backoffice की मदद से ऐक्सेस किए जाने वाले तीसरे पक्ष के ऐप्लिकेशन के लिए, Tray ने ज़्यादा डाइनैमिक तरीका लागू किया है. यह इस तरह से काम करता है:
- अलग-अलग स्टोरेज में कुकी सेव करने की सुविधा वाले एट्रिब्यूट को लागू करना:
Partitionedकुकी एट्रिब्यूट को भरोसेमंद वेंडर के लिए लागू किया गया था. इससे तीसरे पक्ष के ऐप्लिकेशन, CHIPS की सुविधा वाले ब्राउज़र पर कुकी को असरदार तरीके से सेट कर सकते हैं. - तीसरे पक्ष की कुकी ब्लॉक होने पर: अगर उपयोगकर्ता का ब्राउज़र तीसरे पक्ष की कुकी को ब्लॉक करता है, तो तीसरे पक्ष का ऐप्लिकेशन नई (पहले पक्ष की) विंडो में खुलता है. इससे, ऐप्लिकेशन खोलने में आने वाली समस्याओं से बचा जा सकता है. साथ ही, 3PC से जुड़ी पाबंदियों के बावजूद, ऐप्लिकेशन के लगातार काम करने की सुविधा मिलती है.
- तीसरे पक्ष की कुकी को अनुमति कब दी जाती है: अगर उपयोगकर्ता के ब्राउज़र में तीसरे पक्ष की कुकी को अनुमति दी जाती है, तो ऐप्लिकेशन पहले की तरह ही iframe में खुलता रहेगा.
समाधान को विज़ुअलाइज़ करना
इस इमेज में इसका समाधान बताया गया है. स्टोर के मुख्य डोमेन (merchant.example) को इनहेरिट करने पर, एम्बेड किए गए सभी ऐप्लिकेशन एक ही सोर्स से दिखते हैं. इससे सभी विजेट एक-दूसरे के लिए पहले पक्ष के हो जाते हैं. इसका मतलब है कि तीसरे पक्ष की पाबंदियां लागू नहीं होतीं. ये सभी फ़्रेम एक-दूसरे के लिए पहले-पक्ष के तौर पर काम करते हैं. इसलिए, निजता के सिद्धांत, पहले-पक्ष की अन्य कुकी के सिद्धांतों के हिसाब से काम करते हैं: इन्हें सिर्फ़ पहले-पक्ष के संदर्भ में ऐक्सेस किया जा सकता है. साथ ही, ये क्रॉस-साइट ट्रैकिंग की संभावना को सीमित करते हैं.
Tray के मालिकाना हक वाली तीसरे पक्ष की सेवाएं, CHIPS कुकी सेट करने के लिए Partitioned एट्रिब्यूट का इस्तेमाल करती हैं. इसका मतलब है कि उन्हें सिर्फ़ उसी संदर्भ में ऐक्सेस किया जा सकता है जिसमें उन्हें सेट किया गया था. साथ ही, इससे अलग-अलग साइटों पर ट्रैकिंग की संभावना कम हो जाती है.
अहम जानकारी
- वेब पर निजता बनाए रखने के लिए, एक ही तरीका सभी के लिए काम नहीं करता. उपयोगकर्ताओं को बेहतर अनुभव देने के साथ-साथ, उनकी निजता बनाए रखने के कई तरीके हैं.
- एक ही टॉप-लेवल डोमेन में संसाधनों को इकट्ठा करने से, तीसरे पक्ष की कुकी से जुड़ी पाबंदियों के बावजूद कुकी काम करती हैं.
- सभी रिसॉर्स को एक ही टॉप-लेवल साइट पर माइग्रेट करने के मुकाबले, सीएचआईपीएस का इस्तेमाल करना आसान हो सकता है.
- Tray's का सलूशन टिकाऊ है और सभी ब्राउज़र पर काम करता है. CHIPS के लिए सहायता को लागू करने वाले अन्य ब्राउज़र के साथ, इसे Tray's जैसी स्थितियों के लिए, क्रॉस-ब्राउज़र के लिए भरोसेमंद समाधान माना जा सकता है.