活動運營深度解剖(一):活動前準備(含詳細流程圖和大量細節)

我將會在接下來的幾篇文章裡，以一個連續迭代了7個月做了7期的UGC活動為背景，給大夥介紹一下活動運營都需要做些什麼。本文適合1~3年的運營人，從更全局的角度去看一個活動運營。

活動運營流程圖：

理論上，上述時活動的基本流程。單單看這個，或許對活動運營的時候真正要做什麼，遇到什麼，還是沒有對應概念。且看下文的分解。

活動運營：活動的前期準備

一個重運營的活動，如果規模較大，且前期無相關活動模板，則前期需要大量時間搭建模塊，準備素材、跨部門溝通。

如下圖所示：

此圖將活動運營的前期準備分為：

1. 活動產品線（活動線上承接頁面及後臺製作）
2. 運營線（特指活動上線後運營）
3. 推廣線（活動的曝光和傳播準備）

接下來會對這三個方面運營分別要做什麼進行詳細介紹，同時實際工作中需要注意到，這幾條線是幾乎同時進行的，且其中大部分工作都需要在活動上線前完成。

另外次圖僅僅展示在活動目標確認且獲得老闆首肯之後要做的事情，即真實的定位應該是：確認了活動目的及將要落地的活動，其前期準備詳解。

（省略的步驟是：做活動提案，寫明活動背景、玩法、預算、效果、各部門支撐和風險等，做成ppt找上級審核找老闆審批拿錢。老闆首肯後，這個活動規則就可以細化準備執行了）

1.1 活動產品線

背景：一個線上活動，最基本的功能需求肯定是用戶承接頁，然後根據活動的需求和複雜程度，還需要增加相應的運營後臺、用戶信息提取及展示等功能。

思想預防針：產研支撐不一定能製作並滿足最流暢的用戶體驗流程，其他部門的支撐合作程度不一定能滿足活動運營需求，可能要以增加運營成本為代價。保持著把活動做到最優的期待，然後清楚這種最優可能要逐步實現而不是一次辦成，才能在做活動的時候遇到層層阻礙而不會心灰意冷。

1.1.1 確認產品需求

通過明確活動目標、細化的活動規則及用戶參與流程，就可以得出基本的產品需求，在加上其他部門的支撐反饋，則第一期的產品需求就能基本敲定了（但不等於真正實現）。

【其他部門的支持】其他部門的支持程度也會在一定程度上影響產品需求，所以在做提相關需求前（或同時），必須自己把流程試走一次，然後將這個流程中將會涉及的其他部門（通常是財務部）的支撐工作給縷出來，儘早找對應部門商量看看需要怎麼實現。然後以最簡參與流程為標準，輸出產品需求。

例子：

在做一個UGC活動的時候，由於要給用戶發獎，我們希望給用戶發的步驟和體驗可以儘量簡單，而此處涉及財務。

財務提供兩種辦法讓我們發放獎金：

1. 現金髮獎（走活動經費借支流程）；
2. 撥款至用戶帳戶。

第一種方法會涉及大量的運營清點及發獎等人手動作，第二種方法則對用戶還是運營而言都更簡單些，但需要財務開放流程，且財務系統於活動系統相關數據需要打通，而且需要產品研發支持。

我們經歷了從方法1到方法2的過程，這個推動持續了4~5個月，像是一點點地撬動財務想辦法給處更簡便的用戶參與及獲獎體驗。同時對應的產品功能也是一點點地迭代調整。

產品的參與：

有了產品的參與，運營要做的事情可能相對簡單一定，把自己需要的梳理出來，交給產品去畫原型，期間溝通好，確認產品把運營的需求完美展現並優化出來就好。同時，較好的產品經理會幫助運營將活動原型的用戶體驗實現到可執行範圍內的最優，同時也會幫助運營與各個支撐部門溝通以助於實現相關功能。

需要注意的是，產品會有一個內部需求會，通常在資源有限的情況下，內部需求會過後，活動的一些產品功能可能會被砍掉，所以這裡的前提是與產品溝通清楚，活動原型產品功能的輕重緩急。

思想預防針：需求是會被砍的，也可能以打了折扣的形式展現的，持續推動不斷優化就好。能說清楚需求的輕重緩急和收益，是讓需求更快實現的前提。

1.1.2 輸出產品原型中需要填充的文案

上面說到產品的參與會給運營省去很多麻煩和工作，他們會畫產品原型，展現活動的架構及交互需求，但其他的頁面文案，就需要由運營提供。

大致的流程是：落實產品需求——運營提供文案（標題、規則、按鈕文案、交互文案等等）——設計（頁面設計）及技術（運營後臺製作）製作。

文案有哪些：文案真的有很多。

• 頁面文案（主副標題、活動流程、活動規則、獎勵標準、按鈕文案等等）
• 觸達消息文案（大致是指，用戶報名後收到的簡訊、用戶獲獎收到的簡訊等等基於用戶某個動作後產生的站外提示性內容）
• 交互文案等等（大概如：用戶任何做任何預想中的交互動作後給出的彈窗提醒或下一步動作引導，比如提交成功了，可能會說「恭喜您提交成功」、「將於XX個工作日內反饋」、「添加XX微信了解進度」等等。）
• 產品文案（譬如：在後臺頁面上，需要記錄的信息表頭，或者信息狀態判別項等等此類產品文案）
• 其他……

另外，有一些文案是要交給設計放到圖片裡面的，有一些文案是給研發部門做適配的。做適配的文案例如：一個滾動文案說，「XX用戶贏取了XX元」這種類型。文案到底是直接顯示在頁面裡，還是做適配，就看運營需求了。

例子：下圖的所有文字都是需要運營提供的文案，而產品提供的，只是其中結構排版。

1.1.3 活動產品設計及研發的跟進及溝通

活動產品線方面，通常有產品經理跟進的話會省心很多，但不是說運營就放著不用管。因為運營是活動的需求方，因而對於活動的設計、開發需求，會比產品清晰很多。

設計跟進方面：如果希望活動省心省力進行，提交活動設計需求時，除了產品那邊提供產品原型，運營方面最好能找到期待的風格素材作為設計參考。

與設計溝通的理想流程應當是：

• 運營與設計確認設計公司設計風格規範；
• 運營到相關網站尋找若干個符合活動風格，且符合公司設計規範的設計樣板供給設計參考；
• 設計做好大致風格樣式後及時與運營溝通；
• 確認風格及元素ok後完成設計。

而現在很多無經驗者走的流程是：

• 運營提需求後，設計根據產品原型及活動主題，給活動設計活動頁；
• 設計完成基本頁面設計，與運營溝通；
• 若運營認為設計的風格與想像中有較大差異，則需要再次溝通調整風格；
• 設計修改，持續溝通；
• 由於時間關係設計無法做大規模調整，初步定稿。

雖然也有很幸運地設計就設計出運營想要的頁面的情況，但這種情況太考究設計和運營間的默契。所以為了減少來回溝通，給設計需求時最好是同時給出風格參考。
（做這個UGC活動時，運營就曾跟設計就頭圖的展現開了一個下午的會議來商討，而那個下午，運營才了解設計對公司的活動圖的設計風格及元素要求具體且嚴格到什麼程度。)

開發方面：運營與開發方面通常要溝通的問題基本是確認某一個功能的實現，而這裡的複雜程度就和產品的後臺數據相關。
我經常遇到的情況是，開發問：你這裡是要實現XXX功能嗎？是的話，把其設計的所有數據定義情況給我。

例子：

曾經為了達到某個運營目的，提出了讀取該訂單的完成信息，以便運營判斷該訂單是否有資格參與活動的概念性需求。而這個需求到達開發處，應當翻譯為：讀取後臺訂單狀態中，其中A、B、C定義為訂單已完成，D、E、F定義為訂單未完成，G、H 定義為未知。讀取後在活動後臺展示」已完成/未完成/未知「。

可能很多功能提需求的時候運營和產品都未意識到其中數據的複雜性，當研發真正落實的時候，就會發現這個問題，並需要運營進一步落實。

1.1.4 活動上線前測試

上線前，運營應該在測試環境下，按用戶參與流程及運營邏輯將活動體驗一次。儘管有測試幫忙測bug，但運營可以測出活動流程邏輯是否有bug（與預期不符）。

以上就是產品線相關的工作問題。

在運營過程中會發現，提需求花費的時間不多，但在溝通上花費的時間可能會更多一些。和產品的溝通交流時間是必不可少的，產品越是了解活動需求，越能做出符合運營期望的產品原型。

至於與設計和開發之間的溝通上，運營可以在每次溝通過程中了解設計和開發的思維邏輯，提需求的時候可儘量順著他們的邏輯去走，這樣會減少溝通時間。

1.2 運營線

前期準備越充分，活動上線後的麻煩會越少（自然不能避免有麻煩，畢竟一般人不能窮盡所有麻煩情況。）

可能需要考慮到的：

例子：

用戶對活動的諮詢：以這個UGC活動為例子，由於寫長篇UGC內容有一定難度，需要運營介入引導與鼓勵，所以肯定涉及不少的溝通。且在活動流程上，我們確認了需要添加用戶微信來保證有效溝通，所以跟用戶有必不可少的對話。

通常用戶產生的問題和困難80%都是相似的，對於這類型的問題，我們可以預測其中的FAQ，整理好相應的話術文案，以便活動上線後能更加從容應對。若是遇到操作類或較為理解上較為複雜的，可以通過圖文解釋，增加可讀性。
曾經，我們給到用戶的規則描述，是一大段微信文字，用戶長段文字的解讀顯然不在行，很多問題會問了再問，而將這種複雜文案做成圖文之後，情況就優化了很多。

例子：

關於活動後發放的獎品採購：如果獎品是用戶支線活動（促進主線活動玩的），那就必須和獎品管理的相關部門了解清楚剩餘獎品數量、申請流程等細節。

曾經我們有一個獎品是一個毛絨公仔，當時庫存剩餘20個，同時可能會有4個主要部門的人申請，毛絨公仔從製作到到貨的時間需要2周，如果要申請採購，需要走流程層層上報，整個申請流程走起來，最少需要兩天。

所以如果沒有前期了解好這些信息，貿然答應給用戶一些獎品，最後真正需要兌現的時候容易捉襟見肘。

1.3 推廣線

活動上線了就要推廣才有用戶知曉和參與，不同活動目的需要的推廣資源不同，不同推廣資源的流量不同，需要提供的素材也不同。

一般app有閃頻（一打開app看到的）、有banner（一些輪播橫幅廣告）。閃頻只要一開app就能看到，瀏覽和點擊量都很高。banner還根據頁面和位置的不同有不同的點擊量，那我們做活動的時候，是要banner還是要閃頻，還是都要？

• 看目的（我是否要那麼大的曝光/我是否有能力和預算承接那麼多用戶？）
• 看功能（我的活動需要特定時間向特定城市特定類型用戶曝光，這些資源位/渠道是否能做到？）
• 看排位（這些資源位都有排位嗎？）

1.3.1 梳理可用推廣位

一般推廣位可以分內部外部，一個站內的活動，可能內部推廣位已經足夠了，如果涉及外部推廣位，通常與拉新目的相關。

• 內部可能有：各種自營媒體（微信、微博、抖音、支付寶生活號……）、產品資源位（banner、閃頻、feed流、push等等）、EDM、簡訊；
• 外部推廣位：外部資源合作（其他線上線下廣告位）。

例子：

這個持續在做的UGC活動，在不斷迭代的過程成挖出了不少資源位。

• 已在運營的資源位：閃頻、banner、分級頁面banner。其中尤其是banner和分級頁面banner，在後期已經和對應負責部門預定好了每月的固定位置。
• 新增的資源位：觸發類型（用戶下單後推送活動，用戶完成訂單後推送活動）、固定位置類型（菜單欄中的特定類目、用戶訂單頁面新增按鈕）。

ps：對於新增資源位的挖掘邏輯，就是根據用戶的使用流程和使用邏輯，在合適的地方埋下曝光活動的點。當然這麼做的前提是有產研支持。

1.3.2 根據活動的推廣節奏，與相關部門安排好資源位需求

有些資源位並不能長期被佔領，因此必須根據活動的節奏，安排資源位的上線時間，如：banner、閃頻、彈窗等。

有些資源位可能可以長期發布，但內容需要經常更換，如：微博、抖音等社交媒體，另外郵件、簡訊、push、微信推文也可視為次類型，但頻率需要控制在該部門建議範圍內。

1.3.3 確定資源位需求，向設計、技術等部門發起需求

不同資源位需要的物料不同（圖片、文案等），圖片需要設計協助製作。有些資源位可能需要前端切圖，如：郵件中的有交互效果的「圖片」。

1.3.4 輸出相關資源位需要的相應文案

比如微博：在不同的活動周期（前期、中期、後期），需要用的文案時不一樣的，可以提前想好不同周期的文案結構。

比如推文：不同位置需要的文案也是不一樣的，如單獨一篇推文推活動，或在日常推文下增加一小部分活動介紹，文案都不一樣。

所以推廣的位置和節奏越多越豐富，運營需要輸出的文案就越多。

ps：推廣也是各強溝通強輸出工作，第一次活動對推廣位不熟悉時，儘量安排更多時間跟進。

到了這裡，活動的前期準備基本說完了。

寫在最後

以上僅僅是活動前期要做的東西，接下來還有活動上線後要做什麼，一期活動結束後要做什麼等等內容，敬請關注。

另外需要提醒的是，以上所有描述均基於個人經驗，不同公司不同活動目的和產研支持，都會有不一樣的經驗和問題，所以以上僅供參考，同時也歡迎朋友們來討論～～～

 

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

題圖來自 Pexels，基於 CC0 協議