銀行--天氣對用戶消費行爲的影響--地理位置營銷模型

  做爲諮詢行業的技術顧問,服務於各個銀行等金融機構,基於用戶的業務特色推出適合用戶的解決方案。這個方案是最近一個月爲某銀行量身定作的營銷方案,最後由於數據的問題被砍掉了。由此我想到,馬雲爸爸說的大數據是新的石油是正確的,可是個人解讀是,並非數據越多越好,而是數據的多樣性越多越好,只有這樣才能將各類各樣的數據聯繫結合起來挖掘他們的價值,僅僅只有一方面大量的數據也難以挖掘出石油。html

1,背景介紹  api

  有一個多月在爲某銀行作解決方案,客戶沒有明確的需求,只是想作點有價值的東西,可是不知道作什麼,同時要求成本小見效快。風蕭蕭兮易水寒 壯士一去兮不復還,託着我29寸行李箱來到客戶現場後,在和客戶密切交流了半個月後,我結合客戶的的整個數據和業務狀況我另闢蹊徑推出了《探索-天氣對人消費偏好的影響下的地理位置的活動商戶營銷》。微信

  這個思路的背景來源於以前服務的某信用卡中心,當時是基於CEP規則進行配置的,用戶推送什麼商戶徹底是業務人員根據自身經驗進行配置的。客戶使用信用卡消費後,信用卡中心會拿到消費的信息裏面包括地理位置的信息,而後根據配置的CEP規則選擇一個商戶的活動信息,經過各類渠道微信,短信等推送給用戶。大數據

  這種方式去作營銷,相比傳統向全部用戶發送活動信息的暴力方式,它縮小的營銷的人羣,只有在活動商戶附件的人收到營銷信息了纔可能去店裏刷羊肉,離活動商戶50千米以上的客戶基本會認爲是垃圾短信,極大的提升了營銷的轉化率,同時也節省了發短信的費用。
編碼

2,天氣,節日對用戶消費偏好影響影響spa

  傳統基於業務經驗的方式進行營銷是沒有任何問題的,只是徹底能夠業務決策和數據決策相輔去進行營銷,經過挖掘用戶消費偏好和天氣的聯繫,咱們進一步縮小營銷的用戶範圍,結合地理位置,在不一樣的天氣情況下向用戶推薦更符合本身口味的活動商戶。htm

  用戶消費偏好和天氣情況,節日都是有必定聯繫的,挖掘他們之間的聯繫在合適的天氣,合適的節日向合適的用戶去營銷。在上面的思路上,再加上用戶的籍貫做爲一個維度,不一樣的籍貫他們的口味是有很大的差別的,上海人喜歡甜,重慶人喜歡辣。(或者不須要,針對每個人的用戶偏好模型,不可取,地理位置營銷作到人這麼細沒有太大意義)blog

  推薦模型 天氣:籍貫——消費偏好
排序

 

3,分析數據支撐情況接口

  歷史數據:信用卡交易數據:交易金額,交易時間,交易商戶(pos機來講,位置信息的獲取,固定的能夠的,移動的不能。網銀交易走第三方支付寶更是拿不到位置信息,可是若是走信用卡APP支付則能夠拿取地理位置。固然,辦法多,好比不少信用卡都會綁定該信用卡的微信公衆號獲取交易信息,這個時候間接經過微信去拿用戶地理位置也是能夠的,更甚至用戶沒有開GPS,能夠和電信合做,根據最近的基站獲取用戶的大體位置範圍。

  支付寶,微信交易的交易數據中商戶名稱要進行去噪,有些不具備參考意義,好比我在一個麪館用微信消費,顯示的商戶爲包頭農村商業銀行,因此咱們要過濾掉這些商戶信息後進行中文語義分析,這一塊難度是比較大的,或者不去噪了。

  POS機和信用卡APP交易的商戶名稱以及銀聯報文MCC碼。MCC是Merchant CategoryCode的簡寫,中文名稱是商戶行業代碼。全國有幾千萬上億的商戶,銀聯給商戶布POS的時候,會設置一個商戶編號,這個編號是大有講究的,這個編號一般是 15 位,由機構代碼(3位)+地區代碼(4位)+商戶類型MCC碼(4位)+商戶順序號(4位)組成,而MCC碼是這個商戶編號的重要組成部分。http://www.360doc.com/content/18/0128/08/35924208_725696422.shtml MCC碼錶 

  一機一碼,持卡人在商家的POS機上刷卡消費成功後會打印出小票,上面有商戶編號,從第8位到11位(4位數)即爲商家這臺POS機的mcc碼,這個碼對應的就是商家經營的行業。

4,實施思路

  第一步:歷史交易數據本行APP交易的交易數據獲取交易位置信息(數據量比較少);微信,支付寶交易經過用戶綁定的微信公衆號間接獲取交易發生的位置信息;pos機交易經過pos機的地區代碼能夠知道發生交易的城市(沒法精確到區)。至此咱們已經對歷史交易記錄補全了位置信息。

  第二步:根據交易信息補充交易位置信息,同時結合交易時間去天氣服務供應商查詢該地區當時的天氣狀況。

  第三步:整理交易數據關鍵字段:用戶籍貫,交易金額,交易時間,MCC碼,交易地點,天氣。

  咱們能夠根據城市編碼調用高德接口獲取該城市的天氣(歷史交易數據補全當時天氣能夠去掉其餘api獲取,高德不支持歷史天氣查詢,這裏不討論細節問題):

  高德返回的天氣現象碼錶 53種,咱們精簡一下:

  第四步:半年一批次,統計出每種天氣下,每種籍貫交易類型最多的商戶類型。(交易金額做爲一個門檻,以防大量小筆的便利店交易的噪音影響)

  第五部:半年一批次,統計出每一個節日下,交易類型最多的商戶類型。(交易金額做爲一個門檻,以防大量小筆的便利店交易的噪音影響)
好比營銷的合做商戶交易門檻都是50,那麼統計消費偏好過濾掉50如下的金額。或者折中,4個偏好模型,天氣-商戶-50元門檻,天氣-商戶-無消費門檻,節日(包含節日先後5天)-商戶-50元門檻,節日(包含節日先後5天)-商戶-無消費門檻。

  ps:是否須要在統計每個用戶消費金額區間來做爲一個決策方式?有些用戶基本消費習慣都是50元如下,那麼向他推薦200元以上的消費也是沒法促進轉化率的

  咱們已經能夠跑出什麼天氣或什麼節日下不一樣的籍貫用戶更加喜歡進行什麼類型的消費,以此做爲依據結合與信用卡合做的活動商戶進行精準匹配推薦。 實時交易發生之後,對交易數據處理後獲得關鍵信息交易金額,交易時間,交易商戶MCC,交易地點(大部分比較模糊沒法精確到區),天氣,而後去模型中獲取到能夠推薦的商戶列表(可是這裏面不是合做商戶)。這裏建議:由於商戶都要行業碼錶,因此將合做商戶的數據替換到偏好模型裏面。而後從偏好模型中依次遍歷,判斷的條件是該用戶是否還有優惠,若是沒有優惠,則推送下一個有優惠的商戶。同時要判斷商戶在用戶的周邊。

  例如:偏好模型 天氣-商戶-無消費門檻

  目前沒法根據店名識別是賣什麼的,只能人工去打標籤。天氣情況不超過50種,每種天氣消費類型偏好排序10也就500個,模型數據跑出來後,根據店名去補充。同時錄入的合做商戶也會帶有消費類型(人工添加)。

5,死亡

  最後由於MCC碼不許確那麼後面細化方案就沒有意義了。業務知識大小額支付系統的交易流動方式。

相關文章
相關標籤/搜索