![見出し画像](https://assets.st-note.com/production/uploads/images/28943851/rectangle_large_type_2_47de61f456bf9a365adb4b996f6667c1.png?width=1200)
翻訳としてのデータ分析#25 データの主役のバイオリズムに合わせる
原文抜粋 : 誤訳が多いhurt
ほとんどの人が間違えていたのはこの You’re hurting the baby の意味ね。赤ん坊が「怪我する」とか「傷つけてる」って訳してる人が多かったけど、そうじゃなくて hurt は「痛い」あるいは「痛くさせる」っていうこと。
たとえば注射のときに「痛い?」は Does it hurt? と言う。「痛い」のいちばん一般的な言い方です。だからこれ、「赤ん坊が痛がってるでしょ」
『ぼくは翻訳についてこう考えています -柴田元幸の意見100-』より
データ分析に置き換えて考える
「みんな考えたことなさそうだけど、これは広まってもいいんじゃないかな」と思ったことに、日付を4時区切りにする、というのがある。
かつて働いていたところで、業界慣習で午前4時を日付変更基準としている場所があった。ちなみにそこでは、0時〜3時を24時〜27時と呼ぶことが多かった。
午前4時区切りのいいことなのだが。
エンタメを扱うWebサービスは、午前0時付近でアクセス量(およびユーザ数や売上)のピークを迎えることが多い。
0時にコンテンツを更新したり、施策を実施するならば、それでいい。でも実際には日中が多い。我々の労働する時間帯からいって、しょうがない。
その場合に、0時で日付を区切ると「集計基準日」と「ユーザの体感日」が乖離しやすい。毎日夕方にコンテンツを追加するサービスがあったとして、特定の1日に、前日の影響と当日の影響が混在しやすくなる。
例えばだけど、雑誌メディアサイトで金曜日に追加された記事を、日が変わってから読んだ場合、その人の意識としては「金曜日に読んでいる」だろう。メディア側も「金曜日に追加したものを読んでもらった」と考えたいだろう。でも実態としては、土曜日に算入されてしまう。そして土曜日は土曜日で、また何か別の記事が追加される。
つまり0時で日付を切り替える場合、ざっくり
6月20日(土)のユーザ数
= 6月19日(金)の更新を見にきた3割のユーザ
+ 6月20日(土)の更新を見にきた7割のユーザ
のようなイメージとなる。一方、午前4時で日付を切り替えると、
6月20日(土)のユーザ数
= 6月19日(金)の更新を見にきた1割のユーザ
+ 6月29日(土)の更新を見にきた9割のユーザ
のイメージだ。当日見れなくて、翌朝以降見にくるユーザはどうしても一定数いるため、1割と書いた。
飽くまでもイメージだが、まあ、そんな風に、午前4時で日付をまたいだ方が、0時でまたぐよりも、見たいものが見やすくなるサービスは案外多いと思う。
昔は計算速度の制約などから、0時を過ぎて、早めに日次のデータマートをつくる処理を走らせないと、朝までにグラフの更新が間に合わず、偉い人からドヤされたかもしれない。
でも最近は、そこら辺はかなり進歩しているので、4時から始めても間に合いやすい。
まあ、0時基準でも不便なケースはそこまで多くない。逆に4時基準に変えようとすると各方面への説明の手間はかかるし、集計も誤りやすい。
ただ。
データの主役のバイオリズムに合わせる、という観点はあってもいいと思っている。無闇にカレンダーに合わせるのでなく、ユーザとサービス運営者の体感時間にあった計測周期を意識できる自分でありたい。
いいなと思ったら応援しよう!
![阿部 昌利](https://assets.st-note.com/production/uploads/images/24535675/profile_d617b05fcbfa9c283aaaf2e68bfb7f76.jpg?width=600&crop=1:1,smart)