אימות דרך Одноклассники באפליקציית מובייל
כניסה דרך רשת חברתית באפליקציית מובייל נשברת לעיתים נדירות בבקשה עצמה — היא נשברת בחזרה. האדם יוצא לאשר גישה באפליקציית הרשת החברתית או בדפדפן, וחוזר למצב מסך שונה מזה שממנו יצא. ייתכן שהתהליך נפלט לרקע: המסך נוצר מחדש מאפס, ואין פשוט היכן ליישם את תוצאת האימות שהתקבלה.
מכאן הפגם השכיח השני — איפוס הסשן בחזרה. אם אישור הגישה נמצא רק בזיכרון המסך הנוכחי ולא באחסון מאובטח של המכשיר, לאחר המזעור הוא נעלם, והאפליקציה מציגה שוב את טופס הכניסה. עבור המשתמש זה נראה כמו כפתור לא עובד: הוא אישר את הגישה, אבל הכניסה לא בוצעה.
בהמשך נכנס חשבון ההפסדים — הרשמה נטושה. שאלון מלא, מסלול שנבחר, עגלה שנאספה — הכול מתאפס יחד עם הסשן, והאדם עוזב באמצע בלי להשלים את העניין. ככל שיש יותר שלבים אחרי הכניסה, כך יקרה יותר כל חזרה מיותרת: אנשים לא מתווכחים עם האפליקציה, הם פשוט סוגרים אותה.
אנחנו מפרקים כיצד זה נסגר בפועל: היכן לאחסן מצב בין מעברים, מה לעשות בהפעלה חוזרת, כיצד להחזיר את האדם בדיוק לשלב שבו הוא עצר. להלן — כיצד בנויה כניסה לאפליקציית מובייל דרך רשת חברתית כך שהיא תוביל עד הסוף, ולא תאבד משתמשים באמצע הדרך.
מה נותנת כניסה דרך רשת חברתית: המרה ופחות נטישות
שיעור ההרשמות שהושלמו
בכניסה נייטיבית דרך Одноклассники המשתמש מאשר גישה באפליקציית הרשת החברתית שכבר מותקנת, ולא ממלא טופס עם טלפון, דואר וקוד.
כל שלב של הזנה ידנית הוא נקודה שבה חלק מהאנשים נושרים; כאן יש שלב אחד בלבד, ולכן שיעור ההרשמות שהושלמו עולה, ופרופילים שלא הושלמו מפסיקים להצטבר במסד הנתונים.
זמן הכניסה לאפליקציה
האישור חוזר לאפליקציה ישירות, בלי העברה לדפדפן ובלי הזנה חוזרת של סיסמה. כניסה חוזרת במסגרת סשן פעיל — נגיעה אחת, וזמן הכניסה לאפליקציה נמדד בשניות במקום דקה וחצי על טופס. המשתמש מגיע למוצר ברגע שבו הוא רצה לעשות משהו.
פחות פניות לתמיכה בנושא כניסה
החלק הארי של טיקטים בקו הראשון — "הקוד לא מגיע", "אני לא זוכר סיסמה", "המכתב עף לספאם". כשהרשת החברתית מאשרת את הזהות, התרחישים האלה פשוט לא קיימים בתוך האפליקציה: אין קוד שלא הגיע, ואין סיסמה שנשכחה. הפניות לתמיכה בנושא כניסה יורדות יחד עם מספר ניסיונות הכניסה החוזרים.
סוג הנטישות שנסגר על ידי המכניקה
בעבר חלק מהאנשים הגיעו עד לאישור ולא חזרו: המכתב לא נפתח, הקוד לא הוזן, הסשן פג. נטישה לאחר אישור היא ההפסד היקר ביותר, משום שהמשתמש כבר היה מוכן להירשם. באישור נייטיבי החזרה מתרחשת אוטומטית, וסוג הנטישות הזה מוסר ברמת המכניקה, ולא ברמת התזכורות.
דרכי כניסה: השוואת אפשרויות חיבור
הבחירה בדרך כניסה קובעת היכן חי הסשן, מה רואה המשתמש בעת נטישה וכמה קוד יהיה צורך לכתוב מחדש בעת החלפת פלטפורמה. עבור אימות דרך Одноклассники האפשרויות מתקיימות זו לצד זו באפליקציה אחת, אבל עיקרית עושים רק אחת: ערבוב מזהים יוצר כפילויות של חשבונות, שאותן מאחים אחר כך ידנית.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| כניסה מובנית | התרחיש העיקרי באפליקציה נייטיבית: מסך האישור נפתח מעל, נתוני הסשן חוזרים ישירות לאפליקציה | דורשת פרסום בחנויות והגדרות נפרדות לכל פלטפורמה; בעת שלילת הרשאות יש לבדוק מחדש את הגישה |
| כניסה דרך עמוד אינטרנט | גרסת האינטרנט של השירות, בניות בדיקה, כניסה מהמחשב | החזרה לאפליקציה תלויה במעבר בקישור; חלק מהמשתמשים הולכים לאיבוד כשחלונות צד שלישי נחסמים |
| כניסה לפי מספר טלפון | קהל בלי פרופיל פעיל ברשת החברתית, כניסה חוזרת, ערוץ גיבוי | נדרש ערוץ למסירת קודים והגנה מפני ניחוש; קישור המספר לחשבון דורש שלב אימות נפרד |
| כניסה אחודה | כמה אפליקציות או מדורים תחת חשבון אחד, מנוי משותף | תקלה אחת בשרשרת הכניסה משביתה את כל השירותים; נדרש מעגל ניהול סשנים משותף ויציאה מכולם בבת אחת |
בפועל בונים את הסכמה כ"דרך עיקרית ועוד חלופה": כניסה מובנית לרוב, מספר טלפון — כשהפרופיל ברשת החברתית אינו זמין. לכל כניסה מקצים מקור בפרופיל, כדי שהאנליטיקה תראה היכן בדיוק הולכים המשתמשים לאיבוד.
שלבי ההטמעה: מהביקורת ועד ההעברה לתמיכה
הטמעת כניסה דרך Одноклассники מתחילה בביקורת, לא בקוד: אנחנו מפרקים כיצד בנויה כעת הכניסה לאפליקציה, היכן מאוחסן הסשן ומה קורה כשהמשתמש שולל גישה מצדו. כך מוצאים את המקומות שבהם הכניסה החיצונית מתנגשת עם ההיגיון הקיים — קישור פרופיל לפי טלפון, מיזוג חשבונות, שחזור גישה.
סדר העבודות
- ביקורת תרחיש הכניסה — אוספים את דרכי הכניסה הקיימות, כללי יצירת הפרופיל וההתנהגות בכניסה חוזרת באותו מכשיר.
- סכמת חילופי הנתונים — מתעדים אילו נתונים מגיעים מהצד החיצוני, מה אנחנו שומרים אצלנו, כיצד נבדקת אמינות התשובה וכמה זמן חי הסשן.
- תכנון הנטישות — מפתחים את שלילת הגישה, היעדר התשובה, החלפת בעל החשבון וכניסה לאחר עדכון האפליקציה.
- הגדרה באפליקציה — מטמיעים את הכניסה במסכי ההרשמה והאזור האישי, ומסנכרנים עם הדרכים שכבר פועלות.
- בדיקה על מכשירים — מריצים את התרחיש על מכשירים חיים מדורות שונים: רשת איטית, כניסה במקביל מהטלפון ומהטאבלט, מעבר בין חשבונות.
- נראות תפעולית — סופרים את שיעור הכניסות המוצלחות והנטישות לפי סיבות, כדי לראות שחיקה לפני שפונות פניות מהמשתמשים.
- העברה לתמיכה — מוסרים את הסכמה, הנחיות לקו הראשון, סדר האבחון ועדכון המפתחות.
לאחר ההעברה, צוות התחזוקה מבדיל בעצמו בין תקלה בצד הפלטפורמה לבין שגיאה באפליקציה — בלי להזעיק מפתחים על כל מקרה.
ערכת ההגדרות והתיעוד לאחר ההטמעה
את הערכה מרכיבים כך שניתן יהיה להפעיל ולפתח את הכניסה דרך Одноклассники בלעדינו: את ההגדרות מייצאים מהקונסולה של האפליקציה, ולא "מחזיקים בראש", ואת ההסכמות בנוגע לסודות ולהרשאות מתעדים בכתב. להלן — מה שנשאר פיזית בידי הצוות שלכם לאחר המסירה.
- תצורת הכניסה. מזהי האפליקציה, כתובות החזרה המותרות, מערך ההרשאות המבוקשות, תוחלת חיי הסשן וכללי הארכת הגישה — עם ציון היכן בדיוק משתנה כל פרמטר ומה הוא משפיע עליו.
- סכמת זרימות הנתונים. דף אחד: מהלחיצה על הכפתור ועד להופעת הפרופיל באפליקציה, כולל חילופי קוד האישור, הקריאה לחלק השרת ורשימת הנתונים שאיננו מבקשים ואיננו שומרים.
- כללי גישה. מי רואה את סודות האפליקציה, מי רשאי לשנות הגדרות, כיצד נפתח ונסגר חשבון המהנדס, ובאיזו תדירות מתעדכנים המפתחות.
- הנחיה לתמיכה. פירוק הפניות השכיחות: המפתח פג, המשתמש שלל הסכמה ברשת החברתית, הצד של הרשת החברתית אינו זמין. לכל מקרה — מה בודקים ראשון ומה עונים למשתמש.
- סדר שלילת הגישה. כיצד מכבים את הכניסה לחלוטין, כיצד שוללים את ההרשאות שהוענקו למשתמשים, מה קורה לסשנים פתוחים וכיצד מחזירים את התצורה הקודמת.
- צ'ק-ליסט בדיקות לפני שחרור. מערך חשבונות בדיקה, תרחישי כניסה מוצלחת וביטול, בדיקה בגרסאות שונות של המערכת ובמכשיר בלי אפליקציית הרשת החברתית מותקנת.
את כל זה מוסרים בדמות הגדרות מיוצאות, סכמות ותקנונים טקסטואליים במאגר שלכם או בבסיס הידע. מעדכנים עם שינוי כללי הרשת החברתית — לפי תקנון תחזוקה מוסכם.
מקרה בוחן: כיצד החזרנו למשתמשים כניסה בלי תקלות
מה היה
באפליקציה של הלקוח הכניסה דרך Одноклассники הסתיימה בהצלחה רק עבור 71% מהמשתמשים: כל שלישי הגיע למסך "הכניסה נכשלה". הסיבה לא הייתה בממשק — השירות החיצוני השיב מדי פעם בסירוב לחילוף האישור, והאפליקציה ראתה בכל סירוב סופי והציעה להתחיל מחדש.
במהלך שבוע זה הניב כ-2,400 ניסיונות חוזרים: אנשים לחצו על כפתור הכניסה 3-5 פעמים, וחלק הלכו להירשם בדואר. הזמן עד למסך הראשון לאחר האישור נמתח ל-6-9 שניות — בזמן הזה המשתמש הספיק לסגור את האפליקציה.
מה נהיה
הפרדנו בין מצבי הכניסה: סירוב של השירות החיצוני, ניתוק הרשת וביטול מצד המשתמש מטופלים באופן שונה. בתקלה קצרת מועד הבקשה חוזרת אוטומטית בהשהיה הולכת וגדלה, והתשובה שכבר התקבלה נשמרת ומנוצלת מחדש בלחיצה חוזרת — אין יותר בקשות כפולות לשירות.
שיעור הכניסות המוצלחות עלה מ-71% ל-98.6%. הזמן עד למסך הראשון לאחר האישור התקצר מ-6-9 שניות ל-1.3-1.5. מספר הניסיונות החוזרים בשבוע ירד מ-2,400 ל-190 — תקלה בצד החיצוני הפסיקה להיות הבעיה של המשתמש.
בנפרד הצבנו ניטור על שיעור הנטישות: אם הוא עולה מעל לסף, אנחנו יודעים על כך לפני שנשפכות הפניות לתמיכה.
במה שונה כניסה דרך רשת חברתית מכניסה לפי מספר?
כניסה לפי מספר מאשרת בעלות על ערוץ מסוים: הקוד מגיע למכשיר שבו האדם משתמש כעת, והמספר הזה נשאר המפתח לחשבון. כניסה דרך Одноклассники בנויה אחרת — הרשת החברתית כבר אימתה את האדם, ולאפליקציה היא מוסרת מזהה ופרופיל בסיסי, בלי סיסמה משלה ובלי קוד.
מכאן ההבדל העיקרי — בצד של מי נמצא אימות הזהות. בכניסה לפי מספר את הבדיקה מבצעים אנחנו יחד עם ספק התקשורת, ובכניסה דרך רשת חברתית היא מואצלת כולה לשירות חיצוני.
אם הוא אינו זמין, הגביל מתן נתונים או שינה את כללי העבודה עם אפליקציות, הכניסות החדשות נפסקות, אף שהקוד שלנו לא השתנה, — ואין ביכולתנו להשפיע על כך ישירות.
החלפת מכשיר מתנהגת באופן שונה. עם מספר די בהזנת הקוד בטלפון החדש — הגישה עוברת בתוך דקה ואינה דורשת לזכור סיסמה. עם רשת חברתית האדם חייב לזכור את פרטי החשבון שלו ולעבור את הגנתו, ואם האפליקציה נמחקה והסיסמה נשכחה, השחזור עובר לצד של הרשת החברתית.
גם שחזור הגישה שונה בהיקף התמיכה. לפי מספר אנחנו רואים את הקישור, יכולים ליזום הנפקה מחדש של הקוד ולטפל בפנייה בעצמנו. אם אבד חשבון ברשת החברתית, אין לנו מנופים: החשבון באפליקציה הופך לבלתי נגיש, ופניות "אני לא מצליח להיכנס" עוברות לצד החיצוני.
בפועל אנחנו לרוב עושים את הכניסה דרך רשת חברתית לדרך מהירה ומשלימה, ואת המפתח העיקרי לשחזור משאירים מספר או דואר המשויכים לפרופיל. אז החלפת מכשיר ואובדן גישה חיצונית אינם הופכים לאובדן החשבון.
שאלות טכניות שכיחות בנוגע לחיבור הכניסה
כשהכניסה דרך Одноклассники כבר פועלת והאפליקציה חיה בחנויות, השאלות עוברות מ"כיצד להגדיר" ל"כיצד זה מתנהג בהפעלה". לרוב צפים ארבעה תרחישים: עדכון של בנייה שכבר פורסמה, בדיקה חוזרת של החנות, שלילת גישה והחלפת מכשיר.
לא יהיה צורך לכתוב מחדש את שכבת האימות. די לתעד היכן מאוחסן הסשן וכיצד האפליקציה מגיבה לסירוב הפלטפורמה — ואז משפך הכניסה נשאר צפוי.
מה משתנה בעדכון של אפליקציה שכבר פורסמה?
את הכניסה עצמה אין צורך לרשום מחדש: מזהה האפליקציה בצד הפלטפורמה אינו משתנה, רק הבנייה מתעדכנת. הבדיקה החוזרת של החנות עוברת כריליס רגיל — את בניית הבדיקה מריצים לפני הפרסום, כדי לתפוס אי-התאמות בהרשאות.
מה לעשות אם אצל המשתמש לא מותקן לקוח של הרשת החברתית?
כניסה לפי שם משתמש וסיסמה בחלון הפלטפורמה עובדת גם בלי לקוח מותקן — המשתמש חוזר לאפליקציה דרך הקישור. בודקים גם סגירת חלון באמצע: האפליקציה לא אמורה להיתקע בטעינה.
מה קורה בעת שלילת גישה?
המשתמש רשאי לשלול את הגישה בהגדרות הרשת החברתית. בפנייה הבאה לפרופיל מגיע סירוב — זהו תרחיש שגרתי: מציגים מסך כניסה חוזרת ושומרים את נתוני החשבון המקומיים.
כיצד הכניסה מתנהגת בעת החלפת מכשיר?
הסשן משויך למכשיר, ולכן בטלפון חדש עוברים את הכניסה מחדש. בודקים שלושה מצבים — כניסה נקייה, כניסה לאחר התקנה מחדש וכניסה עם פרופיל שמור — כדי שלא ייווצרו כפילויות של חשבונות.
נדון במשימה: כניסה לאפליקציה לפי התרחיש שלכם
הערכת העבודות על כניסה דרך Одноклассники תלויה לא בכפתור עצמו, אלא במה שקורה סביבו. כדי להחזיר מספר ותוכנית, ולא טווח רחב, יש צורך בתרחיש כניסה שלם — כולל הצד שלכם בעיבוד הפרופיל.
- פלטפורמה ואופן הבנייה: פרויקט נייטיבי או שכבה חוצת-פלטפורמות, ועל איזה ענף עדכני נבנית האפליקציה;
- דרכי הכניסה הנוכחיות וכיצד החדשה מתקיימת לצידן על אותו מסך;
- מה אתם עושים לאחר קבלת הפרופיל: קישור למזהה פנימי, הנפקת סשן, מסכים התלויים בנתונים;
- חילופים עם חלק השרת: שירות נפרד או פנייה ישירה מהקליינט;
- מצבי חשבון המשתמש: כניסה חוזרת, סירוב, שלילת גישה, אי-התאמה בין פרופילים;
- מגבלות: דרישות אבטחה, אזורים, כללי חנויות האפליקציות, תאריכי שחרור יעד.
זה מספיק כדי לפרוס את העבודה לשלבים ולנקוב בלוח זמנים לחיבור בלי מרווח "ליתר ביטחון". בתגובה אנחנו שולחים לא "נעשה", אלא ערכה עובדת:
- פירוק תרחיש הכניסה עם הסתעפויות ופתרון מוצע לכל אחת;
- רשימת שאלות שצריך לסגור לפני ההתחלה, עם ציון מי אחראי;
- תוכנית הטמעה לפי שלבים עם תלויות ונקודות בדיקה;
- לוחות זמנים לחיבור ורשימה של מה שמשפיע עליהם;
- הערכת עבודות לפי שלבים עם ציון ההנחות שעליהן היא מבוססת.
אם חלק מהנתונים עדיין אינו ידוע, כתבו כמו שזה: פערים בנתוני המקור אנחנו מוציאים בנפרד, כדי שלא יהפכו לסיכון סמוי בשלב ההשקה. תארו את המשימה — ונחזור עם הערכה ותוכנית.