איך אספנו נתונים על קמפיינים פרסומיים מאתרים מקוונים (הדרך הקוצנית למוצר)

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

מקור

קבוצת תקשורת Dentsu Aegis Network Russia הוא השחקן הגדול ביותר בשוק הפרסום הדיגיטלי ומשקיע באופן פעיל בטכנולוגיה, מנסה לייעל ולהפוך את התהליכים העסקיים שלו לאוטומטיים. אחת הבעיות הבלתי פתורות של שוק הפרסום המקוון הפכה למשימה של איסוף נתונים סטטיסטיים על קמפיינים פרסומיים מפלטפורמות אינטרנט שונות. הפתרון לבעיה זו הביא בסופו של דבר ליצירת מוצר D1.דיגיטל (קראו כ-DiVan), שעל התפתחותו אנו רוצים לדבר.

למה?

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

שירותים כמו Improvado, Roistat, Supermetrics, SegmentStream מציעים אינטגרציה עם פלטפורמות, רשתות חברתיות ו-Google Analitycs, ומאפשרים גם לבנות דשבורדים אנליטיים לניתוח ושליטה נוחים בקמפיינים פרסומיים. לפני שהתחלנו לפתח את המוצר שלנו, ניסינו להשתמש בחלק מהמערכות הללו כדי לאסוף נתונים מאתרים, אך, למרבה הצער, הן לא הצליחו לפתור את הבעיות שלנו.

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

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

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

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

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

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

תוכנית גדולה

מלכתחילה, גיבשנו חזון של מערכת אידיאלית:

• יש לטעון לתוכה קמפיינים פרסומיים מהמערכת הארגונית של 1C באופן אוטומטי עם שמותיהם, התקופות, התקציבים והמיקומים שלהם בפלטפורמות השונות.
• עבור כל מיקום בתוך קמפיין פרסומי, יש להוריד אוטומטית את כל הנתונים הסטטיסטיים האפשריים מהאתרים שבהם המיקום מתבצע, כגון מספר ההופעות, הקלקות, צפיות וכו'.
• מעקב אחר מסעות פרסום מסוימים מתבצע באמצעות ניטור של צד שלישי על ידי מה שנקרא מערכות פרסום כגון Adriver, Weborama, DCM וכו'. יש גם מד אינטרנט תעשייתי ברוסיה - חברת Mediascope. על פי התוכנית שלנו, נתונים מניטור עצמאי ותעשייתי צריכים להיטען אוטומטית גם למסעות הפרסום המתאימים.
• רוב הקמפיינים הפרסומיים באינטרנט מכוונים לפעולות יעד מסוימות (רכישה, התקשרות, הרשמה לנסיעת מבחן וכו'), אשר עוקבים אחריהן באמצעות גוגל אנליטיקס, וסטטיסטיקות לגביהן חשובות גם להבנת מצב הקמפיין ו צריך לטעון לתוך הכלי שלנו.

הדבר הראשון לעזאזל הוא גבשושי

בהתחשב במחויבות שלנו לעקרונות גמישים של פיתוח תוכנה (אג'ייל, הכל), החלטנו קודם כל לפתח MVP ואז להתקדם לעבר המטרה המיועדת באופן איטרטיבי.
החלטנו לבנות MVP על בסיס המוצר שלנו DANBo (Dentsu Aegis Network Board), שהיא אפליקציית אינטרנט עם מידע כללי על מסעות הפרסום של לקוחותינו.

עבור MVP, הפרויקט היה מפושט ככל האפשר מבחינת היישום. בחרנו רשימה מוגבלת של פלטפורמות לשילוב. אלו היו הפלטפורמות העיקריות, כגון Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, ומערכות הפרסום העיקריות Adriver ו- Weborama.

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

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

זה נראה, למען האמת, מפחיד:

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

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

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

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

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

זה נתן לנו את הרעיון שהמקור העיקרי למידע על מיקום צריך להיות מערכת 1C שלנו, אליה כל הנתונים מוזנים בצורה מדויקת ובזמן (הנקודה כאן היא שחשבוניות נוצרות על סמך נתוני 1C, אז הזנה נכונה של הנתונים ל-1C הוא בראש סדר העדיפויות עבור כולם KPI). כך נוצר תפיסה חדשה של המערכת...

מושג

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

בקונספט החדש, החלטנו לטעון D1.דיגיטל מידע על מסעות פרסום ומיקומים בתוכם מ-1C, ולאחר מכן להעלות נתונים סטטיסטיים מאתרים ומערכות AdServing למיקומים אלה. זה היה אמור לפשט משמעותית את החיים עבור המשתמשים (וכרגיל, להוסיף עוד עבודה למפתחים) ולהפחית את כמות התמיכה.

הבעיה הראשונה שנתקלנו בה הייתה בעלת אופי ארגוני וקשורה לעובדה שלא הצלחנו למצוא מפתח או סימן שבאמצעותם נוכל להשוות ישויות ממערכות שונות עם קמפיינים ומיקומים מ-1C. העובדה היא שהתהליך בחברה שלנו מתוכנן כך שמסעות פרסום מוכנסים למערכות שונות על ידי אנשים שונים (מתכנני מדיה, קנייה וכו').

כדי לפתור את הבעיה הזו, היינו צריכים להמציא מפתח גיבוב ייחודי, DANBoID, שיקשר ישויות במערכות שונות יחד, וניתן היה לזהות אותו בצורה די קלה וייחודית במערכות נתונים שהורדו. מזהה זה נוצר במערכת הפנימית 1C עבור כל מיקום בנפרד ומועבר לקמפיינים, מיקומים ומונים בכל האתרים ובכל מערכות AdServing. יישום התרגול של הכנסת DANBoID בכל המיקומים לקח קצת זמן, אבל הצלחנו לעשות את זה :)

ואז גילינו שלא לכל האתרים יש API לאיסוף אוטומטי של סטטיסטיקות, וגם לאלו שיש להם API הוא לא מחזיר את כל הנתונים הדרושים.

בשלב זה החלטנו לצמצם משמעותית את רשימת הפלטפורמות לשילוב ולהתמקד בפלטפורמות העיקריות המעורבות ברוב המוחלט של מסעות הפרסום. רשימה זו כוללת את כל השחקנים הגדולים ביותר בשוק הפרסום (גוגל, Yandex, Mail.ru), רשתות חברתיות (VK, Facebook, Twitter), מערכות AdServing וניתוח עיקריות (DCM, Adriver, Weborama, Google Analytics) ופלטפורמות נוספות.

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

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

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

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

בהמשך המאמר ננסה לתאר ביתר פירוט את ארכיטקטורת הפתרון ואת הפרטים הטכניים של היישום.

ארכיטקטורת פתרונות 1.0

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

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

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

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

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

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

כדי ליצור מנגנון אוניברסלי לבחירת חשבון מאתרים, היינו צריכים להוסיף שיטה ל-connectors API שמחזירה JSON Schema, שמעובדת לטופס באמצעות רכיב JSONEditor שונה. בדרך זו, המשתמשים יכלו לבחור את החשבונות מהם להוריד נתונים.

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

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

מהר מאוד גילינו שלא כל הנתונים מתאימים היטב ל-MongoDB, ולדוגמא, נוח יותר לאחסן סטטיסטיקות יומיות במסד נתונים יחסי. לכן, עבור מחברים שמבנה הנתונים שלהם מתאים יותר לבסיס נתונים יחסי, התחלנו להשתמש ב-PostgreSQL או MS SQL Server כאחסון.

הארכיטקטורה והטכנולוגיות שנבחרו אפשרו לנו לבנות ולהשיק את המוצר D1.Digital במהירות יחסית. במהלך שנתיים של פיתוח מוצר, פיתחנו 23 מחברים לאתרים, רכשנו ניסיון רב ערך בעבודה עם ממשקי API של צד שלישי, למדנו להימנע מהמלכודות של אתרים שונים, שלכל אחד מהם היו משלהם, תרמו לפיתוח ה-API של לפחות 3 אתרים, הורידו אוטומטית מידע על כמעט 15 קמפיינים ולמעלה מ-000 מיקומים, אספו משוב רב ממשתמשים על פעולת המוצר והצליחו לשנות את התהליך העיקרי של המוצר מספר פעמים, על סמך משוב זה.

ארכיטקטורת פתרונות 2.0

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

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

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

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

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

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

במקביל, התחלנו לפרוס מחברים ל-Docker ול-Kubernetes.
תכננו את המעבר ל-Kubernetes די הרבה זמן, ניסינו עם הגדרות CI/CD, אבל התחלנו לזוז רק כאשר מחבר אחד, עקב שגיאה, התחיל לאכול יותר מ-20 ג'יגה-בייט של זיכרון בשרת, ובעצם הרג תהליכים אחרים . במהלך החקירה, המחבר הועבר לאשכול Kubernetes, שם הוא נשאר בסופו של דבר, גם לאחר תיקון השגיאה.

די מהר הבנו ש-Kubernetes נוח, ותוך חצי שנה העברנו לאשכול הייצור 7 מחברים ו-Connectors Proxy, שצורכים את מירב המשאבים.

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

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

כדי לפתור את הבעיות הללו, פיתחנו ארכיטקטורה 2.0.

ההבדל העיקרי בין הגרסה החדשה של הארכיטקטורה הוא שבמקום ה-Web API, אנו משתמשים ב-RabbitMQ ובספריית MassTransit כדי להחליף הודעות בין שירותים. כדי לעשות זאת, היינו צריכים לשכתב כמעט לחלוטין את Connectors Proxy, מה שהופך אותו ל- Connectors Hub. השם שונה מכיוון שתפקידו העיקרי של השירות אינו עוד בהעברת בקשות למחברים ובחזרה, אלא בניהול איסוף המדדים מהמחברים.

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

במקביל, אנו מעבירים את כל השירותים והיישומים ל- Docker ו- Kubernetes כדי להפוך את הפתרון לקל יותר להרחבה ונוח יותר לניהול.

איפה אנחנו עכשיו

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

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

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

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

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

באופן כללי, התוכניות גרנדיוזיות, בואו נמשיך :)

מחברי המאמר R&D Dentsu Aegis Network Russia: Georgy Ostapenko (שמייגה), מיכאיל קוציק (hitexx)

מקור: www.habr.com