YEStifications：Googleの中の人が語る、通知許可プロンプトに関するCrUXの統計レポート

以下は、Googleの中の人であるRick Viscomi( [Twitter](https://twitter.com/rick_viscomi) / [GitHub](https://github.com/rviscomi) )による記事、[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)の日本語訳です。

# YEStifications: Exploring how users engage with notification prompts in the Chrome UX Report

## 📢 example.com wants to show notifications

[Notifications API](https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API)はユーザを留めるための効果的な方法ですが、実のところ多くのサイトはユーザへの通知を許可してもらえていません。
よくある問題は、ページが読み込まれると即座に、あるいはどのように使用されるかの説明なしに、いきなり許可を求めるプロンプトを表示することです。
では、ユーザは通知許可プロンプトにどのように反応しているでしょうか。
CrUXの出番です。

[Chrome UX Report](https://developers.google.com/web/tools/chrome-user-experience-report/)、通称CrUXには、3万を超えるWebサイトに対して、[通知許可プロンプトに対するユーザの反応](https://developers.google.com/web/updates/2020/02/notification-permission-data-in-crux)のデータが存在します。
このデータは、パブリックBigQueryリポジトリで公開されています。
ユーザは通知許可プロンプトにどのように反応しているか、この記事で見ていきましょう。


## The state of notification permissions

手始めに、このデータセットに含まれているWebサイトの総数を数えてみましょう。

```sql
SELECT
  COUNT(DISTINCT origin)
FROM
  `chrome-ux-report.all.202001`
WHERE
  experimental.permission.notifications IS NOT NULL
```

結果は31515で、通知のパーミッションを含むoriginが31515件あることを示しています。
originはWebサイトの最初の`/`までのアドレスのことで、たとえば`https://www.example.com`です。
ひとつのWebサイト上でのユーザの挙動は、全てorigin単位にロールアップされています。

次は試しに、SlackのWebサイトについて通知のパーミッションを見てみましょう。

```sql
SELECT
  SUM(experimental.permission.notifications.accept) AS accept,
  SUM(experimental.permission.notifications.dismiss) AS dismiss,
  SUM(experimental.permission.notifications.deny) AS deny,
  SUM(experimental.permission.notifications.ignore) AS `ignore`
FROM
  `chrome-ux-report.all.202001`
WHERE
  origin = 'https://app.slack.com'
```


| Accept | Dismiss | Deny | Ignore |
|---|---|---|---|
| 92.10% | 5.67% | 1.96% | 0.28% |

![01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26088/be31cbb6-8beb-9293-c8e0-95d01a2db506.png)


見てのとおり、Slackアプリに対しての通知の許可承諾率は92%と、非常に優れています。
言い換えると、通知許可プロンプトが表示されたときに、92%のユーザは許可を与えることを選択したということです。
残りユーザのうち約6%は許可か拒否かを選択することなくプロンプトを閉じ、2%は明示的に拒否しました。
そして、プロンプトに何もせず放置したユーザは約0%です。

ところで、Slackに対する通知パーミッションの結果は、Web全体の通知パーミッションの結果を端的に表していると言えるでしょうか？
調査対象を3万サイト全てに拡大してみましょう。

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

![02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26088/92405ec1-7197-04d0-8e87-39886f400f1f.png)


これは何を表しているでしょうか。
チャート右上のグレー部分は、通知許可プロンプトを無視したユーザの割合を示しています。
次に、チャート中央の最もスペースを取っている赤い領域は、通知許可プロンプトを明示的に拒否した割合です。
そして、チャート左端の急減している緑色の領域が、通知許可プロンプトを許可したユーザの割合です。
最後に、許可と拒否の間にある黄色が、許可も拒否も選択せずに通知許可プロンプトを閉じた割合です。

この図から、いくつかの推論を得られそうです。

最もわかりやすいのは、チャートの結果は赤が大多数であり、緑は少ないということです。
大半のユーザは通知許可プロンプトを拒否しています。
すなわち、Slackは極端に許可率の高い例外中の例外と言えそうです。

また、拒否率と無視率には逆相関がありそうです。
拒否率が小さくなると、無視率が高くなるようです。

Slackが明らかに例外であることはわかりましたが、それでは平均的なWebサイトでの割合はどのようなものでしょうか。

```php
SELECT
  AVG(accept / total) AS accept,
  AVG(dismiss / total) AS dismiss,
  AVG(deny / total) AS deny,
  AVG(`ignore` / total) AS `ignore`
FROM (
  SELECT
    SUM(experimental.permission.notifications.accept) AS accept,
    SUM(experimental.permission.notifications.deny) AS deny,
    SUM(experimental.permission.notifications.ignore) AS `ignore`,
    SUM(experimental.permission.notifications.dismiss) AS dismiss,
    SUM(experimental.permission.notifications.accept +
        experimental.permission.notifications.deny +
        experimental.permission.notifications.ignore +
        experimental.permission.notifications.dismiss) AS total
  FROM
    `chrome-ux-report.all.202001`
  WHERE
    experimental.permission.notifications IS NOT NULL)
```

| Accept | Dismiss | Deny | Ignore |
|---|---|---|---|
| 16.71% | 23.84% | 40.74% | 18.71% |

![03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26088/1384a37f-2157-86e8-de6a-47d6bb2312f1.png)

これが現実的な通知許可の割合です。
ただし、ユーザ数が全く異なるWebサイトのUXを平均化したものであることに注意してください。
この結果によると、平均的なWebサイトでは通知許可プロンプトを承認するユーザは17%であり、24%は選択せずに通知許可プロンプトを閉じ、41%が明示的に拒否し、19%が無視するということになりました。

このデータセットから他に何かわかることがないでしょうか？
今度はデバイスのフォームファクタごとに分けてみましょう。

```sql
SELECT
  device,
  AVG(accept / total) AS accept,
  AVG(dismiss / total) AS dismiss,
  AVG(deny / total) AS deny,
  AVG(`ignore` / total) AS `ignore`
FROM (
  SELECT
    form_factor.name AS device,
    SUM(experimental.permission.notifications.accept) AS accept,
    SUM(experimental.permission.notifications.deny) AS deny,
    SUM(experimental.permission.notifications.ignore) AS `ignore`,
    SUM(experimental.permission.notifications.dismiss) AS dismiss,
    SUM(experimental.permission.notifications.accept +
        experimental.permission.notifications.deny +
        experimental.permission.notifications.ignore +
        experimental.permission.notifications.dismiss) AS total
  FROM
    `chrome-ux-report.all.202001`
  WHERE
    experimental.permission.notifications IS NOT NULL
  GROUP BY
    device)
GROUP BY
  device
ORDER BY
  accept DESC
```
| Device | Accept | Dismiss | Deny | Ignore |
|---|---|---|---|---|
| スマホ     | 22.76% | 18.03% | 57.33% |  1.88% |
| タブレット | 18.75% | 20.24% | 58.34% |  2.67% |
| PC         |  6.11% | 34.01% | 11.61% | 48.27% |

![04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26088/c0c48fc9-cbf5-a97c-8bb2-d36cdf612728.png)

明白な違いが現れました。
スマホとデスクトップでは、露骨に大きな差があります。
スマホユーザは通知許可プロンプトを無視する割合が非常に低いのに対して、デスクトップユーザは約半数が通知許可プロンプトを無視します。
最も理解しやすい理由は画面サイズでしょう。
通知許可プロンプトが画面の大半を占めている場合、それを無視し続けることは難しいことです。
また興味深いこととしては、スマホユーザは拒否率が57%と非常に高いのに、承認率も23%であり最も高いということです。
理由のひとつとしては、スマホは常に持ち歩くので、通知を受信するには最も自然で便利なフォームファクタであるということがあるかもしれません。

## Where we go from here

ユーザは明らかに、押し付けがましい通知許可プロンプトを鬱陶しく感じており、そして開発者もそのことを風の噂に聞いたり実際に経験したりしているかもしれません。
今回我々は、Web全体で通知許可プロンプトがどのように位置付けされているかの実用的なデータを手に入れました。
CrUXのデータから明らかなのは、ユーザに通知許可プロンプトを効果的に承認させることができているサイトが非常に少ないということです。

Chrome開発チームは、ユーザのフラストレーションを減らすために[通知許可プロンプトの表示方法変更](https://blog.chromium.org/2020/01/introducing-quieter-permission-ui-for.html)を発表しました。
通知許可プロンプトの承認率が低いサイトは、より目立たない通知許可プロンプトが自動的に表示されるようになります。
そのため、サイトオーナーは通知許可プロンプトの承認率に注意を払う必要があります。

サイトで通知の許可要求を出しているのであれば、要求に対する反応の割合を調べるためのアクセス解析を追加しましょう。
CrUXデータセットはアクセス解析にはなりませんが、類似したサイトの承認率がどうなっているか調べたり、Web全体のトレンドを調べたりすることに役立ちます。
承認率を向上させ、より多くの効果を得るためには、[通知許可プロンプトのベストプラクティス](https://developers.google.com/web/fundamentals/push-notifications/permission-ux)を読むとよいでしょう。

この記事で紹介したクエリは、BigQueryで実行することができます。
クエリを改良して、独自の視点を見つけ出してみるのもよいでしょう。
より詳しい使い方は[using CrUX on BigQuery](https://web.dev/chrome-ux-report-bigquery/)を参照してください。
データに関する質問やフィードバックがある場合は、以下のいずれかのチャンネルからCrUXチームに連絡をお待ちしています。

・[chrome-ux-report](https://groups.google.com/a/chromium.org/forum/#!forum/chrome-ux-report) Google Groups
・[@ChromeUXReport](https://twitter.com/ChromeUXReport) Twitter
・[chrome-ux-report](https://stackoverflow.com/questions/tagged/chrome-ux-report) StackOverflow
・[GoogleChrome/CrUX](https://github.com/GoogleChrome/CrUX) GitHub


# コメント欄

「通知を求めるサイトの多さに辟易し、他のみんなは好きなのかと考えていた。Slackのように意味のあるサイト以外ではみんな好きではないようだ。」
「PCでの無視率が大きいのは画面が大きいからなのか、マルチタスクのせいなのか、他に理由があるのか、なんだろう。」
「Skackでの通知は明白なユースケースがある。タブロイド紙とかのユースケースが全く異なるサイトと一緒くたにすると有益な結果が得られないかもしれない。」
「対話的な通知許可プロンプトを出してるサイトとの許可率のちがいを出してほしい。」
「最初にページを表示してから通知許可プロンプトを出すまでの時間でプロットしてみると面白いかも。」「ページロード時に通知許可プロンプトを出しているかはチェックしてるから、今後そのネタで記事を書くかも。」



# 感想

むしろ2割も承認してることにびっくりだよ。
0.1%くらいかと思ってたよ。

というわけで、何も考えずに通知許可プロンプトを出すと、ほとんどの人が拒否します。
これは想像でも妄想でもなく、歴然とした事実です。
こんなの言うまでもなく考えるでもなく当然なわけですが、そのあたりを何も考えていない[お](https://marketimes.jp/web-push-notification/)[花](https://dmlab.jp/web/new_web/web160401_1.html)[畑](https://webpush.jp/)な記事やサービスが溢れた結果、当然の帰結として[WebPUSH通知は邪悪なもの](https://mizchi.hatenablog.com/entry/2017/12/05/223520)に成り果てました。
ま、そもそもServiceWorker自体が邪悪な用途にしか使われない技術なので今更ですけどね。

そんなわけで2019年11月、Firefoxはユーザインタラクションなしに[通知許可ウィンドウを出すことを禁止](https://www.fxsitecompat.dev/ja/docs/2019/requesting-notification-permission-and-screen-capture-now-requires-user-interaction/)しました。
Chromeはこの手の変更には極めて消極的なのでまだ追随していませんが( せいぜい[目立たなくした程度](https://developers-jp.googleblog.com/2020/01/chrome-ui.html) )、いずれは同様の変更が入るでしょう。


この記事の著者はGoogleの中の人なので通知許可プロンプトそのものには否定的ではなく、使うときは[うまく導線を考えよう](https://developers.google.com/web/fundamentals/push-notifications/permission-ux?hl=ja)という立場です。
全てのWebサイトが適切に通知を実装すれば、それは確かに有益で便利な機能となることでしょう。
しかし、大多数のWebサイトがそのようなガイドラインに従うかというとそんなわけがありません。
従って、ユーザ側として最も適切な設定は[デフォルトで一律禁止](https://qiita.com/rana_kualu/items/2d06d65e6f71823193f6#%E9%80%9A%E7%9F%A5)ということになります。
これだけで、いちいち煩わしい通知許可プロンプトに邪魔されることがなくなり、快適なブラウジングを行うことができるようになります。
Slackなど通知が必要になったらそのときに個別に設定すればいいだけですし、そして通知が必要なサイトはほとんどありません。