TWI613559B - 一種記錄資訊傳播的方法 - Google Patents

Abstract

本發明所提供的一種記錄資訊傳播的方法，包括步驟：A、獲取對被分享物件的分享資訊；所述分享資訊的屬性包含所述被分享物件、由各分享資訊傳播方構成的分享鏈條；B、判斷當前用戶對所述分享資訊進行分享時，將當前用戶作為一分享資訊傳播方載入至所述分享鏈條末端，構建出本次分享鏈條；C、當分享資訊的被分享物件被該分享資訊中的分享鏈條中的任一分享資訊傳播方進行購買時，對該分享鏈條中該分享資訊傳播方之前的分享資訊傳播方進行記錄。由上，詳細記載資訊傳輸的參與者以及傳輸路徑，對於在資訊傳輸過程中可能帶來的如返利等計算，提供了良好的資料支援。

Description

一種記錄資訊傳播的方法

本發明涉及電子資訊處理技術領域，特別涉及一種記錄資訊傳播的方法。

返利是指供貨方將自己的部分利潤返還給銷售方或用戶的一種行銷模式，它不僅可以激勵銷售方提升銷售業績，同時也能刺激用戶進行更多的購買消費。

在返利過程中，需要記錄所銷售商品的返利鏈條，所述返利鏈條所記錄的資訊包括但不限於以下幾類：參與的物件(例如傳播者、傳播物件)、各個參與物件在返利鏈條中所扮演的角色(不同的會員級別或傳播的先後順序)、銷售商品被分享的次數和返利模式等等。

對於返利鏈條，最為重要的便是對於資訊傳播的有效記錄，如圖1所示的返利鏈條，其包含了電商中的多種角色，各種角色穿插於多種返利、多級返利模式中。此種情況下，對於資料記錄、傳播要求、計算方式，比普通的返利模式將更為複雜。所以，對應資料存儲要求、傳播行為記錄要求、返利計算要求都會比普通返利模式要高很多。若採用現有技術基於返利鏈條的資訊傳播記錄，則存在多種弊端，例如：1、資訊傳輸過程中，所傳播的資訊與傳播者、傳播物件、會員級別、財務等多種業務深度耦合；2、多級返利鏈條帶來的傳播記錄與作弊。

有鑒於此，本發明的主要目的在於，提供一種記錄資訊傳播的方法，包括步驟：A、獲取對被分享物件的分享資訊；所述分享資訊的屬性包含所述被分享物件、由各分享資訊傳播方構成的分享鏈條；B、判斷當前用戶對所述分享資訊進行分享時，將當前用戶作為一分享資訊傳播方載入至所述分享鏈條末端，構建出本次分享鏈條；以及C、當分享資訊的被分享物件被該分享資訊中的分享鏈條中的任一分享資訊傳播方進行購買時，對該分享鏈條中該分享資訊傳播方之前的分享資訊傳播方進行記錄。

由上，詳細記載資訊傳輸的參與者以及傳輸路徑，對於在資訊傳輸過程中可能帶來的如返利等計算，提供了良好的資料支援。

可選的，所述步驟B之後還包括：B1：對所構建出本次分享鏈條進行去重處理，去除重複出現的各分享資訊傳播方；B2：判斷去重後的所述分享鏈條的分享層級是否大於100，當大於100時，僅保留前後各50層級。

可選的，在步驟B1中的所述去重處理包括：當重複出現分享資訊傳播方時，將後出現的分享資訊傳播方刪除，將排在該分享資訊傳播方前、後的分享資訊傳播方相連，構建出本次分享鏈條。

由上，將化簡後的分享鏈條作為原分享鏈條的子集，依據化簡後的分享鏈條進行返利計算，僅當化簡後的分享鏈條無法滿足返利規則要求時，才啟用原始分享鏈條，從起防止返利過程中的作弊情況發生。

可選的，在所述步驟B2後還包括：將所述構建出的本次分享鏈條進行緩存；以及每間隔一定時間，將所述緩存的分享鏈條與永久存儲的分享鏈條進行同步共用。

由上，通過對於分享鏈條的緩存，實現防止大資料分享鏈條衝擊，導致出現死機或者查詢緩慢等情況。

可選的，判斷步驟A中所述分享鏈條是否為首次分享的步驟；若非首次分享，則在緩存中查詢所述分享鏈條，進而執行步驟B； 若緩存中不包含該分享鏈條，則還包括在永久存儲中查詢分享鏈條的步驟，進而執行步驟B。

由上，針對已有的分享鏈條，首先在緩存中查詢，從而避免在永久存儲中過大資料的查詢篩選，保證快速的拿到新的分享鏈條。

可選的，步驟C還包括：依據記錄資訊，對所述對該分享鏈條中該分享資訊傳播方之前的分享資訊傳播方進行相應返利，所述返利包括：根據分享鏈條中的各個分享資訊傳播方的順序確定分享層級；以及根據所述不同的分享層級進行不同級別的返利。

可選的，所述返利包括：選定從首級開始的前四個分享層級作為返利的層級；以及所述其他層級僅享受消費返利。

可選的，所述返利包括：從進行所述購買的分享資訊傳播方開始，其前四個連續的分享層級作為返利的層級。

可選的，所述返利包括：將第一個分享資訊傳播方作為原創者，所述原創者位於所述分享鏈條的首級；選定從首級開始的前五個分享層級作為返利的層級；所述其他層級僅享受消費返利。

可選的，所述返利包括：將第一個分享資訊傳播方作為原創者，所述原創者位於所述分享鏈條的首級；以及從進行所述購買的分享資訊傳播方開始，其前四個連續的分享層級以及所述首級作為返利的層級。

在參閱下文實施方式後，本發明所屬技術領域中具有通常知識者當可輕易瞭解本發明之基本精神及其他發明目的，以及本發明所採用之技術手段與實施態樣。

S10~S30‧‧‧步驟

S401~S411‧‧‧步驟

圖1為返利鏈條示意圖；圖2為本發明基於記錄資訊傳播的方法的返利方法的流程圖；圖3為記錄資訊傳播的方法的流程圖；圖4-7分別為四類返利規則的原理示意圖；以及圖8為實現記錄資訊傳播的系統原理示意圖。

為了使本揭示內容的敘述更加詳盡與完備，下文針對了本發明的實施態樣與具體實施例提出了說明性的描述；但這並非實施或運用本發明具體實施例的唯一形式。實施方式中涵蓋了多個具體實施例的特徵以及用以建構與操作這些具體實施例的方法步驟與其順序。然而，亦可利用其他具體實施例來達成相同或均等的功能與步驟順序。

為克服現有技術存在的缺陷，本發明提供一種記錄資訊傳播的方法，詳細記載資訊傳輸的參與者以及傳輸路徑，對於在資訊傳輸過程中可能帶來的如返利等計算，提供了良好的資料支援。

圖2所示為返利方法的流程圖，包括以下步驟：針對已成功支付的訂單，首先執行步驟S10~S30，即獲取已支付訂單的資訊。

本實施例中，採用如步驟S20所述的資訊佇列(MQ，Message Queue)獲取訂單的資訊。步驟S30中，解析出該訂單的分享鏈條(Kid)。所述分享鏈條即為該訂單被不同分享物件的分享次數。舉例來說，假如分享鏈條為a-->b-->c-->d-->e，在該鏈條中，a、b、c、d、e分別代表五個分享物件，即不同分享物件的id(userid)，該分享鏈條的分享層級為四級。假如分享鏈條為b-->c-->a-->a，在該鏈條中，a、b、c分別代表三個分享物件，由於a-->a為重複分享，則該分享鏈條的分享層級為二級。

步驟S40：在資料庫中查詢該訂單所包含商品的分享鏈條。

如圖3所示，針對分享鏈條的生成，即本發明記錄資訊傳播的方法包括以下步驟：

步驟S401：確定分享商品。

步驟S402：獲取所述分享商品的分享鏈條。

本實施例中，商品的分享鏈條僅包括分享用戶以及分享層級。

步驟S403：依據分享鏈條判斷該商品是否為首次分享，若首次分享則執行步驟S407；否則執行步驟S404。

本實施例中，若分享鏈條為空，則表示該商品為首次分享。

步驟S404：在緩存中查詢分享鏈條。

本實施例中，對於分享鏈條的存儲目的地包括緩存(Redis)和資料庫管理系統(MySQL)，對於兩存儲目的地的選擇將在後文進行詳述。

步驟S405：在Redis中查詢是否已存儲有分享鏈條，若是則進入步驟S408，否則進入步驟S406。

步驟S406：在MySQL中查詢分享鏈條。結束本步驟後，進入步驟S408。

步驟S407：生成一分享id。

針對於商品的首次分享，記錄分享物件的id，例如，a、b或c等等均為分享物件的id。記錄後，進入步驟S408。

步驟S408：確定分享鏈條。

針對首次被分享的商品，記錄其首次分享鏈條。例如由用戶h首次分享，則執行步驟S408後的新分享鏈條便為h。

針對存儲目的地所查詢出的分享鏈條，將本次分享添加至查詢出的原分享鏈條中，從而形成新的分享鏈條。例如查詢出的原分享鏈條為a-->b-->c-->d-->e，本次由用戶h再次分享，執行步驟S408後的新分享鏈條便為a-->b-->c-->d-->e-->h。

步驟S409：針對同步調用，將分享鏈條緩存至Redis中。

所述緩存時間可以設置為3天。

步驟S410：針對非同步調用，將分享鏈條永久存儲至MySQL中。

步驟S409和步驟S410中所述的同步調用和非同步調用屬於消息通信機制(Synchronous Communication/Asynchronous Communication)。所述同步調用，指在發出一個調用時，在沒有得到結果之前，該調用就不返回。但是一旦調用返回，得到返回值。即，由調用者主動等待調用的結果。而非同步調用則是相反，調用在發出之後，這個調用就直接返回了，所以沒有返回結果。即，當一個非同步調用程序呼叫發出後，調用者不會立刻得到結果。而是在調用發出後，被調用者通過狀態、通知來告知調用者，或通過回調函數處理這個調用。

具體到本實施例，同步調用是指確定分享鏈條已存儲入庫。非同步調用是指發起入庫請求，但不確定已入庫成功即返回。

本實施例增加步驟S409的目的在於：在將資料存儲至MySQL之前，增加將資料緩存至Redis的步驟，從而可以實現防止大資料分享鏈條衝擊MySQL，導致MySQL出現死機或者查詢緩慢等情況。在生成分享鏈條後，針對同步調用，緩存到Redis裏，針對非同步調用，存儲到MySQL中，可以保證快速獲取到分享鏈條。

進一步的，以每24小時為間隔，將Redis中緩存的資料與MySQL中存儲的分享鏈條進行同步共用操作。

較佳的，所述Redis採用集群技術，從而進一步降低死機出現的可能性。

步驟S411：依據步驟S408所確定的分享鏈條，生成商品的統一資源定位符(URL)。

本步驟中，採用固定演算法，將步驟S408中確定的分享鏈條(例如a-->b-->c-->d-->e)計算轉換為該商品的統一資源定位符(URL，Uniform Resource Locator)。所述統一資源定位符作為該商品在分享鏈條中位置和訪問方法的一種簡潔的表示，是分享鏈條上商品的位址，每個商品都有一個唯一的URL。

本實施例中，所述URL包含商品名稱、分享層級和分享物件等資訊。進一步的，所述URL還可包含成交時間、以及獲取分享的途徑等其他資訊，所述途徑包括但不限於微信、QQ或者微博等社交應用。將分享鏈條計算轉換為該商品的統一資源定位符的具體的轉換演算法採用現有技術，本發明 不進行限定。所述商品的統一資源定位符採用HBase存儲，從而提供大資料量、高併發I/O讀寫。

結束步驟S40後，執行步驟S31，所述步驟S31包括：依據所述統一資源定位符計算商品返利。

執行本步驟前，還包括化簡分享鏈條的步驟。本實施例中，記錄商品的所有分享鏈條稱為all_path記錄。在後續計算商品返利過程中，若採用all_path記錄，顯然會出現許多重複分享，導致商品返利不準確。本步驟中，對all_path記錄進行化簡，對化簡後的分享鏈條稱為path記錄。path是all_path的子集，具體的，path中存儲分享鏈條的最大分享層級為100，首先進行去重處理，例如分享鏈條為b-->c-->a-->a時，去重處理後的分享鏈條即變為b-->c-->a。又如當某一分享物件間隔出現在分享鏈條中的情況，例如分享鏈條為a-->b-->c--d-->b-->e，則在後續返利過程中，去重處理後的分享鏈條即變為a-->b-->c-->d-->e。其次，若去重處理後分享鏈條的層級仍大於100時，去掉中間的路徑，前後各保存50個層級進行存儲。

在實際應用中，返利的層級是3-5級，由於all_path記錄可能會很長且大部分資訊是返利計算用不到的，所以本實施例採用更短的path記錄來進行返利計算。僅當path中獲取不到必要的資訊時，例如path中的層級少於預設的返利規定，返回all_path中獲取。

圖4~圖7為本實施例所採用的返利規則，包括以下四類：

一、無種子會員有限級4+1模式。

如圖4所示，A表示第一個加入者(會員)，B~F分別表示第二至六級的被邀請用戶，B₁~B_N分別表示同級別的第二級被邀請用戶，同理C₁~C_N、D₁~D_N……。由A級向下分享資訊，此種模式下，返利從A級到D級為止。E級不在分享鏈條中，不再有獎勵。但E級及以後的會員有其他獎勵，例如消費獎勵，節留下的返利歸支付方所有。

即，此種模式下，僅將分享鏈條的前四分享層級作為返利鏈條，自第五分享層級起，不再享受分享返利，僅可以享受消費返利。

二、無種子會員無限級4+1模式。

如圖5所示，A表示第一個加入者(會員)，B~F分別表示第二至六級的被邀請用戶，B₁~B_N分別表示同級別的第二級被邀請用戶，同理 C₁~C_N、D₁~D_N……。由A級向下分享資訊，A~D為資訊分享鏈條，D級為終止點。當D級轉發E級時，B級變為1級，A級此時不在分享鏈條中。當E級轉發F級時，C級變為1級，此時A、B均不在分享鏈條中。

即，此種模式下，在分享鏈條中，以支付的訂單為節點，該支付訂單的前四個連續層級作為返利鏈條。

三、有種子會員有限級1+4模式。

如圖6所示，A表示第一個加入者(會員)，B~F分別表示第二至六級的用戶，B₁~B_N分別表示同級別的第二級用戶，同理C₁~C_N、D₁~D_N……。原創者的資格不變，由原創者向A級下分享資訊，再由A級向下分享資訊，A級~D級為一個分享鏈條，D級再進行轉發時，不再計入分享鏈條，僅A~D四級。E級以後的會員參與其他返利(例如消費返利)，留下的返利歸支付方所有。

即，此種模式下，僅將原創者以及分享鏈條的前四分享層級作為返利鏈條，自第五分享層級起，不再享受分享返利，僅可以享受消費返利。

四、有種子會員無限級1+4模式。

如圖7所示，A表示第一個加入者(會員)，B~F分別表示第二至六級的用戶，B₁~B_N分別表示同級別的第二級用戶，同理C₁~C_N、D₁~D_N……。原創者的資格不變，由原創者向A級向下分享資訊，由A級向下分享資訊，A~D為分享鏈條，D級為終止點。當D級轉發E級時，B級變為1級，此時A級不在分享鏈條中。當E級轉發F級時，C級變為1級，此時A、B均不在分享鏈條中。

即，此種模式下，在分享鏈條中，以支付的訂單為節點，該支付訂單的前四個連續層級以及原創者作為返利鏈條。

步驟31中，依據上述不同的返利規則，結合商品的統一資源定位符分別計算出不同層級的返利結果。

圖8為本實施例的實現返利計算的系統原理示意圖，包括應用層、業務層和存儲層。

所述應用層包括帳戶系統、商品系統、商戶系統、APP、訂單系統、資訊系統、財務系統和會員系統。不同物件對應實現不同功能，例如帳 戶系統存儲有不同用戶的資訊、商品系統存儲有所銷售商品的資訊等等，具體不再贅述。

所述業務層包括返利管理模組、返利計算模組、分享鏈條處理模組、返利查詢模組和非同步存儲模組。

其中，返利管理模組其內部還包括返利計畫設置模組，用於執行返利計畫設置，即設置圖1所對應的內容。

返利規則設置模組，用於設置返利規則，即對應設置無種子會員有限級4+1模式、無種子會員無限級4+1模式、有種子會員有限級1+4模式和有種子會員無限級1+4模式等具體返利規則。

返利規則引擎，分別與所述返利計畫設置模組和返利規則設置模組連接，用於實現上述兩模組的資訊交互。

返利計算模組用於執行返利計算，即步驟31所對應內容。

分享鏈條處理模組包括分享鏈條生成模組和分享鏈條計算模組，其中分享鏈條生成模組用於執行步驟401~409。分享鏈條計算模組用於執行步驟411。

返利查詢模組用於執行步驟40。

非同步存儲模組用於執行步驟410。

存儲區包括MySQL、Redis和HBase。其中MySQL用於永久存儲分享鏈條；Redis用於緩存分享鏈條；HBase用於存儲商品的統一資源定位符。

以上所述僅為本發明的較佳實施例而已，並不用以限制本發明。例如，在所述分享鏈條中還包括以下表1中的資訊。

表1中的Id表示這張資料表的自增主鍵，URL表示在先所述的統一資源定位符、from表示每一步分享鏈條的分享管道，比如，微信、微博、QQ或者app等。skuid表示一個唯一的最小的產品單位。譬如iphone 16G金色，對應一個skuid。itemId表示一類產品，譬如iphone這類有一個唯一的itemid。time表示本次分享的時間。Userid表示分享用戶的id，Distsaleid表示分銷id， 電商的內部概念，可以任意設置。IsFirst表示是否為首次分享，若是可顯示為1，不是顯示為0。總之，凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。

S401~S411‧‧‧步驟

Claims (8)

1. 一種記錄資訊傳播的方法，包含以下步驟：A、獲取對被分享物件的分享資訊，所述分享資訊的屬性包含所述被分享物件、由各分享資訊傳播方構成的分享鏈條；B、判斷當前用戶對所述分享資訊進行分享時，將當前用戶作為一分享資訊傳播方載入至所述分享鏈條末端，構建出本次分享鏈條；以及C、當分享資訊的被分享物件被該分享資訊中的分享鏈條中的任一分享資訊傳播方進行購買時，對該分享鏈條中該分享資訊傳播方之前的分享資訊傳播方進行記錄；所述步驟B之後更包含：B1：對所構建出本次分享鏈條進行去重處理，去除重複出現的各分享資訊傳播方；以及B2：判斷去重後的所述分享鏈條的分享層級是否大於100，當大於100時，僅保留前後各50層級；在所述步驟B2後更包含：將所述構建出的本次分享鏈條進行緩存；以及每間隔一定時間，將所述緩存的分享鏈條與永久存儲的分享鏈條進行同步共用。
2. 根據請求項1所述的方法，其中在步驟B1中的所述去重處理包含：當重複出現分享資訊傳播方時，將後出現的分享資訊傳播方刪除，將排在該分享資訊傳播方前、後的分享資訊傳播方相連，構建出本次分享鏈條。
3. 根據請求項2所述的方法，更包含判斷步驟A中所述分享鏈條是否為首次分享的步驟； 若非首次分享，則在緩存中查詢所述分享鏈條，進而執行步驟B；若緩存中不包含該分享鏈條，則還包括在永久存儲中查詢分享鏈條的步驟，進而執行步驟B。
4. 根據請求項1所述的方法，其中步驟C更包含：依據所記錄的資訊，對所述該分享鏈條中該分享資訊傳播方之前的分享資訊傳播方進行相應返利，所述返利包含：根據分享鏈條中的各個分享資訊傳播方的順序確定分享層級；以及根據所述不同的分享層級進行不同級別的返利。
5. 根據請求項4所述的方法，其中所述返利包含：選定從首級開始的前四個分享層級作為返利的層級；以及所述其他層級僅享受消費返利。
6. 根據請求項4所述的方法，其中所述返利包含：從進行所述購買的分享資訊傳播方開始，其前四個連續的分享層級作為返利的層級。
7. 根據請求項4所述的方法，其中所述返利包含：將第一個分享資訊傳播方作為原創者，所述原創者位於所述分享鏈條的首級；選定從首級開始的前五個分享層級作為返利的層級；以及所述其他層級僅享受消費返利。
8. 根據請求項4所述的方法，其中所述返利包含：將第一個分享資訊傳播方作為原創者，所述原創者位於所述分享鏈條的首級；以及從進行所述購買的分享資訊傳播方開始，其前四個連續的分享層級以及所述首級作為返利的層級。