संक्षेप में जवाब
फ़ैशन स्टोर के लिए चरणबद्ध जाँच: ग्राहक को दिखने वाला उत्पाद पेज, वैरिएंट मार्कअप, मर्चेंट फ़ीड और रिटर्न नीति मिलाकर ही एआई खरीदारी के जवाब परखें।
सही जवाब केवल एक निश्चित उत्पाद वैरिएंट के लिए मिलता है
क्या कोई एआई सहायक ठीक-ठीक बता सकता है कि जैकेट का M साइज़ उपलब्ध है और खरीदार उसे वापस कर पाएगा? केवल यह कहना कि स्टोर का कैटलॉग एआई के लिए तैयार है, इस सवाल का जवाब नहीं है। रंग और साइज़ का सटीक संयोजन, डिलीवरी का देश, स्टॉक देखने का समय और उस खरीद पर लागू वापसी की शर्तें जाननी होंगी। यह लेख स्टोर मालिकों, मर्चेंडाइज़र और डेवलपर के लिए जाँच की विधि है। यह VITON13 या किसी अन्य विक्रेता के वास्तविक SKU की जाँच का परिणाम नहीं है। इस लेख के लिए कोई वास्तविक SKU नहीं चुना गया और किसी एआई प्लेटफ़ॉर्म की उत्तर-सटीकता नहीं मापी गई। उद्देश्य है कि जाँच से पहले किन प्रमाणों को इकट्ठा करना चाहिए, यह स्पष्ट हो।
इस ऑडिट में चार जगहों की जानकारी मिलाई जाती है: ग्राहक को दिखाई देने वाला उत्पाद पेज, उस पेज पर रेंडर हुआ संरचित डेटा, व्यापारिक फ़ीड की निर्यात की गई पंक्ति और पूरी वापसी नीति। नतीजा एक मतभेद रजिस्टर है, कोई एक जादुई एआई-विज़िबिलिटी अंक नहीं। Shopify अपने एजेंटिक कॉमर्स के बारे में बताता है कि उसका कैटलॉग जुड़ी हुई एआई सेवाओं तक उत्पाद जानकारी पहुँचाता है और खरीद के रास्ते में विकल्प, स्टॉक तथा कीमत जाँची जाती है। यह Shopify की अपनी व्यवस्था का विवरण है। इससे यह सिद्ध नहीं होता कि हर एआई सहायक वही फ़ीड पढ़ता है या उसी क्षण का अपडेट देखता है। इसलिए पहले व्यापारी के अपने नियंत्रण वाले तथ्यों को परखें; चैटबॉट का जवाब अलग अवलोकन है।
मूल उत्पाद नहीं, साइज़ और रंग के संयोजन चुनें
पहले से ऐसी छोटी नमूना सूची बनाइए जिसमें कई तरह की समस्या सामने आ सके: स्टॉक में मौजूद सामान्य साइज़, खत्म हो चुका साइज़, अलग तस्वीर वाला रंग, छूट पर चल रहा वैरिएंट और वापसी के अपवाद वाला उत्पाद। हर पंक्ति में तारीख, समय क्षेत्र, देश, मुद्रा, बिक्री चैनल और सटीक साइज़-रंग लिखें। परिणाम देखने से पहले चयन का नियम तय करें, नहीं तो असुविधाजनक उदाहरण अनजाने में हट सकते हैं। पाँच वैरिएंट इस कार्यपत्रक को समझाने के लिए पर्याप्त हैं, पर पूरे कैटलॉग में त्रुटियों का प्रतिशत बताने के लिए नहीं। यदि कई गोदाम या देशों के लिए अलग कैटलॉग हैं, तो उन्हें एक औसत में न मिलाएँ; हर परिस्थिति को अलग जाँचें।
सिर्फ़ समझाने के लिए एक काल्पनिक पंक्ति लें: DEMO-COAT / काला / M / फ्रांस में डिलीवरी। DEMO-COAT बनाया हुआ प्रशिक्षण पहचानकर्ता है, कोई असली वस्तु या मिला हुआ दोष नहीं। इसके साथ स्टोर का आंतरिक वैरिएंट ID, विकल्प चुनने के बाद दिखाई देने वाला URL और प्रत्येक चैनल को भेजा गया फ़ीड ID जोड़ें। मूल कोट का पेज उपलब्ध दिख सकता है, जबकि काला M खत्म हो चुका हो। ऐसे में मूल उत्पाद की सिफ़ारिश खरीदार के प्रश्न का सही जवाब नहीं होगी। कार्यपत्रक में पूरा सवाल लिखें: ‘क्या मैं आज फ्रांस के लिए काला M मँगवा सकता हूँ, और लौटाने की लागत क्या होगी?’ फिर इस सवाल के दोनों हिस्सों का प्रमाण अलग-अलग देखें।
ग्राहक को दिखने वाले उत्पाद पेज का रिकॉर्ड रखें
नई ब्राउज़र सत्र में उत्पाद पेज खोलें, निश्चित वैरिएंट चुनें और पेज पूरी तरह बदलने तक प्रतीक्षा करें। दिखाई देने वाला साइज़, नाप और उनकी इकाइयाँ, फिट संबंधी सलाह, चुनी हुई तस्वीर, मुद्रा सहित वर्तमान कीमत, स्टॉक संदेश, कार्ट बटन की स्थिति, डिलीवरी देश और रिटर्न लिंक दर्ज करें। यदि छोटे मोबाइल स्क्रीन पर कोई विकल्प या लिंक गायब हो जाता है, तो वहाँ भी निरीक्षण करें। समय के साथ URL और स्क्रीनशॉट बचाएँ। अंदरूनी डेटाबेस में सही मूल्य होना उस बात का विकल्प नहीं है जो ग्राहक को स्क्रीन पर दिखाई दे रही है। M का अर्थ शरीर का नाप, कपड़े का नाप या सिर्फ़ एक कोड हो सकता है; चार्ट इसे स्पष्ट नहीं करता तो फ़ीड में M सही लिखे होने पर भी सामग्री अधूरी है।
ऑर्डर जमा किए बिना खरीद प्रक्रिया को कार्ट तक ले जाएँ। क्या चुना हुआ रंग और साइज़ सुरक्षित रहता है? क्या रिफ़्रेश के बाद खत्म वैरिएंट फिर चुनने योग्य हो जाता है? क्या रिटर्न लिंक उत्पाद के पास है या केवल वेबसाइट के सबसे नीचे? ‘मुफ़्त वापसी’ का बैज दिखे तो क्या उस पर देश और श्रेणी की सीमा स्पष्ट है? ये वास्तविक ऑडिट में पूछे जाने वाले सवाल हैं; यहाँ किसी स्टोर पर आरोप नहीं लगाया जा रहा। दिखाई देने वाला पेज मनुष्य के लिए संदर्भ बिंदु है। इसी से पता चलता है कि तकनीकी रूप से सही JSON-LD कहीं ऐसा ऑफ़र तो नहीं बता रहा जो खरीदार सचमुच कार्ट में जोड़ ही नहीं सकता।
हर वैरिएंट को रेंडर हुए संरचित डेटा से मिलाएँ
केवल कोड रिपॉज़िटरी का मूल कंपोनेंट न देखें; उस HTML को जाँचें जिसे क्रॉलर प्राप्त करता है। Google का वैरिएंट दस्तावेज़ बताता है कि ProductGroup, variesBy, hasVariant और productGroupID से रंग तथा साइज़ वाले उत्पाद कैसे जोड़े जा सकते हैं। वह एक पेज और कई पेज वाले तरीके भी समझाता है। चुने हुए उत्पाद का Product या ProductGroup खोजें और उसका SKU, साइज़, रंग, तस्वीर और Offer URL स्क्रीन पर चुने हुए वैरिएंट से मिलाएँ। Offer की priceCurrency, कीमत तथा availability भी जाँचें। वैरिएंट URL को सीधे खोलकर देखें कि क्या सचमुच वही संयोजन चुना जाता है। सामान्य मूल उत्पाद का Offer देखने में पूरा लगे, फिर भी काले M की उपलब्धता का उत्तर न दे।
Google का Rich Results Test लिखावट और संबंधित खोज सुविधा की तकनीकी योग्यता जाँचने के लिए उपयोगी है; तथ्यों का मिलान उसके बाद भी स्वयं करना होगा। टेस्ट पास होने से साइज़ चार्ट का नाप सही, स्टॉक ताज़ा या किसी बाहरी एआई द्वारा मार्कअप पढ़ा जाना प्रमाणित नहीं होता। Google सामान्य वापसी नियम को Organization स्तर और विशेष मामले को Offer स्तर पर दिखाने का तरीका भी बताता है। यदि पूरे स्टोर की नीति एक है, तो वस्तु का Offer बिना वास्तविक अपवाद के अलग अवधि नहीं बताना चाहिए। रेंडर किया हुआ JSON-LD और टेस्ट का परिणाम समय सहित सुरक्षित करें। इससे डेवलपर मतभेद दोहरा सकेगा और संपादक सही स्रोत की पहचान कर सकेगा।
Merchant Center फ़ीड को पेज से मिलाकर देखें
समान वैरिएंट ID और उसी बाज़ार के लिए फ़ीड की पंक्तियाँ निकालें। Google Merchant Center का उत्पाद डेटा विनिर्देश एक वस्तु के ID और वैरिएंट को समूह में रखने वाले item_group_id को अलग करता है। लागू परिस्थितियों में size, size_type तथा size_system जैसे क्षेत्र भी बताए गए हैं; कीमत, उपलब्धता और उतरने वाले पेज का लिंक अलग दर्ज होता है। हर पंक्ति का साइज़ और रंग पेज के चयन से मिलाएँ और समूह ID को मूल उत्पाद से जोड़ें। लिंक खोलने पर वही संयोजन चुना रहता है या पेज किसी दूसरे साइज़ पर लौट जाता है? जल्दी बदलती कीमत और स्टॉक के लिए फ़ीड बनने तथा संसाधित होने का समय, पेज के स्क्रीनशॉट के समय के साथ रखें। पुराना फ़ीड भी ग्राहक को ग़लत संकेत दे सकता है, चाहे समाधान लेखन नहीं बल्कि सिंक्रनाइज़ेशन हो।
यह न मानें कि Google का फ़ीड हर एआई सेवा की सार्वभौमिक भाषा है। Merchant Center की शर्तें उत्पाद श्रेणी और देश के अनुसार बदलती हैं; दूसरे चैनलों के क्षेत्र और अपडेट चक्र अलग हो सकते हैं। Google कहता है कि उपलब्धता फ़ीड, लैंडिंग पेज, चेकआउट और संरचित डेटा में मेल खानी चाहिए। Shopify का लेख उसके अपने कैटलॉग से जुड़ी एआई सेवाओं की बात करता है; उससे यह साबित नहीं होता कि हर संवादात्मक एआई स्वतंत्र Google फ़ीड पढ़ेगा। कार्यपत्रक में स्रोत सिस्टम, निर्यात किया हुआ मूल्य और पेज पर देखी गई जानकारी के लिए अलग कॉलम रखें। सुव्यवस्थित फ़ीड को पूरे स्टोर की अचूक सच्चाई मान लेना इसी तरह रोका जा सकता है।
रिटर्न बैज नहीं, लागू पूरी नीति पढ़ें
जाँचे जा रहे उत्पाद से पूरा वापसी पेज खोलें और डिलीवरी देश भी दर्ज रखें। वापसी की अवधि किस घटना से शुरू होती है, वस्तु की अपेक्षित हालत क्या है, किन वस्तुओं को बाहर रखा गया है, शिपिंग शुल्क कौन देगा, धन कैसे लौटेगा और ग्राहक को कौन से कदम उठाने हैं — सब अलग लिखें। सेल में बिकी चीज़, निजीकरण वाला उत्पाद या स्वच्छता से जुड़ी श्रेणी के नियम भिन्न हो सकते हैं। ‘30 दिन में वापसी’ का छोटा बैज देश, अपवाद और लागत बताए बिना पूरा उत्तर नहीं है। यह सामग्री की संगति का ऑडिट है, कानूनी सलाह नहीं। हर देश के लिए लागू शब्दों को स्टोर के नीति प्रभारी या कानूनी विशेषज्ञ से अनुमोदित कराना होगा।
लिखी हुई शर्तों को संरचित रिटर्न डेटा और Merchant Center की वापसी सेटिंग से मिलाएँ। Google Search Central सामान्य नीति के लिए Organization पर MerchantReturnPolicy और उत्पाद-विशेष अपवाद के लिए Offer स्तर का तरीका बताता है। applicableCountry, merchantReturnDays तथा returnFees जैसे फ़ील्ड उन नियमों को समझने में सहायता करते हैं। लेकिन लंबे दस्तावेज़ का हर किनारा इन फ़ील्डों में नहीं समाता, और वे यह प्रमाण नहीं हैं कि गोदाम हर स्थिति में नीति निभाएगा। केवल काल्पनिक DEMO-COAT उदाहरण लें: पेज डिलीवरी से 30 दिन बताए, जबकि फ़ीड की सेटिंग 14 दिन कहे। इसे वास्तविक स्टोर की खोज न बताएँ; नीति प्रभारी को भेजने योग्य एक अभ्यास वाला मतभेद लिखें। एआई के उत्तर के लिए मनपसंद संख्या न चुनें।
मतभेद सुधारें और वही प्रश्न फिर पूछें
हर दावे के लिए रजिस्टर में एक पंक्ति रखें: वैरिएंट ID, बाज़ार, दावे का प्रकार, पेज पर दिखाई देने वाला मूल्य, संरचित डेटा, फ़ीड, नीति, समय, स्रोत URL, ज़िम्मेदार व्यक्ति और समाधान की स्थिति। प्राथमिकता ग्राहक को होने वाले असर से तय करें, न कि कौन सा विभाग फ़ील्ड संभालता है। चुने हुए साइज़ की गलत उपलब्धता या वापसी का गलत शुल्क तुरंत ध्यान माँगता है। रंग के नाम में मामूली भाषाई अंतर बाद में सुधर सकता है, यदि उससे ऑर्डर की वस्तु नहीं बदलती। काल्पनिक काले M कोट के लिए सुरक्षित अंतरिम जवाब होगा कि उपलब्धता या वापसी की शर्त की अभी पुष्टि नहीं हुई है। यह किसी वास्तविक व्यापारी में दोष होने का दावा नहीं है।
सुधार के बाद पेज और फ़ीड ताज़ा करें, सटीक वैरिएंट URL फिर खोलें और केवल उन एआई सेवाओं में मूल प्रश्न दोहराएँ जिन्हें स्टोर वास्तव में उपयोग करता है। प्रश्न, उत्तर, तारीख, बाज़ार की सेटिंग और सहायक प्रमाण सहेजें। एक सही उत्तर स्थायी सटीकता दर नहीं है; सहायक दूसरा स्रोत पढ़ सकता है, पुराना कैश दिखा सकता है या उत्तर देने से मना कर सकता है। परीक्षण से पहले स्वीकृति का नियम लिखें: चुने हुए वैरिएंट की कीमत और खरीदयोग्यता स्टोर की अपनी सतहों पर मेल खाए; हर रिटर्न दावा स्वीकृत दस्तावेज़ से जुड़े; बचे हुए विवाद का मालिक तय हो। इस उत्पाद डेटा ऑडिट का असल नतीजा सुधरा हुआ मूल रिकॉर्ड और दोहराई जा सकने वाली जाँच है, न कि किसी मॉडल से उद्धरण, रैंकिंग या सिफ़ारिश की गारंटी।
व्यावहारिक चेकलिस्ट
- पहले से कुछ निश्चित साइज़-रंग वैरिएंट चुनें और चयन का नियम, बाज़ार तथा तारीख लिखें।
- वैरिएंट चुनने के बाद दिखने वाला साइज़, मूल्य, स्टॉक और रिटर्न लिंक सुरक्षित करें।
- रेंडर किए गए Product या ProductGroup को चुने हुए वैरिएंट और Offer से मिलाएँ।
- उसी वैरिएंट की फ़ीड पंक्तियाँ निकालकर ID, साइज़, मूल्य, उपलब्धता और लिंक जाँचें।
- चुने हुए देश की पूरी वापसी नीति पढ़ें, मतभेद दर्ज करें और सुधार का मालिक तय करें।
सवाल और जवाब
क्या वैध Product मार्कअप से एआई का साइज़ वाला जवाब सही साबित होता है?
नहीं। वैलिडेशन टूल अपने नियमों के अनुसार डेटा की संरचना जाँचता है। वह कपड़े का नाप, साइज़ चार्ट की सच्चाई, बदलता स्टॉक या जवाब देते समय किसी दूसरे एआई ने कौन सा स्रोत पढ़ा, इसकी पुष्टि नहीं करता।
क्या हर साइज़ और रंग के लिए अलग उत्पाद पेज ज़रूरी है?
ज़रूरी नहीं। Google एक ही पेज और कई पेज वाले, दोनों तरह के वैरिएंट का तरीका समझाता है। हर प्रकाशित संयोजन की पहचान, URL, ऑफ़र और उपलब्धता सुसंगत होना अधिक महत्वपूर्ण है।
ऑडिट में किस रिटर्न नीति को आधार मानें?
वही नीति जो चुने हुए उत्पाद, डिलीवरी देश और बिक्री चैनल पर सचमुच लागू होती है। ग्राहक को दिखता पाठ, संगठन या Offer स्तर का मार्कअप और Merchant Center सेटिंग अलग-अलग जाँचें; अपने आप मेल होने का अनुमान न लगाएँ।
क्या सही मर्चेंट फ़ीड गलत साइज़ चार्ट को ठीक कर सकती है?
नहीं। फ़ीड साइज़ का नाम भेज सकती है, लेकिन गलत फिट या नाप की जानकारी सही नहीं बना सकती। पहले मूल उत्पाद रिकॉर्ड और ग्राहक के लिए लिखी जानकारी सुधारें, फिर निर्यात किए गए सभी चैनल मिलाएँ।
उत्पाद डेटा ऑडिट कब सफल माना जाएगा?
जब चुने हुए वैरिएंट के दावे दर्ज समय पर मेल खाएँ, अपवादों का स्वीकृत स्रोत हो और हर बाकी मतभेद का ज़िम्मेदार व्यक्ति हो। इसका अर्थ खोज में स्थान, एआई उद्धरण या हर प्लेटफ़ॉर्म पर हमेशा सही जवाब नहीं है।