在營銷活動中，雖然不同玩法的串聯(lián)可以搭建出一個活動，但是為了更好的用戶體驗，還應(yīng)該注意玩法與玩法之間的交互。需要有一個集中的“總線”來負(fù)責(zé)用戶的整體交互，那應(yīng)該怎么做呢？一起來看一下吧。

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

系統(tǒng)架構(gòu)設(shè)計或功能抽象時，為了擴(kuò)展性等原因把系統(tǒng)能力進(jìn)行了割裂，每個玩法都能獨立存在，可以動態(tài)關(guān)聯(lián)，系統(tǒng)架構(gòu)設(shè)計層面是優(yōu)秀的。

但這樣搭建出來的活動，沒整體處理交互反饋的話是有傷用戶體驗的，一定程度上來說用戶感受到的還是一個拼圖式的活動，每個玩法處理各自的交互，聯(lián)動性對用戶感知不強(qiáng)烈、玩法和玩法之間的交互可能存在沖突等，整體性不夠強(qiáng)。

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

一、解決方案

1. 問題分析

交互總線的職責(zé)是：“集中處理用戶交互過程中的事件反饋，負(fù)責(zé)交互的整體感”。

對于事件進(jìn)行分類，按照來源來看主要分為：

• 既定的活動交互規(guī)則（玩法自身、玩法間）
• 運營操作觸達(dá)

按照表現(xiàn)形式可以分為：toast、彈窗、活動內(nèi)通知、私信、push……

按照時機(jī)分又基本可以分為：

• 實時觸達(dá)（被動接受）
• 交互時觸發(fā)（主動觸發(fā)）

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

2. 定位確定

交互總線集中負(fù)責(zé)了一個活動對于用戶交互過程中的反饋，拿它必然是一個“切面”般的存在，所有交互的反饋都由這里發(fā)生。

也就是說，玩法和業(yè)務(wù)事件總線提供了集成好的功能呈現(xiàn)、交互總線提供了統(tǒng)一的用戶交互反饋，這兩塊圍繞用戶參與的上下文對用戶提供好的用戶體驗。

3. 抽象一下

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

對于運營者來說，反饋是一種活動交互規(guī)則，需要被配置管理、觸發(fā)。

對于用戶，可以被主動推送，也可以在進(jìn)入活動的時候主動拉取，然后這些反饋有自己具體的內(nèi)容，具有不同的表現(xiàn)形式、接受用戶，反饋之間存在優(yōu)先級或者互斥邏輯等等，總體來看反饋可以大致抽象為如下情況：

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

4. 運行視圖

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

首先交互總線的事件來源可以是某個異步事件，比如說任務(wù)完成、助力成功等，還可以是用戶的一次點擊或者界面打開，再或者運營集中發(fā)的觸達(dá)召回等。

在接收到事件后，我們需要創(chuàng)建事件本身交互反饋及事件相關(guān)連的交互反饋，比如說任務(wù)完成會有 toast 提示，任務(wù)完成后加抽獎機(jī)會會有一個刷新動作或者特效。

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

最終可被消費的序列可以通過 server 長鏈接主動 push 給用戶，或者在用戶發(fā)生交互時帶給用戶。

5. 消費規(guī)則

整個總線的消費規(guī)則的維護(hù)是整個實現(xiàn)中最復(fù)雜的部分，通常消費隊列的消費方式可以分為拉取和推送兩種。

拉取通常的邏輯是取用戶在上次交互和本次交互之間產(chǎn)生的交互的反饋行為，而推送通常為定時&定量的消耗邏輯，并且反饋的消費要支持多維度處理。

比如說只消費某個玩法相關(guān)的，只消費本次互動相關(guān)的，所以反饋有一個很重要的業(yè)務(wù)處理特征，這塊實現(xiàn)起來可以非常復(fù)雜也可以非常簡單，主要看面臨的業(yè)務(wù)場景，通常來說活動維度稍微包裝一下規(guī)則就可以了，并不會膨脹到非常復(fù)雜。

舉個相對常規(guī)的例子大家可以簡單的感受一下：

• 消費方式：拉取、推送（定時、定量）、拉取&推送（定時、定量）
• 特征集合：合并特征、優(yōu)先級、舍棄標(biāo)示、反饋標(biāo)簽

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

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

二、 寫在最后

本篇就先暫時寫到這里，中間涉及的很多技術(shù)細(xì)節(jié)沒有仔細(xì)說。

比如 DSL 的定義、文本的生成方式、存儲到底是 redis 還是 mysql ，再或者是 SDK 提供服務(wù)，還是個 rpc 對外，又或者是 buffer 的計數(shù)機(jī)制、推送機(jī)制、性能和數(shù)據(jù)一致性保證等等。

可以根據(jù)公司的技術(shù)選型和業(yè)務(wù)場景具體來定，有相關(guān)疑惑的可以單聊。

本篇描述的思路其實不僅僅是活動場景可以使用，一些通知系統(tǒng)或者觸達(dá)系統(tǒng)等都是這種思路來處理問題。