שיטות מומלצות להגדרת ניתוח נתונים בשיחה ב-Looker

ניתוח נתונים באמצעות שיחה מאפשר למשתמשים לשלוח שאילתות לגבי נתונים שעברו מודלים ב-LookML, על ידי שאלת שאלות בשפה טבעית בתוך מופע Looker. המשתמשים יכולים לשלוח שאילתות לנתונים בדרכים הבאות:

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

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

איך Gemini for Google Cloud ‎ משתמש בנתונים שלכם, ובאילו מקרים.

שיטות מומלצות לשימוש ב-LookML בניתוח נתוני השיחות

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

  1. מודל LookML: ניתוח שיחות מנתח את המבנה, השדות (מאפיינים, מדדים), התוויות, התיאורים והמילים הנרדפות שמוגדרים במודל LookML שעליו מבוסס הכלי 'ניתוח נתונים' ב-Looker.

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

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

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

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

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

הקפדה על שמות סטנדרטיים: כדאי לבדוק את שמות השדות והתוויות כדי לוודא שהם עקביים וברורים.
עומס מיותר על מסד הנתונים: ניתוח שיחות משתמש בשיטה Model field name suggestions של Looker API כדי לאחזר ערכי דוגמה לשדות ולבחור את השדה או ערך המסנן הנכונים עבור שאילתות שנוצרות. ההצעות האלה נשלפות מהמסד הנתונים, ולכן יכול להיות שהן יופיעו לאט או שהן יגרמו לעומס מיותר. שימוש ב-LookML: כדי להימנע מהצורך להריץ שאילתות API כדי לאחזר ערכי הצעות, אפשר להגדיר ערכי דוגמה ב-LookML:
  • אפשר להשתמש בפרמטר suggestions כדי להגדיר רשימה של ערכים אפשריים למאפיין, לשדה סינון או לפרמטר.
  • משתמשים בפרמטר suggest_explore ובפרמטר suggest_dimension בשילוב כדי להנחות את ניתוח השיחות לשאול שאילתה לגבי מאפיין חלופי של ערכי הצעות כשמשתמשים בשדה filter ספציפי או במאפיין type: string כדי לסנן שאילתה. השיטה הזו יכולה להניב שאילתות יעילות יותר, במיוחד אם השדה נמצא בטבלה גדולה.
מורכבות נסתרת: אם אתם מסתמכים במידה רבה על שדות בהתאמה אישית ברמת לוח הבקרה או על חישובים בטבלה, יכול להיות שלוגיקה עסקית קריטית לא תהיה זמינה לניתוח שיחות. שילוב לוגיקה מותאמת אישית: זיהוי של שדות מותאמים אישית או חישובים בטבלה שחשובים ושימושיים. ממירים את הלוגיקה של השדות האלה למאפיינים ולמדדים ב-LookML כדי שאפשר יהיה להשתמש בהם ב-Conversational Analytics.
נתונים מבולגנים: סוגי הנתונים הבאים לא עקביים או לא מובנים בצורה טובה, ולכן קשה לנתח את השאילתות בצורה מדויקת באמצעות ניתוח שיחות.
  • וריאציות של ערכים: שימוש לא עקבי באותיות רישיות או במוסכמות שמות (לדוגמה, שילוב של הערכים complete, Complete ו-COMPLETE) עלול להוביל לשכפול נתונים או ליצירת קשרים שגויים בין נתונים ב-Conversational Analytics.
  • סוגי נתונים לא עקביים: אם עמודות שאמורות להיות מספריות מכילות ערכי מחרוזת מדי פעם, סוג השדה יהיה string, ולא ניתן יהיה לבצע פעולות מספריות.
  • אי בהירות לגבי אזור הזמן: היעדר אזורי זמן סטנדרטיים בשדות של חותמות זמן עלול להוביל לסינון או לצבירה שגויים.
 איכות נתוני הכתובות: אם אפשר, כדאי לסמן בעיות באיכות הנתונים (ערכים, סוגים ואזורי זמן לא עקביים) שזיהיתם במהלך אוסף הנתונים. עובדים עם צוותי הנדסת נתונים כדי לנקות את נתוני המקור או להחיל טרנספורמציות בשכבת ה-ETL או בשכבת המודלים של הנתונים.

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

מתי כדאי להוסיף הקשר ל-LookML ומתי לניתוח נתונים בשיחה

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

ההקשר של הנציג צריך להיות איכותי וממוקד במשתמש, ויכולים להיות הרבה נציגים שמשרתים משתמשים שונים מתוך Explore אחד. הנה כמה דוגמאות להקשר שצריך לכלול בהוראות לסוכן, אבל לא ב-LookML:

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

שיטות מומלצות להגדרת ניתוח נתונים ב-Explore לשימוש בניתוח נתוני שיחות

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

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