毎日、週間、月間の集計

ホーム » Salescast » このページ

日、週または月によってのデータ集約の概念は、日、週、月のそれぞれの定義から始まる、いくつかの微妙な問題を提起します。ここでは入力レベル（過去のデータ）および、出力レベル（予測データ）の両方で、集計に対処するためSalescastで採択しているアプローチについて解説します。また、異なる状況下での、データ集計の規則に対処する方法についてもガイダンスします。

用語: アイテムおよび注文    Salescastにより定義される集計    入力集約パターンの許容範囲       非集約の生の履歴       週間または月間の事前集約履歴    予測の開始時       週間または月間の集計データ       将来データのサニタイジング、データ中心観点の例外    オルタナティブな月間または週間集計

用語: アイテムおよび注文

アイテムおよび注文という用語は、Salescastの入力データフォーマット（英文）にて言及されています。ここでは、Salescastによって定義された用語として理解していただきたいと思います。アイテムとは予測すべき対象を意味します。アイテムは文脈に応じて、商品、製品、SKU、バーコードとなります。一方、注文とは、過去のある特定日におけるアイテムに関する量を示します。注文は文脈に応じて、販売、出荷、消費となります。

Salescastにより定義される集計

Salescastは以下のような規則に準じています。

• 一日の開始時間は00h00。従い、毎日の予測値は00h00から開始し、23h59:59に終了する期間をカバーしています。
• 週は月曜から開始。従い、毎週の予測値は月曜日（含む）から日曜日（含む）終了までの期間をカバーしています。
• 月は、月の第一日目から開始。従い、毎月の予測値は月の第一日目から月の最終日終了までの期間をカバーしています。
  

この規則はSalescastにて変更することはできません。しかし、企業によっては必要とされる他の規則にどう対処するかについて、以下解説します。

入力集約パターンの許容範囲

Salescastは履歴データを処理するにあたり、寛容であろうとします。特に、毎日の集計法を採用するように、つまり、特定のアイテムにつき、特定の日において、すべての注文をその日の一つの量としてとりまとめてしまうことを勧誘してはいますが、そのほかの状況もSalescastは対応できえます。

非集約の生の履歴

毎日集計することでSalescastへアップロードするデータセットの規模は削減されます。この削減は予測の精度の観点からは何の遜色をももたらしません。しかし、最初からデータベースが比較的小規模であれば、これにより得ることは、ほぼ目に見えない程度です。またSalescastは、完全に集約されていない履歴データを取引ごとに1行を使って、処理することができます。この場合、毎日の量は特定のアイテムおよび特定の日の注文値の合計として算出されます。

週間または月間の事前集約履歴

入力データが発信されるはずの企業のシステムに、週間または月間の集約データのみが保存されていて、毎日の集約履歴データが保存されていない場合が時々見受けられます。Salescastは週間または月間の事前集約注文を処理することができます。 もしもデータが週間集計されるのであれば、Salescastは週間の従来型予測にての対応に限定されます。同様に、もしもデータが月間集計されるのであれば、Salescastは月間の従来型予測にての対応に限定されます。

事前集計データの主な欠点は、作成された予測の特徴が制約されるというところにあります。また、他の欠点として、予測精度に若干の損失が見られるところです。ただSalescastは、毎日のパターンを活用して、週間あるいは月間の予測を洗練することができます。

予測の開始時

予測を作成するにあたり、現在を意味する出発点、つまり、予測の開始日を定義します。この出発点を算出するために、Salescastは主にデータ中心の観点を導入しております。つまり、予測は履歴データが終了する時に開始となります。例えば、もしも履歴データが5月15日（含む）に終了するのであれば、毎日の予測は翌日、5月16日に開始することになります。

データ中心の観点は、特にベンチマークするにあたり、便利となります。データは過去のどこかで切り捨てることができます。予測はそれ自体が過去の一部であることからも、Salescastは（途中で切り捨てられていない）履歴データと比較できる予測を作成します。

具体的に、従来型毎日予測およびクォンタイル予測は同じような動きを示します。予測は、入力データ上において、最も直近の注文がなされた翌日から常に開始となります。

従来型の週刊予測または従来型の月間予測の場合、状況はより微妙になります。例えば、履歴データ（つまり、Salescastの用語によれば、注文）が5月15日に終わったとします。予測は5月1日からの開始となるでしょうか、6月1日からの開始となるでしょうか。Salescastの回答によれば、予測は5月1日から開始となります。5月のデータは未だ一部しかないのですから、Salescastは4月の最終日までのデータを切り捨てたのです。そうして、通常(*)の従来型月間予測として5月分が作成されることになるのです。

(*) 技術的に、部分的期間のデータを利用して予測モデルをデザインすることは可能です。しかしながら、そうすることで複雑な予測機能となり、現段階ではSalescastでのサポートはされていません。

週間または月間の集計データ

週間（または月間）の集計データの場合、Salescastの切り捨て動作が意図しない結果となることもあります。たとえば、月間集計された履歴注文があり、一つの 注文が月の第一日目になされているとします。 2013年5月1日が履歴データの最終日としましょう。この場合、Salescastは5月は一部のみ観察されたと解釈します。従って、5月は切り捨てられ、予測は5月1日から開始となります。5月1日が5月全体を代表することになるのですから、これは意図された動作とはいえません。

切り捨てを回避するには、現在の月の最後の日に注文ラインを一行設け、注文量をゼロとすることをお勧めします。この例の場合ですと、5月31日に注文ラインを設けることで、Salescastは5月の月が完了したことが分かることになります。従い、予測は6月1日からの開始となります。同様に、注文量をゼロとした注文ラインを挿入することは、週刊予測の類似懸念に対する対処法ともなります。

将来データのサニタイジング、データ中心観点の例外

データ中心観点の例外が一つ。サニティチェックとして、Salescastは将来一週間以上の日付となる'注文を検出します。（ここで将来とは、Salescastが稼働している機械のサーバーのクロックがベースとなり決められています）。

日常的に、ご自分のシステムから幾分かの通り将来の日付の'アーティファクト（信号エラー）を最終的に抽出することになるお客様が見られます。これは主に本来の販売や出荷ではなく、企業システムで、ある段階でなされたテストの結果であることが往々にしてあります。

事業の観点からは、未だ存在さえしていない履歴データに依存することは何ら意味をなさないことは確かです。よって、Salescastはこのデータをデータサニタイジング処理の一環として切り捨て、その後予測処理を再開します。

オルタナティブな月間または週間集計

Salescastの観点からは、月間は常に月の第一日目から開始となります。しかしながら、企業によっては、月間が月の第25日目から開始するところもあり、別の規則に従っているところもあります。

この様な状況に対応するべく、目標する期間に対して注文履歴を事前集計することをお勧めします。先ほどの場合では、5月25日から6月24日までの期間のデータは一つの注文ラインに集約すべきとなります。そして、このラインはアイテムのカスタム化された月間値となり、従来レンジに対して事前の月間の第一日目として位置づけされることになります（この場合ですと、5月1日）。そうすれば、Salescastは元来の規則に基づいた月間の第一日目、この場合は月の第25日目より予測を開始します。