JP2020077068A - 評価装置、評価方法およびプログラム - Google Patents

Abstract

【課題】イベントによる消費行動への影響を評価する評価装置、評価方法及びプログラムを提供する。【解決手段】評価装置２０（サーバ装置）は、イベントの評価を行う。イベントの前後におけるユーザの消費活動を示す消費活動情報を取得する消費活動情報取得部と、消費活動情報に基づいて消費活動のパターンを決定するパターン決定部と、消費活動のパターンに応じてイベントの評価を行う評価部とを備える。消費活動情報は、ユーザが操作するユーザ端末において実行されるアプリケーションプログラムに係るアプリ内課金情報を含む。【選択図】図３

Description

本発明は、評価装置、評価方法およびプログラムに関する。

広告等の施策を用いてアプリケーションの利用を促進することが行われている。施策の効果に応じて金銭が配分されると合理的であり、たとえば特許文献１には、サービスの提供に応じたユーザに対する課金額に基づいて、サービスで用いられる誘導先アプリケーションの提供者及びこの誘導先アプリケーションへとユーザを誘導した誘導元アプリケーションの提供者に対する配分額を設定するシステムが開示されている。

特許第５４７５１８０号明細書

しかしながら、特許文献１に記載のシステムでは、広告等の施策に反応して一時的に課金額が増えたのか、広告等の施策により消費活動が活発になったのかを判断することができない。

本発明はこのような背景を鑑みてなされたものであり、イベントによる消費行動への影響を評価することのできる技術を提供することを目的とする。

上記課題を解決するための本発明の主たる発明は、イベントの評価を行う装置であって、前記イベントの前後におけるユーザの消費活動を示す消費活動情報を取得する消費活動情報取得部と、前記消費活動情報に基づいて前記消費活動のパターンを決定するパターン決定部と、前記消費活動のパターンに応じて前記イベントの評価を行う評価部と、を備えることとする。

その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。

本発明によれば、イベントによる消費行動への影響を評価することができる。

本実施形態に係る行動分析システムの全体構成を示す図である。 本実施形態に係るサーバ装置２０のハードウェア構成例を示す図である。 本実施形態に係るサーバ装置２０のソフトウェア構成例を示す図である。 配信ログ記憶部２３１に記憶される配信ログの構成例を示す図である。 認証ログ記憶部２３２に記憶される認証ログの構成例を示す図である。 決済ログ記憶部２３３に記憶される決済ログの構成例を示す図である。 施策ログ記憶部２３４に記憶される施策ログの構成例を示す図である。 パターン記憶部２３５に記憶される標準パターンを説明する図である。 ユーザの消費パターンを分類した一例を示す図である。 サーバ装置２０が実行する評価処理の流れを説明する図である。 提案部２１８による施策の提案処理の流れを説明する図である。 施策の優良パターン比率および施策に対する提案の例を示す図である。

本発明の実施形態の内容を列記して説明する。本発明の実施の形態による評価装置は、以下のような構成を備える。

［項目１］
イベントの評価を行う装置であって、
前記イベントの前後におけるユーザの消費活動を示す消費活動情報を取得する消費活動情報取得部と、
前記消費活動情報に基づいて前記消費活動のパターンを決定するパターン決定部と、
前記消費活動のパターンに応じて前記イベントの評価を行う評価部と、
を備えることを特徴とする評価装置。
［項目２］
項目１に記載の評価装置であって、
前記消費活動情報は、前記ユーザが操作するユーザ端末において実行されるアプリケーションプログラムに係るアプリ内課金情報を含むこと、
を特徴とする評価装置。
［項目３］
項目１または２に記載の評価装置であって、
標準となる前記消費活動のパターンである標準パターンを複数記憶するパターン記憶部を備え、
前記パターン決定部は、前記消費活動情報を前記標準パターンと比較して、前記標準パターンのいずれかにクラスタリングすること、
を特徴とする評価装置。
［項目４］
項目３に記載の評価装置であって、
前記標準パターンには少なくとも、前記ユーザによる消費金額が経時的に上がる第１パターンと、前記消費金額が経時的に下がる第２パターンとが含まれること、
を特徴とする評価装置。
［項目５］
項目３または４に記載の評価装置であって、
前記標準パターンには、評価の高い高評価パターンが含まれ、
前記パターン決定部は、前記ユーザごとに前記消費活動のパターンを取得し、
前記評価部は、前記高評価パターンにクラスタリングされた前記ユーザの数に応じて前記イベントの評価を行うこと、
を特徴とする評価装置。
［項目６］
項目５に記載の評価装置であって、
前記消費活動情報取得部は、複数の前記イベントのそれぞれについて前記消費活動情報を取得し、
前記パターン決定部は、前記イベントおよび前記ユーザごとに前記消費活動のパターンを取得し、
前記評価部は、前記イベントごとに、前記高評価パターンにクラスタリングされた前記ユーザの数である高評価数に応じて前記イベントの評価を行い、
前記高評価数応じて、今後実施する前記イベントの内容についての提案を行う提案部をさらに備えること、
を特徴とする評価装置。
［項目７］
項目６に記載の評価装置であって、
前記提案部は、前記高評価数に応じて、再度同一の前記イベントを実施すべき旨、他で実施された前記イベントを実施すべき旨、および改善した前記イベントを実施すべき旨の少なくともいずれかを出力すること、
を特徴とする評価装置。
［項目８］
イベントの評価を行う評価方法であって、
評価装置が、
前記イベントの前後におけるユーザの消費活動を示す消費活動情報を取得する消費活動情報取得ステップと、
前記消費活動情報に基づいて前記消費活動のパターンを決定するパターン決定ステップと、
前記消費活動のパターンに応じて前記イベントの評価を行う評価ステップと、
を実行することを特徴とする評価方法。
［項目９］
イベントの評価を行うためのプログラムであって、
評価装置を、
前記イベントの前後におけるユーザの消費活動を示す消費活動情報を取得する消費活動情報取得部、
前記消費活動情報に基づいて前記消費活動のパターンを決定するパターン決定部、
前記消費活動のパターンに応じて前記イベントの評価を行う評価部、
として機能させることを特徴とするプログラム。

図１は、本実施形態に係る施策評価システムの全体構成を示す図である。本実施形態の施策評価システムは、サーバ装置２０を含んで構成される。サーバ装置２０は、ユーザ端末１０と通信回線３０を介して通信可能に接続される。通信回線３０は、たとえばインターネットであり、公衆電話回線網や携帯電話回線網、無線通信路、イーサネット（登録商標）などにより構築される。

ユーザ端末１０は、ユーザが操作するコンピュータであり、本実施形態では、スマートフォンあるいはタブレットコンピュータを想定している。ユーザ端末１０は、アプリケーションプログラム（以下、アプリと略記する。）をダウンロードしてインストールし、アプリを実行することにより様々な機能を実現する。ユーザ端末１０がダウンロードして実行するアプリには、たとえばゲームが含まれる。

サーバ装置２０は、アプリを配信するコンピュータであり、たとえば１台または複数台のパーソナルコンピュータやワークステーションなどにより実現される。サーバ２０は、アプリをユーザ端末１０に配信するとともに、ユーザ端末１０において実行されるアプリに対して各種のサービスを提供する。たとえば、サーバ装置２０は、ユーザ名およびパスワード、指紋、虹彩、顔画像などの認証情報に基づいてユーザの認証を行うサービスや、メッセージの送受信、データの保存などの機能を提供する。

本実施形態の施策評価システムは、アプリの提供者が実施するイベントを評価しようとするものである。本発明におけるイベントとは、ゲーム、ＳＮＳ、エンターテインメント、ビジネス、ユーティリティ、ライフスタイル、仕事効率化、ヘルスケア、ファイナンス、ファッション、食事、ブック、ミュージック、旅行、教育、スポーツなどのインターネットを通じて提供されるまたはアプリケーションによって提供されるサービスに対する施策である。たとえば、ゲームサービスにおけるイベントは、定期、不定期にかかわらず実施され、ユーザ単独またはユーザ同士が対戦または協力をして、ゲームにおける得点またはアイテム等を獲得する施策などが一例として挙げられる。他にもイベントとしては、たとえば広告を出すこと、スタンプラリーを行うこと、２つのアプリのコラボにより互いに送客するように誘導することなど、アプリの利用を促進させるべく行う施策がありうる。本実施形態では、サーバ装置２０が、ユーザによるアプリを使用した消費活動のパターンに応じて施策の評価を行う。なお、本実施形態では、消費活動とは、ユーザが何らかの金銭の支払をしたこと（ユーザに対して何らかの課金を行ったこと）であるものとする。たとえば、アプリ内においてユーザが各種のアイテムやサービスの対価の支払を行うアプリ内課金を行ったことや、サーバ装置２０が提供する、アイテム購入やサービス対価に用いることのできるコインの購入を行ったことなどが消費活動に含まれる。消費活動のパターンに応じた評価とは、詳細については後述するが、たとえば、施策の前に支払った金額よりも、施策後に支払った金額が増えた場合には高評価を与え、逆に施策の前に支払った金額よりも、施策後に支払った金額が減った場合には低評価を与えるような手法である。

図２は、本実施形態に係るサーバ装置２０のハードウェア構成例を示す図である。サーバ装置２０は、ＣＰＵ２０１、メモリ２０２、記憶装置２０３、通信インタフェース２０４、入力装置２０５、出力装置２０６を備える。記憶装置２０３は、各種のデータやプログラムを記憶する、例えばハードディスクドライブやソリッドステートドライブ、フラッシュメモリなどである。通信インタフェース２０４は、通信ネットワーク３０に接続するためのインタフェースであり、例えばイーサネット（登録商標）に接続するためのアダプタ、公衆電話回線網に接続するためのモデム、無線通信を行うための無線通信機、シリアル通信のためのＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）コネクタやＲＳ２３２Ｃコネクタなどである。入力装置２０５は、データを入力する、例えばキーボードやマウス、タッチパネル、ボタン、マイクロフォンなどである。出力装置２０６は、データを出力する、例えばディスプレイやプリンタ、スピーカなどである。

図３は、本実施形態に係るサーバ装置２０のソフトウェア構成例を示す図である。同図に示すように、サーバ装置２０は、アプリ配信部２１１、認証処理部２１２、決済処理部２１３、施策ログ登録部２１４、決済ログ取得部２１５、パターン決定部２１６、評価部２１７、提案部２１８、配信ログ記憶部２３１、認証ログ記憶部２３２、決済ログ記憶部２３３、施策ログ記憶部２３４、およびパターン記憶部２３５を備える。

なお、アプリ配信部２１１、認証処理部２１２、決済処理部２１３、施策ログ登録部２１４、決済ログ取得部２１５、パターン決定部２１６、評価部２１７、および提案部２１８は、サーバ装置２０が備えるＣＰＵ２０１が記憶装置２０３に記憶されているプログラムをメモリ２０２に読み出して実行することにより実現され、配信ログ記憶部２３１、認証ログ記憶部２３２、決済ログ記憶部２３３、施策ログ記憶部２３４、およびパターン記憶部２３５は、サーバ装置２０が備えるメモリ２０２および記憶装置２０３の少なくともいずれかが提供する記憶領域の一部として実現される。

配信ログ記憶部２３１は、アプリの配信履歴を示す情報（以下、配信ログという。）を記憶する。図４は、配信ログ記憶部２３１に記憶される配信ログの構成例を示す図である。同図に示すように、配信ログには、ユーザ端末１０に係るユーザを特定する情報（ユーザＩＤ）と、ユーザ端末１０に配信された（ダウンロードされた）アプリを特定する情報（アプリケーションＩＤ）と、アプリがユーザ端末１０に配信された（ダウンロードされた）日時（ダウンロード日時）とを含む。なお、配信ログには、たとえば、アプリのデータサイズや、アプリのダウンロード経路など、アプリの配信に係る各種の情報を含めるようにしてもよい。

認証ログ記憶部２３２は、ユーザの認証履歴を示す情報（以下、認証ログという。）を記憶する。図５は、認証ログ記憶部２３２に記憶される認証ログの構成例を示す図である。同図に示すように、認証ログには、認証を受けたユーザを特定するユーザＩＤと、認証サービスを利用したアプリを示すアプリケーションＩＤと、ログイン処理に成功した日時（ログイン日時）とを含む。なお、ログインに失敗した日時などを含めるようにしてもよい。

決済ログ記憶部２３３は、決済履歴を示す情報（以下、決済ログという。）を記憶する。図６は、決済ログ記憶部２３３に記憶される決済ログの構成例を示す図である。同図に示すように、決済ログには、決済処理を識別する情報（決済ＩＤ）と、決済を行ったユーザを示すユーザＩＤと、決済処理に関連するアプリを特定するアプリケーションＩＤと、決済処理を行った決済日時と、決済処理の内容を表す決済内容と、決済金額とが含まれる。なお、決済ログには、一般的な決済処理に関連する情報が含まれるものとする。本実施形態では、決済ログがユーザの消費活動を表す情報となる。

施策ログ記憶部２３４は、施策の履歴を示す情報（以下、施策ログという。）を記憶する。図７は、施策ログ記憶部２３４に記憶される施策ログの構成例を示す図である。同図に示すように、施策ログには、施策を行った主体を示す情報（ベンダーＩＤ）と、施策の対象となるアプリを示すアプリケーションＩＤと、施策を識別する情報（施策ＩＤ）と、施策が行われた月（施策実施月）と、施策内容を示す情報と、優良パターン比率とが含まれる。なお、施策実施月は日時を設定するようにしてもよい。また、施策の内容等、施策の実施に係る各種の情報を施策ログに含めるようにしてもよい。優良パターン比率とは、優良と評価された消費活動のパターンの出現率であり、詳細については後述する。

パターン記憶部２３５は、標準となる消費活動のパターン（以下、標準パターンという。）を記憶する。図８は、パターン記憶部２３５に記憶される標準パターンを説明する図である。同図に示すように、標準パターンには、優良パターン、不良パターン、およびその他パターンが含まれる。本実施形態では、消費活動のパターンは、施策実施月の前後所定期間（本実施形態では、２ヶ月とするが、１ヶ月、３ヶ月など任意の期間とすることができる。）における月別の決済金額の合計の推移であるものとする。

優良パターンとは、施策の後に消費（決済金額）が増えるパターンである。図８の例では、優良パターンとして、施策実施の翌月に決済金額が上昇し、２ヶ月後には減少しつつも、施策実施から１カ月前および２ヶ月前の水準と同等または増加しているパターン（パターン１）、施策の実施月およびその翌月には決済金額に大きな変化はなくとも、施策から２ヶ月後に決済金額が上昇しているパターン（パターン２）、ならびに、施策の実施月に決済金額が上昇し、その後２ヶ月も増加した決済金額を維持しているパターン（パターン３）が示されている。

不良パターンとは、施策の後に消費（決済金額）が減るパターンである。図８の例では、不良パターンとして、施策の実施月および１カ月後には決済金額に大きな変化がないものの、２ヶ月後には決済金額が下がっているパターン（パターン４）が示されている。

その他パターンとは、優良パターンおよび不良パターン以外のパターンである。図８の例では、施策の実施月のみ決済金額が増加し、１カ月後からは実施月の１か月前および２ヶ月前の水準に戻るパターン（パターン５）、施策の実施にかかわらず、施策の１か月前の決済金額の水準を維持しているパターン（パターン６）、ならびに、施策の１か月前に決済金額の増加が見られるものの、施策の２ヶ月前の水準を、施策の実施月から２ヶ月後まで維持しているパターン（パターン７）が示されている。

これらの標準パターンは、たとえば統計処理のクラスタリングにより抽出することができる。たとえば、決済ログに基づいてユーザごとに月別の決済金額を合計し、施策ログに基づいて、施策が行われた月（施策実施月）の２ヶ月前から２ヶ月後までの各月についての決済金額の合計額を経時的に並べたパターンについてクラスタリングを行う。上記図８に示す７つの標準パターンは、本願発明者らがクラスタリング分析により抽出したパターンである。クラスタリングにより求められたパターンのそれぞれについて、優良パターンであるか、不良パターンであるか、その他パターンであるかの判断はユーザにより行われ、その判断結果が与えられるものとする。クラスタリングにより求められたパターンは、優良パターン、不良パターンまたはその他パターンに分類されて、パターン記憶部２３５に登録される。

アプリ配信部２１１は、アプリをユーザ端末１０に配信する。アプリ配信部２１１は、たとえば、スマートフォンのオペレーティングシステムのメーカーが提供するアプリ配信プラットフォームに対してアプリを登録するようにすることができる。また、アプリ配信部２１１は、ユーザ端末１０に対してアプリを直接送信するようにすることもできる。アプリ配信部２１１は、配信したアプリについての配信ログを作成して配信ログ記憶部２３１に登録する。

認証処理部２１２は、ユーザの認証を行う。認証処理部２１２は、たとえばユーザ名とパスワード（またはハッシュ関数にパスワードを与えて求められる値）の組を記憶装置２０３に記憶しておき、ユーザ端末１０からユーザ名とパスワード（またはハッシュ関数にパスワードを与えて求められる値）とを比較することにより、ユーザの認証を行うことができる。なお、認証処理部２１２には、各種の公知の認証処理の方法を採用することが可能である。認証処理部２１２は、認証の結果を認証ログとして認証ログ記憶部２３３に登録する。

決済処理部２１３は、決済に関する処理を行う。決済処理は、たとえば、ユーザがアプリ内で使用可能なアイテムを購入する場合や、アプリ内で使うコインを購入する場合、アプリにおいて情報を閲覧するために対価を支払う場合など、各種の購買行動に関する支払処理である。決済処理部２１３は、一般的な決済に係る処理を行うものとして、ここでは詳細についての説明を省略する。決済処理部２１３は、決済の金額や日時を含む、決済の結果を決済ログとして決済ログ記憶部２３４に登録する。

施策ログ登録部２１４は、施策ログを施策ログ記憶部２３４に登録する。施策ログ登録部２１４は、たとえば、施策を行ったユーザから当該施策に関する各種情報の入力を受け付け、受け付けた情報を含む施策ログを作成して施策ログ記憶部２３４に登録することができる。

決済ログ取得部２１５は、評価対象となる施策に関連する決済ログを取得する。決済ログ取得部２１５は、たとえば、施策の指定を受け付けて、受け付けた施策に対応する施策ログを施策ログ記憶部２１４から読み出し、読み出した施策ログの施策実施月を基準月として、その前後所定期間（上述したように、本実施形態では所定期間は２ヶ月であり、基準月を含めて５ヶ月分となる。）の決済ログを決済ログ記憶部２３３から読み出すことができる。また、決済ログ取得部２１５は、施策の指定を受け付けず、基準月の指定を受け付けて、基準月前後所定期間分の決済ログを読み出すようにすることもできる。

パターン決定部２１６は、ユーザの消費活動のパターンを決定する。パターン決定部２１６は、ユーザごとに、基準月前後の所定期間における決済金額の推移のパターンを決定する。なお、上記所定期間は、短すぎると分析可能なパターンが出現せず、長すぎると分析に時間がかかる。パターン決定部２１６は、決済金額の推移が、パターン記憶部２３５に記憶されている標準パターンから最も類似しているものを、当該決済金額の推移に係るパターンとして決定することができる。類似度は、たとえば、１ヶ月間での決済金額の変化量（たとえば、２ヶ月前の決済金額と１か月前の決済金額との差）と、標準パターンにおける各月間の変化量との差として求めることができる。また、パターン決定部２１６は、一般的なパターン認識の手法を用いて、標準パターンの中から、決済ログから求めた決済金額の推移に最も近いものを特定することができる。

評価部２１７は、ユーザの消費活動のパターンに応じて施策の評価を行う。本実施形態では、評価部２１７は、ユーザごとに求めた決済金額の推移のパターン（図８の例ではパターン１ないしパターン７の７つのパターンのいずれか）における、優良パターンの割合（優良パターン比率）に応じて評価を行う。具体的な、ユーザごとに求めた決済金額の推移のパターンの何割が優良パターンであるかを計算し、優良パターン比率が高いほど当該施策の評価が高くなるように評価を行う。たとえば、図９の例では、決済ログの存在するユーザについての決済金額の推移パターン１０００個についてパターン１ないしパターン７まで分類された状態を示している。図８の例では、優良パターンはパターン１、パターン２およびパターン３であり、この場合、１０００個中、１５８＋２３８＋１４５＝５４１個が優良パターンである。すなわち、約５４％が優良パターン比率である。評価部２１７は、この５４％の優良パターン比率を評価として利用することもできる。

提案部２１８は、優良パターン比率に応じた提案を行う。提案部２１８は、たとえば、優良パターン比率が所定の閾値以上である施策については、再度同一の施策を実施すべき旨を出力することができる。また、提案部２１８は、優良パターン比率が所定の閾値未満である場合、他で実施された施策を実施すべき旨、および過去に実施した施策を改善して実施すべき旨の少なくともいずれかを出力することができる。

以下、本実施形態の施策評価システムにおいて実行される処理について説明する。図１０は、サーバ装置２０が実行する評価処理の流れを説明する図である。

決済ログ取得部２１５は、基準月およびアプリケーションＩＤの入力を受け付ける（Ｓ３０１）。なお、決済ログ取得部２１５は、施策の指定を受け付けて、指定された施策に対応する施策ログを施策ログ記憶部２３４から読み出し、読み出した施策ログの施策実施月とアプリケーションＩＤとを、基準月およびアプリケーションＩＤの入力として受け付けるようにしてもよい。決済ログ取得部２１５は、基準月前２ヶ月から基準月後２ヶ月までの間の決済日時であり、アプリケーションＩＤに対応する決済ログを読み出す（Ｓ３０２）。

パターン決定部２１６は、読み出された決済ログに係る各ユーザについて、以下の処理を行う。すなわち、パターン決定部２１６は、当該ユーザに対応する決済ログについて、月ごとに決済額を合計し（Ｓ３０３）、月ごとの決済額の平均を基準金額とし（Ｓ３０４）、月ごとの決済額の推移と、パターン記憶部２３５に記憶されている標準パターンとを比較して、最も類似する標準パターンを当該決済額の推移に係るパターンとして決定する（Ｓ３０５）。

以上の処理が各ユーザについて行われた後、評価部２１７は、各パターンの数をカウントし（Ｓ３０６）、優良パターンの数を全パターンの数で割って優良パターン比率を算出する（Ｓ３０７）。提案部２１８は、優良パターン比率を出力する（Ｓ３０８）。

以上のようにして、指定された施策について優良パターン比率を評価として出力することができる。優良パターンは、過去のログより施策後にユーザの決済金額が増加したパターンであり、優良パターンの消費行動をしてくれる消費者が多ければ、全体としても決済金額が増加する。また、優良パターン比率が大きい場合には、施策後の顧客のＬＴＶ（Ｌｉｆｅ Ｔｉｍｅ Ｖａｌｕｅ）が増加することが期待される。よって、アプリを利用したキャッシュフローを増加させることができる。

次に、提案部２１８による、次に実施すべき施策の提案処理について説明する。図１１は、提案部２１８による施策の提案処理の流れを説明する図である。

提案部２１８は、施策の指定を受け付け（Ｓ３２１）、指定された各施策について優良パターン比率を求める（Ｓ３２２）。優良パターン比率は、上述した図１０の処理により求められる。提案部２１８は、指定された各秘策について、以下の処理を行う。

提案部２１８は、優良パターン比率が所定の閾値以上である場合（Ｓ３２３：ＹＥＳ）、再度同一の施策を実施すべき旨を出力する（Ｓ３２４）。

一方、優良パターン比率が所定の閾値未満である場合（Ｓ３２３：ＮＯ）、提案部２１８は、当該施策に対応する施策ログのベンダーＩＤと同一のベンダーＩＤであり、閾値以上の優良パターン比率の施策ログを施策ログ記憶部２３４から検索する（Ｓ３２５）。

提案部２１８は、閾値以上の優良パターン比率の施策ログがなければ（Ｓ３２６：ＮＯ）、優良な施策を横展開すべき旨を出力し（Ｓ３２７）、当該施策に対応する施策ログのアプリケーションＩＤと異なるアプリケーションＩＤであり、かつ、当該施策に対応する施策ログのベンダーＩＤと同一のベンダーＩＤである施策ログのうち最も優良パターン比率の高いものを施策ログ記憶部２３４から検索して出力する（Ｓ３２８）。

一方、提案部２１８は、閾値以上の優良パターン比率の施策ログが見つかった場合には（Ｓ３２６：ＹＥＳ）、当該施策に対応する施策ログのベンダーＩＤと同一のベンダーＩＤであり、当該施策に対応する施策ログのアプリケーションＩＤと異なるアプリケーションＩＤであり、かつ、優良パターン比率が上記閾値未満である施策ログを検索し（Ｓ３２９）、検索した施策ログの施策内容とともに、施策を改善すべき旨を出力する（Ｓ３３０）。

以上の処理を各施策について繰り返すことにより、次に行うべき施策についての提案を行うことができる。

たとえば、図１２は、７月に実施された施策が指定された場合に、施策Ａないし施策Ｆまでの優良パターン比率が図示されるように計算された状態を示している。優良パターン比率の閾値が４０％であったとすると、図１２の例では優良パターン比率が４０％以上である施策Ａおよび施策Ｂについて、再度同じ施策を実施すべき旨が出力される。その他の施策については、優良パターン比率が閾値以上の施策のうち、当該アプリに対してまだ実施されていないものが提案される。図１２の例では、施策Ｃないし施策Ｅについて、施策Ａまたは施策Ｂを実行すべき旨が提案されている。当該アプリに対して閾値以上の優良パターン比率の施策が全て実施されていた場合には、閾値未満の優良パターン比率の施策のうちまだ実施されていないものについて、改善して実施すべき旨が提案される。図１２の例では、施策Ｆについて施策Ｃを改善して実施すべき旨が提案されている。

こうした提案を参考に、ユーザは、提案を参考にして次に実施する施策を検討することができる。

以上説明したように、本実施形態の施策評価システムによれば、施策前後の消費活動のパターンに基づいて、消費が拡大する施策を高く評価することが可能になる。また、本実施形態の施策評価システムによれば、次にどのような施策を行うべきかを提案することができるので、ユーザは次の施策の検討をやりやすくなる。

以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。

たとえば、本実施形態では、アプリを配信するサーバ装置２０が施策の評価・提案を行うものとしたが、サーバ装置２０とは異なる評価装置を設け、評価装置が施策の評価および提案に係る処理を行うようにしてもよい。

また、本実施形態では、標準パターンは７つであるものとしたが、これに限らず、クラスタリング分析などにより分類することのできる任意の数のパターンを標準パターンとして登録してよい。

また、本実施形態では、月ごとの決済金額の推移と標準パターンとの類似度合から決済金額の推移に係るパターンを特定するものとしたが、クラスタリング分析によりどの標準パターンに属するかを決定するようにしてもよい。

また、本実施形態では、月ごとの決済金額の合計額を求め、この月ごとの金額の推移についてのパターンを用いるものとしたが、これに限らず、たとえば１日や１週間、２週間など任意の長さの期間ごとの合計額のパターンを用いるようにしてもよい。

また、本実施形態では、優良パターンはユーザが指定するものとしたが、これに限らず、施策前の所定期間（本実施形態では２ヶ月）における決済金額の合計に対する施策後の所定期間における決済金額の合計の比率が１００％を超えているものを優良パターンとして自動的に決定するようにすることもできる。

また、本実施形態では、施策の提案を行うにあたり、同一ベンダーＩＤの過去の施策を検索するものとしたが、これに限らず、他のベンダーＩＤで優良パターン比率が高いものを読み出して提案するようにしてもよい。

また、本実施形態では、特定のアプリについての施策の評価を行うものとしたが、複数のアプリに対して施策が行われているような場合についても適用可能である。この場合、施策ログにアプリケーションＩＤを複数設定し、図１０のステップＳ３０１において複数のアプリケーションＩＤの入力を受け付けるようにすればよい。

１０ ユーザ端末
２０ サーバ装置
３０ 通信回線
２１１ アプリ配信部
２１２ 認証処理部
２１３ 決済処理部
２１４ 施策ログ登録部
２１５ 決済ログ取得部
２１６ パターン決定部
２１７ 評価部
２１８ 提案部
２３１ 配信ログ記憶部
２３２ 認証ログ記憶部
２３３ 決済ログ記憶部
２３４ 施策ログ記憶部
２３５ パターン記憶部

Claims (9)

1. イベントの評価を行う装置であって、
   前記イベントの前後におけるユーザの消費活動を示す消費活動情報を取得する消費活動情報取得部と、
   前記消費活動情報に基づいて前記消費活動のパターンを決定するパターン決定部と、
   前記消費活動のパターンに応じて前記イベントの評価を行う評価部と、
   を備えることを特徴とする評価装置。
2. 請求項１に記載の評価装置であって、
   前記消費活動情報は、前記ユーザが操作するユーザ端末において実行されるアプリケーションプログラムに係るアプリ内課金情報を含むこと、
   を特徴とする評価装置。
3. 請求項１または２に記載の評価装置であって、
   標準となる前記消費活動のパターンである標準パターンを複数記憶するパターン記憶部を備え、
   前記パターン決定部は、前記消費活動情報を前記標準パターンと比較して、前記標準パターンのいずれかにクラスタリングすること、
   を特徴とする評価装置。
4. 請求項３に記載の評価装置であって、
   前記標準パターンには少なくとも、前記ユーザによる消費金額が経時的に上がる第１パターンと、前記消費金額が経時的に下がる第２パターンとが含まれること、
   を特徴とする評価装置。
5. 請求項３または４に記載の評価装置であって、
   前記標準パターンには、評価の高い高評価パターンが含まれ、
   前記パターン決定部は、前記ユーザごとに前記消費活動のパターンを取得し、
   前記評価部は、前記高評価パターンにクラスタリングされた前記ユーザの数に応じて前記イベントの評価を行うこと、
   を特徴とする評価装置。
6. 請求項５に記載の評価装置であって、
   前記消費活動情報取得部は、複数の前記イベントのそれぞれについて前記消費活動情報を取得し、
   前記パターン決定部は、前記イベントおよび前記ユーザごとに前記消費活動のパターンを取得し、
   前記評価部は、前記イベントごとに、前記高評価パターンにクラスタリングされた前記ユーザの数である高評価数に応じて前記イベントの評価を行い、
   前記高評価数応じて、今後実施する前記イベントの内容についての提案を行う提案部をさらに備えること、
   を特徴とする評価装置。
7. 請求項６に記載の評価装置であって、
   前記提案部は、前記高評価数に応じて、再度同一の前記イベントを実施すべき旨、他で実施された前記イベントを実施すべき旨、および改善した前記イベントを実施すべき旨の少なくともいずれかを出力すること、
   を特徴とする評価装置。
8. イベントの評価を行う評価方法であって、
   評価装置が、
   前記イベントの前後におけるユーザの消費活動を示す消費活動情報を取得する消費活動情報取得ステップと、
   前記消費活動情報に基づいて前記消費活動のパターンを決定するパターン決定ステップと、
   前記消費活動のパターンに応じて前記イベントの評価を行う評価ステップと、
   を実行することを特徴とする評価方法。
9. イベントの評価を行うためのプログラムであって、
   評価装置を、
   前記イベントの前後におけるユーザの消費活動を示す消費活動情報を取得する消費活動情報取得部、
   前記消費活動情報に基づいて前記消費活動のパターンを決定するパターン決定部、
   前記消費活動のパターンに応じて前記イベントの評価を行う評価部、
   として機能させることを特徴とするプログラム。