JPWO2015129847A1 - プログラム - Google Patents

Abstract

端末が、端末で動作するブラウザのウィンドウ等に表示されるコンテンツに対応付けられたプログラムを実行する。当該プログラムの実行により、端末は、ウィンドウ等にコンテンツがロードされる際に、ウィンドウ等に割り当てられたwindow.requestAnimationFrameメソッドによりコールバック関数を登録する。コールバック関数が呼び出されると、端末は、当該ウィンドウ等についてコールバック関数が呼び出されたタイムスタンプ(S101)の間隔に基づいて、当該ウィンドウ等がユーザに閲覧されているか否かの判定をし(S105)、当該ウィンドウ等に割り当てられたwindow.requestAnimationFrameメソッドにより当該コールバック関数を再登録する(S107)。端末は、間欠的に、前記判定の結果をサーバに通知する(S106)。

Description

本発明は、ブラウザのウィンドウもしくはタブに表示されるコンテンツがユーザに閲覧されているか否かを判定するプログラムに関する。

従来から、ワールド・ワイド・ウェブで配布されているコンテンツが閲覧されている度合の指標として、当該コンテンツの単位時間あたりのページビューや当該コンテンツの滞在時間などが採用されている。これらの数値は、たとえば特許文献1に開示されるように、サーバに対するアクセスが行われた時刻に基づいて計測される。

特開2010-015333号公報

しかしながら、端末においてコンテンツが閲覧されているか否かをより一層正確に判定したい、という要望は強い。また、コンテンツ本文がユーザにより読了されたか、熟読されたか、その度合を知りたい、という要望もある。

本発明は、上記の課題を解決しようとするもので、ブラウザのウィンドウもしくはタブに表示されるコンテンツがユーザに閲覧されているか否かを判定するプログラムを提供することを目的とする。

本発明に係るプログラムは、
端末で動作するブラウザのウィンドウもしくはタブに表示されるコンテンツに対応付けられるプログラムであって、前記端末は、前記プログラムを実行することにより、
前記ウィンドウもしくはタブに前記コンテンツがロードされる際に、前記ウィンドウもしくはタブに割り当てられたwindow.requestAnimationFrameメソッドにより前記プログラムにより定義されるコールバック関数を登録し、
前記コールバック関数が呼び出されると、前記ウィンドウもしくはタブについて当該コールバック関数が呼び出されたタイムスタンプの間隔に基づいて、当該ウィンドウもしくはタブがユーザに閲覧されているか否かの判定をし、当該ウィンドウもしくはタブに割り当てられたwindow.requestAnimationFrameメソッドにより当該コールバック関数を再登録し、
間欠的に、前記判定の結果をサーバに通知する
ように構成する。

本発明に係るプログラムにおいて、前記端末は、前記プログラムを実行することにより、
前記コールバック関数が呼び出されると、前記判定の結果ならびに当該判定がされた時点で前記コンテンツに含まれる各要素が前記ウィンドウもしくはタブ内に閲覧可能に描画されているか否かにより、前記コンテンツに対する読了率を求め、
間欠的に、前記求められた読了率を前記サーバに通知する
ように構成することができる。
また、本発明に係るプログラムにおいて、前記端末は、前記プログラムを実行することにより、
前記コールバック関数が呼び出されると、前記判定の結果ならびに当該判定がされた時点で前記コンテンツに含まれる各要素が前記ウィンドウもしくはタブ内に閲覧可能に描画されているか否かにより、当該各要素が読了済であるか否かを求め、
前記コンテンツに対する読了率が閾値を超えると、読了済の要素と未読の要素との切れ目を同定し、
当該切れ目に広告を挿入、もしくは、当該読了済の要素のみに重なるように当該切れ目の前方に広告をポップアップ表示する
ように構成することができる。
本発明の他の観点に係るプログラムは、端末で動作するブラウザのウィンドウもしくはタブに表示されるコンテンツに対応付けられるプログラムであって、前記端末は、前記プログラムを実行することにより、
間欠的に、当該ウィンドウもしくはタブがユーザに閲覧されているか否かの判定をし、
前記判定の結果ならびに当該判定がされた時点で前記コンテンツに含まれる各要素が前記ウィンドウもしくはタブ内に閲覧可能に描画されているか否かにより、前記コンテンツに対する読了率、ならびに、当該各要素が読了済であるか否かを求め、
前記コンテンツに対する読了率が閾値を超えると、読了済の要素と未読の要素との切れ目を同定し、
当該切れ目に広告を挿入、もしくは、当該読了済の要素のみに重なるように当該切れ目の前方に広告をポップアップ表示する。

本発明によれば、ブラウザのウィンドウもしくはタブに表示されるコンテンツがユーザに閲覧されているか否かを判定するプログラムを提供することができる。

本発明の実施例に係るコールバック関数での処理内容を示すフローチャートである。 本発明の実施例における通信の様子を表すセッション図である。 本発明の実施例におけるコンテンツの表示例である。 本発明の実施例におけるコンテンツの要素の既読、未読の状態を表す説明図である。 本発明の実施例におけるコンテンツおよびポップアップ広告の表示例である。

以下に本発明の実施形態を説明する。なお、本実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。

本実施例では、コンテンツが表示されるウィンドウもしくはタブに割り当てられたwindow.requestAnimationFrameメソッドを利用する。当該メソッドは、画面表示の更新(再描画)の準備ができたときに呼び出されるコールバック関数を登録するものである。コールバック関数は、コンテンツに対応付けられるスクリプトプログラムにより定義され、当該スクリプトプログラムは、JavaScript (登録商標)言語により記述されるのが典型的である。

コンテンツが表示されるウィンドウ等が、ユーザから見えるためには、当該ウィンドウ等が、他のウィンドウ等(ブラウザウィンドウやブラウザタブのほか、他のアプリケーションのウィンドウを含む。)に隠されていないことが必要である。

一般に、ブラウザは、ユーザから見ることが可能なウィンドウ等については、画面表示の更新(再描画)を頻繁に行い、隠れたウィンドウ等やフォーカスされていないウィンドウについては、更新(再描画)の頻度を下げることにより、計算負荷を抑制している。

このため、コールバック関数が呼び出される間隔は、ウィンドウ等がユーザから見えているときと、ユーザから見えていないときとの2つのピークを持つと仮定することができる。

そこで、本発明では、この2つのピークの中間を閾値として、コールバック関数が呼び出された間隔が閾値以下であれば、当該ウィンドウ等はユーザに見られており、閾値未満であれば、当該ウィンドウ等はユーザには見られていない、と判定するのである。

コールバック関数の登録は、まず、ウィンドウ等にコンテンツがロードされる際に行われる。その後は、コールバック関数が呼び出されるごとに、当該コールバック関数を再登録する。これにより、システムがウィンドウ等の画面表示の更新(再描画)を行う準備ができる度に、コールバック関数を呼び出すこととする。

コールバック関数内では、呼び出し時刻を管理するための配列を参照している。当該配列は、ウィンドウ等にコンテンツがロードされる際、あるいは、当該ウィンドウ等に対して初めてコールバック関数が呼び出された際に初期化される。

図1は、本発明の実施例に係るコールバック関数での処理内容を示すフローチャートである。以下、本図を参照して説明する。

本図に示すように、コールバック関数が呼び出されると、まず、ブラウザが動作する端末では、コールバック関数に渡された引数を取得する(ステップS101)。当該引数は、コールバック関数が呼び出された時刻のタイムスタンプを示している。

次に、端末は、取得されたタイムスタンプを配列に追加する(ステップS102)。そして、配列の長さが所定長を超えていれば(ステップS103；Yes)、配列の最も古い要素を削除する(ステップS104)。超えていなければ(ステップS103；No)、そのままステップS105に進む。

ついで、端末は、配列に格納されたタイムスタンプの履歴から、当該ウィンドウ等が現在ユーザから見えているか、すなわち、コンテンツがユーザから閲覧されているか、を判定する(ステップS105)。具体的には、以下のような手法が考えられる。

第1には、典型的なブラウザおよび端末について、上記の閾値を実験等により求めておき、最新の2つのタイムスタンプの差と、上記閾値との大小に基づいて、判定を行う、というものである。この場合には、配列の所定長は、2とすることができる。また、配列によるのではなく、前回のタイムスタンプを記憶する変数を用意して、これと今回引数として渡されたタイムスタンプとの差を計算することとしても良い。

実験によれば、多くの端末ならびにブラウザでは、ユーザに見えるウィンドウ等では、1秒間に30フレーム程度の描画がなされ、隠れたウィンドウ等では、1秒間に数フレームから10フレーム程度の描画がなされることが多い。この場合には、1秒間に15フレーム〜20フレーム程度(0.0500秒〜0.0667秒程度)を閾値とすることができる。

第2には、配列の隣り合う要素に格納されたタイムスタンプの差の分布により、閾値を適応的に決定して、判定を行うものである。

上記差を小さい順にソートして、上位(上位半分、上位3分の1、上位4分の1、所定数の上位等。)の平均をウィンドウ等が見える際の呼び出し間隔のピークと推定し、下位(上位と同様。)の平均をウィンドウ等が見えない際の呼び出し間隔のピークと推定し、2つのピークの差を閾値とする。

このほか、上記差が、互いに異なる平均値および分散を持つ正規分布を2つ重ね合わせたものと仮定して、それぞれの平均値を求め、当該2つの平均値の中間を、閾値としても良い。

なお、閾値を適応的に決定するにあたっては、ウィンドウやタブ単位で決定するのではなく、ブラウザ単位で行うことが望ましい。特に、ブラウザの複数のウィンドウやタブにおいて異なるコンテンツが表示され、各コンテンツにおいて登録されたコールバック関数が求めた差をまとめた分布に基づいて、閾値を決定すれば、端末の性能やブラウザの実装に応じた閾値を定めることができる。

また、上記2つの手法を組み合わせても良い。すなわち、ブラウザにおいて本実施形態に係るコールバック関数が初めて登録されてから一定回数は、第1の手法に基づいて処理を行い、十分な数の差が蓄積されてから、第2の手法に移行する等である。

さらに、過去に定められた閾値をクッキー等に基いて参照可能な値として保存しておき、次回以降の初期値として採用することとしても良い。

ついで、端末は、判定の結果をサーバに送信する(ステップS106)。なお、サーバへの送信は、コールバック関数が呼ばれる度に行うのではなく、判定の結果が切り替わった際のみに送ったり、setInterval()等を用いて登録されたハンドラ関数を一定の期間おきに呼び出すことで、間欠的にサーバへ送信することとしても良い。

そして、端末は、コールバック関数を、再度window.requestAnimationFrameメソッドにより登録して(ステップS107)、本コールバック関数の実行を終了する。

このように、本態様によれば、ウィンドウ等に描画されるべきコンテンツがユーザから見えるか否かの判定を、細かい時間単位で正確に行うことができる。

上記実施例のように、コンテンツがユーザから見えるか否かの判定を、細かい時間単位で正確に行うことができれば、当該コンテンツがユーザに熟読されているか流し読みされているかを表す「読了率(熟読率)」を推定することが可能である。

この態様では、まず、コンテンツのロード時等に、コンテンツにおける本文(当該コンテンツ以外の広告やコンテンツのナビゲーションバー等以外の部分。)がどの部分かを推定する。この際には、各種の本文抽出技術を採用することが可能であるが、たとえば、あらかじめ、本文に相当する部分に、特定の属性を有するタグを付与しても良い。

このほか、コンテンツ本文がDOMツリー内のどの部分かを推定する手法として、以下のようなものもある。すなわち、コンテンツを画面表示したと仮定したときの横幅と縦幅を取得し、当該横幅と縦幅に基づいて、コンテンツの画面表示を左上、右上、左下、右下の４つの領域に分割し、ウェブ文書のノードのうち、左上(あるいはその他の領域)に表示されるノードを抽出し、当該ノードの先頭が画面表示される領域であって画面の中央を含む領域の面積を求め、当該面積が所定の範囲に含まれるノードもしくは最大のノードを本文のスタートノードとする。

そして、当該コンテンツ本文の各要素(タグ単位でも良いし、文字単位や単語単位、行単位でも良い。)について、当該各要素がユーザから見える状態にあった可読時間長を積算するのである。

すなわち、コールバック関数内では、コンテンツ本文の各要素が、「ウィンドウ等内に描画されるべき位置に配置されており、かつ、当該コンテンツがユーザから閲覧されていると判断されている」か否か、すなわち、可読状態にあるか否かを判定する。可読状態であれば、タイムスタンプの最新の時間間隔を、現在ウィンドウ等内に描画されるべき位置に配置されている各要素の可読時間長に山分けする。山分けの際には、当該要素の種類がテキストか静止画か動画か、テキストであれば文字の種類や文字列の長さ等に基づいて、静止画や動画であれば表示サイズ等に基づいて、重み付けを行っても良い。また、ブラウザ画面内にて上方に表示されているものと、下方に表示されているものと、では、上方の重みを大きくしても良い。ユーザは、先頭からコンテンツを読むのが通例だからである。スクロールされた後も、要素が現在画面内のどこに配置されているのかを調べ、それに応じて、山分けの重みを算定することができる。このように、最新およびその前回のコールバック呼び出しでユーザがコンテンツが閲覧されていると判定されていれば、両者の差分が山分けされる。

一方、最新およびその前回の少なくともいずれか一方では、コンテンツが閲覧されていないと判定されていれば、差分の山分けは行わない、とするのが最も単純である。これは、コンテンツをユーザが閲覧しているときには、コールバック関数の呼び出しが頻繁に行われるため、ユーザから見えるか否かの切り替えタイミングにおける誤差を無視できるからである。

また、可読でない状態から可読状態に切り替わった際には山分けは行わないが、逆の場合には、山分けを行うこととしても良いし、差の半分の時間を山分けすることとしても良い。

その上で、各要素に山分けされて蓄積された可読時間長が、当該要素の種類に応じた読了時間長を超えているか否かにより、当該要素が読了済みか否かを同定する。読了時間長は、文字の種類や文字列の長さ、動画や静止画のサイズや再生時間等に基いて、人間の平均的な読了時間の統計から求めても良いし、ユーザごとに過去の閲覧の様子等から求めることとしても良い。
これらの統計を蓄積する際には、どの要素がいつ表示されていたかを調べる必要があるが、これらの情報もコールバック関数にて収集することが可能である。

一般に、人間のコンテンツに対する姿勢は、流し見、熟読、表示のまま放置の3通り程度に分類できると考えられる。そこで、コンテンツがユーザに見える状態になっているか否かを、上記実施形態により判定し、当該コンテンツが見える状態となっていた総時間長を求めた上で、上記の統計処理をユーザ全体あるいはユーザ単位で行えば、閾値や読了時間長を求めることができる。

最後に、コンテンツ本文に含まれる要素のうち、どれだけの割合の要素が読了済みかを同定することにより、読了率を計算する。計算された読了率は、コンテンツが見えるか否かの判定結果とともにサーバに送信するのが典型的である。

上記実施例のように、コンテンツがユーザに閲覧されているか否かならびに当該コンテンツの読了率(熟読度)が正確に推定でき、その情報がサーバでほぼリアルタイムで取得できるようになると、以下のような広告を行うことが可能となる。

まず、コンテンツを閲覧可能に滞在していた時間長や、コンテンツの読了率(熟読度)に応じて、適切な広告、SEO対策を施す、というものである。従来のページビューや滞在時間単位での分析に比べて、より正確な分析が可能となり、効果の高い対策を施すことが可能となる。また、本実施例で得られる閲覧の成否、閲覧の時間長、熟読度に応じて、広告料を算定することも可能である。

さらに、コンテンツが閲覧されている瞬間や、コンテンツを読了した直後、コンテンツがほぼ読了された時点等に、サーバからブラウザへ、時間限定クーポン等の広告をプッシュする、という手法である。プッシュは、自動的に行うこととしても良いし、ユーザの閲覧行動をサーバで観察して、サーバ運営者が行うこととしても良い。この態様では、ユーザの閲覧行動に応じてきめ細かく広告を行うことができ、高い広告効果が期待できる。

時間限定クーポン等の広告は、必ずしもプッシュによる必要はない。すなわち、スクリプトプログラムのコールバック関数は、読了率等を計算するとともに、読了率と広告表示用の閾値とを比較する。そして、読了率が広告表示用の閾値を超えていたら、コールバック関数は、サーバから広告を取得して、当該広告を、コンテンツ内にポップアップ表示、もしくは、ユーザが現在見ている箇所の付近に挿入すれば良い。

広告を挿入もしくはポップアップ表示する箇所は、以下のように定めることができる。図3は、本発明の実施例におけるコンテンツの表示例である。なお本図では、各要素の位置および大きさを示すため、当該要素を囲む点線を示しているが、当該点線は、実際のブラウザ画面には表示されない。

そして、プログラムは、コンテンツの本文に相当する部分に含まれる要素の可読時間長が、当該要素の読了時間長を超えているか否か、すなわち、当該要素が読了されているか否かを先頭から並べる。

図4は、本発明の実施例におけるコンテンツの要素の既読、未読の状態を表す説明図である。本図においては、読了済の部分については、背景に斜線を引いている。超えている要素が連続している状態から、超えていない要素が連続している状態へ変化する切れ目の箇所を探す。この箇所は、現在ユーザがコンテンツを読んでいると推定される箇所である。

プログラムは、広告を、当該箇所の直前に挿入することができる。また、読了済の要素がブラウザ画面に表示されている領域を同定した上で、広告を、当該領域の末尾にオーバレイ表示、あるいは、ポップアップ表示しても良い。図5は、本発明の実施例におけるコンテンツおよびポップアップ広告の表示例である。本図に示すように、ポップアップ表示が、まだ読了していない要素、ならびに、既存のバナー広告等を隠さないように配置することが望ましい。また、ポップアップ表示の位置は、できるだけ未読要素の近くが望ましい。その付近が、現在ユーザが注目しているところと推定されるからである。

未読要素の近く、とは、切れ目の直前や、切れ目の前の行などである。本図では、切れ目の前の行の下端にポップアップ広告の下端が接し、切れ目の中央とポップアップ広告の中央が一致するように、ポップアップ広告を配置している。ただし、間隔を置いてポップアップ広告を表示したり、ポップアップ広告が切れ目の直前に入らない大きさの場合には前の行に配置する、等、ポップアップ位置は、適宜変更が可能である。

上記のように、読了済の要素とまだ読了していない要素の切れ目の付近に、まだ読了していない要素を隠さないように、広告を表示することで、ユーザの困惑を防止することができる。

なお、広告表示用の閾値や、広告のポップアップ表示等の手法ならびに場所については、種々の態様をある程度ランダムに採用し、各態様についてコンバージョンレート等を測定して、最も率の高い態様を採用する確率を高くする、等の自動調整を行っても良い。自動調整は、ユーザ単位で行っても良いし、アクセスするユーザ全体で処理しても良い。

本実施例によれば、各要素の可読時間長やコンテンツの読了率を分析し、広告等を適切に提供することができるようになる。

本実施例では、上記実施例におけるスクリプトプログラムを配布され、実行される態様について説明する。本発明においては、スクリプトを配布するサーバと、コンテンツを配布するサーバと、として、同じサーバを利用しても良いが、異なるサーバを利用しても良い。そこで、以下では、前者をスクリプトサーバ、後者をコンテンツサーバと呼ぶこととする。

図2は、本発明の実施例における通信の様子を表すセッション図である。以下、本図を参照して説明する。

まず、端末で動作しているブラウザをユーザが操作することによって、ブラウザからコンテンツサーバへコンテンツを取得するためのコンテンツ要求が送信される(201)。当該操作として典型的なものは、既にブラウザに表示済みの他のコンテンツに示されたリンクを選択したり、ブラウザのアドレスバーにURL(Universal Resource Locator)を直接入力したり等である。

コンテンツ要求を受信したコンテンツサーバは、当該コンテンツ要求に応じたコンテンツを指定したコンテンツ応答を、端末へ送信する(202)。当該応答に指定されるコンテンツは、典型的にはHTML(Hyper Text Markup Language)形式のページであり、当該HTML内には、端末にて当該ページをロードする際に読み込むべきスクリプトプログラムが配布されるURLが記述されている。典型的には、スクリプトプログラムは、JavaScript (登録商標)で記述される。

コンテンツ応答を受信した端末にて、ブラウザは、コンテンツの描画処理を開始する。この処理において、スクリプトプログラムのURLが発見されると、端末は、スクリプトプログラムを取得するためのスクリプト要求を、スクリプトサーバに送信する(203)。

スクリプト要求を受信したスクリプトサーバは、当該スクリプト要求に応じたスクリプトプログラムを指定したスクリプト応答を、端末へ送信する(204)。

スクリプト応答を受信した端末にて、ブラウザは、コンテンツのonloadイベントに対して指定されたonload処理を実行する。このonload処理において、当該スクリプトプログラムに指定されたコールバック関数をウィンドウもしくはタブのwindow.requestAnimationFrameメソッドにて実行するための登録を行う。

この後は、端末のブラウザにて上記の処理を行い、間欠的に、端末からスクリプトサーバへ、現在当該コンテンツが閲覧されているか否かの判定結果や、当該コンテンツの読了率等の情報を指定した報告が送信される(205)。

このように、本実施例によれば、コンテンツの提供者は、提供するコンテンツ内で、スクリプトプログラムのURL指定ならびにonloadイベントにおけるコールバック関数登録の処理を指定すれば良い。これらの指定は、極く短いHTMLの断片テンプレートをコンテンツに埋め込むだけで良い。

コンテンツの閲覧の有無や読了率などの情報は、スクリプトサーバにて統計処理された後、コンテンツの提供者へ伝達される。このため、コンテンツの提供者は、自身が提供するコンテンツの反応について、適切な分析を行うこともできる。

なお、スクリプトの記述によっては、端末からの報告の送信先を、コンテンツサーバにすることも可能である。この態様では、上記のように、閲覧者の行動をコンテンツサーバが観察して、コンテンツの読了が近付いた時点で、時間限定クーポン等のプッシュを行うこととしても良い。

本実施例では、コンテンツ本文を表現した本文ノードが、コンテンツのDOMツリー内のどのノードかを推定するための、上記実施例とは異なる手法を説明する。

まず、上記実施例と同様に、コンテンツを、現在のブラウザ画面に画面表示したと仮定して、DOMツリーのうち、ファーストビューにおいて表示されるノードを抽出する。

そして、候補ノードがファーストビューのブラウザ画面内にて描画される領域の面積を計算して、面積が最大のノードを、候補ノードとする。

その上で、当該候補ノードについて、面積条件「ノードの描画面積が、当該ノードの親ノードの描画面積のZパーセント以上であり、かつ、当該ノードの子ノードの描画面積は、いずれも、当該ノードの描画面積のZパーセント未満である」を満たすノードを、本文ノードとする。ここで、定数Zは、多数のコンテンツを適用した実験等によって定めることができ、現在広く閲覧されているコンテンツにおいては、65-75程度とするのが好適である。

候補ノードの抽出と、本文ノードの検索は、コンテンツのDOMツリーのbodyノードから、深さ優先探索もしくは広さ優先探索を行うことによって行うことができる。すなわち、bodyノードの子ノードのうち、ファーストビューにおける描画面積が最大のノードが上記の面積条件を満たすか否かを判定し、満たすものがあれば、当該ノードを本文ノードとする。面積条件を満たさない場合には、当該ノードの子ノードのうち、ファーストビューにおける描画面積が最大のノードが上記の満たすか否かを判定し、満たすものがあれば、当該ノードを本文ノードとする、という探索処理を繰り返すのである。

なお、画面レイアウトやページ冒頭の広告サイズ等を考慮して、描画面積については、ファーストビューにおいて画面に表示される面積ではなく、当該コンテンツのすべてが表示されたときの各ノードの描画面積を採用しても良い。また、探索の際には、bodyノードの子ノードのうち、ファーストビューでブラウザ画面に表示されるべきノードから探索を始めることとしても良い。ただし、上記実施例と同様に、ファーストビューでブラウザ画面に表示されるべきノードのうち、ブラウザ画面を4分割した左上の領域に表示されるべきノードから、探索を始めることとしても良い。

本実施例によれば、特別なタグなどを用意しなくともコンテンツの本文を自動的に判別することができ、コンテンツに付随する広告や各種ナビゲーション要素などの影響を抑制して、コンテンツの本文についての読了率を、より正確に調査することができるようになる。

上記実施例では、window.requestAnimationFrameメソッドによってコールバック関数を登録し、当該関数が呼び出される間隔によって、コンテンツがユーザに見えるように表示されているか否かを判定していたが、昨今のブラウザで実装されているpage visibilityの機能を利用して、判定を行っても良い。

この機能を利用するためには、visibilitychangeイベントに対するハンドラ関数等を利用することができる。visibilitychangeイベントが生じると、ハンドラ関数が呼び出され、当該ハンドラ関数内では、document.visibilityStateを調べる。この属性が"visible"であれば、当該ページは現在可読であり、"hidden"や"prerender"であれば、当該ページはまだユーザが見ることができない状態となっている。visibilitychangeイベントは、間欠的に発生する。

さらに、このハンドラ関数を間欠的に実行するように、setInterval()を用いて登録を行っても良い。document.visibilityStateが"visible"であれば、現在ブラウザ画面内に描画されている要素の可読時間長の積算を行えば良い。

なお、このような機能は、ブラウザごとに仕様が異なることもある。そこで、ブラウザの種類がサーバにて確認できない場合等には、スクリプトは、window.requestAnimationFrameによる手法とpage visibilityによる手法の両方を併用して各要素の可読時間長の積算を行い、両者のずれを調べる。そして、そのずれが小さいようであれば、window.requestAnimationFrameとpage visibilityのいずれか一方の手法を利用するように、動作を変更するとともに、その旨をサーバに報告する。

サーバは、報告を受けて、当該種類のブラウザではwindow.requestAnimationFrameとpage visibilityのいずれの手法を使用すべきかを決定し、これ以降に、当該種類のブラウザでスクリプトが実行される際には、当該決定された手法を使わせるように、設定を変更する。

本実施例によれば、ブラウザの種類に応じて、window.requestAnimationFrameとpage visibilityのいずれを使用すべきかを適切に判定することができる。

コールバック関数やハンドラ関数で、以下のような処理を実行することにより、ページが再度可読状態となった契機は、当該ページからほかのページに遷移した後にブラウザの「戻る」ボタンを操作したからなのか、それとも、ウィンドウやタブの切替によるものなのか、をある程度推定することができる。

すなわち、「戻る」ボタンを操作した場合には、特に動的に変化するコンテンツでは、コンテンツが閲覧当初の内容に戻されるブラウザが多い。

一方、ウィンドウやタブの切替では、過去にブラウザ画面に表示されていた状態と、今再度可読状態となったときに表示される状態と、は、一致する。

そこで、本実施形態では、プログラムは、コンテンツ本文のブラウザ画面における描画位置や描画サイズをJavaScript(登録商標)の変数やクッキー内に格納する。

コンテンツが非可読状態から可読状態へ切り替わったときに、プログラムは、以前に最後に可読状態だったときのコンテンツ本文の描画位置や描画サイズとの差異を調べる。

そして、プログラムは、両者が異なっていれば、「戻る」ボタンの操作によって可読状態に変化したと推定する。一致していれば、ウィンドウやタブの切替によって、可読状態に変化したと推定する。

本実施例によれば、あるコンテンツから一時的に他のコンテンツへ遷移した後に、当該コンテンツに戻る、というユーザの行動を分析することができ、ユーザの行動に応じて、コンテンツの構成を調整することができるようになる。

(まとめ)
以上説明した通り、上記の実施形態に係るプログラムは、
端末で動作するブラウザのウィンドウもしくはタブに表示されるコンテンツに対応付けられるプログラムであって、前記端末は、前記プログラムを実行することにより、
前記ウィンドウもしくはタブに前記コンテンツがロードされる際に、前記ウィンドウもしくはタブに割り当てられたwindow.requestAnimationFrameメソッドにより前記プログラムにより定義されるコールバック関数を登録し、
前記コールバック関数が呼び出されると、前記ウィンドウもしくはタブについて当該コールバック関数が呼び出されたタイムスタンプの間隔に基づいて、当該ウィンドウもしくはタブがユーザに閲覧されているか否かの判定をし、当該ウィンドウもしくはタブに割り当てられたwindow.requestAnimationFrameメソッドにより当該コールバック関数を再登録し、
間欠的に、前記判定の結果をサーバに通知する。

また、前記端末は、前記プログラムを実行することにより、
前記コールバック関数が呼び出されると、前記判定の結果ならびに当該判定がされた時点で前記コンテンツに含まれる各要素が前記ウィンドウもしくはタブ内に閲覧可能に描画されているか否かにより、前記コンテンツに対する読了率を求め、
間欠的に、前記求められた読了率を前記サーバに通知する
ように構成することができる。

また、前記端末は、前記プログラムを実行することにより、
前記コールバック関数が呼び出されると、前記判定の結果ならびに当該判定がされた時点で前記コンテンツに含まれる各要素が前記ウィンドウもしくはタブ内に閲覧可能に描画されているか否かにより、当該各要素が読了済であるか否かを求め、
前記コンテンツに対する読了率が閾値を超えると、読了済の要素と未読の要素との切れ目を同定し、
当該切れ目に広告を挿入、もしくは、当該読了済の要素のみに重なるように当該切れ目の前方に広告をポップアップ表示する
ように構成することができる。

上記の実施形態に係るプログラムは、端末で動作するブラウザのウィンドウもしくはタブに表示されるコンテンツに対応付けられるプログラムであって、前記端末は、前記プログラムを実行することにより、
間欠的に、当該ウィンドウもしくはタブがユーザに閲覧されているか否かの判定をし、
前記判定の結果ならびに当該判定がされた時点で前記コンテンツに含まれる各要素が前記ウィンドウもしくはタブ内に閲覧可能に描画されているか否かにより、前記コンテンツに対する読了率、ならびに、当該各要素が読了済であるか否かを求め、
前記コンテンツに対する読了率が閾値を超えると、読了済の要素と未読の要素との切れ目を同定し、
当該切れ目に広告を挿入、もしくは、当該読了済の要素のみに重なるように当該切れ目の前方に広告をポップアップ表示する。

本発明は、本発明の広義の精神と範囲を逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施の形態は、この発明を説明するためのものであり、本発明の範囲を限定するものではない。すなわち、本発明の範囲は、実施の形態ではなく、特許請求の範囲によって示される。そして、特許請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、この発明の範囲内とみなされる。

本願では、平成26年(2014年)2月28日(金)に日本において出願された特許出願特願2014-037875を基礎とする優先権を主張し、当該基礎とされた出願にて開示されたすべての事項を、参照として本願に取り込むものとする。

本発明によれば、ブラウザのウィンドウもしくはタブに表示されるコンテンツがユーザに閲覧されているか否かを判定するプログラムを提供することができる。

Claims (4)

1. 端末で動作するブラウザのウィンドウもしくはタブに表示されるコンテンツに対応付けられるプログラムであって、前記端末は、前記プログラムを実行することにより、
   前記ウィンドウもしくはタブに前記コンテンツがロードされる際に、前記ウィンドウもしくはタブに割り当てられたwindow.requestAnimationFrameメソッドにより前記プログラムにより定義されるコールバック関数を登録し、
   前記コールバック関数が呼び出されると、前記ウィンドウもしくはタブについて当該コールバック関数が呼び出されたタイムスタンプの間隔に基づいて、当該ウィンドウもしくはタブがユーザに閲覧されているか否かの判定をし、当該ウィンドウもしくはタブに割り当てられたwindow.requestAnimationFrameメソッドにより当該コールバック関数を再登録し、
   間欠的に、前記判定の結果をサーバに通知する
   ことを特徴とするプログラム。
2. 請求項1に記載のプログラムであって、前記端末は、前記プログラムを実行することにより、
   前記コールバック関数が呼び出されると、前記判定の結果ならびに当該判定がされた時点で前記コンテンツに含まれる各要素が前記ウィンドウもしくはタブ内に閲覧可能に描画されているか否かにより、前記コンテンツに対する読了率を求め、
   間欠的に、前記求められた読了率を前記サーバに通知する
   ことを特徴とするプログラム。
3. 請求項2に記載のプログラムであって、前記端末は、前記プログラムを実行することにより、
   前記コールバック関数が呼び出されると、前記判定の結果ならびに当該判定がされた時点で前記コンテンツに含まれる各要素が前記ウィンドウもしくはタブ内に閲覧可能に描画されているか否かにより、当該各要素が読了済であるか否かを求め、
   前記コンテンツに対する読了率が閾値を超えると、読了済の要素と未読の要素との切れ目を同定し、
   当該切れ目に広告を挿入、もしくは、当該読了済の要素のみに重なるように当該切れ目の前方に広告をポップアップ表示する
   ことを特徴とするプログラム。
4. 端末で動作するブラウザのウィンドウもしくはタブに表示されるコンテンツに対応付けられるプログラムであって、前記端末は、前記プログラムを実行することにより、
   間欠的に、当該ウィンドウもしくはタブがユーザに閲覧されているか否かの判定をし、
   前記判定の結果ならびに当該判定がされた時点で前記コンテンツに含まれる各要素が前記ウィンドウもしくはタブ内に閲覧可能に描画されているか否かにより、前記コンテンツに対する読了率、ならびに、当該各要素が読了済であるか否かを求め、
   前記コンテンツに対する読了率が閾値を超えると、読了済の要素と未読の要素との切れ目を同定し、
   当該切れ目に広告を挿入、もしくは、当該読了済の要素のみに重なるように当該切れ目の前方に広告をポップアップ表示する
   ことを特徴とするプログラム。

Images