從事互聯網行業半年多，對于后端產品逐漸有了一些自己的理解。后端產品，更多的是幫助運營和業務開發工具，從而提高其工作效率，或者是幫助前端功能的實現提供支持。本文就線下掃碼返現工具為例，分享后端產品經理的項目經驗。

• 項目背景：線上流量增速緩慢，為了拓寬獲客渠道，開發線下掃碼買單的工具?？腿司€下掃碼買單，電商平臺可以返現給相應的推薦者。
• 產品定位：線下掃碼購物的工具
• 用戶畫像：門店線下散客，非來自線上渠道的用戶

一、商業邏輯

1. 推薦人向門店的客人展示二維碼，邀請顧客在線上買單
2. 顧客線上買單
3. 根據顧客的消費額度 一定比例的返現給推薦人
4. 推薦人得到物質激勵 觸發下一次推薦行為
5. 平臺獲得更多的線下訂單

小結：線下掃碼返現的商業邏輯較為簡單即平臺讓利給推薦者，驅動推薦者為平臺拉取線下的用戶

二、功能實現

線下掃碼返現工具功能的實現主要分為三個：二維碼的生成、APP頁面的參數傳遞、返現功能的實現。

1. 二維碼的生成

二維碼的生成，從前端看用戶只有兩個動作，輸入手機號，生成二維碼。但是后端卻相對復雜的多，具體流程如下：

1. 錄入手機號
2. 手機號正則校驗，如果校驗成功，進入下一步；如果校驗失敗，提示用戶重新輸入正確手機號
3. 根據正確的手機號調用相關接口，返回對應的用戶賬戶
4. 賬戶校驗，如果接口返回賬戶，進入下一步；如果接口沒有返回賬戶，提示用戶無對應賬號
5. 新建數據表，將對應的用戶賬戶寫進該數據表里（白名單）
6. 將用戶賬號添加到APP的頁面鏈接的URL中（記用戶賬戶的參數為recommenderid）
7. 根據頁面的鏈接，生成對應的二維碼

小結：在前端生成二維碼的過程中，后端做了很多用戶看不出來的操作，包括數據的校驗、接口的調用、數據表的生成、APP相關參數的拼接等。這些操作對于整個項目閉環的實現都很重要，缺少任何一步都會影響整個功能的實現。

2. APP頁面參數的傳遞

1. APP產品首頁的URL中帶入參數recommenderid
2. APP產品sku詳情頁帶入參數recommenderid
3. 訂單填寫頁帶入參數recommanderid
4. 訂單生成的時候 訂單表增加參數recomanderid

小結：APP各級頁面參數的傳遞，是為了在訂單生成的時候可以記錄到推薦人的賬戶信息，從而在之后的返現環節可以成功的把返現的錢打到推薦人的賬戶上。

3. 返現功能的實現

以上，我們完成了二維碼的生成和APP頁面參數的傳遞，接下來就要講講整個掃碼返現閉環中最重要的返現功能的實現過程了。如下圖所示，返現主要有以下8個步驟，簡單的流程示意圖如下所示。

1. 每隔N小時輪詢N小時內已支付的訂單

2. 判斷該訂單表里的字段recommenderid是否空，如果非空，說明該訂單可能源自掃碼訂單，進行下一步；如果字段recommenderid為空，則說明該訂單來源不是掃碼訂單，返現流程結束。

3. 判斷訂單號對應的返現關聯表里面的返現狀態，如果返現關聯表里面的返現狀態是已返現，說明該訂單已經返現，結束返現流程；如果返現關聯表里面的返現狀態是未返現，則執行下一步。

4. 判斷recommenderid是否在白名單里（白名單在二維碼生成環節生成，因為APP鏈接首頁二維碼的生成是通過URL拼接參數的方式實現，所以有可能別的入口也會帶入相同的參數，因此需要用返現白名單做一個二次校驗，以確保recommenderid是我們自己創建的）。如果存在，則進行下一步；如果不存在，則結束返現流程。

5. 判斷recommenderid是否在黑名單里（黑名單的作用是刪除某些刷單的推薦者，此處的刷單是指在掃碼的渠道下單的用戶，支付成功返現后又取消訂單的行為），如果存在，結束返現流程；如果不存在，進入下一步。

6. 根據相關的業務規則，配置返現金額

7. 調用返現接口，傳入主要參數訂單號、recommenderid、返現金額等

8. 根據接口返回的結果，修改返現關聯表的返現狀態。如果返現成功，則更改返現關聯表中的返現狀態為返現成功；如果返現失敗，則更改返現關聯表中的返現狀態為返現失敗。

總結

從前端看，一個生成二維碼的頁面，輸入手機號，點擊生成二維碼，用戶掃碼下單、支付成功就結束了，但是后端卻做了很多事情。

在一個完整的返現流程中，包括二維碼的生成、參數的落地、返現功能的實現三個大的步驟。

在整個流程中，做了多次校驗和判斷和接口的調用。每一個校驗、判斷、接口調用，都會影響整體返現閉環的功能實現。前端一個小小的功能，都需要后端一個完整的閉環流程的支撐。最后，本文從實戰的角度介紹了具體的后端項目經歷，希望能夠和大家一起學習進步。

本文由 @我是范甘迪 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協議