“盲盒抽獎”創意營銷活動實踐

當Serverless與低代碼這兩個不同的技術***同相交於同壹個業務時會有怎樣的價值展現？本文以“盲盒抽獎”這個ServerlessDevs做過的創意營銷活動為例，為大家講述Serverless和低代碼是如何搭配來滿足壹個業務訴求的。前言線上H5創意動畫結合線下實體獎勵是互聯網營銷活動的壹種常見手段。為了抓住關鍵時間節點，活動從策劃到落地的周期壹般都比較短，短時間內落地線上服務對於做技術開發的同學有著不小的挑戰。尤其是當有更多需求，比如增加後臺管理以及關鍵前端訪問數據埋點等需求時，挑戰難度往往會加倍。對於開發而言除了完成業務核心訴求，往往還需要關註非業務訴求以外的其他狀況，比如系統訪問安全，高並發流量應對，系統運行指標可觀測等。在以前這類需求往往需要跟多的角色參與，如產品，前端，後端，設計，測試，運營，運維等，使得投入產出比變得比較低，活動持續性比較差。今天使用Serverless+低代碼的技術我們可以大幅縮減做此類活動的成本，讓它變成持續性的活動，從而大大提高運營效果。實際上ServerlessDevs此次的盲盒抽獎活動僅僅投了3.5個人，便完成了活動策劃，產品設計,前後端實現，系統部署運維等工作。並且借助於Serverless的服務能力，輕松應對了系統訪問安全，高並發流量，系統可觀測等這些非業務挑戰。功能性的補齊+效率提升，讓本次運營取得了非常好的收益，活動服務的模板化沈澱又為後續同類活動奠定好了良好的基礎。“盲盒抽獎”活動的整體流程如下：需求設計（含業務邏輯和交互邏輯）設計稿低代碼實現前端編碼實現Serverless服務聯調測試部署上線活動中問題修復活動後復盤應用效果預覽：“1分鐘Serverless極速部署盲盒”抽獎活動目前已經結束，但是感興趣的同學仍可以體驗壹下：/adc/series/serverless2架構預覽：本次的部署架構沒有使用阿裏雲API網關，而是直接用函數計算CustomRuntime作為托管形態，這樣做是因為本次需求的特殊性，我們是“自己部署自己抽”，實際上意味著端側訪問是非中心化的，端側訪問的服務做的也比較薄，只是數據處理接口調用和提供靜態渲染服務，後經過壹個中心化的邏輯後臺處理中獎概率，管理獎品查詢數據庫等。如果您是自己做中心化的的活動後臺的話建議參考下面的架構模式，采用API網關作為流量入口。方便做更多的安全限制以及更靈活的擴展實現解析前端交互低代碼實現本次前端實現使用低代碼工作hype4，hype4的具體使用這裏不做詳細介紹，有興趣的同學可以自行搜索。設計稿除了之後將需要的圖切出來，然後跟處理Flash壹樣將動畫效果實現，最後就是添加js代碼實現接口訪問，場景切換等能力。整個流程會比全編碼要快很多，尤其是動效實現上比純手寫效率高2-3倍。數據層Serverless服務如架構所示，這裏的數據層實際上就是我們理解的SSF，這層僅做數據轉發和靜態的渲染。代碼實現比較簡單，采用express框架，然後以函數計算Customruntime形式部署。目的是為了這個服務既可以托管靜態內容也可以做動態的數據轉發。值得註意的是，用戶的信息獲取也是在這層實現的。這裏我們獲取的是阿裏雲用戶的accountId，方便對齊中獎信息發放獎品。對於普通開發者而言這個參數沒有太大意義。我們會提前將搖獎後臺部署完畢，接下來就是，每個用戶自己部署完這層服務後，訪問自己部署好的服務，然後向搖獎後臺傳遞uid等基本信息，發起搖獎。最終返回中獎結果透傳給前端展示。作為管理員則可以通過後臺操作設置獎品和概率等。後臺抽獎邏輯實現後端服務采用PythonWeb框架：Django進行實現，主要方法有：1.獲取用戶的uid信息，並對uid信息進行校驗，以確保：uid信息的準確性該客戶端服務是通過ServerlessDevs開發者工具進行部署；2.當日獎品池的構建；3.用戶中獎信息的初步確定；4.用戶中獎信息的復核；5.返回最終的結果給客戶端；基本流程1.用戶在本地，將盲盒抽獎的客戶端服務，通過ServerlessDevs開發者工具進行部署，部署到用戶自己的賬號下；在部署期間，需要給用戶下發壹個臨時域名（這個臨時域名需要用到用戶的uid），ServerlessDevs在進行臨時域名下發的過程中，會生成部分的客戶端token，並記錄到ServerlessDevs後端服務中；這個token實際上就是鑒定用戶身份的重要標記；(如果用戶在Yaml中聲明了不使用系統自動下發的域名信息，可能就沒辦法順利參加本次活動）。2.用戶部署完成之後，會返回壹個ServerlessDevs下發的臨時域名，供用戶學習和測試使用。3.接下來用戶通過瀏覽器，打開該臨時域名，便可以看到抽獎的相關頁面，用戶可以點擊進行抽獎操作。4.用戶點擊抽獎操作之後，會發起請求，請求用戶賬號下的Serverless服務，該服務會根據用戶的uid信息進行相關的處理，並發起真正的抽獎請求到本次活動的後端Serverless服務上；5.本次活動的後端Serverless服務接收到用戶的抽獎請求時，會：獲取用戶賬號下的Serverless服務發起抽獎請求時所傳遞uid信息；使用獲得到的uid信息在臨時域名下發系統中進行數據匹配，確定用戶本次使用了臨時域名下發系統，並下發了對應的域名；實現抽獎操作；抽獎核心實現在抽獎操作的過程中，也是對當前系統進行了初步的評估，設定了壹個簡單的，易於實現的，可以針對小規模抽獎活動的抽獎功能：關於這壹部分，Django項目的實現方法：@csrf_exemptdefprize(request):uid=request.POST.get("uid",None)ifnotuid:returnJsonResponse({"Error":"Uidisrequired."})temp_url="<獲取uid的合法性和有效性，重要判斷依據>?uid="+str(uid)ifjson.loads(urllib.request.urlopen(temp_url).read().decode("utf-8"))["Response"]=='0':returnJsonResponse({"Error":"Uidisrequired."})token=randomStr(10)#獲取當日獎品prizes={}foreve_prizeinPrizeModel.objects.filter(date=time.strftime("%Y-%m-%d",time.localtime())):prizes[eve_prize.name]={"count":eve_prize.count,"rate":eve_prize.rate}#構建抽獎池prize_list=[]forevePrize,eveInfoinprizes.items():temp_prize_list=[evePrize,]*int((100*eveInfo['rate']))prize_list=prize_list+temp_prize_listnone_list=[None,]*(100-len(prize_list))prize_list=prize_list+none_listpre_prize=random.choice(prize_list)#數據入庫try:UserModel.objects.create(uid=uid,token=token,pre_prize=pre_prize,result=False)except:try:ifnotUserModel.objects.get(uid=uid).result:returnJsonResponse({"Result":"0"})except:passreturnJsonResponse({"Error":"Everyonecanonlyparticipateonce."})ifnotpre_prize:returnJsonResponse({"Result":"0"})user_id=UserModel.objects.get(uid=uid,token=token).idusers_count=UserModel.objects.filter(pre_prize=pre_prize,id__lt=user_id,date=time.strftime("%Y-%m-%d",time.localtime())).count()#是否獲獎的最終判斷ifusers_count>=prizes.get(pre_prize,{}).get("count",0):returnJsonResponse({"Result":"0"})UserModel.objects.filter(uid=uid,token=token).update(result=True)returnJsonResponse({"Result":{"token":token,"prize":pre_prize}})系統安全設定當用戶中獎之後，系統會生成壹個token，該token與uid的組合，是用來判斷用戶是否中獎的重要依據，這裏可能涉及到壹個問題：什麽有了uid，還要增加壹個token來進行組合判斷呢？其實原因很簡單的，提交中獎信息和查詢中獎信息，如果是通過uid來直接進行處理的，那麽很有可能會有用戶通過遍歷等手段，非法獲取到其他用戶提交過的信息，而這壹部分信息很有可能涉及到用戶提交的收貨地址等，所以為了安全，增加了壹個token，在壹定程度上，提升了被暴力遍歷的復雜度。而這壹部分的方法也很簡單：@csrf_exemptdefinformation(request):uid=request.GET.get("uid",None)token=request.GET.get("token",None)ifNonein[uid,token]:returnJsonResponse({"Error":"Uidandtokenarerequired."})userInfor=UserModel.objects.filter(uid=uid,token=token)ifuserInfor.count()==0:returnJsonResponse({"Error":"Noinformationfoundyet."})ifnotuserInfor[0].result:returnJsonResponse({"Error":"Nowinninginformationhasbeenfoundyet."})ifrequest.method=="GET":returnJsonResponse({"Result":{"prize":userInfor[0].pre_prize,"name":userInfor[0].name,"phone":userInfor[0].phone,"address":userInfor[0].address}})elifrequest.method=="POST":name=request.POST.get("name",None)phone=request.POST.get("phone",None)address=request.POST.get("address",None)ifNonein[name,phone,address]:returnJsonResponse({"Error":"Name,phoneandaddressarerequired."})userInfor.update(name=name,phone=phone,address=address)returnJsonResponse({"Result":"Savedsuccessfully."})整個流程是：通過用戶的uid和token進行相關用戶信息的獲取；如果請求方法是GET方法，那麽則直接返回用戶的中獎信息（指的是收貨信息）；如果請求方法是POST方法，則允許用戶進行中獎信息的修改（指的是收貨信息）；其他安全方面的補充：如何保證用戶的token等信息的唯壹性以及不可偽造性，這壹部分在瀏覽器端是不太容易實現的，因為用戶可能換瀏覽器，但是對於用戶的在函數計算平臺的函數服務中就相對容易實現了，所以采用域名下發階段，對指定時間段下發過的域名信息進行記錄，再在後期進行對比，以保證用戶確實通過ServerlessDevs開發者工具進行了項目部署，下發了臨時域名，並在規定的時間內參加了活動；（當然，如果用戶註冊了多個阿裏雲賬號，進行該活動的參加，這個時候是被允許的）如何保證獎品不會被超發，這壹部分在該系統中，采用了壹個比較”笨“的方法，但是也是針對小型平臺更容易實現的方法，即先給用戶壹個獎品標記，然後再根據用戶獎品在數據庫中的時序位置，進行最終中獎信息的判斷，例如，用戶中獎壹個機械鍵盤，在數據庫中是中機械鍵盤的第6位置，但是壹***只有5個機械鍵盤，所以此時會對用戶的中獎信息二次核對並標記未中獎。（當然，這種做法針對小規模活動是可以的，但是針對大型活動是不可取的，因為用戶是否中獎這件事情，會導致多次數據庫的讀寫操作，在壹定程度上是不合理的）用戶中獎之後，提交了獎品郵寄信息，如何保證該信息的安全性，不被其他人暴力遍歷出來也是值得關註的問題，此處采用增加了壹個隨機token，以增加被暴力遍歷出來的復雜度，進壹步保障安全；部署準備工作本次部署無需域名，使用函數計算生成的自定義域名即可，依然需要安裝好ServerlessDevs工具，本次只需開通函數計算即可。操作步驟搖獎後臺的部分模板還在準備中，僅演示部署前端和數據層的服務。步驟1：秘鑰配置參考Serverlessdevs阿裏雲秘鑰配置步驟2：初始化使用serverlessdevs命令行工具執行:sinitblindbox-game進入引導式操作：步驟3：構建部署修改壹下相關的配置信息，執行sdeploy效果查看函數部署情況：頁面效果：搖獎部分的應用模板正在準備中，後續也會統壹在這個應用模板給大家提供展示。結語上面實踐結束後關於低代碼和Serverless這個話題想跟大家再展開壹下，