市面上有很多關於微信小程序的文章，但大多都是一些宏觀的分析或者框架式的方法論，卻沒有講到底怎麼去落地、以及實際項目過程中會遇到哪些問題。所以在本文中，我將以自己親手做過的一款小程序為載體，以整個項目流程為主線，系統地解構怎樣從0到1做一款微信小程序。
概述
過去幾個月，我們團隊一直在做一款關於網際網路保險業務的小程序，這不僅是自己第一次從0到1負責一款新產品，也是第一次做微信小程序，在整個項目過程中積累了諸多經驗和體悟，因此需要經過一次系統的復盤，才能真正內化到自己的產品思維體系中。
這裡有兩個重點：一是怎麼去做一款新產品；二是怎麼做一款微信小程序。
我將分三部分講述從0到1做一款小程序的整個流程：定位、規劃、落地。
定位，想做一款微信小程序，一定要先了解微信生態，明白服務號、訂閱號和小程序之間的關係，並且基於自己公司的實際業務情況，將小程序嵌入到業務流程中去，所以我將分為微信生態和業務架構兩部分進行分析。
規劃，把產品做複雜了容易，但做簡單了難。尤其是新產品第一個版本的設計，非常考驗一個產品經理的功力。哪些該第一版做，哪些該後續疊代，這都要基於產品經理對整體業務的理解進行系統規劃。
落地，從一個概念和框架落地為實際的產品是最難的，真正做小程序時會遇到很多的坑，不只是小程序自己的各種坑，也有與自己業務打通時的諸多問題，因此必須要對小程序的特點有所了解，我將把做小程序過程中需要注意的問題一一道來。
1. 定位
1.1 微信生態
為什麼要用微信小程序這種載體？
做小程序前要先回答這個問題，否則選擇了不適合自己業務的載體，只能是浪費資源。
而要回答這個問題，得先了解微信的生態，並結合自己的實際業務流程去權衡。
在微信生態中，通信功能+朋友圈所構建的社交關係是基本盤，並基於這個巨大的流量池，衍生出公眾號和小程序兩大子生態系統。
其中，公眾號又分為訂閱號和服務號，訂閱號提供的是內容，以內容沉澱用戶，個人和企業均可開通；服務號則專門提供給企業，給用戶提供各種商家服務。
服務號和訂閱號大概有三點不同：
（1）服務號在消息列表這個一級頁面直接單獨展示，訂閱號則摺疊在「訂閱號消息」的二級頁面中。這就導致了服務號的曝光能力優於訂閱號。
（2）服務號每個月能推送4條消息，訂閱號每天都可以推送1條消息。因此訂閱號更適合做內容來吸引用戶並運營用戶，而服務號更聚焦於提供服務功能，並且儘量少地打擾用戶。
（3）經過認證的服務號支持微信支付功能和高級開發，而訂閱號不支持。這進一步強化了服務號的B端屬性和服務能力。
從這三點區別可以看到，其實服務號和訂閱號之間的差別其實非常模糊。
訂閱號使用H5或者小程序同樣可以提供商家服務，這樣就兼具內容沉澱和企業服務能力了，但服務號依舊有不能做內容的短板，唯一的優勢只剩可以更容易獲得曝光。
因此，訂閱號和服務號的定位可以概括為：訂閱號偏向獲客、服務號負責服務。
也就是說，在前期，訂閱號可以起到吸引流量的作用，可以當做獲客渠道，用內容教育和轉化用戶，當用戶變成客戶後，就可以引向服務號，專門提供售後的各種長期服務。
那又為什麼會出現小程序呢？
沒有小程序之前，公眾號的各種功能是由H5網頁提供的，在服務工具或者說服務媒介這一環節不由微信掌控，而且H5的體驗也較差。
因此微信推出了小程序，自己制定了一套「H5」規範，這不但可以在技術層面與微信打通，可以提供更多服務接口，也能夠把控工具載體的質量，為用戶提供更好的服務體驗。
更關鍵的是，這也打通了整個服務鏈條，公眾號和小程序形成了業務閉環，企業在為用戶提供某項服務時，全程都停留在微信的平台上，不用離開微信這個大生態系統。
打個比方，這就像微信是一個大商場，各個公眾號是一個個店鋪，在以前，當你進入某個商鋪時，因為這是一個個H5，所以微信無法了解每個商鋪的裝修質量和服務能力，也不知道你在裡面都做了什麼，像一個個黑盒子。
但現在有了小程序，也就是說微信這個大商場為每個商鋪統一裝修，並且把控了他們的服務質量，也都安上了安全監控，不但提高了你的服務體驗，還能獲取你的全程數據。
其中，能收集並打通全程數據非常有意義，因為數據分析是一個系統化工程，碎片化的數據是沒有價值的。
比如用戶的購物行為，沒有小程序時，微信只能知道你點擊商家入口了多少次，進入商家自己提供的H5後，微信就不知道用戶在H5中都有哪些行為了，比如瀏覽了哪些商品、把哪些商品放進了購物車。在最後，用戶付款時使用了微信支付，微信才知道這個用戶轉化成功了，但是中間購買流程上的每一步轉化率怎麼樣，微信一無所知。
也就是說，微信只能獲取入口的流量數據和最後的支付數據，其他的數據則在商家自己手中，微信沒有收集到全流程的數據，自然也無法對用戶有深入的了解。
只有以人為中心，獲取到其全流程數據，才有可能做出精準的用戶畫像。分析其屬性和行為特徵後，便可在後續為每個用戶提供人性化服務以及精準化營銷。
小程序不但對微信的意義重大，而且對開發者來說也非常友好。
由於手機作業系統是割裂的，分為iOS和Android兩大陣營，所以要想開發一款APP，需要兩套人馬，開發兩個APP，分別適配兩套手機作業系統。而且Android的適配問題非常令人頭疼，因為Android是開源的，很多手機廠商的系統也有很大差異，所以光處理適配問題又要花費大量的開發資源。
現在微信已經成為一款10億量級的國民級應用，滲透率極高，基本是網際網路行業的基礎設施，像生活中的水電煤一樣。
基於這個條件，在微信上搭載了各種服務後，其實微信本身就可以承擔手機作業系統的角色。
手機上的一個個APP也就是一個個企業提供的服務，現在微信將自己生態系統中承載的服務統一化和標準化，最後呈現的載體便是小程序。
這是小程序的另一個優勢：開發成本低，只需要一套代碼就能適配所有機型。
背靠微信這個巨大的流量池，開發成本也不高，小程序這個子生態系統便開始迅速成長起來，如今已經成為首選的載體。
但是小程序也存在短板，因為小程序的定位是輕量、用完即走，更像是一個個小工具，具有很強的工具屬性，雖然用戶的體驗很好，但是沒有辦法沉澱下來，最終還是要引向企業自己的APP或者是公眾號。
這也就是現在經常說的私域流量。
只有變成了自己的私域流量，企業才能更直接地觸達到用戶，對這些用戶進行運營和營銷，最終實現轉化。
至此，訂閱號、服務號和小程序之間的關係和定位就非常清晰了：
在訂閱號用內容沉澱用戶、使用服務號在中後期服務用戶、小程序則承擔工具和媒介的作用。
1.2 業務架構
小程序也只是載體，不要跟風做小程序，不要把手段當做目的。
小程序一定是服務公司業務的，屬於業務流程中的一環。
我最近在做網際網路保險業務，因此所做的小程序也和保險相關：保單管理。
先談談保險業務，可能近半的網際網路人不了解保險也不關心保險，因為網際網路行業興起也沒多少年，網際網路從業者好多是二十多歲的年輕人群體。
對於二十出頭的年輕人，不關心保險很自然：一是覺得自己年輕力壯，人也常常有僥倖心理，不覺得自己會得什麼病或者發生什麼意外；二是因為沒有家庭，所以也沒有那麼強的責任感，一人吃飽全家不餓。
但是一旦有了家庭，尤其是有了孩子，自己也步入中年時，就會有很強的風險意識，開始考慮買保險了。
畢竟就算不考慮自己，也要考慮自己的老婆孩子，比如得一場大病，不但很可能會掏空家底，而且也沒有了收入來源，家裡沒有了經濟支柱，上有老下有小的該咋辦？
所以保險業務的目標客戶群體一般是中年人，而且一旦買保險，一定是家庭為單位進行保障規劃的，給自己的父母、伴侶、孩子都購置保險。
購買保險後，保險公司就會給你一張保單，也就是保險合同。
一個人一般會配置重疾險、醫療險、意外險、壽險，有的人還會為自己養老考慮，購買年金險，也叫商業養老保險，這些保險具體都有什麼作用就不展開了。
也就是說，按照一個人平均有4張保單，那一個家庭，包括雙方父母、先生太太、孩子，最少7個人計算，一家人就要有28張保單了。
這些還很可能不是一個保險公司買的，所以對保單的管理就是一個很大的問題了，也是一個痛點。
了解了保單管理的背景，那它在整個業務流程中處於什麼節點呢？
對於一個賣保險的公司，底層商業邏輯和其他行業是一致的，核心是兩點：獲客和轉化。
無論是電商平台，還是線下的商鋪，都要解決流量從哪裡來、又怎麼轉化客戶以獲取商業價值的問題。
關於獲客，雖然現在已經有諸多平台和各種類型的獲客方式，比如近幾年比較火的今日頭條的信息流廣告、抖音的短視頻廣告，或者是傳統的SEO/SEM，到最後才發現最有效的還是微信公眾號平台。
在微信公眾號投放廣告的轉化效果要明顯優於其他平台。
首先是因為公眾號具有聚集效應。
每個公眾號定位不同，因此關注的用戶也明顯有分類，比如母嬰號的關注用戶大部分都是寶媽或者懷孕的准寶媽、軍事類的公眾號的關注用戶比例最高的是中年男性。
因此只要找准自己業務的目標人群，再去目標人群聚集的地方投放廣告，自然會有很好的轉化率。比如賣體育用品的公司，可以將廣告投放健身類的公眾號，賣化妝的可以投放美妝類或情感類的公眾號等等。
更關鍵的是，公眾號文章不同於普通的硬廣，可能不讀到最後根本就不知道這是一篇廣告，因此用戶不會有天然的抗拒心理，而且代入感更強，不知不覺讀完之後，會被文章豐富的圖文和自洽的邏輯所教育，即使不能立即轉化，也會對投放的廣告產生品牌認知。
這也是為什麼，經常會有一家公司會和某一個公眾號長期簽約，定期多次投放相同的廣告。
重複，能起到固化認知的作用。
用戶價值不會一次釋放完，可能第一次沒有轉化成功的用戶，經過多次教育後就能夠轉化，直至一個公眾號的用戶群體的價值被充分壓榨，轉化率下降，此時公司可以轉戰下一個公眾號了，如此循環往復。
我們所做保險業務也正是採用了這樣的獲客方式，有了客戶之後，轉化環節就要靠保險銷售了，把不同質量的用戶分給不同轉化能力的銷售。
用戶質量也就是購買能力，可根據年收入劃分為不同層次。
年收入10萬以下的客戶，不但轉化困難，而且成交後能獲取的收益也很低，保險銷售都不太願意接這樣的客戶；
年收入10萬到20萬的客戶群體則是中堅力量，這也是保險銷售群體比較喜歡的客戶群體；
年收入再高的話，超過50萬以上，則屬於高凈值人群，很多對保險或者一些資產配置產品有比較深入的了解，普通的保險銷售駕馭不了，適合分配給資深的銷售。
轉化環節，其實是一整條服務流程，對於保險業務，可以細分為投前、投中、投後。（即投保前、投保中和投保後）
投前的核心是做家庭財務規劃，投中則是協助核保，投後需要的是保單管理和理賠協助。
基於整個業務架構，便可構建出相應的產品架構，即不同的產品所對應的業務環節和承載的功能。
（1）保險業務後台：主要分為產品、客戶和交易三大模塊。
- 產品管理，也就是我們公司所售賣的保險產品庫，接入的是第三方渠道或者直接對接不同的保險公司。
- 客戶管理，包括客戶的標籤數據和流轉數據，也就是用戶是從哪裡來的（來源渠道）、現在在哪（所處的環節）、又將往哪裡去（購買意願）。
- 交易管理，則是連接了產品和客戶，核心是訂單的相關信息，包括訂單的各類狀態，比如未支付、已支付、已出單、退保、核保、理賠等全流程狀態。
（2）家庭財務智能規劃系統：將轉化流程標準化，根據客戶的財務狀況，自動計算風險缺口，並給出保險配置方案。
不但可以體現出公司的專業性，還可以為保險銷售節省大量的精力，讓其更聚焦於為客戶講解保險知識和財務知識。
（3）保單管理小程序：則承擔售後服務，客戶不但可以查看自己家庭購置的保單，也可以使用申請退保或理賠、續期續保提醒、保單檢視等功能。
2. 規劃
2.1 用戶路徑
了解了保險業務的業務架構和產品架構後，也就知道保險管理小程序在業務流程中所處的位置和發揮的作用了。但這也只是保單管理小程序的完整態，真正實現時，需要分步疊代。
為什麼說一款新產品的第一版一定要足夠簡單？
一方面講，第一版足夠簡單是一種實驗思維，一旦發現存在問題，可以快速調整。甚至發現產品不受用戶認可、產品方向存在根本性問題時，即使迅速拋棄現有的產品，浪費的資源也不算非常大，沉沒成本在可接受範圍內。
另一方面，這也不只是為了開發資源考慮，更關鍵的是需要快速開發、快速進入市場、然後再快速疊代。
網際網路行業常常講究先發優勢，目前網際網路保險行業的入局者越來越多，競爭也是日益激烈，所以儘快地搶先市場並占領用戶認知就非常重要了。
當然，產品的第一版足夠簡單是不夠的，也要足夠有用。
怎麼才能有用呢？
一定要找到一個核心的業務節點，把這個產品嵌入到業務流程中，也就是用戶必經路徑上，才能真正發揮作用。
經常會出現的情況是，做了一款產品，然後沒有在用戶核心路徑上，用戶可用可不用，用了固然有幫助，不用也沒有什麼影響，那這款產品也就發揮不了什麼價值了。
可以拿騰訊相冊小程序舉例，在初期，騰訊相冊只是打通了小程序內的QQ帳號體系，用戶主要是查看自己在QQ的相冊。
而在18年5月，做了從QQ微信的照片由小程序來承載這個功能後，數據量才開始爆發性增長。
也就是說，從QQ分享照片到微信這個核心使用場景中，用戶原來的路徑是直接分享照片即可，不會是進入小程序再去分享，這個路徑反而變長。但是用小程序承載後，也就是把小程序這個載體嵌入到用戶分享的必經路徑中了，使用量比以前自然會有大幅上漲。
其負責人曾提到過，騰訊相冊小程序的用戶增量主要來自於QQ空間用戶的分享，在小程序的新用戶來源中，80%是分享進入的，也就是說每5個使用用戶有4個是通過分享路徑進來的。
由此可見，一款新產品想要「有用」，必須要嵌入到用戶的核心使用路徑中。
對於保單管理來說，客戶在我們公司買完保險後，一定是想要直接能夠看到保單的，而不是讓保險銷售手動發給客戶一個文件或者讓客戶自己登錄網站去查看自己的保單。
所以這也正是保單管理小程序在業務流程中出現的第一個節點：客戶買完保險後，可以直接在微信小程序中查看自己購買的保單，並可以獲得一系列的售後服務。
2.2 功能範圍
查看保單功能是保單管理小程序最基礎也是最核心的一個功能，但是客戶的保單其實分為兩部分：在我們自己公司購買的保險和在其他公司購買的保險。
在我們公司購買的保險，我們有相關的保險數據，所以可以直接在小程序中展示，那客戶在其他公司買的保險，我們也沒有相關數據，那該怎麼辦？
尤其是自然流量的用戶，不是我們平台的客戶，他們又怎樣使用保單管理小程序呢？
這就是我們產品的另一個核心功能：上傳保單。
有了上傳功能後，不但小程序可以獨立使用了，同時，自己平台的保單數據和客戶自己上傳的保單數據合在一起，構成了客戶的完整保單信息。
當然，這個功能也應該在客戶的核心路徑上。
客戶在做保障規劃時，需要納入客戶的已購保險的，不但可以將家庭財務智能規劃系統計算出的風險缺口減去客戶已有的保額，也可以將客戶的已購保險和我們推薦的保險進行對比，最終實現讓客戶買到性價比最高保險的目的。
也就是說，保單管理小程序在業務流程中的位置前置了，不但可以在購買保險後（投後）查看保單，也可以在投前的保障規劃階段起到錄入已購保單的作用。
至此，可以看到，保單管理小程序需要兩個核心功能：查看並分享在我們公司購買的保單和上傳在其他地方已經購買的保單。
其實，這個也可以類比騰訊相冊小程序。
對於騰訊來說，一個人的照片分為兩部分：一部分是在QQ空間和微信朋友圈的照片，也就是用戶在騰訊自己公司的數據；另一部分則是用戶在其他平台的照片，可能大部分都是在用戶自己的手機相冊中。
那麼騰訊相冊小程序的核心功能也需要兩個：用戶可以查看並分享在QQ空間和微信的照片、用戶可以上傳手機相冊中的照片。
這和保單管理小程序的功能邏輯基本相同。
明確了產品的核心功能後，再回到最初的問題：第一版要上哪些功能呢？哪些需要後續疊代呢？
我們選擇了第一版先實現用戶可以查看和分享在我們公司購買的保單，也就是將保險業務後台的保單數據同步至小程序。
已成交客戶作為我們新產品的種子用戶，可以先將小程序用起來，檢驗一下產品的使用效果，並優化使用過程中存在的一些問題。
上傳保單功能則放在第二個大版本進行疊代，有了上傳功能，就不僅是一個內部應用了，可以單獨使用，成為一個獨立的小程序應用。這樣也就有機會去獲取自然流量，成為獲客的另一個渠道。
不過，小程序的核心定位還是形成公司的業務閉環，服務好自有客戶，而所謂獲客只是錦上添花，其實還是很困難的，只是提供了獲客的可能。
3. 落地
3.1 互動設計
明確了業務架構和產品架構後，也確定了產品的疊代路徑，接下來就要考慮產品的具體信息架構了。
信息架構，也就是介面層，即展現在用戶面前的視覺效果，比如不同功能的組織，頁面布局等等。
經常說小程序的特點是用完即走，那怎麼才能達到這樣的效果呢？
第一原則：使用路徑清晰且單一。
這樣用戶一旦進入了小程序，就知道自己要怎麼做、下一步點哪裡。
因為小程序有很強的工具屬性，用戶在進入小程序前帶有明確的目的和預期，那麼，好的小程序一定要讓用戶進入小程序時，就能使他產生一種：「嗯，這就是我想要的。」的感覺，並且順暢和快速地讓用戶解決要完成的事。
摩拜單車的小程序就是很好的例子：掃一掃、點擊解鎖、騎車即走，用戶只需要三步動作即可完成任務，小程序在整個流程中的存在是完美連接線上和線下的，順暢無阻塞，甚至是無感知的。
不好的做法是，堆砌很多偏離業務主線的功能，找半天才找到能解決自己問題的功能入口，也就是把小程序做成了一個很重的APP。
如果業務比較複雜，可以拆分為一個個獨立業務或者功能點，做成小程序矩陣，典型如幾個網際網路巨頭，美團、京東、百度等。
第二原則：交互方式簡單且統一。
這裡有兩個關鍵詞：簡單和統一。
對於簡單而言，最重要的就是不要用太多複雜的交互，更不要用太多頁面跳轉這麼重的交互方式。不用複雜交互可以理解，因為用戶打開小程序是為了快速解決問題，如果各種操作使用複雜交互效果，反而會造成使用不便。
這個和PPT類似，在做匯報時，如果加入各種動效，不僅會造成喧賓奪主，聽眾的注意力被動效吸引，而且動效過程也會浪費很多時間。簡單直接，往往最有效。
那又為什麼說頁面跳轉這種交互比較重，不推薦在小程序中使用呢？
原因有兩個：
一是新頁面加載需要等待；
尤其是生活中經常會有弱網或者無網的場景出現，比如地鐵、電梯、地下停車場等，因此跳轉新頁面會出現長時間加載情況，所以操作能在現有頁面完成就儘量不要跳轉。
二是過多層級的頁面路徑會對用戶認知造成混亂；
本身小程序就屬於微信的子頁面，至少是二級頁面，如果在小程序內的頁面也有很多層級或者是要經常跳轉，就非常容易讓用戶產生疑惑或者焦慮感。同樣，這也違背了第一原則。
反面案例就是京東APP，拿簽到模塊舉例，其頁面層級有非常多層。
關於交互的統一，本身就是一款合格的產品應該具備的。
雖然一款產品可能有很多模塊、很多業務，可能是由多個產品經理分工負責，但是一定要注意交互一致性、布局一致性、設計一致性。
在同一款產品中，如果使用不同的功能或者模塊時，發現視覺效果明顯不同，那就很可能是不同產品經理做的，也說明沒有一個產品負責人去整體把控這款產品。
關於小程序，微信本身提供了一套標準的小程序設計規範，比如啟動頁加載樣式、頁面下拉刷新樣式等等，不但可以減少很多開發量，也提供了一套通用標準，但是依舊要注意交互的一致性問題。
建議先通讀一下微信小程序關於設計部分的官方文檔：
在實際的項目中，最好由產品經理和互動設計師或者UI設計師一起基於微信小程序的設計指南，制定好一套適用於自己產品的設計規範。
拿微信APP自己舉例，對比其設置頁的編輯態，會發現複雜的編輯操作或者重要的編輯操作，都會有「完成」按鈕進行二次確認，而一般的編輯操作可直接操作。
雖然這只是一個簡單交互，但是說明其對設計的規範性。
小程序中幾個典型的交互方式總結一下：
- 能不跳轉就不跳轉（多用底部彈窗）
- 能不輸入就不輸入（多用自動填入、勾選等）
- 鍵盤自動調起（注意不同情況下的不同鍵盤類型）
第三原則：請嚴格遵守第一原則和第二原則。
3.2 數據支撐
做功能一定先要考慮到數據從哪裡來，能不能支撐功能。
很多時候，把功能設計得非常好用，但是往往難以落地或者是實際使用時出現了各種問題，一個很重要的原因就是數據支持沒跟上。
拿我之前想做的一個關於電商比價產品舉例：因為現在電商平台比較多，商家也比較多，我想買一款電視，相同品牌或者相同型號的，在哪裡買便宜呢？
所以我就會去不同的電商平台看看，比如天貓、京東、蘇寧、唯品會、甚至拼多多，在這個過程中，我需要不斷切換不同的應用去對比，花費大量的時間。這個場景在生活中經常會出現，我觀察到很多人也都有過相似的經歷。
要是從場景和需求來看，似乎電商比價這個功能非常有用，很多人肯定也非常想用，要是真的做出來了，萬一大受歡迎，說不定我還可以去創個業、拿個融資，從此走向人生巔峰。
但是，等一下，既然這個功能既然這麼有用，為什麼沒人做呢？
我從美好的幻想中被拉了出來，細想後發現，這裡存在一個關鍵的問題幾乎難以解決：數據從哪裡來？每個電商平台都有自己的價格機制和調控平台，那商品數據和價格數據是否會開放出去呢？
顯然是不可能的，這些數據是電商自己的數字資產，也是自己的優勢，所以一個個電商平台之間樹立起了數據壁壘。
從這個例子可以看到，不同公司之間的數據打通是極其困難的，不只是技術問題，更多是意願問題。
除了不同公司間的數據壁壘問題，相同公司的不同部門的數據打通同樣存在種種困難。
拿騰訊相冊小程序舉例，其功能其實也非常簡單，但是難點一定是在數據上：QQ空間相冊的數據、微信數據和從本地上傳的數據的打通問題。
因此，技術不是問題，重點在於不同部門能否通力合作去解決問題。
對於騰訊這種巨頭公司，經常會出現的大公司病就是「各立山頭」，而QQ和微信就隸屬於不同的事業群，這大大增加了數據整合、信息流通和資源共享的難度。
所以不要把一個公司當做一個整體，也不要覺得一個公司是鐵板一塊，大家都會優先考慮公司的整體利益，畢竟一個公司是由不同的人組成的，位置不同，利益自然也不同。
因此從下往上推動一個項目往往是很難的，只能從上往下去貫徹一個目標，由更高層的人去牽頭才有可能成事。
說完公司管理層面的問題，回到數據打通本身，真正在落地時，很難處理的是數據格式問題。雖然對於保險業務，數據格式相對來說已經比較規範了，但是依舊存在一些細微的差別。
就拿我們公司叫的「保障期限」來說，也就是買一個保險能保障你多長時間，行業中不同公司的叫法有：保障期限、保險期限、保險期間、保障年限等，那麼來自不同公司的保險產品數據在打通時就會存在問題。
因此，數據格式統一是數據打通的第一原則。
尤其是現在我們做的這個微信小程序，是一款新產品，需要使用保險業務後台的現有數據，那麼在新產品中的數據欄位名稱和格式，一定要與原系統保持一致。
在實際的工作中，數據格式這一塊兒就耗費了我們非常多的精力，因為原有業務後台也存在諸多問題，很多地方的數據格式也沒有統一，或者現有的數據格式不規範，因此需要先梳理現有系統的數據格式，並糾正其中的一些數據問題。
數據格式問題解決之後，然後還要依照不同的維度解決接下來的一系列數據問題：
- 數據來源：數據都是由哪些人或者系統產生的，可以分為線上系統同步和線下人工錄入，只有搭建起自動收集數據的自循環，才有對數據分析和應用的可能；
- 數據查看：不同的數據都是有哪些角色查看、不同角色的數據權限有哪些、查看的終端有哪些、目前查看數據的流程和方式是怎樣的；
- 數據應用：數據可以用到哪些具體的功能中，比如數據異常預警機制、數據展板等；
- 數據更新：目前不同類型的數據是怎麼更新的、更新頻率是多久、有哪些數據長期未更新、未更新的原因是什麼、未來建立的數據系統需要怎樣支持數據更新（頻次、實時性等）。
3.3 用戶授權
在以前，進入一個APP時，需要輸入帳號和密碼進行登錄，即使是現在，主流的也是輸入手機號，然後通過簡訊驗證碼登錄，沒有註冊時還經常要先去註冊，整個路徑非常長。
但是在微信生態中就不一樣了，進入小程序時是靜默登錄的，在小程序後台直接完成了登錄操作，企業可以獲取到用戶在此應用中的唯一標識OpenID，用戶不需要進行任何操作。
這個也好理解，用戶進入微信APP時，已經進行過一次登錄，那再使用微信內的應用時自然不需要登錄。
那我們為什麼還會在各種小程序中看到「登錄」按鈕呢？
其實，這裡的「登錄」本質是授權，是為了獲取你的各種信息，因此是兩回事。
可能許多應用為了延續用戶在APP生態中的使用習慣，所以依舊使用「登錄」這種叫法。
微信本身就有你的手機號、身份證、年齡、性別、地域等關鍵信息，但是不會直接開放給其他企業，需要用戶手動授權。其中，手機號信息又從用戶信息中抽離出來，需要用戶單獨授權，畢竟手機號是一個非常關鍵的用戶信息，可謂是現在的網際網路通行證。
所以，微信的信息授權分為兩種：一種是手機號授權、另一種是用戶其他信息授權。
這兩種授權非常簡單，只需要一步點擊操作，即可觸發微信登錄底部彈窗，直接授權手機號或者用戶基本信息，比傳統的登錄操作要便捷很多，這也正是微信生態的優勢所在。
但是出於對用戶信息保護的考慮，也為了避免打擾用戶，微信對用戶信息授權的觸發方式做了各種限制。這不得不提微信的審核機制。
微信的小程序生態和蘋果的應用生態非常類似，新開發的應用都需要審核通過，才能上架開放出去。
開發iOS版本的應用時，很多開發者經常會遇到審核不通過的情況，因為蘋果制定了一套審核標準，必須符合蘋果的設計規範和基本要求才能通過，否則要被打回修改。
微信沿用了蘋果的審核機制，同樣制定了一系列的標準。我們在這個項目中就遇到審核不通過的情況，被打回的原因就是：授權方式不規範。
「你好，小程序帳號登錄功能暫未符合規範要求，請在用戶了解體驗小程序功能後，再要求用戶進行帳號登錄。請整改後再重新提交審核，具體登錄規範及整改可參考：https://developers.weixin.qq.com/community/operate/doc/000640bb8441b82900e89f48351401
請根據上述原因對小程序進行修改，並重新提交代碼審核。
若對上述原因無法理解，可前往反饋頁面進行反饋。
我們原來的設計方案是：用戶進入小程序後，會顯示啟動頁，手機號和用戶基本信息授權成功後才能進入小程序主頁面。
但這是微信不允許的，簡單說，就是不能一進入小程序就直接彈窗提示用戶登錄，必須要讓用戶看到小程序的主體內容後，並手動點擊按鈕去觸發登錄彈窗。
就連我們這種用啟動頁過渡的方式也是不允許的，必須要進入小程序並看到一級頁面才行。
最後我們不得不臨時改動產品方案，在首頁和「我的」頁中分別增加了授權手機號、授權用戶信息兩個觸發按鈕。
3.4 用戶標識
用戶授權的底層是和用戶標識有關。
為什麼我們需要用戶標識呢？
有兩方面作用：
一是微信用戶數據與外部數據的打通，也就是與自己的已有業務數據打通，比如某個用戶已經在我們的後台有了購買數據，那麼我們只要確定了他的身份，然後和我們後台的客戶標識進行對比，就可以知道他到底是不是我們的已有客戶。
目前用戶唯一性的通用標識是手機號，因為手機號是實名的，與身份證綁定在一起。確定了一個用戶是我們後台的已有客戶時，就可以直接把他的購買數據推到小程序端，這個用戶也就可以看到自己的保單數據了。
二是微信內部不同應用數據之間的打通，確定了用戶的唯一性後，其在不同微信應用的行為數據或業務數據就可以串在一起了，比如在訂閱號的閱讀數據、在小程序中的行為數據等。
每一個人都是一個數據源，無時無刻不在創造著各種數據，只不過這些數據要麼沒有被收集到、要麼散落在不同的應用中，所以我們若能收集到這些在不同場景中的碎片化數據，並想辦法歸類到創造這些數據的同一個人身上，我們就能更加全面的和深刻地了解這個人。
這也就是所謂用戶畫像的由來，只不過現在大多數的用戶畫像還非常單薄，可能只有性別、年齡、地域、手機設備型號等屬性數據，而沒有更加深入的、更加細節的信息。
比如從一個人的外賣數據中可以了解到他的飲食習慣，也可以知道他的長住地，公司或者家庭地址等；從一個人的購物數據中可以獲取到他的最近生活方式變化，像開始買紙尿布，推測其有了孩子，後來又買了童裝，則說明他的孩子長大了；從一個人的聊天記錄數據和通信錄數據中可以抽離出更多的有效信息，這個人的說話方式、關係網、最近的心理狀態等等。
唯一的問題就是這些不同場景的數據在不同的平台中，而且是非格式化的數據，包括文字、視音頻等主動數據和點擊查看等被動數據。
那麼我們就需要每個用戶都有唯一的標識，並將其在不同的應用中的不同唯一標識串起來。
在一個應用內，比如小程序、訂閱號或服務號，每個用戶都會打上唯一標識，這個就是OpenID，為什麼叫Open呢？
因為這個ID會提供給應用所屬的企業，但是為了保護用戶隱私，也是為了保護自己的數據資產，微信肯定不會直接把手機號、微信號等重要信息給其他企業，所以這個公開的ID是經過特殊規則轉換過的一個特殊字符串，不包含任何明文信息。
但此時也會出現問題，要是一個企業有多個小程序，還有訂閱號或服務號，那一個用戶在同時使用這些應用時，在每個應用內都有一個唯一標識，也就是會有多個OpenID，那到底有多少真實用戶呢？而且單個用戶在不同應用中的行為數據怎麼串起來呢？
總不能一個用戶在訂閱號中標識為用戶A，跳轉到小程序後，就標識成用戶B，然後數據也就被割裂開吧？
於是，便有了UnionID，就像字面上的意思，聯合的標識。
有了UnionID，同一用戶在不同應用中的不同OpenID就可以映射到唯一的UnionID上了。
簡單總結：
- OpenID是同一用戶同一應用的唯一標識。
- UnionID是同一用戶不同應用的唯一標識。
OpenID是不需要授權的，在公眾號中，關注公眾號時企業可以獲取用戶的OpenID，在小程序中，進入小程序時即可直接獲取。
但是UnionID則不同，在公眾號中，不僅需要用戶關注我們的公眾號，還需要開發者去微信開放平台綁定公眾號後，才可以獲取UnionID；小程序獲取UnionID的規則更複雜一些，用戶進入小程序時，如果用戶已經關注了與小程序同一主體的公眾號，而且公眾號已經獲取了用戶的UnionID，而不需再次授權，否則的話，需要在小程序中單獨授權才能獲取UnionID。
3.5 數據埋點
在項目完成到最後階段時，數據指標一定不能忘，數據指標是量化評估你所做需求的實際效果的關鍵。
關於數據埋點，分兩種情況：
- 一種公司和產品已經比較成熟，也比較穩定，也有現成的數據分析工具，有完善的數據埋點規範，埋點的成本比較低，那就可以全面埋點；
- 另一種是公司處於草莽時期，只是想趕緊疊代，趕緊推上線，關於數據埋點沒有統一規範，但此時依舊不能沒有數據支撐，因為沒有設置好基本的監控數據就上線產品，就像飛機的盲飛，你可能飛起來了，卻不知道還有多少油、數據情況怎麼樣、是變好還是變差，如果要改動，要改哪裡。
事無巨細地追蹤所有用戶行為，需要全面鋪上數據埋點，工作量巨大，對於正在快速疊代的初創企業確實不太現實，可能幾個月後才能看到數據，所以建議採取分級分步的方法，優先定義出最重要的幾個事件追蹤，然後再做其次重要的事件。
不過好在微信小程序本身就提供了基本的數據統計，而且還有直接配置的埋點方式，無需代碼，這樣就簡單很多了。
在微信小程序後台，整體可分為常規分析和自定義分析。
常規分析就是不需要自己數據埋點，微信直接就能收集到的數據，分為三類：
（1）新增、活躍、留存等概況數據，對應「使用分析」模塊
（2）頁面流量數據，又分成了實時和非實時，分別在「使用分析中的頁面分析」和「實時分析」兩個模塊
（3）用戶畫像數據，包括性別、年齡、地區和終端機型
自定義分析也就是數據埋點，分了兩種方式：直接配置和API上報。
1）直接配置
只需要填寫事件名稱、觸發動作和頁面元素的ID即可，不需要添加代碼，也不需要上線，這種埋點方式適合統計功能的使用情況，比如多少人點擊了簽到按鈕、多少人進入設置頁面等。
2）API上報
適用於收集事件下的具體屬性數據，比如點擊商品這個事件，如果我們想要知道用戶具體點擊了什麼商品、商品的價格是多少等信息，就需要這種添加代碼的數據埋點方式了。
從另一個維度看，數據又可以分為兩大類：用戶數據和業務數據。
用戶數據包括用戶畫像和行為數據，業務數據則是和業務直接相關的數據，比如購買金額、購買頻率等。
對不同類型數據的分析要在不同平台處理，微信小程序提供的數據分析更多是集中在用戶數據部分，業務數據則主要在公司自己的業務後台。
「如果你從頭開始建立用戶行為追蹤計劃，建議先找到3個最重要的一級事件，這3個一級事件，應該代表了用戶從初次接觸產品到最終成功使用產品的最重要的里程碑。」
這是我之前在書中看到的埋點理論，把這個理論用到我們的產品中，最關鍵的3個一級事件是：進入小程序（PV/UV）、關鍵功能1的按鈕點擊（PV/UV）、關鍵功能2的按鈕點擊（PV/UV）。
當我按照之前在書中看到的這套理論梳理了三個關鍵指標後，才發現實際情況沒有這麼簡單。
先是leader直接就發現了問題：這不是關鍵指標，應該和業務結合，目前最重要的是要讓保險銷售知道自己名下哪個客戶有沒有使用小程序，然後推動客戶去使用，如果用簡單的PV、UV、按鈕點擊等等，對業務沒有什麼幫助，適合後期再去完善。
之後又深入思考了現狀：我們現在有2個微信公眾號和即將上線的2個小程序，已經構建起了一個微信生態服務矩陣，因此要考慮到4個應用之間的互聯互通，而不只是我現在負責的這個小程序需要收集使用情況的數據，其他兩個公眾號和另一個小程序同樣需要。
那我們怎麼把這幾個微信生態應用的數據使用情況集合到一起呢？
我們了解到另一個產品經理正在保險業務系統中做用戶行為軌跡模塊，即收集一個用戶從接觸到我們的品牌、到使用我們的服務、再到滿足需求，整個業務流程的數據。
這兩個小程序的使用數據也正是整個業務流程中的一部分，他現在已經收集了公眾號的使用情況，因此可以把兩個小程序的使用情況也放到這個模塊中。
也就是說，我們把我們想要的數據需求提交給另一個負責用戶行為軌跡的產品經理，把數據融合在他所做的模塊中，然後我們這邊再做一個用戶是否使用小程序的提醒功能即可，這就實現了一個新小程序的初步數據統計需求，之後再按正常流程提數據埋點需求，把核心頁面和關鍵流程都鋪上點。
我們產品內部策劃好這個需求後，再與程式設計師溝通時，又遇到了一個問題。
因為沒有事前規劃好，已經臨近小程序上線，即使需求較小，現在再改代碼會打亂髮版節奏，所以開發建議在上線後一周內緊接著疊代一個小版本，把一些上線後暴露出來的問題和這個埋點需求整合在一版中。經過評估，這也在可接受的範圍內，所以就按照這個節奏執行了。
這才是實際業務場景中遇到的真實情況，而不是書上講的那麼清晰和簡單。
所以，並不是知道了一個方法論或者一個道理就可以直接套用，而是要結合實際的業務再次深入思考，並根據實際情況及時調整才能真正解決問題。
總結
從定位、到規劃、再到落地，一款微信小程序歷經打磨後終於上線了。
根據線上的數據和用戶反饋，然後開始進行下一版的疊代，不但要解決線上的一些問題，還有可能要修正原來的規劃方向，畢竟真實的效果和自己最初的設想常常會有非常大的出入。
目前這個項目已經疊代了兩個大版本。
真實的項目不是閉門造車，在實操的過程中一定會有大量的細節問題和業務問題，所以我梳理了整個項目後，在這裡寫下的文字略去了諸多細節，只保留了整體的框架、核心的流程和關鍵的問題。
如果問我在這個項目中收穫最大的是什麼？
還是最開始時說的：
首先是從0到1做了一款新產品，這讓我對整個產品的規劃能力有了很大提升，也對公司內部不同系統之間的協同與配合有了更深的理解；
其次才是做了一款微信小程序，對微信生態有了更多的思考，對小程序的特點有了更多了解，只有先掌握好小程序這個工具，才能更好地服務實際業務。
做產品，和拍電影或寫東西一樣，形式與內容，兩者不可偏廢。
本文由 @岳小魚 原創發布於人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議