<bdo id="ks4iu"><del id="ks4iu"></del></bdo>
  • 
    <pre id="ks4iu"></pre>
  • <bdo id="ks4iu"><del id="ks4iu"></del></bdo>
    <input id="ks4iu"><em id="ks4iu"></em></input>
    
    
  • <center id="ks4iu"><cite id="ks4iu"></cite></center>
  • 首頁 > 空調 >

    搞定營銷活動:用戶交互總線

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

    一、前言

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


    (資料圖片僅供參考)

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

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

    二、解決方案 1. 問題分析

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

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

    按照表現形式可以分為:toast、彈窗、活動內通知、私信、push等等; 按照時機分又基本可以分為實時觸達(被動接受)、交互時觸發(主動觸發)。

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

    2.定位確定

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

    3. 抽象一下

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

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

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

    4. 運行視圖

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

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

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

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

    5. 消費規則

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

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

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

    消費方式、拉取&推送; 特征集合。

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

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

    三、寫在最后

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

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

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

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

    責任編輯:Rex_03

    推薦閱讀
    欧美国产在线一区,免费看成年视频网页,国产亚洲福利精品一区,亚洲一区二区约美女探花
    <bdo id="ks4iu"><del id="ks4iu"></del></bdo>
  • 
    <pre id="ks4iu"></pre>
  • <bdo id="ks4iu"><del id="ks4iu"></del></bdo>
    <input id="ks4iu"><em id="ks4iu"></em></input>
    
    
  • <center id="ks4iu"><cite id="ks4iu"></cite></center>
  • 主站蜘蛛池模板: 无码av免费一区二区三区| 欧美性猛交xxxx黑人| 在线免费观看污污视频| 亚洲欧洲第一页| 色碰人色碰人视频| 日本动态120秒免费| 史上最新中文字幕| 99热精品久久只有精品| 欧美交a欧美精品喷水| 国产六月婷婷爱在线观看| 中文国产成人精品久久app| 男人的天堂影院| 国产精品免费αv视频| 久久婷婷是五月综合色狠狠| 美女胸又大又黄又www的网站 | 热狗福利ap青草视频入口在线观看p引导下载花季传媒 | 嘟嘟嘟www免费高清在线中文 | 国产精品视频九九九| 九九影视理伦片| 美国式禁忌芭芭拉| 国产高清av在线播放| 久久精品一区二区| 精品一区二区三区无码免费视频 | 亚洲日韩中文无码久久| 黑色毛衣在线播放| 欧洲美熟女乱又伦av影片| 国产精品久久精品福利网站| 久久国产小视频| 狠狠色欧美亚洲综合色黑a| 国产精品久久久久无码av| 中文字幕在线观看一区| 波多野结衣在线不卡| 国产成人午夜片在线观看| 一本大道香蕉大无线视频| 欧美人与物videos另| 啊轻点灬大ji巴太粗太长h| 91蜜桃传媒一二三区| 日本人与黑人videos系列| 亚洲精品无码高潮喷水在线| 韩国男男腐啪GV肉视频| 天堂岛最新在线免费看电影 |