גוגל אנליטיקס דחף לי קוד
עונה 2 · פרק 59 · 16:00 ·
יותר מעשרים שנה גוגל אנליטיקס סופר אירועים ומייצר דו"חות שהפסקנו לקרוא. על כלים חדשים שקוראים בעצמם לוגים, צופים בהקלטות ופותחים PR באמצע הלילה.
במשך עשרים שנה בנינו מגדל אנליטיקס ענק של טאגים, קוקיז, אירועים ופאנלים, וכמעט תמיד הוא נגמר באיזה דו"ח עייף, שבן אדם, בשר ודם צריך לשים אליו לב, להבין, ולתקן. הגרף הזה היה המתווך, שאמור להניע אותך לשינוי. עכשיו חברת אנליטיקה לא צעירה בשם PostHog רוצה לחתוך את המתווך, ובמקום שנסתכל על נתונים של אתמול, נתעורר לקוד מוכן, שמתקן בעצמו, את מה שראה והבין בעצמו.
כדי להבין את עולם האנליטיקס צריך לחזור לפורמט ישן CLF או Combined Log Format, בעצם שורות על גבי שורות של לוגים שנכתבו לשרת. בכל שורה היו כתובת IP, שעה, איזה URL ביקשו, עם איזה דפדפן, מה הדף המפנה ומה סטטוס התשובה. תוכנות כמו Analog ו-Webalizer של שנות ה-90 פשוט קראו את הקבצים האלה וייצרו מהם דו"חות HTML. הבעיה הייתה שלוגים של אז נספרו כ-hits, וכל קובץ שהדפדפן מבקש הוא hit - כל HTML, כל תמונה, כל קובץ CSS. עמוד עם עשרים אייקונים הפך ביקור אחד ל-21 hits במקרה הטוב, או ל-0 hits אם הקבצים היו שמורים במטמון.
ב-1995 חברה בשם Urchin ניסתה לשנות את התמונה. הלוגים עדיין נכתבו לשרת, אבל לא לשרת שלך, אלא לשרת שלהם. ב-2005 גוגל קנתה אותה ב-30 מיליון דולר והשיקה מחדש כ-Google Analytics. מוצר חינמי, משולב עם AdWords שרץ משרתי גוגל. ואם תסתכלו מקרוב על כל לינק שיווקי שקיבלתם היום: ה-utm_source וה-utm_campaign בכתובת זה Urchin Tracking Module, זכר לעסקה, אולי הכי משתלמת בהיסטוריה של גוגל.
איך זה עבד בפועל? חתיכת קוד JavaScript שאתם משתילים בכל דף, בעצם סקריפט שרץ בדפדפן של הגולש, יוצר קוקי עם מזהה Client ID ושולח לשרתים של גוגל בקשה קטנה, מעין פיקסל, עם כתובת העמוד, גודל המסך, זמן מקומי ופרמטרים נוספים על הדף והדפדפן. המזהה הזה לא מכיל שם, אבל הוא גם לא היה אנונימי באמת - קבוע מספיק כדי לקשר את כל הפיקסלים של אותו דפדפן. כל חישוב מכל הבקשות האלה: מספר משתמשים, שיעור נטישה, משפכים וייחוס, חושבו מתוך הזרם הגולמי הזה, מדי יום, בשרת של גוגל. ב-Universal Analytics, הגרסה ששלטה ב-web מ-2012 ועד 2023, המודל היה ונשאר hit-based. צפייה בעמוד היא hit, אירוע הוא hit, עסקה היא hit, והכל מקובץ לתוך יחידה מלאכותית שנקראה session, או ביקור, מושג שנקבע שרירותית כ-30 דקות של פעילות.
גוגל אנליטיקס ניתנה אז בחינם סביב עוד מושג - sampling או דגימה. כדי להבין אותו צריך להבחין בין שני סוגים של דו"חות. דו"חות סיכום אגרגטיביים (למשל משתמשים יומיים לפי מדינה, שעה או מערכת הפעלה). דו"חות שנשענו על טבלאות שחושבו מראש, ולכן היו מהירים, זולים ולא דגומים, אבל גם הקפיאו את השאלות: יכולת לשאול בעיקר את מה שמישהו בגוגל החליט מראש שכדאי לחשב. ברגע שביקשת דו"ח חופשי, למשל סגמנט מסוים או מימדים נוספים, המערכת הייתה צריכה לחזור למידע הגולמי, ואם היו יותר מ-500 אלף sessions, היא לא עברה על הכל. היא לקחה מדגם, חישבה עליו, וניפחה את התוצאה חזרה לגודל האוכלוסייה. מי ששילם על גירסת 360 קיבל סף של 100 מיליון sessions, כלומר דיוק כפיצ'ר בתשלום.
דגימה היא לא רעיון רע בפני עצמו, אבל נשברת בדיוק במקום שבו הכי צריך אותה. מדגם לא מפספס מגמות גדולות כמו "התנועה מפייסבוק ירדה", אבל ככל שחותכים ומנתחים סגמנט קטן יותר, הוא מייצר טווח טעות ענקי. גוגל הציגה את טווחי הטעות האלה, אבל לא תמיד ולא בבירור, מה שגרם לאנשים לקבל החלטות תקציביות על מספרים שהם אומדן.
"חצי מהכסף שאני מוציא על פרסום הולך לפח, אבל אני לא יודע איזה חצי". הדבר השני שאנליטיקס קלאסי אמור היה לפתור הוא attribution, ייחוס: מי מקבל את הקרדיט על המכירה. הדו"חות הסטנדרטיים של גוגל ייחסו הכל לפי last non-direct click: מאה אחוז מהקרדיט שוייך למקור שיווק האחרון. זה פשוט, אבל גם מוטה באופן מובנה לטובת מי שתופס את הלקוח ברגע האחרון, חיפוש ו-retargeting, בדיוק המוצרים שגוגל מוכרת. גוגל אנליטיקס תמכה במודלים אחרים (first-click, linear ו-time-decay) אבל החביאה אותם יופי יופי עד להעלמתם ב-GA4. היא עברה מאז למודל data-driven, מעין קופסה שחורה שמחליטה כמה קרדיט מגיע לכל פרסומת. אני לא אומר שהמודל משקר, רק שאף אחד מחוץ לגוגל לא באמת יכול לבדוק אותו.
המהפכה הראשונה הגיעה מסטארטאפים שהבינו שהשאלה "כמה ביקורים היו לנו מפייסבוק" כבר לא מעניינת אף מנהל מוצר. ב-2009 מיקספאנל התחילה לספור פעולות בעמוד ולענות על שאלות מורכבות: "מתוך מי שהוסיף מוצר לעגלה, כמה שילמו תוך שבעה ימים, עם אימייל שונה מג'ימייל". היו גם Amplitude ו-Heap, חלוצות ה-autocapture, בעצם אל תבקשו מהמפתחים להגדיר מראש כל אירוע, תנו לנו להקליט הכל מראש, ותגדירו את האירועים בדיעבד, וגם Segment - שהבטיחה לא רק למדוד אלא גם לפזר את אותו זרם אירועים לכלים נוספים. זו מהפכה כפולה, היחידה הבסיסית עברה מ"ביקור" ל"פעולה", ואיתה - יכולת לתשאל את כל הפעולות האלה, תוך שניות, בלי דגימה אבל בעלות יקרה מאוד.
גוגל הגיבה באיחור אופייני עם GA4 ב-2020. מעין שעטנז על Firebase Analytics. ב-2022 היא יזמה מעבר לאנליטיקס שבו כל דבר, גם צפייה בעמוד, הוא אירוע עם פרמטרים. היא לא ויתרה על הדגימה - כל דו"ח עם יותר מ-10 מיליון אירועים נדגם, אבל היא נתנה אפשרות לייצא את המידע לשירות BigQuery. זה מהלך מאוד גוגלי, להכניס את משתמשי החינם לתוך GCP, הענן שלה. אפשר להתווכח על הממשק של GA4, וכן הוא גרוע, אבל ברמת הקונספט גוגל פשוט הודתה ש-Mixpanel צדקה עשר שנים קודם.
ובזמן שהכלים השתכללו, המידע עצמו התחיל להישחק. מעל 30% מהגולשים משתמשים בחוסם פרסומות, שחוסם גם פיקסלים של מעקב. ה-GDPR שנכנס לתוקף ב-2018 חוסם גם הוא מעקב מגולשים שלא אישרו קוקיז וגם הדפדפן ספארי, מאז 2019, מגביל קוקיז שנכתבים על ידי JavaScript, כלומר בדיוק הקוקיז של טאג קלאסי, ל-7 ימים. התעשיה ניסתה לעבור ל-server-side tracking, ובמקום שהדפדפן ידבר ישירות עם google-analytics.com, הוא שולח פיקסל לשרת או לסאב-דומיין שלכם, מהלכים שנחסמו ברובם ע"י ספארי וחוסמי פרסומות מתקדמים.
וכך, המספרים בדאשבורד חזרו להיות הערכה, וכל פעם מסיבה אחרת: hit ספר את היחידה הלא נכונה, session הייתה קונבנציה שרירותית, דגימה הייתה אומדן סטטיסטי, ייחוס השתמש במודל מוטל בספק, ומשתמש שלא רצה להיספר גרם לחור במדידה, אבל גם כשהמספר נכון, נשארה בעיה שאף טכנולוגיה לא פתרה: מישהו צריך להסתכל עליו.
ג'יימס הוקינס וטים גלייזר הקימו את PostHog ב-2020, קודם כל שיהיה קל יותר להסתכל על המספרים, אבל במידה רבה כי לא רצו לשלוח אותם לגוגל. היא חינמית ל-97% מהמשתמשים שלהם שמקבלים free-tier נדיב למוצרים של PostHog. לא מוצר בודד אלא אוסף. בנוסף לאנליטיקס בסיסי יש product analytics שמראה trends, funnels, retention ו-paths בתוך המוצר. יש session replay ו-heatmaps שמציגים הקלטות ולחיצות של אנשים אמיתיים. יש data warehouse שמושך מידע מ-HubSpot, Google Ads ו-Stripe, עם שפת שאילתות בשם HogQL שרצה על ClickHouse, מסד נתונים עמודתי שמאפשר באמת לסרוק הכל בלי דגימה. יש feature flags וניסויים שאפשר לתזמן מתוך הממשק וגם error tracking, לניטור exceptions בדפדפן וקריסות באפליקציות מובייל. למה הריכוז הזה חשוב? כי ברגע שאתה מצליח לחבר את הקליק, ההקלטה, השגיאה בקונסול, ואת ה-flag שהיה דלוק אצל המשתמש, יש לך לראשונה את רוב ההקשר במקום אחד.
אבל אלו רק הברזלים. PostHog הרימו מעליהם שכבה של AI, ראשית chat with your data - עוזר אישי שכותב ומתקן HogQL כולל joins מורכבים למערכות חיצוניות, בונה insights ודאשבורדים שלמים, יוצר ניסויים והתראות, עורך פילטרים בממשק, מוצא הקלטות, וצובר knowledge על המוצר שלכם. טים גלייזר, ה-CTO אמר בעצמו "לבנות גרפים עם ה-AI שלנו היא חוויה הרבה יותר טובה מלנסות ליצור אותם ביד".
יש גם תמיכה מלאה ל-API ו-MCP, פרוטוקולים שדרכם סוכני קוד (כמו Claude Code או Codex) יכולים לשלוט בכל מסך הגדרות ב-PostHog, לייצר משתמשים ודו"חות. האנליטיקס בעצם עובר מהמסך שלכם, המסך של PostHog לתוך הסוכן. זו לא החלטה קלה למייסדים של שום כלי, אבל ככה העולם עובד היום. כלים שלא מאפשרים ניהול ע"י סוכנים פשוט ייעלמו כי האנשים שמפעילים סוכנים כאלו מצפים להם.
השכבה השנייה של AI מטפלת בניתוח. למשל, יש לכם עשרות אלפי הקלטות של סשנים, כולל בקשות הרשת שהרכיבו אותם, אבל אתם צופים אולי בעשר. עם Replay Vision הווידאו נשלח למודל Gemini של גוגל, שיודע לסרוק, לדרג סשנים לפי תסכול, לסווג מה המשתמש ניסה לעשות וגם לסכם. מערכת, שמסתכלת על מסך מרונדר יכולה עכשיו לתפוס באגים שקטים במיוחד, כמו spinner שלא נגמר וכפתור שרק נראה לחיץ.
השכבה השלישית היא כבר קפיצת מדרגה. פיצ'ר ה-self-driving יודע לאסוף signals מכל PostHog, כולל מקורות חיצוניים (כמו PagerDuty, סלאק, Linear ו-30 אחרים), לנטר אותם ולהצליב לדו"ח. כשהדו"ח הזה עובר סף (למשל אם הוא ב-hot path כמו checkout, או משפיע על רף הכנסות או מספר משתמשים), סוכן מחקר שרץ על Claude Agent SDK בסנדבוקס, עם ה-MCP של PostHog וגישה לקוד, בודק אם הוא פתיר אוטומטית. אם כן, סוכן מימוש משכפל את הריפו, פותח branch, כותב תיקון וטסטים ודוחף PR או בקשה למיזוג קוד. וזה, מחזור כמעט שלם של detect, diagnose, fix ו-verify, שבו התפקיד היחיד שנשאר לבן אדם הוא ללחוץ merge.
האם זה סוכן ה-on-call המושלם? לא יודע. הוא כן עושה מה שתורן אנושי יעשה בשלוש בלילה - מקבל התראה, פותח לוגים, מחפש איזה deploy התחיל את האירוע, מנסה לשחזר, מנחש, ועד הבוקר כותב דרישה או מעיר צוותים אחרים. זו כן קפיצה מסוכן שמייעץ, לסוכן שמאבחן וסוכן שעושה, והקפיצה מהרמה השנייה לשלישית היא הקפיצה האמיתית, כי שם הסוכן מפסיק לייצר מידע ומתחיל לייצר שינויים במערכת שלכם, וככל שהוא מתקדם בשרשרת גדל גם היקף ההרשאות שהוא צריך וגם היקף הנזק האפשרי.
אגב PostHog בעצמם כותבים שה-self-driving הוא בעיקר ל"מצב תחזוקה": תיקוני באגים, flows שבורים, פערים במדידה, ועבודות אופטימיזציה שאין לאף אחד ראש אליהם. self-driving "לא ימציא לכם חזון מוצרי או יתקן לכם אסטרטגיה". וזה לא ש-PostHog מתקנים את הבאג. בסוף זה Claude Code מתקן את הבאג, בדיוק אותו סוכן שמתכנת היה מפעיל. PostHog אחראית רק לאיסוף ה-context, וככל שהוא מדויק יותר, הסוכן יתפקד טוב יותר.
אני אגיד כמה דברים על אבטחה. אם אני מבקר באתר שלכם כתוקף, אז יש לי היום יכולת לעשות prompt injection ל-context הזה ע"י יצירה של הודעת שגיאה, מילוי טפסים והקלדת טקסט בעייתי, והקלט הזה ייכנס כ-signal לצינור של self-driving, שבסופו יש סוכן עם גישה לריפו שלכם (מאוד דומה ל-Log4Shell מ-2021). PostHog בוודאות מנסים לפתור בעיות כאלה עם מסווג LLM בראש הצינור לזיהוי סיגנלים זדוניים, כלומר הם מגינים על מודל שפה באמצעות מודל שפה אחר. זו הגנה הסתברותית, לא קיר בטון. הבטון צריך להיות הרשאות מצומצמות, למשל sandbox בלי יציאה לרשת, בלי אפשרות להשפיע על ה-CI או על שרשרת ההפצה (אגב ב-2025 ספריות של PostHog עצמה נפרצו ע"י תולעת זוללת סיקרטים).
וכשסומכים על ספק לאורך כל השרשרת, צריך לשאול גם שאלה פשוטה. ממה הוא מרוויח? self-driving מתומחר לפי $15 ל-PR. שלושה ראשונים בחינם, ואם ה-PR לא שווה כלום, יש החזר. PostHog הלכה על תמחור לפי תוצאה, אבל PR הוא תוצר ולא תוצאה: אפשר לקבל שינוי קוד שעובר את כל הבדיקות, אבל לא פותר את הבעיה שבגללה התחלנו, לכן היא בודקת אם המדד, ה-KPI, הגרף, באמת זז לכיוון הנכון, וזה מנגנון ריסון אמיתי בשבילה. ועדיין, כשהמודד, המאבחן, המתקן והגובה הם אותה חברה, אנחנו חוזרים לניגוד העניינים של Google Analytics מ-2005: ספק שסופר את התוצאה של הפרסום שמכר לכם. יש גם חזרה לתוכניות מוקטנות - אם פעם המיחשוב או ה-storage היה יקר, היום אלו טוקנים של מודל שפה גדול, וצריך להשתמש בהם במשורה, או לשלם.
בשנתיים האחרונות דיברנו על ההבדל בין AI שמספר לבין AI שעושה. אני מניח שעד סוף 2027 פתיחת PRים מתוך סיגנלים בפרודקשן תהיה פיצ'ר סטנדרטי אצל כל ספק observability ואצל חלק גדול מספקי האנליטיקס. PostHog ו-Sentry כבר שם, Datadog בדרך, במיוחד בשגיאות ריצה, שהן ספציפיות מספיק כדי שסוכן יצליח.
אנליטיקס מעולם לא היה רק מספרים, אלא ניסיון לקצר את המרחק בין משהו שקרה למשתמש לבין משהו שאנחנו עושים בעקבותיו. השלבים בהיסטוריה שלו (מלוגים, ל-SQL חופשי ודאשבורדים שבונים את עצמם) קיצרו את המרחק הזה. self-driving הוא הקיצור האחרון והקיצוני ביותר, כי הוא (כמעט) סוגר את הלולאה ומשאיר לבן אדם רק את הלחיצה הסופית. זה מצויין למערכת שעובדת מושלם, אבל מטריד כמעט כמו מאמר "האירוניה של האוטומציה" מ-1983: ככל שמערכת אוטומטית אמינה יותר, כך האדם שאמור להשגיח עליה מתאמן פחות, ולכן פחות מסוגל להתערב בדיוק ברגע הנדיר שבו היא נכשלת. אם במשך שנים לא נפתח את הדאשבורד, לא נראה visit, לא נראה פיקסל, לא נראה log, כי התרגלנו לראות PR מוכן, האם נדע לזהות את היום שבו הסוכן טעה נחרצות?
עד הפעם הבאה, תהיו טובים, ותמשיכו להיות סקרנים. יאללה ביי.