プロセスモデルからデータ計測と分析を捉える重要性
デジタルエクスペリエンスを考えたり、整えていくプロジェクトの中で、よくぶつかる悩みとして、「データってどんなものを集めればいいんですか？」ということがあります。
必ずビジネス目的を確認するところから
こうしたケースの場合、私の場合だと目的からブレイクダウンし、ほしいデータを特定していくということを行います。ざっくりとしたイメージで表すと以下の通り。
こうした整理をすると、実はデータは揃っているケースが多く、そんなに気にしなくてもよかったということがよくあります。
だが、現実はそんなに甘くない
一方で、「何かの役に立つかもしれないので、どんなデータをとればいいですかね？」という質問返しのような状況になる場面も多々あります。こうしたケースはいつも頭を悩まし、「正直知らんがな」、と思うこともしばしば。
ただし、それでは依頼主の問題解決にはなっていないので、それなりの軸をつくって、レコメンデーションするということが、仕事においては必要です（本質じゃないんだけどな、と思いながら・・・）。
デジタルエクスペリエンスのデータモデル（CEDDL）
世の中を見渡すと、こうしたデジタルエクスペリエンスに関するデータを集める標準化を考える組織が存在しています。W3Cの中で、Customer Experience Digital Data Layer (CEDDL)というモデルでデジタルエクスペリエンスに関するデータを集める標準化が考えられています。
CEDDLに関する情報はコチラ
https://www.w3.org/community/ceddl-webspec/
さて、このCEDDLを調べると、以下のようなデータを取ることが推奨とされているようです。
この図を見るとたしかにな、と思う一方で、本当にこれだけ？と思う方もいらっしゃると思います。この疑問に関しては、デジタルエクスペリエンスという根本に立ち返り、ユーザーがコンテンツに触れるプロセスで構造を考えてみることをおすすめします。
コンテンツ体験プロセスを分解すれば必要なデータが構造化できる
私の場合、以下のようなモデルでCEDDLの妥当性を腹落ちさせるようにしています。
各プロセスで主役になる「情報」に関する切り口として、「5W1Hのフレーム」を用いることで、必要なデータは揃えられるのではないかと思います（結果としてCEDDLで網羅されているデータ集とほぼ同じになる）。
ユーザー情報
これは体験を受け取るユーザーの情報そのものです。ここは会員システムを構築してユーザーを管理する際に必要となる場面が多いですね。集めるべき情報は構築システム側である程度、型が決まっていると思うので、そこに従っていれば概ね外すことはないでしょう。
ちなみに、Adobe AnalyticsやAdobe Targetのようなウェブ行動体験では、ユーザーIDだけをまずは収集し、後にIDに紐づく属性を追加して施策や分析を行いましょうというデータの使い方をします。
デバイス情報
体験で使われるデバイス、すなわちデスクトップやスマートフォンといった端末の情報です。ユーザー情報のようなIDの代わりとなる「基本情報」は、Cookie IDが該当します。昨今では、このCookie IDがすぐに消えてしまったりするため、長期間に渡って一意のユーザーだよね、とすることが難しくなるトレンドがあります。とはいえ、うまくユーザ情報とひも付きさえすればユーザーごとの体験を行うことが可能です。
デバイス情報でも、「動機・目的の切り口？」となる方もいらっしゃるかと思います。これは、そのデバイスを使う目的は？と代替思考をしてもらえるとよいでしょう。BtoBのサイトをあえてスマホで見るというのはどういう動機からなのか、BtoCのサイトでパソコンを使って購入検討をするというのはどういう動機なのか、をデータ属性値として付与すると分析の幅が広がります。
ページ（画面）情報
図中にて、受け皿という考え方を用いています。概念的ではありますが、デジタルコンテンツは、ページや画面スクリーンそのものはあくまでも入れ物でしかありません。レイアウトで区切られたスペースに機能やコンテンツが入ることによって、ページが成り立っているという考え方です。
昨今ではページは固定で中身だけが変わるSingle Page Applicationという構成も増えてきています。その際、ページとコンテンツを分けて考える習慣があれば、コンテンツ計測につまずくことはなくなると思っています。
ページを受け皿として考えるアプローチは、コーポレートサイトのデザイン管理をする上でも、情報設計をする上でも重要な考え方になります。入れ物としての画面パターンはどれだけ必要なのか、をまずは決めて、その後１つ１つの仕切りに入る機能・コンテンツを考えるということができれば、バラバラなウェブサイトやアプリになることを防ぐことが出来ます。
コンポーネント情報
何かしらの機能を提供する部品群と捉えてもらえるとよいです。
デジタルコンテンツに埋め込まれている、動画再生プレイヤーや音楽再生プレイヤーはコンポーネントの良い例です。動画や音声自体を流し込むViewer機能、再生・停止・早送りボタン等々の機能、こうした機能がまとまったものが動画再生コンポーネントとなります。
こうした記事も、「イメージとテキストのみで構成されたViewer機能」と捉えることができます。
コンポーネントを計測しておくことで、そのコンポーネントのパフォーマンスを分析したり、きちんとコーポレートサイト内で普及しているのか、といったガバナンス観点で分析を行うことが可能になります。
アクション情報
ユーザーが何かをした、という１つ１つの行動の情報です。私はこのアクション情報は常にコンポーネントと対で考えることを推奨しています。「機能」を「利用する行動」として体現できるからです。
先程の動画再生プレイヤーコンポーネントで考えると、Viewerの表示が視聴、再生ボタン⇛再生数、停止ボタン⇛停止数、と１つ１つのアクションはコンポーネントの機能に準じます。
コンバージョンアクションということも、コンポーネント機能からコンバージョンを考えなおすということができると、指標化として見えてくる発見があると思います。
コンテンツ情報
いわゆるコンテンツそのものです。動画ファイルや音声ファイル、テキストファイルの中身についてのメタ情報です。ECサイトであれば、製品情報に付帯する情報が該当します。コンテンツそのものに関する5W1Hはコミュニケーション設計時に考えるので、そのときの情報をそのまま付与すると企画意図がパフォーマンスを出せているのかという分析に直結できますね。
分析結果が「で？」とならないために
ここまでまとめた内容で、一通り「何かの役に立つかもしれないので、どんなデータをとればいいですかね？」には回答できる状態になっていると思いますが、問題はここからです。
データが揃えば、「それを分析にどうやって使うんですか？」と必ずなります。人とおりデータがそろっているのであれば、後はどんなことを知りたいかだけです。
ただ、いくらデータが揃っていたとしても、受託側の立場で難しいことがあります。
分析に耐えうる前提知識が求められるからです。前提の共有ができていなければ、データが揃い、分析レポートを作ったとしても、「で？」となることが多々あります。
分析以前から分析事後までのチェックポイントが、依頼主とマッチできるまではあまり分析作業自体をすすめることはおすすめしません。少なくとも、こうしたことが分析考察を考えるうえで必要なプロセスだよね、と共通認識を持った上で分析作業を着手することを推奨します。
ただ、残念ながらそれでもやって、となるケースはあります。そうした場合はもはや分析軸を打ち立てて、先に仮説を出す形ですすめる以外にありません。
私個人では分析案件の際に意識するポイントは以下のような用途として絞り込んで分析レポートをつくっていきます。
ここで出すべき仮説を特定し、分析対象のプロセスを明らかにするということを行います。
ここまでブレイクダウンすることができれば、「で？」となる分析にならず、何かしら課題発見につながるレポートをつくることができるはずです。
プロセスを押さえると見えてくるもの
私自身、カスタマージャーニーというコトバは好きではありません。デジタルエクスペリエンスを高度化するうえで、顧客体験も大切な一方で、提供する側の体験も整っていなければ、何も高度化しないと思っています。昨今、顧客起点で考える、という重要性を唱える方々が非常に多い一方、顧客体験をつくる側のプロセスがおざなりになっているように思えます。
デジタルエクスペリエンスは顧客だけのものではなく、関わる全ての人のもの。構造化やプロセス化を改めて行うことで見えてくる事実から、アクションを立て直していく、そのためにデータが必要なのである、という考え方が、もっと広まるといいなと思います。