مشخص کردن «نوع کالا» برای آگهی‌های مهاجر!


مقدمه

از ابتدای برنامهٔ فصلی تابستان دیوار، من از قبیلهٔ خودرو به قبیلهٔ کالا منتقل شدم. طبیعتا جنس مسائل قبیلهٔ کالا با مسائل قبیلهٔ خودرو متفاوته و همزمان روی چند دسته اصلی دیوار متمرکزه. اینجا با طیف وسیعی از کالاها سر و کار داریم، از انواع وسایل الکتریکی و الکترونیکی مثل موبایل و تبلت تا کالا‌های مربوط به خانه و آشپزخانه مثل فرش و مبل تا کالاهایی از جنس صنعتی و ابزارآلات.

همین تنوع دسته‌ها و کالاها و همچنین ابعاد بزرگ‌تر تیم کالا نسبت به خودرو، باعث شد حس کنم وارد فضای جدیدی شدم، مشابه حسی‌ که وقتی وارد مجموعه یا شرکت دیگه‌ای می‌شیم. برای اینکه با سرعت بیشتری خودم رو با فضای ذهنی تیم جدید همگام کنم، پیش از شروع رسمی فعالیتم در کالا، آگهی‌های متنوعی در دسته‌های کالایی ثبت کردم و آگهی‌های منتشر شده در این دسته رو با دقت بیشتری بررسی کردم و با تعدادی از آگهی‌گذاران کالاهای دیجیتال هم تلفنی صحبت کردم. وجود فرهنگ مستند‌سازی در ورتیکال‌های دیوار هم باعث شد خیلی زود بتونم از تصمیم‌های تخصص‌های مختلفی که در تیم وجود داشت مثل دیزاین، محصول و BI در OKR‌های قبلی آگاه بشم و فضای ذهنی‌م رو به هم‌تیمی‌هام نزدیک کنم.

قصدم از نوشتن کیس‌استادی‌ و منتشر کردنش اینه که با مطالعهٔ این اسناد، فضای متفاوت مسائل و محدودیت‌ها و چالش‌های مسیر رو، حتی با اینکه اون‌ها رو تجربه نکردیم، درک کنیم. تجربهٔ شخصی من از مطالعهٔ کیس‌استادی‌های همکاران و هم‌صنفانم در دیوار و خارج از فضای دیوار خیلی برای من آموزنده بوده و از اینکه می‌تونم خودم رو به جای دیزاینر اون مسئله تصور کنم لذت می‌برم و به راه‌حل‌های ممکن دیگه (که به اون‌ها پرداخته نشده) فکر می‌کنم.

شرح مسئله

پس از اتمام فرایند پیاده‌سازی مهاجرت دسته‌بندی‌های دیوار از دسته‌های قدیمی به دسته‌های جدید (به‌‌زودی مطلبی درمورد فرایند مهاجرت دسته‌های دیوار منتشر می‌کنیم) سطح جدیدی از دسته‌ها به نام «دستهٔ سطح ۳» به وجود اومد. دستهٔ سطح ۳ با این هدف ایجاد شد که ماهیت کالا رو تا حد زیادی مشخص کنه. طبق مثال زیر، می‌تونیم ببینیم که دسترسی به محصول «فرش» چطور در ساختار جدید دسته‌های دیوار قرار گرفته.

مسیر دسترسی به دستهٔ سطح ۳ یا نوع کالا از دستهٔ سطح ۱
مسیر دسترسی به دستهٔ سطح ۳ یا نوع کالا از دستهٔ سطح ۱

با اضافه شدن سطح جدید به ساختار دسته‌بندی دیوار، مسئلهٔ آگهی‌های فروشگاهی ایجاد شد.

پیش از اینکه جزئیات مسئله رو بررسی کنیم نیاز داریم تفاوت‌ آگهی‌های شخصی و آگهی‌های فروشگاهی دیوار رو بدونیم. آگهی‌های شخصی (که همهٔ کاربران می‌تونن این نوع آگهی‌ها رو ثبت کنن) پس از طی کردن فرایند ثبت شدن و بررسی ناظران آگهی در دیوار منتشر می‌شن و از اون تاریخ به مدت ۳۰ روز در دیوار باقی می‌مونن.

اما کاربر فروشگاه‌های دیوار بعد از خریدن بستهٔ مرتبط با دستهٔ آگهی می‌تونه در دیوار آگهی ثبت کنه و مهم‌ترین تفاوت آگهی‌های فروشگاهی با آگهی‌های شخصی، منقضی نشدن آگهی‌های فروشگاهیه.




مسئلهٔ ما دقیقا جایی پیش میاد که وقتی تغییرات دسته‌های دیوار شامل آگهی شخصی و فروشگاهی کالا‌های فروشگاه‌های دیوار می‌شن، هم آگهی‌های شخصی و هم آگهی‌های فروشگاهی نوع محصول یا همون «دستهٔ سطح ۳» این کالاها ناقص و نامشخصه.

و با توجه به این که این آگهی‌ها تاریخ انقضا ندارن، همواره در دیوار باقی می‌مونن و باید برای همراه کردن اون‌ها با فرایند مهاجرت دسته‌ها فکری می‌کردیم، در واقع نیاز بود نوع محصول رو در کالاهای فروشگاهی مشخص کنیم.

با همراهی مدیر محصول در بررسی‌ نتیجهٔ یکی از پژوهش‌ها متوجه شدم هر ماه ۲۵۰۰۰ آگهی شخصی به وضعیت انقضای مهلت انتشار می‌رسن که بیشتر اون‌ها در دستهٔ «مربوط به خانه» قرار دارن و تعداد کمی در دسته‌های «برای کسب و کار» و متفرقه‌های «لوازم الکترونیکی»

تصمیم گرفتیم که روی آگهی‌های فروشگاهی متمرکز بشیم. آگهی‌های شخصی با توجه به تعداد اندک‌شون، نسبت به آگهی‌های فروشگاهی اولویت کمتری داشتن.

در ادامه نیاز داشتم بدونم آگهی‌های دستهٔ «مربوط به خانه» و دسته‌های کالایی دیگه، چند درصد از آگهی‌های فروشگاهی رو به خودشون اختصاص می‌دن.

پس از این بررسی و با هماهنگی مدیر محصول، تصمیم گرفتیم مسئله رو به آگهی‌های دستهٔ «مربوط به خانه» محدود کنیم و راه‌حل نهایی رو روی این آگهی‌ها اجرا کنیم و در صورت موفقیت‌آمیز بودنش، برای دسته‌های دیگه‌ نیز در ادامهٔ فرایند مهاجرت دسته‌ها، از همون راه‌حل استفاده کنیم.

در بررسی‌ اولیه مشخص شد گزینهٔ پرداخت و تمدید یک هفته پیش از انقضای آگهی فعال می‌شه. قبل از این بررسی فکر می‌کردم که این گزینه از روز ۷ام انتشار آگهی تا روز ۲۹ام انتشار آگهی فعاله.

دو فلوی دیگه وجود داره که به فلوی پرداخت برای انتشار آگهی می‌رسن:

  • آگهی‌گذاران پرمصرف (Over User)
  • آگهی‌های دستهٔ «تجهیزات و صنعتی»
اگه بخوام داخل پرانتز کاربران اوریوزر یا اوریوزیج (Over Usage) رو در دیوار معنی کنم، باید بگم این واژه لقب کاربران شخصی پرمصرف و پرفعالیت دیواره که ممکنه در هر ورتیکال دیوار فعالیت‌های متنوعی داشته باشن. برای مثال در خودرو ممکنه کاربر اوریوزج نمایشگاه‌دار باشه اما در دستهٔ لوازم الکترونیکی، کاربر اوریوزرج فروشگاه لوازم جانبی موبایل داره و عمده فروش هم هست.

کاربر دستهٔ کسب و کار ابتدا باید هزینه انتشار آگهی رو پرداخت کنه و تا زمانی که پرداخت نکرده، صفحهٔ تمدید و نردبان و فوری رو نمی‌تونه ببینه.و چون این دسته‌بندی شامل مهاجرت دسته‌های ما نمی‌شه، باهاش کاری ندارم.

ارائه راه‌حل، بدون نیاز به ریلیز نسخهٔ جدید!

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

توضیح مختصری در مورد پیاده‌سازی «بدون ریلیز»:پیاده‌سازی صفحات دیوار با ۳ معماری متفاوت انجام شده که یکی از اون‌ها رو widget-based صدا می‌کنیم.صفحاتی که معماری widget-based دارن، می‌تونن از Back-end ویجت‌های مشترکی رو که روی نسخه‌های اپلیکیشن و وب دیوار (کلاینت) پیاده شدن، کنترل کنن و اونا رو تغییر بدن.این تغییرات شامل نمایش دادن یا عدم نمایش ویجت‌ها در صفحه، اولویت نمایش دادن ویجت‌ها در صفحه، تغییرات props و Override‌های ویجت‌ها و... می‌شه.

ارائهٔ راه‌حل بدون نیاز به ریلیز، برای دیزاین محدود‌یت‌هایی رو ایجاد می‌کرد. به این دلیل که تعدادی از ویجت‌ها (یا همون کامپوننت‌های دیزاین سیستم سنّت) به طور موازی روی کلاینت و همچنین در back-end پیاده‌سازی نشدن و باید این دو محدودیت رو در ارائهٔ راه‌حل لحاظ می‌کردیم:

  • استفاده از ویجت‌هایی که در کلاینت (وب/اپلیکیشن) پیاده‌سازی شدن.
  • محدود کردن راه‌حل به تاچ‌پوینت‌هایی که معماری widget-based داشتن.

فرایند ایده‌پردازی راه‌حل

راه‌حل اول: اضافه کردن فیلد نوع کالا به آگهی در صفحهٔ مجزا و جدید

برای اولین راه‌حل، سراغ صفحهٔ مدیریت آگهی رفتم. مسیر کاربری که به این صفحه می‌رسید از صفحهٔ مدیریت فروشگاه می‌گذشت، به این ترتیب که وقتی فقط ۱ هفته تا انقضای آگهی‌ش باقی مونده بود، کاربر برای ارتقای اون متوجه می‌شد باید آگهی رو ویرایش و «نوع کالا» رو مشخص کنه.

کاربر برای ارتقا و تمدید (یک هفته قبل از منقضی شدن) آگهی‌هایی که در وضعیت منتشر شده هستن، باید فیلد نوع کالا رو تکمیل کنه. در این ایده، مرحلهٔ تکمیل فیلد نوع کالا رو قبل از انتخاب بسته‌های تمدید و فوری قرار دادیم تا کاربر با انتخاب اکشن ارتقاء آگهی بتونه اول فیلد نوع کالای خودش رو تکمیل کنه و بعد بستهٔ مورد نظرش برای تمدید، نردبان و یا فوری رو انتخاب کنه.

فیلد نوع کالا رو به دلیل محدودیت فنی نمی‌تونستیم از ویرایش آگهی جدا کنیم و این تغییر به دلیل اینکه نیاز به «ریلیز» داشت، اجرا نشد.

راه‌حل دوم: قرار دادن فیلد نوع کالا در صفحهٔ مدیریت آگهی

به این فکر کردم که از ساختار open-page استفاده نکنیم، بلکه فیلد «نوع کالا» رو در صفحهٔ مدیریت آگهی قرار بدیم و این تغییر رو با یک توضیح کوتاه اضافه کردیم تا کاربر از مزیت این تغییر آگاه بشه. (تصویر سمت راست)

مثل موردی که در راه‌حل اول اتفاق افتاد، برای راه‌حل سمت راست، در مرحلهٔ بعد نیاز داشتیم فیلد نوع کالا رو مجزا نمایش بدیم که امکان‌پذیر نبود و برای دیزاین سمت چپ چون ویجت note-row و ایندیکیتور رو به ردیف ویرایش اضافه کردیم، نیاز به ریلیز داشتیم.

ویجت note-row توی صفحهٔ مدیریت آگهی‌ پیاده‌سازی نشده بود و نمی‌تونستیم از اون برای این فاز استفاده کنیم.

راه‌حل سوم: تغییر در نمایش آگهی‌های صفحهٔ مدیریت فروشگاه

یکی از اصلی‌ترین جاهایی که به نظرم رسید می‌تونم در این صفحه به کاربر اطلاع‌رسانی کنم، صفحهٔ مدیریت فروشگاه بود و تصمیم گرفتم در این مرحله کاربر رو از آگهی‌هایی که باید تغییر کنن، مطلع کنم.

در ابتدا ویجت‌های پیاده‌سازی‌شدهٔ این صفحه رو بررسی کردم.

راه‌حل‌های پیشنهادی صفحهٔ مدیریت فروشگاه که مردود شدن

  • استفاده از تگ «منتشر شده» و تغییر اون به عبارت دیگه‌ای مثل «نیاز به اصلاح»

در این فاز نمی‌خواستیم آگهی رو از وضعیت «منتشر شده» خارج کنیم، چون ممکن بود کاربر با تغییر برچسب آگهی‌ها در صفحهٔ مدیریت فروشگاه، برداشت اشتباهی داشته باشه و فکر کنه آگهی‌ش از دسترس سایر کاربران دیوار خارج شده و دیگه نمایش داده نمی‌شه.

  • ترکیب کردن اطلاعات روی آگهی و یا حذف موقتیِ موردی با اهمیت و اولویت پایین‌تر

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

راه‌حل نهایی: مشخص کردن نوع کالا در مدیریت فروشگاه!

پیشنهاد استفاده از ویجت‌های تایتل، دسکریپشن و سلکتور رو دادم با این هدف که بتونیم آگهی‌هایی که نیاز به ویرایش دارن رو به صفحهٔ جدیدی منتقل کنیم و در صفحهٔ جدیدی همه آگهی‌هایی که به ویرایش نیاز دارن رو لیست کنیم.

این ویجت‌ها مزایایی داشتن:

  • در کلاینت (وب و اپلیکیشن) پیاده‌سازی شده بودن
  • امکان ارائهٔ توضیحات کافی و کامل داشتن

با این روش می‌تونستیم آگهی‌هایی که نیاز به ویرایش دارن رو به نوعی فیلتر کنیم و خروجی رو در صفحهٔ جدیدی نمایش بدیم.

برای همین نیاز داشتیم:

  • بتونیم آگهی‌های مربوط به خانه رو از سایر آگهی‌ها تشخیص بدیم.
    بررسی شد: این شرط شامل آگهی‌های دسته‌بندی مربوط به خانه‌‌‌ای می‌شه که هنوز «دستهٔ سطح ۳» اون‌ها انتخاب نشده (بعضی از آگهی‌ها رو به صورت دستی و با کمک تیم عملیات اصلاح کردیم)، این آگهی‌ها رو می‌تونیم متمایز و انتخاب کنیم. فیلد «نوع کالا» فیلدی اجباری‌ست و کاربر با رسیدن به مرحلهٔ ویرایش آگهی، بدون مشخص کردن این فیلد نمی‌تونه ویرایش پست رو ترک کنه.
  • بتونیم صفحهٔ جدید و موقتی‌ای رو به عنوان لیستی از آگهی‌های مربوط به خانه داشته باشیم و بعد از تغییر دیگه نداشته باشیم.
    بررسی شد: این موضوع با تیم فنی مطرح شد و تونستیم لیستی از آگهی‌هایی که مشخص کردیم رو در صفحهٔ جدید نمایش بدیم. این لیست Lazy Load داره و بعد از هر اکشنی، اگه آگهی‌های بیشتری باشن که توی لیست نمایش داده نشدن (مثلا ۲۰ آگهی رو داریم نشون می‌دیم و تعداد آگهی‌هایی که باید نمایش داده بشن ۲۵ عدده) لیست بدون اینکه کاربر متوجه بشه دوباره لود می‌شه و این برامون مطلوبه.
  • در صفحهٔ مدیریت فروشگاه، بعد از این که تغییرات روی آگهی‌ها انجام شد، ویجت‌های جدید دیگه‌ نمایش داده نشن.
    بررسی شد: در صورتی که از ویجت‌های پیاده‌سازی شده Back-End استفاده بکنیم، می‌تونیم اون‌ها رو در این صفحه به‌ شکل داینامیک نمایش بدیم و در صورت نیاز نمایش اونها رو متوقف کنیم.

ارائهٔ راه‌حل نهایی

در صفحهٔ مدیریت فروشگاه، به اطلاع‌رسانی با وزن بیشتری نیاز داشتیم تا مبدأ ویرایش آگهی رو در متن پستچی به کاربر اطلاع بدیم. زحمت نوشتن متن‌های پستچی دیوار رو باهار ابراهیمی عزیز، تجربه‌نویس دیوار می‌کشه.

همیت تغییر در صفحهٔ مدیریت فروشگاه برامون زیاد بود و چون می‌خواستیم بدون ریلیز کاربرها رو با این تغییر همراه کنیم و برای این کار محدودیت‌هایی داشتیم، نیاز بود از ویجت‌هایی استفاده کنیم که در کلاینت‌های اندروید، iOS و همینطور وب پیاده‌سازی شده بودن.

ویجت‌های DescriptionText ، title-row و selector-row رو با هدف آگاه کردن کاربر از اینکه لیست آگهی‌هایی که به تغییر نیاز دارن رو ببینه ایجاد کردیم، نمی‌خواستیم این لیست رو به همون صفحهٔ مدیریت فروشگاه اضافه کنیم و ساختارش رو تغییر بدیم، به همین دلیل به این فکر کردیم که در صفحه‌ای جدید این کار رو انجام بدیم و لیستی از اون آگهی‌ها ایجاد کنیم.

بعد از اینکه این راه‌حل و استفاده از این سه ویجت رو با تیم فنی مطرح کردیم، فهمیدیم روی اندروید و وب ۱ سال گذشته و روی iOS تا نسخه‌های ۶ ماه گذشته می‌تونن این ویجت‌های جدیدمون رو ببینن و این برامون مطلوب بود.

پس این ویجت‌ها رو بعد از بخش معرفی فروشگاه و ویرایش اطلاعات فروشگاه در نظر گرفتیم که قبل از نمایش آگهی‌ها به قدر کافی جلب توجه کنه، استفاده از این ویجت‌ها برای دیدن آگهی‌هایی که پایین‌تر قرار گرفتن هم از لحاظ بصری مانعی نداره و در viewport ابتدای لیست آگهی‌ها مشخصه.

کاربر پس از انتخاب هر آگهی که در لیست جدید وجود داره (طبق فلوی مدیریت آگهی) باید به صفحهٔ مدیریت آگهی منتقل بشه و بعد از انتخابِ ویرایش و در مرحلهٔ دوم، نوع کالا رو انتخاب کنه.

فکر کردیم خوبه این مسیر رو برای آگهی‌های لیست کوتاه‌تر کنیم و کاربر رو مستقیما به فلو ویرایش آگهی‌ بفرستیم، یعنی با انتخاب این آگهی، صفحهٔ ویرایش رو ببینه و از مرحلهٔ مدیریت آگهی عبور کنه.

البته این شامل آگهی‌های صفحهٔ فروشگاه که شرط «اضافه شدن نوع کالا» رو دارن نمی‌شه و طبق فلو فعلی، کاربر با انتخاب هر آگهی به صفحهٔ مدیریت آگهی منتقل می‌شه.

البته برای این صفحه هم راه‌حلی ارائه دادیم و برای آگهی‌هایی که «نوع کالا» ندارن، ردیف ویرایش رو با کمک indicator واضح‌تر کردیم و نیاز به ویرایش آگهی رو در قالب توضیح کوتاهی ارائه کردیم.

سنجش اثر این راه‌حل

اثربخش بودن این راه‌حل رو با تعبیه کردن Action-Log (وظیفهٔ جمع‌آوری دیتای دفعات استفاده رو به عهده داره) برای این ویجت‌ها و آگهی‌هایی که با این ویجت‌ها فیلد نوع کالاشون تکمیل شده، سنجیدیم. پس از مهاجرت به دسته‌های جدید دیوار، در زمان اجرای راه‌حل در محصول (release) حدودا ۲۰۰ هزار آگهی منتشر شده فروشگاهی دستهٔ مربوط به خانه، فیلد نوع کالا (دستهٔ سطح ۳) نامشخص داشتن که در زمان نگارش این سند به ۴ هزار آگهی (در فاصلهٔ ۳ ماه) کاهش پیدا کردن و روند این کاهش ادامه داره.