Appboy基于MongoDB的數據密集型實踐是怎樣的

這期內容當中小編將會給大家帶來有關Appboy基于MongoDB的數據密集型實踐是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Appboy正在過手機等新興渠道嘗試一種新的方法，讓機構可以與顧客建立更好的關系，可以說是市場自動化產業的一個前沿探索者。在移動端探索上，該公司已經取得了一定的成功，知名產品有iHeartMedia、PicsArt、Etsy、Samsung、Urban Outfitters等。

以下演講摘錄：

為了支撐其營銷自動化平臺，Appboy為其分析和定位引擎使用了MongoDB作為其主要數據存儲層。時下，Appboy每天需要處理上萬用戶的數十億數據點。本文將分享Appboy關于MongoDB的最佳實踐，看看該公司如何在規模迅速擴大后仍然保持敏捷。本文將談及諸多話題，如文檔隨機抽樣、多變量測試及其Multi-arm bandit optimization、Field tokenization，以及Appboy如何在一個個體用戶基礎上存儲多維數據從而優化以最佳的時間給終端用戶提供信息。

Part 1：Statistical Analysis

Appboy適用于各種大小的客戶群體，其中包括了只有數萬用戶的初級客戶，也有客戶已經擁有了數千萬用戶。但是毫無疑問的是，通過Appboy營銷自動化技術，即使擁有上億用戶規模的客戶仍然可以便捷地收集和儲存用戶數據。

Appboy平臺的核心是customer segmentation（客戶細分）。segmentation允許機構根據行為數據、消費史、技術特性、社交概要等來定位。創新和智能的使用Segmentation和信息自動化使機構可以無縫地、輕松地將安裝用戶轉化為活躍的用戶，從而斬獲kpi，Segments可以按需定制。

當客戶使用Appboy儀表板定義segment時，Appboy可以在一些特征上做實時計算，比如群體大小、開通消息推送的用戶規模、用戶平均消費能力。這些計算需要實時和交互式的，而在不具備谷歌規模的基礎設施上，在這種規模上做交互式分析是極具挑戰的。這里存在的挑戰是如何更有效率的支撐如此規模，以及如何服務于各種體積的用戶。基于這些原因，隨機抽樣是個不錯的選擇。

關于統計抽樣

在現實世界中，隨機的統計抽樣時刻發生著，比如針對美國總統的輿情調查不可能去單獨的問每個人，全國收視率統計也并不是靠評級機構查看每個用戶的電視機。相反，這些數來源于統計抽樣，統計抽樣通過抽樣小部分群體來獲得更大群體的特征。通過統計數據，1個小樣本就可以對大規模群體做出準確的評估。許多政治民意調查只調查幾千成年人就可以估計數以百萬計的公民的政治傾向。但調查機構的報告與統計也經常帶有所謂的置信區間，也稱為偏差。

統計抽樣的使用

相同的原則可以運用到這里。與傳統分析數據庫相比，抽樣用戶有一個明顯的優勢，因為這里可以從用戶的整體行為上進行抽樣，而不是從原始事件流中取樣。需要注意的是，Appboy只針對segment 交互式反饋做抽樣，從而在網絡儀表板反饋。當做營銷活動或對Segment進行分析作為Facebook Custom Audience 時，準確用戶會被計算，而這些原則并不適用。

在開始時，會在已知范圍document 內添加一個隨機數字，稱之為“bucket”。選擇一個合理的小用戶群，從而有可能聚焦每個用戶，需要注意的是，這個抽樣規模乘以bucket的數量必須覆蓋該范圍。舉個例子，只選擇了1到10的抽樣顯然不可以支撐上億規模，1到100萬顯然是個不錯的選擇。在Appboy共擁有1萬個“bucket”，所以應該是0到9999。

假設這里有1000萬個documents（代表用戶），首先將給這些文檔加個數字并對其索引。

{
random: 4583,
favorite_color: “blue”,
age: 29,
gender: “M”,
favorite_food: “pizza”,
city: “NYC”,
shoe_size: 11
}

db.users.ensureIndex({random:1})

第一步是獲得1個隨機樣本。1000萬個document ，10000隨機的buckets，每個buckets應該有1000個用戶：

db.users.find({random: 123}).count() == ~1000<br>db.users.find({random: 9043}).count() == ~1000<br>db.users.find({random: 4982}).count() == ~1000

如果抽取整個用戶基礎的1%，那就是10萬的用戶。為了實現這一點，必須選擇一個隨機范圍來“托管”這些用戶。舉個例子，這些都是可以的：

db.users.find({random: {$gt: 0, $lt: 101})
db.users.find({random: {$gt: 503, $lt: 604})
db.users.find({random: {$gt: 8938, $lt: 9039})
db.users.find({$or: [
{random: {$gt: 9955}}, 
{random: {$lt: 56}}
])

在有了隨機樣本后，下一步就是對其分析。要衡量其真正的大小，首先需要進行一個計數，因為鑒于隨機性這里不可能精確到100000。

在并行的方式，這里可以在樣本上添加任意查詢，這里拿找出最喜歡藍色的男性用戶比例。

sample_size = db.users.find({random: {$gt: 503, $lt: 604}).count()
observed = db.users.find({random: {$gt: 503, $lt: 604}, gender: “M”, favorite_color: “blue”).count()

假如，樣本大小設定是100000，觀察數是11302。從這里可以推斷出，在1000萬用戶中有11.3%的用戶符合標準。要稱為優秀的統計學家，還應該提供一個置信區間來估計偏離值。置信區間背后的數學有點復雜，但是，如果想自己嘗試的話，有無數樣本sizecalculators可供參考。本文使用的案例中，置信區間為+ / - 0.2%。

優化

在實踐中，當執行統計抽樣時，Appboy基于這些高等級概念概念做了大量優化。首先，Appboy使用MongoDB聚合框架，并且大量使用緩存。因為這里使用的是內存映射存儲引擎，對于這種抽樣，使用MongoDB的好處是一旦將隨機樣本加載到內存就可以運行任意查詢。這么做為web儀表盤上提供了卓越的體驗，用戶可以通過添加和刪除選擇標準并立即看到統計數據更新，從而用戶可以進行交互式探索。

Part 2：多變量測試和比率限制

多變量測試的快速入門

在當今競爭激烈的市場中，用戶細分是必不可少的。隨著經驗與品牌繼續快速轉向移動等新興渠道，對營銷來說，信息定制化和關聯性性比以往更加重要，這就是用戶分類為什么會成為與客戶交互的先決條件。

因此一旦定義了一個劃分，下一個目標是優化消息推送使其轉換最大化，多變量測試則是實現這一目標的一種途徑。多變量測試是一個實驗，用來比較用戶對相同營銷活動多個不同推廣手段的反應。這些版本擁有相同的營銷目標，但在措辭和風格上有所不同，而多變量測試的目標就是為了確定哪個版本能達到最好的轉換。

例如，假設您有3個不同的推送通知消息：

• Message 1：This deal expires tomorrow!

• Message 2：This deal expires in 24 hours!

• Message 3：Fourth of July is almost over! All deals end tomorrow!

此外，除下消息，通常還會測試大量的圖片搭配合文本。

使用多變量測試，機構可以發現哪種措辭產生更高的轉化率。在下次發送推送式通知談生意時，就可以知道哪種語氣和措辭更有效。更好的是，可以通過限制測試的大小，比如在一小部分聽眾內，找出哪些消息更有效，然后發送這些有效的消息給其他人。

在進行一個多變量測試時，消息推送的目標是測試全體，但是同一細分中的其他用戶不會收到該條消息。從而，機構可以通過對比兩種反應來進行評估。

技術應用

從技術的角度來看，接收消息的人應該是隨機的。也就是說，如果你有100萬用戶且想要發送一個測試給50000人，這50000人應該是隨機分布在你的用戶群里（你還想要另一組5000用戶為對照組）。同樣的，如果你想測試10到50000用戶，隨機性有助于確保每個測試組的用戶都不同。

思考這個問題，它與1個消息中的比率限制問題是一行。許多客戶想要給一小群用戶發送一條消息。比如，一個電子商務公司想隨機的在用戶群中發放50000個優惠碼。這在概念上，是同樣的問題。

為了實現這一點，這里可以通過每個文檔上的隨機值來掃描用戶

Appboy會在不同的隨機范圍內通過隨機值用并行處理的方式來管理用戶。并追蹤全局狀態，因此可以知道何時達到比率的極限。對于多變量測試而言，隨后還會通過發送比率或者是隨機地選擇一個消息版本。

注意

那些有數學思維的人可能已經注意到，如果在隨機字段中使用統計分析，并基于相同的隨機字段選擇個體接收消息，那么在某些情況下，將會產生偏差。為了闡釋這一說法，假定使用隨機bucket值為10來選擇所有用戶，給他們隨機發送消息。這意味著，在這個用戶bucket中收到消息的用戶將不再是隨機分布。作為一個簡單的解決方案，Appboy對用戶使用多個隨機值，注意不要為了多個目的使用相同的隨機值。

Part 3：模式靈活——可擴展的用戶配置文件

在每個用戶打開Appboy的任意一個應用，一個豐富的用戶概要文件都會被創建。用戶的基本字段看起來是這樣：

{
first_name: “Jane”,
email: “jane@example.com”,
dob: “1994-10-24”,
gender: “F”,
country: “DE”,
...
}

Appboy客戶端還可以存儲每個用戶的“自定義屬性”。作為一個例子，一個體育應用程序可能想存儲用戶“最喜歡的球員”，而電子商務應用程序可能會存儲客戶最近購買的品牌等。

{
first_name: “Jane”,
email: “jane@example.com”,
dob: 1994-10-24,
gender: “F”,
custom: {
brands_purchased: “Puma and Asics”,
credit_card_holder: true,
shoe_size: 37,
...
},
...
}

這么做一個巨大的好處是，這些自定義屬性可以在其他屬性更新時直接插入。因為MongoDB提供靈活的模式，添加任意數量的自定義字段都很容易而，且不用擔心它的類型（boolean、string、intege、float又或是什么)。MongoDB會處理這一切，而查詢自定義屬性也很容易理解。針對一個value列，這里不提供復雜的連接，而在傳統關系型數據庫中你往往需要提前定義。

db.users.find(…).update({$set: {“custom.loyalty_program”:true}})
db.users.find({“custom.shoe_size” : {$gt: 35}})

這么做的缺點是，如果用戶不小心在客戶端中使用非常長的名稱來定義(“this_is_my_really_long_custom_attribute_name_it_represents_shoe_size”)或者是被MongoDB，在MongoDB的早期版本中它會占用大量的空間。另外，因為類型不是強制的，這里也可能出現跨documents值類型不匹配問題。1個document可能列出某人{ visited_website: true}，但是如果不小心，另一個就可能是{ visited_website: “yes”}。

Tokenization

為了解決第一個問題，通常會使用1個map來切分用戶屬性名稱。通常情況下，這可以是MongoDB中的一個documents，比如將“shoe_size”值映射成一個獨特的、可預測的短字符串。只要使用MongoDB的自動操作，就可以生成這種映射。

在映射中，通常會使用數組進行存儲，數組索引是“token”。每個客戶至少有一個document會包含list的數組字段。當首次添加一個新的自定義屬性時，可以自動把它放到列表最后，生成索引(“token”)，并在第一次檢索后緩存：

db.custom_attribute_map.update({_id: X, list: {$ne: "Favorite Color"}}, {$push: {list: "Favorite Color"}})

可能會有這樣一個列表：

[“Loyalty Program”, “Shoe Size”, “Favorite Color”]
            0            1            2

MongoDB最佳實踐需要警示documents的不斷增長，而自Appboy定義起，documents就存在無限增長的情況。實際上，這個潛在的問題已經被考慮，而這里則是通過限制數組大小來讓用戶使用多個documents。當給列表添加新的項時，如果數組長度小于一定規模，更新操作只能局限于$push。如果更新操作沒有生成1個新$push，一個自動的$findAndModify可以用來創建一個新文檔并添加元素。

Tokenization確實增加了一些間接和復雜性，但它可以自定義映射屬性，從而在整個代碼庫傳遞。這個解決方案同樣可以應用到其他問題上，可以是數據類型文檔中不匹配。在這里同樣可以使用映射來追蹤數據類型。例如，記錄“visited_website”是一個boolean，只接受true或者false。

第4部分：數據密集型算法

Intelligent Selection和Multi-Arm Bandit Multivariate Testing

多變量測試目標是，在最短的時間內尋找最高的轉化率，當下已經可以在大量平臺上發現，客戶會定期進行測試，并發現最好的那個。

Appboy一種叫做Intelligent Selection（智能選擇）的特性，該特性可以分析多變量測試的性能，并依據統計算法自動調整接收到不同版本消息的用戶比例。這里的統計算法可以確保獲得最真實的性能，而不是隨機的可能性，該算法被稱為themulti-arm bandit。

multi-arm bandit背后的數學算法非常復雜，本文不會闡述，這里不妨著眼劍橋大學數理統計學教授Peter Whittle 在1979年的發言：

[The bandit problem] 是二戰期間被正式提出的，為了解決它，盟軍分析師絞盡腦汁，備受折磨，以至于建議把這個問題拋給德國，作為知識戰的終極手段。

但提出這個算法的理由表明，為了有效地運行，the multi-arm bandit算法需要輸入大量的數據。對于每個消息版本，該算法會計算接受者以及轉換率。這就是MongoDB發光的地方，因為可以使用pre-aggregated analytics實時地自動積累數據：

{
company_id: BSON::ObjectId,
campaign_id: BSON::ObjectId,
date: 2015-05-31,
message_variation_1: {
unique_recipient_count: 100000,
total_conversion_count: 5000,
total_open_rate: 8000,
hourly_breakdown: {
0: {
unique_recipient_count: 1000,
total_conversion_count: 40,
total_open_rate: 125,
...
},
...
},
...
},
message_variation_2: {
...
}
}

通過這樣1個模式,可以快速查看每天和每小時的轉換變化,打開并發送。Appboy模式稍微復雜一點，因為這里還存在其他需要考慮的因素，這里需要注意。

預聚合 documents允許快速終止實驗。鑒于為每個公司對collection進行分片，這里可以以擴展的方式同時優化某個公司的全部活動。

智能交付

Appboy提供給客戶的另一個專有算法稱為智能交付。當規劃消息活動部署時，Appboy分析出給每個用戶發送消息的最優時間，并在正確的時刻提供可顧客。比如Alice更可能在晚上獲取應用程序推送信息，而Bob則喜歡把這個事情放在早上上班前，那么Appboy將會在他們最樂意的時間推送消息。這是個能創造奇跡的特性，正如Urban Outfitters CRM和Interactive Marketing負責人Jim Davis所稱贊的：

對比使用前后的打開比率，可以看到表現提升了1倍。針對男性Urban On members一周活動目標提升了138%。此外，細分功能也值得稱贊，提升了3個月以上不活躍用戶94%。

這種算法無疑是數據密集型，要智能地預測出給每個客戶發送消息的最佳時間，必須清楚的分析出這個用戶的行為特征。除此之外，Appboy每天將發送數千萬智能交付消息，所以這里需求一個非常高的預測。

這里的方法是類似于Intelligent Selection，主要通過實時地在每個用戶的基礎上預聚合多個維度完成。有了MongoDB，每個用戶都有很多documents，類似下面代碼：

{
_id: BSON::ObjectId of user,
dimension_1: [DateTime, DateTime, …],
dimension_2: [Float, Float, …],
dimension_3: […],
...
}

當所關心的用戶維度數據進入時，應使其正規化，并保存documents的副本。通過{_id: “hashed”}對每個documents進行，從而讓讀寫分布的更優化。當需要用Intelligent Delivery發送一條消息，這里可以快速地查詢一系列documents，并送到機器學習算法。在這個方面，MongoDB帶來的幫助很大，其可擴展性當下已支撐系統的數十個維度。而隨著新的維度被添加，這個機器學習算法被不停的修改，而這個過程一直受益于MongoDB的靈活。

上述就是小編為大家分享的Appboy基于MongoDB的數據密集型實踐是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。