Correct way to implement visitor tracking?

[Robert Oschler]

This is my current strategy for tracking hyperlink clicking by a site
visitor (Internet Explorer example):

Using Javascript I:

Attach an event to the document "onclick" handler.
When a click occurs, the Javascript "onclick" event hander I assigned,
checks to see if the event srcElement (or its parent in the case of a "font"
element) is a hyperlink (tagName = "A" or "a").
If so, I build a URL with the search arguments set to the information I wish
to record.
I find a specific IMG element on the page and set it's SRC property to the
URL I built.

If the hyperlink opens a new window using the "_blank" target, this works
flawlessly. If however a new window is not opened, the transaction is lost.

It's as if the IMG element SRC property setting never actually happens.

Is there a way to make this work? Or do I have to create tracking codes for
each hyperlink and change all the URL's to go to a pre-emptive document that
records the click, before showing the desired web page.

thx

Robert.

 

[Lasse Reichstein Nielsen]

Attach an event to the document "onclick" handler.
When a click occurs, the Javascript "onclick" event hander I assigned,
checks to see if the event srcElement (or its parent in the case of a "font"
element) is a hyperlink (tagName = "A" or "a").

Too complicated.

Font tags are deprecated, and what about all the other things you can
put into a link?

It is easier to put an onclick event on each link:

for (var i=0;i<document.links.length;i++) {
document.links.onclick = function () { /* whatever */ };
}

If so, I build a URL with the search arguments set to the
information I wish to record. I find a specific IMG element on the
page and set it's SRC property to the URL I built.

If the hyperlink opens a new window using the "_blank" target, this works
flawlessly. If however a new window is not opened, the transaction is lost.

Yes, the new page starts loading immediately, which drops the image before
it is even requested.

It's as if the IMG element SRC property setting never actually happens.

It happens. Then it is immediately forgotten. The page that needed the image
isn't there any more, so there is no need to fetch it.

Is there a way to make this work? Or do I have to create tracking codes for
each hyperlink and change all the URL's to go to a pre-emptive document that
records the click, before showing the desired web page.

That could work. Or, if you have server side scripting anyway, you can
just let the onclick handler add something to the URL being loaded.
Something unique, like a value added to the page when it was sent,
so you can distinguish the request from a bookmark.

Still, why bother tracking clicks? Either use the referer header on the
server, or forget it if the user has turned that header off.

/L

 

[Robert Oschler]

Attach an event to the document "onclick" handler.
When a click occurs, the Javascript "onclick" event hander I assigned,
checks to see if the event srcElement (or its parent in the case of a "font"
element) is a hyperlink (tagName = "A" or "a").

Too complicated.

Font tags are deprecated, and what about all the other things you can
put into a link?

It is easier to put an onclick event on each link:

for (var i=0;i<document.links.length;i++) {
document.links.onclick = function () { /* whatever */ };
}

If so, I build a URL with the search arguments set to the
information I wish to record. I find a specific IMG element on the
page and set it's SRC property to the URL I built.

If the hyperlink opens a new window using the "_blank" target, this works
flawlessly. If however a new window is not opened, the transaction is

lost.

Yes, the new page starts loading immediately, which drops the image before
it is even requested.

It's as if the IMG element SRC property setting never actually happens.

It happens. Then it is immediately forgotten. The page that needed the image
isn't there any more, so there is no need to fetch it.

Is there a way to make this work? Or do I have to create tracking codes for
each hyperlink and change all the URL's to go to a pre-emptive document that
records the click, before showing the desired web page.

That could work. Or, if you have server side scripting anyway, you can
just let the onclick handler add something to the URL being loaded.
Something unique, like a value added to the page when it was sent,
so you can distinguish the request from a bookmark.

Still, why bother tracking clicks? Either use the referer header on the
server, or forget it if the user has turned that header off.

/L

Lasse,

Thank you for your detailed reply. One note:

Still, why bother tracking clicks? Either use the referer header on the
server, or forget it if the user has turned that header off.

I have some links that lead to external sites. I like tracking them so I
can see what my visitors are interested in, and therefore provide them more
content in those areas in the future.

That could work. Or, if you have server side scripting anyway, you can
just let the onclick handler add something to the URL being loaded.
Something unique, like a value added to the page when it was sent,
so you can distinguish the request from a bookmark.

I don't see how server scripting + URL arguments would work without an
intermediary page for off-site links. Just appending a search argument and
sending would just pass the search argument to the external destination
page, not to me. Or am I misreading something?

If I have to use the URL + "search argument" method, wouldn't I have to
create an intermediary page to intercept those links and record the tracking
info, rather than the direct links I have now? The intermediary page I
assume would then redirect them to the original link destination.

thx

 

[Lasse Reichstein Nielsen]

I have some links that lead to external sites. I like tracking them so I
can see what my visitors are interested in, and therefore provide them more
content in those areas in the future.

Some of us would call that "snooping on my browsing habits" and would
do our best to foil you scheme (or just avoid your page entirely).
I trust it you have a "privacy policy" that tells people that you log
their browsing?

I don't see how server scripting + URL arguments would work without an
intermediary page for off-site links.

Not for off-site links, no. You have to go through your own links.
I didn't think you would try to log off-site links.

Or am I misreading something?
Nope.

If I have to use the URL + "search argument" method, wouldn't I have to
create an intermediary page to intercept those links and record the tracking
info, rather than the direct links I have now?

For pages in your domain, if they are processed on the server, you
don't need a client-side redirect. You can send the new page directly,
and just log the extra information.

/L

 

[Robert Oschler]

Some of us would call that "snooping on my browsing habits" and would
do our best to foil you scheme (or just avoid your page entirely).
I trust it you have a "privacy policy" that tells people that you log
their browsing?


Not for off-site links, no. You have to go through your own links.
I didn't think you would try to log off-site links.


For pages in your domain, if they are processed on the server, you
don't need a client-side redirect. You can send the new page directly,
and just log the extra information.

/L
--
Lasse Reichstein Nielsen - (e-mail address removed)
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
========================

Lasse,

For pages in your domain, if they are processed on the server, you
don't need a client-side redirect. You can send the new page directly,
and just log the extra information.

Oh yes! I wasn't thinking there, thanks.