如何設計一個邀請分成模塊

這一週的開發的邀請分成系統,差很少也完善到了70%的成度,正式上了線,投入了給用戶使用,雖然還有一部分未完善進來,但仍是作一次簡單的覆盤,從技術和用戶體驗上提及。

目標

爲何要作邀請？,還不是爲了拉新、留存這兩兄弟,前者能夠爲咱們的產品引入更多的新用戶,灌入更多的活水,產生更多的優質內容（...目前內容這一塊暫時被砍掉了）,實現更高的business value,後者能夠驅動產品內核增加,改善產品體驗，提升DAU指標,實現正向增加的價值。

同時引入分成機制,就是爲了更好的激勵老用戶,經過我的渠道去拉取更多新用戶進來,利用分成機制來讓本身躺着也能夠賺錢。

如何設計?

基於邀請的設計有不少種方案,邀請H5邀請連接、微信分享小程序註冊、邀請碼機制，以前的兩種方案咱們都嘗試過了,可是轉化效果最終不太理想,最終咱們嘗試了邀請碼機制,此邀請碼非彼邀請碼,咱們採起了淘口令相似的機制,新用戶經過複製老用戶的邀請碼,便可完成自動綁定。整個效果圖以下:

相比以前H5邀請連接更有效的縮短了轉化路徑,新用戶複製邀請碼即可直接與老用戶創建師徒關係。

技術實現

明白了需求流程,開始從技術着手設計.

因爲是邀請口令機制,因此新用戶必定是已經在APP中存在用戶身份了,咱們只須要設計一張表,來創建邀請人與被邀請人的關係,先創建一張Invitations表.

Schema::create('invitations', function (Blueprint $table) {
    $table->bigIncrements('id');
    $table->unsignedInteger('user_id')->index()->comment('邀請人用戶ID');
    $table->unsignedInteger('be_inviter_id')->index()->comment('被邀請人ID');
    $table->timestamp('invited_in')->nullable()->comment('驗證成功後邀請時間');
    $table->timestamps();
});

邀請關係表創建完成後,就須要給每位用戶分配一個邀請碼(惟一標識),能夠生成uuid的方式生成一個惟一的邀請碼,也能夠直接根據用戶的身份ID來推算出一個邀請碼,最簡單的方式就是利用base64來生成一個,編碼和解碼都比較快,並且不佔用實體儲存空間。

public static function encode($id)
{
    return base64_encode($id);
}

public static function decode($code)
{
    return base64_decode($code);
}

邀請碼生成後,便須要提供一個接口給客戶端進行調用解碼驗證的邏輯,整個邏輯就使用僞代碼來實現.

$inviterCode = $request->get('inviter_code);

//驗證邀請碼合法 && 拋出異常提示
$this->invidatedInviterCode($inviterCode);

//解碼
$inviterId = Invitation::decode($inviterCode);

//驗證用戶真實性...

//綁定邀請...

//觸發相應獎勵

這樣,口令邀請系統就實現完了,下面開始來完善分成。

整個分成的處理流程以下:

當用戶觸發各類操做行爲的時候,如瀏覽視頻、打卡、點贊就會經過一個鉤子來觸發分成邏輯,這個觸發就是要在每一個操做被建立後觸發,咱們能夠經過觀察者模式或者監聽器來實現,在Laravel項目咱們使用的是觀察者模式,整個僞代碼邏輯以下。

public function created(Video $video)
{
    $inviter = $user->myInviter;
    if(!is_null($inviter)){
        $inviterWallet = $inviter->wallet;
        //計算視頻收益
        $reward = $this->computeReawrd($video);
        //發放獎勵
        inviterWallet->makeIncome($reward,'視頻瀏覽分成');
    }
}

最後就實現了咱們邀請分成邏輯的編寫,固然面對實際狀況中,還存在更多更復雜的處理流程,可是基本思路以下,包括更多的二三級邀請獎勵業務邏輯也是如此。

用戶體驗

相對以前的h5連接和微信小程序都屬於跳出的方式,在這個過程當中頗有可能沒法進行直接轉化,並且能夠從容應對風險機制,尤爲是微信、QQ的封鎖,連接被封殺概率很大沒法跳轉,而文本內容能夠經過服務端隨時更換,你們只需複製打開APP便可完成綁定,操做性也比網頁上填寫手機號碼要方便不少。

思路延伸

雖然基本的開發工做完成的差很少了,可是還有一些未完善下去,以下:

1. 數據埋點(邀請觸發次數,邀請頁面查看次數、分成次數):數據越細化越能方便後溪總體分析
2. 添加不肯定因素,更誘人的獎勵條件,邀請用戶有概率得到五、十、20元現金紅包.
3. 邀請排行榜,只有看見有人成功吃到了螃蟹,纔會有更多的用戶,嘗試追隨。

在邀請這個功能上,若是限制太多，就會下降用戶參與積極性,若是限制過少，則容易產生漏洞,在這中間仍是得去產生一個平衡,至於把控到什麼程度,還須要往後進一步的繼續探知。