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

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

כ-6% מהניסויים במיקרוסופט מראים אי התאמה ביחס הדגימה, אשר במוצר שמריץ 10,000 ניסויים בשנה מסתכמת בערך בגילוי אחד ביום (פביג'אן ואחרים, KDD 2019). צוותים שמנהלים הרבה פחות בדיקות כמעט ולא רואים את המספר הזה, משום שהבדיקה שהפלטפורמה שלהם מריצה לא יכולה להגיע למשמעותיות בנפח התעבורה שלה. הבדיקה נראית נקייה, מדווחת על עלייה של 4%, ובכל מקרה שגויה.

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

מה באמת אומרת לך אזעקת SRM

אי התאמה ביחס דגימה היא פער בין הפיצול שהגדרת לפיצול שאתה צופה: הגדרת 50/50 וקיבלת 50.8/49.2. הבדיקה הסטנדרטית היא מבחן טובות ההתאמה בריבוע של פירסון על ספירות החשיפה, דרגת חופש אחת עבור מבחן דו-זרועי.

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

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

פלטפורמהמִבְחָןדגלים בהערות
AB טעיםתכופה סדרתית (S-SRM)p <0.01בנוי לניטור רציף, כך שמבחנים חוזרים ונשנים
סטטסיגכי בריבועp <0.01"אנו רואים חשיפות כלא מאוזנות אם ערך ה-p של SRM נמוך מ-0.01"
ספר צמיחהכי בריבועp <0.001האזהרה מדוכאת מעל זה
מיקרוסופט (איור מדויק)כי בריבוע~1 ב-500,000פיצול של 50.2/49.8 ב-n הגדול כבר מנקה את זה

שתי השלכות. בדיקה שסומנה בפלטפורמה אחת עוברת בפלטפורמה אחרת עם נתונים זהים, כך ש"הכלי שלנו לא הזהיר אותנו" אינה עדות לפיצול נקי. וסף של 0.01 מסמן אחת למאה בדיקות בריאות. אם תבחנו את ערך ה-p מדי יום לאורך בדיקה של שלושה שבועות, גבול ההצצה העצמאית הנאיבית באזעקת שווא הוא 19%; הנתון האמיתי נמוך יותר מכיוון שימים רצופים מתואמים חזק, אך הוא אינו 1%. זו הסיבה ש-AB Tasty מפעילה הליך רציף. אם הפלטפורמה שלכם מפעילה חי בריבוע אופק קבוע, התבוננו פעם אחת, בסוף, בספירות מצטברות.

בדקו האם הבדיקה שלכם יכולה לזהות חוסר איזון בכלל

עבור חלוקה של 50/50, סטטיסטיקת כי בריבוע מפשטת ל-4n(p̂−0.5)², כאשר n הוא סך החשיפות. הפוך אותו ותקבל את חוסר האיזון הקטן ביותר שהבדיקה שלך יכולה לסמן:

סך החשיפותהפיצול הקטן ביותר המסומן ב-p < 0.01ב-p < 0.001
5,00051.8 / 48.252.3 / 47.7
10,00051.3 / 48.751.6 / 48.4
30,00050.7 / 49.351.0 / 49.0
100,00050.4 / 49.650.5 / 49.5
1,000,00050.13 / 49.8750.16 / 49.84

קראו זאת כמגבלה, לא כרישיון. ב-10,000 חשיפות, כל דבר קטן מ-1.3 נקודות חוסר איזון אינו נראה לבדיקה, ואפקט סלקציה של 1.3 נקודות מספיק בהחלט כדי לייצר עלייה קטנה בהמרה. זוהי הבעיה המבנית ברוב האזור. טורקיה רשמה כ-6 מיליארד עסקאות מסחר אלקטרוני בכ-634,000 עסקים בשנת 2025 (משרד המסחר, 12 במאי 2026), ממוצע של קרוב ל-9,500 בשנה כל אחד, וממוצע זה עולה בחדות על ידי קומץ שווקים. חנות בינונית שבודקת שלב בקופה עובדת עם עשרות אלפי חשיפות, לא מיליונים, כך שבדיקת ה-SRM שלה מזהה שברים גסים ושום דבר עדין יותר.

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

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

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

  1. ניתוח והפעלה. סימפטום: הפיצול נקי ביומן החשיפה הגולמי ושבור בכרטיס הניקוד. בדיקה: חשב מחדש את היחס ללא תנאי הטריגר, מסנן התאריכים וצירופים ברמת המדד. מאשר זאת אם היחס חוזר למצופה. תיקון: הערכת הטריגרים באופן זהה בשתי הזרועות, לפני שכל התנהגות ספציפית לוריאנט תוכל לשנות את הזכאות. אזעקת השווא הנפוצה ביותר, עשר דקות לשלילתה.
  2. עיבוד יומן. סימפטום: ספירת החשיפה שונה בין שני צינורות, או שהפער מופיע לאחר שלב ה-ETL. בדיקה: השווה את הספירה בצד ה-SDK, ספירת המחסן וספירת הדיווח עבור אותו חלון, לאחר מכן השווה את שיעורי ההדרה של מסנן הבוטים לכל זרוע. מאשר אם הזרועות שוות במעלה הזרם ולא שוות במורד הזרם. תיקון: סנן באופן דטרמיניסטי וזהה. תעבורה אוטומטית הגיעה ל-53% מתעבורת האינטרנט בשנת 2026, לעומת 51% בשנת 2024 (דו"ח Imperva Bad Bot, 29 באפריל 2026), כך שמסנן היוריסטי המתמקד בתזמון טעינה או בהתנהגות סוכן משתמש יכול להוציא בקצב שונה לכל וריאנט. אובדן המונע על ידי הסכמה נמצא גם כאן: כאשר ad_storage נדחה, פלטפורמת התגים של גוגל מפסיקה להגדיר קובצי Cookie של פרסום (מסמכי הסכמה לפלטפורמת התגים של גוגל), כך שאם שיעורי הדחייה שונים בין אזורים גיאוגרפיים במבחן אחד, כל מטלה הנשענת על מזהים אלה מאבדת משתמשים באופן לא אחיד.
  3. ביצוע. תסמין: חוסר האיזון גדל עם משקל הדף, מחמיר בנייד, או מתחיל בפריסה. בדיקה: פצל את היחס לפי מכשיר, דפדפן, סוג חיבור ויום; השווה את זמן החשיפה בין הזרועות. מאשר זאת אם הגירעון מתמקד במקטעים איטיים או בדפדפן אחד. תיקון: כאן מתות בדיקות הפניה מחדש. הפניה מחדש מוסיפה ניווט מלא לזרוע אחת בלבד, וכל מי שנוטש במהלכה הוא הפסד סלקטיבי. עבד את שני הגרסאות בצד השרת בכתובת URL אחת, או קבל את העובדה שהזרועות אינן ניתנות להשוואה.
  4. הקצאה. סימפטום: היחס אינו תקין מהשעה הראשונה ונשאר קבוע. בדיקה: הרצת A/A על אותה הקצאה וודא ש-Hash Salt לא נעשה בו שימוש חוזר מניסוי קודם על אוכלוסייה זו. מאשרת זאת אם גם ה-A/A מראה את חוסר האיזון. תיקון: הקצאה מחדש עם Salt חדש והפעלה מחדש. העברה מבדיקה קודמת היא הגרסה השקטה של ​​זה, ורק ה-A/A חושף אותו.
  5. הַפרָעָה. תסמין: חוסר האיזון מרוכז במספר קטן של מזהים בעלי פעילות גבוהה, או בטווחי IP פנימיים. בדיקה: התפלגות ספירת החשיפות לכל משתמש, ו-1% העליון של המזהים לפי נפח אירועים. אישור אם הסרתם משחזרת את היחס. תיקון: אי הכללה של תעבורה פנימית ותעבורה מבוססת סקריפט לפי כלל מתועד, לא ידנית, כך שהאי הכללה תהיה זהה בפעם הבאה.

מדריך עבודה

המספרים שלהלן הם להמחשה בלבד, לא נתוני לקוח. בדיקת קופה מדווחת על 61,480 חשיפות לקבוצת הביקורת ו-58,520 חשיפות לגרסה: 51.2/48.8 על 120,000 משתמשים, p בריבוע כי מתחת ל-0.001. ענף 1: הסרת תנאי הטריגר מחזירה 60,020 / 59,980, כך שההקצאה תקינה וההפסד מתרחש לאחר החשיפה. ענף 2: ספירות הצינור תואמות, אי הכללות בוטים 0.9% בשתי הזרועות. ענף 3: מחשב שולחני עומד על 50.1/49.9, נייד על 52.4/47.6, וזמן החשיפה החציוני של הגרסה גבוה ב-900 מילישניות בנייד. אבחון: הגרסה שולחת בקשת חסימת רינדור נוספת, משתמשי נייד נוטשים במהלכה, לשורדים יש חיבורים טובים יותר. הקריאה בטלה. התיקון הוא תיקון ביצועים, והבדיקה מופעלת מחדש, לא מתפרשת מחדש.

מה אפשר להציל ומה לא

  • בטל את הקריאה כאשר מנגנון ההפסד יכול להיות בקורלציה סבירה עם המדד. כל סיבת ביצוע והקצאה עומדת בקריטריונים כברירת מחדל.
  • הצלה לפי פלח רק כאשר חוסר האיזון מוגבל לפלח שניתן להוציא אותו באופן ברור, פלח זה הוגדר לפני שבדקתם את המדד, והשאר עובר בדיקת SRM משלו. שניים מתוך שלושה אינם מספיקים.
  • שמור את הבדיקה כאשר הסיבה הייתה אך ורק בניתוח וכרטיס הניקוד המתוקן עובר. אתם קוראים מחדש את אותם נתונים עם מסנן קבוע, לא דיג.
  • רשום את זה בכל מקרה. רשמו את קטגוריית הסיבה בניסוי. הטקסונומיה משתלמת באופן מצטבר: אם שלושה מתוך עשרת הבדיקות האחרונות שלכם נכשלו בענף 3, הבעיה שלכם אינה ניסוי, אלא אספקה ​​חזיתית. [נתונים פנימיים נדרשים: שיעור הניסויים שבוצעו על ידי Switas ב-24 החודשים האחרונים שנכשלו בבדיקת SRM, מחולקים לפי ענף טקסונומיה, כדי להחליף את מדד הייחוס של מיקרוסופט ב-6% בנתון משוק זה]

איפה זה מתפרק

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

שאלות נפוצות

האם פיצול של 51/49 תמיד מהווה בעיה? זה תלוי לחלוטין ב-n. ב-5,000 חשיפות מדובר ברעש רגיל; ב-500,000 מדובר בפגם כמעט ודאי. שפטו את היחס מול טבלת הגילוי, ולא מול כלל אצבע קבוע באחוזים.

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

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

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

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

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

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

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

הפעל את הבדיקה בתוכנית הניסוי שלך

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

מקורות


מאמרים נוספים

סוויטאס כפי שנראה ב

Magnify: הרחבת שיווק משפיענים עם Engin Yurtdakul

צפו במחקר המקרה שלנו בנושא Microsoft Clarity

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