نوشتن توضیحات محصول؛ قالب، سئو و سنجش فروش

فرض کنید مشتری یک کوله‌پشتی «مناسب لپ‌تاپ ۱۵٫۶ اینچ» می‌خرد، اما دستگاهش با وجود همین اندازه اسمی در محفظه جا نمی‌شود. متن صفحه گفته بود «جادار، حرفه‌ای و ضدآب»؛ نه ابعاد داخلی را داده بود، نه ظرفیت را تعریف کرده بود و نه روشن کرده بود «ضدآب» نتیجه کدام آزمون است. اینجا مشکل کمبود کلمات متقاعدکننده نیست؛ شکاف اطلاعات و انتظار است.

توضیحات محصول خوب قرار نیست مشتری را هیپنوتیزم کند. باید عدم‌قطعیت خرید را کم کند: این دقیقاً کدام کالا و Variant است؟ برای چه استفاده‌ای مناسب است؟ چه محدودیتی دارد؟ مشخصات و ادعا از کجا آمده‌اند؟ قیمت، موجودی، محتویات، ضمانت و مرجوعی چه هستند؟ این راهنما یک فرایند قابل‌تکرار برای پاسخ‌دادن به همین پرسش‌ها ارائه می‌کند؛ از Fact sheet و Voice of Customer تا SEO، Product Schema، هوش مصنوعی، QA و سنجش Conversion و مرجوعی.

توضیحات محصول چیست و چه کاری باید انجام دهد؟

توضیحات محصول مجموعه محتوایی است که هویت، کاربرد، مشخصات، تناسب، محدودیت و شرایط خرید یک SKU یا خدمت را به زبان قابل‌فهم ارائه می‌کند. این محتوا فقط یک پاراگراف تبلیغاتی نیست؛ عنوان، خلاصه، جدول مشخصات، گزینه‌های Variant، راهنمای اندازه، تصاویر و Alt، محتویات بسته، سازگاری، شیوه استفاده، هشدار، ضمانت و پاسخ به پرسش‌ها همگی بخشی از تصمیم خریدند.

هدف متن «افزایش فروش به هر قیمت» نیست. یک توضیح دقیق شاید خرید نامتناسب را متوقف کند؛ همین می‌تواند مرجوعی، نارضایتی و هزینه پشتیبانی را کاهش دهد. اثر نهایی را باید با سود، مرجوعی و شکایت سنجید، نه فقط Add to cart.

مخاطب صفحه محصول یک Persona خیالی نیست

سن و جنسیت به‌تنهایی نمی‌گویند مشتری درباره این SKU چه می‌خواهد. برای نوشتن، Job و Context مفیدتر است: کاربر در حال جایگزینی محصول خراب است یا نخستین خرید؟ موبایل می‌خرد یا برای سازمان Quote می‌گیرد؟ محدودیت فضا، بودجه، حساسیت، سازگاری یا زمان دارد؟ شواهد را از Queryها، گفت‌وگوی پشتیبانی، Review و علت مرجوعی بگیرید؛ نه از کلیشه‌هایی مثل «مادر جوان» یا «مدیر پرمشغله».

Search intent در صفحه محصول چندلایه است

• Exact item: برند، مدل یا شناسه مشخص را می‌خواهد.
• Attribute-led: محصول را با اندازه، جنس، رنگ، ظرفیت یا سازگاری می‌جوید.
• Use case: برای سفر کوتاه، پوست حساس، اتاق کوچک یا دستگاه خاص راه‌حل می‌خواهد.
• Risk-led: اصالت، ضمانت، مرجوعی، تاریخ مصرف یا هزینه ارسال برایش تعیین‌کننده است.
• Comparison: میان دو مدل یا Variant تفاوت قابل‌تصمیم می‌خواهد.

یک صفحه نمی‌تواند برای هر Query رتبه بگیرد و نباید Category، راهنمای خرید و Review تخصصی را تقلید کند. Product page برای یک محصول یا گروه Variant است؛ Category انتخاب میان چند محصول را پشتیبانی می‌کند و مقاله راهنما مسئله را آموزش می‌دهد. این مرزبندی از Cannibalization و متن بادکرده جلوگیری می‌کند.

پیش از نوشتن: Product truth را بسازید

کپی‌رایتر نباید مشخصات را از روی تصویر حدس بزند یا متن رقیب را بازنویسی کند. یک Product truth record لازم است: رکوردی نسخه‌دار که هر Fact، منبع، مالک و تاریخ اعتبار آن را نشان دهد. این رکورد می‌تواند در PIM، CMS، Sheet کنترل‌شده یا پایگاه محصول باشد.

Fact sheet حداقل چه فیلدهایی دارد؟

• Parent product، SKU/GTIN/MPN، برند، مدل و همه Variantها؛
• نام Attribute، مقدار، واحد، Tolerance، منبع و سطح اطمینان؛
• مواد/ترکیبات، ابعاد محصول و بسته، وزن خالص و حمل؛
• سازگاری، نیاز نصب، توان/ولتاژ، شرایط استفاده و نگهداری؛
• محتویات جعبه و مواردی که جداگانه فروخته می‌شوند؛
• هشدار، محدودیت، تاریخ تولید/انقضا یا Batch در صورت کاربرد؛
• ضمانت، خدمات، مرجوعی، اصالت و مالک تأیید هر Claim؛
• تصاویر تأییدشده برای همان Variant و حقوق استفاده آن‌ها.

Claim ledger: هر ادعا صاحب و شاهد داشته باشد

اصل داشتن مبنای معقول پیش از انتشار ادعای عینی در سیاست Advertising Substantiation کمیسیون تجارت فدرال آمریکا نیز تصریح شده است. این سند قانون ایران نیست؛ آن را نمونه‌ای از روش حرفه‌ای Evidence management بدانید و برای الزام محلی از مشاور حقوقی و مقررات دسته استفاده کنید.

فرایند نوشتن توضیحات محصول در ۱۲ گام

۱. واحد محتوا را مشخص کنید

آیا برای Parent product می‌نویسید یا هر SKU؟ Attribute مشترک مانند برند و مدل می‌تواند در Parent باشد، اما رنگ، اندازه، موجودی، تصویر، قیمت یا سازگاری Variant باید همراه انتخاب کاربر تغییر کند. نام‌گذاری و URL را پیش از تولید انبوه تثبیت کنید؛ اصلاح هزار SKU پرهزینه‌تر از طراحی درست الگوست.

۲. Decision questions را اولویت‌بندی کنید

از پشتیبانی، Review، Search query و مرجوعی، ۵ تا ۱۰ پرسش اصلی را استخراج کنید. هر پرسش را با Impact و Frequency امتیاز دهید. «آیا لپ‌تاپ من جا می‌شود؟» ممکن است مهم‌تر از داستان تأسیس برند باشد. سؤال بدون جواب به Fact backlog می‌رود، نه اینکه با Copy مبهم پوشانده شود.

۳. پیام مرکزی را در یک جمله بنویسید

فرمول امن: برای [Use case مشخص]، این [نوع محصول] با [ویژگی قابل‌اثبات] کمک می‌کند [پیامد محتمل]؛ با [محدودیت مهم]. این جمله Brief است، نه الزاماً متن نهایی. اگر نتوانید آن را بدون «عالی، بی‌نظیر، انقلابی» بنویسید، تمایز یا Evidence کافی ندارید.

۴. عنوان محصول را برای تشخیص بسازید

الگوی پایه: نوع محصول + برند/مدل + تمایز اصلی + Attribute لازم Variant. ترتیب با Query و دسته تغییر می‌کند. عنوان باید SKU را از همسایه‌هایش جدا کند، نه اینکه همه Featureها، شعار و «ارسال رایگان» را حمل کند.

۵. خلاصه بالای Fold را برای تصمیم سریع بنویسید

در دو یا سه جمله بگویید محصول چیست، برای چه Contextی مناسب است، تفاوت قابل‌اثباتش چیست و مهم‌ترین محدودیت کدام است. سپس ۳ تا ۵ Highlight اسکن‌پذیر قرار دهید. اطلاعات حیاتی مانند سازگاری، اندازه و محتویات را زیر آکاردئون پنهان نکنید؛ روی موبایل هم باید پیش از CTA یا نزدیک آن قابل‌دسترسی باشد.

۶. Feature را به Benefit مشروط تبدیل کنید

فرمول «ویژگی، پس مزیت» کافی نیست؛ ممکن است نتیجه‌ای تضمین‌نشده بسازد. از زنجیره زیر استفاده کنید:

Feature → Mechanism → پیامد برای Use case → شرط/مرز → Evidence

مثلاً «زیپ دوطرفه» یک Feature است. «از دو جهت باز می‌شود» Mechanism است. «هنگام قرارگرفتن کیف زیر صندلی دسترسی آسان‌تر می‌شود» پیامد محتمل است. اما «هرگز گیر نمی‌کند» بدون آزمون Claim نامعتبر است. Benefit باید به ویژگی وصل بماند و محدودیت را پنهان نکند.

۷. مشخصات را ساختاریافته و قابل‌مقایسه کنید

پاراگراف جای جدول Fact نیست. نام Attributeها را در یک دسته یکسان کنید: یک‌جا «حافظه»، جای دیگر «فضای ذخیره‌سازی» نسازید. واحد را صریح، اعشار و Tolerance را ثابت و مقدار ناموجود را از «ندارد» جدا کنید. مهم‌ترین مشخصات برای تصمیم بالاتر بیایند؛ جدول کامل پایین‌تر بماند.

۸. تناسب، سازگاری و «برای چه کسی نیست» را بنویسید

مشتری فقط دنبال دلیل خرید نیست؛ دنبال دلیل حذف گزینه نامناسب هم هست. راهنمای اندازه باید روش اندازه‌گیری بدن یا فضای داخلی را نشان دهد. سازگاری با دستگاه باید Model/نسخه/Connector و استثنا را روشن کند. عبارت «Universal» بدون دامنه تقریباً همیشه ابهام‌ساز است.

• مناسب برای: Use caseهایی که Fact و آزمون پشتیبانی می‌کنند.
• نامناسب یا نیازمند بررسی: شرایطی که محصول محدودیت دارد.
• پیش‌نیاز: آداپتور، نصب، حساب، فضای آزاد یا لوازم جداگانه.
• محتویات: دقیقاً چه چیزی در جعبه هست و چه چیزی نیست.

۹. ریسک خرید را با Policy قابل‌فهم کم کنید

ضمانت، اصالت، مرجوعی و ارسال را با لینک به Policy کامل و خلاصه مرتبط با همین محصول ارائه کنید. «هفت روز ضمانت بازگشت» بدون بیان استثنا، وضعیت پلمب، شروع مهلت و فرایند عملی ابهام دارد. Policy در Checkout نباید با Product page تناقض داشته باشد.

۱۰. متن را برای اسکن و دسترس‌پذیری قالب‌بندی کنید

پاراگراف کوتاه، Heading توصیفی، Bullet و جدول با Header واقعی استفاده کنید. اطلاعات فقط با رنگ منتقل نشود؛ Label Variant باید نام رنگ/اندازه داشته باشد. برای تصاویر، Alt بر اساس هدف همان تصویر نوشته شود. طبق راهنمای تصاویر W3C WAI، تصویر اطلاعاتی به متن جایگزینِ حامل اطلاعات ضروری نیاز دارد و تصویر صرفاً تزئینی باید alt="" داشته باشد.

برای تصویر نمای جلو می‌توان نوشت «کوله‌پشتی Atlas مشکی با دو جیب زیپ‌دار جلو»؛ نمای دیگری که محل پورت را نشان می‌دهد باید همان اطلاعات تازه را توصیف کند. تکرار نام محصول و «خرید ارزان» در Alt همه تصاویر نه برای کاربر مفید است و نه SEO سالم. راهنمای طراحی فراگیر و WCAG ۲.۲ الگوی تست کیبورد، Screen reader و RTL را کامل‌تر پوشش می‌دهد.

۱۱. Fact-check و Cross-channel QA اجرا کنید

صفحه، Cart، Checkout، Feed، تبلیغ، Schema، پیام پشتیبانی و برچسب بسته نباید درباره Variant، قیمت یا موجودی روایت‌های متفاوت داشته باشند. Reviewer باید Sample فیزیکی یا سند منبع را ببیند. Preview موبایل، RTL/Bidi، اعداد، واحد و حالت Out-of-stock را آزمایش کنید.

۱۲. نسخه منتشرشده را Owner و تاریخ بازبینی بدهید

تغییر بسته‌بندی، تأمین‌کننده، Firmware، Policy، قیمت، موجودی، عکس یا علت مرجوعی Trigger بازبینی است. کنار Content version، Source version و Approver را نگه دارید. صفحه محصول یک فایل «تمام‌شده» نیست؛ نمای جاری Product truth است.

قالب پیشنهادی توضیحات محصول

1. نام دقیق: نوع + برند/مدل + Attribute تمایزبخش.
2. خلاصه تصمیم: چیست، برای چه Use case، با چه تمایز و چه مرزی.
3. ۳ تا ۵ Highlight: Fact/Benefitهای اصلی، نه شعار.
4. تناسب و سازگاری: اندازه، دستگاه، فضا، کاربر و پیش‌نیاز.
5. شرح تفصیلی: Feature→Mechanism→Outcome→Boundary→Evidence.
6. جدول مشخصات: داده ساختاریافته با واحد و منبع.
7. محتویات بسته: Included و Not included.
8. استفاده/نگهداری/هشدار: به اندازه ریسک دسته.
9. معامله: قیمت، موجودی، ارسال، ضمانت و مرجوعی.
10. FAQ واقعی: پرسش پرتکرار مختص همان محصول.

نمونه فرضی: کوله‌پشتی لپ‌تاپ برای بازار ایران

عنوان: کوله‌پشتی لپ‌تاپ Atlas 27L، محفظه تا ۱۵٫۶ اینچ، مشکی

خلاصه: Atlas یک کوله ۲۷ لیتری برای رفت‌وآمد روزانه و سفر کوتاه است. محفظه لپ‌تاپ آن ۳۸ × ۲۶ × ۲٫۵ سانتی‌متر اندازه‌گیری شده؛ پیش از خرید ابعاد بدنه دستگاه را بررسی کنید، چون عبارت ۱۵٫۶ اینچ به‌تنهایی تضمین تناسب همه مدل‌ها نیست. پارچه در برابر پاشش کوتاه آب مقاومت نشان داده، اما محصول برای غوطه‌وری یا باران شدید به‌عنوان «ضدآب» آزمون نشده است.

• ظرفیت اسمی ۲۷ لیتر؛ وزن نمونه اندازه‌گیری‌شده ۸۹۰ گرم با تلورانس تولید؛
• محفظه مجزای لپ‌تاپ و بند نگهدارنده؛ ابعاد داخلی صریح؛
• زیپ دوطرفه بخش اصلی برای دسترسی از هر دو سمت؛
• در جعبه: یک کوله و راهنمای نگهداری؛ کاور باران همراه نیست؛
• برای تجهیزات سنگین عکاسی بدون Insert محافظ طراحی نشده است.

این نمونه به‌جای Power word، تناسب و مرز را روشن می‌کند. عکس نیز باید این ادعاها را پشتیبانی کند: نمای محفظه با خط‌کش، محتویات، بافت، پشت و Variant واقعی. برای Brief، Shot list و دقت رنگ، راهنمای عکاسی محصول را ببینید.

قالب را بر اساس دسته تغییر دهید

لحن متقاعدکننده بدون اغراق

متقاعدکنندگی از ارتباط میان نیاز، Fact و نتیجه می‌آید؛ نه از فهرست «شگفت‌انگیز، تضمینی، انحصاری، نهایی». Sensory word وقتی مفید است که تجربه قابل مشاهده‌ای را دقیق کند: «روکش مات با بافت ریز» بهتر از «حس لوکس بی‌نظیر» است. داستان فقط وقتی ارزش دارد که منشأ ماده، روش ساخت یا Context استفاده را روشن کند؛ داستان نباید مشخصات و محدودیت را عقب براند.

CTA باید عمل واقعی را نام ببرد

در Product page، «افزودن به سبد» از شعار طولانی روشن‌تر است. اگر انتخاب Variant لازم است، خطای نزدیک کنترل بنویسید: «پیش از افزودن، اندازه را انتخاب کنید». برای Out-of-stock، «اطلاع از موجودشدن» فقط پس از رضایت و بیان نوع پیام فعال شود. CTA نباید شرایط یا هزینه را پنهان کند.

Social proof را داخل متن جعل نکنید

Review واقعی با تاریخ، Rating، متن و در صورت امکان Verified purchase از Claim برند قوی‌تر است؛ اما نباید نظر ساختگی، نقل‌قول بازنویسی‌شده بدون اجازه یا فقط Reviewهای مثبت نمایش دهید. راهنمای رسمی FTC درباره Reviews و Testimonials قواعد آمریکا را توضیح می‌دهد و می‌تواند به‌عنوان Benchmark حاکمیت Review استفاده شود؛ دامنه حقوقی ایران را جداگانه بررسی کنید.

سئو توضیحات محصول: Query را پوشش دهید، درصد کلمه نسازید

هیچ «چگالی ۱ تا ۲ درصد» عمومی و مطلوبی وجود ندارد. صفحه باید واژه‌ای را که مردم برای نام محصول و Attributeهایش استفاده می‌کنند در عنوان، H1، متن، Alt و Anchor مرتبط به‌صورت طبیعی به کار ببرد. سیاست‌های Spam گوگل Keyword stuffing را تکرار واژه یا عدد برای دست‌کاری رتبه تعریف می‌کند. «LSI keyword» نیز فهرست جادویی سئو نیست؛ Entity، Attribute، Synonym واقعی و زبان مشتری را از موضوع استخراج کنید.

نقشه Keyword در سطح کاتالوگ

رقیب را برای کشف Question و Attribute بررسی کنید، نه برای کپی عبارت و ادعا. چارچوب تحلیل رقبا در سئو Query cluster و Content gap را از تقلید صفحه جدا می‌کند.

Title، H1، Meta و URL

• Title/H1: توصیفی و متمایز؛ نوع، برند/مدل و Attribute اصلی را زود بیاورید.
• Meta description: خلاصه خاص همان SKU؛ برای کاتالوگ بزرگ از فیلدهای معتبر به‌صورت Programmatic بسازید.
• URL: پایدار و کوتاه؛ قیمت، موجودی و شعار زمان‌دار را وارد URL نکنید.
• Internal link: از Category و Guide به Product مهم با Anchor توصیفی لینک دهید؛ Product یتیم نماند.

گوگل می‌گوید Snippet عمدتاً از محتوای صفحه ساخته می‌شود و گاهی Meta description را به کار می‌برد؛ برای فروشگاه بزرگ، تولید برنامه‌ایِ توضیح یکتا از داده خاص صفحه را مجاز و مفید می‌داند. جزئیات در راهنمای Snippet و Meta Description گوگل آمده است. برای کنترل کلی Title، H1، Canonical، لینک و Index، چک‌لیست سئو داخلی را اجرا کنید.

کپی سازنده مساوی «جریمه قطعی» نیست

محتوای تکراری عادی در یک سایت طبق راهنمای Canonicalization گوگل ذاتاً نقض Spam policy نیست؛ موتور جست‌وجو نسخه نماینده را انتخاب می‌کند. با این حال، کپی خام سازنده تمایز و ارزش تصمیم‌ساز کمی دارد و چند URL مشابه می‌توانند Crawl/Canonical را پیچیده کنند. راه‌حل، چرخاندن واژه با AI نیست: داده محلی، اندازه‌گیری، سازگاری، عکس، FAQ و Policy واقعی اضافه کنید و URL/Canonical را یکدست نگه دارید.

Variant strategy را پیش از تولید محتوا تعیین کنید

اگر رنگ/اندازه فقط انتخاب روی یک صفحه است، URL قابل لینک برای Preselect کردن Variant و Canonical پایه را آگاهانه طراحی کنید. اگر Variantها تفاوت تصمیم‌ساز و URL مستقل دارند، هر صفحه باید تصویر، قیمت، موجودی و داده خودش را نشان دهد. Google در راهنمای Product variant و ProductGroup از شناسه یکتا، URL قابل انتخاب و variesBy/hasVariant صحبت می‌کند؛ نسخه پیاده‌سازی را با معماری واقعی سایت هماهنگ کنید.

Product Schema و Feed: واقعیت صفحه باید یکسان بماند

Structured data جای متن قابل‌مشاهده نیست. برای صفحه فروش، Product/Offer می‌تواند نام، تصویر، SKU/GTIN/MPN، برند، قیمت، Currency، Availability، Shipping و Return policy را بیان کند. مستند Merchant listing گوگل الزامات جاری را توضیح می‌دهد؛ Eligibility و پشتیبانی بازار/حساب را همان زمان بررسی کنید و برای دورزدن محدودیت، کشور یا ارز ساختگی ثبت نکنید.

• قیمت و موجودی Schema، صفحه، Cart و Feed باید هم‌زمان باشند.
• priceCurrency باید Currency واقعی و معتبر معامله باشد؛ نمایش تومان را با داده Canonical اشتباه نکنید.
• Rating و Review فقط وقتی Markup شوند که واقعی، قابل‌مشاهده و مطابق Guidelines باشند.
• Variantها شناسه یکتا و رابطه Parent داشته باشند؛ SKU را میان دو کالا بازیافت نکنید.
• Rich result تضمین نیست؛ Valid بودن Schema نیز Accuracy تجاری را ثابت نمی‌کند.

برای طراحی Entity graph، تست Rich Results، رفع Duplicate و نکات ریال/تومان، راهنمای Schema و JSON‑LD را بخوانید.

اگر از Merchant Center استفاده می‌کنید

تنها در بازار و حساب واجد شرایط، Data feed را مطابق مقررات جاری بسازید. Product data specification گوگل برای Description بر اطلاعات مرتبط محصول، Attributeهای مهم و متن دستوری/خوانا تأکید دارد و Promotional text، لینک، اطلاعات پرداخت و Keyword list را در Description نمی‌خواهد. Title/Description و Landing page باید محصول یکسان را نمایش دهند.

Feed یک کانال جدا با محدودیت خودش است؛ پاراگراف صفحه را کورکورانه در همه Attributeها کپی نکنید. ID پایدار، Title، Description، Product detail، Image، Variant group، Price و Availability وظیفه جدا دارند. خطای Feed باید به Owner و Source field برگردد، نه با Override دستی بی‌ردپا حل شود.

اعتماد و الزامات ایران: اطلاعات تصمیم‌ساز را پنهان نکنید

متن زیر آموزش عمومی است و جای مشاوره حقوقی برای دسته، قرارداد و نسخه جاری مقررات را نمی‌گیرد. متن قانون تجارت الکترونیکی ایران در پایگاه NATLEX سازمان بین‌المللی کار در مواد ۳۳ تا ۳۵ بر ارائه اطلاعات مؤثر پیش از عقد—از مشخصات فنی و کاربردی تا هویت تأمین‌کننده، هزینه‌ها، شرایط معامله، ضمانت و پشتیبانی—به‌شکل روشن و ماندگار تأکید می‌کند. مواد ۳۷ تا ۴۲ نیز حق انصراف و استثناها را پوشش می‌دهند و مواد ۵۰ تا ۵۴ تبلیغ گمراه‌کننده و پنهان‌کردن حقیقت را منع می‌کنند.

نتیجه عملی برای صفحه محصول:

• قیمت باید واحد روشن داشته باشد؛ هزینه‌های تحویل و شرایط پرداخت پیش از تعهد قابل‌فهم باشند.
• هویت فروشنده، راه تماس/شکایت، ضمانت و پشتیبانی در مسیر خرید قابل‌دسترسی باشند.
• Policy مرجوعی را با یک نسخه ثابت برای همه کالاها ساده‌سازی نکنید؛ استثناهای نوع کالا و آیین‌نامه‌های جاری را بررسی کنید.
• «اصل»، «درمانی»، «استاندارد»، «ضدآب» و «تضمین نتیجه» ادعای عینی‌اند و Evidence/تأیید متناسب می‌خواهند.
• فوریت و کمیابی فقط از موجودی/زمان واقعی بیاید؛ Timer تکرارشونده یا موجودی ساختگی اعتماد و انطباق را به خطر می‌اندازد.

اعتماد را به نشان و جمله کلی تقلیل ندهید

نشان اعتماد یا Badge امنیتی نمی‌تواند ناسازگاری قیمت، Policy مبهم یا Review جعلی را جبران کند. Trust evidence نزدیک تصمیم قرار می‌گیرد: موجودی به‌روز، عکس Variant واقعی، نام فروشنده، شرایط Warranty، روش تماس و Review قابل‌ردیابی. برای Journey کامل محصول تا Checkout، راهنمای UX فروشگاه اینترنتی را ببینید.

محدودیت را به زبان قابل اقدام بنویسید

هشدار حقوقی یا فنی را با Font ریز دفن نکنید. بگویید کاربر چه چیزی را بررسی کند: «این کابل برای انتقال تصویر پشتیبانی نمی‌شود»، «پیش از خرید عرض چهارچوب را اندازه بگیرید» یا «برای حساسیت شناخته‌شده، فهرست ترکیبات را بررسی و از راهنمای متخصص پیروی کنید». Disclaimers مبهم Claim اصلی را خنثی نمی‌کنند.

نوشتن در مقیاس: Template، PIM و AI

نوشتن دستی هزار صفحه بدون مدل داده، کیفیت را حفظ نمی‌کند. ابتدا Taxonomy Attribute و Source of truth بسازید؛ سپس Template دسته و Rule تولید. بخش‌های مشترک مانند Policy را Component مرکزی کنید و محتوای SKU را از Fieldهای خودش پر کنید. «منحصربه‌فرد بودن» یعنی ارزش خاص صفحه، نه تغییر مترادف‌ها.

AI چه کاری می‌تواند و نمی‌تواند انجام دهد؟

مدل زبانی می‌تواند Factهای تأییدشده را به Draft، Bullet، نسخه کوتاه، FAQ یا ترجمه تبدیل و تناقض‌های احتمالی را علامت‌گذاری کند. نباید مشخصات ناموجود، Review، گواهی، نتیجه آزمون، سازگاری یا ادعای سلامت بسازد. Prompt باید فقط Sourceهای مجاز، Fieldهای ممنوع، لحن، قالب و الزام Citation داخلی را مشخص کند.

1. Fact sheet نسخه‌دار را Retrieval source کنید.
2. مدل را ملزم کنید برای هر Claim شناسه Source بدهد و «نامعلوم» را حفظ کند.
3. خروجی را با Rule و Schema validation کنترل کنید.
4. Reviewer دسته، Claimهای پرریسک و Sample را تأیید کند.
5. Prompt/model/version و Diff را برای Audit نگه دارید.

اگر محتوای AI را به کانال ثالث می‌فرستید، Policy همان کانال را بررسی کنید. مثلاً Merchant Center برای Title/Description تولیدشده با AI Attributeهای Structured و Digital source type تعریف کرده است؛ این الزام ممکن است تغییر کند، پس Documentation جاری را ملاک قرار دهید.

RACI محتوای محصول

QA پیش از انتشار

• Identity: نام، مدل، SKU، GTIN و Variant با محصول واقعی یکسان‌اند.
• Facts: هر عدد واحد، منبع و در صورت نیاز Tolerance دارد.
• Claims: ادعای عینی شاهد و Approver دارد؛ Superlative مبهم حذف شده است.
• Fit: اندازه/سازگاری، روش اندازه‌گیری و استثنا روشن‌اند.
• Transaction: قیمت، Currency، موجودی، محتویات، ارسال، ضمانت و مرجوعی سازگارند.
• Channel parity: Page، Schema، Feed، Cart و تبلیغ درباره SKU اختلاف ندارند.
• SEO: Intent، Title/H1، Meta، URL، Canonical، لینک و Index بررسی شده‌اند.
• Accessibility: Heading، جدول، Label Variant، Alt، Focus و Screen reader آزموده شده‌اند.
• Mobile/RTL: واحد، عدد، واژه لاتین، جدول و CTA در عرض کم خراب نمی‌شوند.
• State: Out-of-stock، Sale، Variant ناموجود و Error بارگذاری محتوا رفتار روشن دارند.

اثر توضیحات محصول را چگونه بسنجیم؟

بهبود متن را با «احساس بهتر» تأیید نکنید. ابتدا فرضیه بنویسید: «نمایش ابعاد داخلی نزدیک انتخاب Variant، خرید نامتناسب لپ‌تاپ را کم می‌کند». سپس Metric tree بسازید. Add-to-cart می‌تواند بالا برود ولی مرجوعی و Support cost هم بالا برود؛ نتیجه باید در Contribution دیده شود.

Tracking plan باید شناسه Product/Variant، نسخه محتوا، Experiment، Channel و Consent را داشته باشد. از ثبت متن Review یا داده شخصی در Analytics خودداری کنید. برای تعریف Event، Warehouse، Attribution و آزمایش، راهنمای تحلیل داده بازاریابی را ببینید.

A/B test را در سطح مناسب طراحی کنید

تغییر یک Product کم‌ترافیک شاید هیچ‌گاه Sample کافی نگیرد. Template را روی مجموعه‌ای همگن از SKUها با Randomization مناسب آزمایش کنید، ولی تفاوت قیمت، موجودی و فصل را کنترل کنید. یک‌زمان چند تغییر—عکس، قیمت، Copy و CTA—علت نتیجه را مبهم می‌کند. پیش از اجرا Primary metric، Guardrail، حداقل اثر مهم و مدت را ثبت کنید.

برای تفسیر Cart/Checkout و جداسازی مشکل متن از خطای پرداخت یا هزینه پنهان، راهنمای سبد خرید رهاشده مفید است. کاهش Abandonment به‌تنهایی اثبات نمی‌کند Copy بهتر شده؛ Mix موجودی و کمپین را هم ببینید.

تحلیل علت مرجوعی را به Backlog محتوا وصل کنید

• «اندازه مناسب نبود» → روش اندازه‌گیری، جدول و داده واقعی را بازبینی کنید.
• «با دستگاه سازگار نبود» → مدل/نسخه و Precondition را دقیق کنید.
• «رنگ متفاوت بود» → Color workflow، نمایشگر و عکس Variant را بررسی کنید.
• «فکر می‌کردم همراه است» → Included/Not included را بالاتر بیاورید.
• «کیفیت مطابق ادعا نبود» → Claim و Evidence را Audit کنید، نه اینکه فقط متن را ملایم‌تر کنید.

برنامه ۳۰روزه برای کاتالوگ موجود

روز ۱ تا ۵: Baseline و اولویت

• SKUها را با Revenue، Margin، ترافیک، مرجوعی، سؤال و Feed error امتیاز دهید.
• ۲۰ محصول پُراهمیت و یک دسته همگن برای Pilot انتخاب کنید.
• Baseline Conversion، Contribution، مرجوعی و Support را ثبت کنید.

روز ۶ تا ۱۲: مدل داده و Evidence

• Attribute dictionary، واحد، Parent/Variant و Source hierarchy بسازید.
• Fact sheet و Claim ledger را با خرید، انبار، کیفیت و پشتیبانی تکمیل کنید.
• ابهام‌های بدون منبع را به Owner و Deadline بدهید.

روز ۱۳ تا ۲۰: Template و تولید Pilot

• Template دسته، عنوان، Summary، Spec، Fit، محتویات و FAQ را طراحی کنید.
• Copy، تصویر/Alt، Product data و Policy context را برای Pilot بسازید.
• Legal/quality، Accessibility، SEO و Mobile QA اجرا کنید.

روز ۲۱ تا ۳۰: انتشار کنترل‌شده و یادگیری

• Page/Schema/Feed parity و Index/Structured data را پس از انتشار کنترل کنید.
• Experiment یا Rollout مرحله‌ای را با Guardrail فعال کنید.
• نتیجه، Incident و سؤال تازه را به Template/Fact backlog برگردانید.
• برای Rollout بعدی Owner، ظرفیت و SLA بازبینی تعیین کنید.

چک‌لیست نهایی نوشتن توضیحات محصول

• □ Product/Variant و مخاطب تصمیم مشخص است.
• □ Fact sheet نسخه‌دار و Source هر عدد موجود است.
• □ عنوان، مدل، اندازه/رنگ و Attribute اصلی را دقیق معرفی می‌کند.
• □ Summary در چند ثانیه تناسب و محدودیت مهم را روشن می‌کند.
• □ Feature به Mechanism و پیامد مشروط وصل است؛ Claim بی‌مدرک نداریم.
• □ مشخصات، واحد، محتویات و Not included ساختاریافته‌اند.
• □ سازگاری، روش اندازه‌گیری و «برای چه کسی نیست» نوشته شده‌اند.
• □ قیمت/موجودی/ارسال/ضمانت/مرجوعی روشن و سازگارند.
• □ کمیابی، Review و Social proof واقعی و قابل‌ردیابی‌اند.
• □ Keyword density یا LSI list تحمیل نشده؛ Intent و زبان طبیعی پوشش دارد.
• □ URL/Canonical/Variant، Product Schema و Feed با صفحه هم‌راستا هستند.
• □ تصویر هر Variant، Alt هدفمند و UX موبایل/RTL بررسی شده‌اند.
• □ AI فقط از Source تأییدشده استفاده کرده و Review انسانی ثبت شده است.
• □ Version، Owner، Trigger بازبینی و KPI/Guardrail تعیین شده‌اند.

پرسش‌های متداول

توضیحات محصول چند کلمه باشد؟

عدد ثابت وجود ندارد. پیچیدگی محصول و ریسک تصمیم طول را تعیین می‌کند. نام، Summary و Attributeهای حیاتی باید سریع دیده شوند؛ مشخصات، Fit، محدودیت، استفاده و Policy هرقدر لازم است ادامه یابند. صفحه ساده می‌تواند کوتاه باشد و کالای فنی به جدول و راهنمای مفصل نیاز داشته باشد.

آیا باید چگالی کلمه کلیدی را روی ۱ تا ۲ درصد نگه داریم؟

خیر. گوگل درصد مطلوب عمومی اعلام نکرده و تکرار غیرطبیعی را Keyword stuffing می‌داند. Query اصلی و Attributeهای واقعی را در عنوان، H1، متن، Alt و لینک مرتبط طبیعی بیاورید؛ کیفیت پوشش Intent را با Query و رفتار کاربر بسنجید.

آیا کپی توضیح سازنده باعث جریمه گوگل می‌شود؟

تکرار عادی محتوا خودبه‌خود مجازات نیست، اما صفحه‌ای که همان متن همه فروشندگان را دارد ارزش متمایز کمی می‌دهد و Canonical/Crawl پیچیده می‌شود. Fact سازنده را حفظ کنید و داده محلی، اندازه‌گیری، عکس، سازگاری، FAQ، خدمات و Evidence واقعی اضافه کنید.

آیا AI می‌تواند توضیحات همه محصولات را بنویسد؟

می‌تواند Draft مقیاس‌پذیر بسازد، به شرط Product truth ساختاریافته، منع Hallucination، Source ID، Validation و Review انسانی. ادعای سلامت/عملکرد، ضمانت، سازگاری، Review و مشخصات ناموجود نباید به مدل سپرده شوند. خروجی و Prompt/Model version را Audit کنید.

از کجا بفهمیم توضیحات محصول بهتر شده است؟

فرضیه و Baseline تعریف کنید و Conversion/Contribution را همراه مرجوعیِ علت‌دار، لغو، سؤال پشتیبانی، خطای Variant، Organic query و Feed error بسنجید. در صورت ترافیک کافی A/B test اجرا کنید؛ Add-to-cart بدون Guardrail پس از خرید معیار کامل نیست.

جمع‌بندی

توضیحات محصول حرفه‌ای از واژه‌های قدرت شروع نمی‌شود؛ از Product truth شروع می‌شود. صفحه باید هویت و Variant را دقیق کند، تناسب و محدودیت را نشان دهد، ادعا را به Evidence وصل کند، اطلاعات معامله را پیش از خرید آشکار سازد و Page/Schema/Feed را هم‌راستا نگه دارد. سپس باید با Conversion، Contribution، مرجوعی و پشتیبانی آزموده شود.

اقدام بعدی: یک SKU پُرفروش و پُرمرجوعی را انتخاب کنید. پنج چیز را کنار هم بگذارید: نمونه واقعی، Fact sheet، ده Query، ده سؤال/Review و علت‌های مرجوعی. هر تناقضی که پیدا می‌کنید، قبل از بازنویسی Copy یک مسئله Product data یا عملیات است.