ダッシュボードを作ったのに、気づいたら使っていない。そういう経験はありますか。

私はLooker StudioでこのサイトのKPIサマリーを作りました。Google Analytics 4（GA4）やGoogle Search Console（GSC）の数値を1画面にまとめられて、完成時は達成感がありました。

でも実際には、GA4やGSCを直接見たり、Notionで別にまとめたりしていて、作ったKPIサマリーを開く機会はほとんどありませんでした。

この記事は、Looker Studioで作ったKPIサマリーを、実際にはあまり使えていなかったことを振り返る回です。

過去に自分でKPIツリーや要件整理、ダッシュボード設計の記事を書いてきましたが、自分のKPIサマリーではその考え方を十分に使えていませんでした。そこで、このシリーズでは、今あるKPIサマリーを見直し、週次報告やサイト改善の判断に使える状態まで作り直します。

GA4・GSCの数値確認を1画面にまとめたかった

私はサイトを運営するなかで、GA4とGSCの数値を確認する機会がどんどん増えていきました。

GA4やGSCのデータをダウンロードしてNotionにまとめたり、スプレッドシートにGoogle Apps Scriptを使って集計したりしていました。しかし、確認する場所が分散していたため、サイトの状況を把握するのに手間がかかっていました。

そこで、「必要な数値を1画面で見られるようにしたい」と考え、Looker StudioでKPIサマリーを作ることにしました。

ただ、この時点では「1画面にまとめること」ばかり考えていて、その画面を週次報告や改善判断でどう使うかまでは決められていませんでした。

初めてLooker StudioでKPIサマリーを作った

当時作成したKPIサマリーがこちらです。GA4とGSCの主要指標を1画面で確認できるようにしていました。

上部には、最低限確認したかった6つの指標をカード形式で並べ、それぞれ前期間との比較も表示しました。その下には、月別PV数の棒グラフや、直近28日間の推移グラフを入れています。GA4の数値はOrganic Searchに絞って、検索流入の動きを見やすくしました。

なお、この画面は当時の状態のまま載せています。指標名やグラフ名、期間の見せ方も含めて、今後見直していく前提です。

作った時点では、確認したい主要な数値や変動を1画面で見られるようになり、「見やすくなった」と感じていました。

ただ、完成した達成感に少し浸りすぎていたのが、正直なところです。

でも、週次報告ではNotionの表を使っていた

KPIサマリーを作り終えて満足していた一方で、実際の週次報告では、Looker StudioではなくNotion上で整理した表を使っていました。

Notionの表には、現在の数値だけでなく、目標値との差分や前回確認時との差分も入れていました。自分がパッと見て分かる形にしていたため、週次で数値を報告するときに使いやすかったです。

ただし、自分が説明しやすい表と、人が見て分かりやすい表かどうかは違います。報告時には、表の見方の説明から始まっていました。

この時に、「Looker StudioのKPIサマリーを活用できていない」と気づきました。Looker Studioは「数値を見る画面」にはなっていましたが、「報告で使う・判断に使う画面」にはなっていませんでした。

使わなかった理由を、いったん仮説として整理する

KPIサマリーを作ってはみたものの、日常的に使う習慣までは定着しませんでした。現時点で確認習慣にならなかった理由は、3つありそうです。

1. 数値確認の入口が、GA4やGSCのままだった

Looker StudioでKPIサマリーを作ったものの、実際にサイト数値を確認するときは、最初からGA4やGSCを開いていました。

Looker Studioで全体像を見てから深掘りする流れではなく、これまで通りGA4やGSCを直接見る習慣が残っていました。つまり、Looker Studioを「いつ・何のために見るのか」を決められておらず、普段の確認作業に組み込めていませんでした。

2. 報告に必要な差分がNotion側にあった

週次報告で話すときは、現在値だけでなく、目標値や前回確認時との差分を使っていました。

その情報をNotionの表に入れていたため、報告時にはNotionの方が使いやすくなっていました。結果として、Looker Studioは作ったものの、週次報告の流れには入っていませんでした。

3. 数値を見たあと、どこを深掘りするかの流れまで作れていなかった

PVやセッション、検索クリックなどの指標がつながっていることは理解していたつもりでした。

ただ自分のKPIサマリーでは、その考え方を「どの指標を見たら、次に何を確認するか」という運用の流れに落とし込めていませんでした。数値の変化は見えても、そこからGA4とGSCのどちらで、どこを深掘りするのかまでは決められていませんでした。

3つを振り返ると、「ダッシュボードを作った」と「ダッシュボードを使って動く」の間には距離がありました。少なくとも私は、「作ったこと」に満足して、実際の確認や報告の流れに乗せるところまで考えられていませんでした。

過去記事を振り返ると、できていなかったこと

ここまでは、実際の行動から「なぜ使わなかったのか」を確認しました。次は、過去に自分で書いた記事と照らし合わせながら、KPIサマリー作成時に何ができていなかったのかを振り返ります。

KPIツリーの記事では、数字をただ並べるのではなく、目的から逆算して指標同士のつながりを見る考え方を扱っていました。今回のKPIサマリーでは、表示回数、クリック数、CTR、セッション、総ユーザー数、PVを横並びに置くところで止まっていました。

要件整理の記事では、分析やダッシュボードを作る前に「誰が何を判断するのか」を整理することが大事としていました。しかし、自分のKPIサマリーでは、自分用の確認なのか、週次報告なのか、サイト改善の入口なのかを決めきれていませんでした。

月次レポートの記事では、数字を報告するだけでなく、次に何を決めるのかにつなげる考え方を書いていました。今回のKPIサマリーでは、数値の変化は見えても、どの記事を確認するのか、どの改善につなげるのかまでは示せていませんでした。

利用者別ダッシュボードの記事では、見る人や目的が違えば、必要な情報や粒度も変わると書いていました。今回のKPIサマリーも、自分用の確認、週次報告、サイト改善の深掘りという用途が混ざっていたと思います。

デジタル庁のガイドブックを参考にした記事では、ダッシュボードを作る前に、目的や使う場面、必要な情報を整理する流れを扱いました。今回のKPIサマリーでは、そこまで深く考えないまま「必要そうな数値を1画面にまとめる」ことから始めてしまっていました。

データドリブンの記事は、データを見るだけでなく、そこから考えて行動につなげる考え方です。今回のKPIサマリーは、データを見るところまではできていましたが、その後の判断や改善行動につなげる流れまでは作れていませんでした。

つまり、今回私ができていなかったのは、誰が何のために見る画面かを決めることでした。そのせいで、作った後にどう判断し、どう動くかまで見えていなかったのだと思います。

まとめ

Looker Studioで作ったKPIサマリーは、結局のところ、ほとんど使っていませんでした。

GA4、GSC、Notionを使いながら数値の確認はしていました。ただ、Looker Studioで作ったKPIサマリーは、普段の確認や週次報告の流れにうまく乗っていませんでした。

このシリーズでは、過去に書いた記事を振り返りながら、自分が作ったKPIサマリーを改善していく過程を記録します。「ダッシュボードを作ったけど、活用できていない」という方が、見直すきっかけになればと思います。

著者

名前：minoRi

Tableau Certified Data Analyst（2025年4月取得）。社内にサポートのない環境でTableauを独学で使い、実務でダッシュボード構築を経験しました。Looker Studioも同じ感覚で触れましたが、作れることと活用できることは違いました。