一個好的活動不僅需要有吸引人的玩法，還需要給予用戶完善的體驗，處理好交互反饋，提升用戶的整體交互感。那麼如何才能達成這一目标？也許你可以嘗試建立“用戶交互總線”。具體如何理解和建立，一起來看看作者的分析。

一、前言

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

系統架構設計或功能抽象時，為了擴展性等原因把系統能力進行了割裂，每個玩法都能獨立存在，可以動态關聯，系統架構設計層面是優秀的，但這樣搭建出來的活動，沒整體處理交互反饋的話是有傷用戶體驗的，一定程度上來說用戶感受到的還是一個拼圖式的活動，每個玩法處理各自的交互，聯動性對用戶感知不強烈、玩法和玩法之間的交互可能存在沖突等，整體性不夠強。

我們整個系統産出的活動應該是完整的而非割裂的，每次定制處理成本又太高，放棄玩法編排就又退回到了原地，所以為了更好的用戶交互體驗、活動交互邏輯開發成本的縮減，我們需要一個集中的“總線”來負責用戶的整體交互。

二、解決方案

1. 問題分析

交互總線的職責是：“集中處理用戶交互過程中的事件反饋，負責交互的整體感”。對于事件進行分類，按照來源主要分為：

既定的活動交互規則（玩法自身、玩法間）、運營操作觸達的兩大類。

1. 按照表現形式可以分為：toast、彈窗、活動内通知、私信、push等等；
2. 按照時機分又基本可以分為實時觸達（被動接受）、交互時觸發（主動觸發）。

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

2.定位确定

交互總線集中負責了一個活動對于用戶交互過程中的反饋，那它必然是一個“切面”般的存在，所有交互的反饋都由這裡發生，也就是說玩法和業務事件總線提供了集成好的功能呈現、交互總線提供了統一的用戶交互反饋，這兩塊圍繞用戶參與的上下文對用戶提供好的用戶體驗。

3. 抽象一下

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

對于運營者來說，反饋是一種活動交互規則，需要被配置管理、觸發；對于用戶，可以被主動推送，也可以在進入活動的時候主動拉取，然後這些反饋有自己具體的内容、具有不同的表現形式、接受用戶，反饋之間存在優先級或者互斥邏輯等等，總體來看反饋可以大緻抽象為如下情況：

所以隻需要落地一個能夠生成&維護反饋、統一處理反饋之間關系的服務即可。

4. 運行視圖

先大體看一下整體的運行時視圖，後面詳細說一下如何完成交互反饋之間的統一處理。

首先交互總線的事件來源可以是某個異步事件，比如說任務完成、助力成功等，還可以是用戶的一次點擊或者界面打開，再或者運營集中發的觸達召回等。在接收到事件後我們需要創建事件本身交互反饋及事件相關連的交互反饋，比如說任務完成會有toast提示，任務完成後加抽獎機會會有一個刷新動作或者特效。

取到對應的反饋之後，灌到現有buffer中，或者直接走後續的流程，然後對事件按照規則進行标準化處理，如果存在buffer同當前的其他事件進行合并或者舍棄處理，并同當前的前端交互序列作融合，确定當前buffer的最終序列等待被消費。

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

5. 消費規則

整個總線的消費規則的維護是整個實現中最複雜的部分，通常消費隊列的消費方式可以分為拉取和推送兩種，拉取通常的邏輯是取用戶在上次交互和本次交互之間産生的交互的反饋行為，而推送通常為定時&定量的消耗邏輯，并且反饋的消費要支持多維度處理，比如說隻消費某個玩法相關的，隻消費本次互動相關的。

所以反饋有一個很重的業務處理特征，這塊實現起來可以非常複雜也可以非常簡單，主要看面臨的業務場景，通常來說活動維度稍微包裝一下規則就可以了，并不會膨脹到非常複雜。

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

• 消費方式<拉取、推送<定時、定量>、拉取&推送<定時、定量>；
• 特征集合<合并特征、優先級、舍棄标示、反饋标簽>。

很多簡單的活動是沒有很強烈的反饋訴求的，這時候我們隻需要一套簡單的默認時序規則或者無特殊規則就可以啦。

這部分的規則設計實踐和業務場景強相關，我們隻要能保證規則能靈活插拔就足夠了，有想交流的可以單獨細聊。

三、寫在最後

本篇就先暫時寫到這裡，中間涉及的很多技術細節沒有仔細說，比如DSL的定義、文本的生成方式、存儲到底是redis還是mysql，再或者是SDK提供服務，還是個rpc對外，又或者是buffer的計數機制、推送機制、性能和數據一緻性保證等等，可以根據公司的技術選型和業務場景具體來定，有相關疑惑的可以單聊。本篇描述的思路其實不僅僅是活動場景可以使用，一些通知系統或者觸達系統等都是這種思路來處理問題。

另外做個預告，下一篇《搞定營銷活動-活動效果反哺》。

本文由@一個數據人的自留地 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部