הזרקת פרסומות בצד השרת

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

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

סקירה מהירה

הבעיה העסקית

כל הפסקת פרסומות בערוץ FAST היא אירוע הכנסה. הערוץ פולט סמן שאומר "פרסומת תוצג כאן, היא תימשך 30 שניות, אנא היכונו." מערכות במורד הזרם — Google Ad Manager, AWS MediaTailor, שרתי פרסומות אזוריים, SDKs של נגני טלוויזיה חכמה — קוראות את הסמן הזה ומחליטות מה להכניס.

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

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

מהו SCTE-35 בפועל (גרסת 90 השניות)

SCTE-35 הוא תקן להכנסת הודעות סימון (cue messages) לזרם וידאו. הסימונים אינם נושאים תוכן פרסומי; הם נושאים אותות — "הפסקת פרסומות מתחילה כאן", "הפסקת פרסומות מסתיימת כאן", "קטע זה באורך N שניות." המערכת במורד הזרם קוראת את האותות הללו ופועלת לפיהם: שכבת SSAI משלבת קריאייטיב פרסומת אמיתי למניפסט HLS, נגן טלוויזיה חכמה מפעיל שכבת-על, שרת פרסומות רושם הזדמנות לשבץ.

שתי צורות סימון חשובות עבור מקרה השימוש שלנו:

• SpliceInsert — סימון ה-SCTE-35 המקורי. נושא `SpliceEventId`, משך זמן בשניות, ודגל "מחוץ לרשת". רוב שרתי הפרסומות הקלאסיים קוראים זאת.
• TimeSignal — סימון חדש יותר, אקספרסיבי יותר. נושא `SegmentationDescriptor` עם `SegmentationTypeId` (52 = תחילת פרסומת של ספק, 53 = סיום פרסומת של ספק) ו-`SegmentationDuration` ביחידות 90,000-tick. מערכות SSAI ונגנים מודרניים מעדיפים צורה זו מכיוון שהיא מתחברת באופן נקי בין התחלה לסיום.

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

למה זה חשוב. יישום נאיבי פולט `SpliceInsert` אחד לכל הפסקת פרסומות ורואה בכך סיום. הפסקת הפרסומות פועלת בנגנים מדור קודם ונכשלת בשקט ב-SSAI. חצי ממלאי הפרסומות שלך ממונף; חצי לא. לא תדע איזה מהם עד שמספרי ההכנסות שלך יגיעו נמוכים.

למה גישות נאיביות נכשלות

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

• "בזמן הקידוד, הכנס פרסומות לווידאו המקורי." אין מקום לגמישות. המפעיל לא יכול לבצע בדיקות A/B על מיקום, לא יכול לשנות פרסומות לאחר פריסה, לא יכול להריץ פרסומות אזוריות או ממוקדות קהל. כל הסיבה לקיומם של ערוצי FAST היא מונטיזציה של אותו תוכן בדרכים מרובות — שריפת פרסומות בזמן הקידוד סוגרת את האפשרויות הללו.
• "השתמש בהזרקת פרסומות בצד הלקוח." חסימת פרסומות פשוטה. נתיב קוד שונה לכל מכשיר. ללא פרסונליזציה בצד השרת. וזה עוקף SSAI לחלוטין, מה שאומר CPMs נמוכים יותר.
• "פשוט פלוט `SpliceInsert` אחד לכל הפסקה." הטעות הנפוצה ביותר בייצור. עובד על חלק מהנגנים, מתעלמים ממנו בשקט על ידי מערכות SSAI שדורשות סימוני `TimeSignal` להתאמת התחלה/סיום. מונטיזציה חלקית, ללא שגיאה לחקור.
• "בטא הכל ב-90 kHz ticks כי המפרט מזכיר אותם." המפרט מעצבן יותר מזה. `SpliceInsert.Duration` הוא בשניות. `SegmentationDuration` הוא ב90 kHz ticks. ערבובם מייצר סימונים שעוברים אימות סכימה ונשלחים החוצה, ואז נכשלים בנגן כמשכי זמן מעוצבים באופן שגוי. המקודד לא יתפוס זאת. הנגן פשוט ידלג על ההפסקה.
• "אפשר ל-MediaLive לאשר." היא לא תעשה זאת. MediaLive מקבלת הפסקות חופפות, הפסקות באורך אפס, ומשכי סגמנטציה בלתי אפשריים ללא תלונה. האישור צריך להתקיים לפני ש-MediaLive רואה את הפעולה.

המנוף שהיה לנו הוא הגבול שבין ממשק המשתמש של המפעיל — שבו הפסקות הפרסומות הן פשוט זוגות `{position, duration}` — לבין לוח הזמנים של MediaLive, שבו כל סימון חייב להיות מושלם.

הפתרון שלנו

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

תרשים 1 · צינור הזרמת סימוני פרסומות מקצה לקצה

ארכיטקטורה

• עורך הפסקות פרסומות ב-Frontend — מפעילים מוסיפים הפסקות פרסומות לכל תוכנית על ידי ציון היסט מיקום (שניות מתחילת התוכנית) ומשך זמן (שניות). חריצי הבאמפר (bumper slots) הם חלק ממודל הנתונים ומוכנים לשכבת ה-playout.
• קולקציית AdMarker (MongoDB) — מסמך אחד לכל תוכנית עם הפסקות פרסומות, המפנה לווידאו. מערך ה-`adBreaks[]` מאחסן `{position, duration}` כאשר Mongoose אוכף `10 ≤ duration ≤ 120` בזמן השמירה. באמפרים נושאים הפניית `adBreakId` להתאמה במורד הזרם.
• NestJS backend (`schedule.service.ts`) — בזמן הפריסה, מצטרף כל לוח זמנים ל-`AdMarker` שלו ומשנה שמות שדות לחוזה של ה-Lambda (`position` → `offsetSeconds`, `duration` → `durationSeconds`). שליפה אחת בכמות גדולה, ללא N+1.
• מנהל ה-Lambda (`fastChannel-lambda-fun/index.js`) — בבעלותו תרגום SCTE-35. עבור כל הפסקת פרסומות, פולט את מארז שלושת הסימונים לאותו `BatchUpdateScheduleCommand` הנושא מתגי קלט וסימני מים. שמות הפעולות מדורגים לפי תוכנית כך שהניקוי (orphan sweep) יכול להתאים אותם לאחר פריסה חלקית.
• AWS MediaLive — מקבל את הפעולות, פולט סמני `#EXT-SCTE35` במניפסט ה-HLS בשנייה שנבחרה על ידי המפעיל.

החלטות הנדסיות מרכזיות

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

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

תרשים 2 · מחזור חיים של הפסקת פרסומות בודדת

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

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

2. שני בסיסי זמן, מתואמים בפונקציה אחת

SpliceInsert.Duration הוא בשניות. `SegmentationDuration` בתוך תיאור `TimeSignal` הוא ביחידות 90,000-tick. אותו משך זמן לוגי, שתי קידודים — והבאג הנפוץ ביותר של SCTE-35 בשטח הוא ערבובם.

תרשים 3 · לוגיקת המרת זמן

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

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

3. מיקום יחסי, זמן הפעלה מוחלט

המפעיל אומר "הפסקת פרסומות ב-720 שניות לתוך התוכנית." ה-Lambda מחשבת את זמן ההפעלה בפועל ב-UTC כ-`programStartTime + offsetSeconds × 1000` ומטביעה זאת על הפעולה. כל פעולת תזמון אחרת — החלפת קלט, סימן מים פעיל, סיום תוכנית — משתמשת באותו צינור המרה של היסט-לחותמת זמן. סימוני הפרסומות נוחתים על אותם גבולות פריים כמו כל דבר אחר, ללא עמימות לגבי איזה שעון הוא הבעלים של ציר הזמן.

4. אימות בשכבת הנתונים, לא בחוט (ברשת)

סכימת ה-`AdMarker` אוכפת `duration ∈ [10, 120]` שניות בזמן השמירה של Mongoose. הפסקה מחוץ לטווח לעולם לא מגיעה ל-Lambda. הפסקות פרסומות שיגלשו מעבר לסיום התוכנית נקטעות בזמן הבנייה ולא נדחות — מפעילים לא מאבדים את עבודתם בגלל הפסקה אחת גרועה. סוגי הבאגים שלא יכולים לקרות מעניינים יותר מאלה שכן יכולים.

5. פליטת סימונים מנותקת מ-SSAI

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

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

תוצאות

• כל הפסקת פרסומות שמפעיל מגדיר פולטת מארז SCTE-35 תואם תקנים בן שלושה סימונים במניפסט ה-HLS של הערוץ — בשנייה הנכונה, מול בסיס הזמן הנכון.
• שכבת התרגום נמצאת בפונקציה אחת. שינויי מפרט או צרכנים חדשים במורד הזרם הם שינוי בקובץ בודד, לא חיפוש על פני כל בסיס הקוד.
• אימות משך זמן מתבצע בשכבת הנתונים, לפני שכל סימון מגיע למקודד. טעויות מפעיל צפות ועולות בממשק המשתמש, לא בשקט בזמן שידור — סימונים מעוצבים באופן שגוי לא יכולים להגיע ל-MediaLive.
• יצירת סימונים היא דטרמיניסטית: קלט מפעיל זהה מייצר פעולות SCTE-35 זהות, כך שאותה הפסקה מתנהגת באותה צורה בכל פריסה ובכל ערוץ.
• שכבת האיתות נשלחה והיא פעילה. צרכן ה-SSAI (MediaTailor) מתוכנן ומוכן לחיבור — וכאשר הוא יחובר, הסימונים של כל הערוצים הקיימים כבר ימתינו לו שם.

ערימת טכנולוגיה: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · SCTE-35 (`Scte35TimeSignalSettings`, `Scte35SpliceInsertSettings`) · AWS SDK v3