क्या WebMCP न्यूज़लेटर और डिस्काउंट ऑफ़र मोडल को ख़त्म कर देगा? हमें उम्मीद है। जानने के लिए हमने अपनी साइट पर एक रजिस्टर कर दिया।

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

वह पॉपअप डिज़ाइन की नाकामी नहीं है। वह ठीक वही कर रहा है जिसके लिए बनाया गया था, और इतना अच्छा करता है कि मार्केटिंग टीम में कोई उसे हटाने की बहस नहीं कर रहा।

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

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

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

WebMCP इसमें से कुछ भी नहीं छूता। वह जो बदलता है वह तरीक़ा है। कोई पेज अपने साइनअप को एक फ़ंक्शन के रूप में प्रकाशित कर सकता है, सादी भाषा में बता सकता है कि वह क्या करता है, और विज़िटर के लिए काम कर रहे AI एजेंट को उसे तब कॉल करने दे सकता है जब विज़िटर सचमुच ऑफ़र माँगे। पता फिर भी पहुँचता है, छूट फिर भी भेजी जाती है, और पढ़ने में कुछ भी बाधा नहीं डालता।

पढ़ने वाले के लिए यही पूरा इनाम है। सवाल यह है कि आज इसमें से कितना बटोरा जा सकता है, और ईमानदार जवाब है: एक हिस्सा।

पॉपअप हटने पर विज़िटर को कैसा लगता है

यहाँ वही ऑफ़र है, दो तरीक़ों से जुटाया हुआ। बाईं ओर वह है जो विज़िटर को आज मिलता है। दाईं ओर वह है जो उसी व्यक्ति को तब मिलता है जब पेज ने अपने साइनअप को ऐसी चीज़ के रूप में प्रकाशित कर दिया हो जिसे उसका असिस्टेंट पूरा कर सके।

पॉपअप को असल में ट्रैफ़िक का बदलाव ख़त्म करता है

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

यह सौदा तभी टूटता है जब कोई दूसरा तरीक़ा बिना टोके वही पते जुटाने लगे, और वह एक-एक विज़िट करके टूटता है।

पॉपअप सिर्फ़ स्क्रीन देख रहे इंसान पर काम करता है। जब पढ़ने का काम कोई असिस्टेंट करता है, तब न ढकने के लिए कोई स्क्रीन होती है और न किसी हिचक का समय नापा जा सकता है, इसलिए वह विज़िट कोई पता नहीं देती, चाहे पॉपअप कितना ही अच्छा ट्यून किया गया हो।

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

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

इसमें से कुछ भी किसी स्पेसिफ़िकेशन के तय किए शेड्यूल पर नहीं आता। यह तब आता है जब पर्याप्त लोग वेब को ऐसी किसी चीज़ के ज़रिए पढ़ने लगें जो उनकी ओर से पढ़ती है, जो स्टैंडर्ड का सवाल नहीं बल्कि ट्रैफ़िक का सवाल है, और आज आप उसे अपने ही लॉग में माप सकते हैं।

साफ़ कहने लायक बात यह है कि मंज़िल अच्छी है। ऐसा वेब जहाँ ऑफ़र हर उस व्यक्ति के लिए उपलब्ध हो जो उसे माँगे, और उन सबके लिए अदृश्य रहे जिन्होंने नहीं माँगा, पाठक के लिए बेहतर है और ब्रांड के लिए बुरा नहीं। यह संयोग दुर्लभ है, और यही वजह है कि पहुँच के आने का इंतज़ार करने के बजाय इसके लिए जल्दी बनाना सार्थक है।

Apple की आपत्ति यह है कि साइट को कभी पता ही न चले कि एजेंट चला रहा है

Apple के दो इंजीनियरों ने जून 2026 के दौरान सार्वजनिक स्टैंडर्ड-पोज़िशन थ्रेड में WebKit की आपत्ति रखी, और 11 जून को स्थिति विरोध के रूप में तय हुई। वे छह वजहें देते हैं, और पहली वजह इस बात पर जाती है कि एजेंट होता क्या है।

WebKit की स्थिति मानती है कि उपयोगकर्ता के लिए काम कर रहा एजेंट “असल में सहायक तकनीक है: उसे साइट को वैसे ही चलाना चाहिए जैसे उपयोगकर्ता चलाता, और साइट को उसे अलग बर्ताव के लिए छाँटना नहीं चाहिए।” WebMCP इसका उलटा करता है। वह “एजेंट चला रहा है” को एक देखने योग्य तथ्य बना देता है, और एक बार वह अलग से संबोधित करने लायक हो जाए, तो दोनों सतहों को बराबर रखने वाला कुछ नहीं बचता। साइट एजेंट को ऐसी क्षमताएँ दे सकती है जो वह अपने ही इंटरफ़ेस से रोक रखती है, या एजेंट से रोक सकती है, जिसे वे “स्क्रीन-रीडर को ब्लॉक करने वाली समस्या, लेकिन AI एजेंट पर लागू” कहते हैं।

वे भरोसेमंदी के वादे पर भी शक करते हैं। एजेंट अब भी टूल का नाम और विवरण पढ़कर उसे चुनता है, और स्पेसिफ़िकेशन खुद मानता है कि ये अस्पष्ट और असत्यापनीय हैं, क्योंकि “इसकी कोई गारंटी नहीं है कि किसी WebMCP टूल का घोषित इरादा उसके असली बर्ताव से मेल खाता है।” टाइप की गई स्कीमा किसी आर्ग्युमेंट का स्वरूप तय करती है, वह अर्थ नहीं जो एजेंट को अनुमान से निकालना है, इसलिए उनके पढ़ने के हिसाब से भंगुरता ख़त्म होने के बजाय पेज से निकलकर टूल के विवरणों में चली जाती है।

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

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

उनके बताए अपरिवर्तनीय सिद्धांतों में से एक सीधे उसी बात की ओर इशारा करता है जिस पर यह लेख है: “कुछ उपयोगकर्ता एजेंट इस्तेमाल नहीं करेंगे, या नहीं कर सकते, इसलिए नतीजा सभी उपयोगकर्ताओं के फ़ायदे का होना चाहिए और उन्हें विशेषाधिकार नहीं देना चाहिए जिनके पास एजेंट है।”

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

Google के संपादकों ने उसी थ्रेड में जवाब दिया और पूछा कि इंपेरेटिव API हटाए बिना WebKit को क्या संतुष्ट करेगा। जवाब यह था कि वे बिंदुवार जवाब नहीं देंगे, क्योंकि हर सवाल यह मान लेता है कि यह तरीक़ा सही है, और उन्होंने नए सिरे से शुरू करने का प्रस्ताव रखा: एक नया कम्युनिटी ग्रुप, किसी समाधान से पहले समस्या की परिभाषा, और अक्टूबर 2026 के अंत में TPAC के आसपास एक वर्कशॉप।

कोई iPhone यह नहीं चला सकता, iPhone का Chrome भी नहीं

Apple की स्थिति सिर्फ़ किसी स्टैंडर्ड थ्रेड में एक वोट नहीं है। वह इस प्लेटफ़ॉर्म के हर ब्राउज़र के लिए इस सुविधा का फ़ैसला कर देती है।

आज iOS पर आने वाला हर ब्राउज़र WebKit से रेंडर करता है। iPhone का Chrome Google के इंटरफ़ेस में लिपटा Safari का इंजन है, और Edge, Firefox तथा बाक़ी सबका भी यही हाल है। इसलिए WebKit जिस सुविधा को लागू करने से मना कर दे, वह iPhone पर उपलब्ध नहीं होती, चाहे कोई किसी भी ब्राउज़र आइकन पर टैप करे।

यह धीरे-धीरे बदल सकता है। UK की Competition and Markets Authority ने Apple की इंजन संबंधी शर्त को अपने Strategic Market Status नियम का उल्लंघन माना, जिसमें कंप्लायंस योजना जून 2026 में देनी थी और बदलाव शरद 2026 में iOS 20 में आने की उम्मीद है, जनवरी 2027 में पूरी कंप्लायंस से पहले। EU के Digital Markets Act ने 2024 से वैकल्पिक इंजन की अनुमति दे रखी है। व्यवहार में दोनों में से किसी ने एक भी नहीं निकलवाया: किसी ब्राउज़र निर्माता ने App Store से वैकल्पिक इंजन जारी नहीं किया, और Google तथा Mozilla, दोनों के पोर्ट अब तक जारी नहीं हुए हैं।

किसी ईकॉमर्स ब्रांड के लिए यही वह आँकड़ा है जो किसी भी स्पेसिफ़िकेशन की तारीख़ से ज़्यादा मायने रखता है, क्योंकि ज़्यादातर स्टोरफ़्रंट के ट्रैफ़िक का बड़ा हिस्सा iPhone से आता है और उसमें से कुछ भी आज किसी रजिस्टर किए गए टूल तक नहीं पहुँच सकता।

इसे परखने के लिए Chromium ब्राउज़र चाहिए, जो ज़्यादातर एजेंट पहले से इस्तेमाल करते हैं

पढ़ने का काम कर रहे एजेंट पहले से सही इंजन पर हैं। Claude Chrome के भीतर एक एक्सटेंशन के रूप में चलता है, Gemini Chrome में ही बना हुआ है, Copilot Edge में बैठता है, और Perplexity का Comet अपने आप में एक Chromium ब्राउज़र है। डेस्कटॉप पर एजेंटिक ब्राउज़िंग आज भारी बहुमत से Chromium है, इसलिए इंजन शायद ही कभी अड़चन होता है।

जो अड़चन लोग चूक जाते हैं वह यह है कि आपका पेज पढ़ रहा हर असिस्टेंट ब्राउज़र होता ही नहीं। चैट विंडो में ChatGPT या Claude से कोई URL खोलने को कहिए और फ़ेच आम तौर पर किसी सर्वर पर होता है: आपका HTML लाया जाता है, कोई JavaScript नहीं चलता, और कोई टूल सूची कभी बनती ही नहीं। वह असिस्टेंट आपके पेज का एक-एक शब्द पढ़ सकता है और फिर भी उसे पता नहीं होगा कि उस पर कोई टूल रजिस्टर था। टूल सिर्फ़ वही एजेंट देखता है जो किसी असली Chromium पेज के भीतर काम कर रहा हो, जिसका आज मतलब Chrome में Gemini जैसा कुछ, या ऐसा एक्सटेंशन है जो खोज खुद लागू करता हो।

अड़चन यह है कि सुविधा अब भी एक गेट के पीछे है, और उस गेट से निकलने के दो रास्ते हैं।

साइट Chrome के ओरिजिन ट्रायल में नाम लिखाती है और टोकन सर्व करती है। प्रोडक्शन स्टोर यही रास्ता लेता है, और इसमें तीन क़दम हैं।

ओरिजिन को developer.chrome.com/origintrials/#/register_trial/4163014905550602241 पर रजिस्टर कीजिए, जो WebMCP का ट्रायल है और Chrome 149 से Chrome 156 तक चलता है। वही ओरिजिन दर्ज कीजिए जो असल में आपके पेज सर्व करता है, सबडोमेन समेत, क्योंकि example.com के लिए जारी किया गया टोकन www.example.com को कवर नहीं करता। अगर आपका एपेक्स www पर रीडायरेक्ट करता है, तो www होस्ट रजिस्टर कीजिए और सबडोमेन मैचिंग छोड़ दीजिए, क्योंकि रीडायरेक्ट कभी कोई डॉक्यूमेंट लोड नहीं करता और इसलिए उसे टोकन की ज़रूरत ही नहीं पड़ती।

जो टोकन वह आपको देता है उसे सर्व कीजिए, या तो रिस्पॉन्स हेडर के रूप में या हर उस पेज के head में मेटा टैग के रूप में जो कोई टूल रजिस्टर करता है:

<meta http-equiv="origin-trial" content="YOUR_TOKEN_HERE">

इसे तभी भेजिए जब आपके पास टोकन हो। ख़ाली या एक्सपायर हो चुका टोकन हर पेज लोड पर कंसोल में एरर लिखता है, इसलिए ख़ाली एट्रिब्यूट चिपकाकर भूल जाने के बजाय टैग को शर्त के साथ रखिए।

Edge अपना अलग ट्रायल चलाता है, अपने रजिस्ट्रेशन और अपने टोकन के साथ। एक में नाम लिखाने से दूसरे में कुछ नहीं होता।

या विज़िटर इसे खुद चालू करे, Chrome को --enable-blink-features=WebMCP के साथ चलाकर या chrome://flags में प्रयोगात्मक वेब प्लेटफ़ॉर्म सुविधाएँ चालू करके। यह डेवलपर का रास्ता है, ग्राहक का नहीं।

यह पेज पहला रास्ता लेता है। इस साइट का हर पेज एक WebMCP ओरिजिन ट्रायल टोकन सर्व करता है, इसलिए Chrome 149 से 156 में आने वाले विज़िटर को बिना कुछ चालू किए document.modelContext मिल जाता है, और ऊपर का पैनल यही बता देगा। वह टोकन 17 नवंबर 2026 को एक्सपायर होता है, जिसके बाद आम विज़िटर के लिए टूल तब तक चुप हो जाता है जब तक ट्रायल बढ़े या सुविधा जारी हो, और फ़ॉर्म वैसे ही चलता रहता है जैसे हमेशा चलता आया है। Safari पर, iPhone के किसी भी ब्राउज़र पर, या उस संस्करण रेंज के बाहर के Chrome पर मौजूद हर व्यक्ति को फ़ॉर्म ही दिखता है, और कुछ नहीं।

पुराने ट्यूटोरियल काम नहीं करेंगे, और उनमें से ज़्यादातर की तारीख़ ग़लत है

WebMCP कोई पूरा हो चुका वेब स्टैंडर्ड नहीं है। यह एक ड्राफ़्ट है, जिसे Google और Microsoft के इंजीनियर संपादित करते हैं, और ड्राफ़्ट तब भी बदलते हैं जब लोग उन पर पहले से बना रहे हों। यह वाला ऐसे बदला कि कोड टूट जाए।

जिस नाम को आप कॉल करते हैं वह बदल गया। पहले वह navigator.modelContext था और अब document.modelContext है। Chrome कुछ समय तक दोनों नाम स्वीकार करता रहा और डेवलपर को कंसोल में चेतावनी देता रहा, फिर Chrome 152 में उसने पुराना नाम स्वीकार करना बंद कर दिया, जो 25 अगस्त 2026 को सबके पास पहुँचा। पुराने तरीक़े से लिखा कोड धीमा नहीं होता या घटिया नहीं चलता। वह रुक जाता है।

हम इसे इसलिए उठा रहे हैं क्योंकि लेखों में इस बात पर मतभेद है कि यह कब हुआ। कई इस बदलाव को अगस्त 2026 में रखते हैं। प्रोजेक्ट का अपना इतिहास इसे मई में रखता है, तीन महीने पहले:

document.modelContext इस्तेमाल कीजिए। navigator तक पहुँचने वाला ट्यूटोरियल ऐसी चीज़ के लिए लिखा गया था जो अब मौजूद नहीं है, और किसी ब्लॉग पोस्ट की तारीख़ प्रोजेक्ट के अपने कमिट इतिहास की उसी तारीख़ से कम क़ीमती है।

समर्थन Chromium है और कुछ नहीं। Chrome ने जून 2026 में एक सार्वजनिक परीक्षण खोला जो Chrome 156 तक चलता है। Edge अपना परीक्षण Edge 150 से चलाता है और Brave के पास यह प्रयोगात्मक रूप से है, और ये दोनों Chrome के इंजन पर बने हैं। Apple ने 11 जून 2026 को औपचारिक रूप से इस प्रस्ताव का विरोध किया। Mozilla ने कोई पक्ष नहीं लिया है और एक प्रोटोटाइप खुला रखा है।

टूल एक फ़ंक्शन है और साथ में वे शब्द जो असिस्टेंट को बताते हैं कि उसे कब इस्तेमाल करना है

टूल एक डिक्शनरी है जिसमें एक नाम, एक विवरण, एक JSON इनपुट स्कीमा और एक execute कॉलबैक होता है। नाम में 1 से 128 ASCII अल्फ़ान्यूमेरिक अक्षर चलते हैं, साथ में अंडरस्कोर, हाइफ़न और बिंदु। सुरक्षित संदर्भ की शर्त पूरे इंटरफ़ेस पर लागू है, जिसमें getTools और executeTool भी शामिल हैं, और पहुँच tools नाम की एक Permissions Policy सुविधा से तय होती है जिसकी डिफ़ॉल्ट अनुमति सूची 'self' है।

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

साइनअप को टूल के रूप में लिखने में क़रीब तीस लाइन लगती हैं

पैटर्न के दो हिस्से हैं। ऑफ़र को टूल के रूप में रजिस्टर कीजिए, और मोडल को सिखाइए कि ऑफ़र ले लिए जाने के बाद वह पीछे हट जाए।

const modelContext = document.modelContext || navigator.modelContext;

if (modelContext) {
  modelContext.registerTool({
    name: "subscribe_to_offer",
    title: "Get the first-order discount code",
    description:
      "Starts a first-order discount signup by sending a confirmation email to an " +
      "address. The code arrives only after the address is confirmed. Call this when " +
      "the visitor asks for the discount or asks to join the mailing list.",
    inputSchema: {
      type: "object",
      properties: {
        email: {
          type: "string",
          format: "email",
          description: "The address the visitor wants the code sent to."
        }
      },
      required: ["email"]
    },
    annotations: { readOnlyHint: false },
    execute: async ({ email }, { signal }) => {
      const res = await fetch("/api/subscribe", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ email, source: "webmcp" }),
        signal
      });

      if (!res.ok) {
        return "The signup did not go through. The form near the foot of the page still works.";
      }

      // Silence the popup for the rest of this visit. Make it permanent from the
      // server when the confirmation link is clicked, never from here.
      try { sessionStorage.setItem("offer_asked", "1"); } catch (e) {}

      return "Confirmation email sent. The code arrives once the address is confirmed.";
    }
  });
}

टूल के चलते ही पॉपअप चुप हो जाता है, और यह सब करने का पूरा मक़सद यही है।

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

annotations: { readOnlyHint: false } एजेंट को बताता है कि यह कॉल कुछ पढ़ने के बजाय कुछ बदलती है। यह पहले से डिफ़ॉल्ट है, और इसे लिख देने से अगला पढ़ने वाला untrustedContentHint से सिर्फ़ एक लाइन दूर रह जाता है, जो उस हर टूल के लिए मायने रखने वाला एनोटेशन है जो ऐसा टेक्स्ट लौटाता है जिस पर एजेंट कार्रवाई करेगा।

signal एक अबॉर्ट सिग्नल है जो ब्राउज़र हर चलाए जाने वाले टूल को देता है। उसे रिक्वेस्ट में पास करने का मतलब है कि बीच में हार मान लेने वाला एजेंट किसी ऐसे व्यक्ति के लिए साइनअप पूरा होता नहीं छोड़ता जिसने माँगना बंद कर दिया।

पेज से यह पूछने का कोई तरीक़ा नहीं है कि कोई एजेंट उसे देख रहा है या नहीं। स्पेसिफ़िकेशन getTools, executeTool और एक toolchange इवेंट देता है, और इनमें से एक भी इस सवाल का जवाब नहीं देता। आपका अपना टूल कॉल होना ही इकलौता भरोसेमंद संकेत है जो आपको मिलता है। वही फ़्लैग लिखिए जिसे आपका पॉपअप पहले से जाँचता है, और वह उस विज़िटर के लिए उसी तरह चलना बंद कर देगा जैसे किसी के फ़ॉर्म भर देने के बाद बंद होता है।

इस पेज पर चल रहा संस्करण

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

उस इंप्लीमेंटेशन के तीन फ़ैसले नक़ल करने लायक हैं।

स्कीमा फ़ॉर्म से ज़्यादा माँगती है। फ़ॉर्म एक ही textarea है जिसके प्लेसहोल्डर में लोगों को अपना नाम और ईमेल शामिल करने की याद दिलाई जाती है। बहुत से संदेश इनमें से किसी के बिना आते हैं, और जिस संदेश पर जवाब देने का पता न हो वह ऐसा लीड है जिसका जवाब नहीं दिया जा सकता। टूल संदेश के साथ-साथ name, email और website को नामित इनपुट के रूप में घोषित करता है, इसलिए कॉल भर रहे एजेंट के पास उन्हें रखने की साफ़ जगह होती है।

लौटाया गया मान एजेंट को कुछ ऐसा देता है जिस पर वह कार्रवाई कर सके। execute कॉलबैक किसी भी चीज़ पर रिज़ॉल्व हो सकता है, और executeTool एजेंट को एक स्ट्रिंग देता है, जिसे वह पढ़ता है। जब कोई संदेश ईमेल पते के बिना आता है, तो हमारा टूल यह बता देता है और एजेंट से कहता है कि एक पता लेकर दूसरा संदेश भेजे। ऐसी पुष्टि जो सिर्फ़ “भेज दिया” कहती है, कॉल सुधारने का वह इकलौता मौक़ा गँवा देती है जो विज़िटर के वहीं मौजूद रहते मिलता है।

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

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

इसे चलते हुए कैसे देखें

यह साइट ट्रायल टोकन सर्व करती है, इसलिए कुछ भी चालू करने की ज़रूरत नहीं। यहाँ का कोई भी पेज Chrome 149 से 156 में खोलिए और इस लेख में पहले आया पैनल बता देगा कि आपके ब्राउज़र के पास टूल है या नहीं, और फिर उसके नीचे का बटन उसे सचमुच कॉल करता है।

खुद जाँचने के लिए ब्राउज़र से पूछिए कि उसे कौन से टूल दिए गए हैं:

const mc = document.modelContext || navigator.modelContext;
const tools = await mc.getTools();
console.log(tools.map(t => t.name));
// ["contact_wislr"]

Chrome 151 में दोनों नाम अब भी काम करते थे, जो उसके आख़िरी माइलस्टोन का उपनाम है। Chrome 152 और उसके बाद सिर्फ़ document.modelContext जवाब देता है।

जिस साइट ने ट्रायल में नाम नहीं लिखाया, वहाँ document.modelContext अपरिभाषित रहता है और इसमें से कुछ नहीं चलता। Chrome को --enable-blink-features=WebMCP के साथ चलाने से API स्थानीय रूप से चालू हो जाता है, और टोकन मिलने से पहले इसके लिए डेवलप करने का तरीक़ा यही है।

स्पेसिफ़िकेशन और इंप्लीमेंटेशन के बीच एक फ़र्क़ आपकी दोपहर ख़र्च कराने से पहले जान लेना बेहतर है। IDL executeTool के दूसरे आर्ग्युमेंट को ऑब्जेक्ट के रूप में टाइप करता है, और ऑब्जेक्ट पास करने पर UnknownError: Failed to parse input arguments के साथ नाकाम हो जाता है, जो न यह बताता है कि कौन सा आर्ग्युमेंट और न यह कि क्यों। Chrome को आर्ग्युमेंट सीरियलाइज़ किए हुए चाहिए:

await mc.executeTool(tool, JSON.stringify({ message: "How do you measure AI referrals?" }));

getTools() भी इसी तरह जवाब देता है। लौटाए गए टूल पर inputSchema रजिस्टर किए गए ऑब्जेक्ट के बजाय JSON स्ट्रिंग के रूप में आता है, इसलिए उसे वापस पढ़ने वाले किसी भी कोड को पहले पार्स करना पड़ता है।

इसी पेज पर और भी काम की चीज़ें बैठी हैं

साइनअप से शुरू करना इसलिए ठीक है क्योंकि एंडपॉइंट, सहमति का फ़्लो और पुष्टि ईमेल पहले से मौजूद हैं। यह पेज पर उजागर करने लायक सबसे छोटी चीज़ भी है।

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

सिर्फ़ पढ़ने वाले टूल शुरू करने के लिए ज़्यादा सुरक्षित जगह हैं। किसी सर्च या उपलब्धता टूल पर readOnlyHint: true लगाना एजेंट को बताता है कि यह कॉल कुछ नहीं बदलती, और ग़लती की क़ीमत आपके डेटाबेस में लिखे गए किसी रिकॉर्ड के बजाय एक बेकार क्वेरी होती है।

ऑथेंटिकेशन के पीछे जो कुछ है वह ऑथेंटिकेशन के पीछे ही रहता है। रजिस्टर किया गया टूल पेज में उसी सेशन के साथ चलता है जो विज़िटर के पास पहले से है, इसलिए get_order_status ठीक उतना ही सुरक्षित है जितना वह अकाउंट पेज जिससे वह पढ़ता है, उससे ज़्यादा नहीं।

यहाँ कुछ भी वह वजह नहीं बदलता जिसके लिए पॉपअप बना था

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

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

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

मार्केटिंग टीमों को इससे मापा जाता है कि लिस्ट कितनी तेज़ी से बढ़ती है और लाइफ़साइकल ईमेल कितना राजस्व लाते हैं। WebMCP इनमें से कोई आँकड़ा नहीं हिलाता। वह किसी इच्छुक विज़िटर को ज़्यादा साफ़ रास्ता देता है और टोकाटाकी की वजह को छुए बिना छोड़ देता है।

बाक़ी फ़ैसला समर्थन करता है। सिर्फ़ Chromium, ऐसे परीक्षणों में जो Chrome 156 पर ख़त्म होते हैं, और Apple विरोध में। साइनअप फ़ॉर्म की जगह टूल रख देना उस रास्ते को हटा देगा जो लगभग हर विज़िटर इस्तेमाल करता है, बदले में ऐसा रास्ता मिलेगा जो एक ब्राउज़र के एक हिस्से में काम करता है।

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

खुला साइनअप वह तरीक़ा है जिससे लोग मेल के नीचे दब जाते हैं

साइनअप टूल ऐसा ईमेल पता लेता है जिसे वह जाँच नहीं सकता और उस पर मेल भेज देता है। जो भी किसी एजेंट को चला सकता है वह उसे किसी भी इनबॉक्स की तरफ़ मोड़ सकता है। आपके फ़ॉर्म में भी यही छेद है, क्योंकि दोनों के पीछे का पता एक सार्वजनिक URL है जिस पर कोई स्क्रिप्ट आपका पेज लोड किए बिना पोस्ट कर सकती है।

इस हमले का एक नाम है। लिस्ट बॉम्बिंग में एक पीड़ित का पता सैकड़ों या हज़ारों साइटों पर एक साथ जमा किया जाता है, हर साइट पर एक रिक्वेस्ट। हर साइट को एक अकेला मामूली साइनअप दिखता है और कहीं कुछ ग़लत नहीं लगता। पीड़ित को एक घंटे में हज़ारों पुष्टि ईमेल मिलते हैं, और यह बाढ़ आम तौर पर उसी इनबॉक्स में आ रही किसी और चीज़ का पर्दा होती है: उसके बैंक की कोई फ़्रॉड चेतावनी, कोई पासवर्ड रीसेट, या किसी ऐसी ख़रीद की रसीद जो किसी ने उसके कार्ड से की है। आपकी भेजने की साख को भी चोट पहुँचती है, और जो हुआ उसमें वह सबसे छोटा हिस्सा है।

यह आकार उस बचाव को हरा देता है जिस तक ज़्यादातर लोग पहुँचते हैं। रेट लिमिट रिक्वेस्ट गिनती है, और जो हमला आपको ठीक एक रिक्वेस्ट भेजता है उसमें गिनने को कुछ है ही नहीं।

चार चीज़ें मदद करती हैं।

साइनअप के सामने एक चैलेंज रखिए, ताकि किसी स्वचालित सबमिशन को कुछ ऐसा पार करना पड़े जिसे असली व्यक्ति बिना ध्यान दिए पार कर जाता है।

पते के हिसाब से डुप्लिकेट हटाइए और एक सप्रेशन लिस्ट रखिए, ताकि वही इनबॉक्स बार-बार साइन अप न किया जा सके और जिस पते की पुष्टि पहले से लंबित है उसके लिए दूसरी रिक्वेस्ट पर कुछ भी न भेजा जाए।

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

हर साइनअप कहाँ से आया, यह पंक्ति लिखते समय ही दर्ज कीजिए। किसी घटना के बाद इसका हिसाब लगाने का मतलब है अंदाज़ा लगाना कि कौन से पते असली थे।

सहमति साबित करना तब मुश्किल है जब क्लिक सॉफ़्टवेयर ने किया हो

फ़ॉर्म सबमिशन इसका रिकॉर्ड बनाता है कि विज़िटर ने क्या देखा। चेकबॉक्स, उसके बग़ल का लेबल, प्राइवेसी लिंक और समय, सब आपकी तरफ़ रहते हैं।

टूल कॉल किसी फ़ंक्शन आर्ग्युमेंट में एक ईमेल पता बनाती है। एजेंट के काम करने से पहले विज़िटर को क्या बताया गया, यह ऐसी बातचीत में हुआ जिस तक आपकी कोई पहुँच नहीं। GDPR के तहत सहमति स्वतंत्र रूप से दी गई, विशिष्ट, सूचित और स्पष्ट होनी चाहिए, और नियंत्रक को बाद में उसे दिखा पाना चाहिए। एजेंट के ज़रिए आया पता अपने आप में इनमें से कुछ भी पूरा नहीं करता।

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

ये साइनअप चुपचाप ग़ायब हो जाते हैं, इसलिए गिनती पहले बनाइए

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

यह वही संरचनात्मक खाई है जो AI क्रॉलर और AI रेफ़रल को ब्राउज़र एनालिटिक्स से छिपाती है, बस एक नई परत पर पहुँचकर। क्रॉलर वह JavaScript कभी नहीं चलाता जो उसकी रिपोर्ट करता। एजेंट JavaScript चलाता है, और वह हिस्सा चलाता है जो कन्वर्ज़न पूरा करता है, जबकि हर उस हिस्से को छोड़ देता है जो उसे मापता।

आपके सब्सक्राइब एंडपॉइंट से टकराने वाली रिक्वेस्ट ही इकलौती जगह है जहाँ कन्वर्ज़न ऐसे रूप में मौजूद है जो आपका अपना है। उस पर वहीं ठप्पा लगाइए, फ़र्स्ट-पार्टी लॉग में, और वह चैनल ऐसी चीज़ बन जाता है जिसका आकार आप अगली तिमाही बता सकें।

चार चीज़ें जो इन्हें ग़ायब होने से रोकती हैं

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

साइनअप की रिपोर्ट नेटवर्क कॉल से पहले कीजिए, सक्सेस हैंडलर के भीतर नहीं। जो कॉल बीच में छोड़ दी जाती है, या सर्वर के काम कर चुकने के बाद नाकाम होती है, वह सक्सेस ब्रांच तक कभी नहीं पहुँचती। बाहर जाते समय रिपोर्ट कीजिए और आप प्रयास गिन लेते हैं, जो असल में वही आँकड़ा है जो आपको चाहिए।

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

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

इस तिमाही इसके बारे में क्या करें

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

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

document.modelContext इस्तेमाल कीजिए, और Chrome के ट्रायल में नाम लिखाइए अगर आप चाहते हैं कि टूल तक फ़्लैग चालू किए हुए डेवलपर के बजाय आम विज़िटर पहुँचें।

टूल भेजने से पहले अपने साइनअप एंडपॉइंट में source फ़ील्ड जोड़िए। बाद में ऐसा करने का मतलब है कि आप बता ही नहीं पाएँगे कि आपके डेटाबेस में पहले से मौजूद साइनअप में से कौन से किसी एजेंट से आए थे।

नतीजे अपने ही सर्वर से पढ़िए। कोई एनालिटिक्स प्रॉपर्टी आपको ये साइनअप दिखाएगी ही नहीं, और उनके बिना गिने रह जाने के दौरान उसमें कुछ भी टूटा हुआ नहीं लगता।

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