中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

項目整體步驟

項目背景

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

第一步：運營部門任務

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

線上新媒體運營策劃案：至于線上新媒體運營部分在這里簡單介紹一下，主要渠道就是當地各大垂直領域自媒體，報紙硬廣，當地電視媒體報道等等。

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

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

• 目的一：雙12拉新，促活，消費轉化。
• 目的二：商家想預知需要提高備貨量的商品。
• 目的三：通過調查問卷做數據埋點，記錄用戶維度，建立用戶畫像，用關聯算法挖掘用戶數據，做精準推薦提高非預期消費比例。

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

2、要有穩定且執行力強的團隊?，團隊協調也是運營

有了產品才能讓新媒體和地推介入進來，否則你連調查問卷都沒有，就去推廣預熱，你的投入就都白白浪費了。

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

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

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

3、產品設計思路就是做一個H5做的調查問卷

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

問題一：如何解決問卷調查參與感不強的問題

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

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

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

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

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

4、運營產品策劃案交付審核，下發

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

第二步：產品部門任務

1、需求文檔編寫

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

2、產品文檔交付技術部門，開發說“無法實現”是真的嗎？

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

技術部人員的性格跟產品運營部門最大的區別在于，一個想一勞永逸，一個不斷要出新玩法，不斷提升用戶體驗，對于技術部人員來說，他們覺得最理想的系統就是健壯的，后期產品運營部門提出任何需求，技術部都不需要改代碼，直接告訴他們如何在后臺配置一下就可以了，對于產品運營人員來說，每次活動都要標新立異，都要不一樣，都要有新的數據埋點，所以就產生了以上的矛盾，那么如何解決呢？

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

2.?一切以運營部的標準為標準，因為運營部門是跟市場關系最緊密的部門，所以提出的建議和需求都是經過市場調查和數據分析的結果，保證運營部門的需求是大前提。

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

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

第三步：技術部門任務

1、拿到需求文檔，分配任務

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

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

2、著重講一下關聯算法，最初級的人工智能，數據挖掘算法

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

定義1： 支持度（support）

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

定義2： 置信度（confidence）

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

定義3： 頻繁項目集

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

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

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

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

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

以上就是本次項目從運營，產品，技術三個維度的詳細剖析，經驗尚淺，大家且閱且指教。

作者：MT，一個為了做產品，臥薪嘗膽，沉淀了8年技術的全棧工程師，兼職眾創空間講師。

本文由 @MT 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 unsplash，基于 CC0 協議