بعد از موفقیت اسنپ در بازار ایران، تقریبا هرکسی حداقل یک بار به این فکر کرده است که یک پلتفرم بسازد تا در آن یک کاری که قبلا با تماس فیزیکی یا تلفن انجام میشده را سر و شکلی دیجیتال بدهد. مثلا برای نظافت خانه، ویزیت شدن توسط پزشک، پیدا کردن معلم برای آموزش و... می‌توان پلت‌فرم‌هایی توسعه داد که در آن صاحب‌خانه یک نظافتچی پیدا کند، بیمار، پزشک مد نظرش را بیابد و ویزیت شود و دانش آموز برای آموختن درس از یک معلم کمک بگیرد. در همه انواع پلتفرمها عده‌ای از کاربران سرویسی را عرضه می‌کنند (producers)، مثل راننده‌ها در اسنپ و دیگران متقاضی آن سرویس هستند (consumers) مثل مسافران در اسنپ. زمانی که در یک پلتفرم فرایندهای خرید و فروش و تراکنش‌های مالی اتفاق بیوفتد از آن با نام مارکت پلیس (Marketplace) هم یاد می‌کنند. در واقع از دو کلمه پلتفرم و مارکت پلیس به جای یکدیگر در مواقع بسیاری استفاده می‌شود اما در کل منظور یک شبکه‌ی انسانی است که میان عرضه‌کنندگان و متقاضیان به صورت مجازی شکل می‌گیرد.
به نظر شما اولین مساله مهم در توسعه یک پلتفرم چیست؟ انتخاب تکنولوژی؟ شناسایی فرایندهای عملیات و خودکارسازی آن؟ طراحی یک تجربه کاربری بی‌نظیر برای تعامل کاربران با پلتفرم؟ نه! اولین و مهم‌ترین سوال برای توسعه پلتفرم این است که اول عرضه‌کننده‌گان را وارد بازی کنیم یا متقاضیان را؟
طبیعتا تا وقتی به اندازه کافی مسافر در یک پلتفرم تاکسی نباشد، راننده‌ای هم جذب آن نخواهد شد و بالعکس. یعنی اگر تعداد مسافران محدود باشد هرچقدر هم راننده جذب شود در مدتی کوتاه خارج می‌شوند زیرا سفرهای کمی نصیب‌شان خواهد شد. به این چالش در دنیای پلتفرم مساله مرغ و تخم‌مرغ گفته می‌شود.
در واقع برای توسعه یک پلتفرم موفق لازم است؛ استراتژی‌های مناسبی اتخاذ کرد تا به مرور جمعیت هر دو سر بازی به میزان مطلوبی رشد نماید. حضور توامان عرضه‌کننده و متقاضی، نوید این را می‌دهد که به زودی چرخه پلتفرم به حرکت بیوفتد.
در یک پلتفرم نقشه سه دارایی (asset) مهم وجود:
دارایی به همان عنصر باارزشی گفته می‌شود که میان عرضه‌کننده و متقاضی در ازای پرداخت پول یا به رایگان، رد و بدل می‌گردد. برای اینکه فهم مشترکی از کلمه دارایی شکل بگیرید، بیایید یک پلتفرم تاکسی اینترنتی را در نظر بگیریم. در این پلتفرم، سفر یک دارایی محسوب می‌شود. راننده، مسافر را طی یک سفر از مبدا به مقصد می‌رساند و در ازای آن کرایه دریافت می‌کند. صاحبین پلتفرمها اگر تنها یک هدف داشتند، آن هدف چیزی نبود جز بیشینه‌سازی دارایی!
تفاوت اصلی یک پلتفرم نقشه با پلتفرم‌های شناخته شده در این است که میان عرضه‌کننده و متقاضی نمی‌توان مرز مشخصی قائل شد. کاربران یک اپلیکیشن نقشه و مسیریاب همزمان می‌توانند مصرف‌کننده و تولیدکننده دارایی‌های آن اپلیکیشن باشند. یعنی من و شما به عنوان یک استفاده‌کننده لازم داریم تا جایی که به دنبالش هستیم را روی نقشه پیدا و آن را به عنوان مقصد انتخاب کنیم، سپس با در نظر گرفتن ترافیک راه‌ها، بهترین مسیرها را تا مقصد مشاهده کنیم. اما این دارایی‌ها برخلاف تصور همه نیاز به عرضه‌کنندگانی دارد تا همیشه کامل و صحیح باشند. اما عرضه‌کنندگان در این دست پلتفرمها به صورت داوطلبانه در تولید دیتا مشارکت می‌کنند. از همین‌رو شناسایی و نگهداری عرضه‌کنندگان و همینطور افزایش میزان مشارکت، چالش‌های پیچیده‌ای را برای صاحبین پلتفرم ایجاد می‌کنند.
در ادامه، استراتژی‌های اتخاذ شده برای به حرکت درآوردن چرخه‌ی میان عرضه‌کننده و مصرف‌کننده را برای هر کدام از دارایی‌ها، مورد بررسی قرار می‌دهیم. اما قبل از هرچیز لازم است با یک فانل (Funnel) مهم از رفتار کاربران روتا آشنا شویم.
شاید تا بحال درباره قیف بازاریابی یا فروش چیزهای زیادی شنیده باشید. در هر محصول جریان‌های کاربری (User flow) متعددی وجود دارد. اما هدف نهایی یک چیز است: فروش کالا. برای ایجاد یک قیف برای محصول لازم است تا گام‌های مهم کاربر در جریان کارش با محصول را به یکی از قسمت‌های قیف متناظر کنیم. یعنی به صورت انتزاعی می‌توان گفت: کاربر با انجام سه گام یا بیشتر به هدف اصلی محصول می‌رسد. نکته حائز اهمیت در تحلیل یک قیف محصولی، نرخ تبدیل (Conversion rate) هر گام به گام بعدی است. هرچه نرخ تبدیل هر گام بیشتر شود، در نهایت تعداد کاربران بیشتری به آخرین مرحله از قیف و در واقع هدف اصلی محصول می‌رسند. فاکتورهای مختلفی در نرخ تبدیل قیف محصول تاثیرگذار هستند و افراد مختلفی از تیم محصول همچون طراح محصول، مدیر مارکتینگ محصول و حتی مدیر SRE در قبال بهبود آن مسئول هستند.
در تصویر فوق، یک قیف ناوبری را مشاهده می‌نمایید. در این قیف ۳ گام اصلی از جریان کاربری متناظر شده است. هدف اصلی ما بالا بردن نرخ تبدیل در هر گام از قیف است چرا که آخرین گام از این قیف نشان می‌دهد چه تعداد از کاربران تا لحظه رسیدن به مقصد ناوبری را ترک نکرده و در اپ روتا مانده‌اند. در ادامه خواهیم دید چرا حضور کاربران در اپ هنگام ناوبری برای پلتفرم نقشه بسیار با اهمیت است. اما الان مروری کوتاه بر گام‌های قیف ناوبری خواهیم داشت:
توقع کاربران امروزی از یک اپ نقشه و مسیریاب با توقع کاربران ۱۰ سال پیش بسیار متفاوت است. دیگر نمایش نقشه خیابان‌ها و ارائه یک مسیر ثابت برای یک جفت مبدا و مقصد کسی را راضی نمی‌کند. کاربران انتظار دارند که ترافیک لحظه‌ای معابر به آنها نمایش داده شود و بر اساس همین ترافیک چندین مسیر پیشنهادی از اپلیکیشن دریافت نمایند. اما این ترافیک از کجا به دست پلتفرم‌های نقشه می‌رسد؟
شیوه‌های متعددی برای استخراج ترافیک معابر وجود دارد که توضیح آنها از حوصله این بحث خارج است. یکی از این شیوه‌ها، تحلیل خطوط سیر (Trajectory) به جا مانده از کاربران پلتفرم هنگام ناوبری و استخراج ترافیک معابر در پنجره‌های زمانی از پیش تعیین شده است. دوباره همان مساله مرغ و تخم‌مرغ! کاربران نقشه اگر ترافیک دقیقی دریافت نکنند، اپ را پاک می‌کنند و از سوی دیگر تا جمعیت کاربران زیاد نشود، نمی‌توان انتظار ترافیک دقیق داشت.
برای شروع لازم بود تا یک نسخه کمینه برای ترافیک راه‌ها توسعه دهیم تا یک ترافیک حداقلی برای نمایش روی نقشه و محاسبه هنگام مسیریابی در اختیار داشته باشیم. از این رو تصمیم گرفتیم تا ترافیک را از سرویس‌های خارجی کرال کنیم. کرال در راه‌های سطح بالا انجام میشد زیرا ریسک بلاک شدن وجود داشت. از طرفی دیگر اگر قرار بود تمام کوچه و پس‌کوچه‌ها را کرال کنیم نیاز بود تا زمان زیادی برای پردازش آن دیتا صرف گردد. در صورتی که دیتای ترافیکی نهایتا ۱۰ دقیقه معتبر است و بعد از آن به درد مصرف نمی‌خورد.
مدل‌سازی ترافیک راه‌ها نیازمند تاریخچه گسترده‌ای از خطوط سیر تولیدشده توسط کاربران نقشه به عنوان ورودی مدل هوش مصنوعی است. پس لازم است کاربران بیشتری شروع به ناوبری کنند و تا رسیدن به مقصد ناوبری را ترک نکنند. حالا اهمیت بالای قیف ناوبری برای ما واضح‌تر می‌شود. در واقع افزایش نرخ تبدیل قیف ناوبری کاربران روتا، مهم‌ترین مساله‌ای بود که باید راه حلی برایش پیدا می‌کردیم.
با توجه به مشخص بودن صورت مساله و تجربه موفق Waze در استفاده از گیمیفیکیشن، تصمیم بر این شد تا با برگزاری یک دیزاین اسپرینت (Design sprint) مکانیک‌های ساده‌ای برای سرگرم کردن رانندگان برای اپ طراحی کنیم. یکی از مکانیک‌های طراحی شده امتیازی بود که کاربران به ازای هر کیلومتر ناوبری با روتا دریافت می‌کردند. همین مکانیک ساده باعث بهبود چشم‌گیر نرخ تبدیل در قیف ناوبری شد. حالا با کاربرانی رو به‌رو بودیم که سابقه طی کردن چند هزار کیلومتر با روتا را داشتند!
هم‌اکنون ترافیک لحظه‌ای معابر شهرهای تهران،کرج، مشهد، اصفهان و شیراز روی نقشه روتا قابل مشاهده است و هنگام ارائه مسیر پیشنهادی به کاربران در نظر گرفته می‌شود و از طریق دو شاخص مهم به صورت روزانه مورد ارزیابی قرار می‌گیرد:
شبکه معابر کشور پهناوری مانند ایران، روزانه تغییرات بسیار زیادی را به خود می‌بیند. کاربرها انتظار دارند که هر کوچه‌ای که شهرداری مسدود می‌کند یا راهنمایی و رانندگی یک طرفه می‌کند در کم‌ترین زمان ممکن روی نقشه اعمال شود. آپدیت نبودن شبکه معابر ضربه بزرگی به نرخ تبدیل قیف ناوبری می‌زند. کاربرانی که چندین بار به بن‌بست هدایت شوند یا مسیر یک طرفه بگیرند اگر هم اپ را پاک نکنند، حتما نرخ تبدیل را کاهش خواهند داد.
این گره تنها به دست خود کاربران باز خواهد شد. اگر هر کاربری که مشکلی در شبکه معابر مشاهده می‌کند، نوع و موقعیت مشکل را به پلتفرم بازخورد دهد، انتظار می‌رود به مرور زمان ایرادات رفع گردد و همیشه یک نقشه آپدیت از راه‌های کشور داشته باشیم. اما چگونه باید انگیزه کاربران برای مشارکت در تکمیل و اصلاح شبکه معابر را افزایش داد؟
شاید دوباره همانند راه حلی که برای ترافیک معابر ارائه شد، بتوان از گیمیفیکیشن برای افزایش مشارکت کاربران بهره برد. مثلا در ازای گزارش‌های صحیح، امتیازاتی به کاربران اهدا شود. اما این بار کمی داستان متفاوت است. استفاده از استانداردهای OSM برای ذخیره و نگهداری دیتا، اعمال فیدبک (گزارش) کاربران را با کندی مواجه می‌کند. زیرا نیازمند عملیات (Operation) سنگین دستی هستیم. به زبان ساده‌تر در حالتی که عملیات به صورت دستی صورت می‌گیرد، میانگین زمانی که طول می‌کشد تا یک گزارش صحت‌سنجی و سپس در نقشه اعمال شود، آنقدر زیاد است که هم کاربران را ناامید می‌کند و هم نمی‌توان به راحتی از مکانیک‌های گیمیفیکیشن بهره برد. از این رو می‌بایست تا توسعه پایپ‌لاین‌های خودکار توزیع و انتشار فیدبک کاربران، سراغ رفع نیازهای سایر افراد درگیر در پلتفرم رفت!
در کنار رانندگانی که از پلتفرم‌های نقشه استفاده می‌کنند گروهی دیگر هستند با عنوان کاوشگر (Explorer). برای این گروه پیدا کردن موقعیت مکان‌های دنیای واقعی روی نقشه یا پیدا کردن مکان‌هایی بر اساس دسته‌بندی خاص (مثلا کافه‌های اطراف) و مشاهده جزئیات آن مکان (همانند ساعت باز یا بسته بودن) از اولویت بالایی برخوردار است. اگر کاوشگران را مصرف‌کننده اصلی بانک اطلاعات شهری بدانیم، گروهی دیگر باید زحمت عرضه اطلاعات مورد نیاز را به دوش بکشند. آنها کسی نیستند جز صاحبین کسب و کاری که می‌توانند به‌روزترین و صحیح‌ترین اطلاعات مربوط به مکان خود را در پلتفرم عرضه کنند. دوباره رسیدیم به همان سوال جذاب: اول به کاوشگرها بگوییم که قرار است با یک دایرکتوری مشاغل کامل رو به رو شوند یا اول به صاحبین کسب و کار این نوید را بدهیم که هزاران کاربر منتظر ثبت کسب و کارشان هستند؟
طبیعتا همانند چالش‌هایی که با ترافیک و شبکه معابر داشتیم، نباید منتظر آمدن صاحبین کسب و کار برای ثبت مکان خود می‌ماندیم. از این رو در ابتدا با انتخاب یک مکانیزم کلد استارت شروع به جمع‌آوری بانک اطلاعات شهری از اینترنت کردیم. به صورتی که چیزی حدود ۳۰۰ هزار POI (Point Of Interest) ثبت شده روی نقشه قابل مشاهده است و کاربران می‌توانند اطراف خود را برای اصناف مختلف جستجو نمایند. اما چالش اصلی به روز نگه داشتن این بانک اطلاعاتی است زیرا به مروز زمان اتفاقات مختلفی ممکن است برای یک مکان رخ دهد از جمله: تعطیل شدن، نقل مکان به جای دیگر، تغییر کاربری یا تغییر نام.
تصمیم گرفتیم تا همانند استراتژی OpenTable که حدود ۲ دهه قبل اتخاذ کرده بود، رفتار کنیم. کریس دیکسون از این استراتژی با نام حالت تک نفره (Single player mode) یاد می‌کند. اپن‌تیبل یک سرویس آنلاین رزرو میز و رستوران است. مساله مرغ و تخم‌مرغ در این استارتاپ میان حضور مشتریان و رستوران‌داران پدیدار شده بود. مشتری‌ها انتظار داشتند با انتخاب‌های زیادی رو به رو شوند ولی از طرف دیگر تا جمعیت کاربران استارتاپ زیاد نمیشد، رستوران‌ها ارزشی در همکاری کردن نمی‌دیدند. از این رو مدیران محصول OpenTable تصمیم گرفتند در شروع کار تنها نیازهای سمت عرضه‌کننده را رفع نمایند (نیازهایی همچون مدیریت و ارتباط با مشتریان). طوری که انگار این محصول تنها یک بازیگر (Player) دارد و قرار است برای او توسعه داده شود.
پس از توسعه MVP مورد نیاز، وقت ارزیابی فرضیات و از همه مهم‌تر پروسه اعتبارسنجی ادعای مالکیت صاحبین کسب و کار رسیده بود. همزمان یکی از شرکت‌های بیمه با مساله مهمی رو به رو شده بود. آنها می‌خواستند موقعیت جغرافیایی تمام شعب و نمایندگی‌های فروش بیمه را در یک بانک اطلاعاتی جامع جمع‌آوری نمایند. با توجه به اینکه نماینده‌های فروش بیمه در سگمنت رفتاری - بازاری استراتژی اتخاذ شده قرار می‌گرفتند، اقدام به اجرای یک کمپین مشترک نمودیم. در این کمپین نمایندگان بیمه موظف شدند تا برای نمایندگی خود در نقشه روتا ادعای مالکیت انجام دهند و پس از طی فرایند اعتبارسنجی، POI خود را مدیریت نمایند.
پس از اتمام این کمپین، ۳۰۰ نماینده فروش بیمه موفق شدند کسب و کار خود را در روتا ثبت کنند و مدیریت صفحه خود را به عهده بگیرند. در تمام مدت اجرای کمپین مشترک، شاخص‌هایی تحت نظر تیم روتا قرار داشت و به کمک آنها سرعت و دقت فرایند ادعای مالکیت، مشکلات طراحی جریان کاربری هنگام ارسال درخواست مالکیت و کاربردپذیری فیچرهای طراحی شده، مورد ارزیابی قرار می‌گرفتند. این شاخص‌ها عبارتند از: ۱) تعداد درخواست‌های ادعای مالکیت ۲) میانگین زمان صرف شده از زمان درخواست مالکیت تا انتشار روی نقشه ۳) میزان استفاده صاحب کسب و کار از هر فیچر طراحی شده.
در این مقاله سعی کردم اندکی درباره چالش‌های محصولات پلتفرمی صحبت کنم. دوست داشتم از دیدگاه پلتفرم به یک اپلیکیشن نقشه و مسیریاب نگاه کنیم و کمی در رابطه با بزرگ‌ترین چالش پلتفرمها، یعنی حل مساله مرغ و تخم‌مرغ تامل کنیم. طبیعتا برای حل یک مساله در دنیای واقعی تنها یک راه حل وجود نداره و حتی ممکنه راهی که برای یک محصول جواب داده روی محصول دیگه در زمان و مکان دیگه جواب نده.
خوشحال میشم اگر این مطلب را با دوستانتون در لینکدین و توییتر به اشتراک بگذارید تا من هم انرژی بگیرم و از این به بعد بیشتر بنویسم. یادتون نره حتما به من فیدبک بدید و اگر جایی ایده بهتری داشتید باخبرم کنید. من از طریق لینکدین و ایمیل در دسترس هستم :)
صفحه لینکدین:
https://www.linkedin.com/in/mohammad-faghih/
آدرس ایمیل:
Mohammadfaghih@gmail.com
