看來網路廣告領域應該盡可能技術先進和自動化。當然，因為 Yandex、Mail.Ru、Google 和 Facebook 等各自領域的巨頭和專家都在那裡工作。但事實證明，完美是沒有極限的，總是有一些東西可以自動化。
通訊組 電通安吉斯網路俄羅斯 是數位廣告市場最大的參與者，正在積極投資技術，試圖優化和自動化其業務流程。網路廣告市場尚未解決的問題之一是收集不同網路平台廣告活動的統計數據。這個問題的解決最終導致了產品的創建 D1.數碼 （讀作 DiVan），我們要談談它的發展。
為什麼呢？
1. 在專案啟動時，市場上還沒有任何現成的產品可以解決廣告活動統計資料的自動化收集問題。 這意味著除了我們自己之外沒有人會滿足我們的需求。
Improvado、Roistat、Supermetrics、SegmentStream 等服務提供與平台、社交網路和 Google Analitycs 的集成，並且還可以建立分析儀表板以方便分析和控制廣告活動。在我們開始開發我們的產品之前，我們嘗試使用其中一些系統從網站收集數據，但不幸的是，它們無法解決我們的問題。
主要問題是測試的產品是基於資料來源，按網站顯示投放統計數據，並且不提供聚合廣告活動統計資料的功能。這種方法不允許我們在一個地方看到來自不同網站的統計數據並分析整個活動的狀態。
另一個因素是，在最初階段，產品針對的是西方市場，不支援與俄羅斯站點的整合。對於那些實施整合的網站，所有必要的指標並不總是下載足夠的細節，並且整合並不總是方便和透明，特別是當需要獲取系統介面中沒有的東西時。
總的來說，我們決定不適應第三方產品，而是開始開發我們自己的...
2.網路廣告市場逐年成長，2018年，就廣告預算而言，超過了傳統上最大的電視廣告市場。 所以有一個尺度.
3.與商業廣告銷售被壟斷的電視廣告市場不同，有許多規模不等的廣告庫存個人擁有者在網路上擁有自己的廣告帳號進行經營。由於廣告活動通常會同時在多個網站上運行，因此為了了解廣告活動的狀態，有必要收集所有網站的報告並將它們組合成一個可以顯示全貌的大型報告。 這意味著存在優化的潛力。
4. 在我們看來，網路廣告庫存的所有者已經擁有收集統計數據並將其顯示在廣告帳戶中的基礎設施，並且他們將能夠為這些數據提供 API。 這意味著它在技術上是可以實現的。 我們馬上說，事實證明事情沒有那麼簡單。
總的來說，實施該專案的所有先決條件對我們來說都是顯而易見的，我們開始努力使該專案付諸實踐...
宏偉計劃
首先，我們形成了一個理想系統的願景：
- 1C企業系統中的廣告活動應自動載入到其中，包括其名稱、週期、預算和在各個平台上的展示位置。
- 對於廣告活動中的每個展示位置，應從進行展示位置的網站自動下載所有可能的統計數據，例如展示次數、點擊次數、瀏覽次數等。
- 一些廣告活動是透過所謂的廣告服務系統（例如 Adriver、Weborama、DCM 等）使用第三方監控進行追蹤的。俄羅斯還有一個工業互聯網儀表－Mediascope公司。根據我們的計劃，來自獨立和工業監測的數據也應該自動加載到相應的廣告活動中。
- 網路上的大多數廣告活動都是針對某些目標操作（購買、致電、註冊試駕等），這些活動是使用 Google Analytics 進行追蹤的，其統計數據對於了解活動的狀態也很重要應該加載到我們的工具中。
第一張煎餅是塊狀的
鑑於我們對軟體開發的靈活原則（敏捷、一切）的承諾，我們決定先開發 MVP，然後迭代地實現預期目標。
我們決定根據我們的產品建立 MVP DANBo（電通安吉斯網路董事會），這是一個網絡應用程序，包含有關我們客戶的廣告活動的一般資訊。
對於MVP來說，專案在實作上盡可能的簡化。我們選擇了有限的整合平台清單。這些是主要平台，例如Yandex.Direct、Yandex.Display、RB.Mail、MyTarget、Adwords、DBM、VK、FB，以及主要廣告系統Adriver和Weborama。
為了透過 API 存取網站統計信息，我們使用了單一帳戶。想要使用自動收集廣告活動統計資料的客戶群組經理必須先將對網站上必要的廣告活動的存取權限委託給平台帳戶。
接下來是系統用戶 丹波 需要將一定格式的文件上傳到Excel系統中，其中包含投放的所有資訊（廣告活動、平台、格式、投放週期、計劃指標、預算等）以及相應廣告活動在平台上的標識符。廣告系統中的站點和櫃檯。
坦白說，它看起來很可怕：
下載的資料被保存到資料庫中，然後單獨的服務從它們收集網站上的活動標識符並下載它們的統計資料。
對於每個站點，都編寫了一個單獨的 Windows 服務，該服務每天一次在站點 API 中的一個服務帳戶下運行，並下載指定活動 ID 的統計資料。廣告系統也發生了同樣的事情。
下載的資料以小型自訂儀表板的形式顯示在介面上：
出乎我們意料的是，MVP 開始工作並開始下載網路上廣告活動的最新統計數據。我們在多個客戶端上實作了這個系統，但在嘗試擴充時，我們遇到了嚴重的問題：
- 主要問題是準備資料載入到系統中的複雜性。此外，在載入之前，放置資料必須轉換為嚴格固定的格式。有必要在下載檔案中包含來自不同網站的實體識別碼。我們面臨的事實是，未經技術培訓的使用者很難解釋在網站上哪裡可以找到這些識別碼以及需要在文件中的何處輸入它們。考慮到在網站上開展活動的部門的員工數量和營業額，這導致我們這邊得到了大量的支持，我們對此絕對不滿意。
- 另一個問題是，並非所有廣告平台都有將廣告活動的存取權委託給其他帳號的機制。但即使有授權機制可用，也不是所有廣告商都願意將其廣告活動的存取權限授予第三方帳戶。
- 一個重要的因素是引起了使用者的憤慨，因為他們已經輸入我們1C會計系統的所有計劃指標和投放細節必須重新輸入 丹波.
這讓我們想到，有關放置的信息的主要來源應該是我們的1C 系統，所有數據都準確、按時地輸入到該系統中（這裡的要點是，發票是根據1C 數據生成的，因此將數據正確輸入到1C 中）是每個人的首要任務 KPI）。這就是系統的新概念的出現...
概念
我們決定要做的第一件事是將收集網路廣告活動統計資料的系統分離成一個單獨的產品 - D1.數碼.
在新概念中，我們決定加載 D1.數碼 1C 中有關廣告活動及其展示位置的信息，然後從網站和廣告服務系統中提取統計數據到這些展示位置。這應該會顯著簡化用戶的生活（並且像往常一樣，為開發人員增加更多工作）並減少支援量。
我們遇到的第一個問題是組織性質的，與我們無法找到可以將不同系統中的實體與 1C 中的行銷活動和展示位置進行比較的關鍵或標誌有關。事實上，我們公司的流程是這樣設計的：廣告活動由不同的人（媒體策劃者、購買者等）輸入不同的系統。
為了解決這個問題，我們必須發明一個唯一的雜湊密鑰 DANBoID，它將不同系統中的實體連結在一起，並且可以在下載的資料集中相當容易且唯一地識別。此標識符在內部 1C 系統中為每個單獨的展示位置生成，並傳輸到所有網站和所有 AdServing 系統中的行銷活動、展示位置和計數器。實施將 DANBoID 放入所有展示位置的做法花費了一些時間，但我們成功做到了:)
然後我們發現並非所有網站都有自動收集統計資料的 API，即使有 API，它也不會傳回所有必要的資料。
現階段，我們決定大幅減少整合平台列表，並專注於參與絕大多數廣告活動的主要平台。此清單包括廣告市場（Google、Yandex、Mail.ru）、社交網路（VK、Facebook、Twitter）、主要廣告服務和分析系統（DCM、Adriver、Weborama、Google Analytics）和其他平台的所有最大參與者。
我們選擇的大多數網站都有一個 API 可以提供我們所需的指標。在沒有 API 或不包含必要數據的情況下，我們使用每天發送到我們辦公室電子郵件的報告來加載數據（在某些系統中可以配置此類報告，在其他系統中我們同意開發此類報告）為了我們）。
在分析不同站點的資料時，我們發現不同系統中實體的層次結構並不相同。此外，需要從不同的系統下載不同細節的資訊。
為了解決這個問題，開發了 SubDANBoID 概念。 SubDANBoID 的想法很簡單，我們用產生的 DANBoID 來標記站點上活動的主要實體，並上傳所有具有唯一站點標識符的嵌套實體，並根據 DANBoID 原則 + 第一層標識符形成 SubDANBoID嵌套實體+第二級嵌套實體的識別碼+...這種方法使我們能夠連接不同系統中的廣告活動並下載它們的詳細統計資料。
我們還必須解決在不同平台上存取活動的問題。正如我們上面所寫，將活動存取權委託給單獨的技術帳戶的機制並不總是適用。因此，我們必須開發一個基礎設施，以便使用令牌和更新這些令牌的機制透過 OAuth 自動授權。
在本文後面，我們將嘗試更詳細地描述該解決方案的架構和實現的技術細節。
解決方案架構1.0
當開始實施新產品時，我們明白我們立即需要提供連接新站點的可能性，因此我們決定走微服務架構的道路。
在設計架構時，我們將所有外部系統（1C、廣告平台和廣告系統）的連接器分開為單獨的服務。
主要想法是網站的所有連接器都具有相同的 API，並且是將網站 API 帶到對我們來說方便的介面的適配器。
我們產品的核心是一個 Web 應用程序，它是一個整體，其設計方式可以輕鬆地分解為服務。該應用程式負責處理下載的數據，整理來自不同系統的統計數據並將其呈現給系統使用者。
為了在連接器和 Web 應用程式之間進行通信，我們必須建立一項附加服務，我們稱之為連接器代理。它執行服務發現和任務計劃程序的功能。該服務每晚為每個連接器運行資料收集任務。編寫服務層比連接訊息代理程式更容易，對我們來說，盡快獲得結果非常重要。
為了簡單性和開發速度，我們也決定所有服務都將是 Web API。這使得快速組裝概念驗證並驗證整個設計是否有效成為可能。
一項單獨且相當複雜的任務是設定從不同帳戶收集資料的存取權限，正如我們決定的那樣，這應該由使用者透過 Web 介面執行。它由兩個單獨的步驟組成：首先，用戶添加令牌以透過 OAuth 存取帳戶，然後配置用戶端從特定帳戶收集的資料。透過 OAuth 取得令牌是必要的，因為正如我們已經寫過的，並不總是可以將存取權限委託給網站上所需的帳戶。
為了建立從網站選擇帳戶的通用機制，我們必須為連接器 API 新增一個傳回 JSON 架構的方法，該方法使用修改後的 JSONEditor 元件呈現為表單。這樣，使用者就可以選擇從中下載資料的帳戶。
為了遵守網站上存在的請求限制，我們將設定請求合併到一個令牌中，但我們可以並行處理不同的令牌。
我們選擇 MongoDB 作為 Web 應用程式和連接器載入資料的存儲，這使我們不必在開發的初始階段過度擔心資料結構，因為應用程式的物件模型每隔一天都會發生變化。
我們很快就發現並非所有資料都適合 MongoDB，例如，將日常統計資料儲存在關聯式資料庫中會更方便。因此，對於資料結構更適合關聯式資料庫的連接器，我們開始使用PostgreSQL或MS SQL Server作為儲存。
所選的架構和技術使我們能夠相對快速地建置和推出 D1.Digital 產品。在兩年多的產品開發過程中，我們開發了23 個網站連接器，獲得了與第三方API 合作的寶貴經驗，學會了避免不同網站的陷阱（每個網站都有自己的陷阱），為至少3 個API 的開發做出了貢獻網站自動下載了近15個活動和000多個展示位置的信息，收集了大量用戶對產品操作的反饋，並根據這些反饋多次更改了產品的主要流程。
解決方案架構2.0
自開始開發以來已經過去兩年了 D1.數碼。系統負載的不斷增加以及越來越多新資料來源的出現逐漸暴露出現有解決方案架構中的問題。
第一個問題與從網站下載的資料量有關。我們面臨這樣一個事實：從最大的站點收集和更新所有必要的數據開始花費太多時間。例如，從 AdRiver 廣告投放系統收集資料（我們使用該系統追蹤大多數展示位置的統計資料）大約需要 12 小時。
為了解決這個問題，我們開始使用各種報表從網站下載數據，我們正在嘗試與網站一起開發他們的API，使其運行速度滿足我們的需求，並盡可能並行化資料下載。
另一個問題涉及下載資料的處理。現在，當新的展示位置統計數據到達時，會啟動重新計算指標的多階段過程，其中包括加載原始數據、計算每個網站的聚合指標、比較不同來源的數據以及計算活動的匯總指標。這會導致執行所有計算的 Web 應用程式承受大量負載。有幾次，在重新計算過程中，應用程式消耗了伺服器上的所有內存，大約10-15 GB，這對用戶使用系統的工作產生了最不利的影響。
所發現的問題和進一步開發產品的雄心勃勃的計劃使我們需要重新考慮應用程式架構。
我們從連接器開始。
我們注意到所有連接器都按照相同的模型工作，因此我們建立了一個管道框架，在其中建立連接器時只需編寫步驟的邏輯，其餘部分都是通用的。如果某些連接器需要改進，那麼我們在改進連接器的同時立即將其轉移到新框架。
同時，我們開始將連接器部署到 Docker 和 Kubernetes。
我們計劃遷移到 Kubernetes 很長一段時間，嘗試了 CI/CD 設置，但只有當一個連接器由於錯誤而開始佔用伺服器上超過 20 GB 的內存，幾乎殺死了其他進程時才開始遷移。在調查過程中，連接器被移至 Kubernetes 集群，即使在錯誤修復後，它最終仍保留在那裡。
很快我們就意識到 Kubernetes 很方便，在六個月內我們將 7 個連接器和消耗資源最多的連接器代理程式轉移到生產叢集。
在連接器之後，我們決定更改應用程式其餘部分的架構。
主要問題是資料大批量地從連接器發送到代理，然後到達 DANBoID 並發送到中央 Web 應用程式進行處理。由於大量的指標重新計算，應用程式的負載很大。
事實證明，監控各個資料收集作業的狀態並將連接器中發生的錯誤報告給中央 Web 應用程式非常困難，以便使用者可以了解正在發生的情況以及未收集資料的原因。
為了解決這些問題，我們開發了架構2.0。
新版本架構的主要區別在於，我們使用 RabbitMQ 和 MassTransit 庫而不是 Web API 在服務之間交換訊息。為此，我們必須幾乎完全重寫 Connectors Proxy，使其成為 Connectors Hub。名稱已更改，因為該服務的主要作用不再是將請求轉發到連接器並返回，而是管理來自連接器的指標集合。
從中央網路應用程式中，我們將有關展示位置和統計資料的資訊從網站中分離到單獨的服務中，這使得擺脫不必要的重新計算並僅存儲展示位置級別上已經計算和匯總的統計數據成為可能。我們還根據原始數據重寫並優化了基礎統計的計算邏輯。
同時，我們正在將所有服務和應用程式遷移到 Docker 和 Kubernetes，以使解決方案更易於擴展且更方便管理。
我們現在在哪裡
概念驗證架構 2.0 產品 D1.數碼 準備好並在具有有限連接器集的測試環境中工作。剩下要做的就是將另外 20 個連接器重寫到新平台，測試資料是否正確載入以及所有指標是否正確計算，然後將整個設計投入生產。
事實上，這個過程將逐漸發生，我們將不得不保留與舊 API 的向後相容性，以保持一切正常運作。
我們的近期計劃包括開發新的連接器、與新系統整合以及向從連接的網站和廣告系統下載的資料集添加額外的指標。
我們還計劃將所有應用程式（包括中央 Web 應用程式）轉移到 Docker 和 Kubernetes。與新架構結合，這將顯著簡化消耗資源的部署、監控和控制。
另一個想法是嘗試選擇儲存統計資料的資料庫，目前儲存在 MongoDB 中。我們已經將幾個新的連接器轉移到 SQL 資料庫，但差異幾乎無法察覺，而且對於可以在任意時間段內請求的按天聚合統計數據，增益可能相當大。
總的來說，計劃很宏大，讓我們繼續吧:)
電通安吉斯網路俄羅斯研發一文的作者：Georgy Ostapenko (），米哈伊爾·科齊克（)
來源： www.habr.com