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

כדי לשמור על רציפות השימוש, המהנדסים של Uber השתמשו בתכונה שחזור פרטי הכניסה, כלי חיוני בתקופה שבה 40% מהאנשים בארצות הברית מחליפים את הטלפון החכם שלהם מדי שנה. אחרי הערכה של דרישות המשתמשים ויצירת אב טיפוס של הקוד, הם הציגו תמיכה בשחזור פרטי הכניסה באפליקציית Uber לנוסעים. כדי לוודא ששחזור פרטי הכניסה עוזר להסיר את החיכוך בתהליך הכניסה מחדש, צוות Uber ערך ניסוי A/B מוצלח למשך חמישה שבועות. השילוב הוביל לצמצום במספר הכניסות הידניות, וכשמבצעים הקבלה על בסיס המשתמשים העצום של Uber, ההערכה היא שייחסכו 4 מיליון כניסות ידניות בשנה.

הסרת חיכוך בכניסה באמצעות שחזור פרטי כניסה

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

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

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

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

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

שיקולים להטמעה

״ההטמעה הייתה די קלה, עם שינויים קלים בצד של Android, בעזרת קוד לדוגמה והמסמכים״, אומר תומאס. האפליקציה שלנו כבר השתמשה ב-Credential Manager למפתחות גישה, ובקצה העורפי נדרשו רק כמה שינויים קטנים. לכן, כל מה שהיינו צריכים לעשות הוא לעדכן את התלות ב-Credential Manager לגרסה האחרונה שלו כדי לקבל גישה ל-Restore Credentials API החדש. יצרנו מפתח שחזור באמצעות אותו תהליך ליצירת מפתח גישה, וכשהאפליקציה שלנו מופעלת במכשיר חדש, היא בודקת באופן יזום אם המפתח הזה קיים על ידי ניסיון לאחזר אותו בשקט. אם נמצא מפתח השחזור, המערכת משתמשת בו באופן מיידי כדי להכניס את המשתמש לחשבון באופן אוטומטי, בלי לבצע כניסה ידנית".

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

בחירת נקודת הכניסה Restore Credentials

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

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

פתרון בעיות שקשורות לצד השרת 

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

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

ניהול מחזור החיים של אישורי השחזור

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

• מניעת מפתחות יתומים: אתגר משמעותי היה הגדרת אסטרטגיה למחיקת מפתחות ציבוריים רשומים כדי למנוע מצב שבו הם הופכים ל "יתומים". לדוגמה, הסרת ההתקנה של האפליקציה מוחקת את פרטי הכניסה המקומיים, אבל מכיוון שהפעולה הזו לא מעבירה אותות אל העורף, היא משאירה מפתח לא בשימוש בשרת.
• איזון בין אורך החיים (TTL) של המפתחות: היה צורך להגדיר למפתחות 'זמן חיים' ארוך מספיק כדי לטפל במקרים חריגים. לדוגמה, אם משתמש מבצע גיבוי ושחזור, ואז מתנתק באופן ידני מהמכשיר הישן, המפתח נמחק מהמכשיר הישן. עם זאת, המפתח צריך להישאר בתוקף בשרת כדי שהמכשיר החדש יוכל להשתמש בו.
• תמיכה בכמה מכשירים: יכול להיות שלמשתמש יש כמה מכשירים (והוא יכול להתחיל גיבוי ושחזור מכל אחד מהם), ולכן היה צורך ב-Backend שתומך בכמה פרטי שחזור לכל משתמש (אחד לכל מכשיר).

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

התכונה עברה משלב העיצוב לשלב ההשקה בתהליך פיתוח ובדיקה מהיר שנמשך חודשיים. לאחר מכן, ניהלנו ניסוי A/B למשך חמישה שבועות (הזמן שנדרש לאימות התכונה עם משתמשים), והוא עבר בצורה חלקה והניב תוצאות חד-משמעיות.  

מניעת נטישת משתמשים באמצעות שחזור פרטי הכניסה

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

• ירידה של 3.4% בכניסות ידניות (סיסמה חד-פעמית ב-SMS, סיסמאות, כניסה דרך רשתות חברתיות).
• ירידה של 1.2% בהוצאות על התחברויות שנדרש בהן קוד אימות חד-פעמי (OTP) ב-SMS.
• עלייה של 0.575% בשיעור הגישה של Uber (אחוז המכשירים שהגיעו בהצלחה למסך הבית של האפליקציה).
• עלייה של 0.614% במספר המכשירים שבהם הושלמו נסיעות. 

היום, התכונה 'שחזור פרטי הכניסה' בדרך להפוך לחלק סטנדרטי באפליקציית הנוסעים של Uber, עם יותר מ-95% מהמשתמשים בקבוצת הניסוי שנרשמו. 

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

ההשפעה העצומה של שחזור פרטי הכניסה, למרות שהיא לא נראית לעין

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

"השילוב של RestoreCredentials של Google אפשר לנו לספק את החוויה החלקה של'פשוט עובד ' שהמשתמשים שלנו מצפים לה במכשיר חדש", אומר מאט מולר (Matt Mueller), מנהל מוצר ראשי (זהות ליבה) ב-Uber. "השינוי הזה הוביל לעלייה מדידה בהכנסות, ומוכיח שהפחתת החיכוך בתהליך ההתחברות היא המפתח למעורבות המשתמשים ולשימור שלהם".

רוצה לשפר את חוויית הכניסה לאפליקציה?

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

אם אתם חדשים ב-Credential Manager, תוכלו להיעזר במסמכים, בסדנת קוד ובדוגמאות הרשמיים שלנו כדי לקבל עזרה בשילוב