1. Overview

本章節(jié)包括以下內(nèi)容：

• 使用新屬性 SKStorefront 來為不同地區(qū)的用戶提供對(duì)應(yīng)的商品
• 應(yīng)用收據(jù)中將添加應(yīng)用預(yù)購的信息（watchOS 6.0 也將支持預(yù)購）
• 使用服務(wù)端對(duì)服務(wù)端的通知來管理用戶訂閱狀態(tài)
• 訂閱生命周期的講解
• 訂閱服務(wù)新特性：賬單緩沖期

其中，最重要的就是服務(wù)端對(duì)服務(wù)端通知的新類型，其他特性業(yè)界基本都有手動(dòng)實(shí)現(xiàn)的方案，現(xiàn)在只不過更方便成本更低。而服務(wù)端對(duì)服務(wù)端通知新類型的添加，則對(duì)用戶訂閱狀態(tài)的管理方案帶來了實(shí)質(zhì)性進(jìn)步，因此蘋果也為此處分配了很長的篇幅。其次是賬單緩沖期，可以為我們帶來額外的收益。

2. What's new in StoreKit

2.1 Subscription Offers（訂閱優(yōu)惠）

從 iOS 12.2、tvOS 12.2、macOS 10.14.4 開始，為了幫助應(yīng)用保持訂閱數(shù)量，挽回訂閱流失，蘋果為應(yīng)用內(nèi)訂閱服務(wù)提供了訂閱優(yōu)惠的支持，包括一定時(shí)長的免費(fèi)試用、一定時(shí)長的低價(jià)訂閱等十種類型的優(yōu)惠方案。開發(fā)者可以在 iTunes Connect 里為訂閱類型的商品設(shè)置促銷，促銷對(duì)新用戶和曾經(jīng)訂閱過的老用戶有效。蘋果會(huì)自動(dòng)判斷當(dāng)前用戶是否符合優(yōu)惠條件，從而在調(diào)起系統(tǒng)的內(nèi)購面板時(shí)，自動(dòng)展示促銷文案或者正常價(jià)格。

2.2 SKStorefront

SKStorefront 用于描述當(dāng)前用戶 App Store 的店面信息，目前它只有一個(gè) countryCode 屬性可用，這是一個(gè)三字符的國家地區(qū)編碼，表示用戶的應(yīng)用商店所設(shè)置的國家或者地區(qū)。蘋果為 SKPaymentQueue 對(duì)象添加了一個(gè)SKStorefront類型的屬性，名為 storefront。 未來應(yīng)該會(huì)有更多的屬性被添加進(jìn)來。

蘋果給出了示例，在進(jìn)行內(nèi)購商品展示前，主動(dòng)獲取 SKStorefront的countryCode， 然后對(duì)內(nèi)購商品一一核對(duì)，確定該商品在當(dāng)前國家是否要提供。這樣一來，內(nèi)購商品的展示邏輯就放在了客戶端。很多公司出于靈活性等考慮，商品列表的數(shù)據(jù)是放在服務(wù)端的，這樣可以隨時(shí)配置線上的商品，而對(duì)于不同國家展示不同商品這個(gè)需求，之前也有很容易實(shí)現(xiàn)的方案，舉個(gè)例子：服務(wù)端根據(jù)請(qǐng)求的 ip 判斷所處地區(qū)，動(dòng)態(tài)返回對(duì)應(yīng)地區(qū)的商品列表。

paymentQueueDidChangeStorefront

由于在程序運(yùn)行期間，SKStorefront 也可能發(fā)生變化（比如用戶更改了自己 App Store 的設(shè)置），所以蘋果在 SKPaymentTransactionObserver 協(xié)議添加了一個(gè)新方法：- paymentQueueDidChangeStorefront:，用來通知應(yīng)用 SKStorefront 發(fā)生了變化。在此方法中，可以重新對(duì)商品的地區(qū)信息進(jìn)行核對(duì)，確保顯示的是正確商品。

SKPaymentQueueDelegate

如果在一次內(nèi)購進(jìn)行的過程中 SKStorefront 發(fā)生了變化，應(yīng)用可能會(huì)對(duì)本次交易的內(nèi)容做出調(diào)整，比如用戶把 App Store 切換到另一個(gè)國家，你就不想讓他買這個(gè)商品了。對(duì)此，蘋果添加了一個(gè)新的協(xié)議：SKPaymentQueueDelegate，用于對(duì)交易過程中 storefront 信息變化時(shí)作出響應(yīng)。

該協(xié)議中目前只有一個(gè)方法： - paymentQueue:shouldContinueTransaction:inStorefront:，當(dāng)內(nèi)購進(jìn)行期間 storefront 發(fā)生變化的時(shí)候被調(diào)用，你可以通過返回值告知系統(tǒng)是否希望此種情況下交易繼續(xù)進(jìn)行。如果你為這個(gè)方法返回了 true，用戶的購買行為正常繼續(xù)。如果返回了 false，那么此次購買就會(huì)終止。

需要強(qiáng)調(diào)的一點(diǎn)是，出于用戶體驗(yàn)的考慮，這個(gè)方法需要盡快返回。因此，諸如網(wǎng)絡(luò)請(qǐng)求詢問服務(wù)端的處理方式可能會(huì)造成延遲，蘋果建議事先把驗(yàn)證需要的相關(guān)信息緩存在本地，然后這部分的驗(yàn)證可以直接在應(yīng)用中進(jìn)行。

當(dāng)你返回了false后，- paymentQueue:updatedTransactions: 方法被調(diào)用，你會(huì)收到一個(gè)被標(biāo)記為失敗的 transaction，錯(cuò)誤碼是 storeProductNotAvailable。這時(shí)購買行為也會(huì)被中斷，你可給出一個(gè)彈窗之類的，告訴用戶發(fā)生了什么。

2.3 App Pre-Orders

從 iOS 11.2、tvOS 11.2、macOS 10.13.2 開始，蘋果推出預(yù)購應(yīng)用的服務(wù)。開啟預(yù)定的應(yīng)用，在上架之前就可以上線產(chǎn)品介紹頁，用戶可以提前購買或者免費(fèi)獲取該應(yīng)用。在最新版 App Store 中，“游戲” tab 會(huì)經(jīng)常出現(xiàn)一個(gè) “現(xiàn)可預(yù)定”分類，里面就是可預(yù)定中的游戲。

游戲行業(yè)有個(gè)運(yùn)營的慣例是提前預(yù)約的用戶在公測(cè)或正式上線后可以獲得特殊獎(jiǎng)勵(lì)，提高玩家預(yù)定的積極性，從而在上線前造勢(shì)。針對(duì)這類需求，蘋果準(zhǔn)備在應(yīng)用的收據(jù)中添加預(yù)購相關(guān)的信息，用來判斷當(dāng)前用戶是否預(yù)購應(yīng)用，在舊版本的系統(tǒng)也將適用。

此外，在 watchOS 6.0 的手表應(yīng)用商店中，也將支持應(yīng)用預(yù)約。

3. Server-to-Server Notifications

在用戶為訂閱的第一個(gè)周期付款后，可能發(fā)生什么事情呢？用戶可能在 App Store 中取消掉自動(dòng)訂閱，可能在用戶支持中申請(qǐng)了退款，可能把自動(dòng)續(xù)費(fèi)的開關(guān)關(guān)了又開，諸如此類的所有事件，我們是通通無法獲知的，因?yàn)樗鼈兌际怯脩艉吞O果的交互，并非發(fā)生在 app 內(nèi)部。除非我們定時(shí)對(duì)所有的訂閱用戶輪詢，把驗(yàn)證收據(jù)接口都調(diào)一遍（通過驗(yàn)證收據(jù)可以獲知齊全的訂閱狀態(tài)信息），這顯然是不可能的，輪詢頻率過高負(fù)擔(dān)太重，頻率過低又失去了時(shí)效性。但是，它們對(duì)于用戶訂閱狀態(tài)的維護(hù)又必不可少，因此，全面理解服務(wù)端對(duì)服務(wù)端通知這套機(jī)制，同時(shí)正確實(shí)現(xiàn)處理的邏輯，對(duì)于提供了訂閱服務(wù)的產(chǎn)品十分重要。

3.1 What Are Server-to-Server Notifications?

以前也被稱為 statusUpdateNotifications，簡單來說，就是你需要維護(hù)一臺(tái)服務(wù)器，在 iTunes Connect 上填寫好這臺(tái)服務(wù)器的地址，并保持其穩(wěn)定可用。當(dāng)用戶訂閱的特定事件發(fā)生時(shí)，蘋果就會(huì)把事件信息通過 HTTP POST JSON 的方式主動(dòng)通知這臺(tái)服務(wù)器。你需要為蘋果的通知返回 200 的響應(yīng)作為確認(rèn)回執(zhí)，異常情況下蘋果會(huì)重發(fā)最多三次，同時(shí)，針對(duì)這些事件進(jìn)行對(duì)應(yīng)的業(yè)務(wù)邏輯處理。

3.2 Setting Up Your Server

蘋果對(duì)接收通知的服務(wù)器有以下幾點(diǎn)的要求：

1. 請(qǐng)求的連接需要符合 ATS (App Transport Security)；
2. 使用受信任證書頒發(fā)機(jī)構(gòu)頒發(fā)的證書；
3. 支持 TLS 1.2；
4. 使用 AES-128 或 AES-256 對(duì)稱加密；
5. 使用 SHA-256 或更高級(jí)算法進(jìn)行認(rèn)證；

3.3 Unified Receipt

在之前，獲取用戶訂閱信息只能通過/verifyReceipt收據(jù)驗(yàn)證接口獲取。在以后的通知中，蘋果對(duì)通知字段的結(jié)構(gòu)進(jìn)行了調(diào)整，添加了新字段.unified_receipt，包含內(nèi)購的歷史記錄等與收據(jù)驗(yàn)證接口相同的信息。需要注意的是，不同于客戶端從 bundle 中取出的收據(jù)，服務(wù)端對(duì)服務(wù)端通知里帶的收據(jù)并不和某次應(yīng)用的安裝對(duì)應(yīng)，因此，你只應(yīng)該在服務(wù)端存儲(chǔ)、處理通知中的收據(jù)。此字段將包含以下幾個(gè)信息：

• lastest_receipt：收據(jù)的唯一碼，可用于收據(jù)驗(yàn)證接口。
• lastest_receipt_info：一個(gè)包含訂閱信息和訂閱者訂閱情況的數(shù)組。
• pending_renewal_info：關(guān)于即將續(xù)訂的信息。
• status：賬單狀態(tài)
• environment：賬單創(chuàng)建的環(huán)境

最多只包含最近100條記錄，更多記錄可以通過數(shù)據(jù)驗(yàn)證接口獲取。

3.4 Notification Types

在此之前，蘋果提供了四種類型的通知：INITIAL_BUY、INTERACTIVE_RENEWAL、DID_CHANGE_RENEWAL_PREF 以及 CANCEL。它們發(fā)送的時(shí)機(jī)和字面意思一致，其中 DID_CHANGE_RENEWAL_PREF 是指自動(dòng)續(xù)費(fèi)訂閱的級(jí)別發(fā)生變化（同一項(xiàng)訂閱服務(wù)，可以分級(jí)別，例如基礎(chǔ)版、高級(jí)版等）。對(duì)于用戶訂閱狀態(tài)的維護(hù)，其實(shí)這四種通知已經(jīng)可以滿足需求，我們可以知曉用戶初次訂閱、用戶更改了自動(dòng)續(xù)費(fèi)項(xiàng)目的級(jí)別、用戶續(xù)費(fèi)了、用戶取消了訂閱。 本次 WWDC 之后，蘋果會(huì)再增加四種通知類型。分別是 DID_CHANGE_RENEWAL_STATUS、DID_FAIL_TO_RENEW、DID_RECOVER、PRICE_INCREASE_CONSENT，分別對(duì)應(yīng)用戶自動(dòng)續(xù)費(fèi)開關(guān)的更改、系統(tǒng)第一次自動(dòng)續(xù)費(fèi)失敗、自動(dòng)訂閱失敗過后再重試訂閱成功以及用戶進(jìn)入了漲價(jià)流程。其中PRICE_INCREASE_CONSENT還包含了一個(gè)字段price_increase_effective_date，用于說明用戶同意訂閱價(jià)格變化的最后限期。

3.5 Handling Notifications

這部分蘋果舉例了一個(gè)用戶訂閱的場景，過了一遍八種通知發(fā)出的時(shí)機(jī)，在此過程中詳細(xì)講解了每種通知你需要重點(diǎn)關(guān)注的字段，以及該如何處理。其中，original_transaction_id大家非常熟悉，也被演講者頻繁提到，它是一個(gè)用戶訂閱最初的交易 id，在每種通知中，你都可以使用這個(gè)字段去追溯這個(gè)交易。

需要注意的是，如果用戶升級(jí)了一個(gè)訂閱項(xiàng)目的級(jí)別，那么會(huì)收到對(duì)舊級(jí)別的 CANCEL 通知，以及對(duì)新級(jí)別的 INTERACTIVE_RENEWAL 通知。如果是自然流失之后再次訂閱，則只會(huì)收到 INTERACTIVE_RENEWAL 通知。未來 DID_RECOVER 會(huì)替代RENEWAL 通知，但目前它們會(huì)同時(shí)收到，這是為了給你的服務(wù)一定的調(diào)整適應(yīng)時(shí)間。

3.6 利用新通知提升用戶體驗(yàn)

用戶在 App Store 對(duì)訂閱項(xiàng)目進(jìn)行的操作，以及在蘋果用戶支持系統(tǒng)中發(fā)起的退款等行為，都是用戶和蘋果進(jìn)行的交互，我們的應(yīng)用和后臺(tái)服務(wù)無法及時(shí)感知，顯得非常愚鈍，因此這套通知系統(tǒng)的存在十分有必要。 總體來看，之前的四種通知，讓這套通知系統(tǒng)達(dá)到了“可用”的水準(zhǔn)，通過這四種通知類型，開發(fā)者可以方便地管理用戶的訂閱狀態(tài)，然而，也僅僅是“可用”的水準(zhǔn)。有了的新的四種通知類型，開發(fā)者可以關(guān)注到用戶訂閱行為更加詳實(shí)的細(xì)節(jié)，對(duì)于用戶的每一個(gè)操作，都能夠及時(shí)感知，并且在應(yīng)用內(nèi)做出應(yīng)對(duì)。舉個(gè)例子，系統(tǒng)第一次自動(dòng)續(xù)費(fèi)失敗，可能是用戶無意間的操作導(dǎo)致付款方式失效。此刻我們的服務(wù)端收到了蘋果的通知，然后下發(fā)一個(gè)提醒指令到客戶端內(nèi)，客戶端在合適的時(shí)機(jī)用合適的方式提醒用戶去檢查一下付款方式，從而避免無意間的用戶流失?？梢钥吹剑辛诵碌乃姆N通知，我們可以把用戶訂閱的流程做到更好，提升了用戶體驗(yàn)，也避免了不必要的流失。

4. Subscription Lifecycle

在這部分，蘋果用細(xì)致又不繁瑣的方式完整講述了訂閱行為的生命周期。大體上的過程如下：

1. Acquisition，通過試用等措施來吸引用戶訂閱你的服務(wù)；
2. Engagement，你需要不斷更新自己服務(wù)的內(nèi)容讓用戶繼續(xù)訂閱你的服務(wù)；
3. Retention，保持用戶訂閱量，減少流失。

在此生命周期中，會(huì)穿插著許多賬單相關(guān)的事件，例如：從試用到購買、服務(wù)升級(jí)或降級(jí)、續(xù)訂或取消訂閱等，通過上述八種通知類型，我們可以檢測(cè)到這些事件發(fā)生，從而做出相應(yīng)操作。在此session中，演講者對(duì)各種通知對(duì)應(yīng)的事件做了詳細(xì)描述以及給出示例。

1. Purchase，第一次訂閱服務(wù)，應(yīng)用收到此次購買的收據(jù)后，將相關(guān)信息加密傳輸?shù)阶约旱姆?wù)器，服務(wù)器請(qǐng)求驗(yàn)證收據(jù)接口驗(yàn)證賬單，并獲取更多信息保存到數(shù)據(jù)庫。服務(wù)器也會(huì)收到INITIAL_BUY通知，通知和賬單信息的original_transaction_id一一對(duì)應(yīng)。

2. Renewal，續(xù)訂服務(wù)時(shí)，應(yīng)用在下次啟動(dòng)時(shí)也會(huì)收到訂閱收據(jù)，如果你不想等到下次啟動(dòng)也可以使用第一次購買的信息，然后把賬單信息發(fā)送到服務(wù)器驗(yàn)證。這種事件服務(wù)器不會(huì)收到通知，服務(wù)器在收到應(yīng)用發(fā)來的收據(jù)信息后，直接調(diào)用接口驗(yàn)證賬單，然后提供相應(yīng)服務(wù)即可。

3. Upgrade，升級(jí)訂閱服務(wù)，服務(wù)會(huì)先收到一個(gè)舊服務(wù)的CANCEL通知，接下來會(huì)是INTERACTIVE_RENEWAL通知，服務(wù)器收到后可以去更新用戶訂閱信息，然后升級(jí)其服務(wù)。

4. Cancel，取消訂閱，用戶關(guān)閉自動(dòng)續(xù)費(fèi)的開關(guān)，在之前你可能需要對(duì)所有用戶調(diào)用驗(yàn)證收據(jù)的接口去更新訂閱信息，蘋果對(duì)這種情況作出改變，新增DID_CHANGE_RENEWAL_STATUS通知，當(dāng)用戶改變續(xù)費(fèi)狀態(tài)時(shí)通知服務(wù)器，從而避免輪訓(xùn)用戶的操作。

5. Churn，用戶在訂閱結(jié)束前，服務(wù)器沒有收到任何關(guān)于他的通知，那么就可以把這名用戶標(biāo)記為流失用戶。

6. Win Back，為了挽回流失用戶，可以實(shí)行訂閱優(yōu)惠等措施，蘋果把這單獨(dú)作為一個(gè)Session，Session 305: 訂閱優(yōu)惠最佳實(shí)踐

7. Billing Error，用戶本來沒有想著取消訂閱，但是 App Store 無法恢復(fù)或續(xù)訂，可能是用戶的信用卡出現(xiàn)異常了，這種情況下，蘋果會(huì)發(fā)出一個(gè)新的通知DID_FAIL_TO_RENEW。當(dāng)你收到這個(gè)通知時(shí)，可以停止提供服務(wù)，標(biāo)記流失用戶，并在應(yīng)用上面提醒用戶訂閱已經(jīng)失效。

8. Billing Retry，在上面的情況下，App Store會(huì)自動(dòng)嘗試?yán)m(xù)訂服務(wù)，如果成功了，將會(huì)發(fā)出新的通知DID_RECOVER， 服務(wù)器可以更新用戶訂閱信息，并重新提供相應(yīng)服務(wù)。

5. Reducing Involutary Churns（減少無意間的用戶流失）

這一節(jié)主要介紹蘋果在幫助我們減少無意間的用戶流失所做的措施和成果，包括不斷優(yōu)化和更新續(xù)訂失敗時(shí)的重試機(jī)制等，甚至使用了機(jī)器學(xué)習(xí)的模型來提升多平臺(tái)恢復(fù)訂閱的可能性。通過這次措施，蘋果恢復(fù)了 77.4% 因?yàn)橘~單問題導(dǎo)致的訂閱流失，從而將無意間的賬單流失減少至 1.6%，恢復(fù)訂閱數(shù)約 4600萬。據(jù)數(shù)據(jù)統(tǒng)計(jì)，挽回的訂閱數(shù)在前 16 天可達(dá)到 80%，那么我們?cè)谶@期間可以做什么？那就是下一節(jié)的賬單緩沖期。

6. Billing Grace Period（賬單緩沖期）

最后，介紹了一個(gè)壓軸的新特性，叫做賬單緩沖期（Billing Grace Period）。開發(fā)者可以自己選擇是否開啟這個(gè)特性，開啟后，用戶的自動(dòng)訂閱失效后會(huì)進(jìn)入一定時(shí)間的緩沖期，蘋果建議你在這段時(shí)間內(nèi)保持對(duì)用戶的服務(wù)（比如維持用戶的會(huì)員狀態(tài)），因?yàn)樵谶@段時(shí)間里蘋果可能還在持續(xù)地進(jìn)行續(xù)費(fèi)嘗試。開啟的步驟也很簡單：

1. 在 App Store Connect 中選擇開啟服務(wù)；

2. 在收據(jù)驗(yàn)證接口/verifyReceipt中，會(huì)有一新字段grace_period_expires_date，說明緩沖截止期；

3. 在截止日期前，保持相應(yīng)服務(wù)不中斷。

開啟新賬單緩沖期，可以減少對(duì)用戶服務(wù)的干擾，賬單可以維持在同一生命周期內(nèi)，那么緩沖期也會(huì)算入長期訂閱的 85/15 分成的時(shí)長中，從而給我們帶來附加的收入，蘋果強(qiáng)烈建議我們開啟這個(gè)功能。

此外，你還可以利用這段時(shí)間在應(yīng)用內(nèi)為用戶提供“最后的溫存”，比如提醒用戶你的會(huì)員你已經(jīng)過期，但我對(duì)你的服務(wù)目前還會(huì)一如既往！用戶極有可能在這段時(shí)間里被你挽回，重新安排上會(huì)員！

參考資料

• WWDC 2019 Session 302: In-App Purchases and Using Server-to-Server Notifications

• In-App Purchase Programming Guide

• Receipt Validation Programming Guide

• In-App Purchase documents

• 內(nèi)購新特性以及使用 server-to-server 通知