साइडबार के हर आइटम को अलग-अलग बताने के बजाय, मुझे आपको एक असली अकाउंट के बारे में शुरू से आखिर तक बताने दें। मान लीजिए यह एक फ्रीलांसर है, प्लेटफॉर्म पर पहला हफ्ता, एक छोटे क्लाइंट के लिए हैबिट-ट्रैकिंग ऐप बना रहा है। यह वही होता है जो उस बिल्ड के साथ होता है जैसे-जैसे यह डैशबोर्ड से गुज़रता है, जिस क्रम में यह वाकई होता है — और हर पड़ाव ने या तो पांच मिनट बचाए या बर्बाद किए।
प्रॉम्प्ट
वे AI Builder खोलते हैं और कुछ ऐसा टाइप करते हैं जो "मुझे एक हैबिट ट्रैकर बना दो" के करीब हो। यह एक ठीक-ठाक पहला वाक्य है और एक खराब आखिरी प्रॉम्प्ट है। जो वापस आता है वह कोड नहीं है — यह सादी भाषा में लिखा गया एक प्लान है, और अगर आप "ठीक लग रहा है" पर पढ़ना बंद करके अप्रूव पर क्लिक कर दें, तो आपको कुछ ऐसा मिलता है जो तकनीकी रूप से "हैबिट ट्रैकर" शब्दों से संबंधित है और हर मायने में जेनेरिक है। फ्रीलांसर के क्लाइंट को कोई सोशल फीचर नहीं चाहिए था, सिर्फ लोकल स्टोरेज, डिफॉल्ट रूप से डार्क मोड। इनमें से कुछ भी पहले प्रॉम्प्ट में नहीं था। यह इसके बजाय प्लान में जाता है, अप्रूवल से पहले तीन एडिट के रूप में: प्लान द्वारा खुद से बनाया गया "शेयर योर स्ट्रीक" फीचर हटाओ, स्टोरेज वाली लाइन बदलो, डिफॉल्ट थीम फ्लिप करो। तीस सेकंड की एडिटिंग। जो बिल्ड दूसरी तरफ से निकलती है वह ब्रीफ से मेल खाती है, न कि सिर्फ "हैबिट ट्रैकर" शब्द से।
प्लान वाला वह स्टेप जिसे लोग स्किप कर देते हैं
मैंने यह ठीक यही पल दूसरे यूज़र्स के लिए गलत होते देखा है — बिना पढ़े पहला प्लान अप्रूव कर दो, तीन इटरेशन आगे पहुंच जाओ, और उन बाधाओं को फिर से समझाना शुरू कर दो जो प्लान स्टेज पर ही तय हो जानी चाहिए थीं। प्लान स्टेप का मकसद ही यही रोकना है। इसकी लागत लगभग शून्य है, और यह लूप का एकमात्र ऐसा बिंदु है जहां आप एजेंट से कोड में उसके आउटपुट को डीबग करने के बजाय अपनी भाषा में बातचीत कर रहे होते हैं।
बिल्ड आखिर में कहां पहुंचता है
जनरेट होने के बाद, हैबिट ट्रैकर My Builds में एक कार्ड के रूप में दिखाई देता है — यह लाइब्रेरी पेज है, टाइप के हिसाब से फ़िल्टर किया जा सकता है, और तीसरे हफ्ते तक जब पांच-छह बिल्ड जमा हो जाएंगे, तब यह फ्रीलांसर सबसे ज्यादा जिस पेज को खोलेगा वह यही होगा। यह Showcase में नहीं दिखता; वह पेज क्यूरेटेड है, ऑटोमैटिक नहीं, और बिना प्रचार के वहां क्लाइंट बिल्ड का पड़े रहना ही सही डिफ़ॉल्ट है। यह Templates में भी तभी दिखेगा जब फ्रीलांसर इसे टेम्पलेट के रूप में सेव करने की सोचे — यहां ऐसा करना वाकई फायदेमंद है, क्योंकि हैबिट ट्रैकर का स्केलेटन ठीक वैसी चीज़ है जिसे फ्रीलांसर अगले क्लाइंट के लिए अलग ब्रांडिंग के साथ फिर से बनाएगा। ज्यादातर लोगों को "save as template" का पता छठे बिल्ड तक जाकर चलता है, और तब उन्हें अफसोस होता है कि उन्होंने यह पहले बिल्ड पर ही क्यों नहीं किया।
Published, या उससे भी भारी कुछ
अब डिस्ट्रीब्यूशन का सवाल। तीन असली विकल्प हैं, न कि तीन नामों वाला एक ही विकल्प। Published एक मुफ्त सबडोमेन देता है, सेकंडों में लाइव, बिना किसी सेटअप के — यह सही विकल्प तब है जब क्लाइंट अभी भी रिव्यू कर रहा हो और रीडिज़ाइन मांग सकता हो। Domain Management तब काम आता है जब क्लाइंट का खुद का डोमेन इसे पॉइंट करने के लिए तैयार हो, और यह स्टेप दोहरा काम करता है — यहां डोमेन कनेक्ट करना सिर्फ URL बदलना नहीं है, बल्कि यही वह चीज़ भी है जो साइडबार में आगे मौजूद एनालिटिक्स पेजों को जोड़ने लायक बनाती है। Deploy, जो सेटिंग्स के अंतर्गत है, वह SFTP रास्ता है जब क्लाइंट ज़िद करे कि बिल्ड उसके अपने नियंत्रण वाले इंफ्रास्ट्रक्चर पर लाइव हो — इसमें ज़्यादा सेटअप लगता है, और फ्रीलांसर अब अपटाइम की कोई ज़िम्मेदारी नहीं रखता, जो एक असली ट्रेड-ऑफ है जिसे स्पष्ट रूप से समझना ज़रूरी है, न कि गलती से पता चले।
इस बिल्ड के लिए, पहले Published चुनें। बाद में सबडोमेन से कस्टम डोमेन पर जाना कोई बड़ी बात नहीं है। लेकिन किसी ऐसे क्लाइंट प्रोजेक्ट पर कस्टम-डोमेन डिप्लॉय को पूर्ववत करना जो रद्द हो चुका है, उससे कहीं ज़्यादा सफाई करनी पड़ती है जितनी ज़रूरत होती है — और वाकई फ्रीलांसर पहले के एक प्रोजेक्ट में ठीक इसी वजह से नुकसान झेल चुका है, यही कारण है कि "डिफ़ॉल्ट रूप से Published चुनो" वाली आदत बनी।
ऐप-स्टोर वाला रास्ता
इस खास क्लाइंट को ऐप-स्टोर लिस्टिंग भी चाहिए थी, इसलिए बिल्ड Published पर रुकने के बजाय Shipped से होकर गुज़रता है — यह पेज इसलिए मौजूद है क्योंकि स्टोर रिव्यू उस तरह असिंक्रोनस होता है जैसा वेब डिप्लॉय बिल्कुल नहीं होता। एक स्टोर पर सबमिट करो तो वह दो दिन पड़ा रहता है; दूसरे पर सबमिट करो तो बीस मिनट में क्लियर हो जाता है। Shipped वह जगह है जहां आप इसे बिना पांच अलग-अलग स्टोर कंसोल के टैब खोले ट्रैक कर सकते हैं, जिनमें हर एक का अपना लॉगिन और अपनी स्टेटस शब्दावली होती है।
खाली पेज जिसके बारे में किसी ने आगाह नहीं किया
डोमेन कनेक्ट होने के एक हफ्ते बाद, फ्रीलांसर उसे चेक करने के लिए Search Performance खोलता है। खाली। असल में थोड़ा उदास दिखने वाला — कोई चार्ट नहीं, कोई नंबर नहीं, बस एक अकाउंट-कनेक्ट करने का प्रॉम्प्ट। यह टूटा हुआ नहीं है, बल्कि ईमानदार है: अभी कोई डेटा नहीं है, क्योंकि Search Performance, Google Analytics, और Store Analytics तीनों सेटिंग्स के अंतर्गत Google अकाउंट कनेक्शन पर निर्भर करते हैं, और इनमें से कोई भी पुराने डेटा को बैकफिल नहीं करता। सिंक उसी पल से शुरू होता है जब आप कनेक्ट करते हैं, आगे की ओर ही, पीछे की ओर नहीं। पहले दिन ही डोमेन कनेक्ट कर लो तो दूसरे हफ्ते तक आपके पास एक हफ्ते का इतिहास होगा; दसवें दिन कनेक्ट करो क्योंकि भूल गए थे, तो दसवें दिन से ही शून्य से शुरुआत होगी। फ्रीलांसर ने डोमेन तो कनेक्ट कर लिया था लेकिन Google अकाउंट नहीं — दो अलग-अलग स्टेप जो एक जैसे दिखते हैं।
यहां असल में कीमत चुकानी पड़ने वाली चीज़ चार्ट का गायब होना नहीं है। असली बात यह है कि ऑप्टिमाइज़ेशन एजेंट्स इसी डेटा से पढ़ते हैं, और जिस एजेंट को बिना किसी Search Performance इतिहास के किसी पेज की रैंकिंग सुधारने को कहा जाए, वह इस साइट के असली आंकड़ों की बजाय सामान्य बेस्ट प्रैक्टिस के आधार पर काम करता है। कनेक्शन छोड़ना सिर्फ एक डैशबोर्ड पेज को खाली नहीं छोड़ता — यह एजेंट्स की क्षमता को भी सीमित कर देता है।
वह ब्रीफ जो बिना मांगे सामने आ जाता है
दो हफ्तों बाद, Discovery में एक कार्ड दिखता है: एक ऑपर्च्युनिटी ब्रीफ जो क्लाइंट की साइट पर किसी कंटेंट गैप की ओर इशारा करता है, साथ में एक Build-this बटन। जब यह किसी ऐसी चीज़ पर आता है जिस पर आप वैसे भी काम करते, तो यह वाकई उपयोगी होता है। लेकिन Discovery डिज़ाइन के हिसाब से सटीकता से ज़्यादा वॉल्यूम की ओर झुका होता है — यानी जितने ब्रीफ आते हैं उनमें से ज़्यादातर पर कोई एक्शन नहीं लेता — इसलिए सही रवैया इसे एक सजेशन इनबॉक्स की तरह लेना है, न कि निपटाने वाली कतार की तरह। फ्रीलांसर हर कुछ दिनों में इसे सरसरी तौर पर देखता है और ज़्यादातर को नज़रअंदाज़ करता है, जो कि इसका इच्छित उपयोग है, न कि पीछे रह जाने की असफलता।
वे सेटिंग्स जो पहले दिन ही हो जानी चाहिए थीं
इस समय तक फ्रीलांसर ने चार सेटिंग्स पेज छू लिए हैं बिना कभी जानबूझकर सेटिंग्स मेन्यू खोले — हर एक की खोज इसलिए हुई क्योंकि कुछ और खाली था।
| पेज | आखिर में इसने किसे गेट किया |
|---|---|
| Google खाते | Search Performance, Google Analytics, और एजेंट्स का ग्राउंडिंग डेटा — एक कनेक्शन, तीन सतहें |
| डिप्लॉय | SFTP लक्ष्य, केवल क्लाइंट-नियंत्रित-सर्वर वाले रास्ते के लिए ज़रूरी |
| AI मीडिया | बिल्ड्स के अंदर इस्तेमाल होने वाले इमेज जनरेशन डिफ़ॉल्ट्स |
| प्लान और क्रेडिट | उपयोग सीमा, क्रेडिट पैक, रसीदें |
Google Accounts वह चीज़ है जिसे पहले ही सेट कर लेना फायदेमंद है। यह तीन अलग-अलग डैशबोर्ड सतहों के पीछे एक ही कनेक्शन बिंदु है, और इसे मुश्किल तरीके से जानना — तीन अलग-अलग खाली पेज, तीन अलग-अलग "अरे, मुझे कुछ कनेक्ट करना है" वाले पल — वही घर्षण है जिसे पहले दिन पांच मिनट का सेटअप टाल सकता है।
वे दो चीज़ें जो शुरू से ही वहां मौजूद थीं
फ्लोटिंग Ask-AI बटन इन सभी पेजों पर पूरे समय मौजूद रहा, और यह कोई सीमित FAQ बॉट नहीं है — यह आपकी ओर से किसी अकाउंट को कनेक्ट कर सकता है, बिल्ड शुरू कर सकता है, या समझा सकता है कि कोई पेज खाली क्यों है। फ्रीलांसर के क्लाइंट, जो अंग्रेज़ी नहीं बोलते, को रिव्यू कॉल के लिए पूरा इंटरफ़ेस किसी दूसरी भाषा में चाहिए था; नेव में मौजूद ग्लोब सभी बीस भाषाओं के बीच स्विच करता है, बीच सेशन में भी, बिना चल रहे बिल्ड को खोए। इन दोनों में से किसी को भी इस वॉकथ्रू की बाकी हर चीज़ की तरह आज़माइश से खोजने की ज़रूरत नहीं थी। वे बस वहां मौजूद थे।
इस पूरे अकाउंट के पहले दो हफ्तों का ईमानदार सार यही है — "पहले डॉक्स पढ़ो, फिर बनाओ" नहीं, बल्कि इसका उल्टा। My Builds एक अमूर्त धारणा भर था जब तक उसमें कोई कार्ड न आया। Search Performance एक खाली स्टेट था जब तक किसी डोमेन ने उसे डेटा न दिया। पहले बिल्ड से पहले फ्लोर प्लान पढ़ लेना ठीक पृष्ठभूमि की जानकारी है, लेकिन फ्लोर प्लान तभी समझ में आता है जब उसमें कहीं कोई असली हैबिट ट्रैकर मौजूद हो।
