JP4859825B2 - 広告サーバ及び広告管理方法 - Google Patents

Description

本発明は、広告サーバ及び広告管理方法に関する。

Ｗｅｂページへの広告掲載に関し、従来も指標の１つとして、広告の配信計画に対するリーチ数（その広告が配信されたユーザ数）を用いるものはある。

例えば、広告条件にマッチする有望サイトを選択し、有望サイトに合致するサンプルユーザのアクセスログを含むデータを抜き出し、有望サイトの有効リーチ等の効果管理指標を算出して有望サイトの組み合わせを見つけ、有望サイトの組み合わせに応じた掲載プランを生成する仕組みが存在する（例えば、特許文献１）。

また、テレビや新聞やラジオ等複数の媒体に既に広告を掲載していた場合に、Ｗｅｂページに掲載した場合の効果を求める際に、顧客への広告の浸透度をリーチという概念を用いて評価する仕組みが報告されている（例えば、特許文献２）。
特開２００１−３０６９３４号公報 特開２００６−２２１２４４号公報

しかし、上記に開示の発明においては、具体的に有効リーチをどのように求めるのかが開示されていなかったり（特許文献１の場合）、あるいは、「リーチ」という言葉は用いていても計算の仕方が本発明とは異なったりして、広告主が希望する掲載回数に基づいて厳密にリーチ数を求める方法は依然として開示されていない。一方、広告主にとって闇雲に広告を配信するのではなく、広告の配信がどのようなリーチ数を実現するのかを予想できることは効果的な広告配信を行う上で必須である。

そこで、本発明は、広告主が希望する掲載回数に対し、過去のＷｅｂページのアクセス状況を参考にして、リーチ数の予想を行うこと、さらに、希望するリーチ数を達成するために必要な掲載回数を求めること等が可能な仕組みを提供することを目的とする。

本発明者は、所定の期間における、特定のＷｅｂページに予定しているバナー広告の掲載回数と、過去の同じ期間における当該Ｗｅｂページへの全ユーザによるアクセス回数とから求めたバナー広告の掲載確率と、当該期間における当該Ｗｅｂページへの各ユーザのアクセス回数に応じて当該ユーザが表示する当該Ｗｅｂページに少なくとも１回以上当該バナー広告が掲載されるリーチ確率を求め、これを全ユーザについて集計することで全ユーザのうち何人に当該バナー広告が閲覧されるかを示すリーチ数を求めるという仕組みを見出し、本発明を完成するに至った。本発明は、具体的には次のようなものを提供する。

（１）Ｗｅｂページに掲載するバナー広告の効果の測定を行うための広告サーバであって、過去の所定の期間における特定のＷｅｂページへのアクセスに係る情報を、フリクエンシー毎に対応する全ユーザについて取得する過去ログ参照部と、前記過去ログ参照部で取得した情報から得られる、前記Ｗｅｂページにバナー広告を掲載する場合の掲載確率とユーザの前記期間における前記Ｗｅｂページへのアクセス回数とに基づき該ユーザが表示する前記Ｗｅｂページに少なくとも１回以上前記バナー広告が掲載されるリーチ確率を、フリクエンシー毎に対応するユーザそれぞれについて算出するリーチ確率算出部と、前記フリクエンシー毎に対応するユーザそれぞれについての前記リーチ確率を、前記過去ログ参照部で情報を取得した前記全ユーザについて加算することにより前記期間と同期間において前記Ｗｅｂページを通じて前記バナー広告がユーザに到達する予想リーチ数を算出する予想リーチ数算出部とを備えることを特徴とする広告サーバ。

本発明のこのような構成によれば、広告サーバは、バナー広告を所定の期間、所定の掲載確率で特定のＷｅｂページに掲載する場合に、その掲載により何人のユーザに閲覧されるかを予想するために、過去の同期間における当該Ｗｅｂページへのアクセス状況を調べ、各ユーザがアクセスした回数に応じて各ユーザにバナー広告が到達する確率（リーチ確率）を求め、それを全ユーザについて加算することで全ユーザ中何人にバナー広告が閲覧されるかを予想した予想リーチ数を算出する。

その結果、バナー広告の掲載確率がどの程度のユーザの閲覧に結び付くかが予想できるので、バナー広告を掲載するＷｅｂページの選択、バナー広告の掲載期間等を適切に決めることができる。

（２）前記特定のＷｅｂページが複数あり、該複数のＷｅｂページの各々について前記掲載確率が定められており、前記リーチ確率算出部は、前記複数のＷｅｂページの各々に係る前記掲載確率とユーザの前記期間における前記複数のＷｅｂページの各々に係るアクセス回数とに基づき前記リーチ確率を算出することを特徴とする（１）に記載の広告サーバ。

本発明のこのような構成によれば、複数のＷｅｂページにバナー広告を掲載する場合においても、各Ｗｅｂページへの掲載確率とアクセス回数に基づき、各ユーザにバナー広告が到達する確率（リーチ確率）を求め、それを全ユーザについて加算することで全ユーザ中何人にバナー広告が閲覧されるかを予想した予想リーチ数を算出する。

その結果、複数のＷｅｂページにバナー広告を掲載する場合においても、バナー広告の掲載確率がどの程度のユーザの閲覧に結び付くかが予想できるので、バナー広告を掲載するＷｅｂページの選択、バナー広告の掲載期間、掲載確率等を適切に決めることができる。
（３）前記過去ログ参照部は、取得した情報に基づき、前記期間における前記Ｗｅｂページへのアクセス回数別ユーザ数を集計する機能を有し、前記予想リーチ数算出部が行う全ユーザについての加算は、前記リーチ確率算出部で前記アクセス回数に基づき算出したリーチ確率に、前記アクセス回数別ユーザ数を乗じて用いて行うことを特徴とする（１）または（２）に記載の広告サーバ。

本発明のこのような構成によれば、（１）または（２）に記載の発明において、各ユーザ別に求めたリーチ確率を全ユーザについて加算する際に、アクセス回数が同じユーザについてはリーチ確率が同一となることを利用し、アクセス回数別のユーザ数を予め集計しておくことにより、簡便にリーチ数を計算することができる。

（４）前記過去ログ参照部は、取得した情報に基づき、前記期間における前記Ｗｅｂページへのアクセス回数を集計する機能を有し、広告主が希望する前記Ｗｅｂページへのバナー広告の掲載回数と前記アクセス回数とに基づき該Ｗｅｂページへの該バナー広告の掲載確率を算出する掲載確率算出部をさらに備え、前記リーチ確率算出部は、前記掲載確率算出部により算出された掲載確率に基づいて前記リーチ確率を算出することを特徴とする（１）から（３）のいずれかに記載の広告サーバ。

本発明のこのような構成によれば、広告主が希望するバナー広告の掲載回数と、バナー広告を掲載するＷｅｂページの過去の総アクセス数とから掲載確率を求め、上記の発明を適用できるので、掲載回数と予想リーチ数との関係を把握することができる。

特に、掲載回数に応じて課金するような場合に、広告主は費用と予想リーチ数との関係を考慮しながら広告掲載についての判断をすることができる。

（５）広告主から少なくともバナー広告を掲載するＷｅｂページを特定する情報と、該バナー広告を掲載する掲載期間と、該バナー広告の掲載回数とに係る情報を受け付ける広告主指定値受付部と、前記予想リーチ数算出部により算出した予想リーチ数を前記広告主に送信する予想結果送信部とをさらに備えることを特徴とする（４）に記載の広告サーバ。

本発明のこのような構成によれば、バナー広告掲載に係るＷｅｂページ、掲載期間、掲載回数等の情報を広告主から受け付け、（４）の発明で求めた予想リーチ数を広告主に送信するので、広告主のシステムと連動した効率的な広告リーチ計算システムを構築することができる。

（６）掲載確率を所定のルールに従って設定する機能を有する掲載確率設定部と、前記掲載確率設定部で設定した掲載確率に基づいて前記リーチ確率算出部及び前記予想リーチ数算出部で求めた予想リーチ数が前記目標とするリーチ数に一致するか否かを判定し、不一致であって、その差が所定の許容範囲外であるという判定結果の場合、前記掲載確率設定部による掲載確率の設定をさらに行うと判定し、一致するか又はその差が所定の許容範囲内になったという判定結果の場合、前記掲載確率設定部による掲載確率の設定を停止させると判定するリーチ数判定部と、前記リーチ数判定部での判定結果が前記掲載確率設定部による掲載確率の設定をさらに行うと判定された場合、前記掲載確率設定部によりさらに設定が行われた後の掲載確率の前記掲載確率に基づいて、予想必要掲載回数を算出する予想必要掲載回数算出部とを備えることを特徴とする（１）から（３）のいずれかに記載の広告サーバ。

本発明のこのような構成によれば、掲載確率を変化させながら目標とする予想リーチ数を達成できる掲載確率を探索し、求めた掲載確率から予想必要掲載回数を求めることができる。その結果、目標とするリーチ数を達成するための広告計画を立案することができる。

（７）広告主から少なくともバナー広告を掲載するＷｅｂページを特定する情報と、該バナー広告を掲載する掲載期間と、該バナー広告の希望リーチ数とについての情報を受け付ける広告主指定値受付部と、前記予想必要掲載回数算出部により算出した予想必要掲載回数を前記広告主に送信する予想結果送信部とをさらに備えることを特徴とする（６）に記載の広告サーバ。

本発明のこのような構成によれば、バナー広告掲載に係るＷｅｂページ、掲載期間、希望リーチ数等の情報を広告主から受け付け、（６）の発明で求めた希望リーチ数を達成するための予想必要掲載回数を広告主に送信するので、広告主のシステムと連動した効率的な広告リーチ計算システムを構築することができる。

（１３）Ｗｅｂページに掲載するバナー広告の効果の測定を行うための広告サーバであって、
複数のＷｅｂページにバナー広告を掲載する場合において、過去の所定の期間における前記Ｗｅｂページへのアクセスに係る情報を、フリクエンシー毎に対応する全ユーザについて取得する過去ログ参照部と、
前記過去ログ参照部で取得した情報から得られる、前記Ｗｅｂページへのバナー広告の掲載確率と前記期間における前記Ｗｅｂページへのユーザのアクセス回数とに基づき該ユーザが前記Ｗｅｂページにアクセスする回数のうち少なくとも１回以上前記バナー広告が前記Ｗｅｂページに掲載されるリーチ確率を、フリクエンシー毎に対応するユーザそれぞれについて算出するリーチ確率算出部と、
前記リーチ確率算出部で前記フリクエンシー毎に対応するユーザそれぞれについて算出した、重複リーチを求める複数のＷｅｂページに係るリーチ確率の積を前記過去ログ参照部で情報を取得した全ユーザについて加算することにより前記期間と同期間において前記Ｗｅｂページの各々を通じて前記バナー広告がユーザに到達する予想重複リーチ数を算出する予想重複リーチ数算出部と
を備えることを特徴とする広告サーバ。

本発明のこのような構成によれば、複数のＷｅｂページにバナー広告を掲載する場合に、これらの複数のＷｅｂページに重複してバナー広告が掲載される予想量を知ることができるので、バナー広告の掲載計画を立てる際、広告効果を上げるために重複の少ないＷｅｂページを選ぶことができる。

（１３）前記Ｗｅｂページはいずれかのグループに属し、前記リーチ確率算出部で算出するリーチ確率は、前記グループに属するいずれかのＷｅｂページにアクセスする回数のうち少なくとも１回以上前記バナー広告が前記Ｗｅｂページに掲載されるリーチ確率であり、前記予想重複リーチ数算出部で算出する予想重複リーチ数は、異なるグループに属するＷｅｂページを通じて重複して前記バナー広告がユーザに到達するリーチ数であることを特徴とする（１２）に記載の広告サーバ。

本発明のこのような構成によれば、Ｗｅｂページがグループに分類されており、複数のグループに係るＷｅｂページにバナー広告を掲載する場合に、これらの複数のグループに係るＷｅｂページに重複してバナー広告が掲載される予想量を知ることができるので、グループ単位に広告掲載を行う方式の下でも、広告効果を上げるために重複の少ないグループを選んでバナー広告の掲載計画を立てることができる。

（１４）広告主から少なくともバナー広告を掲載する複数のＷｅｂページを特定する情報と、該バナー広告を掲載する掲載期間と、該バナー広告の掲載回数に係る情報とについての指示を受け付ける広告主指定値受付部と、前記予想重複リーチ数算出部により算出した予想重複リーチ数を前記広告主に送信する予想結果送信部とをさらに備えることを特徴とする（１２）または（１３）に記載の広告サーバ。

本発明のこのような構成によれば、バナー広告掲載に係るＷｅｂページ、掲載期間、掲載回数等の情報を広告主から受け付け、（１２）の発明で求めた予想重複リーチ数を広告主に送信するので、広告主のシステムと連動した効率的な広告リーチ計算システムを構築することができる。

（１５）Ｗｅｂページに掲載するバナー広告の効果の測定を行うための広告サーバが実行する広告管理方法であって、前記広告サーバが、過去の所定の期間における特定のＷｅｂページへのアクセスに係る情報を、フリクエンシー毎に対応する全ユーザについて取得する過去ログ参照ステップと、前記広告サーバが、前記過去ログ参照ステップで取得した情報から得られる、前記Ｗｅｂページにバナー広告を掲載する場合の掲載確率とユーザの前記期間における前記Ｗｅｂページへのアクセス回数とに基づき該ユーザが表示する前記Ｗｅｂページに少なくとも１回以上前記バナー広告が掲載されるリーチ確率を、フリクエンシー毎に対応するユーザそれぞれについて算出するリーチ確率算出ステップと、前記広告サーバが、フリクエンシー毎に対応するユーザそれぞれについての前記リーチ確率を前記過去ログ参照部ステップで情報を取得した前記全ユーザについて加算することにより前記期間と同期間において前記Ｗｅｂページを通じて前記バナー広告がユーザに到達する予想リーチ数を算出する予想リーチ数算出ステッとを含むことを特徴とする広告管理方法。

本発明のこのような構成によれば、（１）に記載の発明が行う処理をコンピュータを用いて行うので、（１）に記載の発明と同様の効果を発揮することができる。

（１７）Ｗｅｂページに掲載するバナー広告の効果の測定を行うための広告サーバが実行する広告管理方法であって、前記広告サーバが、複数のＷｅｂページにバナー広告を掲載する場合において、過去の所定の期間における前記Ｗｅｂページへのアクセスに係る情報を、フリクエンシー毎に対応する全ユーザについて取得する過去ログ参照ステップと、
前記広告サーバが、前記過去ログ参照部で取得した情報から得られる、前記Ｗｅｂページへのバナー広告の掲載確率と前記期間における前記Ｗｅｂページへのユーザのアクセス回数とに基づき該ユーザが前記Ｗｅｂページにアクセスする回数のうち少なくとも１回以上前記バナー広告が前記Ｗｅｂページに掲載されるリーチ確率を、フリクエンシー毎に対応するユーザそれぞれについて算出するリーチ確率算出ステップと、前記広告サーバが、前記リーチ確率算出ステップで前記フリクエンシー毎に対応するユーザそれぞれについて算出した、重複リーチを求める複数のＷｅｂページに係るリーチ確率の積を前記過去ログ参照ステップで情報を取得した全ユーザについて加算することにより前記期間と同期間において前記Ｗｅｂページの各々を通じて前記バナー広告がユーザに到達する予想重複リーチ数を算出する予想重複リーチ数算出ステップとを含むことを特徴とする広告管理方法。

本発明のこのような構成によれば、（１２）に記載の発明が行う処理をコンピュータを用いて行うので、（１２）に記載の発明と同様の効果を発揮することができる。

この発明によれば、Ｗｅｂページにバナー広告を掲載する場合、過去の対象Ｗｅｂページへのアクセス情報に基づいて、広告掲載した場合に予想されるリーチ数や、重複リーチ数を予め知ることができるので効果を勘案した広告計画を立てることができる。

以下、本発明を実施するための最良の形態について図を参照しながら説明する。なお、これはあくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。
（第１の実施形態）

［バナー広告の配信方法］
Ｗｅｂページ上に掲載するバナー広告は、Ｗｅｂページ群を特定するカテゴリと当該Ｗｅｂページ内の場所を特定するポジションにより掲載場所を特定し、期間を定めて掲載される。

図１は、Ｗｅｂページへの広告の配信方法を示す図である。

Ｗｅｂページを管理するサーバは、ユーザからＷｅｂページにアクセスの要求を受けると、当該Ｗｅｂページポジション別に整理した広告のプールから、一定の規則により選択し、選択した広告へのリンクを埋め込んで当該Ｗｅｂページの情報をユーザのブラウザに送信する。

ユーザのパーソナルコンピュータ（以下、パソコンという。）に表示されるＷｅｂページ内には、上記で選択されたバナー広告が表示されるが、この表示は、ユーザが当該Ｗｅｂページをパソコン画面上に表示している間は変更されない。ユーザが、そのＷｅｂページから他のＷｅｂページに移動し、再度当該Ｗｅｂページにアクセスしたときは、広告サーバにより、上記と同様の方法により、また新たにバナー広告が選択されて表示される。

［リーチ］
Ｗｅｂページ上へのバナー広告の掲載はこのような仕組みで行われるため、ユーザが特定のＷｅｂページにアクセスしても、常に同じバナー広告が掲載されるとは限らない。場合によっては、ユーザがそのＷｅｂページに複数回アクセスしても、特定のバナー広告が一度も掲載されないこともありえるし、また、毎回同じバナー広告が掲載されることもありえる。

バナー広告のＷｅｂページ上への掲載が一定の確率でランダムに行われるならば、ユーザがそのバナー広告を見る確率、すなわちユーザにそのバナー広告が到達（リーチ）する確率はユーザがＷｅｂページにアクセスする回数に基づいて計算することができる。

Ｗｅｂページ上へのバナー広告の掲載に関し、広告主がバナー広告の掲載場所（カテゴリ・ポジション）、掲載期間、掲載回数を指定して広告の掲載を行う場合、過去の同一期間における当該Ｗｅｂページへのアクセス回数に基づいて、その掲載回数を実現するためにはどのような掲載確率で掲載すればいいかを決めることができる。

そして、過去の同一期間におけるユーザの当該Ｗｅｂページへのアクセスログに基づいて、その掲載確率の下で、何人のユーザに当該バナー広告が閲覧されるかを示すリーチ数を予想することができる。本実施形態ではその仕組みを説明する。

リーチとは、バナー広告がユーザに届くこと、すなわちＷｅｂページにアクセスするユーザがバナー広告を見ることであり、これはユーザがアクセスするＷｅｂページに１度以上バナー広告が掲載されることを意味する。これは当該Ｗｅｂページへのすべてのアクセスにおいてバナー広告がまったく掲載されない確率を求め、これを１から引くことによって求められる。１人のユーザにリーチする確率をリーチ確率、リーチするユーザの数をリーチ数と呼ぶことにする。

［広告サーバの機能構成図］
図２は、広告サーバの機能構成並びに広告サーバと周辺の要素との関係を示した図である。広告サーバは、上記のバナー広告の配信において、広告に係る処理を行うサーバである。

広告サーバ１は、広告主端末８からネットワーク（図示せず）を介してアクセス可能であり、広告主指定値受付部２で、広告主端末８から広告を掲載すべきカテゴリ・ポジション、掲載期間、掲載回数の入力を受け付ける。これは、広告主端末８のカテゴリ・ポジション指定入力部８−１、掲載期間入力部８−２、掲載回数入力部８−３と、広告サーバ１にある広告主指定値受付部２のカテゴリ・ポジション指定受付部２−１、掲載期間受付部２−２、掲載回数受付部２−３との間で行われる。

リーチ数予想部３は、広告主指定値受付部２で受け付けた情報に基づき、リーチ数の予想を行う。リーチ数予想部３は、過去ログ参照部３−１、掲載確率算出部３−２、リーチ確率算出部３−３、及び予想リーチ数算出部３−４から構成される。

過去ログ参照部３−１は、アクセスログファイル１０から、過去の同一期間における同一カテゴリに属するＷｅｂページ群へのアクセス記録を読み出し、指定されたカテゴリに属するＷｅｂページ群へのユーザ別のアクセス回数（フリクエンシ）と、それを集計した全ユーザのアクセス回数と、ユーザ別のアクセス回数によって分類したアクセス回数別ユーザ数を求める。各カテゴリに属するＷｅｂページ群へのユーザ別のアクセス回数は、カテゴリＩＤとユーザＩＤをキーとしてアクセス記録を集計すれば得られる。各カテゴリに属するＷｅｂページ群への全ユーザのアクセス回数は、カテゴリＩＤをキーとしてアクセス記録を集計すれば得られる。ユーザ別のアクセス回数によって分類したアクセス回数別ユーザ数は、ユーザごとの各カテゴリＩＤについてのアクセス回数を求め、アクセス回数が同じユーザ数を集計すれば得られる。

掲載確率算出部３−２は、指定したカテゴリに属するＷｅｂページ群への掲載回数をアクセス回数で割って掲載確率を算出する。例えば、一定期間における指定したカテゴリに属するＷｅｂページ群へのあるバナー広告の掲載回数が１千万回であり、過去の同一期間における当該Ｗｅｂページ群へのアクセス回数が１億回である場合、掲載確率は０．１である。ここでは、期間が同一の場合、将来も過去と同じだけのアクセス回数があると仮定して、広告主の希望する広告掲載回数を達成するための掲載確率を求めるものである。

リーチ確率算出部３−３は、上記で求めた掲載確率に基づき各ユーザへのリーチ確率を計算する。

予想リーチ数算出部３−４は、これらを集計し、ユーザ全体に対する予想リーチ数を求める。このとき、同一のアクセス回数を持つユーザへのリーチ確率は同一となるので、先に集計したアクセス回数別ユーザ数を用いて、リーチ確率を集計するようにすると加算する回数を削減できる。

予想結果送信部７は、上記で求めた予想リーチ数を広告主端末８に送信する。

［広告サーバのハードウェア構成図］
図３は、本実施形態に係る広告サーバ１のハードウェア構成を示す図である。広告サーバ１は、制御部３０を構成するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３１（マルチプロセッサ構成ではＣＰＵ３２等複数のＣＰＵが追加されてもよい）、バスライン２０、通信Ｉ／Ｆ（Ｉ／Ｆ：インターフェイス）３３、メインメモリ３４、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）３５、表示装置３６、Ｉ／Ｏコントローラ３７、並びにキーボード及びマウス等の入力装置３８を備える。

制御部３０は、広告サーバ１を統括的に制御する部分であり、ハードディスク４０（後述）に記憶された各種プログラムを適宜読み出して実行することにより、上述したハードウェアと協働し、本発明に係る各種機能を実現している。

通信Ｉ／Ｆ３３は、広告サーバ１が、インターネット（図示せず）を介して広告主端末８から各種の指定情報を受け取ったり、また予想リーチ数を送信したりする場合のネットワーク・アダプタである。通信Ｉ／Ｆ３３は、モデム、ケーブル・モデム及びイーサネット（登録商標）・アダプタを含んでよい。

ＢＩＯＳ３５は、広告サーバ１の起動時にＣＰＵ３１が実行するブートプログラムや、広告サーバ１のハードウェアに依存するプログラム等を記録する。

表示装置３６は、ブラウン管表示装置（ＣＲＴ）、液晶表示装置（ＬＣＤ）等のディスプレイ装置を含む。

Ｉ／Ｏコントローラ３７には、ハードディスク４０、及び半導体メモリ４１等の記憶装置４２を接続することができる。

入力装置３８は、広告サーバ１の管理者による入力の受け付けを行うものである。

ハードディスク４０は、本ハードウェアを広告サーバ１として機能させるための各種プログラム、本発明の機能を実行するプログラム及び後述するテーブルを記憶する。なお、広告サーバ１は、外部に別途設けたハードディスク（図示せず）を外部記憶装置として利用することもできる。図２で説明したアクセスログファイル１０は、外部に設けたハードディスクに記録されている。

以上、広告サーバ１のハードウェア構成について主に説明したが、コンピュータに、プログラムをインストールして、そのコンピュータを広告サーバ１として動作させることにより上記で説明した機能を実現することもできる。したがって、本発明において一実施形態として説明した広告サーバ１により実現される機能は、上述の方法を当該コンピュータにより実行することによって、あるいは、上述のプログラムを当該コンピュータに導入して実行することによっても実現可能である。

なお、本発明でいうコンピュータとは、記憶装置、制御部等を備えた情報処理装置をいい、広告サーバ１は、記憶装置４２、制御部３０等を備えた情報処理装置により構成され、この情報処理装置は、本発明のコンピュータの概念に含まれる。

広告主指定値受付部２、リーチ数予想部３及び予想結果送信部７には主に制御部３０が対応する。

［カテゴリ］
図４は、カテゴリの構成を示す図である。各Ｗｅｂページはツリー状に整理されたカテゴリまたはサブカテゴリに対応づけて特定される。

広告を配信するＷｅｂページの指定については、例えば「カテゴリ２」を指定すると、当該カテゴリに属するＷｅｂページのみが配信の対象となるが、「カテゴリ２／以下」を指定すると、当該カテゴリにつながる下位のすべてのサブカテゴリに属するＷｅｂページが特定される。広告主はこれらの点を把握した上で、カテゴリを指定することによって、広告を掲載したいＷｅｂページ群を特定する。以下の実施形態においてカテゴリの指定は、特に断らない限り、当該カテゴリにつながる下位のすべてのサブカテゴリに属するＷｅｂページを指定することを意味するものとする。

広告主から指定された１つのカテゴリに複数のＷｅｂページが含まれる場合、当該カテゴリに係る掲載回数、当該カテゴリに係る過去のアクセス回数、ユーザ別のアクセス回数（フリクエンシ）はそれぞれのＷｅｂページの掲載回数、アクセス回数、ユーザ別のアクセス回数（フリクエンシ）の合計を意味するものとする。したがって、当該複数のＷｅｂページに係る掲載確率は複数のＷｅｂページの合計の掲載回数を合計のアクセス回数で割ったものを各Ｗｅｂページに適用するので同一となる。

［ポジション］
図５は、Ｗｅｂページ内におけるポジションの一例を示す図である。Ｗｅｂページにおけるバナー広告の掲載位置は、指定されたポジションによって特定される。図５（ａ）はトップページにＴＢＰというポジションが定義されていることを示している。図５（ｂ）は、一般のページにおいて、ノース（Ｎ）、イースト（Ｅ）、サウス（Ｓ）、ウェスト（Ｗ）というポジションが定義されていることを示している。Ｗｅｂページによっては、これらのすべてのポジションが広告掲載の対象となる場合もあるが、その一部しか対象とならない場合もある。また、ポジションはこれらに限らず、Ｗｅｂページ内の他の場所も広告掲載の対象となりえる。

［アクセスログ］
図６は、広告サーバ上に保有するＷｅｂページアクセスログを示す図である。ユーザがＷｅｂページにアクセスした日時とユーザＩＤと当該ＷｅｂページのカテゴリＩＤが記録されている。

広告サーバは、ユーザのＷｅｂブラウザが動作しているパソコンのハードディスク上にあるクッキー（Ｃｏｏｋｉｅ）にユーザＩＤを記録しておき、これを読み出すことにより、どのユーザがどのカテゴリにいつアクセスしたかを把握することができる。

［フリクエンシマップ］
図７はフリクエンシマップを示す図である。前述したアクセス回数別ユーザ数を保有するテーブルである。フリクエンシマップは特定のカテゴリに属するＷｅｂページ群へのアクセス回数別のユーザ数の分布状況を示すものであるので、対象とすカテゴリＩＤと対象とする期間を特定すれば、過去のアクセスログに基づいて作成することができる。Ｗｅｂページ群の特定はカテゴリにより行うことができるので、図７の例では、カテゴリＩＤ＝１、期間＝１週間と指定されている。以下、フリクエンシという場合には、１人のユーザのアクセス回数を意味する。

なお、フリクエンシマップは加算集計するときの便利のために設けたものであるので、複数のＷｅｂページのアクセス回数の合計でユーザ数を集計してもよいし、複数のＷｅｂページのそれぞれのアクセス回数の組み合わせに応じてユーザ数を集計してもよい。目的に応じて適宜フリクエンシマップを作成することができる。

［リーチ確率］
所定期間内に、特定のＷｅｂページ群へのフリクエンシがｆ回であるユーザについてのバナー広告のリーチ確率Ｒは、当該Ｗｅｂページ群への当該バナー広告の掲載確率をｐとすると次のようになる。

［予想リーチ数］
数式１で計算される各ユーザのリーチ確率Ｒを全ユーザについて集計すると全ユーザのうち何人に当該バナー広告が閲覧されるかの予想リーチ数を求めることができる。但し、将来も過去と同様のアクセス回数とフリクエンシマップの分布状況であると仮定する。Ｗｅｂページへのフリクエンシｆのユーザの数ｎｕｍ（ｆ）を利用し、予想リーチ数は次のように表すことができる。

実際には無限大まで集計する必要はなく、フリクエンシマップに保有される最大回数まででよい。

［処理フロー］
以下、図８と図９に従い、広告サーバ１が行う処理の流れについて説明する。

図８は、リーチ数を計算するためのリーチ計算テーブルであり、図９は計算手順を示したフローチャートである。

広告サーバ１は、広告主端末８から入力された、バナー広告を掲載すべきカテゴリ・ポジション、掲載期間、掲載回数の入力を、広告主指定値受付部２で受け付ける（Ｓ１）。

次に所望の掲載期間と同一の期間における当該Ｗｅｂページ群へのアクセス情報を過去のＷｅｂページアクセスログ（図６）から抽出する（Ｓ２）。抽出するのは、当該Ｗｅｂページへのアクセス回数とフリクエンシマップ（図７）に係る情報である。

次に、所望の掲載回数とアクセス回数から掲載確率ｐを計算する（Ｓ３）。具体的には所望の掲載回数をアクセス回数で割ればよい。図８においては、掲載確率を０．１としている。

次に、掲載確率ｐを用いて各フリクエンシｆについてリーチ確率を計算する（Ｓ４）。リーチ確率は数式１で求めることができる。図８には、各フリクエンシについて計算したリーチ確率を表示している。

次に、上記で求めたリーチ確率に各フリクエンシのユーザ数を掛けて各フリクエンシのユーザに対する予想リーチ数を求め（Ｓ５）、それを合計する（Ｓ６）。その合計値が全体の予想リーチ数となる。図８において、各フリクエンシごとに、ユーザ数にリーチ確率を掛けて予想リーチ数が求められている。それを合計したものが、全体の予想リーチ数である。

そして最後に、求めた予想リーチ数を広告主に送信する（Ｓ７）。

このようにして、広告サーバ１は、広告主から受け取った広告計画に基づいて、ユーザへの広告到達度（リーチ数）を予想し広告主に伝えることができるので、広告主は広告効果を考えながら広告計画を立てることができる。

（第２の実施形態）
第２の実施形態では、複数のカテゴリに属するＷｅｂページ群にバナー広告を掲載する場合に予想リーチ数を求める例を示す。

なお、以下の説明及び図面において、前述した第１実施形態と同様の機能を果たす部分には、同一の符号を付して、重複する説明を適宜省略する。

本実施形態において、広告主は、所望のバナー広告の掲載期間と、複数の掲載カテゴリ・ポジションと、各カテゴリに属するＷｅｂページ群への掲載回数を指定する。広告効果を高めるために、複数のカテゴリに属するＷｅｂページ群に広告を掲載することを想定したものである。

本実施形態においても、所望の掲載回数と過去のアクセス回数に基づいて掲載確率を求め、その掲載確率の下で、各ユーザのフリクエンシに応じてリーチ確率を求めて、そのリーチ確率を全ユーザについて集計することで予想リーチ数を求める仕組みは第１の実施形態と同様である。

しかし、本実施形態では複数のカテゴリが指定されるので、掲載確率も各カテゴリについて定まる。掲載確率は、各カテゴリに属するＷｅｂページ群への所望の掲載回数を当該Ｗｅｂページ群の過去の同一期間におけるアクセス回数で割ることによってそれぞれ求めることができる。

［ユーザ別Ｗｅｂページアクセス回数テーブル］
図１０はユーザ別Ｗｅｂページアクセス回数テーブルを示す図である。過去の同一期間に各ユーザが指定されたカテゴリ属するＷｅｂページ群に何回アクセスしたかを記録する。アクセスログを集計することによって得られる。

［リーチ確率］
過去の同一期間に、カテゴリ１にｆ１回、カテゴリ２にｆ２回アクセスする場合の当該ユーザに係るリーチ確率Ｒ（以下、ユーザ別リーチ確率という。）は、当該バナー広告のカテゴリ１への掲載確率をｐ１、カテゴリ２への掲載確率をｐ２とした場合次のようになる。

ここで、ユーザ別リーチ確率Ｒは、１からユーザ別非リーチ確率を引くことによって得られ、ユーザ別非リーチ確率は当該ユーザに係るカテゴリＩＤ別非掲載確率の積として得られる。

同様に、カテゴリｋにｆｋ回（ｋ＝１〜ｇ）アクセスするユーザについてのユーザ別リーチ確率Ｒは、当該バナー広告のカテゴリｋへの掲載確率をｐｋとすると次のようになる。

［リーチ数の予想］
バナー広告の全体の予想リーチ数は、ユーザ別リーチ確率Ｒを過去の同一期間に当該Ｗｅｂページにアクセスした全ユーザについて合計することによって求めることができる。

全ユーザについての加算は、各ユーザについて計算したユーザ別リーチ確率Ｒを個別に集計してもよいが、同一のアクセス回数（フリクエンシ）を有するユーザ数を予め集計してフリクエンシマップを作成し、集計したユーザ数を用いると加算回数を削減することができる。しかし、カテゴリが複数であり、複数のカテゴリに属するＷｅｂページ群へのアクセス回数に応じてフリクエンシマップを作ることは一般に煩雑であるので、本実施形態においてはフリクエンシマップは用いず、個別に加算する方法をとる。

［処理フロー］
以下、図１１と図１２に従い、広告サーバ１が行う処理の流れについて説明する。
図１１は、リーチ数を計算するためのリーチ計算テーブルであり、図１２は計算手順を示したフローチャートである。

広告サーバ１は、広告主端末８から入力された、バナー広告の掲載に係る所望のカテゴリ・ポジション、掲載期間、掲載回数の入力を、広告主指定値受付部２で受け付ける（Ｓ１）。この指定値は、「カテゴリ１」のように単一のカテゴリに対しても、また「カテゴリ２／以下」のように「カテゴリ２」の下位に属するカテゴリ全体に対しても入力することができる。

上記掲載期間と同一の期間における同一のＷｅｂページ群へのアクセス状況を過去のＷｅｂページアクセスログ（図６）から抽出する。そして各Ｗｅｂページ群へのユーザ別のアクセス回数（フリクエンシ）と、それを合計した全ユーザのアクセス回数とを求める（Ｓ２）。

次に、各カテゴリに属するＷｅｂページ群への所望の掲載回数をＷｅｂページアクセスログから集計したそのカテゴリに属するＷｅｂページ群のアクセス回数で割ってカテゴリごとに掲載確率（ｐ１〜ｐｇ）を求める。１つのカテゴリに係るＷｅｂページが複数ある場合は、これらの複数のＷｅｂページに係る掲載回数の合計を各カテゴリに係るＷｅｂページへのアクセス回数の合計で割る。この掲載確率を、そのカテゴリに属するＷｅｂページのすべてに適用する。図１１のリーチ計算テーブルにおいて、「カテゴリＩＤ２−１」と「カテゴリＩＤ２−２」の掲載確率がともに０．２となっているのは「カテゴリＩＤ２／以下」というカテゴリが指定されたためである。もし、「カテゴリＩＤ２−１」と「カテゴリＩＤ２−２」のサブカテゴリがそれぞれ指定された場合は、掲載確率が別々に計算されるため、一般的には掲載確率は異なったものになる。

そして、各ユーザの各Ｗｅｂページ群へのアクセス回数と当該Ｗｅｂページ群への掲載確率に基づいて、ユーザ別リーチ確率Ｒを数式４に従って計算する（Ｓ３〜Ｓ４）。

このようにして求めたユーザ別リーチ確率Ｒを全ユーザについて合計することにより予想リーチ数を求めることができる（Ｓ５）。

そして最後に、求めた予想リーチ数を広告主に送信する（Ｓ６）。

このようにして、広告サーバ１は、広告主から指定された複数のカテゴリへの広告掲載要求に基づいて、ユーザへの広告到達度（リーチ数）を予想し広告主に伝えることができるので、広告主は広告効果を考えながら広告計画を立てることができる。

（第３の実施形態）
第３の実施形態では、広告主が指定するバナー広告の掲載カテゴリ・ポジションと掲載期間とリーチ数に基づいて必要掲載回数を求める仕組みを説明する。

［広告サーバの機能構成図］
図１３に広告サーバの機能構成と、広告サーバと周辺の要素との関係を示す。第１の実施形態（図２）と異なる点は、広告主端末８から掲載回数が入力されるのではなく、希望リーチ数が入力される点である。

広告サーバ１は、広告主端末８から入力された希望リーチ数を広告主指定値受付部２の希望リーチ数受付部２−４で受け付ける。

掲載回数予想部４は、広告主指定値受付部２で受け付けた情報に基づき、必要掲載回数の予想を行う。具体的には、最初に過去ログ参照部３−１で、アクセスログファイル１０から、過去の同一期間における同一カテゴリへのアクセス記録を読み出す。そして総アクセス回数とユーザ別アクセス回数（フリクエンシ）を求める。

掲載確率設定部４−１は、希望リーチ数を達成するための掲載確率を二分探索法に則り設定する。以下で求める予想リーチ数と希望リーチ数との大小比較により掲載確率を、移動幅を半減させながら上下に変化させる。

リーチ確率算出部３−３と予想リーチ数算出部３−４は、第１の実施形態で説明したものと同じである。掲載確率設定部４−１で設定した掲載確率に基づいてリーチ確率算出部３−３と予想リーチ数算出部３−４とにより予想リーチ数が計算される。

リーチ数判定部４−２は、求めた予想リーチ数が希望リーチ数に一致するかどうかを判定して、掲載確率の探索の継続要否を決定する。完全に一致しなくても、予め定めた許容誤差の範囲内に収まるか否かにより決定するようにしてもよい。

予想必要掲載回数算出部４−３は、掲載確率設定部４−１で求めた掲載確率に基づき、予想必要掲載回数を計算する。

予想結果送信部７は、上記で求めた予想必要掲載回数を広告主端末８に送信する。

［掲載確率の探索］
掲載確率が与えられるとアクセスログからアクセス回数に係る情報を抽出し、第１の実施形態または第２の実施形態で説明した方法で予想リーチ数が計算できるので、掲載確率を最初に０．５として、予想リーチ数が希望リーチ数になるように、二分探索法で掲載確率を絞り込んでいく。

［探索のフローチャート］
図１４は二分探索法のフローチャートを示す図である。最初に初期値として掲載確率ｐを０．５、変動幅ｖを０．２５としておく（Ｓ１０）。

次に、その掲載確率に基づきリーチ確率を計算し（Ｓ１１）、予想リーチ数を求める（Ｓ１２）。

次に、計算した予想リーチ数と広告主の希望リーチ数とを比較する（Ｓ１３）。

比較の結果、予想リーチ数が大きい場合（Ｓ１３：＞）は、掲載確率ｐを変動幅分だけ減じて新たな掲載確率ｐを求める（Ｓ１４）。予想リーチ数が小さい場合（Ｓ１３：＜）は、掲載確率ｐを変動幅ｖ分だけ加算して新たな掲載確率ｐを求める（Ｓ１５）。そして、変動幅ｖを半減させる（Ｓ１６）。一致する場合（Ｓ１３：＝）は、処理を終了する。

以下、Ｓ１１からＳ１６の処理を繰り返す。

なお、本例では探索終了の条件を予想リーチ数と希望リーチ数が一致するか否かで判定したが、許容誤差を予め設定しておき、予想リーチ数と希望リーチ数との差がこの許容誤差以下になるか否かで判定するようにしてもよい。

［掲載確率の探索例］
図１５は、二分探索法による掲載確率の探索例を示した図である。希望リーチ数を１，０００，０００として掲載確率を探索する例を示したものである。最初にｐ＝０．５からスタートし、予想リーチ数を計算する。予想リーチ数は、第１の実施形態または第２の実施形態で説明した方法により求められる。

ｐ＝０．５の場合の予想リーチ数は２，３８５，３５５で１，０００，０００より大きいので、１回目は、掲載確率をｐ＝０．２５（＝０．５−０．２５）として、予想リーチ数を計算する。そうして求められた予想リーチ数は１，９３３，８７７であり、これも１，０００，０００より大きいので、２回目は、掲載確率をｐ＝０．１２５（＝０．２５−０．１２５）として、予想リーチ数を計算する。

この例からわかるように、掲載確率は変動幅分だけ加減しながら探索を繰り返すが、変動幅は、最初に０．２５からスタートし、探索を繰り返すたびに半減させていく。

このようにして目標のリーチ数と比較しながら掲載確率を探索していき、２２回目に掲載確率がｐ＝０．０６６３０２９のときに予想リーチ数が１，０００，０００になることが求められる。

このようにして求めた掲載確率に、アクセスログから抽出した総アクセス回数を掛けると予想必要掲載回数を求めることができる。

なお、複数のカテゴリへのバナー広告の掲載を行う場合は、カテゴリごとに掲載回数を求めるので、各カテゴリへの掲載回数の関係を予め決めておく。例えば、「カテゴリ１」と「カテゴリ２／以下」とでは、掲載回数を１：２とする等である。

広告主から指定された掲載期間と掲載カテゴリと同一の期間、同一のカテゴリにより特定されるＷｅｂページ群へのアクセス状況を過去のアクセスログから抽出し、各Ｗｅｂページ群についての総アクセス回数とユーザ別アクセス数（フリクエンシ）を求める。

これと、広告主から指定された各カテゴリへの掲載回数の比率により、各カテゴリに対する掲載率の比率を求める。例えば、カテゴリ１とカテゴリ２の掲載回数の比率を１：ｒとすると、掲載確率の比率は１：ｒ×（カテゴリ１の総アクセス数）／（カテゴリ２の総アクセス数）となる。

このようにして求めた掲載確率の比率を維持しながら、片方の掲載確率を動かして二分探索法により希望リーチ数を達成できる掲載確率を求めていく。

具体的には、掲載確率が一番大きくなるものを基準にして、二分探索法を行えばよい。そうしなければ、他の掲載回数が１を超えてしまう場合もありえるからである。

このようにして基準となる掲載確率を求めた後、最初に計算した掲載確率の比率で他のカテゴリに対する掲載確率を求め、それぞれのカテゴリについての総アクセス回数を掛けると掲載回数を求めることができる。

この仕組みによれば、広告サーバは、広告主の指定した掲載カテゴリ・ポジションと掲載期間に上記で求めた掲載確率でバナー広告を掲載するようにすると、広告主の希望するリーチ数を達成することが期待できる。

（第４の実施形態）
ユーザがアクセスするＷｅｂページ群へのバナー広告の掲載回数に上限値を設定することができる。ユーザがＷｅｂページ群にアクセスすると、バナー広告は所定の掲載確率で当該Ｗｅｂページ群に掲載されるので、ユーザによるＷｅｂページ群へのアクセス数が多くなると、ユーザが当該広告を目にする機会は増えていく。一方、同一のユーザが同一の広告を目にする機会が多くなると、ユーザによっては嫌悪感を抱くこともありえる。そこで、一定回数の掲載をしたら、その後の掲載を中止するという仕組みの下で目標の掲載回数を達成する仕組みを示す。

［広告サーバの機能構成図］
図１６に広告サーバ１の機能構成と、広告サーバ１と周辺の要素との関係を示す。第１の実施形態（図２）と異なる点は、広告主端末８から掲載回数の上限値が入力される点と、入力された情報に基づいて掲載確率の探索を行う点である。なお、広告主端末８への結果値の送信は行わない。

広告サーバ１は、広告主端末８から入力された掲載回数の上限値を広告主指定値受付部２の掲載回数上限値受付部２−５で受け付ける。

掲載確率決定部５は、広告主指定値受付部２で受け付けた情報に基づき、掲載確率の決定を行う。具体的には、最初に過去ログ参照部３−１で、アクセスログファイル１０から、過去の同一期間における同一カテゴリへのアクセス記録を読み出し、ユーザ別アクセス回数とアクセス回数別ユーザ数を求める。

掲載確率探索部５−１は、希望掲載回数を達成するための掲載確率を二分探索法により求める。掲載確率探索部５−１は、所定のルールに従って掲載確率を設定する掲載確率設定部５−２と、設定した掲載確率に基づいてユーザ別に期待掲載回数を求めるユーザ別期待掲載回数算出部５−３と、期待掲載回数を全ユーザについて集計して期待総掲載回数を求める期待総掲載回数算出部５−４と、求めた期待総掲載回数が希望掲載回数に一致するかどうかを判定して、探索の継続要否を決定する期待総掲載回数判定部５−５とから構成される。

［処理の考え方］
特定のＷｅｂページにｆ回のアクセスをするユーザに対し、掲載確率ｐで広告掲載を行うとき、期待掲載回数ｉ（ｆ，ｐ）は次の式で与えられる。なお、掲載確率ｐが同一である複数のＷｅｂページについては、各Ｗｅｂページへのアクセス回数の合計をｆとして計算する場合も同様である。ここで、（ｆ，ｎ）は、ｆ個のものからｎ個のものを選ぶ組み合わせの数である。

したがって、バナー広告の掲載回数に上限値ｃを設定すると、期待掲載回数ｉ（ｆ，ｐ，ｃ）は次のようになる。これは各ユーザについて計算される。

この期待掲載回数ｉ（ｆ，ｐ，ｃ）を全ユーザについて集計すると、上限値ｃとした場合の期待総掲載回数（Ｉ（ｐ，ｃ））を求めることができる。

当該Ｗｅｂページ群についてフリクエンシマップが求められる場合には、そのアクセス回数別ユーザ数に基づき、アクセス回数ｆ別のユーザ数（ｎｕｍ（ｆ））を期待掲載回数ｉ（ｆ，ｐ，ｃ）に乗じてすべてのアクセス回数について集計すると、同様に上限値ｃとした場合の期待総掲載回数（Ｉ（ｐ，ｃ））を求めることができる。

なお、実際には無限大まで集計する必要はなく、フリクエンシマップに保有される最大回数まででよい。

目標の掲載回数Ｉが与えられたとき、Ｉ＝Ｉ（ｐ，ｃ）となるようなｐを二分探索法で見つけることができる。

図１７は、アクセス回数ｆとユーザ数ｎｕｍ（ｆ）に基づき、期待総掲載回数（Ｉ（ｐ，ｃ））を求めた例である。

［掲載確率の探索］
掲載確率が与えられるとアクセスログから必要な事項を抽出し、上述した方法で期待総掲載回数が計算できるので、掲載確率を最初に０．５として、期待総掲載回数が希望掲載回数になるように、二分探索法で掲載確率を絞り込んでいく。

［探索のフローチャート］
図１８は二分探索法のフローチャートを示す図である。最初に初期値として掲載確率ｐを０．５、変動幅ｖを０．２５としておく（Ｓ２０）。

次に、掲載確率に基づき期待掲載回数を計算し（Ｓ２１）、期待総掲載回数を求める（Ｓ２２）。

次に、計算した期待総掲載回数と広告主の希望掲載回数とを比較する（Ｓ２３）。比較の結果、計算した期待総掲載回数が大きい場合（Ｓ２３：＞）は、掲載確率ｐを変動幅分だけ減じて新たな掲載確率ｐを求める（Ｓ２４）。計算した期待総掲載回数が小さい場合（Ｓ２３：＜）は、掲載確率ｐを変動幅ｖ分だけ加算して新たな掲載確率ｐを求める（Ｓ２５）。そして、変動幅ｖを半減させる（Ｓ２６）。一致する場合（Ｓ２３：＝）は、処理を終了する。

以下、Ｓ２１からＳ２６の処理を繰り返す。

なお、本例では探索終了の条件を期待総掲載回数と希望掲載回数が一致するか否かで判定したが、許容誤差を予め設定しておき、期待総掲載回数と希望掲載回数との差がこの許容誤差以下になるか否かで判定するようにしてもよい。

［掲載確率の探索例］
図１９は、二分探索法による掲載確率の探索例を示した図である。希望掲載回数を５０，０００，０００として掲載確率を探索する例を示したものである。最初にｐ＝０．５からスタートし、期待総掲載回数を計算する。

ｐ＝０．５の場合の期待総掲載回数は２５０，１１２，５３０で５０，０００，０００より大きいので、１回目は、掲載確率をｐ＝０．２５（＝０．５−０．２５）として、期待総掲載回数を計算する。そうして求められた期待総掲載回数は１２５，０５６，２６５であり、これも５０，０００，０００より大きいので、２回目は、掲載確率をｐ＝０．１２５（＝０．２５−０．１２５）として、期待総掲載回数を計算する。

このようにして希望掲載回数と比較しながら掲載確率を探索していき、２６回目に掲載確率がｐ＝０．０９９９５５０１のときに期待総掲載回数が５０，０００，０００になることが求められる。

このようにすれば、広告主の希望する掲載回数と同一ユーザについての掲載回数の上限値の両方を達成することができる。これにより広告主は、広告効果の逓減を避けながら希望する総掲載回数を確保することができる。これは掲載回数の上限を超える部分を他のユーザに割り当てることになるので、一定の広告浸透度を持つユーザの数を増やすことを意味する。

（第５の実施形態）
第４の実施形態において、計算した期待総掲載回数と広告主の希望掲載回数とが一致する掲載確率ｐを求める際、初期値を０．５とし、二分探索法を用いた。しかし、これに限られるものではない。

例えば、最初に広告主の希望する総掲載回数に基づいて掲載確率を求め、その掲載確率からスタートするようにしてもよい。初期値をどのようにとっても最後は目標値に収束するからである。

また、二分探索法を用いる代わりに、計算結果をＩ（ｐ）とした場合、Ｉ（ｐ）と希望掲載回数Ｉの比率に基づいて、次のような計算式でｐを探索していくこともできる。

αは調整用のパラメータであり、適当なαを選ぶことにより、二分探索法よりも速く希望掲載回数に収束する可能性がある。

（第６の実施形態）
広告主が、カテゴリ・ポジション、期間及び掲載確率の組み合わせを複数個指定して広告の掲載を行う場合、組み合わせの数を増やせばユーザへのリーチ数が増えると予想されるが、一方、同一ユーザに重複してリーチする可能性も増えるので、効果はその分減殺される。そこで、複数の組み合わせを選択して広告の掲載を行う場合、組み合わせ間で重複してリーチする数がわかれば、無駄の少ない広告掲載を行うことができる。本実施形態は、そのようなニーズに対応する仕組みを提供する。

［広告サーバの機能構成図］
図２０に広告サーバの機能構成並びに広告サーバと周辺の要素との関係を示す。広告サーバは、上記のバナー広告の配信において、広告に係る処理を行うサーバである。

広告主指定値受付部２は図２と同様である。

重複リーチ数予想部６は、広告主指定値受付部２で受け付けた情報に基づき、重複リーチ数の予想を行う。重複リーチ数予想部６は、過去ログ参照部３−１、掲載確率算出部３−２、リーチ確率算出部６−１、重複リーチ確率算出部６−２、及び予想重複リーチ数算出部６−３から構成される。

最初に過去ログ参照部３−１は、アクセスログファイル１０から、過去の同一期間における同一カテゴリに属するＷｅｂページへのアクセス記録を読み出し、指定されたカテゴリに属するＷｅｂページへのユーザ別のアクセス回数（フリクエンシ）と、それを集計した全ユーザのアクセス回数と、ユーザ別のアクセス回数によって分類したアクセス回数別ユーザ数を求める。指定されたカテゴリに複数のＷｅｂページが含まれる場合、アクセスログから抽出するアクセス回数はそれぞれのＷｅｂページごとに行う。

掲載確率算出部３−２は、指定したカテゴリに属するＷｅｂページへの掲載回数をアクセス回数で割って掲載確率を算出する。指定されたカテゴリに複数のＷｅｂページが属する場合は、指定された掲載回数（これは複数のＷｅｂページへの掲載回数の合計）をアクセスログから抽出した各Ｗｅｂページへの全ユーザのアクセス回数の合計で割って複数のＷｅｂページにおける平均的な掲載確率を求める。

リーチ確率算出部６−１は、上記で求めた掲載確率に基づき各ユーザへのカテゴリ別リーチ確率を計算する。カテゴリ別リーチ確率は、カテゴリに属するＷｅｂページごとに非リーチ確率を求め、これらの非リーチ確率の積を１から引くことにより計算される。

重複リーチ確率算出部６−２は、上記で求めたカテゴリ別リーチ確率を、重複リーチを求めるグループについて積を求めて各ユーザについて重複リーチ確率を計算する。

予想重複リーチ数算出部６−３は、これらを集計し、ユーザ全体に対する予想重複リーチ数を求める。このとき、同一のアクセス回数を持つユーザへの重複リーチ確率は同一となるので、先に集計したアクセス回数別ユーザ数を用いて、重複リーチ確率を集計するようにすると加算回数が削減できる。

予想結果送信部７は、上記で求めた予想重複リーチ数を広告主端末８に送信する。

本実施形態において、広告主は（カテゴリ１，ＴＢＰ，１週間，０．１）と（カテゴリ２／以下，Ｎ，１週間，０．２）の２つのカテゴリを指定して広告掲載を行うものとする。前者は、カテゴリがカテゴリ１、ポジションがＴＢＰ、希望掲載期間が１週間、掲載確率が０．１を意味する。後者は、カテゴリがカテゴリ２／以下、ポジションがＮ、希望掲載期間が１週間、掲載確率が０．２を意味する。

指定されたカテゴリに属するＷｅｂページに対する過去の１週間分のアクセスログから各Ｗｅｂページのユーザ別のアクセス回数を求め、各Ｗｅｂページへの掲載確率に基づいて非リーチ確率を求める。非リーチ確率Ｌは、次の式で求めることができる。但し、ｐは当該Ｗｅｂページへの掲載確率、ｆは当該Ｗｅｂページへのユーザ別のアクセス回数（フリクエンシ）である。

次に非リーチ確率Ｌに基づいて、各ユーザについて、カテゴリ別リーチ確率Ｇを求める。これは同一カテゴリに属するＷｅｂページの非リーチ確率の積を１から引くことにより求めることができる。

図２１は、重複リーチ計算テーブル（１）の例である。カテゴリ別リーチ確率を求めるところまでの処理を示したものである。図２１によれば、カテゴリ１については０．１（＝１−０．９）、カテゴリ２については、０．４８８（＝１−０．８×０．６４）である。一般的に、次の式で求めることができる。

なお、指定されたカテゴリに属するＷｅｂページへのアクセスがない場合は、当該カテゴリによるリーチはないので、カテゴリ別リーチ確率Ｇは０とする。

図２２は、重複リーチ計算テーブル（２）の例である。図２１で求めたカテゴリ別リーチ確率をユーザ別に整理し、予想重複リーチ数を求める処理を示したものである。

予想重複リーチ数を計算する対象となるカテゴリについてのカテゴリ別リーチ確率の積をユーザごとに求めると、各ユーザについての当該カテゴリ間の重複リーチ確率が計算できる。そして、この重複リーチ確率を全ユーザについて集計すると予想重複リーチ数を求めることができる。

これにより、バナー広告の掲載を複数のカテゴリに対して行う場合に、これらのカテゴリ間での重複リーチ数の予想を求めることができるので、重複の少ない効率的な広告掲載を行うことができる。

（第７の実施形態）
上述した実施形態においては、広告主が希望する広告掲載期間と同一の期間（例えば、１週間とか、１０日間）の過去のアクセスログを抽出して総アクセス数やフリクエンシマップを求めた。しかし、その件数は膨大なので、負荷の軽減を図るため、一定のサンプリング（例えば、１０％）のアクセスログを抽出し、全体を予想することもできる（例えば、１０％の抽出をしたときは、抽出結果を１０倍すれば全体を予想できる。）。このようにして上述した各実施形態を実施することもできる。なお、実際のサンプリングは、サンプリングを行う際、同時に乱数を発生させて、乱数が一定条件のときにのみサンプリングを実行するようにすれば任意のサンプリング率でサンプリングが可能である。

また、もともと将来のアクセス数を過去のアクセスログに基づいて予想しているので、この方法自体に必然的に含まれる誤差が存在する。これらの誤差については、次のように誤差の範囲を評価することができる。

但し、Ｎは抽出されたユーザ数であり、ＥＮはその期待値、Ｖａｒ（Ｎ）はその分散である。ｆはＷｅｂページ群へのユーザ別のアクセス回数（フリクエンシ）、ｎｕｍ（ｆ）は抽出されたＷｅｂページ群へのアクセス回数がｆのユーザ数、ｐは掲載確率、ａはサンプリング率である。

実際に、特定のＷｅｂページ群について、１週間の期間でサンプリング率１０％で評価をしてみると、リーチ数の標準偏差をリーチ数の平均で割った誤差率は、ｐが極端に小さい場合を除いて３％程度だった。このことは、上記で説明した実施形態によるリーチ数の計算の信頼性が高いことを示している。

以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施例に記載されたものに限定されるものではない。

第１実施形態に係るＷｅｂページへの広告の配信方法を示す図である。 第１実施形態に係る広告サーバの機能構成並びに広告サーバと周辺の要素との関係を示す図である。 第１実施形態に係る広告サーバのハードウェア構成を示す図である。 第１実施形態に係るカテゴリの構成を示す図である。 第１実施形態に係るＷｅｂページ内におけるポジションの一例を示す図である。 第１実施形態に係るＷｅｂページアクセスログを示す図である。 第１実施形態に係るフリクエンシマップを示す図である。 第１実施形態に係るリーチ数を計算するためのリーチ計算テーブルである。 第１実施形態に係る計算手順を示したフローチャートを示す図である。 第２実施形態に係るユーザ別Ｗｅｂページアクセス回数テーブルを示す図である。 第２実施形態に係るリーチ数を計算するためのリーチ計算テーブルである。 第２実施形態に係る計算手順を示したフローチャートを示す図である。 第３実施形態に係る広告サーバの機能構成並びに広告サーバと周辺の要素との関係を示した図である。 第３実施形態に係る二分探索法のフローチャートを示す図である。 第３実施形態に係る二分探索法による掲載確率の探索例を示す図である。 第４実施形態に係る広告サーバの機能構成並びに広告サーバと周辺の要素との関係を示した図である。 第４実施形態に係る期待総掲載回数計算テーブルを示す図である。 第４実施形態に係る二分探索法のフローチャートを示す図である。 第４実施形態に係る二分探索法による掲載確率の探索例を示す図である。 第６実施形態に係る広告サーバの機能構成並びに広告サーバと周辺の要素との関係を示した図である。 第６実施形態に係る重複リーチ計算テーブル（１）を示す図である。 第６実施形態に係る重複リーチ計算テーブル（２）を示す図である。

符号の説明

１ 広告サーバ
２０ バスライン
３０ 制御部
４２ 記憶装置

Claims (12)

1. Ｗｅｂページに掲載するバナー広告の効果の測定を行うための広告サーバであって、
   過去の所定の期間における特定のＷｅｂページへのアクセスに係る情報を、フリクエンシー毎に対応する全ユーザについて取得する過去ログ参照部と、
   前記過去ログ参照部で取得した情報から得られる、前記Ｗｅｂページにバナー広告を掲載する場合の掲載確率とユーザの前記期間における前記Ｗｅｂページへのアクセス回数とに基づき該ユーザが表示する前記Ｗｅｂページに少なくとも１回以上前記バナー広告が掲載されるリーチ確率を、フリクエンシー毎に対応するユーザそれぞれについて算出するリーチ確率算出部と、
   前記フリクエンシー毎に対応するユーザそれぞれについての前記リーチ確率を、前記過去ログ参照部で情報を取得した前記全ユーザについて加算することにより前記期間と同期間において前記Ｗｅｂページを通じて前記バナー広告がユーザに到達する予想リーチ数を算出する予想リーチ数算出部と
   を備えることを特徴とする広告サーバ。
2. 前記特定のＷｅｂページが複数あり、該複数のＷｅｂページの各々について前記掲載確率が定められており、
   前記リーチ確率算出部は、前記複数のＷｅｂページの各々に係る前記掲載確率とユーザの前記期間における前記複数のＷｅｂページの各々に係るアクセス回数とに基づき前記リーチ確率を算出することを特徴とする請求項１に記載の広告サーバ。
3. 前記過去ログ参照部は、取得した情報に基づき、前記期間における前記Ｗｅｂページへのアクセス回数別ユーザ数を集計する機能を有し、
   前記予想リーチ数算出部が行う全ユーザについての加算は、前記リーチ確率算出部で前記アクセス回数に基づき算出したリーチ確率に、前記アクセス回数別ユーザ数を乗じて用いて行うことを特徴とする請求項１または請求項２に記載の広告サーバ。
4. 前記過去ログ参照部は、取得した情報に基づき、前記期間における前記Ｗｅｂページへのアクセス回数を集計する機能を有し、
   広告主が希望する前記Ｗｅｂページへのバナー広告の掲載回数と前記アクセス回数とに基づき該Ｗｅｂページへの該バナー広告の掲載確率を算出する掲載確率算出部をさらに備え、
   前記リーチ確率算出部は、前記掲載確率算出部により算出された掲載確率に基づいて前記リーチ確率を算出することを特徴とする請求項１から請求項３のいずれかに記載の広告サーバ。
5. 広告主から少なくともバナー広告を掲載するＷｅｂページを特定する情報と、該バナー広告を掲載する掲載期間と、該バナー広告の掲載回数とに係る情報を受け付ける広告主指定値受付部と、
   前記予想リーチ数算出部により算出した予想リーチ数を前記広告主に送信する予想結果送信部と
   をさらに備えることを特徴とする請求項４に記載の広告サーバ。
6. 掲載確率を所定のルールに従って設定する機能を有する掲載確率設定部と、
   前記掲載確率設定部で設定した掲載確率に基づいて前記リーチ確率算出部及び前記予想リーチ数算出部で求めた予想リーチ数が前記目標とするリーチ数に一致するか否かを判定し、不一致であって、その差が所定の許容範囲外であるという判定結果の場合、前記掲載確率設定部による掲載確率の設定をさらに行うと判定し、一致するか又はその差が所定の許容範囲内になったという判定結果の場合、前記掲載確率設定部による掲載確率の設定を停止させると判定するリーチ数判定部と、
   前記リーチ数判定部での判定結果が前記掲載確率設定部による掲載確率の設定をさらに行うと判定された場合、前記掲載確率設定部によりさらに設定が行われた後の掲載確率の前記掲載確率に基づいて、予想必要掲載回数を算出する予想必要掲載回数算出部と
   を備えることを特徴とする請求項１から請求項３のいずれかに記載の広告サーバ。
7. 広告主から少なくともバナー広告を掲載するＷｅｂページを特定する情報と、該バナー広告を掲載する掲載期間と、該バナー広告の希望リーチ数とについての情報を受け付ける広告主指定値受付部と、
   前記予想必要掲載回数算出部により算出した予想必要掲載回数を前記広告主に送信する予想結果送信部と
   をさらに備えることを特徴とする請求項６に記載の広告サーバ。
8. Ｗｅｂページに掲載するバナー広告の効果の測定を行うための広告サーバであって、
   複数のＷｅｂページにバナー広告を掲載する場合において、過去の所定の期間における前記Ｗｅｂページへのアクセスに係る情報を、フリクエンシー毎に対応する全ユーザについて取得する過去ログ参照部と、
   前記過去ログ参照部で取得した情報から得られる、前記Ｗｅｂページへのバナー広告の掲載確率と前記期間における前記Ｗｅｂページへのユーザのアクセス回数とに基づき該ユーザが前記Ｗｅｂページにアクセスする回数のうち少なくとも１回以上前記バナー広告が前記Ｗｅｂページに掲載されるリーチ確率を、フリクエンシー毎に対応するユーザそれぞれについて算出するリーチ確率算出部と、
   前記リーチ確率算出部で前記フリクエンシー毎に対応するユーザそれぞれについて算出した、重複リーチを求める複数のＷｅｂページに係るリーチ確率の積を前記過去ログ参照部で情報を取得した全ユーザについて加算することにより前記期間と同期間において前記Ｗｅｂページの各々を通じて前記バナー広告がユーザに到達する予想重複リーチ数を算出する予想重複リーチ数算出部と
   を備えることを特徴とする広告サーバ。
9. 前記Ｗｅｂページはいずれかのグループに属し、
   前記リーチ確率算出部で算出するリーチ確率は、前記グループに属するいずれかのＷｅｂページにアクセスする回数のうち少なくとも１回以上前記バナー広告が前記Ｗｅｂページに掲載されるリーチ確率であり、
   前記予想重複リーチ数算出部で算出する予想重複リーチ数は、異なるグループに属するＷｅｂページを通じて重複して前記バナー広告がユーザに到達するリーチ数であることを特徴とする請求項８に記載の広告サーバ。
10. 広告主から少なくともバナー広告を掲載する複数のＷｅｂページを特定する情報と、該バナー広告を掲載する掲載期間と、該バナー広告の掲載回数に係る情報とについての指示を受け付ける広告主指定値受付部と、
    前記予想重複リーチ数算出部により算出した予想重複リーチ数を前記広告主に送信する予想結果送信部と
    をさらに備えることを特徴とする請求項８または請求項９に記載の広告サーバ。
11. Ｗｅｂページに掲載するバナー広告の効果の測定を行うための広告サーバが実行する広告管理方法であって、
    前記広告サーバが、過去の所定の期間における特定のＷｅｂページへのアクセスに係る情報を、フリクエンシー毎に対応する全ユーザについて取得する過去ログ参照ステップと、
    前記広告サーバが、前記過去ログ参照ステップで取得した情報から得られる、前記Ｗｅｂページにバナー広告を掲載する場合の掲載確率とユーザの前記期間における前記Ｗｅｂページへのアクセス回数とに基づき該ユーザが表示する前記Ｗｅｂページに少なくとも１回以上前記バナー広告が掲載されるリーチ確率を、フリクエンシー毎に対応するユーザそれぞれについて算出するリーチ確率算出ステップと、
    前記広告サーバが、フリクエンシー毎に対応するユーザそれぞれについての前記リーチ確率を前記過去ログ参照部ステップで情報を取得した前記全ユーザについて加算することにより前記期間と同期間において前記Ｗｅｂページを通じて前記バナー広告がユーザに到達する予想リーチ数を算出する予想リーチ数算出ステッと
    を含むことを特徴とする広告管理方法。
12. Ｗｅｂページに掲載するバナー広告の効果の測定を行うための広告サーバが実行する広告管理方法であって、
    前記広告サーバが、複数のＷｅｂページにバナー広告を掲載する場合において、過去の所定の期間における前記Ｗｅｂページへのアクセスに係る情報を、フリクエンシー毎に対応する全ユーザについて取得する過去ログ参照ステップと、
    前記広告サーバが、前記過去ログ参照部で取得した情報から得られる、前記Ｗｅｂページへのバナー広告の掲載確率と前記期間における前記Ｗｅｂページへのユーザのアクセス回数とに基づき該ユーザが前記Ｗｅｂページにアクセスする回数のうち少なくとも１回以上前記バナー広告が前記Ｗｅｂページに掲載されるリーチ確率を、フリクエンシー毎に対応するユーザそれぞれについて算出するリーチ確率算出ステップと、
    前記広告サーバが、前記リーチ確率算出ステップで前記フリクエンシー毎に対応するユーザそれぞれについて算出した、重複リーチを求める複数のＷｅｂページに係るリーチ確率の積を前記過去ログ参照ステップで情報を取得した全ユーザについて加算することにより前記期間と同期間において前記Ｗｅｂページの各々を通じて前記バナー広告がユーザに到達する予想重複リーチ数を算出する予想重複リーチ数算出ステップと
    を含むことを特徴とする広告管理方法。

Images