1. 程式人生 > >日訂單超1000萬,美團外賣是如何設計廣告推送系統的?

日訂單超1000萬,美團外賣是如何設計廣告推送系統的?

在 2013 年,美團一直靠資本推動拉新,到 2015 年,為了達到收支平衡,美團開始考慮商業變現。從 2016 年初到 2017 年,美團針對商業變現做了兩套廣告系統,並上線投入使用。本文由美團外賣商業技術負責人王興星與大家分享外賣業務合理變現系統的設計過程及相關經驗

美團的外賣業務特點

外賣與團購的區別

提到美團,大家接觸更多的是團購,以下是外賣與團購兩大業務之間的對比

  • 使用者需求。團購的出發點是追求價效比,價格會便宜一些。而外賣,前期商家用第一單免費的方式吸引使用者,後期在解決一部分使用者剛需的同時更加方便快捷,所以使用者的消費頻次較高。

  • 支付方式。兩個都是線上支付,外賣業務平臺也會有一部分,但流量不是很多。

  • 就餐地點。就餐形式上團購需要到店消費,而外賣是需要把物品送到消費者手中,背後需要配送團隊的支撐。

  • 消費頻率。兩者差異比較大,團購消費時間集中在月底,而外賣的重度使用者,一週點單可達到十次以上。

外賣業務的特點

除了以上這些對比,相對傳統的網際網路產品,外賣業務有移動化、場景化、本地化三大特點

  • 移動化。美團絕大部分訂餐都是在移動端進行,日誌採集相比 PC 端複雜很多。

  • 場景化。使用者訂餐時間相對集中,系統高峰在早餐、晚餐、夜宵等時段,流量是其他時間的 N 倍。

  • 本地化。傳統業務的供給範圍是整個網際網路,團購面向的是城市粒度,而外賣面向的是商圈粒度。這些會在技術實現方案上體現差異化。

O2O 廣告和傳統廣告的區別

O2O 廣告不僅需要考慮外賣店鋪、外賣使用者以及外賣平臺三方,還要儘可能做到多方的共贏:

  • 幫助外賣店鋪獲得更多的訂單量、拉來新使用者並留存使用者

  • 讓外賣使用者有更多機會嘗試新店,獲得更多優惠

  • 外賣平臺可進行流量變現

O2O 廣告與傳統廣告有很多不同之處,主要介紹以下 6 點

  • 中小廣告主。O2O 廣告服務物件更多的是中小廣告主。

  • 行業資訊化程度。服務物件相對資訊化程度比較低,對網際網路及商業變現接觸較少,這對業務提出較高的挑戰。

  • 形式更加原生。廣告前期採取較為簡單直接的方案,以天為時間單位、針對配送區域、按固定的價格來售賣,可見即可得,廣告主更容易接受。

經過一段時間,待市場對廣告主的教育成熟之後,廣告逐步推行按點選的售賣方式。

  • 強地域限制。這由業務性質決定,相比傳統廣告,O2O 廣告主地域性特別強。

  • 全鏈條資料。因交易型別產品所獨具的特性,從瀏覽、點選、到成單形成全鏈條資料。

  • 交易類&資訊類。這兩類產品存在很多不同點,變現方式也存在差異。

美團外賣 O2O 廣告佈設實踐

第一:針對行業資訊化程度低的特點,佈設廣告需要從運營和產品兩個層面出發,有針對性的進行佈設。

運營層面:

  • 市場教育:通過對廣告主的訪談,瞭解真正的需求。通過線下地推,把廣告的意圖,告知到商家。

  • 廣告主拉新、促活:通過給使用者發紅包的形態,促使 C 端在 B 端使用,廣告主第一單投放可以打些折扣等方式。

  • 精細化運營:從廣告產品來看涉及多個城市,多個商圈,可做一套精細化運營的系統,助力運營或幫助地推做精細化運營。

產品層面:

  • 廣告的變現模式:由簡單向複雜逐步衍化,從按天逐漸過渡到點選售賣,逐漸影響廣告主的認知。

  • 功能“傻瓜”化:功能方面儘量智慧化和傻瓜化,如廣告主並不知道出多少價格合適,變現系統的職責就是預估在當前情況下,收穫多少訂單、使用者等。

如把部分較為簡單、效果明顯提升的廣告推送給廣告主,同時把複雜部分包裝隱藏在演算法中,從而避免困擾廣告主,這稱之為“白+黑”解決方案。

第二:針對本地化、強地域限制的特點,美團推出“配送區”的概念。

一般來說,使用者點外賣時都很餓,不會選擇太遠的商家,同時商家也不願意配送太遠,這樣的現象稱之為“配送區”。

如上圖,藍色部分就是配送區,只有使用者定位在這個區域,才會展示這個店鋪,這樣的業務邏輯需要技術來實現,設計一個專門模組來做,使用者通過搜尋來獲取附近的店鋪列表。在業務模式下,對於廣告來說存在非常強的地域定向,對檢索架構的影響也很大。

第三:原生廣告佈設,如位置選擇、選擇優化和效果提升。

位置選擇,固定 OR 浮動,避免廣告主找不到廣告粉絲。

體驗優化,廣告會對使用者體驗產生影響,所以採用監控機制,從監控出發去優化使用者體驗。

效果提升,讓廣告主只花幾十塊錢就能感受到好的效果,交易類做 ROI 優化更直接。同時,系統會把投放產出比作為資料下發給商家。

CPT(按時長付費)的框架及策略

CPT 的技術框架。如下圖,是商業變現系統 CPT 技術的分層圖,分為負責廣告投放、流量管控的投放端,供廣告主管理賬戶使用的業務端和做區域劃分、定價的離線挖掘三層。

CPT 技術框架

這種按照時間來計費的廣告很直接,商家的接受程度較高。

CPT 的策略。涉及到廣告區的劃分、定價以及線下迭代這三方面問題

  • 廣告區劃分。廣告主在廣告區投放廣告,最直接的影響是假設商家一天只能接 100 單,但廣告效應導致一下爆單,會嚴重影響商家和使用者的體驗。

因此美團提出“廣告區“的概念,用技術手段來控制展現的資料量,幫商家做庫存的管理。同時也能根據冷熱地域進行廣告定價。

  • 廣告區定價。廣告區域劃分之後,流量、使用者等都需要預估,通過演算法模型實現動態定價。

線下迭代。判斷定價策略好不好,這裡要做售賣率預估,提前知道劃分和定價後整體的售賣率情況。

CPC(按點選付費)的架構與策略優化

1.CPC 線上整體架構

CPT 的售賣方式上線之後存在一些問題,如容量限制,當某城市需要買廣告的商戶可能近百近千時,會導致商戶使用的留存受到影響。通過商戶調研,系統發現它們對 CPT 產品接受度很高。因此,進一步上線一套更加複雜的系統 - CPC。

CPC 線上整體架構

如上圖,是 CPC 線上整體架構,業務端為商戶提供一個打理廣告的系統,同時會同步到 ToC 系統,也就是投放端,之後把對應的結果從後端發到前端,美團外賣或團購 APP。

使用者發生點選時傳送到計費端,會對廣告主計費。廣告主的錢花超,系統會發出告警,做下線操作。

2.CPC 線上架構的優化

高效能。從效能的角度,投放端是 ToC 的產品,效能方面的提升是必要的。方法如下:

  • 各模組非同步化:可達到立即執行的目的。

  • 優化核心演算法:對線上、線下的核心計算邏輯進行優化。系統可以做線下預計算,如分詞,挖掘演算法等,提升線上效率。

資料高一致。美團整個資料跨很多端,如何保證資料在流動過程中不出錯?方法如下:

  • 跨端同步。在資料跨端同步的過程中,通過 MQ 來解耦,進行失敗重試、冪等操作。

  • 超播。遇高點選率,超播會比較嚴重,這時需要引入 Pacing 機制。

  • 監控。針對資料流做災備和全量機制。跨端做資料監控,出現問題及時警告。

高可用。美團也遇到一些流量方面的問題,解決方法如下

  • 流量異常。因為一些爬蟲原因,會對系統執行造成影響,不處理會導致服務不可用,這裡會做反爬蟲機制。

  • 流量突增。針對流量突增,線下做全鏈路的壓測,監控。線上針對不同渠道做流量流控,針對不同流量做降級措施。同時,線上針對一些不是很重要的模組進行降級操作。

  • 技術元件。基礎元件部分,會針對儲存做一些跨機房解決方案,還有全公司使用統一中介軟體。應用服務部分,要有一些服務治理元件,當 Web 混合比較多時,需要做超時設定,並且針對 Web 服務做一些降級方案。

3.CPC 架構之策略優化

除上述支撐整個美團資料量上漲的架構層面,還有很多業務層面的功能需要優化。一般來說,業務都有幾個核心指標。在外賣廣告裡,核心指標是平臺收入、商戶投入產出比和使用者體驗度。

平臺、商戶和使用者之間存在著矛盾關係,優化商戶 ROI,平臺收入就會下降。重視廣告收入時,使用者數會下降。多方利益如何抉擇?方法如下:

  • 保證返購率。以使用者體驗為限制,在 1% 的情況下儘可能提升平臺的收入,提升廣告主的體驗。

  • 提升廣告主體驗。從效果和功能角度提升商業產品體驗,做到”品效合一”,質&量,PV&ROI 等效果。

4.CPC架構之受眾定向

廣告定向。從定向出發,把合適的流量給適合的廣告主,實際上是個流量篩選的方式,達到 ROI 與消耗的平衡,摸清流量和廣告度的關係。

白+黑解決方案。把簡單且剛需的功能,如地理位置、時間等這些簡單功能做定向,稱之為白盒。如使用者近百標籤,給到廣告主,大部分都玩不轉。這時就需要通過演算法進行包裝,把複雜內容包裝到系統,助力廣告主去做智慧投放,這稱之為黑盒。

5.CPC架構之排序

資料質量決定了模型的質量,特別是去年美團爬蟲流量比較多時,就需清洗爬蟲相關資料,還有清洗使用者行為的噪聲。解決方法如下:

這裡涉及到的主要特徵,稱之為 AUC,這三個之間還會有一些組合,如非線性模型+單特徵、線性模型+單特徵+組合特徵等。其中,在特徵選擇方面分為特徵維度和有效減少提取次數的特徵組維度。

6.CPC 架構之使用者行為建模

統一的使用者建模方案。使用者行為存在多樣性,如購買,點選、曝光、載入,和廣告、搜尋、推薦、分享等,這時候,如何把多種行為匯聚到一起,做統一的使用者建模方案?

其實每一個行為都是代表使用者背後的行為強度,如購買會比搜尋強,搜尋會比點選強,點選會比瀏覽強,這些都屬於訊號強度概念,通過這樣的關係把所有的行為對應的興趣綜合在一起,最後得到使用者統一的興趣方案。

統一使用者建模方案之時效性。使用者行為時效性分為長時、短時、即時,這三者如何融合?

解決方案是把行為與時間長度,都通過訊號強度綜合在一起,通過手動設定一些引數,也可通過把這些引數自動的選出。

結語

前幾年,外賣平臺的市場競爭異常激烈,依託資本的大力度補貼,搶佔市場爭奪使用者。美團經歷了萌芽、成長、擴張等環節,如今外賣平臺進入成熟期,對流量的使用已經變成核心競爭力之一

外賣平臺連線眾多商家與海量使用者,廣告是滿足商家營銷及平臺商業化訴求的一種常見有效的手段。在此背景下,針對外賣業務特性設計一套合理變現系統就顯得尤為重要。

以上內容由編輯王雪燕根據王興星老師在 WOTA2017 “大資料應用創新”專場的演講內容整理。

王興星

美團高階技術專家,外賣商業技術負責人

曾在搜狗、百度等公司供職,前搜狗 PC 和無線聯盟的演算法負責人,所研發的訓練系統應用於搜狗聯盟、DSP 等多個產品線,多次獲得公司最佳個人、技術部犀牛、MVP 等獎項。也是資料探勘愛好者,曾獲百度電影推薦大賽全國第一名、品友互動 RTB 演算法競賽線下/線上第一名,KDDCUP2012 全球第三名等獎項。

以上內容根據王興星老師在 WOTA2017 “大資料應用創新”專場的演講內容整理。

相關推薦

訂單1000是如何設計廣告系統的?

在 2013 年,美團一直靠資本推動拉新,到 2015 年,為了達到收支平衡,美團開始考慮商業變現。從 2016 年初到 2017 年,美團針對商業變現做了兩套廣告系統,並上線投入使用。本文由美團外賣商業技術負責人王興星與大家分享外賣業務合理變現系統的設計過程及相關經驗

訂單1600的自動化業務運維之路

背景 美團外賣業務在網際網路行業是非常獨特的,不僅流程複雜——從使用者下單、商家接單到配送員接單、交付,而且壓力和流量在午、晚高峰時段非常集中。同時,外賣業務的增長非常迅猛,自2013年11月上線到最近峰值突破1600萬,還不到4年。在這種情況下,一旦出現事故,單純靠人工排查解決問題,存在較多的侷限

MaxCompute助力ofo實現精細化運營:訂單3200、整體運行效率提升76%

數據庫摘要:ofo小黃車大數據BI系統負責人龍利民為大家分享了ofo的上雲體驗,重點分享了MaxCompute的應用實踐,最後對阿裏雲提出了自己的建議需求。 關於ofo小黃車 共享經濟不僅與技術相關,它還關乎人類共同命運,關乎可持續發展。 原文地址:http://click.aliyun.com/m/4396

【筆記】從架構到演算法詳解訂單分配內部機制

1)採用迭代的方式,通過訂單分配優化演算法進行初始的訂單分配,然後通過騎手路徑優化演算法獲取各騎手的最佳行駛路線,進而,訂單分配優化演算法根據騎手路徑優化結果調整分配方案。這兩個層次不斷反覆迭代,最終獲得比較滿意的解 (adsbygoogle = window.adsbygoogle

商家獲取訂單-signToken取值

post ima gsl ffffff hid eve extend -1 ati 所需工具: findller chrome 獲取外賣歷史訂單地址為: http://e.waimai.meituan.com/v2/order/history/r/query?getNe

訂單中心的演進

前言 美團外賣從2013年9月成交第一單以來,已走過了三個年頭。期間,業務飛速發展,美團外賣由日均幾單發展為日均500萬單(9月11日已突破600萬)的大型O2O網際網路外賣服務平臺。平臺支援的品類也由最初外賣單品拓展為全品類。 隨著訂單量的增長、業務複雜度的提升,外賣訂單系統也在不斷演變進化,從早期

詳解訂單分配內部機制

公司做外賣配送,正好又在做系統派單這塊,遇到很多很多的難點,某日看到了這篇文章,從理論的角度介紹了訂單內部分派機制。所以給抄了過來! 美團點評日前完成最新一輪融資,估值達到300億美元。此輪融資後將會在人工智慧、無人配送等前沿技術研發上加大投入。但我們並

移動Web APP開發之實戰 高清無密 百度網盤

管理 如何 第6章 代碼管理 view 優化 移動web webp flex 第1章 課程介紹 通過課程介紹,了解學習課程的必要性,所包含的知識點,課程安排,學習前提,課程收獲,快速全面了解課程。 1-1 課程導學 第2章 移動web硬知識點 本章主要講解移動web開發中必

移動Web APP開發之實戰

第1章 課程介紹 通過課程介紹,瞭解學習課程的必要性,所包含的知識點,課程安排,學習前提,課程收穫,快速全面瞭解課程。 1-1 課程導學 第2章 移動web硬知識點 本章主要講解移動web開發中必要掌握的基本知識,是進行後續學習的前提。從概述到開發除錯方法

WeGeek Talk |

今天前來專欄分享的極客,是來自美團外賣的小程式前端團隊。 在 2017 年 1 月 9 日,美團外賣作為首批小程式正式上線,截止到目前,美團外賣小程式 DAU 已近千萬。但事實上,美團外賣早期時更多的是主打手機網頁端,在美團外賣的小程式剛上線時並沒有過多去維護,之後才與微信官方有了更多交流。

最新移動Web APP開發之實戰

1.1 在設定中勾中Build project automatically 1.2 使用快捷鍵Ctrl + shift + alt + /,開啟Maintenance操作面板,選擇Registry,開啟Registry操作面板 1.3 找到並勾線"compiler.aut0mak

下午不知道吃什麼?用Python爬取評論幫你選餐!

一、介紹 朋友暑假實踐需要美團外賣APP評論這一份資料,一開始我想,這不就抓取網頁原始碼再從中提取資料就可以了嗎,結果發現事實並非如此,情況和之前崔大講過的分析Ajax來抓取今日頭條街拍美圖類似,都是通過非同步載入的方式傳輸資料,不同的是這次的是通過JS傳輸,其他的基本思路基本一致,希望那些資料

iOS App冷啟動治理:來自的實踐

一、背景 冷啟動時長是App效能的重要指標,作為使用者體驗的第一道“門”,直接決定著使用者對App的第一印象。美團外賣iOS客戶端從2013年11月開始,歷經幾十個版本的迭代開發,產品形態不斷完善,業務功能日趨複雜;同時外賣App也已經由原來的獨立業務App演進成為一個平臺App,陸續接入了閃購、跑腿等其他

iOS App冷啟動治理

一、背景 冷啟動時長是App效能的重要指標,作為使用者體驗的第一道“門”,直接決定著使用者對App的第一印象。美團外賣iOS客戶端從2013年11月開始,歷經幾十個版本的迭代開發,產品形態不斷完善,業務功能日趨複雜;同時外賣App也已經由原來的獨立業務App演進成為一個平臺App,陸續接入了閃購、跑腿等其他

訂餐網站原始碼模板多使用者帶後臺 仿餓了麼o2o

系統簡介: 網上訂餐系統,是石家莊晟訊網路科技有限公司為滿足眾多餐飲外賣企業的迫切需要,開發定製的一款成熟的“B2C網上訂餐系統”。目前已經運用到全國各地,網上點餐系統致力於幫助專業從事餐飲外賣企業或有外賣業務的餐飲企業快速部署外賣訂餐系統,拓展網路外賣訂餐業務

移動WebAPP開發之實戰視訊教程

第1章 課程介紹通過課程介紹,瞭解學習課程的必要性,所包含的知識點,課程安排,學習前提,課程收穫,快速全面瞭解課程。1-1 課程導學第2章 移動web硬知識點本章主要講解移動web開發中必要掌握的基本知識,是進行後續學習的前提。從概述到開發除錯方法,以及viewport視窗概念和原理的講解,在到移動web開發

微信小程式(初學篇)——仿

初識小程式,為它的小巧玲瓏所吸引,不由得心血來潮。這不正是使用者所需要的嗎?既方便快捷,又不佔手機記憶體。所以我下定決心一定要做出一個自己的小程式,然後賺錢、賺錢、賺錢...當然現在只是學習階段,所以先仿一個高階產品來挑戰自我吧。說到高階,自然然而的就想到了美團。之後噼裡啪

Android仿點菜聯動列表

Android高仿美團外賣點菜聯動列表效果 最近專案中有一個新增購物車的需求,需要做成美團外賣點菜聯動ListView的效果,可能有的朋友覺得這很簡單,不就是2個Listview點選事件聯動處理機制嗎?沒錯,基本思路就是這樣子,只是美團外賣點菜效果上有一種根據

爬蟲實戰----商家資料介面分析

本文發表於2017年11月6號,不保證其在之後的時間仍適用,只作例子分享 準備工作 抓包工具:Fiddler,Firebug等工具,此文使用Chrome瀏覽器自帶的抓包工具 介面分析(從H5端入手) 首先進入美團外賣h5的商家列表頁

接入 php後臺接入 laravel 常見問題

美團外賣請求的timestamp要求時間戳要精確到毫秒  不然會一直報時間戳過期的美團外賣回撥地址(ngrok 內網對映post請求不行,博主就被坑了)任何回撥地址都在本地postman上自己呼叫一下第一步申請開發者,確認已經申請成功,上面就是沒完全成功有賬號的但是還有其他在