هر بروکری بالاخره برای اپ موبایل اختصاصی خودش درخواست میدهد. منطقش هم درست است: مشتریها با گوشی زندگی میکنند، اپ فروشنده پلتفرم لوگوی شخص دیگری را دارد، و یک آیکون برندشده روی صفحه اصلی تریدر ارزش دارد. بعد پروژه به تیم بررسی Apple میرسد و زمانبندی دو برابر میشود.
اینها در عمل گزینهها هستند، اپ باید چه کارهایی انجام دهد، و کجاها درخواستها رد میشوند.
سه راه برای اینکه یک اپ ترید به نام خودتان داشته باشید
اولین گزینه این است که اصلاً اپی نداشته باشید. مشتریهای شما اپ فروشنده پلتفرم را دانلود میکنند و سرور شما را انتخاب میکنند. این کار هیچ هزینهای ندارد، ریسک استور هم ندارد، و در عوض هیچ برندسازیای هم نصیب شما نمیکند. برای یک بروکری که تازه شروع کرده و حجم مشتری کمی دارد، این اغلب برای سال اول انتخاب درستی است.
دومین گزینه یک اپ موبایل وایتلیبل از فروشنده پلتفرم شماست که با نام شرکت خودتان منتشر میشود. چند ارائهدهنده پلتفرم این امکان را دارند. شما نام و رنگهای خودتان را روی یک ترمینال ترید امتحانپسداده میگذارید، و در عوض مسئولیتهای لیست شدن، فرایند بررسی، و چرخه آپدیت را هم به ارث میبرید. هزینه توسعه پایین است و تعهدات جاری واقعیاند.
سومین گزینه یک اپ سفارشی است که روی CRM و APIهای ترید شما ساخته میشود. این تنها مسیری است که در آن اپ میتواند همه چیزهایی را که یک مشتری لازم دارد، در یک جا انجام دهد: ثبتنام، آپلود مدارک، شارژ حساب، باز کردن یک حساب ترید جدید، و دیدن موجودیها در کنار نمودار. این مسیر همچنین گرانترین گزینه برای ساخت است و تنها گزینهای است که در آن شما مالک هر رد شدنی هستید.
درباره گزینه سوم باید صریح بود: برای بیشتر بروکرها، ترمینال ترید عامل تمایز نیست. تریدرهایی که به چارت اهمیت میدهند، از قبل MetaTrader یا MT4 یا MT5 یا cTrader را نصب کردهاند و قرار نیست به نسخه شما از یک کندلاستیک مهاجرت کنند. بخشی از تجربه که واقعاً مال شماست، ناحیه حساب است؛ برای همین خیلی از اپهای سفارشی، آنبوردینگ، واریز و برداشت، و مدیریت حساب را انجام میدهند و صفحه واقعی ترید را به اپ پلتفرم میسپارند.
اپ باید فراتر از نمایش نمودار چه کار کند
گسترش بیرویه scope این پروژهها را از بین میبرد، پس از همان اول مشخص کنید کدامیک از اینها در نسخه اول هستند:
- ثبتنام و ورود، ترجیحاً بهصورت مشترک با ناحیه وب مشتری تا کاربر مجبور نباشد دو هویت جداگانه را نگه دارد.
- آپلود مدارک با دوربین گوشی، که مهمترین دلیل برتری آنبوردینگ موبایل نسبت به دسکتاپ از نظر نرخ تکمیل است.
- واریز و برداشت، شامل هر روش محلیای که واقعاً در مناطق هدف شما استفاده میشود.
- فهرست حسابها، موجودیها، لوریج، و اطلاعات ورود به پلتفرم.
- نوتیفیکیشنهای push برای سطوح مارجین، تأیید مدارک، و وضعیت پرداخت.
این فهرست عملاً یکtrader’s roomدر قالب اپ است، و دقیقاً هم باید همین باشد. اگر همان دادهها از قبل پورتال وب شما را تغذیه میکنند، نسخه موبایل یک پروژه رابط کاربری است نه یک پروژه پلتفرمی. CRM API همان چیزی است که توسعهدهنده موبایل باید بر اساس آن کار کند، و ارزش دارد قبل از اینکه کسی حتی یک خط Swift بنویسد، بررسی شود که آیا همه موارد این فهرست را پوشش میدهد یا نه. Prop Firmها فهرست مشابهی با محتوای متفاوت دارند، چون صفحه معادل آن در آنجا challenge dashboard است که پیشرفت قوانین، drawdown، و وضعیت payout را نشان میدهد.
Push در این میان شایسته توضیح جداگانه است. در بسیاری از موارد، این خود دلیل ساخت اپ است، چون تنها کانالی است که بدون رقابت با inbox به تریدر میرسد. هشدارهای مارجین، تأیید احراز هویت، و پرداختهای ناموفق همان نوتیفیکیشنهایی هستند که مشتریها واقعاً میخواهند، و باید از همانnotification systemای ارسال شوند که CRM شما از قبل استفاده میکند، نه از یک ابزار جداگانه که هیچکس نگهداریاش نمیکند.
عبور از بررسی Apple
چهار دستورالعمل، بیشتر رد شدنها در این دسته را توضیح میدهند.
- Guideline 3.2.1(viii) اولین موردی است که باید بخوانید. متن Apple: «اپهایی که برای معاملات مالی، سرمایهگذاری، یا مدیریت پول استفاده میشوند باید توسط مؤسسه مالی ارائهدهنده این خدمات ارسال شوند و باید مجوزها و permissions لازم را در مکانهایی که آنها را در دسترس قرار میدهید داشته باشند.» در عمل یعنی حساب توسعهدهنده باید متعلق به نهاد دارای مجوز شما باشد، نام روی حساب باید با نام روی مجوز مطابقت داشته باشد، و محدوده دسترسی کشوری شما باید همان جایی باشد که واقعاً مجاز به فعالیت هستید. ارسال اپ توسط یک آژانس توسعه به نمایندگی از شما، دعوت به رد شدن است.
- Guideline 4.3(b) به اپهایی مربوط میشود که «از آنچه از قبل بهطور گسترده در دسترس است قابلتشخیص نیستند». نسخههای برندشده از همان ترمینال ترید بهطور ناراحتکنندهای به این خط نزدیک میشوند، و به همین دلیل کلونهای per broker از یک پلتفرم شناختهشده سالهاست مسیر دشواری بودهاند. دفاع شما این است که اپ شما کارهایی انجام میدهد که نسخه عمومی انجام نمیدهد، و این هم دلیل دیگری است برای ساختن ناحیه حساب بهجای یک صفحه نمودار دیگر.
- Guideline 4.2 اپهای کممحتوا را گیر میاندازد. اگر ارسال شما فقط یک web view wrapper دور پورتال مشتریتان باشد و هیچ بخش native نداشته باشد، انتظار داشته باشید از شما بپرسند اپ چه چیزی بیشتر از سایت موبایل اضافه میکند. ثبت مدارک با دوربین، ورود بیومتریک، و نوتیفیکیشنهای push پاسخهای معمول هستند، و باید قبل از ارسال وجود داشته باشند، نه اینکه فقط در توضیحات بررسی وعده داده شوند.
- Guideline 5.1.1 به یک privacy policy نیاز دارد که مشخص کند چه چیزهایی جمعآوری میکنید، چگونه از آن استفاده میکنید، آن را با چه کسانی به اشتراک میگذارید، و کاربر چگونه دادههایش را حذف میکند. Apple همچنین انتظار دارد حذف حساب کاربری داخل اپ در دسترس باشد. برای یک بروکر رگولهشده که الزامات نگهداری سوابق دارد، این نیازمند پاسخ واقعی است؛ معمولاً حذف حساب اپ بهعلاوه یک توضیح روشن درباره اینکه چه دادههایی باید بهموجب قانون نگهداری شوند و تا چه زمانی.
دو کار عملی که بررسی را سریعتر میکنند: به بازبین، credentials دمو روی حسابی با موجودی و پوزیشنهای باز بدهید، و یک screen recording کوتاه از جریان کار ضمیمه کنید. بازبینهایی که نتوانند از gate KYC شما عبور کنند، بهجای تحقیق، رد خواهند کرد.
سؤال خرید درونبرنامهای برای Prop Firmها
Prop Firmها یک مشکل اضافه دارند. Guideline 3.1.1 ایجاب میکند برای باز کردن featureها یا contentها از in-app purchase استفاده شود، و صراحتاً استفاده از مکانیزم خودتان را برای این کار رد میکند. اینکه هزینه challenge بهعنوان محتوای دیجیتال حساب میشود یا نه، چیزی است که باید قبل از ساختن flow جوابش را بدانید، نه بعد از آن؛ چون تفاوت کمیسیون بهاندازهای زیاد است که اقتصاد واحد شما را عوض میکند.
الگوی امنی که بیشتر اپراتورها استفاده میکنند این است که خرید challenge را روی وب نگه دارند و اپ فقط حسابهایی را که تریدر از قبل دارد نمایش دهد و مدیریت کند. قواعد Apple درباره لینک دادن به خریدهای خارجی در چند سال اخیر چندین بار تغییر کرده و بسته به منطقه هم فرق میکند، پس متن فعلی guideline را بخوانید، نه یک پست وبلاگی دو سال پیش را؛ این مورد هم شامل همین نکته میشود.
Google Play
Play معمولاً سریعتر است، اما کاغذبازی خودش را دارد. هر اپی با ویژگیهای مالی باید Financial features declaration را در Play Console تکمیل کند، و Financial Services policy هم الزامات اضافیای دارد که بسته به کشور فرق میکند، از جمله در برخی بازارها مدارک مجوز. اولین بار این declaration را صادقانه پر کنید، چون اصلاحات بعد از رد شدن کندتر از بررسی اولیه است.
همچنین به یک بخش تکمیلشدهٔ Data safety نیاز خواهید داشت که با سیاست حریم خصوصی شما مطابقت داشته باشد، و باید برای الزامات سطح API هدف Google برنامهریزی کنید، که هر سال، چه محصول شما تغییر کرده باشد و چه نه، یک بهروزرسانی فنی را الزامی میکند.
یک نکتهٔ دیگر که پیش از نوشتن متن فروشگاه باید بررسی کنید: قوانین تبلیغات برای محصولات مالی پیچیده و سفتهبازانه، نحوهٔ توصیف معاملات را هم در فروشگاهها و هم در تبلیغات محدود میکند. اسکرینشاتهایی که سود را القا میکنند، راهی مطمئن برای حذف شدن هستند.
بودجه را برای سال دوم در نظر بگیرید، نه برای زمان عرضه
هزینهٔ ساخت، رقم کوچک است. هر سال نسخههای جدید سیستمعامل، یک افزایش اجباری سطح API در Android، بهروزرسانیهای SDK از سوی فروشندهٔ پلتفرم شما، و یک چرخهٔ بررسی برای هرکدام را به همراه دارد. اپی که بودجهٔ نگهداری نداشته باشد، ظرف حدود هجده ماه از کار میافتد و بیش از آنکه نداشتن آن آسیب بزند، به برند شما آسیب میزند.
اگر خط نگهداری تأمین مالی نشود، پاسخ صادقانه بهجای اپ، یک ناحیهٔ کاربری واکنشگرا است. یکپرتال وب موبایلی بهخوبی ساختهشده، آنبوردینگ، تأمین موجودی، و مدیریت حساب را روی گوشی انجام میدهد، در بیشتر دستگاهها از web push پشتیبانی میکند، نیازی به تأیید فروشگاه ندارد، و میتواند روزی که تصمیم میگیرید یک بهروزرسانی منتشر کنید، آن را عرضه کند.
چگونه تصمیم بگیریم
ببینید چه سهمی از ترافیک ناحیهٔ کاربری شما همین حالا موبایلی است و آن نشستها چه کارهایی انجام میدهند. اگر بیشترِ آن برای بررسی موجودی و پیگیری واریزهاست، اپ کمک میکند و دامنهٔ کار روشن است. اگر تقاضا از سمت تیم فروش میآید که چیزی برای نشان دادن به مشتریان بالقوه میخواهند، یک پرتال وب با برند شما همان کار را با کسری از هزینه انجام میدهد.
وقتی ساخت را آغاز میکنید، ابتدا بخش حساب را منتشر کنید و اگر اعداد توجیهش را داشتند، بعداً صفحهٔ معامله را اضافه کنید. مشتریان بهندرت برای اپ درخواست میکنند چون نمودارهای بهتر میخواهند. آنها درخواست میکنند چون میخواهند پول و مدارکشان با یک لمس در دسترس باشد، که با الگویی که هنگام بررسیآنچه معاملهگران واقعاً از یک بروکر میخواهند دیدیم همخوانی دارد.
درخواست مشاوره دربارهٔ تجربهٔ کاربری موبایل مشتریان
برای انتخاب استراتژی موبایلی مناسب برای بروکریج یا Prop Firm خود، از راهنمایی تخصصی بهرهمند شوید. ما به شما کمک میکنیم ارزیابی کنید که آیا یک اپ بومی، یک Traders Room با برند اختصاصی، یا یک پرتال وب واکنشگرا، با کسبوکار، انتظارات مشتریان، و الزامات عملیاتی شما بهتر سازگار است.
با هم، سفر فعلی مشتریان شما را بررسی میکنیم و یک استراتژی موبایلی ترسیم میکنیم که برای مقیاسپذیری و نگهداری بلندمدت طراحی شده باشد.
