מערכת AI לאנליטיקת מוצר: הטמעה מקצה לקצה

מדוע אנליטיקת מוצר מבוססת AI נתקעת בייצוא נתונים ידני

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

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

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

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

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

מה משתנה לאחר ההטמעה: מהירות, שלמות, אמון

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

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

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

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

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

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

פורמטים של אנליטיקה: פיילוט, זרימה, קונטור אוטונומי

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

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

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

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

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

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

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

תיעוד, סכמות ותקנונים שנשארים אצלכם

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

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

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

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

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

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

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

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

מה לעשות אם הנתונים כבר פזורים במאגרים שונים?

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

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

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

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

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

ספקות טכניים לפני תחילת הפרויקט

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

מה לעשות אם הנתונים ההיסטוריים חלקיים?

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

האם אפשר להטמיע בשלבים?

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

מי מלווה את המערכת לאחר ההטמעה?

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

נדון במשימה: ממה להתחיל את השיחה

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

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

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

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