データ補正という話

オリジナルデータの信憑性です。オリジナルデータがダメダメならば、
どんなにすごい分析結果がみえても全く意味をなしませんね。
我々はまず以下について慎重に吟味し、すべてOKで初めて次のステップに
進むことになります。

 そのデータソースは信頼できるのか?
母集団の定義は?
サンプリングに問題は無いか?
設問設計に問題は無いか?
ウェイトバックは適当か?(適用されている場合)

時として、サンプリングやデータの取り方に不備があり、かつ再調査ができないときも
あります。そんなとき、「そんなデータは使わない方がまし」という考えももちろん
ありますが、「精度は低くても考えうる限りのデータ修正/補正をして使えるものは
使おうよ」ということもよくあります。
補正をするにあたり、本来の数値がわからないのですから、補正の方法についてどれが
正解かもわかりません。私もその都度工夫しながらやっています。

<<おせっかいですが、勝手に補正してみます>>
(当該キャンペーンはまったく当研究所は関与していませんし、この件で連絡もしていません。
問題がございましたらすぐに削除するので、ご連絡ください。)

1週間ほど前から私の通勤路でファッションビルのキャンペーンが行われています。
様々な服を着たモデルさんの大きな写真が20枚、
そこに実際に押すことのできる「いいね!」ボタンがカウンターとともについています。
そして通りがかりのオーディエンスが気に入ったコーディネートに”いいね”するという仕組みです。

もちろんFacebookにも連動したページがありました。現在のカウンター数値もここで確認できます。OOHの上段がFacebookでは左列。OOHの向かって左側から右の並び順がFacebookでは上から下に並んでいます。
http://www.facebook.com/lumine.yurakucho?sk=app_163787417033168

OOH設置の方を見ていたときに、ちょっと気になりました。
上段にくらべて下段の方が明らかにカウンター数値が高いのです(Facebookでは右列)。
ぱっと見は2倍弱くらい高いようです。さらに真ん中より外側の方が若干高いようにも感じます。
そこで、しばらく人の動きを観察してみたところ、キャンペーンターゲットと思われる20代(前半〜中盤)女性が立ち止まって見たり、ボタンを押してもいましたが、
 ・ボタンに気づいたひとがポスターを見ずに「なんだこりゃ?」な感じで押しまくり
・子供が「わーーーーー」っていいながら端から走りながら押しまくり

な光景も多く見られました。
確かに、上段ボタンは子供にも、背の低めの方にも押しにくい位置にあります。

私は全然関係はないのですが、本来の数値はどんなものなのか見てみたくなりました。
というわけで、”勝手に補正”やってみます。

まず、上下の補正を考えます。
実際のカウンターの数値を拾ってきて、上段下段の比をそれぞれ計算してみました。
簡単ではありますが、その比の平均(1.92)を上下補正値とします

次に、真ん中〜はじっこ補正です。
今回は、回帰曲線を書いてそれがノイズが無かった場合の値とし
回帰曲線からはずれている分は実際に獲得した「いいね」だと仮定してみました。

まず上段の数値を右半分、左半分に分け、真ん中を1〜外側を5として
並び替えました。

平均をとって、エクセル上で回帰曲線を書きます。
決定係数が最も高かったのが、指数関数で、
y=6085.3e^0.0591x
R^2=0.84なのでまあまあアリとしましょう。

この式から、各位置が持つボタンの押されやすさ度合いが
計算されます。これを基準値(上段の)と呼ぶ事にします。

全く同じ写真が貼られていた場合に、写真の位置によって
カウンター数値がこのようになるのではという理論値です。

この基準値に、上下補正値をかけ算すると、
下段基準値が算出されます。

基準は8000カウントなのに観測値が9000なら
その1000分が他よりも「本当にいいね」されたものだと
考えることができます。

次に実際の観測値と基準値を割り算すると、
基準に対してのブレがでてきます。
(割り算でなく引き算も考えられます)

さらに観測値全体の平均10648をかけ算すると
補正が完了したカウンター値が算出されます。

この値と実際の写真を見比べてみましょう。
どうでしょうか???

さぁ、分析の準備が整いました!!
そうです、ここからが分析の本番です!!
今回はここまでの話ですが。。。

こんなことも書いたもの、不真面目な数字遊びのつもりではないんです。
かつては、きちんとした目的の下、きちんとした調査設計が行われて、ほぼきれいなデータが取得され、実査前から予定していた分析軸で集計し、統計解析しということを行っていました。しかし、Web系のデータを扱うようになってから”予定通り”のものはほぼありません。アドホックで行う分析の場合、まず文字コードやデータ形式の変換から、システムバグと思われるものの修正、マスタにないデータの処理、なんかは必ず発生します。これら前処理の前処理みたいなもので相当な時間を使う事が多いです。
そして、結構きれいなデータになってきてから今回のような補正が発生することが多いです。もうこのあたりで挫折する方も多いのではと想像します。

分析前のこの補正の作業でもすでにアイデアやセンスが必要です。今回の補正も一つのアイデアです。ご参考になれば。

Written by