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

מדוע התאמה אישית של החיפוש ב-e-commerce מאבדת המרות

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

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

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

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

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

מה משתנה לאחר ההטמעה: אפקטים בגדלים מדידים

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

חלק ההזמנות מתוך תוצאות החיפוש

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

זמן עד לתשובה רלוונטית

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

יציבות בעומסי שיא עונתיים

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

סוג השגיאות שנעלם

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

דרכי התאמה אישית: מה מתאים ומה חסר

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

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

מקרי קצה ששוברים את הסכימה

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

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

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

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

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

קריטריוני מוכנות בכל שלב

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

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

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

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

תמיכה בכוחות עצמך

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

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

מה קורה לאחר המסירה

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

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

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

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

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

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

מדדים לפני ואחרי

במהלך שישה שבועות של תצפית חלק ההזמנות מתוצאות החיפוש עלה מ-7% ל-12%, חלק השאילתות הריקות ירד מ-18% ל-6%, וההמרה של התוצאות — פי 1.6. גם עומק הסשן עלה: חלק השאילתות שאחריהן הקונה אינו מנסח מחדש את התנאי עלה מ-61% ל-79%.

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

מה לעשות אם הקטלוג כבר מחובר למנוע מוכן?

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

מדוע לרוב בוחרים בהיברידי

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

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

שאלות טכניות: נתונים, התחלה קרה, חזרה לאחור

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

חנות בלי היסטוריית הזמנות — מה לעשות?

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

כיצד מתנהגות התוצאות בעונה?

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

מה עם כרטיסים שכבר אינם בקטלוג?

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

האם אפשר לחזור אחורה משינויי דירוג?

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

נדון במשימה: מה נדרש ממך להתחלה

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

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

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