摘要：相反，這些數來源于統計抽樣，統計抽樣通過抽樣小部分群體來獲得更大群體的特征。但調查機構的報告與統計也經常帶有所謂的置信區間，也稱為偏差。在進行一個多變量測試時，消息推送的目標是測試全體，但是同一細分中的其他用戶不會收到該條消息。

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

【編者按】本文摘錄自 Appboy 聯合創始人兼 CIO Jon Hyman 在 MongoDB World 2015 上的演講。Appboy 正在過手機等新興渠道嘗試一種新的方法，讓機構可以與顧客建立更好的關系，可以說是市場自動化產業的一個前沿探索者。在移動端探索上，該公司已經取得了一定的成功，知名產品有 iHeartMedia、PicsArt、Etsy、Samsung、Urban Outfitters 等。本文主要包括 Statistical Analysis、Multivariate Testing and Rate Limiting、Flexible Schemas: Extensible User Profiles 和 Data Intensive Algorithms 四方面內容，本文系 OneAPM 工程師編譯整理。

以下演講摘錄：

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

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
db.users.find({random: 9043}).count() == ~1000
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 儀表盤上提供了卓越的體驗，用戶可以通過添加和刪除選擇標準并立即看到統計數據更新，從而用戶可以進行交互式探索。

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

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

例如，假設您有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 對用戶使用多個隨機值，注意不要為了多個目的使用相同的隨機值。

在每個用戶打開 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”}。

為了解決第一個問題，通常會使用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。

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

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 的靈活。

本文討論了系統的主要設計思想，而這一切都得益于 MongoDB 靈活的模式和強擴展性。而通過 MongoDB，Appboy 在數據密集型工作上取得了一個很大的成功。

原文鏈接：Remaining Agile with Billions of Documents: Appboy’s Creative MongoDB Schemas

本文系 |6803da6e1241c3b46359f28d015fd7e314| 工程師編譯整理。想閱讀更多技術文章，請訪問 OneAPM 官方博客。