בניית תהליך אימות משתמשים לפלטפורמות — בלי לפגוע בהמרות

לקבלת הצעת מחיר שלא תוכלו לסרב כתבו לנו

אימות

אימות

אימות משתמשים הוא אחד השלבים החשובים ביותר בכל פלטפורמה דיגיטלית. הוא מסייע לצמצם הונאות, למנוע שימוש לרעה בחשבונות, להגן על משתמשים ולתמוך בדרישות רגולטוריות.

אבל יש לו גם מחיר אפשרי: חיכוך.

כל שלב נוסף בתהליך ההרשמה, כל מסמך שהמשתמש נדרש להעלות וכל המתנה לאישור יוצרים הזדמנות נוספת לנטישה.

זו הסיבה שהשאלה עבור פלטפורמות כיום אינה רק כיצד לבצע אימות זהות דיגיטלי, אלא כיצד לעשות זאת מבלי לפגוע באופן משמעותי בשיעור ההמרה.

במילים אחרות, אימות משתמשים אינו רק נושא של אבטחה או Compliance. הוא גם חלק מתכנון ה־Funnel.

פלטפורמות שמבינות זאת אינן שואלות רק "איזה מידע אנחנו צריכים מהמשתמש?", אלא גם "באיזה שלב אנחנו באמת צריכים אותו?".

למה אימות הוא בדרך כלל הנקודה שבה פלטפורמות מאבדות משתמשים

תהליך הרשמה יכול להיות מהיר מאוד: כתובת אימייל, סיסמה ולעיתים מספר טלפון.

אבל ברגע שהמשתמש מתבקש להוכיח מי הוא, התהליך הופך מורכב יותר.

הוא עשוי להידרש לצלם מסמך מזהה, לבצע בדיקת פנים, להמתין לאישור או לעבור בין מספר מסכים. כל אחד מהשלבים האלה מגדיל את רמת החיכוך.

הבעיה אינה תיאורטית.

בסקר רב־מדינתי באירופה של Signicat נמצא שכ־68% מהצרכנים נטשו בשלב כלשהו בקשה לשירות פיננסי במהלך תהליך ה־onboarding. לשם השוואה, בסקר דומה משנת 2016 שיעור הנטישה עמד על כ־40%.

גם נתונים שצוטטו על ידי UserTesting מצביעים על כך ששיעורי נטישה בתהליכי onboarding דיגיטליים בבנקאות יכולים להגיע לכ־60%.

ובמקרים שבהם המשתמש נדרש להעלות מסמכים, שיעורי הנשירה יכולים להיות משמעותיים אף יותר.

המשמעות אינה שפלטפורמות צריכות לוותר על אימות. להפך.

המשמעות היא שצריך להתייחס לאימות כחלק מחוויית המשתמש וכחלק ממנגנון ההמרה.

פתרון הרשמה מאובטח טוב אינו רק כזה שעוצר משתמשים בעייתיים. הוא גם כזה שמאפשר למשתמשים לגיטימיים להתקדם במהירות ובבהירות.

אימות מדורג לפי סיכון: לא כל משתמש צריך את אותן בדיקות

אחת הטעויות הנפוצות היא להפעיל את אותו תהליך אימות על כל המשתמשים.

משתמש שרק פותח חשבון ומעוניין לעיין בתוכן אינו בהכרח מציג את אותה רמת סיכון כמו משתמש שמבצע פעולה כספית, מושך כסף או מקבל גישה לתכונה רגישה.

לכן אחת הגישות היעילות ביותר היא Risk-Tiered Verification — אימות מדורג לפי רמת סיכון.

במקום לבצע את הבדיקה הכבדה ביותר כבר בתחילת הדרך, ניתן להתאים את עומק האימות לפעולה שהמשתמש מבקש לבצע.

לדוגמה:

משתמש שנרשם לשירות יכול לעבור בדיקות בסיסיות בלבד.

כאשר הוא מגיע לפעולה בעלת סיכון גבוה יותר, ניתן לבקש אימות נוסף.

ואם ההתנהגות או הנתונים מצביעים על סיכון חריג, המערכת יכולה לדרוש בדיקה מעמיקה יותר.

כך ניתן לצמצם את החיכוך עבור רוב המשתמשים, מבלי לוותר על רמת האבטחה במקום שבו היא באמת נדרשת.

עבור כל פלטפורמת אימות משתמשים, האתגר הוא למצוא את נקודת האיזון בין שלושה משתנים: סיכון, חיכוך והמרה.

ככל שהתהליך הופך קשיח יותר, ייתכן שהסיכון יורד — אבל שיעור המשתמשים שמשלימים אותו עלול לרדת גם כן.

לכן גישה בטוחה ומדורגת לאימות משתמשים שווה לבנות בכוונה תחילה, במקום להוסיף בדיקות באופן אוטומטי לכל משתמש ובכל מצב.

תכנון לקראת הפרעות — כי משתמשים יופרעו באמצע

תהליכי אימות אינם מתבצעים תמיד בתנאים אידיאליים.

משתמש יכול להתחיל את התהליך בטלפון בזמן שהוא נוסע, לגלות שמסמך הזהות שלו נמצא בחדר אחר, לקבל שיחת טלפון באמצע או פשוט להחליט לחזור לתהליך מאוחר יותר.

אם המערכת מחייבת אותו להתחיל מחדש בכל פעם, החיכוך גדל בצורה משמעותית.

לכן שמירת התקדמות היא מרכיב חשוב בתכנון נכון של onboarding.

פלטפורמה יכולה, לדוגמה, לשמור את השלבים שכבר הושלמו ולאפשר למשתמש לחזור בדיוק לנקודה שבה עצר.

גם הודעות ברורות יכולות להפחית נטישה.

במקום להציג הודעה כללית כמו "Verification failed", כדאי להסביר מה חסר ומה המשתמש צריך לעשות כדי להתקדם.

לדוגמה:

"התמונה אינה ברורה מספיק. נסה לצלם שוב במקום מואר."

או:

"סיימת שניים מתוך שלושה שלבים. ניתן להמשיך מאוחר יותר."

לכאורה מדובר בפרטים קטנים, אך בפועל הם משפיעים ישירות על שיעור השלמת התהליך.

איפה אוטומציה עוזרת, ואיפה היא רק מוסיפה חיכוך

אוטומציה יכולה להפוך אימות משתמשים למהיר ויעיל יותר, אך רק כאשר משתמשים בה במקום הנכון.

לדוגמה, מערכות יכולות לבצע בדיקות אוטומטיות של מסמכים, לזהות מידע חסר, להצליב נתונים או להפעיל בדיקות נוספות רק כאשר מתגלה חריגה.

היתרון הגדול הוא שלא כל פעולה מחייבת בדיקה ידנית.

עם זאת, אוטומציה אינה צריכה להיות מטרה בפני עצמה.

מערכת שמפעילה מספר גדול של בדיקות על כל משתמש רק משום שהן זמינות עלולה ליצור בדיוק את הבעיה שהיא אמורה לפתור.

גישה יעילה יותר היא להפריד בין בקשת האימות לבין תהליך עיבוד האימות.

המשתמש מתבקש לספק רק את המידע הנדרש, בעוד שהמערכת יכולה לנתב את הבקשה, לעבד אותה ולהחזיר תוצאה באופן עצמאי.

בפועל, פלטפורמות שמפרידות בין בקשת האימות לבין הבדיקה עצמה נוטות להמיר טוב יותר, משום שהן יכולות לבנות תהליך מדורג ולאפשר למנגנוני ה־backend לבצע את העבודה מבלי להעמיס שלבים מיותרים על המשתמש.

גישה כזו גם מאפשרת לצוותי מוצר לבצע שינויים בתהליך האימות מבלי לבנות מחדש את כל חוויית ההרשמה.

למדוד את הדבר הנכון: שיעור השלמה, לא רק שיעור הונאות

אחד המדדים הברורים ביותר למערכת אימות הוא כמה הונאות היא מצליחה לעצור.

אבל זה לא צריך להיות המדד היחיד.

נניח שפלטפורמה מחמירה מאוד את דרישות האימות ומצליחה להפחית הונאות ב־20%.

אם באותו זמן שיעור השלמת ההרשמה יורד ב־35%, ייתכן שהפתרון יצר בעיה עסקית גדולה יותר מזו שהוא פתר.

לכן יש למדוד לפחות שני צדדים של המשוואה:

שיעור ההונאות והשימוש לרעה בפלטפורמה, לצד שיעור המשתמשים הלגיטימיים שמצליחים להשלים את תהליך האימות.

מומלץ גם למדוד באיזה שלב המשתמשים נוטשים.

לדוגמה, ייתכן שהבעיה אינה בתהליך האימות כולו אלא בשלב מסוים בלבד — העלאת מסמך, צילום פנים או זמן ההמתנה לתוצאה.

כאשר יודעים היכן מתרחשת הנשירה, ניתן לשפר את השלב הספציפי במקום לפשט את כל מנגנון האבטחה.

בסופו של דבר, אימות זהות דיגיטלי יעיל אינו חייב להיות תהליך ארוך או מכביד.

הוא צריך להיות פרופורציונלי לרמת הסיכון, ברור למשתמש ומובנה כך שרק מי שבאמת צריך לעבור בדיקות נוספות יתבקש לבצע אותן.

פלטפורמות שמתייחסות לאימות כחלק מתכנון ה־Funnel ולא רק כאל Checklist של Compliance יכולות לבנות תהליך ששומר על הביטחון מבלי להפוך את האבטחה למחסום בפני משתמשים לגיטימיים.

וזה אולי העיקרון החשוב ביותר: מערכת אימות טובה אינה זו שמבקשת את כמות המידע הגדולה ביותר. היא זו שיודעת לבקש את המידע הנכון, מהמשתמש הנכון, ברגע הנכון.

לקבלת הצעת מחיר שלא תוכלו לסרב כתבו לנו