Appboy基于MongoDB的數(shù)據(jù)密集型實(shí)踐是怎樣的

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)Appboy基于MongoDB的數(shù)據(jù)密集型實(shí)踐是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

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

以下演講摘錄：

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

Part 1：Statistical Analysis

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

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

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

關(guān)于統(tǒng)計(jì)抽樣

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

統(tǒng)計(jì)抽樣的使用

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

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

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

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

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

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

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

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

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ī)樣本后，下一步就是對其分析。要衡量其真正的大小，首先需要進(jìn)行一個計(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)該提供一個置信區(qū)間來估計(jì)偏離值。置信區(qū)間背后的數(shù)學(xué)有點(diǎn)復(fù)雜，但是，如果想自己嘗試的話，有無數(shù)樣本sizecalculators可供參考。本文使用的案例中，置信區(qū)間為+ / - 0.2%。

優(yōu)化

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

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

多變量測試的快速入門

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

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

例如，假設(shè)您有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!

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

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

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

技術(shù)應(yīng)用

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

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

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

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

注意

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

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

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

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

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

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

這么做一個巨大的好處是，這些自定義屬性可以在其他屬性更新時直接插入。因?yàn)镸ongoDB提供靈活的模式，添加任意數(shù)量的自定義字段都很容易而，且不用擔(dān)心它的類型（boolean、string、intege、float又或是什么)。MongoDB會處理這一切，而查詢自定義屬性也很容易理解。針對一個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)是，如果用戶不小心在客戶端中使用非常長的名稱來定義(“this_is_my_really_long_custom_attribute_name_it_represents_shoe_size”)或者是被MongoDB，在MongoDB的早期版本中它會占用大量的空間。另外，因?yàn)轭愋筒皇菑?qiáng)制的，這里也可能出現(xiàn)跨documents值類型不匹配問題。1個document可能列出某人{(lán) visited_website: true}，但是如果不小心，另一個就可能是{ visited_website: “yes”}。

Tokenization

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

在映射中，通常會使用數(shù)組進(jìn)行存儲，數(shù)組索引是“token”。每個客戶至少有一個document會包含list的數(shù)組字段。當(dāng)首次添加一個新的自定義屬性時，可以自動把它放到列表最后，生成索引(“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最佳實(shí)踐需要警示documents的不斷增長，而自Appboy定義起，documents就存在無限增長的情況。實(shí)際上，這個潛在的問題已經(jīng)被考慮，而這里則是通過限制數(shù)組大小來讓用戶使用多個documents。當(dāng)給列表添加新的項(xiàng)時，如果數(shù)組長度小于一定規(guī)模，更新操作只能局限于$push。如果更新操作沒有生成1個新$push，一個自動的$findAndModify可以用來創(chuàng)建一個新文檔并添加元素。

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

第4部分：數(shù)據(jù)密集型算法

Intelligent Selection和Multi-Arm Bandit Multivariate Testing

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

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

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

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

但提出這個算法的理由表明，為了有效地運(yùn)行，the multi-arm bandit算法需要輸入大量的數(shù)據(jù)。對于每個消息版本，該算法會計(jì)算接受者以及轉(zhuǎn)換率。這就是MongoDB發(fā)光的地方，因?yàn)榭梢允褂胮re-aggregated analytics實(shí)時地自動積累數(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個模式,可以快速查看每天和每小時的轉(zhuǎn)換變化,打開并發(fā)送。Appboy模式稍微復(fù)雜一點(diǎn)，因?yàn)檫@里還存在其他需要考慮的因素，這里需要注意。

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

智能交付

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

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

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

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

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

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

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