חיפוש דינמי

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

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

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

הסבר על הרכיבים המרכזיים

כדי ליצור תכונה מקיפה של SAYE, צריך להבין את שני ממשקי ה-API הבסיסיים שמוצעים על ידי AI Commerce Search:

  1. ‫CompleteQuery API: זהו הממשק שמספק את ההצעות להשלמה אוטומטית.

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

  2. ‫Search API:זהו מנוע ליבת גילוי המוצרים שלכם.

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

חיפוש בזמן ההקלדה

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

תבנית הטמעה 1: גישה ישירה אבל יקרה יותר

זו השיטה הכי פשוטה להטמעה. הלוגיקה היא שלכל הקשה על מקש, מתבצעות קריאות מקבילות ל-API‏ CompleteQuery ול-API‏ Search.

Flow

התהליך מתבצע לפי הנתיב הבא:

  1. משתמש מזין תו, כמו l.
  2. האפליקציה שולחת את l אל CompleteQuery API.
  3. במקביל, האפליקציה שולחת את l אל Search API.
  4. התוצאות משולבות ומוצגות.
  5. המשתמש מזין תו נוסף (l), כך שהשאילתה הופכת ל-li.
  6. התהליך חוזר על עצמו עבור השאילתה החדשה li.

יתרונות

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

חסרונות

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

התבנית הזו מבצעת אופטימיזציה של העלות, הביצועים והרלוונטיות באמצעות ה-API‏ CompleteQuery כדי להחליט בצורה חכמה מתי לבצע קריאה ל-API‏ Search.

Flow

התהליך מתבצע לפי הנתיב הבא:

  1. משתמש מזין שאילתת טקסט חלקית, כמו lip.
  2. האפליקציה שלכם שולחת את lip אל CompleteQuery API.
  3. ה-API מחזיר רשימה של הצעות, כשהתוצאה הראשונה היא כנראה שפתון.
  4. האפליקציה שלכם מקבלת את ההצעה הראשונה (שפתון) ושולחת קריאה אחת ל-Search API עם המונח הזה.
  5. מוצגים ההצעות להשלמה אוטומטית ותוצאות המוצרים לחיפוש שפתון.
  6. כשהמשתמש ממשיך להזין lips, lipst, ..., אפשר להוסיף לוגיקה כדי לבצע קריאה חדשה לחיפוש רק אם ההצעה הראשונה להשלמה אוטומטית משתנה.

יתרונות

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

טיפול במקרי קצה

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

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

מדידת ההצלחה באמצעות מזהי ניסויים

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

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

  • אירועי SAYE: הקצאת מזהה ספציפי, כמו "experimentId": "saye-widget", לכל אירועי החיפוש שמקורם בתכונה 'חיפוש תוך הקלדה'.
  • אירועי חיפוש ראשיים: משתמשים במזהה אחר (או ללא מזהה) לחיפושים שמתחילים כשמשתמש מקיש על Enter או לוחץ על חיפוש כדי לעבור לדף הראשי של תוצאות החיפוש.

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

סיכום

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