「サービスを提供するためのデータ」と「解析に適したデータ」の違い

過去の記事で何度か「サービスを提供するためのデータ」が「解析に適したデータ」と違うという話をしました。
今回は、実際に解析するとき困ったことがある上書きされたデータ・圧縮されたデータ・曖昧なデータという3つの事例を紹介しようと思います。

上書きされたデータ: 過去の商品価格のデータが残ってない

商品価格などのマスターデータを上書きしてしまっているサービスをよく見かけます。
サービス運用上、紛らわしいデータを残しておくとデータを引っ張る時に無意味に複雑なクエリを書く必要が出てきます。そのため、データベースをできるだけシンプルに保ち、サービス運用に関係のあるデータだけを保持するような設計をすることがあります。
商品価格のマスターデータを直接上書きするのもその一つとなります。
マスターデータを上書きをすることでシンプルな構造を保つことはできます。しかし、一度上書きをしてしまうと上書きしてしまったデータを戻すことは困難になります。
上書きとは、新しいデータを残すのと同時に過去の似たようなデータを消していく作業となります。過去データを利用して何かをする目的が入った作業ではありません。
顧客の購買行動を分析するとき、購入した時点での価格が必要となります。このとき、マスターデータを上書きしてしまう構造になっていると、どの価格で顧客が購買したかを辿りづらくなってしまいます。
商品データは売上に直結しているので購買時価格を保存していることは多いですが、関連した話として顧客属性の変化も上書きされやすい項目となります。
どの段階の属性のときに何をしたかの情報は、属性に合わせた施策考える時の分析に必要となります。
どのようにデータの変化を管理するかに関しては様々な方法がありますが、データを上書きしてしまう前に、変化を知る必要があるデータであればログを残すようにしましょう。

圧縮されたデータ: 解約会員がいつやめたか日時情報がない

会員が解約したときに、会員情報を削除もしくは停止すればサービス上は問題ありません。多くの場合、解約会員はdisableフラグなどを用意して管理していると思います。つまり、退会したという情報が、disableされたかどうかの2値に情報量が圧縮された状態で保存されてしまうということです。
しかし、解約会員データを解析するときに、会員がいつ解約したという情報が必要となります。disableフラグのみだといつ解約の日時情報がないため、どの月にどのくらい解約した会員がいるかを分析できなくなります。
この事例は、解約会員の人数を把握しようとしたときに分かるため、すぐシステム改変がされるものだと思います。一般に、データベースの構造の変更を後からするのは、最初から必要な項目を用意していたときより工数がかかります。
圧縮されたデータは圧縮前に戻すことが不可逆なことが多いです。
データを圧縮して保存して不都合が生じないか前もって考えるようにしましょう。

曖昧なデータ: ログにユーザIDが吐き出されていない

ユーザのアクセスログがサーバに残っているサービスは多いと思います。
しかし、どのユーザがアクセスしたログであるかを明示的にアクセスログに残していない場合があります。
どのページでエラーが起きたかを検知するだけなら、個々のユーザを気にしなくてもよいため、このアクセスログで十分かもしれません。
しかし、このデータでは、ユーザごとにアクセスログを集計して、ユーザごとのアクセスするページの傾向を出すことができません。ユーザIDがログに残されていないため、どのログがどのユーザのログか判別ができないということです。
このようにデータが残っていても、複数のデータが混ざりデータを判別することができないことで分析するときに制限がかかってしまいます。
このような事象も解析時に初めて判明することが多いです。
解析では、データをグループ分けをし分析することで、グループごとの傾向の差を見ていきます。しかし、今回のユーザ単位でのグループ分けができなくなっている事象と同様に、様々な単位でグループ分けをできなくしてしまうデータの曖昧性を仕込んでしまっていることがあります。
ログだけに限らず、複数のデータが一緒のものとなってグループ分けできないように、グループ分けのキーとなるようなデータを残すようにしましょう。

まとめ

今回は、データ解析しようとして困るデータの保存の仕方3つを紹介しました。
事前にこのようなものは防げると思う人も多いと思いますが、意外と最初の設計から漏れてしまっている企業が多いです。
データが上書きされている部分、情報量が圧縮されている部分、情報は出ているが曖昧性が残っている部分、それぞれを自社のデータと照らし合わせながらぜひ一度確認してみてください。