הטמעת דשבורדים של Metabase באפליקציית ווב: signed embedding

למה דוחות מובנים חושפים נתונים: ניתוח signed embedding

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

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

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

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

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

מה נותן הטמעת אנליטיקה בממשק המוצר

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

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

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

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

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

דרכים להטמעת אנליטיקה: היכן צריך signed embedding

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

מה עומד מאחורי הבחירה

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

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

שלבי עבודה: מאודיט מקורות ועד העלאה לפרודקשן

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

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

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

3. הגדרת signed embedding. ב-Metabase החתימה נבנית בשרת, המפתח הסודי לא נכנס לסימון; בתוכה מטביעים את פרמטרי הסינון ותוקף הקישור, כדי שדרך חשבון אחר לא ייפתחו נתונים של שכן.

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

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

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

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

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

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

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

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

קייס: צמצמנו שיעור כשלי גישה לדשבורדים

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

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

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

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

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

מה זה נתן

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

במה קישור חתום שונה מקישור ציבורי?

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

קישור חתום (Metabase signed embedding) — זה טוקן למשתמש מסוים ולכרטיס מסוים. בתוכו — מזהה דשבורד, סט פרמטרי גישה וזמן תפוגה; חתימה במפתח סגור לא מאפשרת להחליף אותם בשורת הכתובת. תוקף קובעים במפורש: מדקה לייצוא חד-פעמי ועד כמה שעות למסך עבודה.

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

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

ספקות טכניים ומגבלות הגישה

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

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

יעבירו את הקישור לצד שלישי?

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

מי אחראי לדשבורדים אחרי ההשקה ומה הגישה לא סוגרת?

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

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

נדון במשימת הטמעת האנליטיקה שלכם

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

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

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

תארו את המשימה — איזה מוצר, אילו משתמשים, עד איזה תאריך נדרשת התוצאה. נחזור עם הערכה ותוכנית.