שיפור AI Commerce Search באמצעות התאמה אישית של מערכת ניהול קשרי לקוחות (CRM)

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

בחירת הנתונים להתאמה אישית

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

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

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

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

קטגוריות נתונים שסביר פחות שתהיה להן השפעה

לקטגוריות הנתונים האלה יש השפעה שולית על איסוף נתוני המסחר.

  • מאפיינים שנגזרים מהיסטוריית הרכישות:
    • המערכת שלנו כבר משלבת התנהגות רכישה קודמת לצורך התאמה אישית.
    • אין צורך לשלוח מאפיינים כמו user bought a green dress yesterday, כי המידע הזה נאסף ומשמש באופן טבעי.
    • להתמקד בתובנות חדשות ממערכת ה-CRM.
  • נתוני תגובה ספציפיים לשיווק, כמו Clicked email #7:
    • הנתון הזה רלוונטי לניתוח של קמפיינים שיווקיים, אבל הוא לא מציין ל-AI איזו תוצאת חיפוש להציג.

שלמות הנתונים

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

  • שימושי מאוד:
    • מאפיינים שקיימים עבור רוב המשתמשים, למשל shipping_state:MA אם הוא זמין ל-70% מבסיס המשתמשים.
    • כך אפשר לזהות דפוסים בצורה יעילה וליישם התאמה אישית באופן נרחב.
  • פחות מועיל:
    • מאפיינים שזמינים רק לחלק קטן מהמשתמשים, כמו hair_color:blonde אם המאפיין זמין רק ל-0.1% מבסיס המשתמשים.

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

הנחיות לגבי רמת הפירוט של הנתונים

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

רמת פירוט מתאימה

דוגמאות לגרנולריות מתאימה הן שדות של:

  • מגדר
  • מדינה
  • עיר
  • קבוצת גיל (לדוגמה, 30-39)

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

רזולוציית הניווט לא מספיקה

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

רמת פירוט גבוהה מדי

דוגמאות לגרנולריות מוגזמת:

  • מיקודים מדויקים (zipcode:12345): יש עשרות אלפי מיקודים פוטנציאליים, ולרובם יש מספר קטן מאוד של לקוחות משויכים. הפיצול הזה מדלל את האות. אם משתמשים במיקוד, כדאי לקצר אותו לשתי הספרות הראשונות כדי להשיג רמת פירוט מתאימה יותר. שתי הספרות הראשונות של המיקוד ממופות בקירוב לאזורים בגודל של מדינה.
  • גילאים מדויקים (age:37): האפשרות הזו יוצרת מספר גדול מדי של קטגוריות גיל. כדי לצמצם את המספר, אפשר לקבץ נתונים מספריים כמו גיל לכ-10 קטגוריות מוגדרות מראש (למשל age:30-39).

הנחיות נוספות לגבי נתונים

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

פורמט נתונים קטגוריים

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

  • state:MA
  • gender:male

נתונים מספריים

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

דוגמאות שגויות ונכונות בהתאמה:

  • age:37
  • age:30-39

מגבלות נוספות על נתונים

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

שילוב API והעברת נתונים

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

מבנה מאגר אחסון לפרוטוקולים (למפתחים)

מאפייני המשתמש מוגדרים בהודעה SearchRequest כמיפוי של מחרוזות להודעה StringList.

הצגת דוגמה של protobuf

// A list of string values.
message StringList {
// String values.
repeated string values;
}

// Request message for [SearchService.Search][] method.
message SearchRequest {
...
// The user attributes that could be used for personalization of search.
maptring, StringList> user_attributes;
}

דוגמה לבקשת JSON

בדוגמה הזו מוצג מבנה של user_attributes בבקשת חיפוש בפורמט JSON.

הצגת קובץ JSON לדוגמה

{
...

user_attributes: [
       { key: "pets" # note keys can be hashed or unhashed
         value {
           values: "dog" # Note: these values MUST be hashed
           values: "cat"
         }
       },
       { key: "state"
         value {
           values: "CA"
         }
       }
      ]
}

תגובה מה-API

אין שינויים ב-API של SearchResponse כשמשתמשים בתכונה הזו. ההתאמה האישית מתבצעת באופן פנימי על סמך מאפייני המשתמש שסופקו.

הדרישות לגבי גיבוב נתונים

כדי לשמור על פרטיות הנתונים ועל האבטחה שלהם, חובה לבצע גיבוב (hash) של ערכי המאפיינים. אפשר לשלוח מפתחות מגובבים (hashed) או לא מגובבים.

גיבוב (hashing) של מפתחות

אפשר לשלוח מפתחות מאפיינים, כמו pet_owner ו-state, בצורת מחרוזת מקורית או בצורה מגובבת. שתי האפשרויות מקובלות.

לדוגמה:

  • מקובל – pet_owner
  • מקובל – hash(pet_owner)

גיבוב (hashing) של ערכים

ערכי מאפיינים, כמו dog ו-CA, חייבים להיות מגובבים. אסור לשלוח ערכי טקסט רגיל.

לדוגמה:

  • מקובל – hash(dog)
  • לא מקובל – "Dog"

גיבוב משולב של צמדי מפתח/ערך

אם רוצים לבצע גיבוב גם של המפתח וגם של הערך, צריך לבצע גיבוב של כל אחד מהם בנפרד. אל תבצעו גיבוב (hashing) של המחרוזת המשולבת של צמד המפתח/הערך.

לדוגמה:

  • מקובל – pet_owner:hash("dog")
  • מקובל – hash(pet_owner):hash("dog")
  • לא מקובל – hash("Pet_owner:dog")

שיטות מומלצות להעברת נתונים

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

איך מטפלים בערכים חוזרים

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

בדוגמאות הקוד הבאות אפשר לראות שימוש לא נכון ושימוש נכון, בהתאמה:

לצפייה בדוגמה

// This is incorrect because it sends the same key multiple times for different
// values, causing only one of the two values for pets to be used, choosing one
// value or the other in an inconsistent manner.
{
  key: "pets",
  value {
    values: "dog"
  }
},
{
  key: "pets",
  value {
    values: "cat"
  }
}

לצפייה בדוגמה

{
  key: "pets",
  value {
    values: "dog",
    values: "cat"
  }
}

עקביות הנתונים

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

לדוגמה, המאפיינים State:MA,‏ state:MA,‏ state:ma,‏ STATE:MA ו-residence_state:MA ייחשבו כמאפיינים נפרדים ולא קשורים.

גמישות בשמות של מפתחות מאפיינים

למרות שהיא עקבית, מוסכמת השמות הספציפית של מפתחות המאפיינים (לדוגמה, pet_owner, ‏ pets, ‏ codeabc) לא משפיעה באופן מובנה על היכולת של המערכת להשתמש בנתונים. ההיבט החשוב ביותר הוא העקביות של הנתונים שאתם מעבירים.

איך מטפלים בפרופילים שונים של משתמשים

מקובל שקבוצות שונות של משתמשים יכללו מאפיינים שונים.

  • דוגמה: למשתמש א' יכול להיות age:30-39 ו-pet:dog, ולמשתמש ב' יכול להיות gender:male אבל לא נתונים לגבי חיית מחמד או גיל. המערכת מטפלת בפרופילים חלקיים בצורה חלקה.

עדכונים דינמיים של נתונים

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

  • דוגמה: משתמש שמזוהה בהתחלה עם age:30-39 ו-pet:dog יכול לקבל בהמשך את state:MA אם המיקום שלו מתקבל.

עקביות בפלטפורמות שונות

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

  • אופטימלי: משתמש א' הוא תמיד age:30-39 גם באפליקציה לנייד וגם באתר.
  • לא אופטימלי: משתמש א' הוא age:30-39 באפליקציה לנייד, אבל רק pet:dog באתר.

איך מטפלים בנתונים חסרים

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

  • דוגמה: לא מומלץ להשתמש ב-pet:unknown או ב-pet:

גישה ל-SDK ולספרייה

אפשר לגשת לספריות האלה בגרסאות הבאות ואילך: