【導讀】指導下進行的研究工作及取得的成果。盡我所知，除文中特別加以標注。和致謝的地方外，不包含其他人或組織已經(jīng)發(fā)表或公布過的研究成果，了明確的說明并表示了謝意。的規(guī)定，即：按照學校要求提交畢業(yè)設計（論文）的印刷本和電子版本；閱覽服務；學?？梢圆捎糜坝　⒖s印、數(shù)字化或其它復制手段保存論文；在不以贏利為目的前提下，學?？梢怨颊撐牡牟糠只蛉績?nèi)容。重要貢獻的個人和集體，均已在文中以明確方式標明。本聲明的法律后果由本人承擔。本人授權大學可以將本學位論文的全。涉密論文按學校規(guī)定處理。紙應符合國家技術標準規(guī)范。的移動社交軟件“微信”逐漸走進了手機用戶的生活，深受全國數(shù)億用戶的歡迎。微信不僅改變了人們的生活方式，本文梳理了在移動互聯(lián)網(wǎng)環(huán)境下網(wǎng)絡營銷的特點、現(xiàn)狀以及微信帶來的影響，的設計思路，并提出了相應的技術解決方案。在微信公眾平臺的開發(fā)模式下，采用

　　

【正文】 從平臺用戶方面，平臺需要滿足用戶 查看信息的功能，還需要有在線咨詢、建議投訴之類和商家進行交流的功能，目的是用戶通過這個平臺獲得更好的服務。然后就商家方面而言，主要需要平臺給他們提供信息發(fā)布，內(nèi)容管理，會員管理等功能，目的是為自己招攬更多顧客 ， 促成更多的消費行為 [14]。 平臺用戶的功能需求 （ 1）商家信息的瀏覽 用戶在第一次關注公眾號時，商家可以發(fā)送文本或者圖文的歡迎信息，讓用戶了解商家的一些基本信息，也可以讓用戶感受到商家的熱情。以后還可以通過設置自動回復的圖文信息，將商家的基本信息編輯在圖文信息上，方便用戶隨時瀏覽信息。 （ 2）在線咨詢功能 當用戶對商家的產(chǎn)品不夠了解時，可以直接在微信上發(fā)送信息給商家，商家通過在線幫助用戶解答疑惑， 以提升 用戶 對 商家 的滿意度。對于一些比較常見的問題，商家可以通過設置自定義回復來更高效地處理用戶的 咨詢 請求。 19 信息科學與技術學院學士學位論文 （ 3） 娛樂 互動 功能 用戶 可以在微信上通過預設的關鍵詞開啟一些互動小游戲，或者平臺通過一些智能聊天程序接口對用戶發(fā)來的一些信息進行智能回復。以此 提升 用戶 使用 本平臺的娛樂性和實用性。 （ 4） 建議意見留言 用戶 在 使用 或者 消費了商家的產(chǎn)品服務之后，可能會 有 一些不滿意 的 地方或者有一些比較好的建議，這時便 需要 提供 一個留言 反饋的 功能讓用戶能將這些信息傳達給 企業(yè) 商家 ， 以幫助 企業(yè)商家更好地 提升 和完善自己的產(chǎn)品和服務 。當用戶在微信里 發(fā)送 “ 建議意見 ” 之后 ，引導用戶進入 一個 專門用來 填寫建議意見的 網(wǎng)頁 ， 并讓 用戶 在 這個網(wǎng)頁上 填 寫 提交 自己的意見或者建議 。 平臺商家的功能需求 （ 1）公眾號管理 管理商家的微信公眾號，對公眾號進行接口配置，實現(xiàn)公眾號接入平臺。 （ 2）微信用戶中心 實現(xiàn)微信用戶綁定、微信用戶信息管理等基本功能。 （ 3）會員卡 商家通過平臺向用戶提供會員卡功能，需要有會員卡制作、會員管理、通知發(fā)布、優(yōu)惠券 發(fā)布等功能，并且商家可在此基礎上根據(jù)自己的具體業(yè)務需求，增加積分、充值、簽到等功能。 （ 4）自定義回復 通過匹配用戶發(fā)來的信息中的關鍵詞，自動進行內(nèi)容回復，可以支持圖文回復、多圖文回復和文本回復。 （ 5）智能聊天 通過網(wǎng)絡 的一些 支持的智能聊天 的 開源 接口 ，如小黃雞、小九機器人 等 ，在平臺上實現(xiàn) 天氣查詢、英文翻譯、笑話 娛樂 、 地圖 導航 、手機號碼歸屬、人工智能聊天等功能，增加平臺的實用性和娛樂性，加強和用戶的粘度。 （ 6）融合第三方功能擴展 20 信息科學與技術學院學士學位論文 商家可以自己編程開發(fā)一些功能模塊，通過配置一些特定的關鍵詞，當用戶在微信里回 復這些關鍵詞時，插件會把微信的請求數(shù)據(jù)轉(zhuǎn)發(fā)到配置的商家自己開發(fā)的功能模塊中，從而大大擴展了商家公眾號功能的多樣性，也能滿足商家更個性化的需求。 基于微信的生活服務平臺功能模塊設計 根據(jù)對平臺的需求分析，我們將平臺的功能分為兩大模塊：用戶模塊和商家模塊。兩大模塊 中 具體 需求與 服務平臺中的 各個 功能模塊相互對應 ， 如圖 41 所示 。 圖 41 微信的生活服務平臺功能模塊設計 21 信息科學與技術學院學士學位論文 5 基于微信的生活服務平臺開發(fā)與實現(xiàn) 基于微信公眾平臺開發(fā)概述 微信公眾平臺開發(fā)模式的數(shù)據(jù)交互方式 微信公眾平臺 開發(fā)模式 的 數(shù)據(jù) 交互線路 可以 簡單 地 歸納為 “ 用戶 — 微信服務器— 第三方服務器 — 微信服務器 — 用戶 ” ， 每一次 的 數(shù)據(jù)交互的過程 都是 由用戶發(fā)送消息而發(fā)起的 。微信公眾平臺開發(fā)模式 提供的 消息接口 是指導 數(shù)據(jù)進行交互的行為標準 。 如果 微信公眾 帳 號 啟用 了開發(fā)模式并接入了消息接口 ，當用戶 向 公眾賬號 發(fā)送 消息 時，微信公眾平臺 的 服務器 將消息 通過 HTTP 請求 推送給 第三方 服務器 ，第三方服務器 則根據(jù) 我們預設的規(guī)則 進行響應 ， 并回復指定 的消息 [15]。 通俗的來講 ，就是 我們可以 通過 自己 編寫 的程序 讓 微 信公眾帳號自動地 和用戶進行對話。 使用了開發(fā)模式的微信公眾賬號 就像 一個預設了高級規(guī)則 的賬號 ， 用戶 在和 公眾帳號進行互動的時候， 可以 獲取 相應的 信息 反饋 。而 如何獲得 相應的信息反饋則需要根據(jù)公眾平臺提供的開發(fā) 接口通過第三方 服務器 實現(xiàn)。用戶、微信后臺和我們開發(fā)的公眾賬號后臺的第三方服務器三者之間 形成 了一個 信息 交互 的 關系 ， 如圖 51所示。 圖 51 用戶、微信后臺和第三方服務器間的交互圖 22 信息科學與技術學院學士學位論文 對于 圖 51 中 的 交互過程 具體的 描述如下： （ 1）用戶在向 微信 公眾賬號發(fā)送一條消息， 并到達 微信的服務器后 臺； （ 2）微信后臺 將 消息轉(zhuǎn)發(fā)給 公眾賬號的第三方服務器 ，也就是 我們開發(fā)的微信生活服務平臺 所在 的服務器 ； （ 3）第三方服務器收到請求后，解析消息格式， 對 消息進行處理 ， 并將處理 后的結果 返回給微信后臺； （ 4）微信后臺把第三方服務器 的處理 結果 回復 給用戶，這樣用戶在 微信 上就看到 了 公眾賬號回復的消息了。 在這個過程中，我們的第三方服務器需要做的三件事情：獲取微信后臺發(fā)過來的消息， 按照預設 的規(guī)則進行信息處理 ，發(fā)送返回消息給微信后臺。 微信公眾平臺開發(fā)模式的接口 應用程序編程接口，簡稱 API（ Application Programming Interface）， 它是 為了方便程序軟件 中 各個組成 部分 之間 進行連接而指定 的 規(guī)則 。 現(xiàn)在各種應用 軟件 的 規(guī)模變得越來越 大， 為了 更高效 地 進行軟件的開發(fā)維護 ，我們 把 龐大 且復雜 的軟件程序劃分 成為 一個個較 小的組成部分， 每個 部分之間都是通過編程接口進行銜接的， 重視 設計編程接口 的 工作也就變得理所應當 。 在 程序設計的 工作 中， 設計 編程接口 第一個 要 考慮 的 就是 合理 地 劃分 軟件程序 的 各個 功能模塊 。 設計合理 的接口可以降低系統(tǒng)各 功能模塊 之間 相互 的 依賴 性 ，提高 各 個功能模塊 的內(nèi)聚性，降低 個 各 功能模塊 之 間的耦合程度， 從而提高 整個 軟件程序 的 穩(wěn)定 性和擴展性 [16]。微信接口開發(fā)及公眾平臺消息接口就是這樣 的 一種 用于 處理 消息 編程接口 。 微信公眾平臺 的 API 接口 有 兩 種，分別 為 ： 消息接口和通用接口。通用接口 可以 實現(xiàn)獲取 用戶 個人資料，上傳 圖片 、視 音 頻 文件 ， 消息的主動推送等功能。 通用接口 提供 的這些功能更多的是 幫助 消息接口回復圖片、語音和視頻等多媒體消息，以及向 用戶推送 一些 個性化的 消息 。 而 消息接口 的主要 功能則是 對 用戶 向 微信公眾號發(fā)送的消息的處理 ， 利用 消息接口的規(guī)則可以編程預設一些處理規(guī)則， 來 獲取特定的處理結果 ， 并將處理結果返回給微信后臺 ， 再經(jīng)過微信后臺的解析后回復給用戶 [17]。 23 信息科學與技術學院學士學位論文 微信公眾平臺消息接口簡介 消息推送 當普通微信用戶向公眾賬號發(fā)消息時，公眾平臺將 POST 該消息到填寫的 Url上（現(xiàn)支持文本消息以及地理位置消息）。 消息 將以 使用 xml 格式 推送 ， 接下來將對消息 xml 格式 進行 具體說明 。 （ 1）文本消息 xml 格式 xml ToUserName![CDATA[toUser]]/ToUserName FromUserName![CDATA[fromUser]]/FromUserName CreateTime1348831860/CreateTime MsgType![CDATA[text]]/MsgType Content![CDATA[this is a test]]/Content MsgId1234567890123456/MsgId /xml 文本 消息中 傳遞 的 各項 參數(shù)相對應的 描述 如表 51 所示 。 表 51 文本消息 中 的 參數(shù) 描述 參數(shù) 描述 ToUserName 開發(fā)者 微信號 FromUserName 發(fā)送方帳號（一個 OpenID） CreateTime 消息創(chuàng)建時間 （整型） MsgType text Content 文本消息內(nèi)容 MsgId 消息 id， 64 位整型 （ 2）圖片消息結構 xml ToUserName![CDATA[toUser]]/ToUserName 24 信息科學與技術學院學士學位論文 FromUserName![CDATA[fromUser]]/FromUserName CreateTime1348831860/CreateTime MsgType![CDATA[image]]/MsgType PicUrl![CDATA[this is a url]]/PicUrl MediaId![CDATA[media_id]]/MediaId MsgId1234567890123456/MsgId /xml 圖片 消息中 傳遞 的 各項 參數(shù)相對應的 描述 如表 52 所示 。 表 52 圖片 消息 中 的 參數(shù) 描述 參數(shù) 描述 ToUserName 開發(fā)者 微信號 FromUserName 發(fā)送方帳號（一個 OpenID） CreateTime 消息創(chuàng)建時間 （整型） MsgType image PicUrl 圖片鏈接 MediaId 圖片消息媒體 id，可以調(diào)用多媒體文件下載接口拉取數(shù)據(jù)。 MsgId 消息 id， 64 位整型 （ 3）地理位置消息 xml 格式 xml ToUserName![CDATA[toUser]]/ToUserName FromUserName![CDATA[fromUser]]/FromUserName CreateTime1351776360/CreateTime MsgType![CDATA[location]]/MsgType Location_X/Location_X Location_Y/Location_Y Scale20/Scale Label![CDATA[位置信息 ]]/Label 25 信息科學與技術學院學士學位論文 MsgId1234567890123456/MsgId /xml 地理位置 消息中 傳遞 的 各項 參數(shù)相對應的 描述 如表 53 所示 。 表 53 地理位置 消息 中 的 參數(shù) 描述 參數(shù) 描述 ToUserName 開發(fā)者 微信號 FromUserName 發(fā)送方帳號（一個 OpenID） CreateTime 消息創(chuàng)建時間 （整型） MsgType location Location_X 地理位置維度 Location_Y 地理位置經(jīng)度 Scale 地圖縮放大小 Label 地理位置信息 MsgId 消息 id， 64 位整型 消息回復 對于每一個 POST 請求，開發(fā)者在響應包中返回特定 xml 結構，對該消息進行相應操作（現(xiàn)支持回復文本消息 、 回復圖文消息和星標操作）。 回復消息時 也使用xml 格式 進行推送 ， 接下來將對 消息 xml 格式 進 行 具體說明 。 （ 1）回復文本消息格式 xml ToUserName![CDATA[toUser]]/ToUserName FromUserName![CDATA[fromUser]]/FromUserName CreateTime12345678/CreateTime MsgType![CDATA[text]]/MsgType Content![CDATA[你好 ]]/Content /xml 回復文本 消息 時傳遞 的 各項 參數(shù)相對應的 描述 如表 54 所 示 。 26 信息科學與技術學院學士學位論文 表 54 文本消息 回復中 的 參數(shù) 描述 參數(shù) 是否必須 描述 ToUserName 是 接收方帳號（收到的 OpenID） FromUserName 是 開發(fā)者 微信號 CreateTime 是 消息創(chuàng)建時間 （整型） MsgType 是 text Content 是 回復的消息內(nèi)容（換行：在 content 中能夠換行，微信客戶端就支持換行顯示） （ 2）回復圖文消息格式 xml ToUserName![CDATA[toUser]]/ToUserName FromUserName![CDATA[fromUser]]/FromUserName CreateTime12345678/CreateTime MsgType![CDATA[news]]/MsgType ArticleCount2/ArticleCount Articles item Title![CDATA[title1]