מה עושים כשאתה פאבלישר מדיה ענק בישראל, יש לך כמה אתרים, אפליקציות מובייל, אפליקציית טלוויזיה וכולם מבוססים על טכנולוגיות שונות וספקים שונים ומליוני צופים – וכל מה שאתה רוצה לדעת זה את הרייטינג ולנתח את נתוני הצפייה?
ברוכים הבאים לאחר הפרוייקטים הכיפים והמספקים שהיו לי השנה, המיגרציה המורכבת של "כאן – תאגיד השידור" לגוגל אנליטיקס 4 והדשבורד המתוחכם שבא מיד אחריו.
אבל תחילה, תודה לתמיר כהן, ראש אגף מוצרים והפצה וסגן מנהל חטיבת הדיגיטל, ולניר כימיה, מנהל המוצר ב"כאן" שעבדתי איתם על הפרוייקט ההו כה מורכב ומתגמל. הייתם עשר!
כשנפגשנו בהתחלה, ב"כאן" פרשו את האתגרים הקשים לקראת השדרוג. חלק מהם נבעו מריבוי אתרים שעדיין עבדו עם יוניברסל על פני דומיינים שונים ואפליקציות שונות, המון legacy stuff וחוסר אחידות. הרצון היה לעשות "ניקוי בית" יסודי. לא לעשות שדרוג פשוט אלא לחשוב קדימה ולעשות את זה כמו שצריך, ב"מכה אחת". איך ניגשים לזה? מהסוף להתחלה.
וככה נראה הסוף (תמונה חלקית):
לצוות ב"כאן" יש את האפשרות לבחור נתוני "אתמול" או טווח תאריכים אחר, לבחור אם רוצים נתוני VOD/AOD או שידורים חיים, או בכלל באילו כתבות תוכן צפו.
תחת ה VOD אפשר לבחור תוכנית/עונה/פרק/שעה ולראות יוניקים צפו, כמה לחצו על play, כמה צפו בדקה או יותר ומה חישוב זמן הצפייה הכולל. מעבר לזה יש עוד גרפים, trendlines למיניהם, pie charts צבעוניים ועוד חישגוזים שקצרה היריעה מלהציגם.
קביעת יעדים
ב"כאן" רצו שכל הפלטפורמות ידברו בשפה אחת. על פניו זה נשמע קל אבל אתרי ה Web משתמשים בנגן הוידאו של Kaltura, אפליקצית המובייל רצה על מנוע של Applicaster שאורזת למעשה את הגרסה הוובית, ואפליקציית הטלוויזיה (Kan Box) רצה על מנוע של חברת 24i ההולנדית. בין לבין יש גם את נגן האודיו של Omny שמטפל בפודקאסטים וקטעי האודיו השונים. ומאחורי הכל יש את מערכת ניהול התוכן של "כאן" שמחזיקה את כל המידע ומתוחזקת בין היתר ע"י חברה חיצונית. חתיכת סלט.
מערך המדידה היה צריך לתמוך בסוגי התכנים הבאים:
- תכני טקסט (כתבות) – כולל שם הכתבה, שם הכתב, קטגוריות, מילות מפתח וכו'.
- תכני VOD – שם תוכנית ("קופה ראשית"), שם פרק ("כוכבה משדרגת ל GA4"), מספר פרק ומספר עונה.
- תכני AOD – תוכנית ("חיות כיס"), עונה (אם יש), שם פרק ("שאול מגלה את עולם הלק ג'ל") וכו'.
- תכני Live – האזנה לערוצי רדיו וצפייה בשידורים חיים.
בשלב הזה צריך להזכיר שכל המדידה הזו לא כוללת מנוע צפייה אחד חשוב ומשמעותי – הצפייה הלינארית שלא נעשית דרך אפליקציות של "כאן". כלומר כשאתם צופים בשידורי "כאן" דרך עידן, סלקום TV, פרטנר TV וכיו"ב. אותו כנ"ל יוטיוב שהוחרג בשלב זה.
אבל כדי שלא יהיה משעמם, ב"כאן" הוסיפו דרישה חשובה לא פחות. חישוב רייטינג. כלומר, כמה זמן צפו בכל התכנים האלה.
תוכנית עבודה
אז איך מתחילים פרוייקט כזה? הנה המתודלוגיה לפניכם.
- הכרת הפלטפורמות הטכנולוגיות המשתתפות במשחק. איסוף דוקומנטציות רשמיות ושיחות עם הספקים השונים.
- מיפוי כל השדות החשובים והאוונטים שהפלטפורמות מייצרות, ואופן שליחת הנתונים ל GA4.
- יצירת מסמך הרמוניזציה (מת על המילה הזו) – אותו מסמך שבו יש סוג של מילון שמתרגם את כל הפלטפורמות השונות לשפה אחת. פה יהיה רשום שכשיוזר מפעיל וידאו, פלטפורמה אחת קוראת לזה video_start ואחרת video_play.
- תכונן הלוגיקות והחישובים שאדרש לבצע בדגש על חישוב זמני צפייה.
- כתיבת תוכנית ההטמעה בפועל וההבנה איך בדיוק GA4 ישתלב בעניין ובאיזה פיצ'רים נצטרך להשתמש.
כך או כך – היה ברור שבתהליך ההרמוניזציה לקראת הדשבורדים, אצטרך להשתמש בהרבה custom dimensions שיחזיקו את כל המידע המאפיין את פרטי המדיה (עונה, פרק, תוכנית וכו') וכל השאבאנג הזה צריך לזרום ל BigQuery ושם יתרחש הקסם שמדביק את הכל. כמו שאפשר לראות – הרבה עבודת אפיון והכנה לפני התכל'ס.
הפלטפורמות הטכנולוגיות המשתתפות במשחק
כל אחת מהחברות שציינתי מקודם – אפליקסטר, קלטורה, 24i – מחזיקות את התוכן ואחראיות להצגה שלו (אם הוא תוכן טקסטואלי), או לניגון שלו (אם זה VOD/AOD או שידור חי), אבל השליטה שלנו על האופן בו הדאטה נשלח מוגבלת. לכל חברה יש קריטריונים שונים מה זה Play, איך קוראים לאוונט בדיוק, מתי הוא נשלח וכיו"ב, וללקוח (כלומר ל"כאן") לא תמיד יש say בעניין. חברות טכנולוגיה מספקות את צרכי המדידה באופן גנרי לכמה שיותר לקוחות, ומשתדלות ככל האפשר להמנע מקסטומיזציות ייעודיות ללקוח. (בהזדמנות אני אכתוב איך זה להרים כלי מדידה לתוכנות שישרתו את כלל הלקוחות. זו הרפתקאה מרתקת בפני עצמה.)
קחו דוגמא: החבר'ה ב 24i שאחראים על אפליקציית ה Box לטלוויזיה החליטו ליישר קו עם הסטנדרט של GA4 ולשלוח אוונטים של מעקב אחרי וידאו בדיוק לפי התיעוד הרשמי וזה עובד באמצעות Measurement protocol.
קלטורה הציעו להשתמש בספריית ה open source שמדווחת אירועים ל Google Tag Manager במקום להשתמש במדידה במובנית בתוך הנגן, ואפליקסטר הציעו סט ענק של אוונטים עם שמות משלהם שנשלחים ישירות ל GA4 באמצעות כלי "מתורגמן" שיושב במערכת הניהול שלהם והדאטה בכלל נשלח ל Firebase. כשמציירים את זה, זה מתחיל לקבל צורה:
מה רואים בתרשים?
חלק א' (למעלה) – אפשר לראות שאפליקציות המובייל (iOS/Android) מנוהלות על ידי Applicaster, שואבות נתונים מה CMS של "כאן" (שמכיל את המידע המאד חשוב של מספר פרק, עונה, ומאפיינים נוספים) עם נגן הוידאו של קלטורה ונגן האודיו של Omny.
המערכת של Applicaster אורזת את הכל כאפליקציה עם ה SDK של Firebase ושם נוצרים כל האוונטים. לשמחתי Applicaster נותנים ל"כאן" ממשק שמאפשר להם לשלוט בחלק מהאוונטים ולהעשיר את המידע שנשלח. כלומר, כשצופה לוחץ על PLAY נדע לא רק את הפעולה עצמה, אלא גם את שם הפרק, העונה וכו'. מידע שמגיע מה CMS בכלל ושאפליקסטר דואגים שיתגלגל הלאה.
חלק ב' – האתר עצמו, מכיל את הנגן של קלטורה ופה הייתה צריכה להתבצע עבודת הטמעה "ידנית" עם Google Tag Manager, אבל מאיפה הוא יקבל את המידע? הנגן של קלטורה צריך לשלוח לו מידע על התוכן שנטען ועל הפעולות של היוזר. לשמחתנו Kaltura שחררו ל GitHub ספרייה עשירה מאד של פקודות שהם יכולים לירות ל dataLayer. בנוסף לזה, ה CMS של "כאן" יודע להגיד כל פעם שנטען דף עם פרק כלשהו, איזה פרק זה, עונה וכו'. כנסו לאתר של כאן, בחרו פרק ב VOD ונגנו אותו. אם יש לכם analytics debugger, אתם תראו את כל המידע שעובר הלאה ל GTM על כל הפעולות שמתרחשות בנגן. רוב האוונטים האלה נורים על ידי Kaltura באמצעות הספרייה המיוחדת שלהם:
וככה זה נראה כשזה יוצא ל GA4 אחרי שמועשר על ידי המידע מה CMS:
אפשר לראות את כל ה Custom dimensions שמכילים את שם הפרק, התוכנית, מספר עונה וכו'. בהמשך, אפשר לקחת את המידע הזה ו"להדביק" אותו לפעולות של הנגן. אם מישהו לחץ על Play אפשר לדעת איזה פרק זה היה וכו'.
חלק ג' – אפליקציית BOX, שואבת את הנתונים מ ה CMS אבל שולחת את הדאטה ישירות ל GA4 באמצעות ה Measurement protocol. אין Firebase ואין שום דרך להתערב באמצע. מה שיש זה מה שיש.
יצירת Custom dimensions והטמעות
כדי לתמוך בכל המטא-דאטה (שם פרק, עונה וכו'), נתתי ל Firebase לקבוע את הטרמינולוגיה של כל ה custom dimensions ולאחר מכן האתרים שלחו את הדאטה לאותן שדות. עם זאת, אפליקציית הטלוויזיה, בגלל מבנה הנתונים המיוחד שלה, שולחת דאטה לחשבון נפרד עם שדות שונים. את "התרגום" וההתאמה בין שני העולמות האלו, ביצעתי בשאילתות עצמן ב BigQuery.
שימו לב, עבודת ההטמעה בפועל התחילה רק אחרי כל תהליך החשיבה והתכנון. היה ברור מה הולך לאן, ואיך זה יראה בסוף. זה שלב קריטי כדי להצליח לעשות את הכל במכה אחת.
אורזים את הכל
אחרי ההטמעה הטכנית, חיברתי את כל החשבונות ל BigQuery, והדאטה התחיל לזרום. לשמחתי, ב BigQuery ניתן לבצע שאילתות מכמה חשבונות שונים במקביל וצללתי לשלב ה SQL. לשמחתכם, אני לא אכנס לשאילתות עצמן כי זה שיעמום של SQL מסובך, אבל אני כן אתייחס לכמה נקודות חשובות בפרוייקט הזה:
- עבור כל פלטפורמה (אפליקציה, אתר, BOX), יש שאילתה שרצה על נתוני האתמול, מעבדת את הנתונים ו"מתרגמת" אותם לשפה חדשה, המשותפת לכל מקורות המידע. את הנתונים הסופיים, מעבירים לטבלה שטוחה ופשוטה לניתוח שמכילה עבור כל "פרק" את כל הפעולות שבוצעו עליו. למשל בטבלה יש שורה אחת של קופה ראשית, עונה 5, פרק 2, שעה 5 בבוקר, ושם פלטפורמה (אתר, אפליקציה..) עבור השורה הזו יש נתוני צפייה מצטברים – כמה התחילו צפייה, מה זמן הצפייה המצטבר וכו'. השאילתות דרשו fine-tuning בכמה וכמה סבבים עד שהתוצאות היו טובות. זה לא פגע במכה הראשונה והיה צורך לבדוק כל הזמן מול ה Raw data ולעשות חישובי סנדלרים ואקסלים כדי לוודא שמה שהשאילתה מוציאה אכן make sense. זה השלב הכי קשה בפרוייקטים כאלה. להוכיח שהשאילתה "צודקת", וככל שיש יותר עיניים על התהליך – יותר טוב.
- נתוני realtime ב BigQuery. שימו לב, שכשעוברים מליון אוונטים ביום, הסנכרון היומי (Daily) של GA4 עם BigQuery מפסיק לעבוד (מקבלים התראה). עם זאת, אם הפעלתם את הסנכרון גם של ה Realtime – הדאטה ממשיך להגיע לטבלאות realtime. אני ממילא תשאלתי רק את נתוני אתמול, אז לא דאגתי יותר מדי.
- לא הטמעתי את כל האתרים במכה אחת. עברתי אתר אתר, פלטפורמה פלטפורמה. התוכנית לטווח הארוך כבר הייתה כתובה, אבל כדי לאפשר לי סביבה סטרילית ככל האפשר לדיבוגים, העדפתי לשדרג פלטפורמה אחת, לראות שהדאטה תקין, לכתוב את השאילתות, לחכות לנתונים, להעלות אותם על הדשבורד, לראות שהמספרים make sense, ואז לצרף את האתר הבא. בתצורה הזו גם "כאן" קיבלו תוצרים חלקיים מצטברים. במקום להמם אותם בבלוק של נתונים מכל הפלטפורמות עם קושי בדיבוג, החלוקה לשלבים הייתה במובן מסויים בריאה יותר לתהליך. הנה נתוני האתר בלבד, ננתח אותם כמה זמן ועוד שבוע נצרף גם את נתוני ה Box וכן הלאה. אנשי הפיתוח שביניכם מכירים את זה כ Iterative development או סוג של Continues integration. מעבר לזה, יש עוד בונוס חשוב – זה מראה ללקוח על התקדמות הפרוייקט.
- חישוב זמני הצפייה היה מסובך כי ל Applicaster יש נתונים בתצורה אחת שמצריכים חישוב מסוג אחד, ל 24i שיטה אחרת לגמרי וב Kaltura צריך לחשב לבד, כדי להגיע לזמן הכי מדוייק שניתן, ברמת האייטם הספציפי. מעבר לזה, חלק מהפלטפורמות שולחות נתונים בשניות וחלק בדקות. אז יש פה הרבה נוסחאות וטריקים חמודים אבל בסוף צריך להציג מספר אחד.
- טיוב נתונים – כשהנתונים התחילו לזרום ל BQ ובהמשך לדשבורד, התחילו לצוץ כל מיני אנומליות מוזרות. מספרים שקפצו לשמיים או התאפסו, תווים מוזרים שהגיעו וכל מיני. זה כמעט שלב מנדטורי בפרוייקטים כאלה. שלב טיוב המידע. קשה מאד לראות את הנתונים החריגים האלה מבעוד מועד, ודווקא ההשפעה שלהם בתוצאה הסופית ישר מצביעה על האשמים. פעם זה משך פרק שהוזן ל CMS בשניות במקום בדקות (או ההיפך), פעם זה זמן שחסר או מספר עונה שלא מופיע וכו', והרבה NULL-ים יתומים שקופצים מדי פעם. לאט לאט לאחר טיוב הנתונים הבנו מאיפה הפערים יכולים להיווצר ועכשיו צריך לדאוג שהמקרים האלה לא יחזרו שוב.
- תיעוד תיעוד תיעוד – התיעוד תמיד חשוב אבל הפעם במיוחד. אנליטיקס במערכות מורכבות הוא טריקי ומסובך. התיעוד מאפשר לאנשים חדשים להרים מכסה מנוע ולהבין מיד איך המנגנון עובד. זה אומר איך קוראים לשאילתות, מה הלוגיקות מאחורי הקלעים, איך הדאטה נשלח ונשמר וכו'. אגב, התיעוד חשוב גם לי, לא רק ללקוח. לא תמיד מתאפשר לכם לעבוד על פרוייקט ברצף. כדי לחזור לעניינים, פשוט חוזרים למסמך התיעוד ונזכרים מה עשיתים לפני חודש. במיוחד אם יש פתאום באג.
- ונקודה אחרונה וחשובה מאד! הפרוייקט לקח המון זמן. לא שעות עבודה, אלא זמן קלנדרי. כל שינוי, טיוב, בדיקה, זה עוד יום ועוד שבוע שעבר בהמתנה לנתונים או תיקונים בקוד, או בכלל העלאת תיקון לאפליקציה וסתם לחכות לספרינט הבא. עם זאת, היינו נחושים והצוות ב"כאן" היה סבלני עד כמה שאפשר (תודה לכם!), ועקב בצד אגודל הגענו לסיום המיוחל. ארוך אבל סופר מתגמל. איך כוכבה אומרת:
