הגדרת בדיקות A/B באפליקציה למובייל
אתם משיקים בדיקת A/B, רואים ערך p של 0.04 אחרי שלושה ימים, ועוצרים את הניסוי. התוצאה היא חיובית שגויה. זה קורה ב-80% מבדיקות ה-A/B למובייל, לפי נתונים סטטיסטיים. הסיבה היא הפרות סטטיסטיות בסיסיות: בדיקות מרובות ועצירה מוקדמת. בדיקות A/B הן כלי חזק, אבל רק כשהן מוגדרות נכון. הניסיון שלנו של 5+ שנים בפיתוח מובייל — יותר מ-50 בדיקות A/B שיושמו על iOS ו-Android. אנו מבטיחים הגדרה נכונה ותוצאות מובהקות סטטיסטית. צרו קשר לייעוץ.
איך לבחור כלי לבדיקות A/B?
| כלי | מתאים ל | חסרון |
|---|---|---|
| Firebase A/B Testing | ממשק פשוט/טקסט/פרמטרים | גמישות מוגבלת במיקוד |
| Amplitude Experiment | השערות מוצר עם ניתוח שימור | בתשלום, דורש Amplitude Analytics |
| Statsig | מחזור מלא: דגלים, ניסויים, ניתוח | דורש הגדרה |
| Growthbook | קוד פתוח, מתארח עצמאית | עלויות תשתית |
Firebase A/B Testing הוא התחלה סבירה לרוב הפרויקטים. אינטגרציה דרך Remote Config, ללא SDK נוסף. לפילוח מורכב (משתמשים ממוסקבה עם שלוש סשנים), Statsig יעיל פי שלושה בזכות דגימה מרובדת.
למה רוב בדיקות ה-A/B מייצרות חיוביים שגויים?
עצירת הבדיקה בתוצאה המובהקת הראשונה היא הטעות הנפוצה ביותר. אם אתם מסתכלים על ערך p כל יום ועוצרים כשערך p < 0.05 בפעם הראשונה, שיעור החיוביים השגויים יכול לעלות ל-30%. יש לעצור את הבדיקה רק כשמגיעים לגודל המדגם שנקבע מראש.
בדיקה אחת — מדד אחד. אי אפשר לבצע אופטימיזציה בו-זמנית לשיעור המרה ואורך סשן בבדיקה אחת. אם שני המדדים משתפרים, זה טוב, אבל היעד צריך להיות יחיד.
אפקט החידוש. עיצוב חדש נותן קפיצה בקליקים בשבוע הראשון רק בגלל שהוא חדש. לבדיקות התנהגותיות, משך מינימלי הוא שבועיים. לבדיקות שימור — 4 שבועות.
מתי כדאי לעצור בדיקת A/B?
יש לעצור את הבדיקה רק כשמגיעים לגודל המדגם שחושב מראש. אל תסתמכו על ערך p נוכחי. השתמשו במחשבון גודל מדגם: הזינו המרת בסיס, אפקט מינימלי ניתן לזיהוי (MDE), ורווח בר-סמך (בדרך כלל 95%). לדוגמה, עבור בסיס של 10% ו-MDE של 1%, תצטרכו כ-10,000 משתמשים לכל גרסה.
Firebase A/B Testing: הגדרה
Firebase A/B Testing בנוי על גבי Remote Config. ראשית, הגדירו פרמטר:
// Получаем значение из Remote Config
let remoteConfig = RemoteConfig.remoteConfig()
remoteConfig.configSettings = RemoteConfigSettings()
remoteConfig.configSettings.minimumFetchInterval = 0 // в debug
remoteConfig.fetchAndActivate { status, error in
let ctaText = remoteConfig.configValue(forKey: "checkout_cta_text").stringValue
self.checkoutButton.setTitle(ctaText, for: .normal)
}ב-Firebase Console → A/B Testing, צרו ניסוי:
- בחרו
// Получаем значение из Remote Config let remoteConfig = RemoteConfig.remoteConfig() remoteConfig.configSettings = RemoteConfigSettings() remoteConfig.configSettings.minimumFetchInterval = 0 // в debug remoteConfig.fetchAndActivate { status, error in let ctaText = remoteConfig.configValue(forKey: "checkout_cta_text").stringValue self.checkoutButton.setTitle(ctaText, for: .normal) }כפרמטר מטרה - קבוצת ביקורת: "Place Order"
- גרסה A: "Buy Now"
- מדד מטרה:
checkout_cta_text(אירוע המרה) - אחוז משתתפים: 50%
- גודל מדגם מינימלי: Firebase מחשב אוטומטית
מובהקות סטטיסטית: מלכודות נסתרות
| בעיה | השלכה | פתרון |
|---|---|---|
| בדיקות מרובות (הצצה) | חיוביים שגויים | הגדירו מראש גודל מדגם |
| מדדים מרובים | אופטימיזציית יתר | בחרו מדד ראשי אחד |
| אפקט חידוש | תוצאות מנופחות | לפחות שבועיים לבדיקות ממשק |
Statsig לניסויים מורכבים
כשנדרש פילוח גמיש יותר (בדיקה רק על משתמשים ממוסקבה עם > 3 סשנים):
// iOS Statsig SDK
import StatsigSDK
Statsig.initialize(sdkKey: "client-xxx") {
let experiment = Statsig.getExperiment("checkout_flow_v2")
let variant = experiment.getValue(forKey: "flow_type", defaultValue: "standard")
if variant == "simplified" {
self.showSimplifiedCheckout()
} else {
self.showStandardCheckout()
}
} // Android
val experiment = Statsig.getExperiment("checkout_flow_v2")
val flowType = experiment.getString("flow_type", "standard")Statsig תומך בדגימה מרובדת — חלוקה שווה של משתמשים בין שכבות (פלטפורמה, מדינה, תוכנית מנוי). ללא ריבוד, חלוקה אקראית יכולה ליצור קבוצות עם הרכב שונה, מה שמעוות תוצאות.
רישום חשיפה
לניתוח נכון, חשוב לרשום את העובדה שגרסה הוצגה — לא רק המרות:
Analytics.logEvent("experiment_exposure", parameters: [
"experiment_id": "checkout_cta_v2",
"variant": variantName,
"user_id": userId
])זה מאפשר לנתח המרה רק בקרב משתמשים שבאמת ראו את הניסוי, לא כל המשתתפים.
מה כלול בעבודה
- בחירת כלי מותאם למשימות ולמחסן הטכנולוגי (Firebase / Statsig / Amplitude Experiment)
- אינטגרציית SDK והגדרת Remote Config / Feature Flags
- יישום שכבת A/B בקוד עם טיפול נכון בגרסאות
- הגדרת מדדי מטרה ואירועי המרה
- הגדרת גודל מדגם ומשך בדיקה
- רישום חשיפה לניתוח
- ניתוח לאחר בדיקה עם בדיקות הנחות סטטיסטיות
- תיעוד תוצאות
לוח זמנים
בדיקת A/B בודדת על Firebase Remote Config: 1–2 ימים. תשתית לבדיקות A/B קבועות (Statsig/Growthbook): 3–5 ימים. התמחור מחושב באופן אישי. נבחן את הפרויקט שלכם — צרו קשר לייעוץ. אנו מבטיחים דיווח שקוף וניסויים נכונים. בקשו יישום בדיקות A/B וקבלו תוצאות מובהקות סטטיסטית ללא חיוביים שגויים.







