一個(gè)好的活動(dòng)不僅需要有吸引人的玩法，還需要給予用戶完善的體驗(yàn)，處理好交互反饋，提升用戶的整體交互感。那么如何才能達(dá)成這一目標(biāo)？也許你可以嘗試建立“用戶交互總線”。具體如何理解和建立，一起來(lái)看看作者的分析。

一、前言

之前說(shuō)完了玩法之間的解耦、玩法之間的串聯(lián)，已經(jīng)基本解決了功能上50%的問(wèn)題，基本可以完備地搭建一個(gè)活動(dòng)出來(lái)，但是離一個(gè)好的活動(dòng)還是有差距的，主要是對(duì)于用戶體驗(yàn)上和活動(dòng)效果方面上，本篇要講的就是如何從后端角度處理用戶參與活動(dòng)過(guò)程中的交互問(wèn)題。

系統(tǒng)架構(gòu)設(shè)計(jì)或功能抽象時(shí)，為了擴(kuò)展性等原因把系統(tǒng)能力進(jìn)行了割裂，每個(gè)玩法都能獨(dú)立存在，可以動(dòng)態(tài)關(guān)聯(lián)，系統(tǒng)架構(gòu)設(shè)計(jì)層面是優(yōu)秀的，但這樣搭建出來(lái)的活動(dòng)，沒(méi)整體處理交互反饋的話是有傷用戶體驗(yàn)的，一定程度上來(lái)說(shuō)用戶感受到的還是一個(gè)拼圖式的活動(dòng)，每個(gè)玩法處理各自的交互，聯(lián)動(dòng)性對(duì)用戶感知不強(qiáng)烈、玩法和玩法之間的交互可能存在沖突等，整體性不夠強(qiáng)。

我們整個(gè)系統(tǒng)產(chǎn)出的活動(dòng)應(yīng)該是完整的而非割裂的，每次定制處理成本又太高，放棄玩法編排就又退回到了原地，所以為了更好的用戶交互體驗(yàn)、活動(dòng)交互邏輯開(kāi)發(fā)成本的縮減，我們需要一個(gè)集中的“總線”來(lái)負(fù)責(zé)用戶的整體交互。

二、解決方案

1. 問(wèn)題分析

交互總線的職責(zé)是：“集中處理用戶交互過(guò)程中的事件反饋，負(fù)責(zé)交互的整體感”。對(duì)于事件進(jìn)行分類(lèi)，按照來(lái)源主要分為：

既定的活動(dòng)交互規(guī)則（玩法自身、玩法間）、運(yùn)營(yíng)操作觸達(dá)的兩大類(lèi)。

1. 按照表現(xiàn)形式可以分為：toast、彈窗、活動(dòng)內(nèi)通知、私信、push等等；
2. 按照時(shí)機(jī)分又基本可以分為實(shí)時(shí)觸達(dá)（被動(dòng)接受）、交互時(shí)觸發(fā)（主動(dòng)觸發(fā)）。

本質(zhì)上這些動(dòng)作都屬于活動(dòng)同用戶間的“互動(dòng)中的反饋”，我們只需要抓清楚觸動(dòng)的本質(zhì)就可以啦，然后對(duì)于“反饋”出現(xiàn)的場(chǎng)景、形式、時(shí)機(jī)進(jìn)行分析，然后歸納抽象就可以了。

2.定位確定

交互總線集中負(fù)責(zé)了一個(gè)活動(dòng)對(duì)于用戶交互過(guò)程中的反饋，那它必然是一個(gè)“切面”般的存在，所有交互的反饋都由這里發(fā)生，也就是說(shuō)玩法和業(yè)務(wù)事件總線提供了集成好的功能呈現(xiàn)、交互總線提供了統(tǒng)一的用戶交互反饋，這兩塊圍繞用戶參與的上下文對(duì)用戶提供好的用戶體驗(yàn)。

3. 抽象一下

先確定上下文：我們是在活動(dòng)領(lǐng)域處理用戶參與時(shí)的交互反饋問(wèn)題，核心的處理的對(duì)象是反饋，要解決的問(wèn)題主要是交互過(guò)程中反饋不統(tǒng)一、過(guò)多or過(guò)少、無(wú)法集中管理、維護(hù)成本相對(duì)較高的問(wèn)題。

對(duì)于運(yùn)營(yíng)者來(lái)說(shuō)，反饋是一種活動(dòng)交互規(guī)則，需要被配置管理、觸發(fā)；對(duì)于用戶，可以被主動(dòng)推送，也可以在進(jìn)入活動(dòng)的時(shí)候主動(dòng)拉取，然后這些反饋有自己具體的內(nèi)容、具有不同的表現(xiàn)形式、接受用戶，反饋之間存在優(yōu)先級(jí)或者互斥邏輯等等，總體來(lái)看反饋可以大致抽象為如下情況：

所以只需要落地一個(gè)能夠生成&維護(hù)反饋、統(tǒng)一處理反饋之間關(guān)系的服務(wù)即可。

4. 運(yùn)行視圖

先大體看一下整體的運(yùn)行時(shí)視圖，后面詳細(xì)說(shuō)一下如何完成交互反饋之間的統(tǒng)一處理。

首先交互總線的事件來(lái)源可以是某個(gè)異步事件，比如說(shuō)任務(wù)完成、助力成功等，還可以是用戶的一次點(diǎn)擊或者界面打開(kāi)，再或者運(yùn)營(yíng)集中發(fā)的觸達(dá)召回等。在接收到事件后我們需要?jiǎng)?chuàng)建事件本身交互反饋及事件相關(guān)連的交互反饋，比如說(shuō)任務(wù)完成會(huì)有toast提示，任務(wù)完成后加抽獎(jiǎng)機(jī)會(huì)會(huì)有一個(gè)刷新動(dòng)作或者特效。

取到對(duì)應(yīng)的反饋之后，灌到現(xiàn)有buffer中，或者直接走后續(xù)的流程，然后對(duì)事件按照規(guī)則進(jìn)行標(biāo)準(zhǔn)化處理，如果存在buffer同當(dāng)前的其他事件進(jìn)行合并或者舍棄處理，并同當(dāng)前的前端交互序列作融合，確定當(dāng)前buffer的最終序列等待被消費(fèi)。

最終可被消費(fèi)的序列可以通過(guò)server長(zhǎng)鏈接主動(dòng)push給用戶，或者在用戶發(fā)生交互時(shí)帶給用戶。

5. 消費(fèi)規(guī)則

整個(gè)總線的消費(fèi)規(guī)則的維護(hù)是整個(gè)實(shí)現(xiàn)中最復(fù)雜的部分，通常消費(fèi)隊(duì)列的消費(fèi)方式可以分為拉取和推送兩種，拉取通常的邏輯是取用戶在上次交互和本次交互之間產(chǎn)生的交互的反饋行為，而推送通常為定時(shí)&定量的消耗邏輯，并且反饋的消費(fèi)要支持多維度處理，比如說(shuō)只消費(fèi)某個(gè)玩法相關(guān)的，只消費(fèi)本次互動(dòng)相關(guān)的。

所以反饋有一個(gè)很重的業(yè)務(wù)處理特征，這塊實(shí)現(xiàn)起來(lái)可以非常復(fù)雜也可以非常簡(jiǎn)單，主要看面臨的業(yè)務(wù)場(chǎng)景，通常來(lái)說(shuō)活動(dòng)維度稍微包裝一下規(guī)則就可以了，并不會(huì)膨脹到非常復(fù)雜。

舉個(gè)相對(duì)常規(guī)的例子大家可以簡(jiǎn)單地感受一下：

• 消費(fèi)方式<拉取、推送<定時(shí)、定量>、拉取&推送<定時(shí)、定量>；
• 特征集合<合并特征、優(yōu)先級(jí)、舍棄標(biāo)示、反饋標(biāo)簽>。

很多簡(jiǎn)單的活動(dòng)是沒(méi)有很強(qiáng)烈的反饋訴求的，這時(shí)候我們只需要一套簡(jiǎn)單的默認(rèn)時(shí)序規(guī)則或者無(wú)特殊規(guī)則就可以啦。

這部分的規(guī)則設(shè)計(jì)實(shí)踐和業(yè)務(wù)場(chǎng)景強(qiáng)相關(guān)，我們只要能保證規(guī)則能靈活插拔就足夠了，有想交流的可以單獨(dú)細(xì)聊。

三、寫(xiě)在最后

本篇就先暫時(shí)寫(xiě)到這里，中間涉及的很多技術(shù)細(xì)節(jié)沒(méi)有仔細(xì)說(shuō)，比如DSL的定義、文本的生成方式、存儲(chǔ)到底是redis還是mysql，再或者是SDK提供服務(wù)，還是個(gè)rpc對(duì)外，又或者是buffer的計(jì)數(shù)機(jī)制、推送機(jī)制、性能和數(shù)據(jù)一致性保證等等，可以根據(jù)公司的技術(shù)選型和業(yè)務(wù)場(chǎng)景具體來(lái)定，有相關(guān)疑惑的可以單聊。本篇描述的思路其實(shí)不僅僅是活動(dòng)場(chǎng)景可以使用，一些通知系統(tǒng)或者觸達(dá)系統(tǒng)等都是這種思路來(lái)處理問(wèn)題。

另外做個(gè)預(yù)告，下一篇《搞定營(yíng)銷(xiāo)活動(dòng)-活動(dòng)效果反哺》。