不正値を検知する

不正値は自分で検知する

仕組みがおかしいならばエンジニアに直してもらいたいところ。しかし、いくらしっかり作ってもらったとしても実装ミスやシステムトラブルは起きる。

なので整備側でも不正値を検知する手段は持っておくべきだ。全部は無理でも検知できるところはしておきたい。

そこで、以前に検知する仕組みを作ったことがあるか、今後必要に応じて作るだろう項目を以下に書いてみる。

月ごとのデータを見ていて何かおかしいと思ったら途中で数日データがごっそり抜けていたりする。

チェックするテーブルを集計してもないものは出てこない。短い期間なら日別に集計して目検でもいいがそれだけでは仕組みとしては少々心もとない。

そこで、別に日付のマスタを作ってjoinする。nullが出てきたらその日のレコードがない。

毎日100万PVあるのにその日だけ100PVしかなかったらすぐわかる。しかし、ちょっと抜けているだけだと気づくのが難しい。

前日比だと平日と土日のトレンドの違いで都度ひっかかる。前週の同曜日と比較する方がいいだろう。

distinctをとっておけばいいじゃないかと思うかもしれない。しかし更新時間だけ違ってあとは同じレコードが発生することがある。レコード単位では重複にならないためdistinctでは重複を除けない。

「重複にならない単位でみたらどうか」が重要。その単位で集計して2レコード以上出てきたら重複だ。

区分値が1と2しかないはずなのに3がある、年齢なのにマイナスや200がある、日付が遥か未来あるいは過去になっている。

これは指定した値か、範囲内かを直接指定すればわかる。nullが正しいかどうかは事前に確認しておくこと。

別にマスタがある場合はマスタをjoinする。マスタにない値が存在するとnullがでてくる。

nullが出てきてもそのまま不正値とは限らない。実装はされたがマスタが更新されていないこともある。この場合は正しい値だがnullになってしまう。

なのでマスタを先に確認した方がいい。しかしどこで誰が更新しているかすぐわからないなら先にjoinしてみて一致しない値が出たら確認する方が早いこともある。

全ての不正値を無くしたいが、それは実際には無理。なので不正値の許容範囲を決め、基準値以下なら不正値と見なさない方法もある。

日単位で考えるとする。その日のレコードに不正値かのフラグを立てる。あとはフラグの数／レコード数で比率をだしてこれが決めた値かどうかを見る。

検知もぱっと思いついたのを書いてみたけどまだあるはず。思いついたら追記していく。

さて、今回は不正値を検知する方法だけを書いてどう直すかには触れなかった。

その理由は２つある。１つは検知できるのは「不正値の可能性がある」までだからだ。検知しても不正値だとは限らない。なのでまず「本当に不正値なのか、それ以外の理由か」を確かめる必要がある。

ある日の売上0円でも開店直後や特定のセグメントに絞っていればありえる。PVが急増や急減はシステムエラーによる重複や欠損ではなく、外部環境の影響かもしれない。そういった要因を検討しなければならない。

もう１つは「不正値だったとして仕組みを直すか、整理で吸収するか、そのままにしておくか」を決める段階がある。検知する仕組みは自動化できても整理はできない。コストや費用対効果も絡んでくる。

つまり、検知してから整理するのはまったく別の話なのだ。その話はまた今度まとめる。