JP3961213B2 - An e-commerce system that tracks user activity - Google Patents

Description

【００１５】
一方、イベント・ページ上のＨＴＭＬイメージ・ソース・タグは、以下のデータを含んでいる。
・トラッキング・サーバ……マシーン処理トラッキングのアドレス（例えば、ｈｔｔｐ：／／ｖａｌｕｅｃｏｍｍｅｒｃｅ．ｃｏｍ／）
・マーチャントＩＤ……ＥＣサイトのＩＤ（例えば４００５）
・ユーザのＩＰアドレス……ユーザ端末のＩＰアドレス（例えば、２１０．１３３．４７．８４）
・トランザクション量……トランザクションの総量（例えば５２５０）
・トランザクションＩＤ……マーチャントが供給するトランザクションのＩＤ（例えば、３３）
・通貨……トランザクションの通貨（例えば、ＪＰＹ）
・アイテム数……トランザクション内のアイテム数（例えば、２）
・製品ＩＤ……トランザクションにおける製品アイテムのＩＤ（例えば、ＢＲＡＣＥＬＥＴ１，Ｒｉｎｇ３）
・支払い方法……支払い方法（例えば、ＶＩＳＡ）
・クライアント名……クライアントの名前（例えば、ヤマダタロウ）
・クライアント電子メール……クライアントの電子メール・アドレス（例えば、ｔａｒｏｕ＿ｙ＠ａｂｃ．ｎｅ．ｊｐ）
・クライアント電話……クライアントの電話番号（例えば、０３-５５５-６６６６）
【００１６】
イベント・ページ上のＨＴＭＬイメージ・ソース・タグの一例は、以下のように表される。

【００１７】
次に、本発明によるトラッキング・システムにおけるトラッキング動作について、図３及び図４を参照することによって説明する。トラッキング・プロセスは、ユーザ端末１すなわちユーザのブラウザが、パートナー・サイト３のウェブ・ページ上においてユーザがあるバナー上でクリックした後に、ＥＣサイト２上のエントリ・ページにリダイレクトされた、即ち、回帰(bound)されたときに開始される。パートナー・サイト３からのリダイレクト・メッセージは、以下のパラメータを含んでいなければならない。
・プロファイルＩＤ……クリックされたバナーが属するプロファイルのＩＤ
・サイトＩＤ……パートナー・サイトのＩＤ
・アバートＩＤ（ＡＩＤ）……クリックされたバナーのＩＤ
【００１８】
エントリ・ページは、ユーザ端末１上でブラウジングされる前に、トラッキング・サーバ・ブロック４１のトラッカ・サーブレット４１１によて常にチェックされるように設定されており、したがって、ユーザのブラウザは、ステップＡにおいてリクエストを送ることにより、トラッカ・サーブレット４１１から、それが考えているイメージをロードしようとする。リクエストは、パートナー・サイト３からのリダイレクト・メッセージに含まれるＰＩＤ、ＳＩＤ及びＡＩＤを含む、ＨＴＴＰ ＧＥＴ ＴＲＡＣＫＥＲリクエストである。必要であれば、これはクッキー等も含む。トラッカ・サーブレット４１１は、リクエストを取り込み、このリクエストの中に「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」メッセージがあるか否かについてチェックする。これがない場合、長い値を有する「Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ−Ｔｉｍｅ（ＬＭＴ）」キーを、ユーザのセッションを表すユニークＩＤとして作成する。ＬＭＴキーは、セッションが行われる日付（即ち時点）を表すが、日付に限定される訳ではない。
【００１９】
次に、トラッカ・サーブレット４１１は、ステップＢ１において、ユーザ端末１へＬＭＴキーを有するＧＩＦイメージを含む応答を送る。ＧＩＦイメージは、エントリ・ページ内に挿入され、ユーザ端末１においてブラウジングされる。ＧＩＦイメージ及びＬＭＴキーは、ユーザのブラウザ・キャッシュ内に記憶される。
ステップＢ１と同時に、又はステップＢ１において応答が送られるとすぐに、トラッカ・サーブレット４１１は、ステップＡで受信したリクエストに関連するパラメータから、関連するセッション情報の全てを抽出する。次に、抽出したパラメータ及びＬＭＴキーを、セッション・データ・オブジェクトに封入し、ステップＢ２２においてクライアント４１３に送る。クライアント４１３は、図４におけるセッション管理ボックス４２のサーバ４２１に、セッション・データ・オブジェクトを送信して、セッション・キャッシュ４２８に格納させる。
【００２０】
セッション・データは、以下のエレメントで構成されている。
・ＬＭＴ（最後に変更した時刻）……日付として解釈可能な整数（例えば、８５８９６９９５５０００）
・ＩＰアドレス……ユーザ端末のＩＰアドレス（例えば、２１０．１３３．４７．８４）
・クッキー……クッキーが要求の中で発見されたか否かを示す値
・リファーラ(参照元)……イメージ・ソース要求を送ったホームページのＵＲＬ（パラメータを含む）
（例えば、”ｈｔｔｐ／／ｔｒａｖｅｌｌｅｒ．ｖａｌｕｅｃｏｍｍｅｒｃｅ．ｃｏ．ｊｐ．／ＣａｓａｄｅＰｌａｔａ／ＭａｉｎＦｒａｉｍ．ｈｔｍ？ＰＩＤ＝３００１＆ＳＩＤ＝３００２＆ＡＩＤ＝３００３”）
・アドバートＩＤ……（前述を参照）
・サイトＩＤ……（前述を参照）
・プロファイルＩＤ……（前述を参照）
・マーチャントＩＤ……（前述を参照）
・タイム・スタンプ……セッションの作成時刻
・ブラウザ・エージェント……トラッカ・サーブレットにリクエストを行なったブラウザ・エージェント（例えば、”Ｍｏｚｉｌｌａ／４．７２［ｅｎ］（ＷｉｎＮＴ；１）”）
【００２１】
後のある時点において、ユーザは、ＥＣサイト２のホームページ上のマーチャントとトランザクションを行い、その結果、トランザクション完了ページ即ちイベント・ページをブラウジングする。しかしながら、基本的に、ＥＣサイト２内にありトラッカ・サーブレット４１１に対するイメージ・ソース・リクエストを含むページであれば、他の任意のものでもよい。ＥＣサイト２は、完了したばかりのトランザクションと関連するデータが、トランザクション・サーブレット４１１へのリクエストに関連するパラメータ・ストリング内に置かれるように、そのシステムを設定しておかなければならない。したがって、ステップＣにおいて、ＨＴＴＰ ＧＥＴ ＴＲＡＮＳＡＣＴＩＯＮを含むリクエストにより、そのパラメータを含むトランザクション・データの全てがトランザクション・サーブレット４１２に渡される。トランザクション・データの構造については、トランザクション完了ページ上のイメージ・ソース・タグを参照して既に説明した。
【００２２】
トランザクション・サーブレット４１２がトランザクション・データを受信すると、それに応答して、着信したパラメータからマーチャントＩＤ（ＭＩＤ）を抽出する。次に、ステップＤ１において、トランザクション・サーブレット４１２は、着信したパラメータを用いて、ユーザのブラウザをトラッカ・サーブレット４１１にリダイレクトする。この時、エントリ・ページにおいてトラッカ・サーブレット４１１にリクエストしたときに用いたのと全く同じシンタックスが利用される。
ステップＤ１におけるリダイレクトを行なった後、トランザクション・サーブレット４１２は、ステップＣにおいて、リクエストに関連するトランザクション・データ（パラメータ及び種々のヘッダを含む）を解析し、これらをトランザクション・データ・オブジェクトに纏め、ステップＤ２においてクライアント４１３に受け渡す。クライアント４１３は、トランザクション・データ・オブジェクトを、セッション管理ボックス４２のサーバ４２１に転送する。
【００２３】
次に、ステップＥにおいて、ユーザのブラウザは、ＬＭＴキーを含むＨＴＴＰＧＥＴ ＴＲＡＣＫＥＲリクエストを送信する。これは、セッションのユニーク・ＩＤであり、ブラウザ・キャッシュ内のＧＩＦイメージと関連付けて格納されていたものである。その理由は、トランザクション・サーブレット４１２によって送られるリダイレクションは、エントリ・ページにおいてユーザのブラウザによってリクエストされたものと全く同一であり、ブラウザは、このリクエスト（ＧＩＦイメージ）の結果が変化したか否か確認するために常にチェックするように指示されているからである。トラッカ・サーブレット４１１は、ブラウザが最新バーションのイメージを表示しているか否かをチェックするためにこれを用いることができるので、この情報を明示的に供給しているが、ユーザを識別するために把握される。
【００２４】
したがって、トラッカ・サーブレット４１１は、着信したＬＭＴキー・ヘッダを取得し、同一のＬＭＴキーを有するイメージを返送して、すべてのトラッキング・プロセスを継続し、更に、イベント・ページ内にＡＩＤ／ＰＩＤ／ＳＩＤがないことを判定するために、トラッカ・サーブレット４１１は新たなセッション・データ・オブジェクトを作成する必要がないことを確認する。トラッカ・サーブレット４１１は、ＬＭＴキーを含む、ステップＥにおいて送られたリクエストに関連するデータを封入してヘッダ・データ・オブジェクトを作成する。ステップＦにおいて、ヘッダ・データ・オブジェクトをクライアント４１３に送ることにより、それをセッション管理ボックス４２のサーバ４２１に転送する。
【００２５】
ヘッダ・データ・オブジェクトは、セッション・データ・オブジェクトと同一であるが、ＰＩＤ、ＳＩＤ及びＡＩＤのいずれも含んでおらず、セッション管理ボックス４２は、これらをリファーラ・ページから受け取る。しかしながら、ヘッダ・データ・オブジェクトはＬＭＴキーを含んでいるので、これを用いて、以下に説明するようにヘッダ・データを正しいセッション・データと照合する。
【００２６】
セッション管理ボックス４２内のサーバ４２１が、トラッキング・サーバ・ボックス４１のクライアント４１３から着信ストリングを受信すると、図４に示すステップＧから、照合プロセスにおけるデータ・フローが開始する。着信ストリングは、セッション・データ・オブジェクト、トランザクション・データ・オブジェクト、及びヘッダ・データ・オブジェクトのいずれかである。ステップＧにおいて、サーバ４２１は受信したデータ・ストリングをメッセージ・マネージャ４２２に渡し、該マネージャは、この着信メッセージがセッション・データ・オブジェクトか、トランザクション・データ・オブジェクトか、又はヘッダ・データ・オブジェクトかを識別する。メッセージ・マネージャ４２２が着信メッセージ内にセッション・データ・オブジェクトを発見した場合、メッセージ・マネージャ４２２はオブジェクトをセッション・マネージャ・リクエストの中に包み込む。セッション・マネージャ・リクエストは、ステップＨにおいて、セッション・マネージャ４２３に送られる。セッション・マネージャ４２３は、ステップＩにおいて、追加セッション・アルゴリズムをコールすることによって、リクエストをメッセージ・マネージャ４２２からセッション・キャッシュ４２８に渡し、ここにリクエストを格納する。また、リクエストは、アルゴリズムによって、セッション・データベース４３にも格納される。
【００２７】
メッセージ・マネージャ４２２が、サーバ４２１から受信したメッセージを、トランザクション・データ・オブジェクトを含むものとして識別した場合、メッセージ・マネージャ４２２は、これをトランザクション・マネージャ・リクエストの中に包み込む。次に、ステップＪにおいて、トランザクション・マネージャ・リクエストはトランザクション・マネージャ４２５に送られる。トランザクション・マネージャ４２５は、ステップＫにおいて、追加トランザクション・アルゴリズムをコールすることにより、受信したリクエストをトランザクション・キャッシュ４２９に渡し、ここに格納する。また、リクエストは、アルゴリズムによって、トランザクション・データベース４４にも格納される。
【００２８】
メッセージ・マネージャ４２２が、サーバ４２１から受信したメッセージを、ヘッダ・データ・オブジェクトを含むものとして識別した場合、該オブジェクトをヘッダ・マネージャ・リクエストの中に包み込む。そして、ステップＬにおいて、ヘッダ・マネージャ・リクエストをヘッダ・マネージャ４２４に送る。ヘッダ・マネージャ４２４が該リクエストを受信すると、マネージャ４２４は、ステップＭにおいて、照合セッション・アルゴリズムをコールし、ヘッダ・データがセッション・キャッシュ内に現在あるセッション・データのいずれかと一致するか否かについて判定を行なう。照合セッション・アルゴリズムによって、受信したヘッダ・マネージャ・リクエスト内のクッキーに続くＬＭＴキー、次いでブラウザ−エージェント／ＩＰアドレスがチェックされる。
【００２９】
ヘッダ・データとセッション・キャッシュ４２８内のセッション・データとの間で一致が見られた場合、ステップＮにおいて、セッション・データを含むマッチ・マネージャ・リクエストが作成され、マッチ・マネージャ４２６に渡され、該マッチ・マネージャはセッション・データを更に処理する。尚、ヘッダ・データは、前述のように、ＳＩＤ／ＰＩＤ／ＡＩＤを含んでいないセッション・データと同一であり、一致したヘッダ及びセッション・データはセッション・データと同一であることを注記しておく。一方、ヘッダ・データとセッション・キャッシュ４２８のセッション・データとの間に一致が見られない場合、ステップＮ１において、ヘッダ・データがヘッダ・マッチ・マネージャ４２７に渡され、ヘッダ・データがセッション・データベース４３内のいずれかのセッション・データと一致するか否かがチェックされる。ヘッダ・マッチ・マネージャ４２７がデータベース４３内に一致するセッションを発見した場合、一致したセッション・データを含むマッチ・マネージャ・リクエストを作成する。次いで、ステップＮ２において、このリクエストをマッチ・マネージャ４２６に渡し、該マネージャが更に処理を進める。
【００３０】
最後に、マッチ・マネージャ４２６は、ステップＯにおいて、照合トランザクション・アルゴリズムをコールし、正しいブラウザ−エージェント／ユーザＩＰアドレスの組み合わせをチェックすることにより、セッション・データをトランザクション・キャッシュ内のトランザクション・データと照合する。セッション・データがクッキーを含む場合、マッチ・マネージャ４２６によるチェックも受ける。次に、マッチ・マネージャ４２６は、新たにセッション及びトランザクション・データの組み合わせを格納することによって、トランザクション・データベース４４を更新する。
このようにして、セッション情報及びトランザクション情報を正しく組み合わせることができ、したがって、ＥＣシステムにおけるユーザのアクティビティは、ほぼリアル・タイムに、しかもＥＣサイトにおいて複雑なプログラムのインストールを全く行なうことなく、把握することができる。
【図面の簡単な説明】
【図１】本発明に係る、インターネット上の電子商取引システムにおいてユーザのアクティビティをトラッキングするシステムを示す説明図である。
【図２】図１に示すトラッキング・サーバ・サイトの構成を示す図である。
【図３】図２に示すトラッキング・サーバ・サイトにおけるトラッキング・サーバ・ボックスの構成を、その中のデータ・フローと共に示す図である。
【図４】図２に示すトラッキング・サーバ・サイトにおけるセッション・マネージャ・ボックスの構成を、その中のデータ・フローと共に示す図である。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a system for tracking user activity in an electronic transaction system on the Internet, and more particularly using an image source tag on an entry page and a transaction completion page browsed on a user terminal. And a system for tracking user activity in an electronic transaction system on the Internet.
[0002]
[Prior art]
Currently, the Internet is becoming a medium used for electronic commerce, that is, transactions involving the purchase of goods and services. In the transaction system on the Internet, a partner site (or a member site) that provides an advertisement banner to a user terminal is an advertiser or an electronic commerce site (in which an advertisement banner is inserted in the home page of the partner site). EC site) is changed according to the CPM price model or the CPC price model. EC sites may also change their partner sites depending on advertising effectiveness. Accordingly, there is a need to provide a system for tracking and analyzing user activity at partner sites and EC sites within a transaction system.
[0003]
In the conventional tracking system as described above, the EC site needs to install some program in order to grasp the user's session activity and send it along with the user's transaction data to the tracking server site. is there. This program is for example an entry program that transfers cookies to the user terminal when the user's session is switched from the partner site to the EC site, a session / transaction that sends data to the tracking server site periodically. A data (or user activity data) transmission program is included. However, installing such a program on an EC site is time consuming and problematic.
[0004]
Further, as described above, a cookie is sent from the EC site to the user terminal for tracking. However, depending on the user configuration, the cookie cannot be returned from the user terminal to the EC site. In such a case, it is impossible to track user activity.
In addition to the above, session / transaction data transmission programs are often set up to transfer data to the tracking server site once or twice a day, after which the tracking server site Stores session / transaction data and matches them with the click data of the advertising banner to identify which partner site the user visited before visiting the EC site. Therefore, the tracking server site must wait for such data to perform the matching process.
[0005]
[Problems to be solved by the invention]
The present invention has been made to overcome the problems of the prior art as described above. Therefore, an object of the present invention is to obtain session and transaction data as needed without troublesome installation at each EC site and without using cookies, and in addition, the session and transaction data can be obtained in real time. To provide a system for tracking user activity in an EC system on the Internet capable of obtaining data verification information.
[0006]
[Means for Solving the Problems]
To achieve the foregoing objectives, the present invention provides a tracking server site that tracks user activity in an electronic commerce (EC) system. The EC system includes an EC site that supplies a transaction home page to a user terminal, and a partner site that supplies an advertisement banner corresponding to the EC site to the user terminal. The tracking server site
Means for assigning a unique key to a user terminal session when the session is switched from a partner site to an EC site;
Means for receiving transaction data and a unique key from a user terminal when a transaction is completed;
Means for verifying session data and transaction data by referring to the unique key and the IP address of the user terminal;
It is characterized by comprising.
[0007]
The electronic commerce system according to the present invention is specified by the following items (1) to (15).
(1) An electronic commerce system including a tracking server site, a plurality of EC sites, a plurality of partner sites, and a plurality of user terminals, and tracking user activities.
(2) The partner site includes first storage means for storing a homepage with an advertisement banner including a partner site ID and a banner ID.
(3) Each of the EC sites includes second storage means for storing entry pages.
(4) The tracking server site includes a first image storage means in which an EC site ID and first image data are stored in association with each other, and a second image storage in which an EC site ID and second image data are stored in association with each other in advance. Means, third storage means for storing session data, fourth storage means for storing session data and transaction data in association with each other, and uni key generation means for generating a unique key in response to a request.
(5) The user terminal includes temporary storage means for temporarily storing information to be displayed on the browser.
(6) The entry page includes first set image source tag information including an EC site homepage address, a tracking server site address, and an EC site ID.
(7) In response to an information acquisition request in response to a click on the advertisement banner of the user terminal in a state where the user terminal is displaying a homepage with an advertisement banner supplied by the partner site, the user terminal Sends first request information including partner site ID and banner ID to the EC site.
(8) When the EC site receives the first request information from the user terminal, the EC site specifies an entry page specified by the banner ID included in the first request information from the first storage unit. Supplying
(9) The user terminal receives the entry page from the EC site, and transmits second request information including first set image source tag information included in the entry page to the tracking server site.
(10) In response to receiving the second request information from the user terminal, the tracking server site acquires a unique key from the unique key generation unit, and the EC site ID, the user terminal IP address, and the Session data including a unique key is created and stored in the third storage means, and the first image data specified by the EC site ID in the first set image source tag information included in the second request information is Extracted from the first image storage means and transmitted to the user terminal together with the unique key
(11) In response to receiving the first image data and the unique key from the tracking server site, the user terminal displays the entry page in which the first image data is incorporated, and the first image Performing a process of storing the unique key in the temporary storage means in association with data
(12) Upon completion of a transaction with the user terminal, the EC site includes a second set image including an address of the tracking server site, the EC site ID, the user terminal IP address, and transaction data. Generate a transaction completion page including source tag information and send it to the user terminal
(13) The user terminal receives the transaction completion page from the EC site, and includes a second key including the second set of image source tag information and a unique key stored in association with the first image data. Sending request information to the tracking server site;
(14) The tracking server site receives the third request information from the user terminal, and stores in the stored session data based on the unique key and the user terminal IP address included in the third request information. Session data including the same unique key and user terminal IP address is extracted from, and the extracted session data and transaction data in the third request information are associated with each other and stored in the fourth storage unit, Extracting the second image data specified by the EC site ID from the second image storage means and transmitting it to the user terminal
(15) In response to receiving the second image data from the tracking server site, the user terminal performs a process of displaying a transaction completion page incorporating the second image data.
[0008]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a schematic diagram illustrating a system for tracking user activity in an electronic transaction or electronic commerce (EC) system according to the present invention. In FIG. 1, number 1 indicates a user terminal (PC) that can be connected to the Internet, 2 indicates a merchant web site or EC site, 3 indicates a member site or partner site, and 4 indicates a tracking server.・ Show the site. Although FIG. 1 shows only one user terminal 1, one EC site 2, and one partner site 3 for explanation, there are actually a plurality of these. The partner site 4 provides the user terminal 1 with an advertisement banner browsed by the user terminal 1. When the user clicks on one of the browsed advertising banners, the session of user terminal 1 is switched from partner site 2 to EC site 2 associated with the clicked advertising banner, which causes EC site 2 to A special entry page for the user terminal 1 is provided. The EC site 2 supplies a transaction completion page (or event page) to the user terminal 1 once the transaction is completed between the user terminal 1 and the EC site 2.
[0009]
Session information and transaction information are sent from the user terminal 1 to the tracking server site 4, where each is stored in a database and associated with the partner site 3 or clicked advertisement banner by matching the transaction. The associated information is then collected and stopped and stored in one of the databases. Detailed operation of tracking according to the present invention will be described later.
[0010]
FIG. 2 shows the overall architecture of the tracking server site 4. The tracking server site 4 includes a plurality of tracking server boxes 41, a session manager box 42, a session database 43, and a transaction database 44. Of course, the databases 43 and 44 may be constituted by a single common database. As shown in FIG. 3, each tracking server box 41 includes a tracker servlet 411 and a transaction servlet 412, which are used as session data from the user terminal 2 (shown in FIG. 1). And transaction data, respectively. The tracker servlet also receives a unique key representing a session and creates header data from the user terminal 1. On the other hand, as shown in FIG. 4, the session manager box 42 includes a server 421, a message manager 422, a session manager 423, a header manager 424, a transaction manager 425, a match manager 426, and a header match manager. 427, a session cache 428, and a transaction cache 429 are incorporated.
[0011]
The caches 428 and 429 include a linked list that holds data referred to later. Each of managers 422-425 and 427 maintains a vector of objects to be executed. In contrast to caches 428 and 429, which store information until it overflows, items obtained from the vector are retrieved therefrom and processed. The item from which the vector was taken is the oldest. Thus, a manager can be considered to own an in-tray and a cache can be considered to own a filing cabinet. Dividing this dichotomy is a transactional cache with a cache and a vector of things to do. The combination of cache and vector is required for multistage bi-directional processing with a database. The managers and caches in the session manager box 42 all have their own threads, and whenever a new object is added, the thread is kicked up. Each of these independent threads processes the entire vector of things to do and ensures that the cache is backed up to the database.
[0012]
EC site 2 must place a unique (unique) HTML image source tag (invisible) for the EC site on each of the entry page and the transaction completion (event) page. One of the HTML image source tags on the entry page calls a box tracker servlet 411 in the tracking server box 41, while one of the tags on the event page Call the box's transaction servlet 412, which redirects the user to the tracker servlet 411.
[0013]
The HTML image source tag on the entry page contains the following data:
Merchant home page: EC site or merchant home page address (for example, http://myshop.com/index.html)
Tracking server: Machine processing tracking address (for example, http://valuecommerce.com/)
-Merchant ID: EC site ID (for example, 4005)
[0014]
An example of an HTML image source tag on an entry page is as follows:

[0015]
On the other hand, the HTML image source tag on the event page includes the following data.
Tracking server: Machine processing tracking address (for example, http://valuecommerce.com/)
-Merchant ID: EC site ID (for example, 4005)
User IP address: IP address of user terminal (for example, 210.133.47.84)
-Transaction volume: Total transaction volume (eg, 5250)
Transaction ID: Transaction ID supplied by the merchant (eg 33)
・ Currency: Currency of the transaction (for example, JPY)
-Number of items: Number of items in the transaction (for example, 2)
-Product ID: ID of the product item in the transaction (for example, BRACELET1, Ring3)
・ Payment method …… Payment method (eg VISA)
・ Client name …… Name of the client (for example, Taro Yamada)
Client email: Client email address (eg, tarou_y@abc.ne.jp)
・ Client phone: Client phone number (for example, 03-555-6666)
[0016]
An example of an HTML image source tag on the event page is represented as follows:

[0017]
Next, the tracking operation in the tracking system according to the present invention will be described with reference to FIGS. The tracking process is redirected to the entry page on the EC site 2 after the user terminal 1, ie the user's browser, clicks on a banner on the web page of the partner site 3, ie, the regression Started when (bound). The redirect message from partner site 3 must contain the following parameters:
-Profile ID: ID of the profile to which the clicked banner belongs
・ Site ID …… Partner site ID
・ Avert ID (AID): Clicked banner ID
[0018]
The entry page is set to always be checked by the tracker servlet 411 of the tracking server block 41 before browsing on the user terminal 1, so that the user's browser is Attempts to load the image it thinks from the tracker servlet 411 by sending a request at. The request is an HTTP GET TRACKER request including the PID, SID, and AID included in the redirect message from the partner site 3. This includes cookies, etc. if necessary. The tracker servlet 411 takes in the request and checks whether there is an “if-modified-since” message in the request. If this is not present, a “Last-Modified-Time (LMT)” key having a long value is created as a unique ID representing the user's session. The LMT key represents the date (ie, time) when the session is performed, but is not limited to the date.
[0019]
Next, the tracker servlet 411 sends a response including the GIF image having the LMT key to the user terminal 1 in step B1. The GIF image is inserted into the entry page and browsed on the user terminal 1. The GIF image and LMT key are stored in the user's browser cache.
Simultaneously with step B1 or as soon as a response is sent in step B1, the tracker servlet 411 extracts all relevant session information from the parameters associated with the request received at step A. Next, the extracted parameters and LMT key are enclosed in a session data object, and sent to the client 413 in step B22. The client 413 transmits the session data object to the server 421 of the session management box 42 in FIG. 4 and stores it in the session cache 428.
[0020]
Session data consists of the following elements:
LMT (last change time): an integer that can be interpreted as a date (for example, 858896995000)
IP address: IP address of the user terminal (for example, 210.133.47.84)
Cookie: A value indicating whether the cookie was found in the request
・ Referer (referrer) …… URL of the homepage that sent the image source request (including parameters)
(For example, “http://traveller.valuecommerce.co.jp./CasadePlata/MainFraim.htm?PID=3001&SID=3002&AID=3003”)
・ Advertise ID …… (see above)
・ Site ID …… (see above)
・ Profile ID …… (see above)
• Merchant ID (see above)
・ Time stamp …… Session creation time
Browser agent: Browser agent that made a request to the tracker servlet (for example, “Mozilla / 4.72 [en] (WinNT; 1)”)
[0021]
At some later point in time, the user conducts a transaction with a merchant on the home page of EC site 2 and, as a result, browses the transaction completion page or event page. However, basically any other page may be used as long as it is a page in the EC site 2 and includes an image source request for the tracker servlet 411. The EC site 2 must have its system set up so that the data associated with the transaction just completed is placed in the parameter string associated with the request to the transaction servlet 411. Accordingly, in step C, a transaction including HTTP GET TRANSACTION causes all of the transaction data including the parameters to be passed to the transaction servlet 412. The structure of the transaction data has already been described with reference to the image source tag on the transaction completion page.
[0022]
When the transaction servlet 412 receives the transaction data, in response thereto, the merchant ID (MID) is extracted from the received parameter. Next, in step D1, the transaction servlet 412 redirects the user's browser to the tracker servlet 411 using the received parameter. At this time, the same syntax as used when making a request to the tracker servlet 411 in the entry page is used.
After performing the redirect in step D1, the transaction servlet 412 parses the transaction data (including parameters and various headers) associated with the request in step C, collects them into a transaction data object, and step The data is transferred to the client 413 in D2. The client 413 transfers the transaction data object to the server 421 of the session management box 42.
[0023]
Next, in step E, the user's browser sends an HTTP GET TRACKER request including the LMT key. This is a unique ID of the session, which is stored in association with the GIF image in the browser cache. The reason is that the redirection sent by the transaction servlet 412 is exactly the same as that requested by the user's browser on the entry page, and the browser checks to see if the result of this request (GIF image) has changed. It is because it is instructed to always check to do. The tracker servlet 411 provides this information explicitly because it can be used to check if the browser is displaying the latest version of the image, but to identify the user To be grasped.
[0024]
Thus, the tracker servlet 411 obtains the incoming LMT key header, returns an image with the same LMT key, continues all tracking processes, and further includes an AID / PID / To determine that there is no SID, the tracker servlet 411 verifies that it is not necessary to create a new session data object. The tracker servlet 411 encloses the data related to the request sent in step E, including the LMT key, and creates a header data object. In step F, the header data object is sent to the client 413 to transfer it to the server 421 of the session management box 42.
[0025]
The header data object is the same as the session data object, but does not include any of PID, SID, and AID, and the session management box 42 receives them from the referrer page. However, since the header data object contains an LMT key, it is used to match the header data with the correct session data as described below.
[0026]
When the server 421 in the session management box 42 receives the incoming string from the client 413 of the tracking server box 41, the data flow in the matching process starts from Step G shown in FIG. The incoming string is one of a session data object, a transaction data object, and a header data object. In step G, the server 421 passes the received data string to the message manager 422, which determines whether the incoming message is a session data object, a transaction data object or a header data object. Identify. If the message manager 422 finds a session data object in the incoming message, the message manager 422 wraps the object in a session manager request. The session manager request is sent to the session manager 423 at step H. In step I, session manager 423 passes the request from message manager 422 to session cache 428 by calling an additional session algorithm, where the request is stored. The request is also stored in the session database 43 by an algorithm.
[0027]
If message manager 422 identifies a message received from server 421 as containing a transaction data object, message manager 422 wraps it in a transaction manager request. Next, in step J, the transaction manager request is sent to the transaction manager 425. In step K, the transaction manager 425 calls the additional transaction algorithm to pass the received request to the transaction cache 429 for storage. The request is also stored in the transaction database 44 by an algorithm.
[0028]
If message manager 422 identifies a message received from server 421 as containing a header data object, it wraps the object in a header manager request. In step L, the header manager request is sent to the header manager 424. When header manager 424 receives the request, manager 424 calls the matching session algorithm at step M to see if the header data matches any of the session data currently in the session cache. Make a decision. The matching session algorithm checks the LMT key following the cookie in the received header manager request, then the browser-agent / IP address.
[0029]
If a match is found between the header data and the session data in session cache 428, a match manager request including session data is created and passed to match manager 426 at step N; The match manager further processes the session data. Note that the header data is the same as the session data not including the SID / PID / AID as described above, and the matched header and session data are the same as the session data. . On the other hand, if no match is found between the header data and the session data in the session cache 428, the header data is passed to the header match manager 427 in step N1, and the header data is transferred to the session database. It is checked whether it matches any of the session data in 43. If the header match manager 427 finds a matching session in the database 43, it creates a match manager request that includes the matching session data. The request is then passed to the match manager 426 at step N2, which proceeds further.
[0030]
Finally, the match manager 426 calls the matching transaction algorithm in step O and checks the correct browser-agent / user IP address combination to match the session data with the transaction data in the transaction cache. Match. If the session data includes a cookie, it is also checked by the match manager 426. The match manager 426 then updates the transaction database 44 by storing a new session and transaction data combination.
In this way, session information and transaction information can be correctly combined, so that user activity in the EC system is grasped in near real time and without any complicated program installation at the EC site. be able to.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing a system for tracking user activity in an electronic commerce system on the Internet according to the present invention.
FIG. 2 is a diagram showing a configuration of a tracking server site shown in FIG.
FIG. 3 is a diagram showing a configuration of a tracking server box in the tracking server site shown in FIG. 2 together with a data flow therein.
FIG. 4 is a diagram showing a configuration of a session manager box in the tracking server site shown in FIG. 2 together with a data flow therein.

Claims (1)

In an electronic commerce system comprising a tracking server site, a plurality of EC sites, a plurality of partner sites, and a plurality of user terminals, and tracking user activities,
The partner site includes first storage means for storing a homepage with an advertisement banner including a partner site ID and a banner ID.
The EC site includes second storage means for storing each entry page,
The tracking server site includes a first image storage unit that stores an EC site ID and first image data in association with each other; a second image storage unit that stores an EC site ID and second image data in association with each other; Third storage means for storing session data; fourth storage means for storing session data and transaction data in association with each other; and a unikey generation means for generating a unique key in response to a request,
The user terminal includes temporary storage means for temporarily storing information to be displayed by a browser,
The entry page includes first set image source tag information including an EC site homepage address, a tracking server site address, and an EC site ID.
In response to an information acquisition request in response to a click on the advertisement banner of the user terminal in a state where the user terminal is displaying a homepage with an advertisement banner supplied by the partner site, the user terminal Sending first request information including a site ID and a banner ID to the EC site;
When the EC site receives the first request information from the user terminal, the EC site supplies the user terminal with an entry page specified by a banner ID included in the first request information from the first storage unit. ,
The user terminal receives the entry page from the EC site, transmits second request information including first set image source tag information included in the entry page to the tracking server site,
In response to receiving the second request information from the user terminal, the tracking server site acquires a unique key from the unique key generation unit, and obtains the EC site ID, the user terminal IP address, and the unique key. Session data including the first image data specified by the EC site ID in the first set of image source tag information included in the second request information is created and stored in the third storage means. Extracted from the storage means and transmitted to the user terminal together with the unique key;
In response to receiving the first image data and the unique key from the tracking server site, the user terminal displays the entry page incorporating the first image data and corresponds to the first image data. In addition, the unique key is stored in the temporary storage means.
Upon completion of the transaction with the user terminal, the EC site receives the second set of image source tag information including the tracking server site address, the EC site ID, the user terminal IP address, and transaction data. Generates a transaction completion page including, sends it to the user terminal,
The user terminal receives the transaction completion page from the EC site, and receives third request information including the second set image source tag information and a unique key stored in association with the first image data. Sent to the tracking server site,
The tracking server site receives the third request information from the user terminal and, based on the unique key and user terminal IP address included in the third request information, stores the same session data from the stored session data The session data including the unique key and the user terminal IP address is extracted, the extracted session data and the transaction data in the third request information are associated with each other, stored in the fourth storage unit, and the EC site ID Extracting the second image data specified by the second image storage means and transmitting it to the user terminal;
In response to receiving the second image data from the tracking server site, the user terminal performs a process of displaying a transaction completion page incorporating the second image data.

Images