# 產品付費策略設計

> 讓用戶願意為你的產品買單



大家好，我是魚皮。先問大家一個問題，如果你花了大量時間做出一款面向用戶的產品，接下來你會選擇哪種方式來向用戶收取費用呢？

是直接收費，讓用戶一次性購買產品的永久使用權？

還是訂閱制，讓用戶包月包年購買產品的使用權呢？

以上兩種方式，都是在上一篇文章中給大家分享的主流盈利模式。但其實除了這些「打包付費」的產品付費機制外，還有一些更靈活的「按需付費」機制，比如點數機制、套餐制、單次付費等。

在這篇文章中，我會以自己的 AI 產品為例，給大家講解一種關於付費機制的通用化設計 —— **點數機制**。

無論你是用 Vibe Coding 做個人項目，還是想做一款真正的產品，了解點數機制都能幫你設計出更靈活的付費策略。



## 什麼是點數機制？

區別於用戶直接通過購買或者按時間訂閱（比如包月會員）來獲取產品或服務，對於點數機制，用戶購買的是 **虛擬點數** ，然後可以 **根據需要** 使用這些點數來獲取服務。

相信大家對這種付費機制並不陌生吧，我們玩手遊時充值的鑽石、金幣、點券，都是典型的點數機制。

![](https://pic.yupi.icu/1/image-20230719131457025.png)

而且毫不誇張地說，現在絕大多數國產手遊，都會採用這種機制。

為什麼呢？



## 為什麼選擇點數機制？

這裡我會分別從產品和開發兩個角度來介紹點數機制的優勢。



### 產品角度

可以從我們自己的角度出發來思考點數機制的優勢，比如問問自己：我在什麼情況下會選擇充值點數，而不是購買會員？



#### 1、更靈活

首當其衝的理由肯定是更加靈活。我可以用點數有選擇地購買遊戲中的多個商品，比如一半買裝備、一半抽獎等，從而用同樣的金額帶來對自己來說最大的收益。

我們的 AI 產品支持用戶直接購買點數，並且提供了多種不同的點數套餐，用戶可以靈活地使用這些點數來進行 AI 對話、AI 繪畫等不同服務。

![](https://pic.yupi.icu/1/image-20230719144924694.png)



#### 2、降低試錯成本

在我還沒有了解清楚一款產品的功能、或者對一款產品「上癮」前，我不會輕易地購買價格更高的會員。但是，有可能會樂意先付一點兒小錢來體驗一下付費功能。

使用點數機制，就為用戶提供了更小的試錯成本。比起直接用高價將用戶拒之門外，先讓用戶體驗到付費功能的價值，他們可能會更樂意繼續付費，從而增加產品的收入。

這種做法還有一個額外的好處：側重於用產品的功能，而不是花里胡哨的營銷手段（百年會員）來吸引人，更有利於產品的口碑。

我們的 AI 產品也參考了很多手遊的套路，最低只需 6 元就可以購買點數。



#### 3、降低心理成本

在我花更高的固定價格去購買產品前，我肯定會考慮很多方面：比如我會用多久？會用到哪些功能？這些功能是否對得起這些價格？

用戶做決策所需的思考越多，購買意願就越不固定。

而使用點數機制，我不用考慮很多，比如就用 1 元充 10 點，購買意願就會更強。

此外，點數機制將價格抽象為虛擬點數，讓用戶能夠更專注於所購買的產品本身，而非金錢上的支出，在消耗點數時也會更自然一些。



#### 4、提升用戶黏性

點數機制能夠提升用戶的黏性和留存率。一旦我購買了點數，就會不自覺地產生「我要把這些點數花完」的心理，就會持續使用這款產品，從而進一步增強對這款產品的依賴。

在我們的 AI 產品中，為了留存用戶、培養使用習慣，支持讓用戶每日免費領取一定點數，這種做法對產品前期尤為重要。

![](https://pic.yupi.icu/1/image-20230719145440147.png)



#### 5、適應多樣化的業務

如果一個系統有很多功能，對用戶來說，肯定不希望自己在某個功能的使用上都存在獨立的限制，比如：

- AI 對話剩餘 10 次
- AI 繪畫剩餘 5 次
- AI 寫書剩餘 0 次

如果用戶只想用 AI 寫書功能，那麼比起買打包的套餐，肯定更希望直接買 AI 寫書次數，產品就需要支持這個購買選擇。

而如果用戶想同時用 AI 繪畫和 AI 寫書功能，那麼肯定更希望買個針對這兩個功能的打包套餐，產品也需要支持這個購買選擇。

隨著功能的增多，需要支持的購買選擇將指數級增長，各種購買選擇的定價也會越來越難統一。

而如果把上述的所有次數都統一為「點數」，那麼對於用戶來說就更好理解，不用關心每個功能還剩幾次、也不用精打細算怎麼買最實惠，可以自由地分配點數。

對於公司來說，不僅可以簡化定價的過程，還能夠通過各功能或各業務的搭配，實現整體銷售額的提升。騰訊的 Q 幣就是典型的例子，任何一個騰訊下的產品，都有可能吸引你去充值它。



### 研發角度

從研發角度來看，我認為點數機制最大的優勢在於 **通用化** 。

而通用化設計帶來的好處又分為：統一概念、簡化開發、提升可擴展性。



#### 1、統一概念

不知道大家是否聽說過 KISS 原則（Keep It Simple, Stupid），保持簡單、越簡單越好。

在系統研發的過程中，出現的概念越少，越有利於系統的設計、開發和維護。

相比起讓產品的各功能分別對應不同的使用次數限制，使用 **點數** 這個統一的通用概念，更便於研發和產品同學的交流和理解。

舉個極端的例子：

- AI 對話功能消耗 1 個「對話幣」
- AI 繪畫功能消耗 2 個「繪畫幣」
- AI 寫書功能消耗 3 個「寫書幣」
- 用戶 A 還剩  2 個「對話幣」、3 個「繪畫幣」、 9 個「寫書幣」
- 用戶 A 還能使用 2 次 AI 對話、1 次 AI 繪畫、3 次 AI 寫書

大家就需要同時關注 3 種功能及其對應的虛擬代幣。

而如果統一為點數的概念，上述信息就很好理解了：

- AI 對話、AI 繪畫、AI 寫書功能分別消耗 1、2、3 點數
- 用戶 A 還剩  14 點數



#### 2、簡化開發

最開始的時候，因為系統的功能還比較少，我們打算每個功能分別限制用戶的可使用次數。比如用戶每天只能使用 10 次 AI 對話、5 次 AI 繪畫。

那麼在編寫代碼時，就要分別在 AI 對話和 AI 繪畫功能中都增加 **特定的** 校驗和統計邏輯，比如：

```java
// AI 對話功能
void doChat() {
  // 獲取並校驗用戶剩餘的 AI 對話次數
  chatLeftNum = user.getChatLeftNum()
  if (chatLeftNum < 1) {
    throw new Exception("AI 對話次數不足")
  }
  // 操作成功，AI 對話次數 - 1
  chatLeftNum--;
  chatLeftNum = chatLeftNum - 1;
}

// AI 繪畫功能
void doDraw() {
  // 獲取並校驗用戶剩餘的 AI 繪畫次數
  drawLeftNum = user.getDrawLeftNum()
  if (drawLeftNum < 1) {
    throw new Exception("AI 繪畫次數不足")
  }
  // 操作成功，AI 繪畫次數 - 1
  drawLeftNum = drawLeftNum - 1;
}
```

此外，數據庫中要存儲更多的信息，比如：

| 用戶 id | AI 對話次數 | AI 繪畫次數 | 其他 |
| ------- | ----------- | ----------- | ---- |
| 1       | 1           | 5           | ...  |
| 2       | 2           | 6           | ...  |

可想而知，隨著系統功能數的增多，相似但不完全相同的校驗邏輯會越來越多，系統會越來越難以維護；而且數據庫也要不斷增加新的列、佔用更多存儲空間。

如果使用點數機制，可以把各種調用次數變量（chatLeftNum 和 drawLeftNum）統一為點數（points），不同的功能消耗的點數不同。

示例代碼如下：

```java
// AI 對話功能
void doChat() {
  // 獲取並校驗用戶剩餘的點數
  points = user.getPoints()
  if (points < 1) {
    throw new Exception("AI 對話次數不足")
  }
  // 操作成功，點數 -1
  points = points - 1;
}

// AI 繪畫功能
void doDraw() {
  // 獲取並校驗用戶剩餘的點數
  points = user.getPoints()
  if (points < 2) {
    throw new Exception("AI 繪畫次數不足")
  }
  // 操作成功，點數 -2
  points = points - 2;
}
```



還可以把點數的校驗和消耗邏輯統一抽象為通用的公共方法，示例代碼如下：

```java
// 檢查剩餘點數
// 參數 type 表示功能 
void checkPoints(type) {
  needPoints = 1;
  if (type === "draw") {
    needPoints = 2;
  }
  points = user.getPoints();
  if (points < needPoints) {
    throw new Exception("剩餘點數不足")
  }
}

// 消耗剩餘點數
// 參數 type 表示功能 
void usePoints(type) {
  needPoints = 1;
  if (type === "draw") {
    needPoints = 2;
  }
  points = user.getPoints();
  // 減少點數
  points = points - needPoints;
}
```



有了這 2 個公共方法後，原本的代碼可以簡化為：

```java
// AI 對話功能
void doChat() {
  checkPoints("chat");
  ...
	usePoints("chat")
}

// AI 繪畫功能
void doDraw() {
	checkPoints("draw");
  ...
	usePoints("draw");
}
```



當然，這還不是最佳實踐，因為代碼中仍然包含了「硬邏輯」 —— 根據 type 來區分消耗的點數。

我們可以編寫一個 json 配置文件，專門存放所有功能對應的點數消耗，示例代碼如下：

```json
[
  {
    "type": "chat",
    "usePoints": 1
  },
  {
    "type": "draw",
    "usePoints": 2
  },
]
```



再編寫一個公共方法，根據功能（type）從該配置文件中取出對應的點數消耗，示例代碼如下：

```java
int getUsePoints(type) {
  list = readJSON("配置文件")
  for (item : list) {
      if (item.type == type) {
          return item.usePoints;
      }
  }
  return 0;
}
```



然後公共的點數校驗和消耗方法，就可以不用再寫 if else 了！

```java 
// 檢查剩餘點數
// 參數 type 表示功能 
void checkPoints(type) {
  needPoints = getUsePoints(type);
  points = user.getPoints();
  if (points < needPoints) {
    throw new Exception("剩餘點數不足")
  }
}

// 消耗剩餘點數
// 參數 type 表示功能 
void usePoints(type) {
  needPoints = getUsePoints(type);
  points = user.getPoints();
  // 減少點數
  points = points - needPoints;
}
```



之後如果我們需要增加新的功能，只需要在 json 配置文件中增加一個元素即可，比如：

```json
{
  "type": "writeBook",
  "usePoints": 2
}
```



而且無論後續系統增加多少新功能，數據庫中始終只需要存儲用戶剩餘的點數，不用反覆增加新的列。極大地簡化了開發！



#### 3、提升可擴展性

一般來說，越通用的邏輯，可擴展性越強。

如果我們不使用點數機制，而是分別給每個功能增加對應的次數限制，如果要在這個功能內部再增加次數消耗的區分，邏輯就會越來越複雜。

舉個例子，AI 繪畫功能還支持額外功能以圖生圖，如果只使用 AI 繪畫，消耗 1 次；如果要額外使用以圖生圖功能，消耗 2 次；那麼如果還有額外的功能，要消耗幾次呢？會不會出現需要消耗 1.5 次的情況呢？如果次數不支持小數，怎麼辦呢？

很有可能系統隨著上述邏輯的增多，慢慢走到一個死胡同，無法繼續擴展新功能。

如果使用點數機制，我們可以把數字的基數放大，比如說 1 次對應 10 個點數，這樣就有利於我們給額外的功能設置額外的點數消耗。比如 AI 繪畫消耗 20 點數，額外使用以圖生圖增加 10 個點數，更有利於系統的擴展。



## 點數機制的應用

因為點數機制的上述優勢，我們的 AI 產品選擇它作為主要的付費制度。

當然，點數機制也是存在缺點的，比如不夠直觀、價值不固定等。而且對於「營銷 > 價值」本身的產品來說，給用戶一定的試錯成本，可能反而不如會員訂閱制的銷售額多。

所以是否要運用點數機制，需要結合實際情況和產品性質來綜合考慮。

像我們的 AI 產品，是同時結合了點數機制、會員制和套餐制三種制度，為用戶提供更全面的選擇。比如用戶可以成為會員每日領取更多點數、享受更多權益；也可以通過套餐優惠獲得更多點數；同時也兼具了點數機制本身帶來的通用性和靈活性。

此外，點數機制本身就是一種 **通用化設計** ，不僅可以作為付費制度，還可以應用到很多不同的場景，比如：

- 電商平台中，消費者可以通過購物積分兌換其他商品。
- 外賣平台中，用戶可以通過點餐積分兌換折扣優惠。
- 教育平台中，學生可以看課程得積分，用於兌換特定獎勵。






## 寫在最後

點數機制是一種靈活且通用的付費策略設計。它不僅能提升用戶體驗，還能簡化系統開發，提高可擴展性。

記住這幾個關鍵點：

1. 點數機制更靈活，降低用戶的試錯成本和心理成本
2. 點數機制能適應多樣化的業務需求
3. 點數機制能統一概念，簡化開發
4. 點數機制要結合實際情況使用，不是萬能的
5. 可以組合點數機制、會員制、套餐制等多種方式

在 Vibe Coding 時代，實現點數機制的代碼可以讓 AI 幫你生成。但是，如何設計出合理的付費策略，讓用戶願意為你的產品買單，仍然需要你認真思考。

加油，設計出讓用戶滿意的付費策略！💪




## 推薦資源

1）魚皮 AI 導航網站：[AI 資源大全、最新 AI 資訊、免費 AI 教程](https://ai.codefather.cn)

2）編程導航學習圈：[學習路線、編程教程、實戰項目、求職寶典、交流答疑](https://www.codefather.cn)

3）程序員面試八股文：[實習/校招/社招高頻考點、企業真題解析](https://www.mianshiya.com)

4）程序員寫簡歷神器：[專業模板、豐富例句、直通面試](https://www.laoyujianli.com)

5）1 對 1 模擬面試：[實習/校招/社招面試拿 Offer 必備](https://ai.mianshiya.com)