【開源分享】微信營銷系統(第三方微信平臺)github 開源

升訊威微信營銷系統(微信第三方平臺)前端

在線體驗:http://wxcm.eeipo.cn/
開源地址GitHubhttps://github.com/iccb1013/Sheng.WeixinConstruction
做者:曹旭升 sheng.chao   git

說明:有問題上QQ羣交流github

QQ羣:173459027   591928344數據庫

做者最初的指望是實現一個微信雲平臺,相似於微盟,只須要商家掃碼綁定便可提供整套的營銷功能。
個人定位是專門服務於線下商家,例如電影院、商業中心、各種線下門店等,線下商家的一些業務場景和業務流程是比較特殊的,和純現上的公衆號運營不盡相同。 這是我最初想找到的切入點,在系統初步上線後,本身也試着作了推廣,包括百度關鍵詞、線下陌拜都嘗試過,這些細節有機會我會再詳細說一說。後端

本項目開源了所有工程和代碼,可直接編譯後進行部署運行。
微信第三方平臺的部署方法是須要先註冊微信開放平臺,而後申請第三方應用,通過審覈和接口聯調確認,就可使用了。跨域

本微信第三方平臺包括瞭如下功能: 瀏覽器

【吸粉】
投票、按期抽獎、聚人氣抽獎、搖一搖抽獎、粉絲海報、1元奪寶、發紅包、在線捐款 等 緩存

【持續變現】
微官網、微會員、積分商城、卡券、微信支付、分類信息、電影排片 等 安全

【管理考覈】
電腦手機雙後臺、營銷二維碼、後臺用戶管理、操做日誌 等備註:服務器

1、功能設計

1)設計目標

◇ 爲微信服務號提供運營及管理所需的各類功能,包括微官網、微會員、活動中心、營銷輔助、微信支付。

◇ 提供簡潔友好的功能畫面,使非專業技術人員也可以輕易的使用。

◇ 提供可獨立於系統以外的插件功能或接口,可輕易對接其它系統或功能模塊。

 

2)詳細設計

如圖,功能的設計從業務上劃分,分爲五大塊:

◇  微官網

         微主頁提供若干預置的模版,能夠經過上傳自定義的主題圖片造成本身的微主頁,對於有必定開發能力的使用者,提供模版引擎功能,使用一個相似於輕量級CMS的功能,定製本身的微主頁。

         電影排片須要寫一個蜘蛛程序進行抓取。

◇  微會員

         須要實現一套積分系統,包括在後臺對積分規則的設定。積分商城與大多數商城系統相似。

         卡券功能須要支持後臺派發和前端在線下經過二維碼覈銷,這一塊與微信原生卡券有一個重要區別,在於領取的方式,微信原生卡券主要是自主領取,好比掃碼、分享等,可是對於部分線下商戶,卡券的派發是要嚴格管控的,好比電影院的兌換券、景點的門票等,這種場景目前微信自帶卡券不能實現。

◇  活動中心

         必須將全部的活動所有模版化,使用戶可以簡單配置就發起活動,並在活動進行的過程當中提供運營數據報表。

◇  微信支付

         除了打通微信支付之外,須要提供線下的充值和消費能力,好比會員直接在線下向服務人員現金充值,或線下購物時刷二維碼消費本身預存的現金,這裏實際上意味着須要實現一套比較完整的消費系統。

◇  營銷輔助

         可以提供各類運營數據,並提供郵件通知、短信通知的能力。

 

2、架構設計

1)設計目標

◇  穩定可靠,低耦合高內聚,可維護性強。

         穩定可靠主要取決於設計及編碼水平,這個無需多解釋。低耦合高內聚應該也是你們都瞭解的原則,爲了實現這個目標,項目會按功能模塊進行拆分和抽象,具體拆分方式請見下文的詳細設計。

◇  易水平擴展,易運維。

         將高頻請求的部分和低頻請求的部分分解,將內網請求與外網請求分解,可分佈式部署,將內網請求部分徹底隔離在防火牆以後或內網環境中,並使對外的高頻請求的部分可經過增長服務器來增長承載能力。在設計之初就須要考慮負載均衡及CDN分發所帶來的問題,在負載均衡方面,咱們以負載均衡不開啓會話保持爲設計指標,此外,咱們須要將全部用戶上傳的文件,或發送的文件,在獨立的文件服務器存儲,以便於CDN分發和控制流量及帶寬,要知道服務器的流量及帶寬費用是至關可觀的,同時也避免文件傳輸對服務器帶寬的佔用而影響業務數據的處理能力。

◇  所選技術應用成熟,生產性(開發維護的效率)高,編碼實施難度較低,後續開發容易。

         在具體的技術選型上,選擇成熟穩定的技術方案,而不是「牛」的方案,這一點很是重要,由於咱們不是在作研究,咱們是在作項目。或者從另外一個角度來講,你對技術「牛」和「不牛」是怎樣理解的。在此項目中咱們考量如下幾個因素:

         a.是否成熟穩定,後續支持怎樣。成熟穩定一般表明着問題較少,團隊學習成本低,接納度高,後續支持指的是是否有商業公司或開源社區積極的維護更新。

         b.生產性怎樣,是否能夠提供足夠高的生產性。生產性指的是開發維護的效率,軟件開發過程當中最大的成本是人力成本,如何用更少的人作到更多的事,甚至說在市場競爭中你的速度快不快,都至關重要,對於商業項目,我不須要你知道回香豆的「回」有幾種寫法,我只要你又快又好的給我寫一百遍「回」字便可。

         能解決個人問題,成熟穩定,生產性高,能夠稱之爲「牛」的技術。

◇  數據庫必須支持分庫存儲

         基於承載能力擴展性和業務方面的考量,必需要可以將不一樣的公衆號數據存儲到不一樣的數據庫服務器上。

 

2)詳細設計

         架構設計我想分爲兩個部分說明,一是開發架構,二是部署架構。這兩個不一樣角度的設計互相影響或者互相制約,必須在設計期間就把握好大方向,作好這件事情須要設計者除了懂開發,還要懂運維,不然很容易形成前人挖坑後人填坑。

 

         1.開發架構

         注意圖上的一個矩形模塊並不必定就表明着一個程序集,一個邏輯上的「模塊」可能由多個程序集共同構成。

         從上向下簡單分析,首先是管理端的UI層和手機端的UI層,我習慣將之稱爲Shell。從圖上能夠看到管理端Shell和手機端Shell是分開的兩個模塊,在咱們的解決方案中它們是兩個不一樣的工程,我也看到過一些微信項目將管理端和手機端放在一個工程中,不管是從安全性、可維護性上說我都強烈不建議你這麼作。徹底分開的好處有不少,首先是部署成本,管理端通常狀況下是不須要應對大量請求的,而手機端有這個需求,在部署時管理端甚至只需一臺服務器便可,而手機端則須要更多的服務器和帶寬支撐,另外在工程的前期運維階段,管理端的版本發佈頻率可能高於手機端,徹底隔離的開發和部署能夠避免在發佈管理端時影響到手機端的業務,第二是安全性的問題,手機端從工程上就是徹底不包含任何管理功能的,能夠在必定程序上提升安全性。

         接下來是若干輔助服務,報表服務、文件服務,這兩個服務是獨立的Web工程。和管理端或手機端並非一一對應的關係,一個報表服務器或文件服務器能夠爲多臺管理端或手機端Shell提供服務。

         報表服務器直接提供報表查詢和顯示的畫面,嵌入在管理端中。

         文件服務器提供文件上傳下載功能,這個服務有幾個技術細節須要注意,聰明的你或許已經想到第一個問題:跨域上傳的問題。管理端和手機端都是獨立部署的,所使用的域名天然是不一樣的,那麼在瀏覽器中上傳就存在跨域的問題,不過這個問題並不難解決,我將的後續篇章中介紹,另外一個就是對於(嵌入在微信中的)手機端來講,是不能直接上傳文件的,必須先把文件發送到微信後臺,獲取媒體ID,再下載下來,這個過程須要文件服務器完成,最後是關注服務號的會員,發文件到服務號上,實際是發到了微信服務器,咱們的文件服務器要能異步的把這些文件從微信後臺下載下來。

         定時任務是一個或若干個Windows服務,用於定時執行一些業務。

         業務核心模塊這裏的介紹比較籠統,在項目中實際對應着實現不一樣功能的諸多程序集,限於篇幅和本章節的主旨,仍是留到後文中詳細說明業務核心的設計和實現。

         中控服務器主要的功能是維護調用微信API所需的AccessToken,與微信對接時,根據公衆號的AppId和AppSecert,你能夠獲取到一個有效期爲2個小時的AccessToken,調用幾乎全部的微信接口都須要這個         AccessToken,固然你不能在每次請求API時都獲取一個新的AccessToken,這是徹底沒有必要的,因此須要一個獨立的服務來處理這件事,其它模塊須要使用AccessToken時,從中控服務器獲取。

         微信SDK並非微信官方提供的,是項目裏須要本身實現的部分,微信官方並無提供完善的開發包,只有若干示例。網上有一些開源的微信SDK,可是或多或少存在一些問題,此處使用的是咱們本身實現的SDK包。

         基礎架構部分涉及到數據實體的定義、數據協議的定義等等,數據協議指的是各Web工程之間之前單個Web工程中先後端通訊所使用的協議。此外還包括許多共通的功能實現也在這裏。

         服務模塊封裝了項目中所需的許多服務,如:日誌、緩存、統一異常處理等等。

         最後是數據層,數據層沒有使用Entity Framework,使用的是個人另外一個開源項目S-ORM,下文的技術選型部分有簡略的說明和介紹。

 

         2. 部署架構



功能清單:

 

微官網 

運營數據

能夠按時段統計實時運營數據,如各項關注指標,積分訂單數據等。

微主頁

能夠經過模塊版自定義微主頁的樣式和功能,也能夠徹底經過代碼自定義,方便修改調整。

公衆號菜單

與微信官方的菜單管理功能打通,在平臺中管理髮佈菜單。

快捷菜單

在微信端打開的頁面上,懸浮一個快捷菜單,做爲公衆號菜單的補充。

分類信息

自定義顯示各項分類信息供粉絲查詢,如樓層導購,產品信息,導購員信息等等。

自定義頁面

自定義 H5 頁面實時發佈到微信端。

自定義表單

自定義表單供粉絲填寫,可用於收集粉絲信息等。

微會員

 

 

 

 

會員管理

與微信官方後臺的會員數據聯動,並在此基礎之上,實現積分管理,現金餘額管理,會員卡管理,等等一系列 CRM 相關功能。

羣發功能

與微信官方的信息羣發打通,在此基礎之上,能夠與平臺中的會員管理進行聯動,能夠根據平臺會員進行有針對性的篩選和定向的發送。

積分商城

一個完整的積分商城功能,支持積分購買、現金購買、積分加現金購買多種方式。 所購商品能夠在線下實時覈銷。

卡券

電子卡券功能,可在後臺根據須要製做不一樣功能、類型的電子卡券,派發給會員。會員在線下經過展現卡券的二維碼進行覈銷。可製做現金券,代金券,禮品券等等。

本卡券功能徹底爲線下場景設計,會員出示二維碼,工做人員線下掃碼覈銷。

會員多級推廣

爲會員生成一個專屬的推廣連接,引導會員分享,經過此連接引流的新會員,可爲老會員獎勵積分。

活動中心

投票

在後臺實時發起各種主題的投票活動,能夠配置活動的規則,會員參與活動、轉發,均可以獎勵積。

 

 

 

 

 

粉絲海報

在後臺發起粉絲海報活動後,上傳一張背景圖片,會員訪問活動頁面後,可自動生成一張帶有會員頭像和二維碼的海報圖片,粉絲轉發此圖片後,其它人掃描此二維碼可落地到指定的營銷頁面,並給會員獎勵積分。

按期抽獎

按期抽獎可根據週期(如一天、一週等),滾動的讓會員來營銷頁面報名,並在指定的週期結束時,自動開獎。會員轉發活動頁面也可獎勵積分。

聚人氣抽獎

會員訪問營銷頁面時,可自動得到一個抽獎碼。引導他把活動頁面進行轉發,分享,他的好友點

 

擊訪問以後,會獎勵他一個新的抽獎碼,引流的人數越多,抽獎碼越多,管理人員可在必定時間後,手工開獎。

搖一搖抽獎

經過手機的搖一搖功能,進行抽獎。在後臺配置好活動週期,獎品,中獎機率後,引導會員訪問營銷頁面,搖動手機進行抽獎。

在線捐款

與微信支付聯動,可發起各種不一樣的捐款活動,會員可在營銷頁面上直接使用微信支付捐款。

微信支付

1 元奪寶

與微信支付聯動,發起 1 元奪寶活動。

設置

基本設置

 

 

 

 

 

 

 

會員卡級別

能夠自定義不一樣的會員卡級別,金卡、銀卡等,併爲會員分配不一樣的會員卡。全部的會員都會有一個惟一且固定的會員卡號。

自動回覆

與微信官方的自動回覆聯動,可根據規則配置,自動爲會員回覆各種信息。

場景二維碼

場景二維碼與公衆號自帶二維碼功能一致,都是掃碼關注,可是場景二維碼能夠實現對粉絲來源的統計,知道粉絲是掃哪一個二維碼關注的公衆號,對於地推或不一樣渠道的推廣來講,能夠知道各渠道的引流效果。

素材管理

與微信官方後臺素材管理聯動,管理各種型不一樣的圖文素材。

加強圖文素材

與微信原有圖文素材相比,能夠實現粉絲轉發獎勵積分的功能。

廣告

能夠自定義圖片廣告,並顯示在微信平臺相關頁面上,能夠統計各廣告的展現,點擊次數,分析營銷效果。

系統

用戶管理

後臺用戶管理功能,並支持將用戶綁定到微信,直接在微信端使用微信版後臺。

 

我的信息

後臺用戶的我的信息維護。

 

修改密碼

全部密碼使用 MD5 加密傳輸及存儲。

 

操做日誌

記錄系統中的全部操做狀況。

 

更新日誌:

微分銷模塊功能(20180801)

1、後臺:
一、增長渠道管理;
二、增長返傭清單;
三、修改訂單詳情,添加返傭詳情;
四、添加查看下級功能;
五、添加審覈渠道人員入口;
六、後臺提供改價功能(解決部分地區有優惠的場景)
七、解決返傭是按照特色價格(例如扣除評測中心部分)
八、微主頁擴展「個人分銷Url」 {{#DCCenterUrl}}標籤

2、前端:一、增長「個人分銷」頁面:實現分銷相關的信息顯示和入口(個人返傭、個人下級、推廣海報、個人推廣碼、)二、增長「個人返傭」頁面;三、增長「個人下級」頁面;

相關文章
相關標籤/搜索