以下実施の形態を、図面を参照して説明する。以下の説明おいて、イベントとはスポーツの試合、コンサート、及び飲食店のタイムセールなどである。また、事前とはイベントの開始前である。一方、イベントの参加者は、イベントに参加するにあたり、事前にチケットを購入することを前提とする。
(実施の形態1)
図1は広告配信システム(広告出力システム)100の構成例を示す説明図である。広告配信システム100は広告配信装置(広告出力装置)1、携帯端末2及び出稿端末3を含む。広告配信装置1、携帯端末2及び出稿端末3はネットワークNにより通信可能に接続されている。広告配信装置1は携帯端末2へ広告やクーポンを送信する。広告配信装置1はサーバコンピュータ又はワークステーションなどで構成する。携帯端末2は消費者が携帯する端末である。携帯端末2はスマートフォン、携帯電話又はタブレットコンピュータなどで構成する。出稿端末3は広告を広告配信装置1へ広告など出稿するための端末である。出稿端末3は広告主や広告代理店に配される。出稿端末3はデスクトップPC(Personal Computer)、ノートPC又はタブレットコンピュータなどで構成する。なお、広告配信装置1が担う機能をクラウドサービスにて提供してもよい。
広告配信システム100の動作の概略を説明する。広告配信システム100において、広告の配信対象となるのは、チケットを購入した消費者(以下、「チケット購入者」又は「購入者」ともいう。)である。チケットとはスポーツ試合の観戦チケットや、舞台やミュージカルの観劇チケット又は映画の鑑賞チケットなどである。購入者が購入したチケットに関する情報を取得することにより、購入者が特定の時間に、特定の場所で時間を過ごすことが分かる。また、チケットに対応づくイベント(スポーツ試合、舞台、ミュージカル又は映画など)の種別により、購入者の趣味又は趣向を把握することが可能となる。チケットの購入情報は、図1には図示しないチケット販売システムから、広告配信装置1に送信される。
チケット購入者に配信される広告又はクーポン(以下、単に「広告」という。)は、広告主や広告代理店(以下、「出稿者」という。)が出稿端末3から送信する。送信される広告には、属性として、広告に対応付けられた日時、場所、及び表示希望タイミングなども付加され、それらも広告配信装置1へ送信される。広告に対応付けられた日時とは、広告が展示会や街頭キャンペーンに関するものの場合、例えば、展示会や街頭キャンペーンの開催日時である。広告が店舗に関するものである場合、店舗の営業時間である。広告に対応付けられた場所は展示会や街頭キャンペーンの場合、展示会や街頭キャンペーンの開催場所である。広告が店舗に関するものである場合、広告に対応付けられた場所は店舗の場所である。表示希望タイミングは、広告の効果が最も増大すると出向者が考えるタイミングである。
広告配信装置1はチケットの購入情報と、広告及びその属性を含む広告情報とのマッチングを行う。広告配信装置1は広告の配信対象とする購入者、及びその配信のタイミングを決定する。広告配信装置1は決定した配信のタイミングで、配信対象とした購入者に広告を配信する。それにより、高い広告効果を得ることが可能となる。
配信の例としては、以下のものである。スポーツ試合の観戦予定のチケット購入者に対して、試合当日の数時間前に、自宅から試合会場の途中にある応援グッズの販売店に関する割引クーポンを配信する。それにより、観戦前に応援グッズの購入をチケット購入者に促すことが可能となる。映画を鑑賞する予定の消費者に対して、映画鑑賞前又は映画鑑賞直後に、映画館近くであって映画の舞台と関連するレストラン(例えば、イタリアの映画であれば、イタリアレストラン)の割引クーポンを配信する。それにより、映画鑑賞後に当該レストランでの食事をチケット購入者に促すことが可能となる。例えば、割引クーポンは試合開始予定時刻前の2時間のみ有効、又は映画上映終了予定時刻から3時間のみ有効としても良い。それにより広告効果を高めることが可能となる。広告配信装置1について、以下に説明を加える。
図2は広告配信装置1のハードウェア構成例を示すブロック図である。広告配信装置1はCPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、大容量記憶部14、計時部15、通信部16及び読み取り部17を含む。各構成はバスBで接続されている。
CPU11はROM12に記憶された制御プログラム(広告出力プログラム)1Pに従い、ハードウェア各部を制御する。RAM13は例えばSRAM(Static RAM)、DRAM(Dynamic RAM)又はフラッシュメモリである。RAM13はCPU11によるプログラムの実行時に発生するデータを一時的に記憶する。
大容量記憶部14は、例えばハードディスク又はSSD(Solid State Drive)などである。大容量記憶部14は広告配信に必要な各種データを記憶する。大容量記憶部14はチケット購買DB(Data Base)141、コンテンツDB142、単価DB143、配信設定DB144、配信候補DB145、広告枠DB146、配信予定DB147、表示結果DB148、及び関連判定DB149などを記憶する。また、制御プログラム1Pを大容量記憶部14に記憶してもよい。
計時部15は時刻又は広告配信装置1が起動してからの経過時間等の時間を計時しており、CPU11からの求めに応じて、計時結果をCPU11に与える回路である。
通信部16はネットワークNを介して、携帯端末2及び出稿端末3と通信を行う。読み取り部17はCD(Compact Disc)−ROM及びDVD(Digital Versatile Disc)−ROMを含む可搬型記憶媒体1aを読み取る。CPU11が読み取り部17を介して、制御プログラム1Pを可搬型記憶媒体1aより読み取り、大容量記憶部14に記憶してもよい。また、ネットワークN等を介して他のコンピュータからCPU11が制御プログラム1Pをダウンロードし、大容量記憶部14に記憶してもよい。さらにまた、半導体メモリ1bから、CPU11が制御プログラム1Pを読み込んでもよい。
図3は携帯端末2のハードウェア構成例を示すブロック図である。携帯端末2はCPU21、ROM22、RAM23、計時部24、位置計測部25、大容量記憶部26、表示部27、入力部28及び通信部29を含む。各構成はバスBで接続されている。
CPU21はROM22に記憶された制御プログラム2Pに従い、ハードウェア各部を制御する。RAM23は例えばSRAM、DRAM又はフラッシュメモリである。RAM23はCPU21によるプログラムの実行時に発生するデータを一時的に記憶する。
計時部24は時刻又は携帯端末2が起動してからの経過時間等の時間を計時しており、CPU21からの求めに応じて、計時結果をCPU21に与える回路である。
位置計測部25はGPS(Global Positioning System)受信機などを含み、携帯端末2の現在位置の計測を行う。位置計測部25は、通信部29の通信相手である携帯電話網の基地局やWiFi(Wireless Fidelity)アクセスポイント、設置位置が既知であるBluetooth(登録商標)による接続先装置より得た位置情報や誤差情報により、現在位置の計測値を補正する機能を備えてもよい。
大容量記憶部26は、例えばSDカード又はmicroSDカードなどである。大容量記憶部26は消費者のE−mailアドレス、Webサイトのアクセス履歴、及び広告配信装置1から配信された広告などを記憶する。また、制御プログラム1Pを大容量記憶部26に記憶してもよい。
表示部27は広告配信装置1から配信された広告などをチケット購入者に提示する。表示部27は例えば、液晶表示装置である。入力部28は携帯端末2に対してデータやコマンドを入力するためのデバイスである。入力部28は例えば、液晶表示装置で構成された表示部27と一体化したタッチパネルを含む。通信部29はネットワークNを介して、広告配信装置1と通信を行う。
図4は出稿端末3のハードウェア構成例を示すブロック図である。出稿端末3はCPU31、ROM32、RAM33、大容量記憶部34、入出力部35、通信部36及び読み取り部37を含む。各構成はバスBで接続されている。
CPU31はROM32に記憶された制御プログラム3Pに従い、ハードウェア各部を制御する。RAM33は例えばSRAM、DRAM又はフラッシュメモリである。RAM33はCPU31によるプログラムの実行時に発生するデータを一時的に記憶する。
大容量記憶部34は、例えばハードディスク又はSSDなどである。大容量記憶部34は広告配信装置1へ出稿(送信)する広告及び該広告の属性などを記憶する。また、制御プログラム3Pを大容量記憶部34に記憶してもよい。
入出力部35は液晶表示装置やCRTなどの表示する画像信号を出力する。入出力部35はマウスやキーボードにより入力されたデータや操作コマンドを受け付ける。
通信部36はネットワークNを介して、広告配信装置1と通信を行う。読み取り部37はCD−ROM及びDVD−ROMを含む可搬型記憶媒体3aを読み取る。CPU31が読み取り部37を介して、制御プログラム3Pを可搬型記憶媒体3aより読み取り、大容量記憶部34に記憶してもよい。また、ネットワークN等を介して他のコンピュータからCPU31が制御プログラム3Pをダウンロードし、大容量記憶部34に記憶してもよい。さらにまた、半導体メモリ3bから、CPU31が制御プログラム3Pを読み込んでもよい。
次に、広告配信装置1の大容量記憶部14が記憶するデータベースについて説明する。図5はチケット購買DB141のレコードレイアウトの一例を示す説明図である。チケット購買DB141はチケット販売システムから送信されたチケット購入情報を記憶する。チケット購買DB141はチケットID列、開催場所列、開催時間列、購入者ID列、E−mailアドレス列、購入者住所列、及びジャンル列を含む。チケットID列はチケットを一意に特定可能なチケットIDを記憶する。開催場所列はチケットに対応付けられたイベントの開催場所を特定する位置情報、住所又は緯度及び経度などの地理座標を記憶する。開催時間列はチケットに対応付けられたイベントの開催日並びに開始予定時刻及び終了予定時刻を記憶する。購入者ID列はチケットを購入した購入者を一意に特定可能な購入者IDを記憶する。E−mailアドレス列は購入者のE−mailアドレスを記憶する。購入者住所列はチケット購入者の住所を記憶する。ジャンル列はチケットに対応付けられたイベントのジャンル及びイベントの内容を示す補助情報を記憶する。補助情報とは例えば、舞台やミュージカルであれば演目や劇団名などである。スポーツ試合であれば対戦カードなどである。映画であれば映画のタイトルなどである。
図6はコンテンツDB142のレコードレイアウトの一例を示す説明図である。コンテンツDB142は出稿端末3より送信された広告を記憶する。コンテンツDB142はコンテンツID列、場所列、開催時間列、所要時間列、開始時点列、単価ID列、総額列、タイミング列、距離列、及びコンテンツ列を含む。コンテンツID列はコンテンツを一意特定可能なコンテンツIDを記憶する。場所列は広告内容に関連する出来事(例えば、展示会、街頭キャンペーン、タイムセール)が行われている場所を特定する位置情報、住所又は緯度及び経度などの地理座標を記憶する。開催時間列は広告内容に関連する出来事が開催されている時間を記憶する。所要時間列は出来事を消費するのに要する時間を記憶する。出来事を消費するとは、出来事が展示会であれば会場を見て回ることである。出来事が街頭キャンペーンの場合は、例えば、試供品を貰うための時間、アンケートに答えるのに要する時間などを合算した時間である。開始時点列は広告の配信を開始する開始時点を記憶する。単価ID列は広告の単価設定したレコードのIDを記憶する。総額列は広告費総額予算を記憶する。タイミング列は、出稿者が配信を希望するタイミングを記憶する。タイミングは、例えば「イベント前」、「イベント後」、又は「イベント前後問わず」である。「イベント中」、「イベント開始10分後」、及び「イベント終了15分前」などである。なお、タイミング列にはイベントと重なる時間を含む条件は設定できないものとする。イベントと重なる時間は消費者の時間が既に専有されているためである。距離列は配信時の距離条件を記憶する。チケット購入者の現在位置又はイベント開催場所と、広告に対応する出来事の場所との距離が、距離列に設定された距離よりも短い場合は、広告を配信する。コンテンツ列は広告などのコンテンツの実体又は実体へのハイパーリンクを記憶する。実体とは動画データ、画像データ又はテキストデータである。
図7は単価DB143のレコードレイアウトの一例を示す説明図である。単価DB143は広告の単価を記憶する。広告の単価は、一人のチケット購入者に広告が1回配信された場合に、広告主が支払う額である。若しくは1回チケット購入者から広告がアクセスされた場合に、広告主が支払う額としてもよい。若しくは両者を組み合わせてもよい。広告の単価は広告主が設定する。広告の単価は一律であってもよいが、距離条件又は時間条件で変動させてもよい。単価DB143は単価ID列、距離\時間列、期間1列、期間2列、及び期間3列を含む。単位ID列は単価の設定を一意に特定可能な単価IDを記憶する。距離\時間列、期間1列、期間2列、及び期間3列は、距離及び期間で定まる単価を記憶する。例えば、チケット購入者の現在位置又はイベント開催場所と、広告に対応する出来事の場所との距離が、短ければ短いほど、チケット購入者は広告に対応した消費行動を起こす可能性が高い。したがって、図7に示すように、距離が短いほど単価を高くする。また、チケットに対応したイベントの開催日に近いほど、チケット購入者は消費行動を起こしやすいと考えられるので、イベントの開催日、開催時刻に近くなると単価が高くなるように設定する。広告の単価は予め設定されているものを広告主が選択してもよい。図7において、例えば、単価IDが1又は2のレコードは予め単価が設定されているレコードである。単価IDが11のレコードは広告主が独自に設定したレコードである。
図8は配信設定DB144のレコードレイアウトの一例を示す説明図である。配信設定DB144はチケット購入者が広告の配信を受ける際の設定を記憶する。当該設定によりチケット購入者は広告配信のタイミングを制御可能となる。配信設定DB144は購入者ID列、タイプ列、及び内容列を含む。購入者IDはチケット購入者を一意に特定可能な購入者IDを記憶する。当該購入者IDはチケット購買DB141の購入者IDと同じものである。タイプ列は設定方法のタイプを記憶する。内容列はタイプに対応した設定内容を記憶する。図8ではタイプの例として、時間固定タイプ及び期間指定タイプを示している。時間固定タイプは広告配信を受ける時間帯を指定するタイプである。図8に示す例では、曜日ごとに配信を受けるか否かを設定可能としている。そして、配信を受ける曜日については、配信時間帯を午前中(AM)か午後(PM)など設定可能である。時間帯については、更に細かくして、例えば、午前中(9時から12時)、午後1(12時から15時)、午後2(15時から17時)、夜間1(17時〜19時)、夜間2(19時〜21時)などしてもよい。期間指定タイプは曜日や時間帯は指定せず、所定期間内で配信を受ける回数を指定する。図8に示す例では、購入したチケットに係るイベントの開催日を基準に3つの期間(当週、前週、前々週)に分けている。そして、前々週に配信を1回、前週に配信を2回、当週に配信を4回受けるとしている。
図9は配信候補DB145のレコードレイアウトの一例を示す説明図である。配信候補DB145はチケット購入者に配信する広告の候補を記憶する。広告の候補であるのは次の理由による。コンテンツDB142が多数の広告を記憶している場合、チケット購入者に配信すべき広告は多数となる確率が高い。しかし、上述したようにチケット購入者は広告の配信タイミングや配信回数を設定可能である。そのため、チケット購入者に配信すべき広告は全て配信できるとは限らない。そこで、配信すべき広告を配信候補としてDB145に記憶する。配信候補DB145に記憶された配信候補である広告の一部が、チケット購入者へ配信される。配信候補DB145は候補ID列、購入者ID列、E−Mail列、住所列、開催場所列、イベント開催時間列、チケットID列、ジャンル列、広告枠ID列、コンテンツID列、場所列、開催時間列、所要時間列、開始時点列、単価ID列、総額列、タイミング列、及び距離列を含む。配信候補DB145はチケット購買DB141とコンテンツDB142とを結合したようなテーブルとなっている。すなわち、配信候補DB145はチケット及びチケット購買者毎に配信候補となるコンテンツが割り当てた結果を記憶している。配信候補DB145において、購入者ID列、E−mail列、開催場所列、イベント開催時間列、チケットID列、及びジャンル列は、それぞれチケット購買DB141の購入者ID列、E−mailアドレス列、開催場所列、開催時間列、チケットID列、及びジャンル列に対応するので、説明を省略する。配信候補DB145において、コンテンツID列、場所列、開催時間列、所要時間列、開始時点列、単価ID列、総額列、タイミング列、及び距離列それぞれは、コンテンツDB142のコンテンツID列、場所列、開催時間列、所要時間列、開始時点列、単価ID列、総額列、タイミンク列、距離列に対応するので、説明を省略する。配信候補DB145に特有な列は、候補ID列及び広告枠ID列である。候補ID列は配信候補のレコードを一意に特定可能な候補IDを記憶する。広告枠ID列は購入者ID毎に設定される広告枠を一意に特定可能な広告枠IDを記憶する。
図10は広告枠DB146のレコードレイアウトの一例を示す説明図である。広告枠DB146が記憶する広告枠はチケット購入者毎に設定される広告枠である。広告枠DB146は広告枠ID列、期間列及び配信枠列を含む。広告枠IDは広告枠を一意に特定可能な広告枠IDを記憶する。当該広告枠IDは配信候補DBの広告枠ID列が記憶する広告枠IDと対応する。期間列は広告枠が有効な期間を記憶する。広告枠が有効な期間とは、当該広告枠により広告が配信される期間である。配信枠列は配信枠の集合を記憶する。配信枠は1つにつき、1つの広告を1回配信する時間等を定義するものである。配信枠列の形態は前述したタイプにより異なる。図10Aは時間固定タイプの例を示している。配信枠列は月曜日から日曜日を示す月列から日列を含む。図10Bは期間指定タイプの例を示している。配信枠列は条件列及び月曜日から日曜日を示す月列から日列を含む。
図11は配信予定DB147のレコードレイアウトの一例を示す説明図である。配信予定DB147は広告の配信予定を記憶する。配信予定DB147は配信ID列、配信日列、購入者ID列、コンテンツID列、及び配信フラグ列を含む。配信ID列は配信予定を一意に特定可能な配信IDを記憶する。配信日列は広告を配信する日付を記憶する。購入者ID列は広告の配信先となる購入者の購入者IDを記憶する。コンテンツID列は配信する広告のコンテンツIDを記憶する。配信フラグ列は配信が実行されたか否かを記憶する。配信がまだ実行されていない場合、配信フラグ列は「未」を記憶する。配信が実行された後、配信フラグ列は「済」を記憶する。配信フラグ列により、同じ広告が同じ購入者に対して、同じ日に配信されてしまうことを防ぐ事が可能となる。
図12は表示結果DB148のレコードレイアウトの一例を示す説明図である。表示結果DB148はチケット購入者が携帯する携帯端末2の表示部27に表示されたコンテンツなどの情報を記憶する。表示結果DB148は購入者ID列、日時列及び表示URL列を含む。購入者ID列はチケット購入者を特定する購入者IDを記憶する。日時列はコンテンツなどが表示された日時を記憶する。表示URL列は表示されたコンテンツのURLを記憶する。コンテンツを特定可能な情報であればURLに限らず、他の情報を記憶してもよい。その場合は、別途列を設け、設けた列に記憶する。また、表示結果DB148に記憶する情報は、例えば、コンテンツを配信するWebサイトが用いるCookieにより取得し、取得した情報を広告配信装置1がさらに取得する。また、携帯端末2で動作するWebブラウザが表示履歴を広告配信装置1に送信することにより取得する。なお、表示結果DB148の説明で述べたコンテンツは、広告配信装置1が配信する広告とは異なるものである。
図13は関連判定DB149のレコードレイアウトの一例を示す説明図である。関連判定DB149は携帯端末2で表示されたコンテンツが配信予定の広告と関連するか否かを判定するための判定データを記憶する。関連判定DB149は関連ID列、コンテンツID列、及びURL列を含む。関連ID列は判定データを一意に特定可能な関連IDを記憶する。コンテンツID列は関連する広告を特定するコンテンツIDを記憶する。URL列は携帯端末2で表示されたコンテンツを特定するURLを記憶する。関連判定DB149が記憶するレコードにより、コンテンツと広告との関連性が定義される。
続いて、広告配信装置1が行う処理について説明する。図14はマッチング処理の手順例を示すフローチャートである。マッチング処理はチケット購買DB141に記憶されているチケット購買情報とコンテンツDB142が記憶している広告とをマッチングして、配信候補の広告を求める処理である。広告配信装置1のCPU11はチケット購買DB141が記憶しているレコード(購買レコード)の1つを処理対象として選択する(ステップS1)。CPU11はコンテンツDB142が記憶しているレコード(広告レコード)を処理対象として選択する(ステップS2)。CPU11は購買レコードに含まれる開催場所の情報及び広告レコードに含まれる場所の情報から、2つの場所の距離を算出する(ステップS3)。CPU11は算出した距離が広告レコードに含まれる距離(許容値)より小さいかを判定する(ステップS4)。CPU11は算出した距離が距離(許容値)より小さいと判定した場合(ステップS4でYES)、CPU11はタイミングが整合するか否か判定する(ステップS5)。より具体的には以下のアルゴリズムにより、CPU11は判定する。広告レコードに含まれる広告に対応付いた開始時点と、購買レコード含まれるイベントの開催時間とを比較し、2つの前後関係を判定する。判定結果が広告レコードに含まれるタイミングと整合するか否かを判定する。タイミングが整合するならば、CPU11はステップS5でYESと判定し、タイミングが不整合ならCPU11はステップS5でNOと判定する。図5及び図6に示す例で説明する。図6において、コンテンツID=1のレコードに含まれる開始時点は2016年11月1日である。図5において、チケットID=1のレコードに含まれるイベントの開催時間は11月23日である。したがって、広告レコードで定義される広告は、イベントより前に配信可能である。そして、広告レコードのタイミングは、イベント前であるから、タイミング判定はYESと判定する。CPU11はタイミングが整合すると判定した場合(ステップS5でYES)、購買レコードと広告レコードから配信候補レコードを生成し、生成した配信候補レコードを配信候補DB145に記憶する(ステップS6)。CPU11は算出した距離が距離(許容値)より以上であると判定した場合(ステップS4でNO)、又はCPU11はタイミングが整合しないと判定した場合(ステップS5でNO)、処理をステップS7に移す。CPU11は未処理の広告レコードがあるか否かを判定する(ステップS7)。CPU11は未処理の広告レコードがあると判定した場合(ステップS7でYES)、処理をステップS2へ戻す。CPU11は未処理の広告レコードがないと判定した場合(ステップS7でNO)、未処理の購買レコードがあるか否かを判定する(ステップS8)。CPU11は未処理の購買レコードがあると判定した場合(ステップS8でYES)、処理をステップS1へ戻す。CPU11は未処理の購買レコードがないと判定した場合(ステップS8でNO)、マッチング処理を終了する。CPU11は新たなチケット購買情報がチケット購買DB141に記憶される毎に、マッチング処理を実行する。この場合、CPU11は新たなチケット購買情報に関してのみマッチ具処理をすればよい。また、CPU11はコンテンツDB142に新たな広告が記憶された場合、又はコンテンツDB142に記憶された広告が更新された場合に、マッチング処理を実行する。この場合、CPU11は新たな広告又は更新された広告のみについて、マッチング処理をすればよい。
図15は広告枠生成処理の手順例を示すフローチャートである。広告枠生成処理はマッチング処理によって、配信候補となった広告を配信するための広告枠を生成する処理である。前述したように広告枠は配信候補となった広告の配信先となるチケット購入者毎に生成する。CPU11は配信候補DB145のレコードを購入者IDでソートする(ステップS11)。CPU11は処理対象とする購入者IDを選択する(ステップS12)。CPU11は選択した購入者IDに対応付けられた配信設定を配信設定DB144から取得する(ステップS13)。CPU11は購入者IDと対応付けられたイベントのイベント開催時間を取得する(ステップS14)。CPU11はイベント開催時間と配信設定とに基づいて配信枠を作成する(ステップS15)。図9に示す候補ID=005及び006に対応する広告枠は広告枠ID=002の広告枠である。当該配信候補に係るイベントの開催日は2016年11月19日である。したがって、図10に示すように広告枠ID=002の広告枠は、2016年11月19日を当日とする複数の配信枠を含む広告枠となっている。CPU11は生成した複数の配信枠を1つのまとめた広告枠を広告枠DB146に記憶する(ステップS16)。CPU11は未処理の購入者IDがあるか否かを判定する(ステップS17)。CPU11は未処理の購入者IDがあると判定した場合(ステップS17でYES)、処理をステップS11に戻す。CPU11は未処理の購入者IDがないと判定した場合(ステップS17でNO)、広告枠生成処理を終了する。
図16は広告割付処理の手順例を示すフローチャートである。広告割付処理は配信候補の広告を配信枠に割り付ける処理である。CPU11は広告枠DB146に記憶されている広告枠の中から1つを処理対象として選択する(ステップS21)。CPU11は広告枠IDをキーにして、当該広告枠に対応した配信候補の広告を配信候補DB145より取得する(ステップS22)。CPU11は候補の絞り込みを行う(ステップS23)。CPU11は配信枠の配信期間と候補に含まれる広告配信の開始時点とを比較し、配信候補の中から配信期間に配信しうる広告のみに絞り込む。CPU11は絞り込んだ候補に順位付けを行う(ステップS24)。CPU11は候補を順位の高い順に並べ替える(ステップS25)。順位付けについては後述する。CPU11は広告枠に含まれる広告が未割付の配信枠を1つ選択する(ステップS26)。CPU11に未割付の候補中から順位が最も高いものを配信枠に割り付ける(ステップS27)。CPU11は割り付けた結果を配信予定DB147に記憶する。CPU11は未割付の配信枠があるか否かを判定する(ステップS28)。CPU11は未割付の配信枠があると判定した場合(ステップS28でYES)、処理をステップS26へ戻す。CPU11は未割付の配信枠がないと判定した場合(ステップS28でNO)、未処理の広告枠があるか否かを判定する(ステップS29)。CPU11は未処理の広告枠があると判定した場合(ステップS29でYES)、処理をステップS21へ戻す。CPU11は未処理の広告枠がないと判定した場合(ステップS29でNO)、広告割付処理を終了する。なお、ステップS26において、配信枠を選択する際、イベントの当日から日付を遡る順に選択するのが望ましい。それにより、最もチケット購入者が消費行動を起こす確率が高いイベントの当日に、優先順位の高い広告を割り付けることが可能となる。それにより、順位が低いものよりも広告効果を得られる確率を高めることが可能となる。
配信候補広告の優先順位付けについて、その例を説明する。ここではオークション式と最適マッチング推定式を説明する。
オークション式は各候補広告に含まれる単価を参照し、単価が高いものの優先順位を高くする方式である。それにより、単価が高いほど配信する確率が高まるので、出稿者により高い単価を設定するよう促すことが可能となる。
最適マッチング推定式はチケット購入者が配信された広告に関心を持つ可能性を数値化し、可能性の高いものの順位を高くする方式である。関心を持つ可能性を数値化する際の観点としては、例えば、1)趣味趣向、2)距離、又は3)1)と2)との組み合わせである。1)趣味趣向では、チケットに対応付けられたジャンルと広告のジャンルとが似通っている組み合わせほど、関心を持つ可能性が高いと定義する。2)距離では、チケットに係るイベントの開催位置と、広告と対応付けられる出来事の位置との距離が近い組み合わせほど、関心を持つ可能性が高いと定義する。3)1)と2)との組み合わせについては、それぞれの評価を数値化し、数値した評価に重み付けして足し合わせる。以上の処理は公知の技術により実現可能であるので詳しい説明は省略する。なお、順位付けのアルゴリズムは上述したものに限らない。公知の他のアルゴリズムにより、順位付けしてもよい。
次に、広告配信処理について説明する。広告配信処理は配信枠に割り付けられた広告を配信する処理である。ここでは2つの例について説明する。
図17は広告配信処理の手順例を示すフローチャートである。図17に示す広告配信処理は、配信候補に関連する他のコンテンツをチケット購入者が閲覧したタイミングで配信を行うものである。CPU11は表示結果DB148が更新されたか否かを判定する(ステップS31)。前述したようにチケット購入者が携帯端末2でコンテンツを閲覧した場合、閲覧結果を広告配信装置1は取得し、表示結果DB148に保存する。CPU11は表示結果DB148が更新されたと判定した場合(ステップS31でYES)、表示結果DB148から表示内容を取得する(ステップS32)。CPU11は表示内容を元に、関連判定DB149を検索する(ステップS33)。例えば表示内容に含まれるURLをキーに関連判定DB149を検索する。CPU11は検索がヒットした否かを判定する(ステップS34)。CPU11は検索がヒットした判定した場合(ステップS34でYES)、ヒットしたレコードより、コンテンツIDを取得する(ステップS35)。CPU11は取得したコンテンツIDをキーに配信予定DB147を検索する(ステップS36)。CPU11は検索がヒットした否かを判定する(ステップS37)。CPU11は検索がヒットしたと判定した場合(ステップS37でYES)、ヒットした配信予定レコードに従い、広告を配信する(ステップS38)。CPU11は検索がヒットしていないと判定した場合(ステップS37でNO)、広告配信処理を終了する。また、CPU11は表示結果DB148が更新されていない判定した場合(ステップS31でNO)、広告配信処理を終了する。さらにまた、CPU11は関連判定DB149の検索がヒットしていないと判定した場合(ステップS34でNO)、広告配信処理を終了する。広告配信処理は例えば計時部15によるタイマ割り込みにより、繰り返し実行される。なお、チケット購入者が他のコンテンツを閲覧したタイミングに替えて、チケットを購入したタイミングで広告を配信してもよい。
図18及び図19は広告配信処理の他の手順例を示すフローチャートである。図18及び図19に示す広告配信処理は、配信した広告をチケット購入者が閲覧した後程なく行動を開始すると、ちょうど広告に対応付けてある出来事に間に合うタイミングで、広告の配信を行うものである。CPU11は配信予定DB147から処理対象とする配信予定を選択する(ステップS41)。CPU11は配信先であるチケット購入者の位置を取得する(ステップS42)。チケット購入者の位置は公知の技術により随時取得可能であるとする。CPU11は配信候補広告に対応付けられた出来事の位置と、チケット購入者の現在位置との距離を算出する(ステップS43)。CPU11は算出した距離が配信候補広告に対応付けられた距離条件を満たすか否か判定する(ステップS44)。CPU11は距離条件を満たすと判定した場合(ステップS44でYES)、タイミングが適合するか判定する(ステップS45)。例えば、CPU11は本日が配信予定日であるか否かを判定する。CPU11はタイミングが適合すると判定した場合(ステップS45でYES)、本日がイベント当日か否かを判定する(ステップS46)。CPU11は本日がイベント当日と判定した場合(ステップS46でYES)、現在時刻がイベント前か否かを判定する(ステップS47)。CPU11は現在時刻がイベント前と判定した場合(ステップS47でYES)、チケット購入者の現在位置から配信広告に対応付けられた出来事の位置までの移動時間(第1移動時間)を算出する(ステップS48)。CPU11は配信広告に対応付けられた滞在時間を取得する(ステップS49)。CPU11は出来事の位置から、イベントの開催位置への移動時間(第2移動時間)を算出する(ステップS50)。CPU11は現在時刻に第1移動時間、滞在時間及び第2移動時間を足し合わせた到着予定時刻を算出する(ステップS51)。CPU11はイベントに間に合うか否かを判定する(ステップS52)。CPU11は到着予定時刻がイベントの開始時刻より前であれば間に合うと判定する。CPU11は到着予定時刻がイベントの開始時刻より後であれば間に合わないと判定する。CPU11はイベントに間に合うと判定した場合(ステップS52でYES)、広告を配信する(ステップS56)。CPU11は処理をステップS57へ移す。
CPU11は現在時刻がイベント前ではないと判定した場合(ステップS47でNO)、イベントの位置から配信広告に対応付けられた出来事の位置への移動時間(第3移動時間)を算出する(ステップS53)。CPU11はイベントの終了予定時刻に第3移動時間を足し合わせた到着予定時刻を算出する(ステップS54)。CPU11は到着予定時刻が時刻要件を満たすか否かを判定する(ステップS55)。CPU11は、配信広告に対応付けられた出来事の開催時間に、到着予定時刻が含まれる場合は時刻要件を満たすと判定する。CPU11は、配信広告に対応付けられた出来事の開催時間に、到着予定時刻が含まれない場合は時刻要件を満たさないと判定する。CPU11は到着予定時刻が時刻要件を満たすと判定した場合(ステップS55でYES)、広告を配信する(ステップS56)。CPU11は到着予定時刻が時刻要件を満たさないと判定した場合(ステップS55でNO)、処理をステップ57へ移す。
CPU11はイベントに間に合わないと判定した場合(ステップS52でNO)、処理をステップS57に移す。
CPU11は本日がイベント当日でないと判定した場合(ステップS46でNO)、広告を配信する(ステップS56)。
CPU11は距離条件を満たさないと判定した場合(ステップS44でNO)、又はCPU11はタイミングが適合しないと判定した場合(ステップS45でNO)、処理をステップS57へ移す。
CPU11は未処理の予定があるか否かを判定する(ステップS57)。CPU11は未処理の予定があると判定した場合(ステップS57でYES)、処理をステップS41に戻す。CPU11は未処理の予定がないと判定した場合(ステップS57でNO)、広告配信処理を終了する。
続いて、携帯端末2に表示される広告例を示す。図20及び図21は携帯端末2に表示される広告の一例を示す説明図である。図20はイベント前に配信する広告の例である。図20に示すように広告とともに来店を促すクーポン271を表示してもよい。図21はイベント後に配信する広告の例である。図21に示すように広告とともに来店を促すサービスに関するメッセージ272が表示してもよい。
図22は広告配信装置1の機能構成の一例を示すブロック図である。広告配信装置1は取得部11a、特定部11b、抽出部11c、及び送信部11dを含む。これらの各機能部は、CPU11が制御プログラム1Pに基づいて動作することにより、実現される。
取得部11aは、所定の場所で所定の期間提供されるイベントの参加者(チケット購入者)の情報を取得する。特定部11bは、参加者の位置を特定する。抽出部11cは、位置及び期間に対応付けられた広告であって、参加者の位置と広告に対応付けられた位置との位置関係が所定の条件を満たし、参加者の位置、広告に対応付けられた位置及びイベントの位置より算出した所定時間が、イベントの提供期間から定まる時間条件を満たす広告を抽出する。送信部11dは、抽出した広告を参加者の端末(携帯端末2)に送信する。
本実施の形態においては、以下の効果を奏する。イベントに係るチケットを購入したチケット購入者に対して、イベントの開催位置及び開催時間に適合した出来事に関わる広告を配信するので、広告の効果を高めることが可能となる。
各実施の形態で記載されている技術的特徴(構成要件)はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味では無く、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
以上の実施の形態に関し、さらに以下の付記を開示する。
(付記1)
所定の場所で所定の期間提供されるイベントの参加者を特定し、
前記参加者の位置を特定し、
位置及び期間に対応付けられた広告であって、前記参加者の位置と前記広告に対応付けられた位置との位置関係が所定の条件を満たし、かつ前記参加者の位置、前記広告に対応付けられた位置及び前記イベントの位置より算出した所定時間が、前記イベントの提供期間から定まる時間条件を満たす広告を抽出し、
抽出した前記広告を前記参加者の端末に送信する
処理をコンピュータに実行させる広告出力プログラム。
(付記2)
前記参加者の位置は前記参加者の現在位置であり、
前記現在位置から前記広告に対応付けられた位置への移動に要する第1移動時間、前記広告に対応付けられた位置での滞在時間、及び前記広告に対応付けられた位置から前記イベントの位置への移動に要する第2移動時間の合計時間を現在時刻に足し合わせた時刻が、前記イベントの開始時刻前となる場合に、前記時間条件を満たすと判定する
付記1に記載の広告出力プログラム。
(付記3)
前記参加者の位置を前記イベントの位置に置き換え、
前記イベントの位置から前記広告に対応付けられた位置への第3移動時間を、前記イベントの提供終了予定時刻に足し合わせた時刻が、前記広告に対応付けられた期間内となる場合に、前記時間条件を満たすと判定する
付記1に記載の広告出力プログラム。
(付記4)
前記参加者が参加する前記イベントに係る場所と、前記広告に対応付けられた位置との距離を算出し、
算出した距離が所定の距離よりも短いか否かを判定し、
前記イベントの提供期間の直前又は直後の時間が、前記広告に対応付けられた期間に含まれるか否かを判定し、
前記算出した距離が前記所定の距離よりも短く、前記イベントの提供期間の直前又は直後の時間が、前記広告に対応付けられた期間に含まれると判定した場合、
前記イベントに係る場所及び提供期間、並びに広告に対応付けられた位置及び期間を対応付けて記憶する。
付記1から3のいずれか1つに記載の広告出力プログラム。
(付記5)
前記抽出した広告が複数である場合、抽出した広告を所定の条件で並べ替え、
並べ替えた後の先頭の広告から優先して送信を行う
付記1から付記4のいずれか1つに記載の広告出力プログラム。
(付記6)
抽出した広告を広告と対応付けられた単価の降順に並べ替える
付記5に記載の広告出力プログラム。
(付記7)
所定の場所で所定の期間提供されるイベントの参加者の情報を取得する取得部と、
参加者の位置を特定する特定部と、
位置及び期間に対応付けられた広告であって、前記参加者の位置と前記広告に対応付けられた位置との位置関係が所定の条件を満たし、前記参加者の位置、前記広告に対応付けられた位置及び前記イベントの位置より算出した所定時間が、前記イベントの提供期間から定まる時間条件を満たす広告を抽出する抽出部と、
抽出した前記広告を前記参加者の端末に送信する送信部と
を備える広告出力装置。
(付記8)
コンピュータが、
所定の場所で所定の期間提供されるイベントの参加者の情報を取得し、
参加者の位置を特定し、
位置及び期間に対応付けられた広告であって、前記参加者の位置と前記広告に対応付けられた位置との位置関係が所定の条件を満たし、前記参加者の位置、前記広告に対応付けられた位置及び前記イベントの位置より算出した所定時間が、前記イベントの提供期間から定まる時間条件を満たす広告を抽出し、
抽出した前記広告を前記参加者の端末に送信する
広告出力方法。