安裝 使用 RevenueCat 管理付費牆和支付網關 第一次嘗試時可能會覺得有點複雜，尤其是如果您之前使用的是像 Superwall 這樣的「即插即用」解決方案。但如果您想要為擴展業務、準確衡量收入以及精細控制訂閱事件打下堅實的基礎，那麼花時間了解 RevenueCat 如何融入您的應用程式架構是值得的。
本文旨在幫助您了解如何使用 RevenueCat。 建立簡單的付費牆，管理訂閱牆，並將所有這些都與您的分析和行銷聯繫起來。 （例如，使用 Pushwoosh），充分利用其作為支付資料「單一資料來源」的角色。我們將探討實際案例、店鋪評論的常見問題、如何建立付費牆以及如何充分利用平台的所有活動。
為什麼 RevenueCat 是您訂閱服務體系的核心？
許多公司最終都選擇了安置 RevenueCat 是其訂閱基礎設施的核心主要原因在於它提供了一個集中式平台，所有支付和續訂資料都集中儲存於此，無論資料來自 iOS、Android 還是網頁。這解決了最常見的難題之一：不同應用商店、後端和分析工具中的數據各不相同。
使用 RevenueCat，您可以獲得 一個關於訂閱和帳單的可靠資訊來源之後，您可以透過原生整合或 Webhook 將這些資料分發到您技術堆疊中的其他工具（分析、CRM、行銷自動化、推播通知等）。當您想要細分使用者、進行追加銷售活動或真正了解訂閱者的行為時，這種一致性至關重要。
實際上，這意味著您的產品和行銷決策都基於以下幾點： 一致且統一的訂閱活動首次購買、續約、取消、付款問題、產品變更等等，所有這些都可以透過 Pushwoosh 等解決方案連接起來，建立高度精細化的自動化客戶旅程。
RevenueCat 與 Superwall：簡潔性與控制性
如果你之前一直使用像 Superwall 這樣的工具，那麼有這種感覺是很正常的。 RevenueCat 則較為複雜Superwall 的重點在於快速建造視覺化付費牆，幾乎可以即插即用。相較之下，RevenueCat 則更著重於業務層面：產品管理、訂閱邏輯、事件和資料。
但這並不意味著您不能使用 RevenueCat 進行創建。 簡單有效的付費牆相反，該工具專注於控制訂閱的“內容”和“時間”，而付費牆的“實現方式”則很大程度上取決於您的特定實施方案。作為回報，您可以獲得極大的靈活性，將付費牆與其他系統集成，並協調整個用戶生命週期。
此外，RevenueCat 不斷發展，引入基於人工智慧的付費牆生成工具，從而實現 從商店清單、提示或視覺參考開始 首先建立初始付費牆設計。根據該草稿，您可以針對每次對話調整設計、文字和行動號召，並在正式發布前測試關鍵點。這顯著縮短了業務層面和視覺體驗之間的差距。
簡單的付費牆：推薦結構
訂閱應用程式中常見的模式是： 兩種簡單但差異明顯的付費牆。 例如：
- 註冊完成後，會設置一個初始付費牆，沒有任何限制，用來展示整體價值主張。
- 當使用者嘗試使用進階功能時，會出現與某些功能相關的第二道付費牆，並伴隨各種限制。
在第一種情況下，付費牆通常更具「激勵性」： 您需要解釋整體福利、計劃摘要以及訂閱原因。在第二種情況下，上下文決定了：用戶正在嘗試執行特定操作（例如，訪問高級課程或高級功能），因此您需要突出顯示該功能的確切價值以及訂閱如何立即解鎖該操作。
RevenueCat涵蓋了以下部分 產品管理、定價、試用期和權利驗證您可以完全控制應用程式內付費牆的佈局、文字和視覺效果。結合人工智慧驅動的付費牆產生器，您可以快速迭代主付費牆和上下文功能付費牆的不同設計方案。
App Store 訂閱審核常見問題
使用 RevenueCat（或任何訂閱系統）時，一個相當常見的場景如下： 您提交應用程式以供審核，並首次提交應用程式內訂閱。但訂閱狀態仍為「待審核」。與此同時，蘋果的審核員打開了你的應用，到達了付費牆，然後…由於訂閱尚未獲得批准，價格和產品資訊無法正確加載。
結果通常是災難性的： 評論者無法繞過付費牆。 結果，用戶一再拒絕這款應用，因為他們覺得購買流程有問題。這就形成了一個惡性循環：應用程式仰賴尚未完善的訂閱服務，而訂閱服務又仰賴一款審核不通過的應用程式。
為了最大限度地減少這類問題，建議 準備好你的應用程式以處理中間狀態例如，如果沒有可用產品，可以顯示友善的提示資訊；可以新增跳過選項；或為審核者提供其他導航路徑。此外，建議在審核說明中清楚記錄發生的情況，如果可能，最好附上螢幕截圖或步驟說明，以便在訂閱獲得批准後重現預期行為。
另一個有用的提示是 不要將整個應用程式置於付費牆之後，而該付費牆又依賴尚未獲得批准的產品。保留部分內容或一小部分功能可供訪問，有助於審核人員理解價值主張，避免因無法測試任何內容而感到沮喪。在 RevenueCat 的背景下，也要確保您的應用程式能夠正確處理空響應或產品上傳錯誤。
RevenueCat 作為訂閱管理平台
RevenueCat 的定義是 簡化應用程式內購買和訂閱流程的平台 適用於 iOS、Android 和網頁。它處理訂閱邏輯中最敏感的部分：收據驗證、跨裝置狀態同步、購買恢復、試用期管理、促銷活動等。
此外，它還提供 用於分析和優化訂閱效能的完整工具這包括經常性收入、留存率、流失率、LTV、用戶群行為和細分等指標，可幫助您了解哪些計劃效果最佳、哪些促銷活動轉換率最高，或在生命週期的哪個階段用戶流失最多。
它的主要優勢在於，透過集中管理所有功能，避免了為每個平台重複編寫相同的邏輯。您無需直接操作每個商店的原生 SDK，而是依賴… 一個公開統一資料模型的單一SDK 讓 RevenueCat 來處理每家店的詳細資訊解析。
將 RevenueCat 與 Pushwoosh 整合：自動化和細分
在付費牆和用戶留存方面，最強大的整合之一是… RevenueCat 和 PushwooshPushwoosh 是一個用於發送推播通知、應用程式內訊息和其他類型定向通訊的平台，透過將其與 RevenueCat 連接，您可以根據真實的訂閱事件來策劃行銷活動。
這個想法很簡單： RevenueCat 向 Pushwoosh 發送訂閱事件 透過 Webhook，這些事件可以觸發客戶旅程、自動化流程和進階細分。這使您能夠鼓勵續訂、提醒客戶套餐價值、建議升級到更高級別或適時推出特惠活動，從而最大限度地提高客戶參與度和收入。
例如，一個線上學習平台可以 透過發送個人化通知來提高參與度 當系統偵測到套餐變更時，會傳送一則訊息。該訊息可能包含過渡指南、與新訂閱等級相符的課程推薦，以及強化用戶升級決定的專屬權益。
RevenueCat + Pushwoosh 整合的具體應用案例
結合使用時的應用場景範圍 訂閱活動與資訊行銷活動 它規模龐大。一些常見場景包括：
- 記住續費資訊並恢復失敗的催收嘗試。
- 將一次性購買轉化為定期訂閱。
- 利用情境化資訊推廣升級到進階版本。
- 計劃變更時，應附上教育內容或建議。
想像一下，一個串流媒體服務能夠偵測到… 訂閱計費問題透過集成，您可以觸發定向推播通知，解釋錯誤並提供清晰的解決方法，例如更新付款方式。這可以減少意外註銷帳戶的情況，並改善用戶體驗。
另一個例子：食品配送服務可以利用購物活動 將一次性訂單轉化為長期合作關係購買完成後，您可以發送推播通知，感謝客戶並推薦相關產品或介紹定期配送的訂閱方案。這種溝通頻率有助於建立客戶忠誠度、促進追加銷售，並有可能將一次性買家轉化為訂閱用戶。
對於具有多個訂閱等級的應用程式（例如許多手機遊戲），這種整合允許 監控每個使用者的等級並觸發個人化升級訊息例如，透過通知突出高級等級的優勢，例如專屬內容、額外金幣或特別折扣，鼓勵用戶在最佳時機升級等級。
RevenueCat 整合中提供的事件 → Pushwoosh
Pushwoosh 會自動建立整合。 RevenueCat首次向他們發送一系列事件每個事件都代表訂閱生命週期中的一個相關操作，並且許多事件都帶有有用的屬性（例如價格或貨幣），這些屬性隨後可用於高級細分。
以下是同步發生的最相關事件：
- RC_INITIAL_PURCHASE – 當使用者首次購買訂閱時觸發。它包含以下屬性： 價格, 以購買貨幣計價 y currency.
- RC_非續訂購買 ——表示該筆購買不會自動續訂，對於限購商品非常有用。它還包含價格和貨幣屬性。
- RC_RENEWAL ——表示現有訂閱的續訂或不活躍用戶重新訂閱的啟用。包含新的價格和貨幣。
- RC_PRODUCT_CHANGE – 當訂閱者更改產品時，例如從月度計劃升級到年度計劃，或從基本級別升級到高級級別，就會發生這種情況。
- RC_取消 – 標記訂閱取消或不可續訂購買，這是留存流程和客戶挽回的關鍵。
- RC_BILLING_ISSUE – 表示在嘗試向使用者收費時出現問題，例如卡片已過期或餘額不足。
- RC_SUBSCRIBER_ALIAS 每次註冊新車時都會簽發此證。 app_user_id 對於現有訂閱用戶，可用於多裝置追蹤。
- RC_SUBSCRIPTION_PAUSED – 表示訂閱已設定為在目前週期結束時暫停。
- RC_取消 – 通知您已取消但尚未到期的訂閱已重新啟用。
- RC_TRANSFER – 當應用程式的一個或多個使用者 ID 之間的交易和權限轉移到另一個使用者時，就會發生這種情況，這在遷移或帳戶合併中非常重要。
- RC_SUBSCRIPTION_EXTENDED – 這表示現有訂閱已延期，目前訂閱期的到期日提前。
- RC_EXPIRATION 表示客戶的訂閱已過期。包含以下屬性： 價格, 以購買貨幣計價, currency, 到期時間 y 已購於.
所有這些事件都可以用於 Pushwoosh客戶旅程那些帶有價格屬性的屬性尤其值得應用。 RFM（最近一次購買時間、購買頻率、購買金額）細分，透過它，您可以根據用戶的經濟價值和近期活動對用戶進行優先排序。
RevenueCat 與 Pushwoosh 之間的使用者同步
為了使 RevenueCat 事件能夠正確匹配 Pushwoosh 中的用戶，這一點至關重要。 對齊用戶標識符建議 Pushwoosh 使用者 ID 應與 RevenueCat 的應用程式使用者 ID.
實際上，這意味著你必須 取得 RevenueCat SDK 處理的 appUserID，並將其傳遞給 Pushwoosh SDK。這樣，當 RevenueCat 發送事件 webhook 時，Pushwoosh 可以將其與正確的設定檔關聯起來，並啟動相應的旅程，而不會遺失資訊。
例如，在 Android 系統中，可以透過以下呼叫建立這種聯繫： Pushwoosh.getInstance().setUserId(appUserIDFromRC);，哪裡 appUserIDFromRC 這是 RevenueCat 提供的識別碼。在 iOS 上，模式類似，使用類似這樣的識別碼。 [[Pushwoosh sharedInstance] setUserId: appUserIDFromRC];一旦您完成了這些通訊並同步了硬體 ID，兩個平台之間的整合就能持續正常運作。
如何在 RevenueCat 控制面板中啟用 Pushwoosh 集成
在SDK中對齊用戶ID之後，下一步是： 從 RevenueCat 控制面板啟動整合。整體流程相當簡單明了：
- 在 RevenueCat 面板中找到您的項目，並找到以下部分： 整合方式 在側邊選單中，點選「+ 新建」或「新增整合」。
- 在整合清單中，選擇該選項 網絡掛接因為與 Pushwoosh 的整合正是基於這種機制。
- 給整合功能一個易於識別的名稱，例如“Pushwoosh”，以便以後可以輕鬆識別它。
- 在 Webhook URL 欄位中，輸入 Pushwoosh 提供的路徑，例如： https://integration-revenuecat.svc-nue.pushwoosh.com/integration-revenuecat/v1/post-event?pwapp=APP_CODE. 替換 應用程式程式碼 透過 Pushwoosh 中的應用程式程式碼，您可以在其控制面板中應用程式名稱下方找到該程式碼。
- 在授權標頭值中，貼上您的 Pushwoosh API 令牌此令牌可在 Pushwoosh 帳戶的「設定」>「API 存取」區域中取得。
- 決定是否僅從以下位置發送事件 生產採購，只是從 砂箱 （測試）或兩者兼而有之。對於初步測試，通常建議先啟用沙箱環境，待一切驗證無誤後再啟用生產環境。
- 在「應用」下拉式選單中，指定是否應將 webhook 事件傳送至 一個特定的應用程式 或針對 RevenueCat 中項目中的所有應用程式。
- 在“事件類型”部分，選擇您是否想要 發送所有事件 或根據您的溝通策略，僅針對特定子集（例如，僅續訂和取消）。
- 配置是否顯示它們 所有事件、僅成功的事件或僅失敗的事件這種區別有助於您調試集成問題。
此外，您還可以選擇 啟動測試 Webhook 直接從 RevenueCat 取得資料。強烈建議使用此功能來驗證事件是否正確到達 Pushwoosh，事件模板是否自動創建，以及客戶旅程是否按預期觸發。
利用 RevenueCat 改進您的付費牆
除了驗證付款之外，RevenueCat 還提供 為優化付費牆提供了非常豐富的背景信息借助詳細的事件追蹤以及與分析和費用傳遞工具的整合能力，您可以將付費牆視為一個動態元素，根據用戶的真實行為而演變。
利用從 RevenueCat 獲取的信息，您可以例如： 找出轉換用戶和未轉換用戶之間的特徵模式這些數據能幫助您優化廣告文案、調整權益順序、優化套餐展示數量，甚至根據用戶群提供不同的付費牆選項。您可以追蹤用戶選擇的套餐、從安裝到購買所需的時間、造訪受限功能頁面的用戶數量等等。
如果再加上一個能夠利用你的店鋪商品資訊和視覺參考的AI驅動的付費牆生成器，你就擁有了一個非常強大的工作流程： 您產生付費牆的初始版本，發布它，使用 RevenueCat 分析其效能，並快速進行調整。 設計、資訊和行動號召，直到找到轉換率最高的組合。
綜合來看，將精心設計的付費牆與 RevenueCat 的訂閱管理和 Pushwoosh 的訊息自動化功能相結合，可以為擴展訂閱業務奠定非常堅實的基礎：您擁有 集中可靠的數據、完整的生命週期事件結構、即時定向溝通以及測試付費牆變體的靈活性.
雖然它最初看起來可能比超簡單的解決方案更令人印象深刻，但一旦堆疊配置完成，它就成為一個穩定而強大的組成部分，可以在此基礎上建立真正可持續的經常性收入模式。分享此信息，更多用戶將了解該工具。.