閑魚互動(dòng)玩法標(biāo)準(zhǔn)化建設(shè)
2023-01-25|23:20|發(fā)布在分類 / 引流推廣| 閱讀:90
2023-01-25|23:20|發(fā)布在分類 / 引流推廣| 閱讀:90
現(xiàn)在大家對互動(dòng)玩法應(yīng)該已經(jīng)司空見慣,很多APP或多或少都會(huì)在業(yè)務(wù)場景中采用各式各樣的互動(dòng)玩法來吸引用戶,讓用戶在參與互動(dòng)的同時(shí),得到平臺(tái)權(quán)益,進(jìn)而提升平臺(tái)心智,達(dá)到促活拉新目的。隨著閑魚規(guī)模變大,平臺(tái)權(quán)益擴(kuò)展,基于任務(wù)+抽獎(jiǎng)的互動(dòng)玩法在日常以及大型營銷活動(dòng)中應(yīng)用越來越多。
痛點(diǎn)分析
對于活動(dòng)中的互動(dòng)玩法,從設(shè)計(jì)到研發(fā)再到驗(yàn)收上線的流程大致如上,在具體實(shí)踐過程中,我們經(jīng)常會(huì)遇到以下問題:
技術(shù)方案
針對上面的痛點(diǎn),對問題進(jìn)行抽象,我們期望建設(shè)互動(dòng)玩法標(biāo)準(zhǔn)化,當(dāng)前階段關(guān)鍵解法主要是以下三點(diǎn):
大多數(shù)情況下,抽獎(jiǎng)活動(dòng)中都會(huì)有任務(wù)玩法,用戶需要通過完成任務(wù)來增加抽獎(jiǎng)次數(shù)。閑魚的任務(wù)體系是使用淘系任務(wù)中心進(jìn)行搭建的。任務(wù)與抽獎(jiǎng)的鏈路如下圖所示。
閑魚的互動(dòng)任務(wù)有以下幾種類型:
關(guān)于任務(wù)上報(bào),目前閑魚主要有兩種方案:前端上報(bào)、事件采集上報(bào)。
下面以兩個(gè)典型的任務(wù)來介紹任務(wù)上報(bào)鏈路,分別是會(huì)場瀏覽任務(wù)和關(guān)注閑魚號(hào)任務(wù),前者是前端進(jìn)行任務(wù)上報(bào),后者是事件采集進(jìn)行上報(bào)。
在互動(dòng)任務(wù)標(biāo)準(zhǔn)化建設(shè)過程中,前端在淘系任務(wù)中心的列表組件基礎(chǔ)上,進(jìn)行二次封裝,簡化組件配置,并且加一些閑魚的定制能力,最終形成閑魚通用的任務(wù)列表組件。
前端在實(shí)現(xiàn)抽獎(jiǎng)標(biāo)準(zhǔn)化中,主要是抽象抽獎(jiǎng)能力,將抽獎(jiǎng)通用邏輯封裝成SDK,提高業(yè)務(wù)開發(fā)效率。
const oliverSdk = new Oliver({/*** 抽獎(jiǎng)活動(dòng)Id */activityId: '544',/** * 其他選項(xiàng)*/options: {/*** 活動(dòng)參數(shù)*/oliverParams: {/*** 是否需要權(quán)益的詳情,默認(rèn)false*/needBenefits: false,/*** 否需要權(quán)益詳情,只有抽取的情況下才生效,默認(rèn)false*/needDetails: false,/*** 否需要是否已經(jīng)中獎(jiǎng)過的信息,只有 needDetails 為true時(shí)候生效 非必須不要使用性能及其差,默認(rèn)false*/needHadWin: false,/*** 擴(kuò)展參數(shù),用于服務(wù)端能力擴(kuò)展*/extend: {}},/*** 是否需要頁面聚焦后自動(dòng)刷新活動(dòng)數(shù)據(jù),默認(rèn)true*/autoUpdate: true,/*** 是否需要判斷登錄態(tài),默認(rèn)true*/checkLogin: true},/*** 活動(dòng)數(shù)據(jù)返回回調(diào)*/dataWatcher: (data) =>{}});
為了降低業(yè)務(wù)上層開發(fā)同學(xué)對SDK的使用成本,考慮提供基于集團(tuán)Rax方案的Hook能力。
業(yè)務(wù)層開發(fā)只需在調(diào)用方法時(shí),依據(jù)數(shù)據(jù)變化來進(jìn)行交互展示。這樣既減少了上層代碼量,同時(shí)降低開發(fā)成本。下面是Hook的使用代碼示例:
// 使用hookconst{ oliverData, drawResultData, draw } = useOliver({activityId: '544'});
// 監(jiān)聽活動(dòng)數(shù)據(jù)useEffect(()=>{const availableTimes = oliverData?.availableTimes || 0;// do some things}, [oliverData]);
// 監(jiān)聽抽獎(jiǎng)結(jié)果useEffect(()=>{// do some things}, [drawResultData]);
// 抽獎(jiǎng)draw();
以往在抽獎(jiǎng)活動(dòng)測試驗(yàn)收過程中,服務(wù)端返回的異常code對于運(yùn)營和測試同學(xué)來說非常不友好,沒有直接展示異常原因,每次都需要技術(shù)同學(xué)介入來排查問題。為了快速定位問題解決問題,我們考慮提供問題調(diào)試能力,讓運(yùn)營和測試同學(xué)可以自助排查問題。
抽獎(jiǎng)SDK中有一個(gè)日志存儲(chǔ)功能,在測試環(huán)境中將用戶操作記錄和服務(wù)端返回的數(shù)據(jù)存儲(chǔ)在本地,另外提供一個(gè)日志列表頁面,在頁面中對日志進(jìn)行解析,提供異常code的具體原因并提供解決方法,展示給運(yùn)營和測試同學(xué)。自助排查功能使用流程如下圖所示。
互動(dòng)玩法配置鏈路復(fù)雜,為了降低配置成本,減少配置錯(cuò)誤,我們提出配置標(biāo)準(zhǔn)化方案。標(biāo)準(zhǔn)化配置主要解決以下三個(gè)問題:
目前建設(shè)的抽獎(jiǎng)標(biāo)準(zhǔn)化配置流程如下:
效果
總結(jié)
互動(dòng)玩法已然成為一種常用的運(yùn)營手段,在玩法落地過程中,我們分析痛點(diǎn),不斷探索,以技術(shù)手段降低互動(dòng)玩法上線成本,并且取得了顯著效果。
在實(shí)現(xiàn)互動(dòng)玩法標(biāo)準(zhǔn)化后,我們會(huì)繼續(xù)抽象基礎(chǔ)互動(dòng)玩法,搭建一個(gè)玩法模塊化的互動(dòng)玩法平臺(tái),抽象基礎(chǔ)玩法,如抽獎(jiǎng)、簽到、抽簽、投票等。在互動(dòng)玩法平臺(tái)上,運(yùn)營同學(xué)可以自助配置玩法,無需開發(fā)和測試同學(xué)高成本投入,活動(dòng)上線效率與質(zhì)量也可以得到有效保障。
這個(gè)問題還有疑問的話,可以加幕.思.城火星老師免費(fèi)咨詢,微.信號(hào)是為: msc496。
推薦閱讀:
《淘寶規(guī)則 - 違背承諾》及其實(shí)施細(xì)則生效通知
天貓dsr動(dòng)態(tài)評分如何查看?天貓dsr動(dòng)態(tài)評分是如何計(jì)算的?
更多資訊請關(guān)注幕 思 城。
微信掃碼回復(fù)「666」
別默默看了 登錄\ 注冊 一起參與討論!