כל ברוקר בסופו של דבר מבקש אפליקציית מובייל משלו. ההיגיון מוצק: הלקוחות חיים על הטלפונים שלהם, האפליקציה של ספק הפלטפורמה נושאת לוגו של מישהו אחר, ואייקון ממותג על מסך הבית של טריידר שווה משהו. ואז הפרויקט פוגש את צוות הבדיקה של Apple והלוח הזמנים מוכפל.
הנה מהן למעשה האפשרויות, מה האפליקציה צריכה לעשות, ואיפה בקשות נדחות.
שלוש דרכים לשים אפליקציית מסחר על שמכם
האפשרות הראשונה היא לא להחזיק אחת. הלקוחות שלכם מורידים את האפליקציה של ספק הפלטפורמה ובוחרים את השרת שלכם. זה לא עולה כלום, לא טומן בחובו סיכון מול החנויות, ולא מעניק לכם מיתוג בכלל. עבור חברת ברוקראז' חדשה עם תיק קטן, זו לעיתים קרובות הבחירה הנכונה לשנה הראשונה.
האפשרות השנייה היא אפליקציית מובייל White Label מספק הפלטפורמה שלכם, שמפורסמת תחת החברה שלכם. כמה מספקי הפלטפורמות מציעים זאת. אתם מקבלים את השם והצבעים שלכם על גבי טרמינל מסחר מוכח, ומקבלים על עצמכם את הרישום, את תהליך הבדיקה ואת מחזור העדכונים. עלות הפיתוח נמוכה, והמחויבויות השוטפות ממשיות.
האפשרות השלישית היא אפליקציה מותאמת שנבנית על גבי ה-CRM וה-API-ים למסחר שלכם. זהו הנתיב היחיד שבו האפליקציה יכולה לעשות הכול במקום אחד: הרשמה, העלאת מסמכים, מימון החשבון, פתיחת חשבון מסחר חדש, וצפייה ביתרות לצד הגרף. זה גם הנתיב היקר ביותר לבנייה והיחיד שבו כל דחייה היא באחריותכם.
שווה לומר זאת בצורה ברורה לגבי האפשרות השלישית: עבור רוב הברוקרים, טרמינל המסחר אינו גורם המבדל. טריידרים שאכפת להם מגרפים כבר מותקנת אצלם MetaTrader או cTrader, והם לא הולכים לעבור לגרסה שלכם של נר יפני. החלק של החוויה שבאמת שייך לכם הוא אזור החשבון, ולכן אפליקציות מותאמות רבות מטפלות בקליטה, במימון ובניהול החשבון, ומשאירות את מסך המסחר עצמו לאפליקציית הפלטפורמה.
מה האפליקציה חייבת לעשות מעבר להצגת גרפים
Scope creep הורג את הפרויקטים האלה, אז החליטו מוקדם אילו מהדברים הבאים יהיו בגרסה הראשונה:
- הרשמה והתחברות, רצוי משותפות עם אזור הלקוחות באתר, כך שללקוח לא יהיו שתי זהויות שונות לתחזוקה.
- העלאת מסמכים באמצעות מצלמת הטלפון, שהיא הסיבה הגדולה ביותר לכך שקבלת לקוחות במובייל עולה על זו שבדסקטופ בשיעור ההשלמה.
- הפקדות ומשיכות, כולל כל שיטות התשלום המקומיות שבאמת משמשות את האזורים שלכם.
- רשימת חשבונות, יתרות, מינוף ופרטי ההתחברות לפלטפורמה.
- התראות Push עבור רמות מרג'ין, אישורי מסמכים ומצב תשלום.
הרשימה הזו מתארתחדר טריידרבאפליקציה, וזה בדיוק מה שהיא צריכה להיות. אם אותם נתונים כבר מניעים את פורטל האינטרנט שלכם, הפיתוח למובייל הוא פרויקט ממשק ולא פרויקט פלטפורמה. ה-CRM APIהוא מה שמפתח מובייל בונה מולו, וכדאי לבדוק שהוא חושף הכול מהרשימה לפני שמישהו כותב שורת Swift אחת. ל-Prop firms יש רשימה דומה עם תוכן שונה, שכן המסך המקביל הוא ה-דשבורד של ה-challengeעם התקדמות לפי חוקים, drawdown ומצב payout.
Push ראוי להערה נפרדת. במקרים רבים זו הסיבה לבנות אפליקציה בכלל, כי זהו הערוץ היחיד שמגיע לטריידר בלי להתחרות בתיבת הדואר הנכנס. קריאות מרג'ין, אישורי אימות והפקדות שנכשלו הן ההתראות שהלקוחות באמת רוצים, והן צריכות להישלח מאותהמערכת התראותש-CRM שלכם כבר משתמש בה, ולא מכלי נפרד שאף אחד לא מתחזק.
מעבר לבדיקת Apple
ארבעה סעיפים אחראים לרוב הדחיות בקטגוריה הזו.
- הנחיה 3.2.1(viii) היא הראשונה שכדאי לקרוא. הנוסח של Apple: "Apps used for financial trading, investing, or money management should be submitted by the financial institution performing such services and must have necessary licensing and permissions in the locations where you make them available." בפועל זה אומר שחשבון המפתח שייך לישות המורשית שלכם, שהשם על החשבון תואם לשם ברישיון, ושזמינות המדינות שלכם תואמת למקומות שבהם אתם באמת מורשים לפעול. אפליקציה שמוגשת על ידי סוכנות פיתוח בשמכם מזמינה דחייה.
- הנחיה 4.3(b) עוסקת באפליקציות שהן "indistinguishable from what's already widely available." גרסאות ממותגות של אותו טרמינל מסחר יושבות לא בנוחות קרוב לקו הזה, ולכן שכפולים לכל ברוקר של פלטפורמה מוכרת היו במשך שנים נתיב קשה. ההגנה היא שהאפליקציה שלכם עושה דברים שהגרסה הגנרית לא עושה, וזו עוד סיבה לבנות את אזור החשבון ולא עוד מסך גרפים.
- הנחיה 4.2 תופסת אפליקציות דלות. אם ההגשה שלכם היא מעטפת web view לפורטל הלקוחות שלכם בלי שום רכיב native, צפו לשאלה מה האפליקציה מוסיפה על פני האתר המובייל. לכידת מסמכים באמצעות המצלמה, התחברות ביומטרית והתראות Push הן בדרך כלל התשובות, והן צריכות להיות קיימות לפני ההגשה ולא רק להיות מובטחות בהערות הבדיקה.
- הנחיה 5.1.1 דורשת מדיניות פרטיות שמציינת מה אתם אוספים, איך אתם משתמשים בזה, עם מי אתם משתפים את זה, ואיך משתמש מוחק את הנתונים שלו. Apple גם מצפה לכך שמחיקת החשבון תהיה זמינה בתוך האפליקציה. עבור ברוקר מפוקח עם חובות שמירת רישומים, זה צריך לקבל תשובה אמיתית, בדרך כלל מחיקת חשבון האפליקציה בתוספת הצהרה ברורה מה חייב להישמר על פי חוק ולכמה זמן.
שני דברים מעשיים שמקצרים את הבדיקה: תנו לבודק פרטי התחברות לדמו עובדים על חשבון עם כספים ופוזיציות פתוחות, וצרפו הקלטת מסך קצרה של ה-flow. בודקים שלא מצליחים לעבור את שער ה-KYC שלכם ידחו במקום לחקור.
שאלת ה-In-App Purchase עבור Prop firms
ל-Prop firms יש בעיה נוספת. הנחיה 3.1.1 דורשת In-App Purchase עבור פתיחת תכונות או תוכן, והיא שוללת במפורש שימוש במנגנון שלכם לכך. האם עמלת challenge נחשבת לתוכן דיגיטלי היא שאלה שתרצו לקבל עליה תשובה לפני שאתם בונים את ה-flow, לא אחריו, כי ההבדל בעמלות מספיק גדול כדי לשנות את economics היחידתיים שלכם.
התבנית הבטוחה שרוב המפעילים משתמשים בה היא להשאיר את רכישות ה-challenge באינטרנט, ולאפשר לאפליקציה להציג ולנהל חשבונות שהטריידר כבר מחזיק. כללי Apple לגבי קישור החוצה לרכישות חיצוניות השתנו כמה פעמים בשנים האחרונות ותלויים באזור, אז קראו את טקסט ההנחיה הנוכחי ולא פוסט בבלוג מלפני שנתיים, גם לא זה.
Google Play
Play בדרך כלל מהיר יותר, אבל יש לו ניירת משלו. כל אפליקציה עם תכונות פיננסיות חייבת למלא את הצהרת Financial features ב-Play Console, ומדיניות Financial Services מטילה דרישות נוספות שמשתנות לפי מדינה, כולל תיעוד רישוי בשווקים מסוימים. מלאו את ההצהרה בכנות כבר בפעם הראשונה, כי תיקונים אחרי דחייה איטיים יותר מהבדיקה המקורית.
תצטרכו גם למלא סעיף Data safety שהושלם, והוא חייב להתאים למדיניות הפרטיות שלכם, וכדאי לכם לתכנן גם את דרישות רמת ה-API היעד של Google, שמחייבות עדכון טכני מדי שנה בין אם המוצר שלכם השתנה ובין אם לאו.
עוד דבר שכדאי לבדוק לפני שכותבים את טקסטי החנות: כללי הפרסום עבור מוצרים פיננסיים ספקולטיביים מורכבים מגבילים את האופן שבו אפשר לתאר מסחר בשתי החנויות וגם במודעות. צילומי מסך שמרמזים על רווח הם דרך בטוחה להוביל להסרה.
תקצבו לשנה השנייה, לא להשקה
הצעת המחיר לפיתוח היא המספר הקטן. בכל שנה מגיעות גרסאות חדשות של מערכת ההפעלה, העלאה מחייבת של רמת ה-API ב-Android, עדכוני SDK מספק הפלטפורמה שלכם, ומחזור בדיקה לכל אחד מהם. אפליקציה שלא מקבלת תקציב תחזוקה מפסיקה לעבוד בתוך כשמונה עשר חודשים, והיא גורמת יותר נזק למותג מאשר היעדר אפליקציה.
אם אין מימון לשורת התחזוקה, התשובה הכנה היא אזור לקוחות רספונסיבי במקום אפליקציה. מערכת בנויה היטב פורטל אינטרנט למובייל מטפל בהרשמה, מימון וניהול חשבון בטלפון, תומך ב-web push ברוב המכשירים, אינו דורש אישור מחנות, וניתן להשיק בו עדכון ביום שבו מחליטים לבצע אותו.
איך להחליט
בדקו איזה חלק מתעבורת אזור הלקוחות שלכם כבר מגיע ממובייל ומה אותם סשנים עושים. אם רוב הפעילות היא בדיקת יתרות ומעקב אחרי הפקדות, אפליקציה תועיל וההיקף ברור. אם הביקוש מגיע מצוות מכירות שרוצה משהו להציג ללקוחות פוטנציאליים, פורטל אינטרנט ממותג יעשה את אותה עבודה בעלות של חלק קטן מהמחיר.
כשבונים, השיקו קודם את אזור החשבון והוסיפו את מסך המסחר מאוחר יותר אם המספרים מצדיקים זאת. לקוחות כמעט אף פעם לא מבקשים אפליקציה כי הם רוצים גרפים טובים יותר. הם מבקשים כי הם רוצים שהכסף והמסמכים שלהם יהיו במרחק לחיצה אחת, וזה מתאים לדפוס שראינו כשבחנו מה סוחרים באמת רוצים מברוקר.
בקשו ייעוץ לגבי חוויית הלקוח במובייל שלכם
קבלו הכוונה מקצועית בבחירת אסטרטגיית המובייל הנכונה עבור חברת הברוקראז' או ה-Prop Firm שלכם. נעזור לכם להעריך האם אפליקציה נייטיבית, Trader Room ממותג, או פורטל ווב רספונסיבי מתאימים ביותר לעסק שלכם, לציפיות הלקוחות ולדרישות התפעוליות.
ביחד נבחן את מסע הלקוח הנוכחי שלכם ונשרטט אסטרטגיית מובייל שנועדה ליכולת הרחבה ותחזוקה ארוכות טווח.
