Google پیشنهادی را در نمونه پروژه Schema.org GitHub منتشر کرد که پیشنهاد میکند بهروزرسانی در Schema.org برای گسترش دادههای ساختاری خرید بهگونهای که تاجران بتوانند اطلاعات حمل و نقل بیشتری را ارائه دهند که احتمالاً در جستجوی Google و سایر سیستمها نشان داده میشود.
داده های ساختاری Schema.org حمل و نقل
نوع داده ساختاریافته پیشنهادی جدید می تواند توسط بازرگانان برای ارائه جزئیات بیشتر حمل و نقل استفاده شود. همچنین پیشنهاد میکند که انعطافپذیری استفاده از دادههای ساختیافته ارسال در سراسر سایت را که میتوان با دادههای ساختاری سازمان تودرتو کرد، اضافه کرد، در نتیجه از تکرار هزاران بار اطلاعات مشابه در یک وبسایت اجتناب کرد.
در پیشنهاد اولیه آمده است:
«این پیشنهادی از طرف Google برای پشتیبانی از نمایش غنیتر جزئیات حملونقل (مانند هزینه و سرعت تحویل) و شفافسازی این نوع دادهها است. در صورت پذیرش توسط schema.org و ناشران، احتمال میدهیم تجارب جستجو و سایر سیستمهای مصرفکننده با استفاده از چنین نشانهگذاریهایی بهبود یابند.
این تغییر نوع جدیدی به نام ShippingService را معرفی می کند که محدودیت های حمل و نقل (مکان تحویل، زمان، محدودیت وزن و اندازه و نرخ حمل و نقل) را گروه بندی می کند. بنابراین، فیلدهای اضافی از ShippingRateSettings در این پیشنهاد منسوخ شدهاند.
در نتیجه تغییرات زیر نیز پیشنهاد شده است:
برخی از فیلدها در OfferShippingDetails به ShippingService منتقل شده اند.
ShippingRateSettings راه های بیشتری برای تعیین نرخ حمل و نقل متناسب با قیمت سفارش یا وزن حمل و نقل دارد.
پیوند دادن از Offer اکنون باید با پیوند URI وب معنایی استاندارد انجام شود.
این پیشنهاد برای بحث باز است و بسیاری از ذینفعان نظرات خود را در مورد نحوه عملکرد داده های ساختاریافته به روز شده و جدید ارائه می دهند.
به عنوان مثال، یکی از افراد درگیر در بحث پرسید که چگونه یک نوع داده ساختاریافته در سطح سایت قرار داده شده در سطح سازمان می تواند توسط محصولات جداگانه جایگزین شود و اطلاعات متفاوتی دارد و شخص دیگری پاسخی ارائه کرد.
یکی از شرکت کنندگان در بحث GitHub به نام Tiggerito پست کرد:
من سند را دوباره خواندم و آنچه شما گفتید منطقی است. سازمان مکانی است که می توان شرایط حمل و نقل مشترک را در آن ذخیره کرد. اما ShippingDetails همیشه در سطح ProductGroup یا Product است.
من در حال حاضر با جزئیات حمل و نقل اینگونه برخورد می کنم:
در قسمت پشتی، مالک می تواند مجموعه ای جهانی از جزئیات حمل و نقل را تعریف کند. هر کدام شامل فیلدهایی است که Google در حال حاضر از آنها پشتیبانی می کند، مانند مکان و زمان، اما جزئیاتی در مورد ابعاد وجود ندارد. هر ورودی همچنین دارای شرایطی است که برای چه محصولی می تواند درخواست شود. این می تواند شامل محدوده قیمت و محدوده وزن باشد.
هنگامی که من داده های ساختاریافته را برای یک صفحه تولید می کنم، ورودی هایی را درج می کنم که محصول با شرایط مطابقت دارد.
به نظر میرسد این تغییر به من اجازه میدهد از فیلتر کردن شرایط روی سرور به گنجاندن آنها در دادههای ساختاریافته در صفحه محصول تغییر کنم.
سپس مصرفکنندگان دادهها میتوانند محاسبه کنند که کدام شرایط حمل و نقل مطابقت دارد و بنابراین هنگام سفارش تعداد خاصی از محصول، چه نرخهایی در دسترس است. در حال حاضر، شما فقط می توانید برای ارسال یک قیمت ارائه دهید.
این تقسیم همچنین به این معنی است که ارائه اطلاعات خاص محصول و همچنین اطلاعات حمل و نقل به اشتراک گذاشته شده بدون نیاز به تکرار آسان تر است.
مثال شما در سند در پایان برای استفاده از سازمان. به نظر می رسد که شما به شرایط حمل و نقل برای محصولی اشاره می کنید که در صفحه حمل و نقل است. اگر توسط گوگل پشتیبانی شود، این ارجاع متقابل بین صفحات میتواند تا حد زیادی از نفخ این صفحه در صفحه محصول بکاهد.
کارمند گوگل به تیگریتو پاسخ داد:
«@Tiggerito
سازمان مکانی است که می توان شرایط حمل و نقل مشترک را در آن ذخیره کرد. اما ShippingDetails همیشه در سطح ProductGroup یا Product است.
در واقع، و این در حال حاضر مورد است. این تغییر همچنین دو معنای eg را از هم جدا می کند. عرض، ارتفاع، وزن به عنوان توضیحات محصول (در جزئیات ارسال) و به عنوان محدودیت در شرایط حمل و نقل که در آن می توان آنها را به عنوان یک محدوده بیان کرد (مقدار کمی حداقل و حداکثر دارد).
در قسمت پشتی، مالک می تواند مجموعه ای جهانی از جزئیات حمل و نقل را تعریف کند. هر کدام شامل فیلدهایی است که Google در حال حاضر از آنها پشتیبانی می کند، مانند مکان و زمان، اما جزئیاتی در مورد ابعاد وجود ندارد. هر ورودی همچنین دارای شرایطی است که برای چه محصولی می تواند درخواست اعمال شود. این می تواند شامل محدوده قیمت و محدوده وزن باشد.
هنگامی که من داده های ساختاریافته را برای یک صفحه تولید می کنم، ورودی هایی را درج می کنم که محصول با شرایط مطابقت دارد.
به نظر میرسد این تغییر به من اجازه میدهد از فیلتر کردن شرایط روی سرور به گنجاندن آنها در دادههای ساختاریافته در صفحه محصول تغییر کنم.
سپس مصرفکنندگان دادهها میتوانند محاسبه کنند که کدام شرایط حمل و نقل مطابقت دارد و بنابراین هنگام سفارش تعداد خاصی از محصول، چه نرخهایی در دسترس است. در حال حاضر، شما فقط می توانید برای ارسال یک قیمت ارائه دهید.
برخی از محدودیتهای حمل و نقل در زمانی که محصول فهرست میشود یا حتی در یک صفحه ارائه میشود در دسترس نیستند (مثلاً مقصد حمل و نقل، تعداد اقلام، سرعت تحویل مورد نظر یا ردیف مشتری اگر کاربر وارد نشده باشد). جزئیات حمل و نقل پیوست شده به یک محصول باید فقط حاوی اطلاعات مربوط به خود محصول باشد، بقیه به شرایط ارسال جدید در این پیشنهاد منتقل می شوند.
توجه داشته باشید که schema.org یک کاردینالیته را مشخص نمی کند، بنابراین می توانیم چندین پیوند ShippingConditions را مشخص کنیم تا پیوند مناسب در سمت مصرف کننده انتخاب شود.این تقسیم همچنین به این معنی است که ارائه اطلاعات خاص محصول و همچنین اطلاعات حمل و نقل به اشتراک گذاشته شده بدون نیاز به تکرار آسان تر است.
مثال شما در سند در پایان برای استفاده از سازمان. به نظر می رسد که شما به شرایط حمل و نقل برای محصولی اشاره می کنید که در صفحه حمل و نقل است. اگر توسط گوگل پشتیبانی شود، این ارجاع متقابل بین صفحات می تواند تا حد زیادی از نفخ این صفحه محصول بکاهد.
در واقع. این همان جایی است که ما تلاش می کنیم به آن برسیم.»
بحث در مورد لینکدین
عضو لینکدین، ایرینا تودوس (نمایه لینکدین)، مهندس نرم افزار در Google Shopping، بحثی را آغاز کرد که پاسخ های متعددی دریافت کرد که نشان دهنده علاقه به پیشنهاد بود.
آندریا ولپینی (نمایه لینکدین)، مدیر عامل و یکی از بنیانگذاران WordLift، در پاسخ خود اشتیاق خود را برای این پیشنهاد ابراز کرد:
مانند Irina Tuduce، مدلسازی سرعت تحویل، مکانها و هزینه را برای سازمانهای بزرگ سادهتر میکند.
در واقع. این همان جایی است که ما تلاش می کنیم به آن برسیم.»
یکی دیگر از اعضا، ایلانا دیویس (نمایه لینکدین)، توسعه دهنده JSON-LD برای SEO Shopify App، پست کرد:
من قبلاً بازخورد خود را در مورد قراردادهای نامگذاری به schema.org ارائه کردم که آنها اجرا کردند. نگرانی من برای Google این است که چگونه تاجران دقیقاً این داده ها را به نشانه گذاری وارد می کنند. تقریباً غیرممکن است که نرخ های حمل و نقل دقیق را در SD در صورت نوسان داشته باشید. بازرگانان می توانند نرخ ثابتی را که تقریبی است وارد کنند، اما اغلب از خود می پرسند که آیا این نرخ قابل قبول است یا خیر. آیا در صورت تقریبی بودن نرخ حمل و نقل، عواقبی برای آنها وجود دارد (مثلاً عدم تطابق قیمت در GMC یک محصول را تأیید نمی کند)؟»
نگاهی درونی به توسعه داده های ساختاریافته جدید
بحث در حال انجام LinkedIn نگاهی به احساس سهامداران در داده های ساختاریافته جدید در مورد پیشنهاد می دهد. بحث رسمی Schema.org GitHub نه تنها دیدگاهی از نحوه پیشرفت پروپوزال ارائه می دهد، بلکه به ذینفعان فرصتی برای ارائه بازخورد برای شکل دادن به آنچه در نهایت به نظر می رسد ارائه می دهد.
همچنین یک Google Doc عمومی با عنوان، پیشنهاد تغییر طرح جزئیات ارسال، وجود دارد که شرح کاملی از پیشنهاد دارد.
تصویر ویژه توسط Shutterstock/Stokkete