[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化

Starrier發表於2019-02-28

提高營銷效率的工程(二)—— 廣告製作和管理的規模化

Ravi Srinivas RanganathanGopal Krishnan 編寫

在本系列的第一篇部落格中,我們描述瞭如何把廣告科技融入市場營銷的理念,動機和方法。除此之外,為了大規模地解決創意開發和本地化的問題,我們還制定了一些管理計劃。

在第二部分中,我們描述了 在 Netflix 中通過廣告組裝和個性化來推廣廣告的過程。

問題的表象

我們的世界級營銷團隊的獨特任務是為我們展示不斷增長的原創電影和電視節目,以及每一部電影和電視劇背後的獨特故事。他們的工作不僅僅是提高我們製作的內容的認知度,更困難的是 —— 共同地為一部分非會員(受到營銷)和會員量身定製合適的內容,這些數十億的使用者都是我們線上廣告的受眾。這些廣告必須在各種網站和釋出商、Facebook、YouTube 和其他廣告平臺上送達至網際網路使用者。

想象一下,如果你要為下一部大片電影或必須看的電視節目發起數字營銷活動。你需要為各種創意概念、A/B 測試、廣告格式和本地化建立廣告,然後為技術和內容錯誤建立 QC(質量控制)。在考慮到這些變化後,你需要將它們傳輸到這些廣告將要投放的對應平臺上。現在,想象一下,每天釋出多重標題,同時仍然確保這些廣告中的每一個都能傳達給它們想要與之交談的人。最後,你需要在廣告發布後繼續管理你的廣告組合,來確保他們是最新的(比如,音樂授權和許可權到期),並繼續支援推出後的各個階段。

問題可以分為三類:

  • Ad Assembly: 一種可擴充套件的廣告製作和構建自動化工作流的方法
  • Creative QC: 一組可以輕鬆地對成千上萬的廣告單元的功能和語義正確性進行質量控制的工具和服務。
  • Ad Catalog Management: 基於 ML 的自動化管理使管理規模性廣告活動成為可能

什麼是 Ad Assembly?

總之,如果你從純粹的分析角度來看待這個問題,我們需要找到一種方法來有效地自動化和管理內容組合所產生的指數級規模增長。

廣告基數總數 ≈

Titles in Catalog x Ad Platforms x Concepts x Formats x A/B Tests x Localizations

我們處理組合學的方法是從源頭捕獲它,然後建立我們的廣告業務(我們產品的主要使用者)可用最少資訊來簡潔地表達各種變化的營銷平臺。

[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化

基於視訊的社會廣告創意變體

考慮以下廣告,這些廣告的高亮部分在多個維度上有所不同。

[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化

在顯示廣告上的創意性區別

如果你只是簡單地改變這則廣告在所有市場的獨特本地化,那麼就會導致產生 30 種變體。在建立靜態廣告的世界中,這意味著將通過營銷生成 30 個唯一的廣告檔案,然後進行投放。除了更努力外,任何需要處理所有單元的變化都必須分別引入份單元中,然後再重新進行 QC-ed。哪怕是對一個創意表達的小小修改,比如資產的改變,也會涉及到在廣告單元中進行修改。然後,每個變體都需要涉及 QC 和素材更新/重放廣告投放的剩餘流程。

我們對於上述內容的解決方案是構建動態廣告建立和配置平臺 —— 我們的廣告製作合作伙伴構建單個 dynamic 單元,然後使用相關的資料配置來修改廣告單元的行為。其次,通過提供工具,營銷人員只需要表達變化並自動繼承不變的內容,就可以顯著減少需要定義和管理的資料的表面積。

如果你檢視下面的本地化版本就會發現,它們會重用相同的基本構建塊,但只會基於配置來表達不同的創意。

[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化

簡單的本地化配置

這樣就可以在幾分鐘內從 1 => 30 地逐個進行本地化,而不是每個廣告單元都花費幾個小時甚至是幾天時間!

我們還可以通過與許多有用的服務構建整合來加快廣告組裝的過程,從而使這個過程更加無縫。比如,我們有支援成熟度評級、轉碼和壓縮視訊資產或從我們的產品目錄中提取圖稿等整合功能。總而言之,這些便利性極大地降低了執行具有極大覆蓋範圍的活動所需的時間。

創意 QC

質量控制的一個主要方面是確保廣告正確渲染並沒有任何技術或視覺錯誤的 —— 我們稱之為“功能性 QC”。鑑於不同廣告型別之間存在廣泛差異以及可能出現的問題,下面是我們追求改進創意質量控制狀態而採取的一些頂級方法。

首先,我們有一些工具可以在整個廣告組裝過程中插入合理的值,並減少出錯的可能性。

然後,通過在整個裝配過程中增加驗證和正確性檢查,使 QC 問題的總量最小化。比如,當超過 Facebook 視訊廣告的字元限制時,我們就會給出警告。

[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化

廣告裝配期間的警告

其次,我們執行自動測試套件,幫助識別廣告單元中是否存在任何可能對功能產生負面影響或對使用者體驗產生負面影響的技術問題。

[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化

來自一個顯示廣告的樣本自動掃描

最近,我們開始利用機器視覺來處理一些 QC 任務。比如,根據廣告的投放位置,可能需要新增特定的評級影像。為了驗證在視訊建立過程中應用了正確的評級影像,我們現在使用由我們的雲媒體系統團隊開發的影像檢測演算法。隨著以 AV 為中心的廣告素材的數量不斷擴大以及時間的推移,我們將在整體工作流中新增更多這樣的解決方案。

[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化

採用計算機視覺的抽樣來評定影像 QC-ED

除了功能的正確性,我們還非常關心語義化 QC —— 即,讓我們的營銷使用者確定廣告是否符合他們的創意目標,並準確地代表了內容和 Netflix 品牌的腔調及影響力。

構建我們廣告平臺的核心原則之一是立即更新實時渲染功能。這再加上我們的使用者可以很容易地識別和做出具有廣泛影響的精確的更新,使他們能夠儘快解決問題。我們的使用者還能夠根據需要進行創造性的反饋,通過共享 tearsheets 來進行更有效地評論。Tearsheet 是在最後的廣告被鎖定時的預覽,用來在發射前獲得最終的許可。

鑑於這一過程對我們的廣告活動的整體健康和成功的重要性,我們正大力投資 QC 自動化基礎設施。我們還積極地致力於開啟複雜的任務管理,狀態跟蹤和通知工作流,幫助我們以可持續的方式擴充套件到更高的數量級。

廣告目錄管理

廣告準備好後,我們會用一個“目錄”層將廣告製作、組裝和廣告投放分離開來,而不是直接投放廣告。

目錄根據廣告活動的意圖選擇要執行的廣告集,這是為了建立標題意識還是用於收購營銷?我們是在為一部電影或節目做宣傳活動,還是它突顯多個標題,還是一項以品牌為中心的資產?這是釋出前的廣告系列還是釋出後的廣告系列?

一旦指定了使用者定義:自動目錄就會處理以下內容:

  • 使用聚合的第一手資料和機器學習模型,使用者配置,廣告效能資料等,來管理它所提供的廣告素材。
  • 自動請求製作所需但尚未提供的廣告
  • 對不斷變化的資產可用性、推薦資料、黑名單等作出響應。
  • 簡化使用者工作流 —— 管理活動的啟動前和啟動後階段,排程內容重新整理等。
  • 收集指標並跟蹤資產的使用情況和效率

因此,目錄是一個非常強大的工具,因為它完成了對自己的優化,因此它支援 —— 實際上,它把我們的第一手資料變成了一個“情報層”。

個性化和 A/B 測試

所有這些都可以加到大於其部分 – 的總和中。使用這一技術,我們現在可以執行 Global Scale Vehicle —— 一個由內容效能資料和廣告效能資料驅動的始終支援常綠/常青狀態的自動化優化廣告系列。自動預算分配演算法(我們將在本系列的下一篇部落格中討論它),這非常有效地調整了操作複雜度。因此,我們的營銷使用者可以專注於構建精彩的廣告素材,並制定 A/B 測試和市場技術,我們的自動化目錄有助於將創意傳達到與之對應的地方 —— 自動化廣告選擇和個性化。

為了理解為什麼這是一個遊戲改變者,讓我們回顧一下之前的方法 —— 每個需要釋出的標題都必須涉及預算、目標定位,是否支援任意標題,執行時長,消費水平等。

面對我們不斷增加的內容庫,對於世界上幾乎所有國家的營銷廣度和細微差別以及需要支援的平臺和格式的數量,這是一項極其艱鉅的任務。其次,對創造性表現的意外變化做出足夠快的反應是很有挑戰性的,同時也要把重點放在即將到來的廣告和釋出會上。

[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化

實際上,Netflix 的做法是,我們通過一系列 A/B 測試獲得這個模型 —— 起初,我們執行了幾個測試,瞭解到一個帶有個性化互動的始終線上的廣告目錄的效能優於我們先前的 tentpole 釋出方法。我們之後進行了跟進,來確定它在不同平臺是如何做到表現優異的。正如人們所想的那樣,這基本上是一個持續學習的過程,當我們繼續在世界各地進行越來越多的營銷 A/B 測試時,我們驚喜地發現我們的優化指標有了巨大的、連續的改進。

服務架構

我們使用一些基於 Java 和 Groovy 的微服務來啟用這項技術,這些服務可以訪問各種 NoSQL 儲存,比如 Cassandra 和 Elasticsearch,使用 Kafka 和 Hermes 傳輸資料或觸發導致在 Titus 上呼叫的 dockerized 微服務應用程式事件來粘合不同部分。

[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化
[譯] 提高營銷效率的工程(二)—— 廣告製作和管理的規模化

我們廣告伺服器中大量使用 RxJava 來處理實時服務展示和 VAST 視訊請求,使用 RXNetty 作為它的應用程式框架,它提供定製化但是特色很少還伴隨著相應的開銷。我們使用 Tomcat / Jersey / Guice 作為廣告的中介軟體伺服器,因為它提供了更多的特性,且易於整合,比如簡單的驗證和授權。因為我們缺少嚴格的延遲和吞吐量限制,這些中介軟體伺服器可以為 Netflix 的雲端系統提供開箱即用的支援。

展望未來

儘管過去的這些年中,我們利用機會建立了大量的技術,但現實是,我們所需要完成的工作仍有很多。、

我們已經在一些廣告平臺上取得了巨大的進步,在有些平臺上卻才剛起步,而還有一些平臺,我們還未納入考慮範圍。在有些平臺中,我們已經完成了廣告創作,組裝和管理以及 QC 等流程,而在其他平臺中,我們甚至還未觸及廣告中簡單的組裝內容。

自動化和機器學習已經讓我們走得足夠遠了 — 但我們的團隊對於如何做得更多以及做的更好的興趣遠超於構建這些系統的速度。因為我們面臨著許多有趣的挑戰,所以每次在廣告流程的各個方面使用資料進行流量分析和預測時,每個 A/B 測試都會讓我們相處更多的探索方向。

Closing

總之,我們已經討論瞭如何構建獨特的廣告技術來幫助我們在廣告工作中增加規模和智慧。其中一些細節本身就值得後續的文章,我們將在未來發布它們。

為了進一步推進我們的營銷技術之旅,我們很快就會有下一個部落格,它將故事推進到我們如何支援來自各種平臺的營銷分析,並使不可能的事情成為可能,以及用它來優化營銷支出。

如果你對加入我們有興趣,想要參與 Netflix 的營銷團隊的機會,可以關注我們現在的招聘 ?

如果發現譯文存在錯誤或其他需要改進的地方,歡迎到 掘金翻譯計劃 對譯文進行修改並 PR,也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。


掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群,文章來源為 掘金 上的英文分享文章。內容覆蓋 AndroidiOS前端後端區塊鏈產品設計人工智慧等領域,想要檢視更多優質譯文請持續關注 掘金翻譯計劃官方微博知乎專欄

相關文章