הטמעה של פילוח ברמת השורה לתוכן מוטמע של Looker

המאמר נכתב על ידי כריסטופר סימור, אנליסט נתונים בכיר, ודין היקס, מהנדס Developer Relations

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

מבוא

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

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

סקירה כללית של תרחישי שימוש

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

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

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

explore: products {
  access_filter: {
    field: products.brand
    user_attribute: brand
  }
}

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

משתמשים בנקודת הקצה create_sso_embed_url כדי ליצור כתובות URL להטמעה של לוח הבקרה הזה לכל משתמש שרוצה להטמיע אותו. בדוגמה הזו נשתמש בשני מותגים: Pied Piper ו-Hooli. זהו גוף הבקשה שמשמש בקריאה create_sso_embed_url עבור Pied Piper, עם external_user_id pied_piper:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "pied_piper",
  "first_name": "PiedPiper",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper"}
}

כתובת ה-URL שיצרתם עבור Pied Piper מציגה את לוח הבקרה כך:

זהו גוף הבקשה שמשמש בקריאה create_sso_embed_url עבור Hooli, עם external_user_id hooli:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "hooli",
  "first_name": "Hooli",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Hooli"}
}

כתובת ה-URL שנוצרה עבור Hooli מציגה את לוח הבקרה כך:

Voilà! הסינון של לוח הבקרה מתבצע לפי הערך של מאפיין המשתמש brand של כל משתמש שמוטמע.

חוקרים לעומק

מגניב! אבל מה קורה אם רוצים לתת למשתמש יחיד גישה לכמה מותגים? איך אפשר לוודא שרק משתמשים רלוונטיים יוכלו לראות את הנתונים שלי?

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

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

מידע בסיסי על הטמעה חתומה ב-Looker

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

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

המבנה של כתובת URL חתומה להטמעה

זו אחת מכתובות ה-URL החתומות לאימות הטמעה שנוצרו על ידי הקריאה create_sso_embed_url עם גוף הבקשה עבור Pied Piper:

https://mylookerinstance.cloud.looker.com/login/embed/%2Fembed%2Fdashboards%2F17?permissions=%5B%22access_data%22%2C%22see_user_dashboards%22%5D&models=%5B%22thelook%22%5D&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r%2FtFuvE%3D&nonce=%22967729518a7dbb8a178f1c03a3511dd1%22&time=1696013242&session_length=300&external_user_id=%22pied_piper%22&access_filters=%7B%7D&first_name=%22Pied%22&last_name=%22Piper%22&user_attributes=%7B%22brand%22%3A%22Pied+Piper%22%7D&force_logout_login=true

הנה אותה כתובת URL אחרי פענוח, שמוצגת בשורות נפרדות:

https://mylookerinstance.cloud.looker.com/login/embed/
/embed/dashboards/17
?permissions=["access_data","see_user_dashboards"]
&models=["thelook"]
&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r/tFuvE=
&nonce="967729518a7dbb8a178f1c03a3511dd1"
&time=1696013242
&session_length=300
&external_user_id="pied_piper"
&access_filters={}
&first_name="PiedPiper"
&last_name="User"
&user_attributes={"brand":"Pied Piper"}
&force_logout_login=true

כשניגשים לכתובת ה-URL הזו, קורים כמה דברים:

  1. מערכת Looker מחפשת חשבון משתמש קיים עם external_user_id = pied_piper. אם לא קיים חשבון כזה, Looker יוצר חשבון משתמש חדש עם ה-external_user_id הזה.

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

  3. ‫Looker מאמת את המשתמש ויוצר סשן עבורו על ידי אחסון קובץ Cookie זמני בדפדפן.

  4. לאחר מכן, Looker מפנה לכתובת היעד או לכתובת ההפניה שצוינו בקריאה create_sso_embed_url:

    https://mylookerinstance.cloud.looker.com/embed/dashboards/17.

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

    %2Fembed%2Fdashboards%2F17

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

  1. אתם (האדמינים של Looker) עוברים לחלונית Admin – Users ומשתמשים בסרגל החיפוש כדי לבדוק אם כבר קיים חשבון משתמש עבור המשתמש הזה. אם לא, יוצרים חשבון משתמש חדש.

  2. אתם (האדמינים של Looker) לוחצים על עריכה לצד המשתמש בחלונית 'אדמין – משתמשים' ומקצים למשתמש הרשאות, מודלים, קבוצות, ערכים של מאפייני משתמש וערכים אחרים.

  3. המשתמש עובר לדף הכניסה בכתובת https://mylookerinstance.cloud.looker.com/login ומזין את שם המשתמש והסיסמה שלו. ‫Looker מאמת את המשתמש ויוצר סשן עבורו על ידי אחסון קובץ Cookie זמני בדפדפן.

  4. לאחר מכן, Looker מפנה לדף הנחיתה (בדרך כלל https://mylookerinstance.cloud.looker.com/browse).

שימו לב: קובץ Cookie זמני יחול על כל כרטיסייה בחלון הדפדפן. אם המשתמש מתחיל ב-https://mylookerinstance.cloud.looker.com/browse, פותח כרטיסייה חדשה בדפדפן ומנווט לדף כלשהו שההרשאות שלו מאפשרות לו גישה אליו, הדף ייטען כצפוי באמצעות קובץ ה-Cookie של הסשן שכבר נוצר בכרטיסייה המקורית בדפדפן.

אותו הדבר נכון לגבי משתמשים שמוטמעים. הגישה של משתמשים שמוטמעים קצת יותר מוגבלת, והם יכולים לגשת רק לדפים בממשק המשתמש עם קידומת /embed של כתובות URL של Look, מרכז בקרה ו-Explore. אבל הם עדיין יכולים לעבור באופן ידני לכל לוח בקרה שהפרטים של חשבון המשתמש שלהם מאפשרים להם גישה אליו. נניח שכתובת ה-URL המקורית של ההטמעה החתומה מפנה אתכם ל-https://mylookerinstance.cloud.looker.com/embed/dashboards/17 בכרטיסיית דפדפן אחת. לאחר מכן פותחים כרטיסייה חדשה בדפדפן וטוענים לתוכה לוח בקרה מוטמע אחר שנמצא באותה תיקייה (ולכן יש לו את אותן הגבלות גישה): https://mylookerinstance.cloud.looker.com/embed/dashboards/19.

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

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

גישה לכמה מותגים בו-זמנית

חשוב לזכור שיש לכם גם שותפים חיצוניים שאולי הם הבעלים של כמה מותגים או מנהלים אותם. בדוגמה הזו, שותף מנהל את המותגים Pied Piper ו-Hooli.

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

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

  1. יוצרים שני חשבונות משתמשים שונים בדף 'משתמשים' במסוף Admin.
    1. בדף העריכה של נקודת הצירוף של המשתמש, מגדירים את ערך המאפיין של המשתמש brand ל-pied_piper.
    2. בדף העריכה של חשבון המשתמש השני, מגדירים את הערך של מאפיין המשתמש brand ל-hooli.
  2. אתם שולחים לשותף אימיילים להגדרת חשבון עבור שני חשבונות המשתמשים.
  3. השותף מגדיר לכל חשבון אישורים נפרדים של כתובת אימייל וסיסמה.
  4. אתם נותנים לשותף את הקישור למרכז הבקרה. (https://mylookerinstance.cloud.looker.com/dashboards/17) ולהסביר לו שכדי להחליף את לוח הבקרה בין מותגים, הוא צריך לחזור לדף הכניסה בכרטיסייה אחרת ולהזין את האימייל והסיסמה של חשבון המשתמש השני שלו, ואז לטעון מחדש את לוח הבקרה בכרטיסייה הזו.

השותף פועל לפי ההוראות. אבל אחרי שהשותף מזין את שם המשתמש והסיסמה של חשבון המשתמש ב-Hooli בכרטיסייה בדפדפן השנייה, ואז חוזר לכרטיסייה בדפדפן הראשונה שבה לוח הבקרה של Pied Piper כבר נטען, הוא לוחץ על הלחצן טעינה מחדש. להפתעתו של השותף, במרכז הבקרה מוצגים הנתונים של Hooli!.

אולי אתם חושבים עכשיו:

רגע… זה מאוד לא נוח. מה הדרך הכי טובה לעשות את זה?

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

‫Looker משתמש ב-external_user_id כדי להבדיל בין משתמשים מוטמעים מחוברים, ולכן לכל משתמש צריך להיות מזהה ייחודי שמוקצה לו.

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

גישה לכמה מותגים בו-זמנית – מה לא לעשות

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

  1. עוברים לכרטיסייה של לוח הבקרה של Pied Piper.
  2. עוברים לכרטיסייה של לוח הבקרה של Hooli.
  3. חוזרים לכרטיסייה של מרכז הבקרה של Pied Piper.
  4. לוחצים על הלחצן טעינה מחדש בלוח הבקרה של Pied Piper.

…לוח הבקרה של Pied Piper מציג את הנתונים של Hooli!

אפשר לנסות גישה דומה, אבל במקום זאת להשתמש באותו external_user_id test_user לשתי הקריאות create_sso_embed_url. אבל ההתנהגות זהה בדיוק – אחרי שהכרטיסייה נטענת מחדש עם לוח הבקרה של Pied Piper, מוצגים בה הנתונים של Hooli.

איך אפשר לוודא שבלוח הבקרה של כל מותג יוצגו רק הנתונים של אותו מותג?

יישום שיטות מומלצות

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

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

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

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

סינון התוצאות בלוח הבקרה

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

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

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

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

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

מילוי מראש של מסנני מרכז הבקרה

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

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

צריך לכלול את החלק הזה של כתובת ה-URL בקריאה target_url של create_sso_embed_url:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

אם אתם משתמשים ב-SDK להטמעה, אתם יכולים להשתמש ב-withFilters כדי לציין מסננים ראשוניים להחלה על התוכן המוטמע:

https://looker-open-source.github.io/embed-sdk/classes/EmbedBuilder.html#withFilters

אם אתם משתמשים בסקריפט מותאם אישית משלכם, חשוב לוודא שאתם מוסיפים את המסנן לכתובת ה-URL לפני שהנתיב מקודד. יכול להיות שחלק מהערכים כבר מקודדים במחרוזת המסנן (לדוגמה, יש רווח שמקודד כ-‎+‎ ב-?Brand=Pied+Piper), ולכן הערכים האלה יקודדו פעמיים בכתובת ה-URL הסופית. אפשר לעיין במאמר הזה. אפשר לעיין בפוסט בקהילת Looker כדי לקרוא על חלק מהניואנסים האלה. אם עדיין יש לכם בעיות בהוספת הפילטרים, תוכלו גם לפרסם את השאלות שלכם בפוסט הזה לקהילה.

הסתרת המסננים של מרכז הבקרה

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

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

אחרי שמפעילים את התכונה הזו, עוברים לקטע Dashboard Controls בדף Admin - Themes, ומבטלים את הסימון של האפשרות Display Filters Bar:

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

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli&theme=test_theme",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

במדריך הזה ב-YouTube, Embed Looker with custom filters (הטמעה של Looker עם מסננים בהתאמה אישית), יש מידע נוסף על הסתרת מסננים של לוח בקרה להטמעה, כולל כמה קטעי קוד של SDK להטמעה.

התוצאה הסופית צריכה להיות זהה לחוויית המשתמש מהשאלה המקורית:

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

בדיקה בתור משתמשים אחרים

עכשיו חוויית המשתמש דומה מאוד למה שדמיינתי בהתחלה. אבל בתרחיש השימוש שלי, לשותף יש הרשאות שונות והגדרות משתמש אחרות שאין למשתמשים הפרטיים עם external_user_id=pied_piper ו-external_user_id=hooli, ולכן האפשרויות שזמינות בממשק המשתמש שונות, וחוויית המשתמש הכוללת שונה במקצת. אני רוצה לאפשר למשתמש לראות הכול בדיוק כמו שמשתמשי pied_piper ו hooli רואים את זה, כאילו האדם הזה התחבר בפועל כמשתמשים האלה. איך אפשר לעשות את זה?

אם רוצים לאפשר למשתמש לבצע בדיקה בתור כל אחד מהמשתמשים של המותג, אפשר ליצור פונקציית sudo דומה באפליקציה שתטען את כתובות ה-URL להטמעה של external_user_id=pied_piper כשהמשתמש מבצע sudo בתור המשתמש של Pied Piper, ואת כתובות ה-URL להטמעה של external_user_id=hooli כשהמשתמש מבצע sudo בתור המשתמש של Hooli. אם האפליקציה שלכם משתמשת ב-API, אתם יכולים גם להשתמש בנקודת הקצה של login_user API כדי להשתמש ב-sudo בתור משתמש המותג עם ה-API.

עם זאת, אם נחזור להקשר של משתמשים שלא מוטמעים: בדף 'אדמין – משתמשים', אי אפשר להשתמש בפקודת sudo בו-זמנית לכמה משתמשים שלא מוטמעים בכמה כרטיסיות – סשן ה-sudo יחול על כל חלון הדפדפן, בדיוק כמו כל סשן משתמש אחר. לכן, מומלץ לעצב את sudo to sudo כך שרק משתמש אחד יוכל להשתמש בו בכל פעם. אם חושבים על זה, העיצוב הזה עקבי יותר עם חיקוי מושלם של חוויית המשתמש של המשתמשים שאתם מתחזים להם. לדוגמה, למשתמש pied_piper יש גישה רק ללוח הבקרה Pied Piper, ואין לו גישה לפתיחת לוחות בקרה נוספים בכרטיסיות נוספות. לכן, גם כשמבצעים פעולת sudo בתור המשתמש הזה, אי אפשר לפתוח לוחות בקרה שונים בכרטיסיות שונות.

סיכום

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