サブスクリプションオファーのベストプラクティス

(音楽) (拍手) “Subscription Offers Best Practices”へようこそ App Storeチームの ロス･ルボーです 今日 取り上げるのは App内課金の最新機能

“登録オファー”です これは斬新な方法で カスタマーに― 特定期間の割引価格を 提供できます

登録制アプリケーションの減益の 主な原因の１つは解約です これは解約を減らせる 強力なツールで カスタマーの維持や再獲得を 可能にします

何よりカスタマーへの オファーのタイミングと― タイプを選べます カスタマーが自動更新を 無効にしたという― server-to-server notificationが 届いたとします すぐに手を打ちましょう 例えば“３カ月 半額”という オファーで― 登録継続を働きかけます

お試しオファーと違い― デベロッパが 件数を決められますし 複数回 利用できます

App Storeからの 唯一の条件は― “登録中または前に登録していた カスタマーに限る”

このオファーの作成手順を 詳細に見ていきます

トランザクションごとに必要な 暗号署名の生成

新しいStoreKit APIと それを使った― トランザクションの送信

App Storeの観点と デベロッパのルールによる― オファーの対象の決定

オファーの配信とマーケティングの ヒントとコツ

そして最後に 解約を減らすビジネス戦略

まずはApp Store Connectで オファーを設定します

“機能”タブの “App内課金”セクションで― 自動更新登録のどれかを選択 “登録価格”の横の “＋”をクリックし “プロモーションオファーの作成”を 選択

分かりやすい名前と プロダクトコードを入力します プロダクトコードは 識別子でもあります このオファーの 一意の識別子です

次もお試しオファーと同じで オファーの タイプ 期間 価格を選びます こうした オファーだけでなく― 署名を生成できるよう 秘密鍵も設定します 後で詳しく説明しますが 秘密鍵の作成は― “ユーザとアクセス” セクションです “キー”を選び 左から“登録”を選択し “＋”をクリック

分かりやすい名前を入力し “生成”をクリック

するとアクティブなキーの 一番上に表示されます また そのキーのIDも 生成されます StoreKitでの参照に使う 一意の識別子です

“キーをダウンロード”で ダウンロードできます ただし キーは一度しか ダウンロードできません そう 一度だけです Appleのserverから 完全に削除されます

理由は これらのキーが― 機密の暗号化情報だからです 秘密鍵は トランザクションの利用を― 許可しているデベロッパの いわば身元証明です

アプリケーションと 設定したオファーに― １つのキーを使う場合― デベロッパアカウント全体で 有効です

複数のキーも使えます 複数の アプリケーションに― １つのアカウントを 使っているなら―

複数のキーを作成し 分割できます オファーのために送信する トランザクションは― 暗号署名が必要になります

許可されたユーザだけが オファーを利用できるように 同じくApp Storeに送る ペイロードを使い― 署名を生成します この署名は “非対称暗号方式” 広く使われている方法で― 署名の生成と検証に 鍵を２つ使います １つは先ほどの秘密鍵で ペイロードに署名する際の 身分証明書です

２つ目は“公開鍵”です 名前のとおり 他人に公開できる鍵で 署名の生成には使えません 秘密鍵を使って生成した署名の証明と 署名したペイロードの― 照合にのみ使えます

署名の生成には 秘密鍵が必要なため― デバイスではなく secure serverで生成します 他人のハードウェアに この暗号化情報が流れないように

Node.jsとExpressを使った server構築を見てみます ダウンロードできる サンプルコードです JavaScript以外の言語でも 簡単にできます PythonやPHP JavaでもSwiftでも大丈夫

アプリケーションがオファーを 表示する準備ができたら― このリクエストをserverに送り 署名を生成

ペイロードの要素を アプリケーションが把握しており― リクエストの本体から 取得するだけです Appバンドルの識別子と― 登録のプロダクト識別子を 取得します カスタマーに表示するオファーの 識別子も

最後にハッシュ化された ユーザ名を取得 これはユーザ識別情報の 一部の― 一方向ソルト化 セキュアハッシュです ユーザ名や Eメールです プレーンテキストの 識別情報を― App Storeに送っては いけません データベースで 安全に守りましょう

次の要素は“ノンス” ２つの トランザクションが― 別物だと確認する 乱数データです リプレイ攻撃などを 防ぐのに使います ユーザは デベロッパの許可なく― 同じ無料登録を 何度も要求できません

App Storeと同じ バージョン4のUUIDを使います

次はタイムスタンプ UNIX Epochフォーマットなので ミリ秒です

広く使われており JavaScriptで簡単に生成できます タイムスタンプは 攻撃を防ぐのにも使います このタイムスタンプの後 各トランザクションは― 24時間しか 受け付けられないので 署名を１週間前などに 生成しないこと

最後の要素はキーIDですが App Store Connectが 生成済みです

getKeyID関数を 埋め込みました 環境変数に格納したキーIDを 返すだけです

こうした方が― コミットしてリポジトリに 納めるより安全です 見られにくくなる

そして１つのキーIDを 返したら… ここは複数のキー使用時の ロジックの実装に理想的です

またはキーの１つが 不正アクセスされたと判断した時― App Store Connectで 無効にできます ここでロジックを 切り替え― キーを新たに生成して使えば 署名ができます 更新のプッシュが不要で ダウンタイムは最小限

ペイロードの要素が そろったので― １つのデータにして 署名を生成します

どうやるかというと この順番の文字列にします 各文字列を連結するのに― 文字コード番号 U2063を使います なぜ空白だけではダメか 暗号署名の 生成や検証の際は― 使う文字を厳密に決めることが 重要になります 空白だけでは複数の空白類文字を 参照しかねないのです

ペイロードができました 次はキーの取得です

キーIDのgetKeyStringForIDが あるので―

あとは このキーIDを 照合するだけです 別の環境変数から キーを返します

文字列内で キーを使っています これはPEM形式です よく使う形式で App Store Connectから送られ― 自社ライブラリも 他社ライブラリも扱えます

キーも取得でき いよいよ署名です

ここで使うのは “だ円曲線デジタル署名アルゴリズム” 奇妙な響きですが― ごく簡単で たった１行です Node.jsで ECKeyライブラリを使います 他言語のライブラリでも 簡単です keyStringを渡し PEM形式と伝えます

次のcryptoSignは Node.jsの暗号ライブラリの一部です SHA-256ハッシュ関数を 使います 使うライブラリに関係なく これを必ず指定します

このcryptoSignにペイロードを足し 署名の生成元だと説明します

最後は署名の生成です

この暗号ライブラリは デフォルトでは― DER形式で署名を生成します 使うライブラリの デフォルトが違う場合― ここでDERを指定します

また 生の暗号化バイト列を 返させるのではなく― base-64エンコードの文字列を 送らせます これでデータを簡単に デバイスに転送できます これもStoreKitが 使う形式です

署名ができました

次のステップは検証です 毎回でなくても 行いましょう 例えば この署名生成コードを― serverに書き込む時― エラーを防ぐのに役立ちます

これで秘密鍵を基に 公開鍵が生成され― 署名とペイロードが 検証されます あとは署名をデバイスに 送り返すだけ ここで生成した ペイロードの要素― キーID ノンス タイムスタンプと一緒に

これでserverの設定が できました 次は このリクエストを 送れるよう―

アプリケーションを 設定します

まずはApp Store Connectで 設定した― オファーの詳細を取得 SKProductsRequestを使います

コードを追加し 署名リクエストをserverに送ります

その場合の上策は― カスタマーが購入できる時に 送ることです お勧めは― ストアUIかオファーを 表示する直前です タイムスタンプの 24時間期限もありますが― 最新のビジネスロジックを 使うためです スワップアウトした キーや― オファーの対象を特定する 新たな情報など すべて― 最新版を得ること

最後にserverの応答を 処理し― トランザクションを 送信します

各SKProductに― 登録オファーの 新しいプロパティができています “discounts”です これはSKProductDiscount オブジェクトの配列 分かる人もいるでしょう お試しオファーと 同じモデルなので

価格や登録期間などの情報が 含まれています しかし 新たなプロパティが２つ

１つは識別子です App Store Connectで足した プロダクトコード

お試しオファーには 識別子がないのでnilが入りますが 登録オファーには 必ずあります

２つ目はタイプ 登録オファーか お試しオファーか 区別する列挙値です しかしお試しオファーが 取得できるのは― SKProductの introductoryPriceプロパティのみ

これでオファーを 表示できます まずはserverに fetchOfferDetailsをリクエスト

この例で渡すのは ハッシュ化されたユーザ名と― プロダクトの識別子と―

オファーの識別子 serverはAppバンドルのIDを 把握しており― すべてのコードを実行します そしてノンスと― タイムスタンプと―

キーの識別子と base-64文字列の署名を返信します

安全なHTTPS要求と応答の 作成方法は割愛します リソースが豊富ですから この完了ブロックの説明を 続けます

これらの情報を使って 作るのが― 新しいクラス “SKPaymentDiscount” SKProductDiscountでは ありません SKProductDiscountは― App Store Connectで設定した オファーの詳細 SKPaymentDiscountは― ペイロードと署名の詳細です StoreKitに送信する支払いに 添付します

これを作成してイニシャライザに渡し 完了ブロックに返せば― 準備完了です

カスタマーが “購入”をタップすると― buyProduct関数が 呼び出されます

その登録のSKProductと―

署名の生成と同じく ハッシュ化されたユーザ名と―

SKPaymentDiscountが 必須です

あとは簡単で そのプロダクトで SKMutablePaymentを作成し

applicationUsernameを設定

PaymentDiscountを そのSKPaymentDiscountで設定

これだけです 他のApp内課金と同様 支払いキューを追加します

我々は登録オファー用の SKError.Codeを追加しました

まずinvalidOfferIdentifier オファーの識別子が 見つからない時や― 無効な時に これが返されます

次はinvalidOfferPrice App Storeは都度払いの登録オファーの 価格を検証します 必ず基本登録よりも 安い価格にしますので―

例えばオファー設定後に― 基本登録を安くしたら このエラーが発生します

しかし前払いの登録オファーの 価格は検証しません

バンドルを作成する権限を 皆さんに与えたいから 例えば登録制ゲームを 始めるとします 登録を３カ月 利用できる オファーに加えて― レジェンダリーギアや 経験値ブースターもプラス 登録の価値を高めます

次はinvalidSignature

これは送信した署名が― 公開鍵で 検証できないということです または送ったペイロードで 検証できない 何かが切り替わったのです

最後はmissingOfferParams これが現れるのは― ペイロードの要素を送信し忘れたか 空で送った場合です 最もよくある例は― SKMutablePaymentの ユーザ名の送信漏れです

コードはすべて ダウンロードできます Node.js serverに 接続して― ダウンロードし すぐにローカルで実行できます Swiftコードは より詳細な― ドキュメンテーションが あります

ご質問があれば この後のラボへどうぞ

署名の生成方法と StoreKitへの― 送信方法を説明しました ここで浮かぶ疑問が― “オファーを誰に送る？”

App Storeが課すルールは １つだけです オファーを 利用できるのは― 自動更新登録に 前に登録していたカスタマーのみ

対象はすべての自動更新登録 オファーする登録と 違ってもいい

どの登録グループでも 構いません

現在 登録中でも 解約した登録者でもいいので― カスタマーの維持も 再獲得もできます

カスタマーは 最初の登録期間から対象です 無料 または有料の お試しオファーの登録者もです

こうしたことから― 対象になるか確認するには レシートを見ること

非常に簡単です in app配列か 可能なら latestReceiptInfo配列を見て 全オブジェクトを 反復処理します

その際 それぞれの プロダクトIDを見ます それが自動更新登録の プロダクトIDで― 登録済みであれば そのApp内の自動更新登録の― どの登録オファーも 利用できます これはApp Storeのルールで ほぼすべて 皆さんにお任せします 独自のビジネスルールを 実装して― 対象カスタマーと オファーを決めましょう

そのための すばらしいヒントを― 同僚のマイケルが お出しします (拍手) ありがとう (拍手)

こんにちは 僕はマイケル･ガーガス App Storeの 技術普及担当です 今日 皆さんに ご説明するのは― 登録オファーを使った 対象の特定 配信 そして― 自発的な解約の減らし方です

デベロッパとして 自分のApp内の― 登録アクティビティについて 自問した経験はありませんか 例えば“カスタマーは いつ解約する？” “もう解約した？” “なぜ登録を キャンセルした？”

登録オファーの対象は ロスが言ったとおり― Appレシートで判断できます in-app配列と latest receipt infoで― 過去の登録者のアクティビティが 分かります 最新のserver-to-server notificationでもお知らせします

しかし それで分かるのは 登録したプロダクトのみ Appレシートには― カスタマーの登録に関する より価値ある情報が満載です 例えば登録ステータス カスタマーは 登録期間中に更新するか？ あるいは支払いに 問題がある？

我々は一意の識別子も提供 トランザクションIDや Web注文明細行IDです カスタマーにオファーする 登録を― 皆さんが決める材料です

登録者が登録した日付や 現在の登録期間の有効期限や― 前回の更新期限などの データも提供します

登録者の意図も提供します これは登録を キャンセルされた理由です 返金要求があった場合 アプリケーションの問題かどうか

昨年のセッションで― Appレシートのユーザデータの 保存について説明しました この例ではカスタマーの 有効期限を見て― 自分のserverに保存し 登録サービスの対象になるか 判断します

verifyReceiptの― 他のフィールドを 保存する話もしました

この応答から フィールドの解析もできます 例えば自動更新ステータス

server-to-server notificationからの ステータス変更も保存しましょう server-to-server notificationには― 統合されたAppレシートも 含まれますから

登録者とカスタマーに関し Appleは― こうしたデータを 提供しています

デベロッパは― ユーザの 登録アクティビティに関し― Appleよりも 豊富なデータを得られます こうした情報を― 購入や自動更新の後に提供される JSONデータと組み合わせて― カスタマー群への特定のオファーを キュレートできます そのカスタマー群の― オファーへの反応を 経時的にモニターできます その主な指標は― コンバージョン エンゲージメント リテンション 解約

イメージしやすいよう― serverのユーザテーブルの例を 見てみましょう

ユーザIDと― オリジナルの トランザクションIDです これは登録の購入の 一意の親識別子です

しかし カスタマーの情報は― Appレシートから 追加できます ユーザの自動更新や 再請求のステータスです

さらに これらの情報は― カスタマーのアクティビティの 情報と組み合わせられます こちらは 消費されたコンテンツの例 視聴した動画や読んだ記事 保存した小説などです

この情報を見れば― 登録オファーの対象になる ユーザやカスタマーが―

判断できます

さらに一歩 進めると 追加情報の保存ができます 例えば更新期間や― カスタマーが経験した 請求エラーの数や― 特定のオファーの 対象かどうか ロスが言ったとおり― 登録キューごとに 最大10件のオファーが可能です 最大で10種類の ユーザ群を作成して― オファーの特定と配信が できます

serverのカスタマーから ３人を例に取ります

その登録アクティビティを 基に― 再獲得オファーの対象に できました カスタマーは 無料の試用期間中に― 自動更新を無効化し 解約していました

またはリテンションオファー 自動更新を無効化した カスタマーに― 登録を維持してもらうために 示すオファーです

最後はアップグレードオファー 例えば１カ月単位で 連続更新しているカスタマーに― １年間にアップグレードする オファーを提供します

こうして登録プロダクトへの 以前の登録状況だけでなく― もう少し情報を得て 対象カスタマーを判断できます こうして詳細に検討し 対象を決めたら― 次は登録オファーの配信です 登録オファーの過程を 見てみましょう

まずはお話ししたとおり― 対象のカスタマーや カスタマー群を特定します そうしたカスタマーに 働きかけ― App Storeから情報をフェッチし 提示します うまくいけば ここで― カスタマーは オファーを購入します

まずは特定ですが― ３種類の 登録オファーに対し― ３人を対象にしています

この情報をどこで提示するか

興味を持ちながら 未登録のカスタマーに― App内で メッセージやローカル通知で― 登録オファーを 直接 提示できます 重要なのは アプリケーションは― オファー消費の着地点だと いうことです ですからオファーの利用を 促す際は― 呼びかけ方を考えること そして そのオファーの価値と― 利用条件を 明確に説明することです そして必ず― 最新のApp Reviewガイドラインに 従ってください 以上はアプリケーションが 使われている場合 ユーザが 起動しなくなったら？ この過程はどう変わる？

特定までは同じですが 次に必要となるのは 登録オファーを― App外に配布する能力です

App Store外 またはApp外で― オファーを提示し ユーザの再獲得を図ります

App外での オファーの提示ですが 既存の外部チャネルを 使って― 登録の呼びかけを 配信できます 例えば既存の有料広告や Eメールマーケティング 次はuniversal linkを 使って― 外部チャネルからユーザを アプリケーションに戻せます どのオファーなら受け入れ可能か 特定します

universal linkの詳細は セッションを― ぜひご覧ください 今年のWWDCアプリケーションで 見られます

このように 対象のカスタマーを決定し そうしたカスタマーに 登録オファーを― App内か 既存の外部チャネルで 配信します 次は解約を減らすために こうしたオファーで使える― 戦術や戦略を検討します

昨年のセッションでも言及した 自発的な解約は― カスタマーが登録期間中に 登録をキャンセルすることです カスタマーが自分の意志で 登録プロダクトを手放す 一方で非自発的解約は― 意志ではなく 請求の問題が原因です

昨年は― 自発的な解約者に 別のプロダクトを提示するなどの― 戦術を提案しました しかし最善の 再獲得策ではありません 今年は次の方法を お勧めします 登録者の挙動を 分析してください Appレシートのデータや― 登録者のコンテンツ消費に関する 情報が使えます

この情報でカスタマー群を 特定してください

そして できれば それぞれの― カスタマー群に合った 登録オファーを配信します 登録オファーを 考える場合― カスタマーの再獲得だけを 考えることが多いです しかし そこから もう少し広げて― 登録オファーに実装できる あと５つの手段を検討します

まずは リテンションマーケティング 次の登録期間に更新しないと 決めたカスタマーの維持を― 登録オファーで図れます

いずれ解約される可能性を におわせる情報があった場合― セーブオファーを 提供できます 解約される可能性を 前提にしています

登録者のアクティビティと プロダクトをAppレシートで見て― アップグレードか ダウングレードのオファーを― 提案できます

さらに App内で不快な経験をした カスタマーを― 登録オファーで なだめられます

更新の多いカスタマーに 報いるのにも使えます

１つずつ見ていきましょう こうしたオファーを どうカスタマーに表示するか

まず最初は再獲得の例です こちらは 26日に購入した登録者の例です

登録の途中でキャンセルを決めて AppleCareに電話し― 不満とキャンセルと 返金要求を伝えました

お話ししたとおり この情報はAppレシートで分かります 例えば“キャンセル日”は 返金とキャンセルが発生した日 “キャンセル理由”は― アプリケーションの問題か どうかが分かります

最新のserver-to-server notificationで知らせますので― 登録者の状況を リアルタイムで把握できます

代替オファーを見るよう 登録者に促せます

こうした情報を― レシートやserver-to-server notificationから取得したい 自動更新ステータスや 期限切れの意図などの情報です そしてserverに保存したい

再獲得オファーの対象者を 特定できます これで登録オファーを 表示できるのです

こちらの例は “もう一度 新たな体験を” 解約したカスタマーを― デベロッパとして 取り戻そうとしています

こちらは iTranslateのデベロッパが― 登録オファーで無料期間を １カ月 追加した例です 登録オファー機能実装の 好例です

次はリテンション アプリケーションの 現在の登録者を維持することです こちらは 登録を購入したカスタマー しかし途中で― Appleの“登録の管理”に たどり着いて― キャンセルを選びました

server-to-server notificationが 最新なので― レシートの再検証で この情報が分かりました 自動更新ステータスが “1”から“0”に変わっていたら― カスタマーは 自動更新をしないという合図です

しかし登録オファーの 発信後は― ステータスの送信か server-to-server notificationで― カスタマーが更新しないことを お知らせします カスタマーが更新ステータスを 無効にした時にも― 有効にした時にも お知らせします

こちらはカスタマーを 引き止めるメッセージ 今後の登録オファーに注目と 呼びかけています

ユーザテーブルのカスタマーを 見てみると― フィールドが更新され リテンションオファーの対象に マーケティングか 実際の使用により― カスタマーが アプリケーションに戻った際― 登録オファーで 今すぐ登録できると伝えられます “もう一度 新たな体験を” “来月もぜひご利用ください”

再獲得と維持のための すばらしい呼びかけです

Ultimate Guitarは１カ月無料と 月額50％割引をオファー 本日限りのオファーと 知らせています

以上がリテンションです 次はアップグレード

この登録者は― ４月１日に ダウングレードを選択

更新されるプロダクトが レシートに記載されます この応答を解析し serverに保存できます また server-to-server notificationで― ダウングレードを選んだことも 知らせます

カスタマーが 別のプロダクトを選んだら― それまでの サービスのレベルを把握します 例えば１年間 登録し― 長期登録による割引を 受けていたかも あるいは さらに高レベルの― 低いレベルではもうアクセス不可の コンテンツで カスタマーは見ていました

この例ではダウングレードした カスタマーを― アップグレードオファーの 対象に

カスタマーが 戻ってきたら―

明確かつ簡潔な呼びかけで 登録オファーを表示できます どんなオファーか 受けて何が得られるか

こちらはDashLaneの好例です プレミアムプランへの アップグレードを促しています

以上がアップグレード

次はカスタマーサービスです

我々は完璧を期していますが それでも登録プロダクトの 問題や停止― バグやダウンタイムが 発生することがあります

ユーザは サポートチャネルから― 今ひとつな体験をしたと 知らせてくるかも

ユーザテーブルを 再度 見てみましょう カスタマーサービス担当者が そのカスタマーを検索し― オファー対象だと 特定できれば― そのアプリケーションの 再起動を指示できます 今はオファー対象ですから 設定画面に―

登録オファーを 表示すべきかもしれません こちらは １カ月無料のオファーと― サービス中断に対する おわびです カスタマーに示される 登録オファーの― 呼びかけは明確で簡潔です カスタマーを満足させ続け― 不快な体験をしたカスタマーを なだめられます

更新の多い登録者に報いるのにも 登録オファーが使えます

このカスタマーは― 11回目の連続更新を しようとしています デベロッパにとっては すばらしい登録者です ぜひ報いたい ユーザテーブルを見ると― 更新期間が記録されています Appレシートの情報を 保存すれば分かります

カスタマーの タイムラインから― ロイヤルティオファーの 対象にできます 報いたいと感じる基準値を 超えているからです 次にアプリケーションが 起動された時― カスタマーに 報いることができます 例えば１カ月無料を 提供します

こちらはLuminaryの例です プレミアム登録者への 報酬として― 今 アクティブにすると サービスを２カ月 延長

最後はセーブオファーです リテンションオファーに 酷似しています ただしデベロッパには― カスタマーが解約する可能性を におわせる情報があります これはカスタマーが― “購読の管理”にたどり着き キャンセルする前です

解約しかねないと思われる カスタマーの１人が― デベロッパが設定画面に 深く埋め込んだリンクから― “登録の管理”に 飛ぼうとしていたら？ そのカスタマーに 登録オファーを表示します カスタマーが 飛んでしまう前に

この６つが App内の自発的な解約を― 最小限に抑える方法の例です

しかしこれは序の口で デベロッパの皆さんの― すばらしい体験を 提供できる― 驚きのアイデアを 楽しみにしています

登録オファーを カスタマーに配信したら― 次は登録オファーの パフォーマンス分析です そして本日 発表するのが― ２つの新たな レポート用ダッシュボードです 登録アクティビティの分析を 支援します “Subscription State”と “Subscription Event”です

App Store Connectへ “売上とトレンド”に 移動すると― Subscription Stateが できています ここでは登録者基盤を 経時的に把握できます

例えば標準価格 お試しオファー 登録オファーが― それぞれ登録者全体に占める 割合が分かります

これは優れたツールで 登録者数の増加を経時的に― テリトリ別に分析できます

さらに このダッシュボードは― どのオファーがApp内で― カスタマーに 利用されているかも分かります

もう１つの Subscription Eventは― ユーザやカスタマーの― 登録アクティビティを 経時的に見られます 標準価格の登録への移行が どのぐらい順調か確認できます あるいは例えば 新規登録者と― 再登録者の比率を見られます

適切なフィルタをかけることで 具体的に確認できます 特定の登録オファーが どれだけ非登録者を再獲得したか その上でオファーが通知でき オファーと配布方法を― 経時的に最適化できます

まとめますと 今日のセッションの収穫は― 登録オファーの実装でしょう

これはApp内にもserverにも 実装しなければなりません

対象特定の詳細なルールを ぜひ実装してください レシートの情報や―

server-to-server notificationから― カスタマーの状況を リアルタイムで把握できます

デベロッパだけが持つ データからも

登録オファーの提示は 前後関係を踏まえてください

最高のカスタマー体験を App内で提供できるように

最後に 登録オファーを カスタマーに配置したら― 新たな２つの レポート用ダッシュボードで― パフォーマンスを 経時的にモニターします

もっと詳しく 知りたい方は― この後 すぐに始まるラボへ ぜひどうぞ

ご参加 ありがとうございました どんなアプリケーションを 皆さんが作り― 優れた体験を提供するか 楽しみです 以上です (拍手)