在開發模式下，企業消息系統發送圖文推送、範本消息、自動回復、客服消息等類型的消息至微信服務端，在微信公眾號對話視窗下與使用者進行互動。

首先將公眾號的APP ID等資訊同步開發者，並將開發者的參數配置到後臺，並開啟開發者模式。驗證正確後即成功接入開發模式。

獲取使用者資訊是進行消息推送最基礎的步驟，獲取使用者資訊時需要使用者授權，開發者需將微信回檔的CODE值調用微信使用者資訊介面替換相關資訊，並進行資料存儲。

消息推送從發送發起方來劃分，分為兩種：用戶觸發推送，企業主動推送。

關注歡迎語、關鍵字回復、客服消息等使用者主動發起並且即時互動的消息，使用者主動發出消息或觸發事件，微信側會將相關資訊同步至開發者，待開發者處理好後推送給用戶。

主動推送主要為群發的圖文消息等，使用者被動接受。開發者直接調用相關消息推送介面即可，但此類消息微信有嚴格的頻率控制。

每個用戶在每一個微信公眾號下有對應的唯一open ID，微信的推送也是以一個open ID來對應一個用戶。

對於公司內部來說，可能會運營多個微信公眾號。一個用戶同時關注了多個公眾號，對於內部運營來說便產生了各個公眾號關注用戶關聯關係（用戶打通）的需求。微信側提供了union ID作為關聯帳號，同一用戶，對同一個微信開放平臺下的不同應用（小程式、公眾號等），unionid是相同的。因此，需將微信公眾號去微信開發平臺進行綁定（open.weixin.qq.com）。

對於精准推送來說，需要將企業內部的customer ID與微信的open ID形成映射關係，這樣便可以根據使用者在企業自身的產品上產生的行為，通過微信公眾號對指定使用者進行消息推送，例如信用卡還款提醒。

綁定關係的實現主要通過微信授權協力廠商登陸頁面（企業登陸頁面），在企業登陸頁面登陸後，可將企業customer ID與微信code值同時傳輸到綁定服務，之後調用微信介面將code值對應的open ID等資訊與企業customer ID建立綁定關係。其中已關注對應公眾號的用戶則為靜默授權，無需用戶確認授權，用戶體驗較好。

在啟用開發模式後，微信公眾號提供了企業與微信關注使用者互動的一個視窗。本質上，每次交互都是微信會將用戶的行為與提交的內容傳遞公眾號開發者，等待開發者處理好後，將對應的消息或者指令回饋給使用者。

因此，企業可結合微信與自身的能力與用戶進行互動，推送的精細程度與靈活程度大大提高。以下為部分微信消息典型場景與實現邏輯，發送內容形式可以是文本、圖文、圖片、語音、視頻等，檔要求詳見微信公眾平臺技術文檔。

可以根據使用者的歷史關注資料區分首次、非首次用戶，來回復針對新關注用戶的露出的特定優惠。

當企業的公眾號在某些管道推廣時也可以根據不同的參數二維碼來識別關注來源，評估推廣管道的好壞或針對不同管道或活動的使用者回復不同的內容。

當使用者回復的內容命中關鍵字時，回復對應關鍵字的內容。

可以用在彩蛋互動、活動推廣、使用者主動查詢資訊等場景。對於關鍵字判斷時，如果關鍵字有較多相近的詞彙的話也可組成片語，命中其中一個便進行消息回復。這些命中規則在消息系統實現即可。

對於認證訂閱號，，每個月每個用戶只有接受4次主動推送圖文等消息的機會。當用戶數量達到一定程度，用戶需求出現一定差異化，企業需要精細化運營的時候便捉襟見肘了。

為了更好地差異化推送，可利用企業自身使用者標籤、使用者畫像系統與微信群發消息結合，將使用者進行分群推送，實現精細化運營。

如果企業有智慧問答等相關能力的話，也可以接入微信推送系統，這樣可以增加與微信用戶互動的趣味性，也可用來解決一些用戶的實際問題，提高用戶解決問題的效率，降低企業客戶服務相關的成本。

大多數情況下，微信的功能表列都被設置成了各個頁面或者小程式的入口，實際上微信也提供了通過底部功能表列進行觸發消息事件的能力，使用者點擊後可回復相關內容。

由於開啟了開發者模式，微信公眾平臺上的某些功能（功能表配置、自動回復設置）便不可使用，或者微信提供了更好的精准推送的能力，需要微信公眾號的開發者利用微信公眾平臺提供的相關介面進行自行實現。

微信公眾平臺上的功能表列配置在開發模式下會失效，因此微信推送系統需要提供此功能便於日常運營。當然，每個人看到的功能表列也可以是不一樣的，比如開過本行信用卡的用戶再開第二張的可能性較低，因此可釋放出申卡功能表列進行其他資源投放。差異化的功能表列展示可以通過微信的自訂功能表相關介面實現。

帶參數的二維碼主要用來做管道區分，其中一個場景可以應用於個人用戶的裂變，生成專屬邀請碼，不過要注意微信側對於永久、臨時二維碼的限制。

使用者標籤主要是將企業對使用者的分群資料打標到微信用戶上，實現差異化推送、差異化功能表的基本能力。

素材管理也是消息回復中常涉及到的部分功能，將圖片、語音等素材檔提交至微信側。

access token是公眾號的全域唯一調用憑證且有效期目前為2個小時，需要定時刷新，每日調用次數限制2000次以內。刷新後，前一個token將會失效。特別需要注意的是，如果當企業內部有多個團隊或者多個場景需要使用access token時，不要各自去對接微信，要建立一個唯一對接者，然後對內部需求進行分發，避免互相將token置失效，若沒有良好的重試控制機制，瞬間浪費調用額度。

對於大多數微信公眾號接入開發模式前，已經運營了一段時間，積累了一定的用戶數量。在接入開發者模式之後，對於存量使用者需要進行資料初始化，需從微信側獲取必要資訊並記錄，避免後續消息推送無法覆蓋存量用戶。

帳號遷移需要一定費用並且會在遷移時通知用戶，用戶有是否取關的權利。對於遷移造成的用戶open ID變化要做好替換，避免出現由於遷移導致長時間無法推送的事故出現。

對於以上提到的各種功能並不是每一個公眾號都是具有相關的介面許可權的，贏在接入開發模式之前將相關介面的許可權獲取好，避免許可權不夠導致不能平穩接入，對研發工作和用戶造成影響。相關的許可權可以在微信公眾平臺——開發——介面許可權模組進行查看。

微信的一些介面在調用上是有一定限制的，一定要事先瞭解並且在微信消息推送系統做好相應的調用控制，避免出現不合理調用造成額度浪費，無法進行用戶推送。詳細限制在微信公眾平臺——開發——開發者工具——開發者文檔——介面調用頻次限制說明。

目前公眾號底部功能表列可以進行關聯後的小程式的設置，或者通過回復超連結的形式（體驗不是很好）。直接回復小程式卡片的功能微信側還未開放，但可通過客服消息功能實現，需認證後公眾號具有客服消息許可權及關聯過小程式。當需要推送小程式時，調用相關客服消息介面。

任何的消息觸達都需要進行資料分析，發送、觸達、點擊，轉化等資料是必不可少的。在微信公眾號的場景下，更有功能表列的點擊、使用者關注、取消、消息閱讀量等資料來衡量公眾號的運營情況。在微信消息系統產品設計時，便需要將相關資料獲取、統計分析。

小程式場景下，使用者更多是集中在小程式功能上，消息互動僅僅是其中一塊非常小的模組，但對於小程式運營者來說，利用好服務通知也是可以提升小程式活躍度的重要手段。

小程式的服務通知會在使用者的聊天清單專門有一個“服務通知”對話，收納各種小程式的服務通知。其中特別值得注意的是，小程式有一個form_id的概念，當使用者在小程式內發生過提交表單行為且該表單聲明為要發範本消息時或使用者在小程式內支付時，產生一條form_id，有效期為7天且不可重複使用。開發者在下發服務通知時需要提交有效的form_id。

• 遵守規則，以使用者為中心，避免封號產生重大影響。
• 微信提供了許多基礎功能，可將多個功能或結合企業自身的能力組合形成一種新的互動的方式，例如根據生成參數二維碼、自動回復形成用戶可自行裂變邀請的功能。
• 對於某些場景的限制要做到深入瞭解，避免某些業務場景達到了微信介面調用次數限制後出現問題，需瞭解各介面調用頻次說明。
• 一切功能實現基於微信公眾平臺能力，需並且經常回顧平臺規則並且關注更新。
• 消息推送只是微信公眾號生態下一個消息的模組，市面上已經有各種各樣的針對微信的運營工具，可根據自身需求評估，是否需要自己獨立開發。
• 以上寫的只是協力廠商公司有公眾號消息推送需求的基本經驗，最重要的還是多瞭解微信公眾平臺的開發者文檔。

以上內容為個人經驗總結，歡迎討論指正。