בדיקת כתובות אתרים מפוצלות

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

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

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

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

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

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

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