摘要：相反，這些數(shù)來源于統(tǒng)計(jì)抽樣，統(tǒng)計(jì)抽樣通過抽樣小部分群體來獲得更大群體的特征。但調(diào)查機(jī)構(gòu)的報(bào)告與統(tǒng)計(jì)也經(jīng)常帶有所謂的置信區(qū)間，也稱為偏差。在進(jìn)行一個(gè)多變量測(cè)試時(shí)，消息推送的目標(biāo)是測(cè)試全體，但是同一細(xì)分中的其他用戶不會(huì)收到該條消息。

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

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

以下演講摘錄：

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

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

Appboy 平臺(tái)的核心是 customer segmentation（客戶細(xì)分）。segmentation 允許機(jī)構(gòu)根據(jù)行為數(shù)據(jù)、消費(fèi)史、技術(shù)特性、社交概要等來定位。創(chuàng)新和智能的使用 Segmentation 和信息自動(dòng)化使機(jī)構(gòu)可以無縫地、輕松地將安裝用戶轉(zhuǎn)化為活躍的用戶，從而斬獲 kpi，Segments 可以按需定制。

當(dāng)客戶使用 Appboy 儀表板定義 segment 時(shí)，Appboy 可以在一些特征上做實(shí)時(shí)計(jì)算，比如群體大小、開通消息推送的用戶規(guī)模、用戶平均消費(fèi)能力。這些計(jì)算需要實(shí)時(shí)和交互式的，而在不具備谷歌規(guī)模的基礎(chǔ)設(shè)施上，在這種規(guī)模上做交互式分析是極具挑戰(zhàn)的。這里存在的挑戰(zhàn)是如何更有效率的支撐如此規(guī)模，以及如何服務(wù)于各種體積的用戶?；谶@些原因，隨機(jī)抽樣是個(gè)不錯(cuò)的選擇。

在現(xiàn)實(shí)世界中，隨機(jī)的統(tǒng)計(jì)抽樣時(shí)刻發(fā)生著，比如針對(duì)美國總統(tǒng)的輿情調(diào)查不可能去多帶帶的問每個(gè)人，全國收視率統(tǒng)計(jì)也并不是靠評(píng)級(jí)機(jī)構(gòu)查看每個(gè)用戶的電視機(jī)。相反，這些數(shù)來源于統(tǒng)計(jì)抽樣，統(tǒng)計(jì)抽樣通過抽樣小部分群體來獲得更大群體的特征。通過統(tǒng)計(jì)數(shù)據(jù)，1個(gè)小樣本就可以對(duì)大規(guī)模群體做出準(zhǔn)確的評(píng)估。許多政治民意調(diào)查只調(diào)查幾千成年人就可以估計(jì)數(shù)以百萬計(jì)的公民的政治傾向。但調(diào)查機(jī)構(gòu)的報(bào)告與統(tǒng)計(jì)也經(jīng)常帶有所謂的置信區(qū)間，也稱為偏差。

相同的原則可以運(yùn)用到這里。與傳統(tǒng)分析數(shù)據(jù)庫相比，抽樣用戶有一個(gè)明顯的優(yōu)勢(shì)，因?yàn)檫@里可以從用戶的整體行為上進(jìn)行抽樣，而不是從原始事件流中取樣。需要注意的是，Appboy 只針對(duì) segment 交互式反饋?zhàn)龀闃樱瑥亩诰W(wǎng)絡(luò)儀表板反饋。當(dāng)做營銷活動(dòng)或?qū)?Segment 進(jìn)行分析作為 Facebook Custom Audience 時(shí)，準(zhǔn)確用戶會(huì)被計(jì)算，而這些原則并不適用。

在開始時(shí)，會(huì)在已知范圍 document 內(nèi)添加一個(gè)隨機(jī)數(shù)字，稱之為「bucket」。選擇一個(gè)合理的小用戶群，從而有可能聚焦每個(gè)用戶，需要注意的是，這個(gè)抽樣規(guī)模乘以 bucket 的數(shù)量必須覆蓋該范圍。舉個(gè)例子，只選擇了1到10的抽樣顯然不可以支撐上億規(guī)模，1到100萬顯然是個(gè)不錯(cuò)的選擇。在 Appboy 共擁有1萬個(gè)「bucket」，所以應(yīng)該是0到9999。

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

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

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

第一步是獲得1個(gè)隨機(jī)樣本。1000萬個(gè) document ，10000隨機(jī)的 buckets，每個(gè) buckets 應(yīng)該有1000個(gè)用戶：

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

如果抽取整個(gè)用戶基礎(chǔ)的1%，那就是10萬的用戶。為了實(shí)現(xiàn)這一點(diǎn)，必須選擇一個(gè)隨機(jī)范圍來「托管」這些用戶。舉個(gè)例子，這些都是可以的：

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}}
])

在有了隨機(jī)樣本后，下一步就是對(duì)其分析。要衡量其真正的大小，首先需要進(jìn)行一個(gè)計(jì)數(shù)，因?yàn)殍b于隨機(jī)性這里不可能精確到100000。

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

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()

假如，樣本大小設(shè)定是100000，觀察數(shù)是11302。從這里可以推斷出，在1000萬用戶中有11.3%的用戶符合標(biāo)準(zhǔn)。要稱為優(yōu)秀的統(tǒng)計(jì)學(xué)家，還應(yīng)該提供一個(gè)置信區(qū)間來估計(jì)偏離值。置信區(qū)間背后的數(shù)學(xué)有點(diǎn)復(fù)雜，但是，如果想自己嘗試的話，有無數(shù)樣本 sizecalculators 可供參考。本文使用的案例中，置信區(qū)間為+ / - 0.2%。

在實(shí)踐中，當(dāng)執(zhí)行統(tǒng)計(jì)抽樣時(shí)，Appboy 基于這些高等級(jí)概念概念做了大量?jī)?yōu)化。首先，Appboy 使用 MongoDB 聚合框架，并且大量使用緩存。因?yàn)檫@里使用的是內(nèi)存映射存儲(chǔ)引擎，對(duì)于這種抽樣，使用 MongoDB 的好處是一旦將隨機(jī)樣本加載到內(nèi)存就可以運(yùn)行任意查詢。這么做為 web 儀表盤上提供了卓越的體驗(yàn)，用戶可以通過添加和刪除選擇標(biāo)準(zhǔn)并立即看到統(tǒng)計(jì)數(shù)據(jù)更新，從而用戶可以進(jìn)行交互式探索。

在當(dāng)今競(jìng)爭(zhēng)激烈的市場(chǎng)中，用戶細(xì)分是必不可少的。隨著經(jīng)驗(yàn)與品牌繼續(xù)快速轉(zhuǎn)向移動(dòng)等新興渠道，對(duì)營銷來說，信息定制化和關(guān)聯(lián)性性比以往更加重要，這就是用戶分類為什么會(huì)成為與客戶交互的先決條件。

因此一旦定義了一個(gè)劃分，下一個(gè)目標(biāo)是優(yōu)化消息推送使其轉(zhuǎn)換最大化，多變量測(cè)試則是實(shí)現(xiàn)這一目標(biāo)的一種途徑。多變量測(cè)試是一個(gè)實(shí)驗(yàn)，用來比較用戶對(duì)相同營銷活動(dòng)多個(gè)不同推廣手段的反應(yīng)。這些版本擁有相同的營銷目標(biāo)，但在措辭和風(fēng)格上有所不同，而多變量測(cè)試的目標(biāo)就是為了確定哪個(gè)版本能達(dá)到最好的轉(zhuǎn)換。

例如，假設(shè)您有3個(gè)不同的推送通知消息：

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!

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

使用多變量測(cè)試，機(jī)構(gòu)可以發(fā)現(xiàn)哪種措辭產(chǎn)生更高的轉(zhuǎn)化率。在下次發(fā)送推送式通知談生意時(shí)，就可以知道哪種語氣和措辭更有效。更好的是，可以通過限制測(cè)試的大小，比如在一小部分聽眾內(nèi)，找出哪些消息更有效，然后發(fā)送這些有效的消息給其他人。

在進(jìn)行一個(gè)多變量測(cè)試時(shí)，消息推送的目標(biāo)是測(cè)試全體，但是同一細(xì)分中的其他用戶不會(huì)收到該條消息。從而，機(jī)構(gòu)可以通過對(duì)比兩種反應(yīng)來進(jìn)行評(píng)估。

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

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

為了實(shí)現(xiàn)這一點(diǎn)，這里可以通過每個(gè)文檔上的隨機(jī)值來掃描用戶：

Appboy 會(huì)在不同的隨機(jī)范圍內(nèi)通過隨機(jī)值用并行處理的方式來管理用戶。并追蹤全局狀態(tài)，因此可以知道何時(shí)達(dá)到比率的極限。對(duì)于多變量測(cè)試而言，隨后還會(huì)通過發(fā)送比率或者是隨機(jī)地選擇一個(gè)消息版本。

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

在每個(gè)用戶打開 Appboy 的任意一個(gè)應(yīng)用，一個(gè)豐富的用戶概要文件都會(huì)被創(chuàng)建。用戶的基本字段看起來是這樣：

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

Appboy 客戶端還可以存儲(chǔ)每個(gè)用戶的「自定義屬性」。作為一個(gè)例子，一個(gè)體育應(yīng)用程序可能想存儲(chǔ)用戶「最喜歡的球員」，而電子商務(wù)應(yīng)用程序可能會(huì)存儲(chǔ)客戶最近購買的品牌等。

{
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,
...
},
...
}

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

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

這么做的缺點(diǎn)是，如果用戶不小心在客戶端中使用非常長(zhǎng)的名稱來定義(「this_is_my_really_long_custom_attribute_name_it_represents_shoe_size」)或者是被 MongoDB，在 MongoDB 的早期版本中它會(huì)占用大量的空間。另外，因?yàn)轭愋筒皇菑?qiáng)制的，這里也可能出現(xiàn)跨 documents 值類型不匹配問題。1個(gè)document 可能列出某人{ visited_website: true}，但是如果不小心，另一個(gè)就可能是{ visited_website: “yes”}。

為了解決第一個(gè)問題，通常會(huì)使用1個(gè) map 來切分用戶屬性名稱。通常情況下，這可以是 MongoDB 中的一個(gè) documents，比如將「shoe_size」值映射成一個(gè)獨(dú)特的、可預(yù)測(cè)的短字符串。只要使用 MongoDB 的自動(dòng)操作，就可以生成這種映射。

在映射中，通常會(huì)使用數(shù)組進(jìn)行存儲(chǔ)，數(shù)組索引是「token」。每個(gè)客戶至少有一個(gè) document 會(huì)包含 list 的數(shù)組字段。當(dāng)首次添加一個(gè)新的自定義屬性時(shí)，可以自動(dòng)把它放到列表最后，生成索引(「token」)，并在第一次檢索后緩存：

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

可能會(huì)有這樣一個(gè)列表：

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

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

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

多變量測(cè)試目標(biāo)是，在最短的時(shí)間內(nèi)尋找最高的轉(zhuǎn)化率，當(dāng)下已經(jīng)可以在大量平臺(tái)上發(fā)現(xiàn)，客戶會(huì)定期進(jìn)行測(cè)試，并發(fā)現(xiàn)最好的那個(gè)。

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

multi-arm bandit 背后的數(shù)學(xué)算法非常復(fù)雜，本文不會(huì)闡述，這里不妨著眼劍橋大學(xué)數(shù)理統(tǒng)計(jì)學(xué)教授 Peter Whittle 在1979年的發(fā)言：

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

但提出這個(gè)算法的理由表明，為了有效地運(yùn)行，the multi-arm bandit 算法需要輸入大量的數(shù)據(jù)。對(duì)于每個(gè)消息版本，該算法會(huì)計(jì)算接受者以及轉(zhuǎn)換率。這就是 MongoDB 發(fā)光的地方，因?yàn)榭梢允褂?pre-aggregated analytics 實(shí)時(shí)地自動(dòng)積累數(shù)據(jù)：

{
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個(gè)模式,可以快速查看每天和每小時(shí)的轉(zhuǎn)換變化,打開并發(fā)送。Appboy 模式稍微復(fù)雜一點(diǎn)，因?yàn)檫@里還存在其他需要考慮的因素，這里需要注意。

預(yù)聚合 documents 允許快速終止實(shí)驗(yàn)。鑒于為每個(gè)公司對(duì) collection 進(jìn)行分片，這里可以以擴(kuò)展的方式同時(shí)優(yōu)化某個(gè)公司的全部活動(dòng)。

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

對(duì)比使用前后的打開比率，可以看到表現(xiàn)提升了1倍。針對(duì)男性 Urban On members 一周活動(dòng)目標(biāo)提升了138%。此外，細(xì)分功能也值得稱贊，提升了3個(gè)月以上不活躍用戶94%。

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

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

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

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

本文討論了系統(tǒng)的主要設(shè)計(jì)思想，而這一切都得益于 MongoDB 靈活的模式和強(qiáng)擴(kuò)展性。而通過 MongoDB，Appboy 在數(shù)據(jù)密集型工作上取得了一個(gè)很大的成功。

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

本文系 |6803da6e1241c3b46359f28d015fd7e314| 工程師編譯整理。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問 OneAPM 官方博客。