見出し画像

【Apple WWDC2022】アプリマーケターが知っておくべき最新アップデート情報まとめ

■ はじめに
こんにちは!Repro稲田(@HirotoInada)です!

今年もAppleの開発者向けイベント"WWDC"が開催されました。

今回は"WWDC"のアプリマーケターが知っておくべき注目アップデート情報を取り上げます。

"Google I/O"のGoogle Play Store・Google Play Console編はこちら
"Google I/O"のAndroid・Firebase編は
こちら

1. iOS16

1-1. ロック画面が大刷新

ロック画面が大幅に刷新され主に3つのアップデートがなされる。

①ロック画面にウィジェットが配置可能に
iOS14でホーム画面にウィジェットが追加できるようになったが、iOS16からはロック画面にもウィジェットを設置することができるようになる。

ロック画面に配置できるウィジェットをサードパーティアプリも開発可能かどうかは現時点では不明だが、ホーム画面でのウィジェット開発状況を考慮すると、一定可能性があるのではないかと思われる。

Appleによると2016年段階で平均的なユーザーは1日80回ロック画面を確認しているそうなので、もしサードパーティアプリでもロック画面向けのウィジェット開発が可能な場合は、ユーザーとの重要な接点として大いに活用余地があるだろう。

②複数種類のロック画面を設定可能に
旧来はロック画面は1種類しか設定ができなかったが、iOS16では複数種類のロック画面が設定でき、スワイプにより自由に切り替えられるようになる。
また、後述の”Focus Filter”と組み合わせることで、特定のシチュエーションではこのロック画面を表示するなどの切り替えが柔軟にできるようになる。

③プッシュ通知の見え方に変更あり
昨年導入された”Notification Summary”に続き、ロック画面での通知の見え方が変更される。
現状のiOS15では通常はロック画面にプッシュ通知が新着順に縦に並んで表示されるが、iOS16からは新着の3つのみがロックスクリーンでは表示されるように。

iOS16のロック画面での通知の見え方

通知を送信するタイミングによっては他のアプリと被ってしまい、プッシュ通知がユーザーに表示されない可能性もあるため、送信時間の策定を慎重に行う必要がある。

参考:iOS15のロック画面での通知の見え方

1-2. リアルタイムの情報をお知らせできる”Live Activities”

一定時間の間に刻一刻と変化が生じる事象を毎回通知するのはユーザー体験としてよろしくない。
この課題を解決するのが”Live Activities”である。

Live Activities APIを使用することで、通知を複数回送信することなく、ロックスクリーン上でリアルタイムの変化する状況を表示することができる。
Live Activitiesが活用できるケースとしては、スポーツの試合状況・デリバリーの配送状況・ワークアウトの進捗などが挙げられる。

1-3. “Focus Filter”によりきめ細かい”Focus”モード設定が可能に

昨年登場した”Focus”モードがよりユーザーに合わせて自由に設定ができるようになる。
具体的には、ロック画面との連動・”Focus Filter”の登場の2つがアップデートになる。

①ロック画面との連動
前述の通り、大幅にカスタマイズ性が向上したロック画面であるが、特定のFocusモードとロック画面を紐付けて管理・切り替えることが可能になる。
例えば、”Focus”のWorkモードとToDoリストをウィジェットとして表示したロック画面を紐付けたり、Personalモードと家族の写真を壁紙にしたロック画面を紐づけるなどができる。

②”Focus Filter”の登場
旧来の”Focus”では、モードごとにユーザーがどのアプリから通知を受け取るか・ホーム画面に表示するかどうかを”アプリ単位”で選択をしていた。
今回発表された”Focus Filter”では、”アプリ内のコンテンツ種単位”で通知・表示の制御が可能になる。

例えば、ブラウザアプリであれば特定のウェブサイトのみをモードに紐づけることができたり、メッセージアプリでは特定の連絡先からの通知をモードに紐づけるなどが可能になる。

アプリ側はFocus Filter APIを使用することで、アプリ内のどのコンテンツ・機能がどのモードに該当するかを宣言することができ、ユーザーはその制限内容に応じて各モードと紐付けたり、制御を有効にすることになる。
特定のシチュエーションでユーザーが利用・機能を制限したくなるようなサービス(エンタメ系・SNS系が多いか)の場合は、Focus Filter APIを導入することで、ユーザーのアクセス低下可能性を最大限減らせるのではないだろうか。

1-4. Wallet で管理できる情報が大幅拡張

Walletで管理・利用できる情報が大幅に拡張する。

①本人確認書類の保存と利用
既に米国では運転免許証などの本人確認書類をWalletに保存することが一部の地域で可能になっていたが、iOS16ではWalletに保存された本人確認書類のデータを利用した年齢確認・本人確認作業がアプリ・AppClipsから可能になる。

この確認の際に、読み込みを行うアプリ・App Clipsには本人確認書類の結果データのみを返す形になるため、安全に本人確認ができる。
例:20歳以上かを確認する本人確認処理に対しては生年月日の年のみを返す・確認結果のみを返すなど

この機能が日本でも対応した場合は、特にマッチングアプリなどはリスク低減のために本人確認書類データを自社で管理するのではなく、Wallet側から結果を戻してもらう形などが良いかもしれない。

②デジタルキーの電子化・共有
既に車・ホテル・住居などの鍵を開ける鍵を電子化してWalletに保存することは可能だったが、さらに鍵の共有が可能になった。
既に、車ではBMW・ホテルではハイアットグループがデジタルキーを導入しており、今後も様々なシチュエーションで本機能は活用されるだろう。

③配送状況確認・受け取りコード表示も可能に
“Apple Pay Order Tracking”で注文した商品の配送状況もWallet上で確認が可能になる。また、受け取りに必要な二次元コードもWallet内で表示できる。

オーダー管理情報を連携することでどのアプリでも“Apple Pay Order Tracking”上に配送状況を表示することが可能になる。
加えて、Shopify・注文管理サービスRoute、Narvarを用いるとより簡単に配送状況の連携が実現でき、今後もさらに多くのECプラットフォームとも連携予定。

1-5. Apple Payの対応領域が拡張

AppleはApple Payで本気でフィンテック領域を取りに行くようだ。

①”Tap to Pay”の正式提供開始
今年2月に提供予定が発表された”Tap to Pay”がiOS15.4から米国で利用可能になった。
”Tap to Pay”はiPhoneを決済端末化する機能で、物理の専用決済端末がなくても、iPhone to iPhoneやタッチ決済対応カード to iPhoneでの決済を可能にする。
これにより、専用決済端末を持たない個人店や露店においても、iPhoneさえあれば決済が可能になり、デジタル決済対応による新規顧客取り込み・機会損失低下が見込まれる。

既にStripeやSquareなどの決済サービスプロバイダーと連携も完了しており、今後も順次対応サービスが拡充していく予定。
ちなみに、国内ではドコモも電子マネー”iD”をスマホ同士で決済可能にする実証実験を行なっており、日本に”Tap to Pay”が上陸した際にどのような受け入れられ方をするかが気になるところだ。

②”Apple Pay Later”でBNPL市場に参入
昨今若年層を中心に広がっているBNPL(Buy Now Pay Later)市場に、Appleが”Apple Pay Later”の提供で参入する。

Appleが凄いのが、貸し付け自体もApple自身の子会社を通じて自分で行う点。
小売の巨人のAmazonでさえ自身で貸し付け行わず、与信管理サービスであるAffirmとの提携でBNPLを実現している。また、そのAffirm自身も自身での貸し付けは行わず、あくまでも与信管理のみを行う。

自身で貸し付けのリスクを負うことになるが、4回分割払い・無利子・手数料無しの魅力でユーザーを強烈に惹きつけ、BNPL市場に食い込んでいくのだろう。

尚、”Apple Pay Later”はApple Payに対応している事業者であればオンライン・オフライン問わずに利用ができ、事業者側には追加機能開発は必要なく通常のApple Pay決済と同様に支払いが行われる。

③複数マーチャントへの支払いが安全に可能に
Apple Payに”Multi-merchant Payments”機能が登場し、一回の支払いでの複数マーチャントへの支払いが安全に可能になる。
例えば、旅行代理店サイトを経由して飛行機・ホテル・レンタカーの予約をする際に、旧来は旅行代理店を介して各サービスに支払い情報が渡っていた。

今回のアップデートでApple Payを介した支払い時に、中間サービスにどのサービスにいくら払うかのトークンを渡せるようになるため、直接取引をするサイトだけに支払い情報を渡した状態で、安全に複数の取引を一括で行えるようになる。

④支払い情報の紐付き先がデバイスではなくApple IDに
旧来の支払い情報はiPhoneにデバイス単位で紐づいていたが、”Apple Pay Merchant Token” ではApple IDに紐づける形で管理がされるようになる。

これにより、仮にユーザーがiPhoneの端末変更をしてもApple IDに紐づく形で支払い管理が可能になるため、支払い失敗による機会損失やユーザーの再登録などが必要なくなる。

1-6. SafariもWeb Pushに対応予定

遂にSafariもWeb Pushに対応予定であることが発表された。
Macでは今秋リリース予定のmacOS Venturaから対応予定、iOS・iPad OSも来年対応予定。

Chromeなどと同様に、SafariでもWeb Pushを送信するにはユーザー側に許諾を求める必要がある。(上図参照)
通知設定はユーザー自身が2つの方法で管理可能で、システム環境設定の通知設定・Safariの環境設定のいずれかから設定が変更できる。

尚、Web Pushの配信にはネイティブプッシュ通知と同様にApple Push Notification Serviceを用いるが、Apple Developerアカウントは必要ない。

1-7. App Clipsの機能アップデート

2020年に登場したApp Clipsのアップデートが発表された。
①App Clipsサイズの拡張
旧来は10MBしかApp Clipsファイルに含めることができなかったが、今回のアップデートで15MBまでサイズが拡張する。
単純にApp Clipsに含めることができるデータ量が増加したため、よりリッチな体験をApp Clipsで実現することができるようになる。

②Diagnostics Toolの登場
App Clipsが正常に作動しているかを診断できるデベロッパー用のツールが登場。
XCodeと接続してDeveloper Settingにアクセスし、App Clipsのリンクを入力することで、App Clipsに設定しているリンク・コードなどが正常に動くものかどうかを自動で診断をしてくれる。

③Cloud Kitへの対応
App Clipsは今まではiCloud上に存在するデータにアクセスできるようにするCloud Kitに対応していなかったため、App Clipsがデータを参照する際にはサーバーに読み込みに行く必要があった。

今回のアップデートで、App ClipsがCloud Kitに対応したことで、Cloud Kit上に保存したデータを読み込めるようになるため、フルパッケージアプリと同一のコード・データを共有してApp Clipsを動作させることが可能に。

今まで
これから

④Live Activities APIとの連携
前述のLive Activities APIともApp Clipsは連携予定。
App Clipsを用いたLive Activities体験が提供可能になるため、ユーザー体験・ユースケースが広がる形となる。
想定されるユースケースとしては、スポーツVODアプリでスコア結果進捗のみをApp ClipsのLive Activitiesで体験してもらい、試合終了後にフルパッケージアプリでの動画視聴を促進するなどだろうか。

2. App Store / App Store Connect

2-1. 審査プロセスの変更

アプリの審査プロセスに変更があり、一度の審査で複数のアイテムの審査提出が可能になる。
例えば、カスタムプロダクトページは旧来は1つずつ審査に提出する必要があったが、それが複数種類まとめて一回の審査で提出ができるようになった。

グループ化して提出したアイテムはまとめて審査してもらえるため、より提出アイテムのコンテキストが伝わりやすくなり、且つ審査プロセスも効率的になる点が利点。
グループ化して提出できるアイテムは、アプリバージョン・In-App Events・Custom Product Pages・Product Page Optimizationが該当。

ただし、グループ化して提出した審査対象のアイテムのいずれかがリジェクトされた場合は、そのグループに含まれる他のアイテムも公開することができない点に注意が必要。
対応としては、リジェクトされたアイテムを修正して再提出するか、リジェクトされたアイテムをグループから削除することで残りのアイテムはストアに公開が可能になる。

2-2. App Store Connect APIの強化

App Store Connectの管理を簡易にするAPIに3つのアップデートが行われる。

①アプリ内課金アイテムの編集強化
アプリ内課金アイテムの作成・編集・削除に加えて、価格変更やプロモーションコード生成などもAPI経由でできるようになる。

②ユーザーレビューデータの取得・返信が可能に
全デベロッパー待望のユーザーレビューデータの取得・返信がAPI経由でできるようになる。

③App Hang Diagnosticsの強化
アプリフリーズに関するデータがより詳細にAPI経由で取得・確認できるようになる。

2-3. ベンチマークレポート機能が提供予定

Appleもベンチマークレポート機能“Benchmarking”を提供する予定。
既に2020年段階でGoogleも”Peer Group”という名称でベンチマーク機能を提供しているが、Appleも倣う形となった。

“Benchmarking”では、ユーザー獲得→利用・定着→収益化の各段階でそれぞれ以下の指標が閲覧可能。

ユーザー獲得:コンバージョンレート
利用・定着:リテンションレート(Day1・7・28)・クラッシュ率
収益化:ARPPU

“Benchmarking”で比較対象になるPeer Groupは以下の軸に沿ってApple側が自動的に選定を行う。

①カテゴリ:同一カテゴリのアプリが対象
②ビジネスモデル:無料・フリーミアム・有料・ペイドミアム・サブスクリプション

具体的なベンチマーク比較方法としては、以下のようにPeer Group内での各指標の優劣を相対的に可視化するのみで、個別アプリの具体的な数値はおろか、どのどのアプリが実際にPeer Groupに入っているかどうかはデベロッパーが互いに分からないようになっている。

簡単にGoogle Play Consoleのベンチマーク機能と比較を行う。

アプリの指定・閲覧
Apple:自動で判定されどのアプリが対象かは分からない
Google:個別カテゴリを指定可能

アプリの選定粒度
Apple:アプリカテゴリ×マネタイズモデル
Google:アプリカテゴリ>サービス種 (例:ビジネス>転職アプリ)

閲覧可能な指標
Apple:DL率・リテンションレート(Day1・7・28)・クラッシュ率・ARPPU
Google:DL率・ユーザー増減率・リピート率

本機能は来年初旬より提供開始予定。

2-4. アプリアイコンが単一サイズのみ作成すればOKに

旧来はデバイスタイプ・使用箇所ごとにアプリアイコンファイルをサイズ違いで生成する必要があった。
今後はXcode14を用いることで、1024×1024の単一サイズのファイルをアップロードするだけで、ターゲットに合わせて自動的にアプリアイコンがリサイズされるようになる。

アプリアイコン作成の手間の削減はもちろんであるが、こちらの記事によるとパッケージ化されたアプリファイル自体の削減にも繋がるようである。特に、前述の通り今回のアップデートでApp Clipsの利用機会が増えることも予想されるため、限られたアプリサイズを最大活用するには有効な手段だと考えられる。

3. プライバシー関連

3-1. フィンガープリントが禁止される旨を再度明確に宣言

App Tracking Transparencyの説明セッション終盤において、Appleは明確に再度フィンガープリントが禁止される旨を宣言した。
仮に、ATTでユーザーがトラッキングに同意した場合でも、フィンガープリントなどデバイスから取得したシグナルをベースにユーザー・端末を特定するのは禁止と明確に言っている。

昨年のATT適用開始時にもAppleは、ATTポリシーに準拠していないSDKが含まれているアプリを連続的にリジェクトしていたが、今回の宣言で改めてフィンガープリントは今後も認可されないことが明確になった。
多くのMMP(モバイル計測パートナー)がユーザー特定を行わない、Probabilistic Attribution(確率的アトリビューション)の採用を行なっているが、今後この手法もAppleの制裁対象となるかは分からない。(Vungle曰くシグナルを使用していないため含まれないと言っているが…)

今年はATTには大きなアップデートはなかったが、GoogleもADID廃止方向性を表明して実際に”Android版 Privacy Sandbox”を推進しているため、今後も注目が必要なトピックだ。

3-2. SKAdNetwork 4.0 発表

SKAdNetworkの次期バージョン”SKAdNetwork 4.0”が発表された。(リリース自体は今年後半予定)
主なアップデート内容は以下の3点

①Hierarchical IDs / Conversion Values
②Multiple Conversions
③Web to SKAdNetwork

①Hierarchical IDs / Conversion Values
Source IdentifierとConversion Valuesの両方で階層構造を伴った計測が可能になる。

まず、Source Identifierに関しては、旧来は2桁のみしか指定できなかったものが、4桁まで指定ができるようになる。
これにより、桁数ごとに任意の階層構造を持った識別子を渡すことができるように。例えば、キャンペーン→ロケーション→プレースメントと桁数ごとに階層構造を持たせてSource Identifierを指定することができるようになる。この階層構造をどのように組むかなどは全て自由になっている。

次に、Conversion Valuesに関しては、コンバージョン数が少ないキャンペーンに関してもざっくりとした粒度で値がポストバックされるようになる。
旧来はプライバシーレベルが満たされない水準のコンバージョンしか発生していない場合はConversion Valuesはポストバックされず、大規模なコンバージョンの場合のみ値が精緻な値(Fine Conversion Values)で返されるようになっていた。
今回のアップデートでは、仮にプライバシーレベルが満たされない場合でも、ざっくりの粒度(Coarse Conversion Values)がどの程度あるのかが、Low・Medium・Hightの3段階で返ってくるようになる。

ただし、Source Identifier・Conversion Valuesいずれも、Crowd Anonymityのレベルに応じてポストバックされる情報量と粒度が変化していく仕組みになっている点に注意。

②Multiple Conversions
旧来はポストバックされるコンバージョン値は1回のみになっており、複数回コンバージョンが発生するようなサービスにおいては初回CVが発生した後にユーザーがどのような行動をしているのかなどは取れなかったが、4.0ではポストバック回数が3回に増大する。
ポストバックのタイミングは、1回目:0〜2日 2回目:3〜7日 3回目:8〜35日 で区切られており、それぞれの回数の期間終了時にポストバックが送信される。

ただし、それぞれの回数でのポストバック値・取得可能者に関しては以下の注意点がある。

・初回ポストバック時にのみ精緻なFine Conversion Valuesが送信される
・2回目以降のポストバック時はざっくりのCoarse Conversion Valuesが送信される
・2回目以降のポストバックはデベロッパー・入札勝利者(アドネの場合)のみが受け取れる

Web to SKAdNetwork
SKAdNetworkの計測がWebブラウザにも対応を開始する。
ブラウザの広告を踏んだ場合でも計測が可能になるが、広告リンクが埋め込まれている先がファーストパーティのサイトである点・アイフレームで埋め込まれていることが計測の条件となる。

計測においてアプリデベロッパー側で必要な対応は特になく、広告媒体・アドネットワークから発行される広告リンクを埋め込むだけで良い。
アドネットワーク側はWeb to SKAdNetworkに対応した広告リンクの生成、そのための計測環境対応が必要になるため、SKAdNetwork導入時と同様に計測可能な媒体とそうでない媒体が大きく分かれてくる気がする。

3-3. 他サービスからペーストをする際にも許諾が必要に

iOS16では”Pasteboard permission”という名称で、他アプリからコピー&ペーストをする際にも許諾が必要となる。

具体的にはコピー元のアプリからペースト先のアプリでペーストを行う際に、読み込み権限を与えていいかどうかの許諾ダイアログが表示される。(初回のみか毎回なのかは不明)
以下の例では、”Notes”から”Sample App”にクリップボード内のコンテンツをペーストしようとしている。

ただし、このダイアログの掲出を防ぐ手段も存在し、キーボードショートカットを利用した場合・UIKit Paste Controlを適用した場合はダイアログが掲出されない。

UIKit Paste Controlをペースト先のサービスで適用すると、ペーストを行うボタンが表示可能になり、このボタン押下経由であればユーザーに”Pasteboard permission”のダイアログは表示されない。尚、このボタンの見た目は自由に設定することが可能であるため、アプリ内デザインに合わせて、アイコンのみ・テキストのみなど変更することができる。

3-4. パスワード管理が不要に”Passkeys”

煩雑なパスワード管理を不要にする新機能”Passkeys”機能が発表された。
旧来のパスワード管理では、アクセスするサービスのサーバー側にハッシュ化されたパスワードが保存されていたため、攻撃対象になる懸念があった。

“Passkeys” ではサービスにアクセスするための鍵を、秘密鍵・公開鍵で分離して保存する仕組みにすることで、理論上情報の流出が発生しない仕組みになっている。
具体的には、秘密鍵はユーザーのデバイスに保存し、公開鍵はアクセスするサービスのサーバーに設置することで、仮にサービスが攻撃されたとしても秘密鍵がない限りは個人情報にアクセスできないような仕組みを構築している。(そもそも公開鍵は公開しても問題ないもので、公開鍵のみではアクセスできないのでセキュリティ上の懸念はない)

また、家族や友達に特定のサービスのパスコードを共有する際、旧来はテキストで送信をしており管理に安全上の懸念が存在したが、Passkeysを特定のユーザーにAirdrop経由で共有をすることもできるので、安全で簡単な管理が可能になる。

“Passkeys”を用いることで、SMSやメールなどによる二段階認証も必要がなくなり、サービスからの情報流出の恐れも低減されるため、Appleとしては各デベロッパーに積極的な”Passkeys”への対応を呼びかけている。


最後に

以上、"WWDC 2022"のアップデート情報でした!

---------------
ぜひこのnoteの感想やご意見をTwitterで教えてください!
https://twitter.com/HirotoInada

この記事が気に入ったらサポートをしてみませんか?