CrUXからWeb Pushの許諾のUXを考察する

## 課題
WebPush関連の施策に関して、CTRや流入数といった数値をKPIとして置いた結果、通知文言の内容や送信時間帯・送信回数が検討されることがあります。
CTRは煽る文言で改善するかもしれませんし、流入数は単純に送信回数を増やせばいいという話にもなります。

ただ利用者の立場で考えると、プッシュ通知はメールマガジンでもないので運用の仕方によっては登録を解除するかもしれません。また許諾の許可率が低いサイトはブラウザ側で[許諾の表示を目立たないように変更](https://developers-jp.googleblog.com/2020/01/chrome-ui.html)してしまう可能性もあります。

つまり本質的ではないKPIを元に運用した結果、エンゲージメントや許諾の許可率が悪化するということが起こり得るのです。さらに、その状況を見て社内でもWebPush自体に否定的な意見が出てきてしまうこともあります。

本来期待したいのは利便性やエンゲージメントの向上で「継続して利用される」ことが必要ですので、重要な指標は「許諾の許可率」になるのかもしれません。

そこでここではChrome User Experience Report(CrUX)を利用して許諾の許可率の高いサイトを抽出し、WebPushの許諾のUXを考察してみます。

## WebPushとは
ブラウザ経由で許諾を取れるプッシュ通知の仕組みです。
2021年3月現在iOSでは対応しておらず、Androidでは以下のような形で許諾を求められます。

iOSを利用している私は馴染みがないのですが、Androidユーザーであればたまに見かけているUIなのかもしれません。

![examp.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147689/838b96de-b8b8-dc17-d838-efec9b706ba9.png)

## CrUXで許諾状況を抽出
Google Chromeによって収集された「ドメインごとのUXの統計情報」がBigQueryの公開データセットとして用意されているので、ここからWebPushの許諾状況を取得することが可能です。


https://console.cloud.google.com/bigquery?project=chrome-ux-report

### SQL

以下のクエリの例では日本における2021年1月の許諾状況を、許可率順に並び替えています。

```sql
SELECT
  origin,
  SUM(experimental.permission.notifications.accept) AS accept,
  SUM(experimental.permission.notifications.deny) AS deny,
  SUM(experimental.permission.notifications.dismiss) AS dismiss,
  SUM(experimental.permission.notifications.IGNORE) AS `ignore`
FROM
  `chrome-ux-report.country_jp.202101`
WHERE
  experimental.permission.notifications IS NOT NULL
GROUP BY
  origin
ORDER BY
  accept DESC
```

※同一ドメインでも`effective_connection_type.name`ごとに行が分かれているので、集計関数`SUM()`で合算する必要があります。
※`ignore`はBigQueryの予約語のため、バッククォートでエスケープしています。
※データセット名のサフィックスで[カントリーコード](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)を指定することで任意の国のデータセットを選ぶことができます。
※各月のデータセットは翌月の第2火曜日に更新されます。

`experimental.permission.notifications`のフィールドはCrUXのドキュメントに記載があるように、acceptは許可、denyは拒否、dismissは応答せずに閉じた、ignoreは無視ということになります。

> Accept
　If the user has explicitly allowed the website to show them notifications.
Deny
　If the user has explicitly disallowed the website from showing them notifications.
Dismiss
　If the user closes the permission prompt without giving any explicit response.
Ignore
　If the user does not interact with the prompt at all.<br>
https://developers.google.com/web/tools/chrome-user-experience-report#notification_permissions

### 抽出結果

さて、クエリを実行したところ以下のような結果になりました。acceptで降順にしていますので「許可率が高い順」に並べています。

| origin                            | accept | deny   | dismiss | ignore |
|-----------------------------------|--------|--------|---------|--------|
| https\://app.slack.com             | 0.8962 | 0.0169 | 0.0716  | 0.0154 |
| https\://teams.microsoft.com       | 0.8351 | 0.0246 | 0.0822  | 0.0581 |
| https\://mail.google.com           | 0.8248 | 0.023  | 0.1072  | 0.0449 |
| https\://twitter.com               | 0.8081 | 0.0559 | 0.101   | 0.035  |
| https\://meet-in.jp                | 0.7939 | 0.0415 | 0.1104  | 0.0542 |
| https\://drive.google.com          | 0.7819 | 0.0286 | 0.1178  | 0.0717 |
| https\://membership.cyberlink.com  | 0.7803 | 0.0824 | 0.0656  | 0.0717 |
| https\://photos.google.com         | 0.7584 | 0.0665 | 0.1178  | 0.0573 |
| https\://jp.cyberlink.com          | 0.7543 | 0.0827 | 0.0823  | 0.0807 |
| https\://pasha.rakuten.co.jp       | 0.7525 | 0.0832 | 0.1303  | 0.0341 |
| https\://app.chime.aws             | 0.7106 | 0.0374 | 0.1631  | 0.0889 |
| https\://watchnavi.getnavi.jp      | 0.7041 | 0.1729 | 0.0707  | 0.0524 |
| https\://www\.low-ya.com            | 0.677  | 0.1298 | 0.1001  | 0.0932 |
| https\://mobile.twitter.com        | 0.6761 | 0.1422 | 0.1701  | 0.0116 |
| https\://member.studying.jp        | 0.6721 | 0.1429 | 0.0772  | 0.1078 |
| https\://app.jooto.com             | 0.6656 | 0.0343 | 0.1551  | 0.145  |
| https\://www\.mypage.ouchi-eneos.jp | 0.6638 | 0.1519 | 0.1843  | 0      |
| https\://us05web.zoom.us           | 0.6614 | 0.0602 | 0.1962  | 0.0822 |
| https\://kuikkuuwaki.com           | 0.6598 | 0.1771 | 0.163   | 0      |
| https\://us04web.zoom.us           | 0.6585 | 0.0504 | 0.1774  | 0.1137 |
| https\://www\.instagram.com         | 0.6546 | 0.0835 | 0.1814  | 0.0806 |
| https\://zoom.us                   | 0.6426 | 0.0598 | 0.1848  | 0.1127 |
| https\://messages.google.com       | 0.6339 | 0.037  | 0.1814  | 0.1477 |
| https\://furu-sato.com             | 0.6305 | 0.201  | 0.1201  | 0.0484 |
| https\://d.dmkt-sp.jp              | 0.6238 | 0.0819 | 0.2808  | 0.0134 |
| https\://www\.hotpepper.jp          | 0.6227 | 0.173  | 0.1573  | 0.047  |
| https\://evernote.com              | 0.6209 | 0.1044 | 0.1349  | 0.1398 |
| https\://mobilelaby.com            | 0.6154 | 0.1933 | 0.1115  | 0.0799 |
| https\://gelatopique.com           | 0.6139 | 0.1765 | 0.1512  | 0.0584 |
| https\://news.biglobe.ne.jp        | 0.5915 | 0.09   | 0.1322  | 0.1863 |
| https\://business.facebook.com     | 0.5854 | 0.0689 | 0.2004  | 0.1454 |


Slack,Microsoft Teamsが上位に位置していますが、サービスを利用する上でどちらもPush通知が重要になるサービスのため、結果としての順位には納得がいきます。

同様にgmailやtwitterもコミュニケーションツールとしてPush通知の必要性が高いのだと思います。

#### 例：時系列で可視化

各月のテーブルをUNIONする形でクエリを書き、結果をデータポータルで可視化すると以下のような形で時系列の推移が把握できます。

```sql
SELECT
  origin,
  SUM(experimental.permission.notifications.accept) AS accept,
  SUM(experimental.permission.notifications.deny) AS deny,
  SUM(experimental.permission.notifications.dismiss) AS dismiss,
  SUM(experimental.permission.notifications.IGNORE) AS `ignore`,
  202102 as month
FROM
  `chrome-ux-report.country_jp.202102`
WHERE
  experimental.permission.notifications IS NOT NULL
GROUP BY
  origin
UNION ALL
SELECT
  origin,
  SUM(experimental.permission.notifications.accept) AS accept,
  SUM(experimental.permission.notifications.deny) AS deny,
  SUM(experimental.permission.notifications.dismiss) AS dismiss,
  SUM(experimental.permission.notifications.IGNORE) AS `ignore`,
  202101 as month
FROM
  `chrome-ux-report.country_jp.202101`
WHERE
  experimental.permission.notifications IS NOT NULL
/* これを繰り返す */
```

![スクリーンショット 2021-03-26 23.36.32（2）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147689/85997d78-5b80-c5c9-d27b-df1f08e2691b.png)

例えばWHERE句で任意のドメインを指定することで、自社サイトや競合サイトがどのように推移しているか確認できます。

## Web Pushの許諾のUX
次にここからは許可率の高いサービス（非コミュニケーションツール）を参考に、許諾のUXを分類してみます。


### 1) ダブルパーミッションでの実装

任意の許諾UIを掲出して許諾を得られた場合にシステムUIの許諾を再度掲出する手法がダブルパーミッションと呼ばれており、事前にプッシュ通知の意図や利便性を伝えることで「許可率を向上」させたり「許諾とその後の配信のギャップを埋める」ことができます。

独自のパーミッションであれば拒否されても再度適切なタイミングでオファーが出せる、という運営側のメリットもあるようです。


#### SDKを利用する場合
WebPush SDKの一部としてのダブルパーミッション実装です。アイコン画像を変えたり文言を工夫することで、ある程度サイト側のテイストに合わせることができます。

![no22i.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147689/65ffbfe1-6aa6-d8b1-c33e-0091f44ec016.png)

文言だけでも「許可する」と「受け取る」では印象が変わりますね。


※上記の例の多くはOneSignalの[Web Push SDK](https://documentation.onesignal.com/docs/web-push-sdk)を利用しているようでした。


#### 独自にデザインする場合
 
SDKが用意しているUIではなく独自にパーミッションUIをデザインしています。ある程度の表示領域を確保できるので、UIデザインや伝えるメッセージの自由度も高くなります。


![ddf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147689/e5474770-9e6d-ed07-4913-5fb2b97a7212.png)


### 2) コンテクストのある許諾
あるニュースポータルでは特定カテゴリの記事詳細にプッシュ通知のオプトイン・アプトアウトUIを掲出していました。おそらく個別のトピックに対しての購読になっているものと思われます。また、通知設定ページでも任意のトピックを購読が可能になっています。

![07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147689/b5b77e1e-1c26-5797-7c12-e2b33e65415c.png)

「今読んでいる記事カテゴリ」のプッシュ通知であればある程度の興味はありますし、許諾許可までの文脈も感じられます。

そしてコンテクストの必要性についてGoogle Developersのブログでは以下のように書かれています。

> 多くの場合、初回アクセス時にウェブ通知への登録をリクエストするウェブサイトでは、受け入れ率がとても低くなります。そうする代わりに、ユーザーが状況を理解して通知を受け取るメリットを認識するまで待ってから、許可プロンプトを表示することをお勧めします。ウェブサイトによっては、ネイティブの許可プロンプトを表示する前に、コンテンツ エリアに事前にプロンプトが表示されています。ユーザーの操作が妨げられる場合、このアプローチも推奨できません。状況に応じて適切なタイミングで許可をリクエストするサイトは、直帰率が低く、コンバージョン率が高くなります。<br>
https://developers-jp.googleblog.com/2020/01/chrome-ui.html

先のダブルパーミッション実装例においても、例えばあるサイトでは「マイページや一部ページに限定」していたり、また別のサイトでは「スクロール位置でコントロールし記事を読み始めたすぐのタイミングでは掲出しない」実装になっており、サイト自体の利用体験を阻害しないような工夫がされていました。

ダブルパーミッションで実装するだけでなく、さらにコンテクストのある形での掲出が許諾のUXとして重要になりそうです。

### 3) オプトアウトが容易にできる

一部のサイトでは通知のオプトアウトのUIがわかりやすい形で提供されていました。
ユーザーによってはOS・ブラウザ設定でのオプトアウト方法が分からない場合もあると思うので、こういった配慮も大切だと思います。

![gf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147689/221211b1-3aa6-e2f5-553d-4685c814aee9.png)


## まとめ

許可率の高いサイトを観察して気付いたのは、「1) ユーザーの操作を邪魔しない形で 2) コンテクストのある適切なタイミングで 3) プッシュ通知の意図を明示し許諾を得る。また、4) オプトアウト手段も提供する」という設計がUX観点で大事である ということでした。

WebPushを「リテンション手法」として事業目線で考えるのではなく「どういった通知であれば利便性がありエンゲージメントが高まるのか」ということをあくまでユーザー目線で考えていけると良さそうです。

そしてUXの他社事例の参考にもなりますので、CrUXのデータセット是非ご活用ください。

## 参考文献

- [パーミッションの UX  |  Web Fundamentals  |  Google Developers](https://developers.google.com/web/fundamentals/push-notifications/permission-ux)
- [YEStifications: Exploring how users engage with notification prompts in the Chrome UX Report](https://dev.to/chromiumdev/yestifications-exploring-how-users-engage-with-notification-prompts-in-the-chrome-ux-report-4h7c)
- [Adding notification permission data to the Chrome User Experience Report](https://developers.google.com/web/updates/2020/02/notification-permission-data-in-crux)
- [Google Developers Japan: Chromeに、邪魔にならない通知許可UIを導入します](https://developers-jp.googleblog.com/2020/01/chrome-ui.html)

https://www.youtube.com/watch?v=riKmez3sHaM

https://www.youtube.com/watch?v=J_t8c9HOjBc