BI ללא Data Lake

רוב פרויקטי ה-BI בסטארטאפים מתחילים מוקדם מדי ובגדול מדי.

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

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

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

זו התבנית שאנו משתמשים בה ב-VM0: ענף Neon עם מסכות, לקריאה בלבד, שמספק לסוכנים שלנו מספיק אמת כדי להריץ BI, מבלי לתת להם את הנתונים שהם לעולם לא אמורים לראות.

בעיית המייסד: השאלות מגיעות לפני צוות הדאטה

חברות בשלבים מוקדמים לא חסרות שאלות. הן חסרות זמן.

כל יום, צוות המייסדים רוצה לדעת דברים כמו:

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

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

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

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

מסד הנתונים הוא כבר מקור האמת

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

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

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

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

מתוך המשתמשים שנרשמו מהערוץ הזה, כמה הריצו משהו ביום הראשון, וכמה חזרו אחרי ההרצה הראשונה?

או:

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

או:

כמה משאבים שרפו חשבונות ניסיון חדשים ב-6 השעות הראשונות, לפני ואחרי ששינינו את מנגנון מניעת הניצול?

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

קיצור הדרך הלא בטוח הוא גישה לייצור הגולמי

קיצור הדרך המפתה ברור: פשוט לאפשר לסוכן לשאול את מסד הייצור.

זה לא מקובל.

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

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

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

עבורנו, ההגבלות האלו הן העיקר:

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

זו הצורה של המערכת שהיינו צריכים.

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

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

ב-VM0, אנו משתמשים בזה כדי ליצור את מה שאנו מכנים MaskDB.

הזרימה פשוטה:

1. מתחילים מענף ההורה של Neon בייצור.
2. יוצרים ענף חדש לפי לוח זמנים.
3. מתקינים את PostgreSQL Anonymizer וכלי מסכות ייעודיים ל-VM0.
4. מיישמים תוויות אבטחה לעמודות רגישות.
5. מריצים אנונימיזציה סטטית על הענף.
6. מיישמים מסכות מותאמות לשדות שדורשים טיפול מיוחד.
7. יוצרים תפקיד masked_readonly עם גישת SELECT.
8. מאפשרים לסוכנים לשאול את התפקיד הזה, לא את הייצור.

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

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

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

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

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

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

הוא יכול לשאול שאלות ישירות מול נתוני המוצר:

• שימור משתמשים ל-7 ו-30 ימים
• הפעלה מהרשמה להרצה ראשונה
• שימור מעוגן בהרצה ראשונה
• רדימות ארגונים בתשלום
• מצב מנוי ומעקב נטישה
• שימוש במודל לפי מודל נבחר
• מסלולים מובנים מול מסלולי ספק משתמש
• צריכת משאבים בניסיון
• עלות להרצה לפי מודל
• שיעור כשל ושיעור השלמה לפי קבוצה

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

ה-Morning Brief שלנו מושך מ-Plausible, Axiom, Sentry, Google Ads, GitHub ומקורות תפעוליים נוספים. מסד הנתונים מספר מה עשו משתמשים וארגונים. Plausible מספר מה קרה באתר. PostHog עוזר בהקשר אירועי מוצר. Axiom מספר מה קרה בלוגים ונתיבי בקשות. Sentry תופס שגיאות. Stripe ו-Clerk מסבירים חיוב וזהות. GitHub מראה תפוקת הנדסה.

העניין הוא לא להחליף כל כלי ב-SQL. העניין הוא לאפשר לסוכן לחבר את העובדות שמעניינות את המייסדים באמת.

לדוגמה:

Google בתשלום שלחה יותר תנועה מאורגני אתמול. האם המשתמשים האלו באמת הגיעו להרצה ראשונה, או נעצרו בראש המשפך?

או:

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

או:

המסלול הזה זול יותר להרצה. האם זה בא לידי ביטוי בשימוש צ'אט היסטורי אמיתי, או רק בתיאוריה של תמחור?

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

דוגמה אמיתית: שימור ובריאות משתמשים חיצוניים

אחת מהאנליזות הפנימיות היומיות שלנו בוחנת את בריאות המשתמשים החיצוניים ב-24 השעות האחרונות.

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

משם, הסוכן יכול להפיק דוח תפעולי תמציתי:

• הרצות וארגונים חיצוניים פעילים
• שיעור השלמה
• תמהיל טריגרים בין web, CLI, לוחות זמנים ומסלולים לא-Zero
• תמהיל מודלים
• מצב ספק
• פעילות ארגונים בתשלום
• ארגונים בתשלום רדומים
• הרשמות בתשלום חדשות וארגוני ניסיון
• מעקב נטישה
• סגמנטציה ל-30 ימים
• שימור מהרשמה להרצה
• שימור מהרצה ראשונה

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

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

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

דוגמה שנייה: כלכלת ניצול תקופת ניסיון

נתוני מוצר עם מסכות שימושיים גם לשאלות שאינן תרשימי BI קלאסיים.

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

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

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

לאחר שמנגנון המניעה הופעל, ממוצע המשאבים שנשרפו בשעות הראשונות לאחר ההרשמה ירד ביותר מ-80%. הזנב הכבד כמעט נעלם. באחוזון ה-90, משאבים בשעות הראשונות ירדו מכ-$4.05 לכ-$0.26, ירידה של 94%.

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

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

דוגמה שלישית: עלות מודל במוצר האמיתי

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

כמה עולה המודל הזה במוצר האמיתי שלנו, בהרצות אמיתיות?

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

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

בניתוח שלנו, ל-DS v4 Pro הייתה עלות קרדיט-מודל חציונית להרצת צ'אט שהייתה כ-49% מזו של Sonnet. במילים אחרות, הרצת צ'אט חציונית הייתה זולה בכ-51% במסלול הזה.

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

זה לא תחליף קבוע למחסן נתונים

יש שלב שבו חברה צריכה מערך דאטה פורמלי יותר.

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

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

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

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

התבנית לצוותי מייסדים

התבנית פשוטה:

1. התייחסו למסד הנתונים של המוצר כמקור האמת הראשון.
2. לעולם אל תחשפו ייצור גולמי לסוכנים.
3. השתמשו בענף דמוי ייצור, לא בדאטה לדוגמה שנבנה ידנית.
4. מסכו עמודות רגישות סטטית לפני הגישה.
5. שימרו מזהים אטומים לחיבורים כדי שהניתוח יעבוד.
6. חשפו את הענף דרך תפקיד לקריאה בלבד.
7. אפשרו לסוכנים להריץ את לולאת האנליסט על המסד עם המסכות והכלים הסובבים.

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

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

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

לפני שאתם בונים data lake, שאלו האם ענף עם מסכות ולקריאה בלבד של מסד הנתונים שלכם יכול לענות על 20 השאלות הבאות של הצוות שלכם.

עבורנו, זו הייתה הדרך המהירה ל-BI.

מקורות

• Neon, "Create Environments with Masked Production Data Using Neon Branches": https://neon.com/blog/environments-masked-production-data
• Neon fork of PostgreSQL Anonymizer: https://github.com/neondatabase/postgresql_anonymizer