רשימת משימות לביצוע של בדיקת A/B למתחילים

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

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

לפני שמתחילים

אפשר לעיין בהנחיות הכלליות לביצוע ניסויי A/B.

רכיבי בדיקה

בדיקות ה-A/B למתחילים כוללות את רכיבי הבדיקה הבאים:

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

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

מזהה משתמש: מזהה מתמשך מומלץ מאוד למשתמש מחובר (כמו מזהה לקוח) שמשמש להתאמה אישית במכשירים שונים. הערך צריך להיות תמיד ערך מגובב.

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

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

תיאור

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

מזהה המבקר הוא מזהה ייחודי של משתמש במכשיר יחיד.

השפעה

בעבר, חלוקה לא הוגנת של מזהי מבקרים עלולה הייתה לגרום לשגיאות במדידה בבדיקות A/B.

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

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

תיאור

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

השפעה

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

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

• הדבר משפיע על המדידה ועל ההשוואות של מדדי הביצועים המרכזיים (KPI).

התפלגות של משתמשים מתקדמים (מזהה מבקר עם יותר רכישות)

תיאור

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

המטרה היא לוודא שהמשתמשים האלה עם ההוצאות הגבוהות יפוצלו באופן שווה.

השפעה

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

מספר טוקנים ייחודיים של AI Commerce Search לטוקן של אירועי חיפוש (אפשר להחיל את זה על גלישה אם צריך)

תיאור

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

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

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

השפעה

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

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

הבעיה הזו משפיעה על אימון המודל, על המדידה ועל ניתוח הביצועים.

התאמה בין מזהה המבקר ומזהה המשתמש בחיפוש המסחרי מבוסס ה-AI ובאירועי החיפוש (אפשר להחיל את זה על הגלישה אם צריך)

תיאור

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

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

השפעה

חוסר התאמה מצביע על בעיות פוטנציאליות כמו אירועים חסרים או נתונים פגומים.

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

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

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

התאמה בין מספר השאילתות ב-Search API לבין מספר האירועים (אפשר להחיל את זה על גלישה אם צריך)

תיאור

בבדיקה הזו משווים את נפח בקשות החיפוש שנשלחו אל Search API עבור נתיב ניסוי ספציפי (במיוחד נתיב Google) לנפח אירועי המשתמשים בחיפוש שנרשמו עבור אותו נתיב.

המספר של אירועי החיפוש שנאספים אמור להיות דומה למספר הקריאות ל-Search API שבוצעו.

השפעה

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

המסננים תואמים בין Search API לבין אירועי חיפוש, שניהם מצורפים לפי טוקן וכוללים (אפשר להחיל את זה על גלישה אם צריך)

תיאור

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

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

השפעה

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

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

תיאור

• בבדיקה הזו מוודאים שהפרמטרים של העמודים (offset) והקריטריונים למיון (order by) שכלולים בבקשת חיפוש שנשלחת אל Search API מיוצגים בצורה נכונה באירוע המשתמש המתאים של החיפוש.
• בדרך כלל האירועים האלה מקושרים לבקשה המקורית באמצעות אסימון השיוך (Attribution).
• הבדיקה הזו נועדה לוודא שיש עקביות באינטראקציות ספציפיות שמקושרות לטוקן ובנתונים הכוללים שנשלחים באירועים.
• חשוב לשמור על העקביות הזו בנתוני האירועים כדי לנפות באגים בתהליכים שעוברים המשתמשים שכוללים חלוקה לדפים או מיון, וכדי להשתמש בתכונות כמו חיפוש שיחות וסינון דינמי.

השפעה

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

העברת מזהי מבקרים בין מסלולי ניסויים

תיאור

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

השפעה

• הקצאה עקבית של מבקרים באתר היא חיונית לבדיקת A/B הוגנת.
• אם מבקר באתר עובר בין נתיבים, יכול להיות שהאירועים של המשתמש (קליקים, הוספה לעגלת קניות, רכישות) יתועדו תחת מזהי ניסוי שונים, ולכן לא ניתן יהיה לשייך באופן מדויק את ההתנהגות הכוללת שלו לחוויה אחת. הדבר גורם להשחתת הנתונים שמשמשים לחישוב מדדי הביצועים המרכזיים (KPI) של כל ערוץ, וכתוצאה מכך לתוצאות מדידה מוטות ולא מהימנות.
• האימון של מודל חיפוש מסחרי מבוסס-AI, במיוחד לצורך התאמה אישית, מסתמך במידה רבה על שדות visitorId ו-userId עקביים כדי לקשר בין אינטראקציות של משתמשים לאורך זמן ולשייך רכישות לאירועי חיפוש קודמים.
• החלפת מזהה המבקר מנתקת את הקישור הזה, ומונעת מהמודל ללמוד ביעילות מהמסלול של המשתמש בחוויית חיפוש עקבית. הדבר משפיע באופן משמעותי על המדידה ועל אימון המודל.

חיפוש אירועים עם אסימונים בנתיב ניסוי אחר (אפשר להחיל את הפעולה הזו על דפדוף אם צריך)

תיאור

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

השפעה

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

חיפוש ממשקי API עם מבקרים מנתיב ניסוי אחר (אפשר להחיל את זה על הגלישה אם צריך)

תיאור

• הבדיקה הזו מתמקדת בקריאות הנכנסות לבקשות חיפוש ל-AI Commerce Search API עצמו.
• הכלי מחפש בקשות שמקורן במזהי מבקרים או במזהי ניסויים שמיועדים לקבוצת הבקרה או לתנועת ההמתנה.
• המשמעות היא שהתנועה שמיועדת לקבוצת הבקרה או לקבוצת ההשוואה מנותבת באופן שגוי לנקודת הקצה של ה-API של מסלול הניסוי של Google.
• הבעיה הזו דומה מאוד לבדיקה של החלפת מזהה המבקר, אבל היא נצפית מצד בקשת ה-API ולא רק מצד אירוע המשתמש.

השפעה

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

אירועי רכישה עם מזהה מבקר מנתיב אחר של ניסוי

תיאור

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

השפעה

• הקצאה עקבית של מבקרים לנתיבי ניסוי היא חיונית לבדיקות A/B מדויקות.
• אם אירועים מסוג purchase-complete (רכישה הושלמה) מתויגים בטעות במזהה ניסוי שגוי, הם ישויכו באופן שגוי למסלול הזה.
• הדבר משפיע באופן ישיר על מדדים שמסתמכים על נתוני רכישה לפי נתיב, כמו שיעור ההכנסות, שיעור הזמנות הרכישה, ערך הזמנה ממוצע ושיעור ההמרה.
• שיוך שגוי לא מאפשר להשוות בצורה מדויקת בין הביצועים של קבוצות ניסוי שונות, ולכן התוצאות של מדידת בדיקות ה-A/B לא תקפות ולא מהימנות.
• מבחינת אימון המודל, מודלים של חיפוש מסחרי מבוסס-AI, במיוחד אלה שמבצעים אופטימיזציה להכנסה או לשיעור המרה, מתאמנים על ידי קישור אינטראקציות של משתמשים (כמו חיפוש) לרכישות שמתבצעות לאחר מכן, כדי להבין אילו תוצאות מובילות להמרות.
• כדי ליצור דוגמאות חיוביות לאימון, חשוב להשתמש בשיוך נכון, שלרוב מבוסס על מזהי מבקרים, משתמשים וניסויים כדי לקשר בין אירועי רכישה לחיפושים.
  • אם אירועי רכישה משויכים בטעות בגלל מזהים לא עקביים או מעבר בין נתיבי ניסוי, נתוני האימון נפגמים בגלל אותות שגויים.
• הבדיקה תקפה אם מזהי הניסוי נשלחים באירוע הרכישה: כמו שצוין, הבדיקה הזו תקפה ומשפיעה רק אם experimentIds מיושמים ונשלחים בצורה נכונה באירועי המשתמשים של השלמת הרכישה.

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

תיאור

• בדומה לבדיקה של אירוע הרכישה, הבדיקה הזו מוודאת שאירועי המשתמשים מסוג add-to-cart שמשויכים למזהה מבקר מסוים משויכים בצורה נכונה לנתיב הניסוי שהוקצה למשתמש באמצעות השדה של מזהי הניסוי.
• הוא מזהה מקרים שבהם אירוע של הוספה לעגלת הקניות מתויג במזהה ניסוי של נתיב שהמשתמש לא שויך אליו.
• הבעיה הזו יכולה לנבוע משימוש לא עקבי במזהה המבקר בסוגים שונים של אירועים או מתיוג שגוי של experimentIds.

השפעה

• תיוג שגוי של אירועי add-to-cart מוביל לשיוך שגוי של התנהגות המשתמש הזו לנתיבי הניסוי.
• הדבר משפיע ישירות על מדדים כמו שיעור ההוספות לעגלת הקניות ושיעור ההמרה, במיוחד אם שיעור ההוספות לעגלת הקניות נחשב לשלב חשוב במשפך ההמרה.
• מדדים לא מדויקים פוגעים באמינות של תוצאות בדיקת ה-A/B וביכולת למדוד בצורה נכונה את ההשפעה של הניסוי.
• מנקודת המבט של אימון המודל, אירועים של הוספה לעגלת הקניות משמשים כאותות חיוביים חשובים שהמודלים לומדים מהם, במיוחד מודלים שעברו אופטימיזציה להגדלת ההכנסות.
• אם האירועים האלה משויכים בטעות לנתיב הניסוי הלא נכון בגלל תיוג לא עקבי של מזהה או experimentIds, המודל מקבל אותות הדרכה שגויים או עם רעשי רקע.
• הבדיקה תקפה אם מזהי הניסוי נשלחים באירוע add_to_cart: כמו שצוין, הבדיקה הזו תקפה ומשפיעה רק אם experimentIds מיושמים ונשלחים בצורה נכונה באירועי המשתמש add_to_cart.

התפלגות המכשירים בכל סוג של אירוע במסלולי הניסוי

תיאור

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

השפעה

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

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

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

• אירועים הם הבסיס למעקב אחר מדדי ביצועים מרכזיים (KPI) ולפתרון בעיות כללי.

חיפוש אירועים עם מסננים בין נתיבי הניסוי, השוואה (אפשר להחיל את זה על חיפוש אם צריך)

תיאור

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

השפעה

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

שאילתה בין אירוע חיפוש לבין התאמה של Search API לפי אסימון, אבל לא לפי שאילתה (אפשר להחיל את זה על עיון אם צריך)

תיאור

• בבדיקה הזו בודקים תהליך ספציפי שעובר משתמש שמבצע חיפוש, על ידי קישור אירוע חיפוש לבקשה התואמת שלו ב-Search API באמצעות attributionToken.
• אסימון השיוך נוצר על ידי AI Commerce Search ומוחזר עם כל בקשת חיפוש.
• בבדיקה הזו מתבצעת השוואה בין השדה searchQuery באירוע החיפוש לבין מחרוזת השאילתה בפועל שנשלחה בבקשה הראשונית ל-Search API, שהחזירה את טוקן השיוך.
• אם מחרוזות השאילתה האלה לא תואמות למרות הנוכחות של אסימון שיוך לקישור, זה מצביע על כך שהשאילתה שהמשתמש שולח באירוע המשתמש לא משקפת בצורה מדויקת את שאילתת החיפוש המקורית של המשתמש.

השפעה

• הבעיה הזו משפיעה באופן משמעותי על אימון המודל.
• המודלים של AI Commerce Search מאומנים על סמך נתוני אירועים.
• המודלים, במיוחד מודלים לדירוג מחדש שמבוסס על קליקים, לומדים על ידי קישור של אינטראקציות עם המשתמשים (כמו קליקים, הוספה לעגלת קניות ורכישות) בחזרה לבקשות החיפוש שיצרו את התוצאות.
• הקישור הזה מתבסס על מידע מדויק באירועים, כולל השדות searchQuery ו-attributionToken.
• אם הערך searchQuery באירוע לא תואם לשאילתה בפועל מבקשת Search API, המודל מתאמן על נתונים שגויים, ומשייך את התנהגות המשתמש לשאילתה הלא נכונה.
• הדבר עלול להוביל להשפעה שלילית חמורה על איכות תוצאות החיפוש, כי המודל לומד אסטרטגיות דירוג לא אופטימליות שמבוססות על נתוני שאילתות פגומים.
• ההשפעה העיקרית היא על איכות אימון המודל, אבל יכולה להיות גם השפעה עקיפה על המדידה. הסיבה לכך היא שמודלים שאומנו על נתונים לא טובים יכולים להניב ביצועים נמוכים, מה שיוביל לתוצאות מוטות של בדיקות A/B, גם אם האירועים נרשמים.

מעקב אחרי Search API למבקר יחיד ואירוע חיפוש תואם (אפשר להחיל את זה על גלישה אם צריך)

תיאור

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

השפעה

• הבעיות שמזוהות בבדיקה הזו משפיעות באופן משמעותי על המדידה ועל אימון המודלים.

מדידה

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

אימון המודל

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