最大の難関はシステム連携（部署間調整・ベンダー調整）
何を測定するか検討し、さあデータ取得をしようとすると、次に別の課題が発生します。それぞれのデータを保有・蓄積しているシステムが別々となっているのです。
先に挙げた3つの指標をデータとして取得するなら、以下のような要件を、現状のシステムの環境や制約条件を鑑みながら検討する必要があります。
1.プッシュ通知によるアプリ起動、ECの閲覧
- システム要件：プッシュ通知から起動、当該のページを表示させた事を記録する。外部URL（ECページ）を表示した事を記録する。
- 課題：一連の行動として紐付けることは、プッシュ通知に特定のパッケージを利用していた場合に可能なのか？
2.アプリからECへの新規会員登録
- システム要件：EC側で「アプリからのアクセス」であることを関知させる。会員DBにも、「アプリから登録した」ことを記録する。
- 課題：アプリからのアクセスを判別することは可能か？
3.お気に入り登録された商品を店舗で購買しているのか
- システム要件： ECのお気に入り登録データと購買情報を突合し、店舗システムからバックエンドにデータを送信し、ECと共有する。
- 課題：店舗システムでは会員バーコード以外の情報を取得送信することは可能か？
取得したいデータの素材が、複数のシステムに散らばっていたり、取得経路がまたがっていることにより、出力が難しいケースがあります。システムの一部にパッケージを導入している場合や、店舗システムのようにセキュアなシステムとの連携が必要な場合は、特にこのような事が起こりえます。
こういった課題に直面した方も多いのではないでしょうか。まさに文字通り、一筋縄にいかない課題です。
これは、第1回記事でも記述しましたが、「マルチベンダー体制」という状況から生まれる課題で、各担当者、各ベンダーとのコミュニケーションが重要になります。この課題に向き合いながら、データを揃えたレポートへと整形していきます。
ここで気を付けるべきことは、完璧な出力を目指してはいけない。ということです。最終的なレポートが全て、自動連携、自動出力されている必要はなく、各セクションの報告数値を結合、整理する作業の発生は許容するべきと考えます。
全自動のレポート化は、システムが複雑化しやすく、後に別の要件が発生した際に改修の難易度も上がり、その分のシステム投資が発生してしまいます。
そのため、「各セクションごとの生データを出力さえできれば、あとは自分でレポートを作成する」という心構えの方がよいと思います。その方が、自ら主体的にデータに向き合う時間が作れますし、作業内に気づきも得られるでしょう。
この心構えを持ち、測定データの出力のための調整を行いましょう。
また、レポートが運用できるようになったら、第2回記事の運用設計にもとづき定期ルールとすることで、全社的なナレッジとすることができます。
