我用最簡單粗暴的形式，為大家講解一個調(diào)查問卷項目橫跨運營，產(chǎn)品，技術(shù)三個部門的背后，到底都經(jīng)歷了什么，從無從下手到順?biāo)兄?，詳?xì)講述一個用戶調(diào)查問卷產(chǎn)品的生命周期，并且從代碼層級展示一套初級的人工智能算法如何挖掘用戶數(shù)據(jù)，那么這套算法對于商城類的線上產(chǎn)品有什么作用呢？簡單來說就是，通過算法算出商品之間的關(guān)聯(lián)性，下面我來帶你們一步一步分別從運營，產(chǎn)品，技術(shù)三個維度去做這個項目。

項目整體步驟

項目背景

廣電智能機(jī)頂盒覆蓋率高達(dá)80%以上，覆蓋用戶千萬級，我們的產(chǎn)品是基于廣電內(nèi)網(wǎng)的智能機(jī)頂盒的線上超市業(yè)務(wù)，以新零售作為出發(fā)點，用戶在家用機(jī)頂盒下單，社區(qū)附近超市配送，雙十二需要提前備貨，所以庫存貨物品類是否精準(zhǔn)，會直接影響到此次活動的成敗，商家希望能預(yù)知某種商品的需求度，提前備貨，運營部門需要線上線下配合做好這次活動，那么除了要預(yù)先知道不同產(chǎn)品客戶的需求量以外，最重要的就是要做到精準(zhǔn)推薦，讓用戶買他本來沒想到要買，但是確實需要的東西。

第一步：運營部門任務(wù)

線下運營策劃案：線下運營主要流程就是，先出線下地推方案，然后市場部門帶著方案跟之前有過合作的超市去洽談地推細(xì)節(jié)讓他們提供場地支持和優(yōu)惠券支持，敲定具體推廣地點和時間，然后再進(jìn)入社區(qū)找到社區(qū)物業(yè)或者居委會洽談社區(qū)內(nèi)的地推時間和地點，由于是政府項目，所以居委會積極響應(yīng)，此次活動開展的還算比較順利。后期我們就讓地推團(tuán)隊帶著易拉寶和DM單，同時進(jìn)入社區(qū)和周邊超市推廣預(yù)熱去了，由于本文章主要是要講解線上運營，所以這里我就不對線下運營做詳細(xì)的描述了，我會有后續(xù)文章發(fā)上來，一步步的帶大家做地推。

線上新媒體運營策劃案：至于線上新媒體運營部分在這里簡單介紹一下，主要渠道就是當(dāng)?shù)馗鞔蟠怪鳖I(lǐng)域自媒體，報紙硬廣，當(dāng)?shù)仉娨暶襟w報道等等。

線上產(chǎn)品運營策劃案：我們這次主要來說一下線上產(chǎn)品運營，拿到這個項目的需求就只有老板的一句話，要做雙12，銷量要翻倍，自己去找資源，自己去協(xié)調(diào)，自己想方案，運營的工作就是這樣，一開始都無從下手，不知道先干什么后干什么，那么就需要你自己目標(biāo)感特別強(qiáng)，在迷茫的時候想一想源點，我到底是為什么要做這個活動，那么想做線上運營第一步就是基礎(chǔ)數(shù)據(jù)分析，那么有人會說，如果是冷啟動階段，沒有數(shù)據(jù)怎么辦，當(dāng)然也有其他渠道可以做數(shù)據(jù)分析我后面會說，先看下圖，這是雙十一期間的銷售數(shù)據(jù)。

1、首先分析此次活動的目的

• 目的一：雙12拉新，促活，消費轉(zhuǎn)化。
• 目的二：商家想預(yù)知需要提高備貨量的商品。
• 目的三：通過調(diào)查問卷做數(shù)據(jù)埋點，記錄用戶維度，建立用戶畫像，用關(guān)聯(lián)算法挖掘用戶數(shù)據(jù)，做精準(zhǔn)推薦提高非預(yù)期消費比例。

基于這三個目的，所以不光要做同比環(huán)比數(shù)據(jù)對比，還著重看雙11期間的數(shù)據(jù)，上圖就是雙11期間后臺統(tǒng)計的數(shù)據(jù)，最后從數(shù)據(jù)中分析出幾種購買頻次比較高的商品，發(fā)現(xiàn)例如米面油這些剛需產(chǎn)品的購買頻次最高，酒水飲料其次，所以這些產(chǎn)品就是這次調(diào)查問卷的主要涉及維度，基于這些維度在做深度數(shù)據(jù)挖掘。

2、要有穩(wěn)定且執(zhí)行力強(qiáng)的團(tuán)隊?，團(tuán)隊協(xié)調(diào)也是運營

有了產(chǎn)品才能讓新媒體和地推介入進(jìn)來，否則你連調(diào)查問卷都沒有，就去推廣預(yù)熱，你的投入就都白白浪費了。

其實，產(chǎn)品和運營兩個部門的主要矛盾就是因為工作內(nèi)容邊界比較模糊，有些產(chǎn)品的工作其實離不開運營提出的建議，甚至一些運營人員都要替產(chǎn)品去寫需求文檔。所以后期就會出現(xiàn)一種現(xiàn)象，明明是運營人員輸出的價值結(jié)果，產(chǎn)品經(jīng)理拿去上老板那邊邀功請賞，說這個產(chǎn)品的創(chuàng)意是他自己想出來的，這點就會讓運營人員很不舒服，后期直接導(dǎo)致產(chǎn)品缺乏創(chuàng)意，怎么可能達(dá)到很好的運營效果？

所以比較靠譜的解決方式就是，統(tǒng)一的團(tuán)隊KPI，運營，產(chǎn)品，技術(shù)三個部門KPI相互關(guān)聯(lián)，利益共同體，功過分明，功勞是誰的就是誰的，并且每個部門的主管是項目需求的唯一出入口，項目主管的核心作用就是降低團(tuán)隊內(nèi)部和團(tuán)隊間的溝通成本，攻克項目中出現(xiàn)的難題。

我相信大家都遇見過那種你有事問他的時候，明明不懂還裝出一副不屑于回答的樣子，要不就是直接甩給你一個QQ號或者手機(jī)號讓你自己去溝通的那種廢柴領(lǐng)導(dǎo)，無形中給團(tuán)隊內(nèi)部增加了大量的溝通成本造成項目成本過高，團(tuán)隊離職率上升。有了強(qiáng)力的團(tuán)隊，下面就是該設(shè)計產(chǎn)品了。

3、產(chǎn)品設(shè)計思路就是做一個H5做的調(diào)查問卷

H5做調(diào)查問卷最大的好處就是多平臺適配，開發(fā)周期短，開發(fā)成本低，非常適合線上線下多渠道推廣活動，有人會說這和一般的調(diào)查問卷沒有什么區(qū)別啊，常見的調(diào)查問卷都是這種形式的，無非就是讓用戶做一些選擇題，其實調(diào)查問卷的背后是用戶畫像，這是一個很大的課題，那些常見的調(diào)查問卷缺少用戶參與感，很簡單的一個例子，當(dāng)你刪除電腦軟件的時候他都會問你為什么刪除，有多少人會真正去按照自己的意愿去選擇，都是直接點擊右上角關(guān)閉按鈕，歸根結(jié)底就是這種調(diào)查問卷缺少參與感，運營的根源就是對人性的把控，那些運營l大咖都非常了解用戶心理學(xué)，那么基于這種用戶思維就產(chǎn)生了兩個問題需要解決：

問題一：如何解決問卷調(diào)查參與感不強(qiáng)的問題

那么我是如何解決以往的調(diào)查問卷沒有參與感這個問題呢，很簡單，用十秒倒計時搶答的方式，讓用戶產(chǎn)生緊迫感，而且用戶不知道后面還有幾道題，永遠(yuǎn)都覺得下一次就是紅包了，所以會一直做到結(jié)束，但是也不建議太多，大概10 – 15個選項就可以了，保證用戶能在1分鐘之內(nèi)選擇完就可以。

問題二：如何解決用戶身份與獎品綁定步驟，層級過深的問題

所謂用戶身份綁定步驟層級太深，就是指往常做問卷調(diào)查涉及到獎品的時候，需要把獎品和用戶綁定，常用的做法就是在做問卷調(diào)查之前或者最后一步，讓用戶通過短信驗證碼綁定手機(jī)號登錄，用戶需要操作的流程是 ?輸入手機(jī)號碼點擊發(fā)送驗證碼——>點擊短信推送進(jìn)入短信詳情——>背下驗證碼——>返回問卷調(diào)查頁面——>輸入驗證碼點擊確定，之前做過一次數(shù)據(jù)分析，每增加一個用戶層級，用戶流失率就會提高20%，也就是以往的問卷調(diào)查方式會流失80%以上的用戶。

那我給你算一筆賬：你花1W塊錢做地推，比如獲客成本是2塊錢的話，也就能引流來5000個人參與問卷調(diào)查，經(jīng)過上面四步每步流失20%用戶，也就是最終要損失掉 5000 * 80% = 4000人 也就是說真實的獲客成本從2塊錢漲到了10塊錢，如果你這次活動引流了1W人的話，你們老板要多花8W塊錢，那么10W人呢，100W人呢，現(xiàn)在看出用戶層級有多么重要了吧。

那么要解決這個問題，就盡量減少用戶層級，能在首層解決的都在首層解決，所以我采用直接由服務(wù)器分配用戶唯一優(yōu)惠碼并與獎品在后臺綁定，用戶只需要在最后頁面點擊保存優(yōu)惠碼圖片，付款的時候直接使用就可以了。兩個問題的解決方式見下圖：

4、運營產(chǎn)品策劃案交付審核，下發(fā)

至此線上運營產(chǎn)品策劃案完畢，把UE和問卷調(diào)查需要采集的用戶標(biāo)簽匯總，交付產(chǎn)品部門，其實大家可以看出來，運營部門其實已經(jīng)幫助產(chǎn)品做了一部分的工作了，所以這就是我剛才說的運營和產(chǎn)品的工作內(nèi)容邊界比較模糊的原因。

第二步：產(chǎn)品部門任務(wù)

1、需求文檔編寫

需求文檔的原則就是要把運營部門的用戶需求，轉(zhuǎn)變成技術(shù)能看的懂的功能需求，從控件大小，組件顏色的色號，到每一個功能的細(xì)節(jié)都要展示出來，甚至一些技術(shù)選型和數(shù)據(jù)交互策略都要體現(xiàn)出來，從而節(jié)省技術(shù)部溝通成本，由于本項目主要是配合運營時間節(jié)點，所以適用敏捷開發(fā)方式，我直接把需求文檔和UE圖整合，效果如下。

2、產(chǎn)品文檔交付技術(shù)部門，開發(fā)說“無法實現(xiàn)”是真的嗎？

拿著需求文檔去跟技術(shù)部開產(chǎn)品會的時候，經(jīng)常會遇到的問題就是，技術(shù)部會找各種借口說無法實現(xiàn)，最后為了保證基本功能，產(chǎn)品妥協(xié)，為了保證按時上線，運營妥協(xié)，后果就是對著悲慘的PVUV只能由大家一起買單，獎金就別想了。難道是真的無法實現(xiàn)嗎？真的是技術(shù)部的人懶嗎？真的是技術(shù)部的人多報工期嗎？

技術(shù)部人員的性格跟產(chǎn)品運營部門最大的區(qū)別在于，一個想一勞永逸，一個不斷要出新玩法，不斷提升用戶體驗，對于技術(shù)部人員來說，他們覺得最理想的系統(tǒng)就是健壯的，后期產(chǎn)品運營部門提出任何需求，技術(shù)部都不需要改代碼，直接告訴他們?nèi)绾卧诤笈_配置一下就可以了，對于產(chǎn)品運營人員來說，每次活動都要標(biāo)新立異，都要不一樣，都要有新的數(shù)據(jù)埋點，所以就產(chǎn)生了以上的矛盾，那么如何解決呢？

1. 首先盡早提出需求，切記不要今天提出需求明天就要，這種行為會讓技術(shù)部很反感。

2.?一切以運營部的標(biāo)準(zhǔn)為標(biāo)準(zhǔn)，因為運營部門是跟市場關(guān)系最緊密的部門，所以提出的建議和需求都是經(jīng)過市場調(diào)查和數(shù)據(jù)分析的結(jié)果，保證運營部門的需求是大前提。

3. 如果現(xiàn)有需求跟原有技術(shù)選型和數(shù)據(jù)架構(gòu)沖突太大，那就只能深入討論，抽絲剝繭，在保證運營需求的前提下適當(dāng)?shù)淖鲆恍┩讌f(xié)，有些時候技術(shù)解決不了的問題，是可以用優(yōu)化交互設(shè)計解決的，例如列表頁的點贊功能，每次點贊都落盤的話服務(wù)器壓力相當(dāng)大，如果數(shù)據(jù)庫也不是用redis的話很容易服務(wù)器宕機(jī)，更換數(shù)據(jù)庫研發(fā)成本太高需要重構(gòu)項目太不現(xiàn)實，所以通過優(yōu)化交互設(shè)計把點贊功能放在更多里面把評論功能放在淺層級，這樣平臺既可以提升UGC(用戶產(chǎn)生的內(nèi)容)，服務(wù)器壓力也減小了。

4. 產(chǎn)品運營人員多了解一些技術(shù)方面的知識是很有必要的，最起碼跟技術(shù)部談判的時候能知道他們是不是在夸大問題，如果真的是技術(shù)部人員消極怠工，故意不干活的話，那就只能直接把立項郵件帶著需求文檔設(shè)計稿@老板@各部門主管，自上而下的分配任務(wù)。

第三步：技術(shù)部門任務(wù)

1、拿到需求文檔，分配任務(wù)

此次問卷調(diào)查項目，需要用到的技術(shù)崗位有，web前端，測試工程師，java后臺工程師，項目經(jīng)理。這四個崗位的任務(wù)，由項目經(jīng)理按照需求下發(fā)到各崗位，按照時間進(jìn)度排期進(jìn)行就可以了，開發(fā)完畢測試通過上線，至此一次項目迭代完成。

1. 項目經(jīng)理任務(wù)：把控整體項目進(jìn)度和成本，發(fā)現(xiàn)需求問題及時與其他部門溝通，編寫接口文檔，攻克技術(shù)難題。
2. java后臺任務(wù)：完善接口文檔，根據(jù)需求文檔和接口文檔做后臺數(shù)據(jù)庫搭建，接口功能實現(xiàn)，關(guān)聯(lián)算法功能實現(xiàn)。
3. web前端任務(wù)：做調(diào)查問卷的頁面效果實現(xiàn)與后臺接口對接，不同分辨率設(shè)備適配。
4. 測試任務(wù)：根據(jù)需求文檔寫測試用例，測試整體項目功能，做好適配測試和jmeter壓力測試。

2、著重講一下關(guān)聯(lián)算法，最初級的人工智能，數(shù)據(jù)挖掘算法

本次線上運營的精髓之一就是利用關(guān)聯(lián)算法增加用戶非理性購買概率，達(dá)到提升消費轉(zhuǎn)化的效果，那么什么是關(guān)聯(lián)算法呢，舉個最簡單的例子就是，你去淘寶看了一款包包，然后頁面拉到底部會有猜你喜歡，那里面的內(nèi)容就是根據(jù)關(guān)聯(lián)算法算出來然后精準(zhǔn)推送給你的，那很多人說了，我知道這種就叫關(guān)聯(lián)算法，但是作為一個運營人員怎么去使用關(guān)聯(lián)算法，作為一個技術(shù)人員研發(fā)關(guān)聯(lián)算法從哪里入手呢？下面拿出我用java實現(xiàn)的關(guān)聯(lián)算法代碼來給大家參考一下。

定義1： 支持度（support）

支持度s是事務(wù)數(shù)據(jù)庫D中包含A U B的事務(wù)百分比，它是概率P（A U B），即support（A B）=P（A U B），它描述了A和B這兩個物品集的并集在所有的事務(wù)中出現(xiàn)的概率。

定義2： 置信度（confidence）

可信度為事務(wù)數(shù)據(jù)庫D中包含A的事務(wù)中同時也包含B的百分比，它是概率P（B|A），即confidence（A B）=P（B|A）。

定義3： 頻繁項目集

支持度不小于用戶給定的最小支持度閾值（minsup）的項集稱為頻繁項目集（簡稱頻集），或者大項目集。所有的頻繁1-項集記為L₁。

定義看的一臉懵逼吧，我給翻譯了一下：

• 支持度：同時買了衣服和褲子的訂單數(shù) ÷ 總訂單數(shù) （也就是看所有訂單里面多少人同時買了衣服褲子，除一下的結(jié)果就是衣服和褲子的支持度）
• 置信度：購買了衣服和褲子的訂單數(shù) ÷ 購買了衣服的訂單數(shù)（也就是所有買了衣服的訂單里面，有多少人還買了褲子，除一下得到的結(jié)果就是衣服和褲子的置信度）
• 頻繁集：就是事先設(shè)定一個最小支持度，比如0.2也就是20%，然后算法會把所有訂單一起計算，不斷的剪枝，凡是支持度不小于最小支持度的項集都是頻繁集

目的就是從頻繁集中選擇支持度和置信度比較大的項集，去做關(guān)聯(lián)推薦，比如我發(fā)現(xiàn)所有訂單中買了衣服以后又買了褲子的人站有70%以上的比例，那我就給所有有意向買衣服的用戶推送褲子，從而提高消費轉(zhuǎn)化率，于是技術(shù)出身的我，用Java實現(xiàn)了這套算法，光說不直觀，看代碼運行效果吧。

這次活動一共獲取到有效用戶維度（數(shù)據(jù)庫記錄條數(shù)）23000組左右，通過算法深度挖掘用戶維度，計算出來以下部分頻繁集，可以看到最后三組，置信度都是80%以上，完全就可以用來關(guān)聯(lián)推送了，這就是一個最初級的人工智能數(shù)據(jù)挖掘算法。

以上就是本次項目從運營，產(chǎn)品，技術(shù)三個維度的詳細(xì)剖析，經(jīng)驗尚淺，大家且閱且指教。

作者：MT，一個為了做產(chǎn)品，臥薪嘗膽，沉淀了8年技術(shù)的全棧工程師，兼職眾創(chuàng)空間講師。

本文由 @MT 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 unsplash，基于 CC0 協(xié)議