一個好的活動不僅需要有吸引人的玩法,還需要給予用戶完善的體驗,處理好交互反饋,提升用戶的整體交互感。那么如何才能達成這一目標?也許你可以嘗試建立“用戶交互總線”。具體如何理解和建立,一起來看看作者的分析。
一、前言
【資料圖】
之前說完了玩法之間的解耦、玩法之間的串聯(lián),已經(jīng)基本解決了功能上50%的問題,基本可以完備地搭建一個活動出來,但是離一個好的活動還是有差距的,主要是對于用戶體驗上和活動效果方面上,本篇要講的就是如何從后端角度處理用戶參與活動過程中的交互問題。
系統(tǒng)架構(gòu)設(shè)計或功能抽象時,為了擴展性等原因把系統(tǒng)能力進行了割裂,每個玩法都能獨立存在,可以動態(tài)關(guān)聯(lián),系統(tǒng)架構(gòu)設(shè)計層面是優(yōu)秀的,但這樣搭建出來的活動,沒整體處理交互反饋的話是有傷用戶體驗的,一定程度上來說用戶感受到的還是一個拼圖式的活動,每個玩法處理各自的交互,聯(lián)動性對用戶感知不強烈、玩法和玩法之間的交互可能存在沖突等,整體性不夠強。
我們整個系統(tǒng)產(chǎn)出的活動應(yīng)該是完整的而非割裂的,每次定制處理成本又太高,放棄玩法編排就又退回到了原地,所以為了更好的用戶交互體驗、活動交互邏輯開發(fā)成本的縮減,我們需要一個集中的“總線”來負責用戶的整體交互。
二、解決方案
1. 問題分析
交互總線的職責是:“集中處理用戶交互過程中的事件反饋,負責交互的整體感”。對于事件進行分類,按照來源主要分為:
既定的活動交互規(guī)則(玩法自身、玩法間)、運營操作觸達的兩大類。
按照表現(xiàn)形式可以分為:toast、彈窗、活動內(nèi)通知、私信、push等等;按照時機分又基本可以分為實時觸達(被動接受)、交互時觸發(fā)(主動觸發(fā))。
本質(zhì)上這些動作都屬于活動同用戶間的“互動中的反饋”,我們只需要抓清楚觸動的本質(zhì)就可以啦,然后對于“反饋”出現(xiàn)的場景、形式、時機進行分析,然后歸納抽象就可以了。
2.定位確定
交互總線集中負責了一個活動對于用戶交互過程中的反饋,那它必然是一個“切面”般的存在,所有交互的反饋都由這里發(fā)生,也就是說玩法和業(yè)務(wù)事件總線提供了集成好的功能呈現(xiàn)、交互總線提供了統(tǒng)一的用戶交互反饋,這兩塊圍繞用戶參與的上下文對用戶提供好的用戶體驗。
3. 抽象一下
先確定上下文:我們是在活動領(lǐng)域處理用戶參與時的交互反饋問題,核心的處理的對象是反饋,要解決的問題主要是交互過程中反饋不統(tǒng)一、過多or過少、無法集中管理、維護成本相對較高的問題。
對于運營者來說,反饋是一種活動交互規(guī)則,需要被配置管理、觸發(fā);對于用戶,可以被主動推送,也可以在進入活動的時候主動拉取,然后這些反饋有自己具體的內(nèi)容、具有不同的表現(xiàn)形式、接受用戶,反饋之間存在優(yōu)先級或者互斥邏輯等等,總體來看反饋可以大致抽象為如下情況:
所以只需要落地一個能夠生成&維護反饋、統(tǒng)一處理反饋之間關(guān)系的服務(wù)即可。
4. 運行視圖
先大體看一下整體的運行時視圖,后面詳細說一下如何完成交互反饋之間的統(tǒng)一處理。
首先交互總線的事件來源可以是某個異步事件,比如說任務(wù)完成、助力成功等,還可以是用戶的一次點擊或者界面打開,再或者運營集中發(fā)的觸達召回等。在接收到事件后我們需要創(chuàng)建事件本身交互反饋及事件相關(guān)連的交互反饋,比如說任務(wù)完成會有toast提示,任務(wù)完成后加抽獎機會會有一個刷新動作或者特效。
取到對應(yīng)的反饋之后,灌到現(xiàn)有buffer中,或者直接走后續(xù)的流程,然后對事件按照規(guī)則進行標準化處理,如果存在buffer同當前的其他事件進行合并或者舍棄處理,并同當前的前端交互序列作融合,確定當前buffer的最終序列等待被消費。
最終可被消費的序列可以通過server長鏈接主動push給用戶,或者在用戶發(fā)生交互時帶給用戶。
5. 消費規(guī)則
整個總線的消費規(guī)則的維護是整個實現(xiàn)中最復雜的部分,通常消費隊列的消費方式可以分為拉取和推送兩種,拉取通常的邏輯是取用戶在上次交互和本次交互之間產(chǎn)生的交互的反饋行為,而推送通常為定時&定量的消耗邏輯,并且反饋的消費要支持多維度處理,比如說只消費某個玩法相關(guān)的,只消費本次互動相關(guān)的。
所以反饋有一個很重的業(yè)務(wù)處理特征,這塊實現(xiàn)起來可以非常復雜也可以非常簡單,主要看面臨的業(yè)務(wù)場景,通常來說活動維度稍微包裝一下規(guī)則就可以了,并不會膨脹到非常復雜。
舉個相對常規(guī)的例子大家可以簡單地感受一下:
消費方式
很多簡單的活動是沒有很強烈的反饋訴求的,這時候我們只需要一套簡單的默認時序規(guī)則或者無特殊規(guī)則就可以啦。
這部分的規(guī)則設(shè)計實踐和業(yè)務(wù)場景強相關(guān),我們只要能保證規(guī)則能靈活插拔就足夠了,有想交流的可以單獨細聊。
三、寫在最后
本篇就先暫時寫到這里,中間涉及的很多技術(shù)細節(jié)沒有仔細說,比如DSL的定義、文本的生成方式、存儲到底是redis還是mysql,再或者是SDK提供服務(wù),還是個rpc對外,又或者是buffer的計數(shù)機制、推送機制、性能和數(shù)據(jù)一致性保證等等,可以根據(jù)公司的技術(shù)選型和業(yè)務(wù)場景具體來定,有相關(guān)疑惑的可以單聊。本篇描述的思路其實不僅僅是活動場景可以使用,一些通知系統(tǒng)或者觸達系統(tǒng)等都是這種思路來處理問題。
另外做個預(yù)告,下一篇《搞定營銷活動-活動效果反哺》。
本文由@一個數(shù)據(jù)人的自留地 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
關(guān)鍵詞: 搞定營銷活動用戶交互總線 用戶體驗