大數據:談 DMP 與廣告聯播網間的關係

談談廣告系統的 DMP 到底是怎麼運作。說在前面,用文字來描述可能容易理解,但要實作到能正常商轉的程度,遠遠不及文字上所看到的百分之一。為了要讓後面的解釋容易理解,先描述其中一種資料應用的情境,再來說明該資料到底是怎麼來,怎麼去以及怎麼用。
評論
評論

朋友傳來一份關於廣告聯播網的業務開發簡報,裡面提到 DMP,他特別問到 DMP 到底是什麼。光從字面意義來解釋的話,DMP (Data Management Platform) 資料管理平台,白話點就是管理資料用的平台。只不過,管理什麼資料,這些資料從輸入到輸出,又能做到何種應用,可有各種不同的變形或變化。如果拿到許多大氣資料來,那就能用來作為天氣預測;如果拿到很多網站使用者足跡,那就能用來判斷他的興趣、嗜好。

如果拿到廣告聯播網來用,那就是所謂的廣告受眾。

開始談  DMP  之前,我必須先講,此技術應用要做到派得上用場,要做到能夠替廣告平台帶來穩定收入,其難度非常之高,涉及的專業與技術領域也很深且廣。沒有實作之前,很難想像一套要能精確瞄準使用者的資料分析系統得耗費多少功夫。也因此,市面上真正喊出能弄 DMP 的公司,不外乎是 IBM、Oracle、Salesforce、Google 之流,一般企業要用來作廣告系統,得耗費龐大成本與資源。

接著進入正題,談談廣告系統的 DMP 到底是怎麼運作。說在前面,用文字來描述可能容易理解,但要實作到能正常商轉的程度,遠遠不及文字上所看到的百分之一。為了要讓後面的解釋容易理解,先描述其中一種資料應用的情境,再來說明該資料到底是怎麼來,怎麼去以及怎麼用。

資料怎麼來?

「使用者經搜尋引擎或直接連結點入某網站,該網站屬於某個聯播網裡的一個網站。使用者進入該網站後,點擊 A 頁面,然後看了 A 頁面某個內容後,被引導到點擊廣告 B,而後在 B 的到達頁面上連續點擊 C、D、E 至各個不同頁面。」同上,該使用者以類似但不規則的方式造訪其他網站,不論出自於什麼動機或是理由。

一般來說,廣告聯播網的技術提供者,會提供一段 code 給網站主 (publisher) 定版,請他放在網站要置放廣告版位的地方,其作法因人而異,不細談各自差異。又或者有些廣告主,為了要追蹤廣告轉換成效,會放廣告聯播網所提供的 code 在指定到達頁或全站。兩個 code 都會做一樣的事情,都是用來存取使用者瀏覽器 (browser) 端的 cookie。cookie 則是使用者造訪該網站時,會被存放在瀏覽器本機端的暫存檔,該檔案簡單記錄了一些資本資料、到訪網址等。

一個網站就在一個瀏覽器存取一個 cookie,然而一個網站每天有數十萬個瀏覽器到訪,cookie 就存取數十萬個下來。有的網站更甚者會儲存一個以上的 cookie,特別像是某些網站用了五、六個廣告聯播網的廣告 code 之後,使用者一造訪該網站,可能就在瞬間被立刻儲存五、六個以上的 cookie。在此,純粹就廣告聯播網會用到的 cookie 做探討,不說明一般網站存取 cookie 的目的。

廣告聯播網技術提供者,靠著提供給網站主的 code,蒐集大量 cookie 回來,運用 ocokie 進行使用者的興趣與行為分析。在此,我們稱這類資料來源類型為 cookie based,其他還有 API based,經資料庫串 API 的方式把資料傳送出來供第三方使用。通常會用到 API basd,大多網站本身必須稍具規模或具足夠技術力,不然額外要請技術人員開 API 出來給第三方接,倒不如直接讓對方放 code 要來得直接。這兩者資料精準度差異很大,願意給 API 接的網站佔少數。

(Photo Credit: Neil Conway)

資料怎麼去?

擁有大量 cookie 後,接著就是進資料清洗,或稱數據清洗。首先要洗掉無效值、空值、不合法值,再做異常檢測、重複處理等,就想像成一道又一道處理工法,目的是要篩選掉那些沒有意義的資料。資料量小的時候就算了,資料量要是很大的話,每次資料進來都得花不少時間去清洗。靠電腦依照某些規則、條件去清洗資料,盡量讓有用的資料留下來。麻煩點,資料又特別複雜的狀況,還得特別靠演算法來計算,要加速每次清洗的速度,這又得靠機器學習來做。

清洗完之後,則進行資料歸納、歸類,將各不同資料分門別類存好,數據工程師面對的可能是每天數百 G 至數百 T 的資料量。這些資料有的有用,有的是垃圾,在還沒開始用之前,沒人知道這麼龐大的資料背後到底代表什麼。這就好比要在龐大亞馬遜森林裡面,找到某個特定顏色或味道的果實,得從數都數不清的樹林裡,慢慢翻慢慢找。怎麼正確找出果實,靠著一條又一條去嘗試設計出來的路徑來翻找。

有的廣告聯播網想要提供廣告主優質流量,會再針對清洗過的資料做二次篩選。篩選掉垃圾流量來的資料,包含點擊機器人、資料爬蟲、網路攻擊等,各種非正常人為資料,清洗過後,留下真正造訪網站的使用者,再針對該群使用者進行資料加工與校準。是不是每個廣告聯播網都願意這麼做,一樣因人而異,因為真要這麼洗下去,可能有些網站的使用者從報表來看會直接少掉一半左右。

(Photo Credit: kreezzalee)

資料怎麼用?

前面提過 cookie 會存取使用者瀏覽過的網址以及各頁面上的點擊資訊。基本上,廣告聯播網拿到的 cookie 無法辨識出該使用者是誰,更不清楚這個人是男生還是女生,因為 cookie 存取的資料有限,除非網站主願意分享自己站上該使用者登入後的資料,再把該使用者上站時的資料與登入後的狀態資料交集在一起,這才有可能比較準確知道該使用者是誰,不然的話,大多 cookie 取回來的資料都是遠遠猜測使用者是誰。

既然用猜的,那就有一套猜測方法。辨識方式才是所有資料分析之中最困難、最麻煩的地方。大致上可以分成三個面相:

1. 使用者瀏覽過後的內容比對

2. 使用者瀏覽行為與路徑記錄

3. 使用者被標籤反覆不斷標記

簡單來講,當使用者瀏覽過某個網頁後,會在  cookie 上存下瀏覽的 URL,然後廣告聯播平台,不論是用資料爬蟲或是快照的方式,將該 URL 上的內容儲存下來,進行內容標籤化的工作。這段工作又可分成兩段,一段是人工、一段是機器。當廣告聯播網面臨的網站不多以及頁面內容數量較少時,採取人工作法去分類每個 URL 裡的內容,並對該 URL 下標記會比較容易。可是當網站數量一多,各網站的內容頁面數量一大,人工處理就顯得非常無力,這時透過機器去分會比較適當,可是要用到機器去分,又得扯到自然語義分析。

我們稱這類工作叫做內容比對,透過將內容比對產出的標籤,標記到使用者上。這邊指的使用者,指的是來瀏覽網站的人,實際上並不是真的知道他 (她) 是誰,而是透過每個存取的 cookie 賦予一個 ID,每個 ID 都會在資料庫端存取一份,然後將這些 ID,貼上各式各樣的標記。貼標記的作用在於定義出使用者輪廓,例如該使用者看的各網頁內容有刮鬍刀、刮鬍泡泡、柔膚水、古龍水等,這些關鍵字一貼到使用者上,資料分析人員會很粗淺的劃分該使用者或許為男性。

上述這段的解釋,就是我們用來定義使用者之前,會先針對網站進行內容分析的使用者 demography  定義。這是一種假設,很不精確但卻提供一種可能性,我們不知道使用者到底是不是如我們所想,可是與其在茫然模糊的大海裡,連辨識都不知道怎麼做起,倒不如先用該使用者接觸到的內容作為定義之中心。從中,工程師訓練機器開始學習並改善使用者之於 demography 的精確性。能找出來的 demography 可能有性別、年齡、消費水平、居住地、學歷等,資料準確性不高,但這只是其中一個面相。

(Photo Credit:  Scott Cresswell)

從內容比對,還可比對出使用者的興趣。一樣用標記的方式,將各網站上的內容分析置入到 interest  類別裡。這類別,主要看的是使用者對哪些事物有興趣,以及接觸這些內容的頻率。興趣類別中,又有所謂的精準興趣、相似興趣、模糊興趣等類別,每個類別底下的興趣分支其實都差不多,差別只在於精準,是用來判定使用者有在網站上產生過具體交易行為或是某些行動,會把使用行為分析交叉寫入到興趣資料之中。至於相似則是從中找到該使用者與其他使用者,可能類似相近的興趣。模糊則是推測具有同樣 demography 的使用者,以及相似但頻率不高的興趣,採取基礎資料交集。

Demography 有了,interest 有了,再來就是 behavior。使用者到每個不同網站的行為都不大一樣,例如瀏覽新聞類型的網站,可能有很大一部分都是靠著臉書或搜尋連過去,但電子商務的網站,則有可能是靠著廣告宣傳。不同的網站類型,所牽動的使用者行為也都不同,因此分析者得先針對不同的網站做不同類型的行為脈絡定義。這定義並不難,也就是一個網站的瀏覽行為,到底需不需要登入,有沒有購買,會不會結帳,有無其他必要行動才可以到下一個單元,在 GA 裡面,我們稱作工作階段。

所以,從 cookie 來的資料,被加工處理過後,會被 demography、interest、behavior 這三者資料,像是金字塔般的以使用者為中心,圍繞著使用者,不斷增長並且豐富其資料。請注意,這邊談的是豐富其資料,不代表資料會變得更精準,要讓使用者資料變得更準確,嚴格來講,不是真實世界的準確,而是網路世界裡的人格與行為相似於我們所描述輪廓的那一群人,那就得反覆重新的進行 tagging。Tagging 的目的有兩個,一個是將使用者定義的更精確,另一個則是讓機器學習,從網站中間接辨別使用者。

到此,資料怎麼來、怎麼去、怎麼用,不過就只是一套 DMP 開發基礎,然後廣告聯播網的 DMP 設計又不只面向使用者,還有另外一端是代表著廣告主的廣告操作人員。廣告操作人員在操作廣告時,將廣告投放到各大網站,使用者有無點擊,攸關廣告操作人員依據什麼樣的資料來投放。廣告操作人員之於投放準的使用者,使用者對於網站內容以及廣告素材,這之間是屬於隨時都在動態改變的資料模式,難以被輕易找出固定脈絡,也因此廣告成效要準確做到某種程度,數據沒有大到某種量級,分析能力沒有強到某種程度,可以說是完全做不來。

(Photo Credit: Matthew Hutchinson)

最後,回到第一段,廣告聯播網之於 DMP 所對準的廣告受眾,就是整篇文章在講造訪網站的使用者。使用者能不能依循著廣告主的意圖、意念,接觸到廣告之後進而採取行動,是每個廣告聯播網面臨的最大挑戰,因為這背後處理的是極為龐大又難以理解的資料,資料的正確性低,而為了要加強資料正確性,在系統尚未成熟的早期,都得透過大量人工辨識的方式來輔助或標記,直到機器的行為到達一定準確度,例如機器做的跟人做的相似度達 70% 以上,此時某些資料就可以交由機器自動判斷處理。

由人與機器之間反覆的協作,提昇資料可用性,最後能成為可以轉換為營運資金的廣告平台基礎是 DMP 設計時的原始核心要素,而這段路隨著越發展越深,則會進入到人工智慧的領域,那處理資料與運算的速度、規模跟量級,又是另外一個完全不同世界的事情了。以上,說的容易做得難,特別這例子僅包括網站,其他還有行動裝置裡的 app、其他數位裝置等,每種不同平台能獲取的資料都不同,再加上現在使用者不會僅用一台電腦上網,有可能在公司一台、在家一台,然後明明就是同一個人,可在兩台電腦上的使用行為卻大不同,導致在系統端的解讀也有可能會是完全獨立的兩個人。

朋友問到 DMP 是不是很好作 (開發),為何從 2014 年一直到 2015 年,在這兩年如雨後春筍般的冒出來。或許應該這麼說,大數據談了好幾年,落實到應用層面的情境,比較能為人所見的就算數位廣告聯播為顯學,另一則是網路口碑分析及輿情預測,其他運用大數據的領域,舉凡像是醫療、農業、金融等,較難為一般人所接觸,反倒數位廣告因 Google、Facebook 等平台出現,還有越來越普遍的 AD Exchange,才讓 DMP 這類存在已久的應用,伴隨著大數據一起熱鬧浮上檯面。

歡迎加入「Inside」Line 官方帳號,關注最新創業、科技、網路、工作訊息

好友人數

開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?
評論
評論

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

打造第一個在 AWS 上的應用程式

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!