從0獲取10萬種子用戶實操全流程

寫在前面：產品運營從0到1（實操篇）：如何獲取種子用戶的系列文章，主要是針對產品、人羣、渠道、文案、活動、優化六個方面來寫。

至於爲什麼先寫實操篇：

1、實操篇難寫而且累，沒有真正主導、經歷過的人很難寫出來；

2、網上的文章大多講理論，脫離了實操的步驟，小白一般看的很明白卻不知道如何下手實踐。

3、從實操到理論更好理解理論層面，幫助新手快速成長。

步入正體：最近特別幸運，經歷了兩個工具產品從0冷啓動階段，這兩個產品已經開始增長，個人感覺有必要總結一下這方面的想法和趟過的坑。

接手產品冷啓動，看了很多網上的文章，很多從思想層面來分析或者大方向指點，真正落地是有問題的，也就是看着說的都對，做起來卻都錯。其實有一部分寫文章的人，把其他人的思維總結一下就拿出來分享，連運營基本的玩法都沒搞明白。看這類總結是真沒有價值。

本篇不同於市面上講理論和案例的文章，將會從落地方向分享，做過的先有產品後有運營的套路，與先有運營和後有產品的運營方式略微有所不同，另一個產品屬於先有運營後有產品的運營套路。（如果有時間，將會從0到1分享，ai產品的快速落地，從先有用戶後有產品的思路來寫）。

這篇文章更適合剛入運營的小白，大多操作都屬於落地層面，思想也有不過不作爲重要總結，真正的思想層面的東西，將會在思想篇總結。這頓操作是如何把產品從0做到大幾萬用戶，而且行業內的人也已經知道，用戶奔着10萬的目標去了。

做一件事情的時候，一定要明白做這件事情的目的或者意義，不然就屬於盲幹，對於產品運營，每一個階段都會有北極星指標。

產品的北極星指標怎麼來，一般都是領導下達或者運營部門上報，領導審批。

一、目標

第一階段北極星指標：快速獲取1萬用戶並驗證產品是否達到了pmf。老闆這句話有兩個重要的指示：

1、快速獲取1萬用戶，快速過於籠統，只能找領導在此之前溝通。

2、產品是否達到pmf，pmf應該也有一個指標，何種狀態屬於達到了pmf。

於是把老闆、產品和運營，最好也叫上技術，一塊討論一下，快速到底有多塊，何種狀態爲pmf，對於籠統的指標一定要量化，講感覺的指標都不靠譜。

最終定義爲：快速的時間爲1個月，pmf狀態爲次日留存大於20%。

於是北極星指標改爲：1個月內獲取1萬用戶，並驗證產品次日留存率是否大於20%。

運營的目標很明確：1個月內獲取1萬用戶，產品目標也很明確：次日留存大於20%。

所有的指標要可量化纔能有接下來的運營方案。

二、產品定位

有了目標要對產品進行定位，我接觸產品的時候，產品已經制作出來，但是還沒有上線，對於一個創業公司來講，在產品沒有上線的時候優化產品細節是很致命的一件事情，

無論如何，產品已經有了，那就從產品角度進行分析，對產品進行定位，開幹吧！

2.1、產品屬性

產品是aixcoder智能編程插件，只有程序員纔會用的產品。程序員絕大多數都在電腦上寫代碼，也就決定了產品的使用場景：程序員坐在電腦前編程。

雖然都是坐在電腦前，但是操作系統、編程工具、編程語言都不同，產品使用場景也將從這三個緯度方面來劃分。

2.1.1、操作系統

Windos、Mac、Linux

2.1.2、編程工具

IntelliJ IDEA、Eclipse、PyCharm、Android Studio、PhpStorm、Visual Studio Code、sublime……

2.1.3、編程語言

Java、python、php、c++、js、go……

按照產品使用場景劃分，有這麼多的操作系統、編程工具和語言，那一個纔是主攻路線？我們是從3個方面進行數據統計和判定。

2.2、產品數據

2.2.1、調查問卷

調查問卷發哪裏？平時看到有人在朋友圈發送調查問卷的鏈接，這種方式獲取的數據可信性有待考察。畢竟朋友看到之後可能會給你填寫，但是他不是做這個行業的人，這種拿到的數據沒有可信性。

調查問卷發放的最佳姿勢，加入幾個相關QQ羣，之所以建議入QQ羣入手，因爲微信羣不太好找，QQ有搜索功能可以找到相關QQ羣。

發出一個調查問卷的鏈接，隨即發一個紅包，個人感覺有兩個好處：

（1）、避免被羣主或者管理員踢出

（2）、調動羣內用戶的積極性

從操作來看，卻是避免了被管理員踢出羣，而且能收集到10%羣用戶的反饋，不發紅包收集到大於3%左右的用戶反饋。

2.2.2、內部討論

選取那個作爲主打的渠道，一般老闆和產品經理已經有思路了，但是他們的想法有的時候並不靠譜，一定要拿出數據來決定選取那個渠道；或者產品經理在做產品的時候，已經對產品數據進行過統計，根據產品經理的數據就可以選擇主要的方向。

2.2.3、第三方數據

每一年都會有數據統計機構，放出一些數據，通過互聯網可以獲取到這些數據，不過不建議通過百度搜索，很多搜索出來的數據都不靠譜，如果你不知道有沒有類似的數據，最好還是找專業人問一下。

針對編程語言：編程行業還是容易獲取到編程語言使用情況。

2019年3月份編程語言排行榜

 

針對使用場景：windows、mac和Linux都支持，不存在先投放那個操作系統的問題。

針對編程工具：這個需要對用戶進行調研，根據用戶調研數據，發現有一部分人使用的編輯器產品不支持，從其他方面數據來分析，沒辦法按照編輯器進行產品推廣，除非上官方市場。

於是我們根據產品使用場景的獲取用戶的投放就排列出來，從語言入手：按照語言排行榜從上往下，按照產品已經支持的語言投放。暫不考慮操作系統和編程工具的因素。

三、人羣定位

其實這個產品已經決定了人羣，程序員。針對程序員人羣劃分，工具類產品的人羣劃分沒辦法按照普適性產品，按照性別、年齡、偏好進行劃分，這裏只能劃分成初級程序員，高級程序員。

3.1、用戶屬性

也可以通過第三方的工具進行探索性劃分，比如按照Java從地域、年齡、興趣分佈

從這裏，可以得出：我們的用戶羣體爲：30-39歲的的男性，因爲興趣分佈差不多。

這裏得出的是表面現象，是一種極度不負責任的推論。因爲這個編程類工具，對任何程序員都適用，所以我們的用戶羣體爲全體的程序員。

3.2、用戶愛好

根據Java用戶搜索訪問java的數據進行訪問設備劃分，（ps：這裏的訪問設備不同於產品使用設備）

按照用戶日常訪問數據，發現一個很有意思的現象，週六週日這兩天數據偏低，主要是週六週日的程序員不上班，於是我們就放棄了週六週日推廣產品的想法。（到後面的產品使用數據也證明了我們的想法。）

3.3、用戶聚集地

用戶都在哪裏？所謂的魚塘到底有沒有？其實是有的，比如：qq羣就算一個小魚塘。

國內最大的程序員聚集地：CSDN、51CTO。

既然有魚塘，有沒有辦法從裏面釣魚？

常規想到的是發帖子、不過這類方式來的太慢，不能滿足公司的目標。至於這些渠道如何玩，在渠道的裏面會做介紹。

從人羣定位，我們可以得出，我們的產品投放人羣：針對所有程序員的pc端，時間：週一到週五的工作時間。

四、渠道

非常開心，渠道是我的強項，因爲我是網絡營銷出身，從seo、sem、自媒體、電商、社會化媒體、edm都有過操作。

按照我個人的理解，每個渠道都有流量，只是流量多少的問題，能不能支撐起來公司的業務目標。

4.1、渠道劃分

按照獲客渠道的三種類型，我們把渠道劃分成：口碑渠道、有機渠道和付費渠道。

其中口碑渠道有：社交媒體（比如：微信、微博）、朋友推薦、社區推薦等等

有機渠道：SEO、內容營銷、edm、投稿等等

付費渠道：SEM、廣點通、粉絲通、贊助等等

其實每個運營人員都會想到這些渠道，但是好多人（包括運營總監）不瞭解渠道的特性，做方案的時候，只能胡說一通，搞了一個根本不能測試或者實行的方案。

有的時候產品是一個好產品，被一些不懂運營和推廣的人給玩死了。

如果有幸在大廠，這種渠道劃分的問題幾乎不存在，隨便一個渠道導量過來就足以讓產品成爲6位數的明星啓動產品，不過大多數的運營並沒有那麼幸運，只能按照這些渠道來吸引用戶。

4.2、渠道測試

羅列出來這麼多的渠道，至於先投放那個，從掌握情況、成本、時間投入、產出時間、規模幾個方面進行評測。

確認掌握情況：對於渠道的瞭解程度，團隊中誰對渠道比較瞭解，讓對渠道比較瞭解的人，確認渠道是否能用，按照5分計算，看看我們對渠道掌握分數是否及格，以及其他投入的計算，並且內部討論渠道是否可以測試。

這裏只是一些簡單的羅列，其實在這正考慮以及計算的時候要比這個表格詳細，至於爲什麼一天觸達這麼多人，爲什麼花費這麼多錢，以及最後的轉化多少人，一定要有理有據的羅列出來，不然領導會質疑或者不給通過測試。

對於別人的疑問，渠道人員一定要能解釋詳細，而且要堅持自己的觀點，當時出現的爭執，很多人認爲EDM在國內沒有效果，大家一致認爲要放棄EDM渠道。

對於我個人而言，我知道如何做有效果，堅持要做EDM，最後一天發送1萬封郵件，轉化大概500下載使用用戶，轉化率在5%左右，一封郵件的成本在3分錢左右，也就是一個用戶的成本在0.6元，非常划算的ROI。

第一輪篩選出來的渠道有：EDM、SEM、贊助、付費投稿

測試順序爲：EDM、SEM、贊助、付費投稿（這裏有人會問，爲什麼付費投稿又搞出來了，因爲渠道太少，沒有可以拓展的空間）

4.3、渠道細分：

4.3.1、EDM渠道，按照語言和ide進行劃分，語言有java、python、php、js、c、c++，按照ide劃分，用戶量太少，暫時放棄。

SEM：渠道暫時只投放百度，考慮程序員只用電腦，放棄移動端，渠道只有百度&pc。

4.3.2、贊助：按照綜合領域和垂直領域進行贊助，綜合領域又csdn、51cto等等，垂直領域又java、python。

當然，這裏細分完之後，又應該有一個表格，這個表格我以EDM爲例進行展示，因爲有些數據確實不方便透露。

渠道細分完，準備需要的東西，上線進行測試，最終拿到測試結果，我們預估獲取用戶的單價在15元左右。

測試結果：測試結果按照細分渠道統計，根據總目標的kpi，考覈指標爲註冊用戶單價。

百度&pc：150元，贊助：csdn:150、51cto：60；垂直領域java1：6元；EDM：java：0.6，python：1.5，spring：0.9。

4.4、渠道壽命：

每一個固定用戶渠道都有一定壽命，隨着在單一渠道的加大力度投入，渠道的流量來源就會枯竭。這裏不包含dsp、sem、seo這些流動渠道。

4.4.1、固定用戶渠道：

因爲固定用戶渠道，一般用戶羣體變動很小，你從這裏獲取用戶，這裏的用戶只有流出，沒有流入，最後池子裏的用戶日漸枯竭，最終就要換渠道。

4.4.2、流動渠道：

而流動用戶的渠道，一般有客戶的流入和流出，池子裏的用戶永遠不會枯竭，而且流入的用戶遠大於流出的用戶，這樣的池子可以一直利用下去。

渠道測試完畢，可以篩選出來合適的渠道加大投放，不合適的渠道暫停投放。讓我們始料未及的問題還是來了，EDM渠道，因爲規則的改變，再我們進行了兩個月之後，渠道徹底的廢掉，需要用其他渠道來代替。

也就是在做渠道測試的時候，至少要有1個主要渠道，2個輔助渠道，一旦主要除了問題，及時加大輔助渠道投入，不至於主要渠道除了問題之後手忙腳亂。

 

至於文案在渠道前還是渠道後，現在想想肯定是在投放渠道前寫，但是可以肯定的是，渠道和人羣確定了之後，我們才能確定文案的寫作風格，以及寫成什麼樣子，所以還是把文案放在了渠道之後寫。

當然，如果有不同意見的朋友，可以提出來，咱們一塊探討。

五、文案

這裏的文案包含廣告頁面上的文字、網站上的文字、軟文，並不單指寫在廣告上的文字和網站上的短文字。

至於文案寫成什麼樣子，還是取決於文案在整個流程中的作用。

5.1、文案撰寫

文案撰寫與渠道、產品、人羣和在渠道中的作用是分不開的，這裏我們舉例sem、banner圖、edm和軟文四個方面來寫。

首先分析文案在其中的作用

1、sem：吸引用戶點擊到落地頁。

2、banner圖：吸引用戶點擊到落地頁

3、edm：標題：吸引用戶打開郵件，內容：讓用戶產生興趣並轉化。

4、軟文：標題：吸引用戶打開文章，內容：讓用戶產生興趣並轉化。

這裏的文案大致可以分爲兩類，1、吸引用戶點擊；2、讓用戶產生興趣並轉化。

對於小型的公司來講，文案很少承載產品形象，因爲一般高大上的文案轉化並不是太好，或者說有一個較長的時間轉化，只是加深品牌在用戶心智中的地位，顯然對於生存纔是硬道理的公司並不划算。

於是，我們的文案決定方向：

標題：誇張、引人醒目。

內容：寫出亮點，提升用戶轉化。

考慮我們的產品是國內首家，而且世界上只有寥寥無幾的人在做，而且國內知名度不高，於是我們的內容偏向使用方面來寫。

在banner圖的文案，字數較少，只能用ai編程提升3倍工作效率這類的字眼。

於是我們的軟文標題就出現了：人工智能幫你寫java代碼，99%的程序員都不知道的代碼必備神器，ai擼碼神器讓程序員界沸騰了……郵件的標題大致就：邀請您一起XXX

sem的標題和簡介有自己的規則，在寫標題的時候有自己的規則，首先要符合他通用詞的規則，一般爲：你還在找{代碼補全}工具嗎？大家都在用ai寫代碼了。

看起來好標題黨，不過這樣的點擊還是可以的，當然咯，如果內容跟不上標題就會被人罵標題黨，內容攥寫方面還是要與標題相符合。

我們的內容方向是產品介紹，與ide自帶的代碼補全的區別與優勢。突出產品使用的便利性和先進性，附上用戶評論照片。

EDM還是以邀請的口吻敘述，邀請編程大牛一起做人工智能編程。

5.2、文案修改

文案寫完投放出去就萬事大吉了？NO！還差得遠，這纔是剛剛開始。

在文案落地之後，把從曝光，點擊，轉化等一系列的用戶數據做好記錄，在數據中分析問題。

理想狀態我們在每一層的數據都能進行埋點，做成數據漏斗，分析數據轉化問題，然而實際工作中，有幾家公司可以做完這些步驟，很少很少。

更多的時候，還是依靠運營敏銳的判斷力，至於判斷力如何養成，只能是多踩坑了。不過說過來，能統計的數據還是要統計上。

百度可以統計到點擊率、進入網站的pv、最終的下載量；banner圖統計不到曝光，只能統計進入網站的pv和最終的下載量；edm可以統計發送數量、打開率、點擊下載鏈接；軟文可以統計閱讀量，至於轉化統計就很尷尬，基本上屬於當天發送完，統計24個小時的註冊量，至於閱讀量與之前10篇的平均閱讀量相比，看文章標題如何。

拿到這些數據之後，再決定對標題還是對文案進行優化。有一些不怕死的運營或者文案人員，修改什麼東西都是靠感覺，還是建議一下，感覺不靠譜，還是數據靠譜。

整體的文案、標題和內容相符合，以及後期優化之後，整體的轉化效果超過了我們的預期，在如此長的轉化鏈路下，最差的閱讀轉化效果也到了10%。

六、活動

拿到了第一波的用戶之後，只能讓他們作爲一個產品使用者嗎？如果他們只作爲一個產品使用者，在他們身上花的引流的費用就有點浪費了，把他們變成產品的形象大使或者品牌的宣傳者。

很多人又會分析AARRR模型，套用理論是沒有錯的，關鍵還是要落地。

讓用戶分享一個產品，個人認爲只有兩個方面：1、產品足夠令人驚喜，用完之後滿足了用戶的心裏，自動發起分享。2、物質獎勵，刺激用戶進行分享。

6.1、活動目的

預選本次活動目的：1、增加用戶註冊量；2、增加產品知名度。

我們可以說出很多個活動的目的，不要忘記，現在階段的北極星指標是增加用戶註冊量，所有的活動以及其他操作，均要貼合這個目標。

確定活動目的：增加用戶註冊量！

這個目的有了，目的不能作爲考察的指標，於是把模糊不清的數據進行量化。

活動目標：1個月通過活動增長2000用戶。（ps：目標不能拍腦門定，要根據投入的資源和精力進行估算，特別是揹負巨強kpi的運營，拍腦門的目標當心你的獎金不見哦～）

6.2、活動細節

要用戶分享產品，顯然產品本身並沒有讓用戶產生尖叫感，只能通過活動獎勵讓用戶產生傳播。

這裏有很多種獎品方式，不過一般公司不會通過RMB來刺激用戶，當然也有通過RMB刺激用戶的產品。對於一個沒有充值接口的工具類型產品，通過RMB刺激用戶就有點low了。

還好，在產品設計初期就規劃了社區版本、專業版本和企業私有化版本，社區版本免費，VIP版本是128元/年，企業私有化不在活動考慮範圍之內。

於是我們以最低的成本，邀請滿3個人送1年VIP，並且可以累積，並且送企業文化衫。宣傳渠道爲自由公衆賬號、軟文投放和插件客戶端提示。

6.3、活動流程

活動流程，用戶註冊登陸客戶端的時候，給用戶一個提示，免費升級VIP！用戶點擊之後會跳轉到官網，官網上有一個強提示，在用戶下載客戶端或者瀏覽網站的時候就能看到，提示用戶升級專業版。

順便說一下，開始升級爲專業版並沒有這麼顯眼，但是轉化太差了就搞的顯眼一些，效果就上來了。

用戶登陸到網站之後，有3種方式供用戶進行選擇，1、圖片邀請，2、文字邀請，3、掃碼分享邀請。

獲取到邀請碼之後，用戶自動去傳播，只要滿足條件就可以自動升級爲vip用戶。

活動的目標定完之後就要

制定活動的日期：2019年7月1號

活動投放渠道：自有公衆號、軟文渠道、官網。

物料準備：公衆號增加獲取專業版tab；軟文增加活動板塊；官網增加活動入口、準備分享的物料；VIP功能的完善、用戶自動升級。

在確定活動計劃的時候，涉及開發以及物料準備，一定要責任到人和確定last day，不然活動就不能如期舉行，運營肯定是要拿來第一個殺了祭天的崗位。

6.3、活動效果

實時監控活動效果，活動上線之後，第一週只有120人蔘與了這個活動，只邀請到了200多人，按照這個節奏，我們的目標遠遠不能完成。

當然嘍，這種很多數據都不能夠進行監控，我們只能分析整個活動的鏈路，看看在哪一步擋住了用戶。

第一：整個鏈路過長。

確實整個鏈路長，但是也只能用戶註冊之後才能邀請用戶，而且目前的研發精力不夠，沒有足夠的時間優化鏈路。

第二：各地方提示不夠突出。

在投放的軟文中突出活動，專門做一個福利板塊，並把重點以及獲取流程標註出來；官網突出獲取專業版的方式；公衆號的一個欄目專門一篇文章介紹如何獲取vip。

優化完這些細節，3周的時間，參與活動達標升級專業版用戶1300多人，邀請VIP用戶5000多人。

整個活動流程大致就是這樣，定好活動目標，確定刺激產品、做好產品流程並優化，確定投放渠道，確定活動日期，確定準備的物料。

說點活動題外話，當初我們與大V合作投放軟文，其中就有一個大V怒氣衝衝的過來找我說我們做了羣裂變，原來是他自己有一個社羣，好多參與活動的用戶把邀請碼都發到他羣裏了。我還給他解釋了一通。最後他並沒有理解，雙方就互刪了好友，從側面也說明了我們活動的效果還是可以的。

七、優化

隨着渠道和活動的深入，用戶的增多，產品暴露出來的問題也就越多。順便說一下，產品測試也很盡力，公司電腦配置較高，而且真正工程中使用和按照測試案例進行測試是兩碼事。

我們收到了很多用戶的吐槽。

7.1、收集問題

如何收集用戶的問題，用戶調研是一個方式，但是用戶調查不一定獲取真實的數據。

我們着重收集自建用戶羣裏的吐槽內容和每次大V投放之後的評論和留言，把這些問題收集起來。

在羣裏吐槽的用戶，能夠私聊的儘量私聊了一下，看一下用戶的問題到底在哪裏。總結所有的問題，最後挑選主要問題進行解決。

7.2、產品改進

產品上線之初，總會有很多的問題，至於改進那個產品的方面，在創業公司尤爲重要，畢竟就那麼幾個人，做了這件事就做不了另外一件事。

最後我們定義了兩個最爲主要的問題，延遲和卡頓。

其中有一部分卡頓是因爲延遲引起的，那麼解決延遲就成了首要的問題。

這裏給大家介紹一個bug修復四象限，快速定義先修復那些bug。

有了這個bug修復四象限，我們就能快速定義修復延遲的問題，其他個別電腦導致IDE卡頓的問題，屬於致命影響人數少，暫時先不處理，畢竟現在用低配電腦的人少。

修復bug屬於AARRR模型中的解決留存問題，當然這裏留存還有一些其他方式，暫時不做討論。

文章來源：運營官張沐