בדיקות A/B לדיוור ב-Bitrix24: הגדרת בדיקות מדויקות

בדיקות A/B ב-Bitrix24: היכן הסטטיסטיקה נשברת

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

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

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

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

מה נותנת מתודולוגיה נכונה לבדיקת היפותזות ב-Bitrix24

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

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

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

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

סוגי הגדרת בדיקה: מלא, סגמנטי, מזווג

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

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

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

שלבי יישום: מביקורת הבסיס ועד לנהלים

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

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

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

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

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

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

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

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

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

תרשימי סגמנטים, תבניות מייל ונהלי עצירת בדיקות

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

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

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

מקרה בוחן: איך פיצול הזרימה הסיר את כישלון המסירה

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

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

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

מה שינו

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

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

מה קרה בסוף

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

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

במה שונה בדיקה מזווגת מגלים עוקבים?

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

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

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

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

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

ספקות של מהנדס: גודל מדגם, חפיפות, ניקיון נתונים

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

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

אנשי קשר נכנסים לשני הסגמנטים — איך לספור?

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

שרשראות אוטומטיות, עונתיות ותדירות שליחה?

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

נדבר על המשימה שלכם: מה להכין לשיחה

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

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

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