HitsLink – Prevent Duplicate Leads & Conversions From Being Reported


I’m a big fan of HitsLink – a third-party hosted client-side web stats service. Its similar to WebTrends, ClickTracks, Urchin, and all the others – although generally I’d classify it as a more basic offering. For many sites that makes it preferred – as its very quick to setup, is fairly flexible, and gives lots of great data. The new WebTrends 7.5 (or whatever version they are up to now) and other well-known web traffic analysis packages often can go a good bit deeper than HitsLink, but in my opinion the increased price and setup time they come with often does not justify it. I generally find that HitsLink has plenty of data for me – I barely have time to act on it… Lord knows what I would do with more data!

(Main Part of Post)

Anyhow, one issue I’ve had on many sites for a while now is that I had been getting duplicate conversions recorded in HitsLink for the same lead. Essentially it was when someone would fill out a form and maybe accidentially or (due to impatience) click “submit” twice. Or perhaps they’d fill out the form and submit, and then realize they wanted to add or correct something, so they’d hit the back button and submit the form again with a slight modification. One additional cause could be if you are using a “confirmation” page to call the conversion script, and the user decides to stick on the site for a while, maybe either refresh the confirmation page or navigate away, then hit the back button a number of times to find a previous page – during which time they would pass the confirmation page again, causing the script to be called and thus record another duplicate.

For most e-commerce sites you can plug in a unique order ID in the HitsLink conversion script:

… where you would just replace “YOUR-UNIQUE-ID” with a dynamic value generated by your e-commerce system – perhaps a sales order number or something like that. Each number is unique to that one transaction, and thus even if the script/image call was activated several times it would only count 1 conversion for each unique ID.

That’s great for e-commerce sites, but most of my clients are service businesses. They are lead generation sites. The conversion is a lead form that is not connected to any e-commerce engine, so I had no unique ID number available. Then I found a rather obvious solution. Use what you do have. Most contact forms ask for a Name, Email Address, perhaps a Phone Number, etc. Use one of those fields and pass that through. Thus, if person@email.com submitted the form and was therefore one lead, but activated the script 3 times (see above possible reasons for this), than if you used their email address – person@email.com as the unique ID it would only register the first conversion and not skew your stats. If you think about it, for most sites an email address will be unique for our purposes, unless of course your site aims to get repeat leads from the same person over time – in which case you should completely ignore this article πŸ™‚

I was elated to discover this method. I had wanted to rely on HitsLink to count leads for my sites, but I often found duplicates skewed the numbers so I’d have to manually count leads or rely on another data source.

There’s also another great benefit. Using either the email address or name or phone number makes it easier to match up the leads in your “Latest Transactions” report with what comes through either to your database or email if your contact form sends to one of those. In the past I tried to match up leads and see where each specific one (on a micro level) came from, what they searched on if they came from a search engine, etc. I had to use the time field to do this. I’d see what time the lead came in via email, and then match that up with HitsLink’s recorded time. Sometimes due to time zones or whatever else the two times might be 1-3 hours off (daylight savings, time zones, etc.) and/or also several minutes off. Thus Lead A might show 10:35 am in my email and 11:29 am in HitsLink. That’s a pain. Matching email addresses or actual names is much easier, and allows you to dig deeper to see where the “good” leads came from rather than just relying on drawing assumptions based on the macro-data.

Okay, So How?

Most forms post to some script or other page – maybe a Pearl page, ASP page, PHP page, etc. to process the form. Then, its common practice to redirect the user to a confirmation page. The processing page runs so quickly and is not displayed that to the user it just looks like they click submit and are taken to a confirmation page.

This is the method I used, and thus what I’ll describe. You can do it other ways too. Steps for this method:

1) Pick your unique ID field and make sure its going to be unique for each lead – a Name (usually unique, although you might have issues with real common names and high traffic sites), an email address (generally pretty unique), etc.

2) On your form processing page you’ll need to add a call for this value into the URL of the confirmation page. Thus, instead of redirecting to www.website.com/confirmation.php you’ll need to redirect to www.website.com/confirmation.php?unique=person@email.com where “unique” can be any parameter name you want and “person@email.com” must be a dynamic value – a call for the name of the field. In ASP you might try plugging in


into your URL. Something like this would work:

response.redirect (“http://www.website.com/confirmation.asp?unique=”&request.QueryString(“name_of_form_field_youre_using”))

Be aware that you may need to play with the syntax as your dynamic call might have apostrophes and parenthesis that cause issues. Talk to someone who knows the programming language and they should be able to give you a work around for the syntax. Once implemented, this will redirect the person to the confirmation page upon form submission, and in the URL it will pass your unique value.

3) The next step is to grab that unique value from the URL and plug it into HitsLinks confirmation image call – which is basically what records the event in HitsLink. Thus you’ll modify that script:

by plugging in the value you passed in the URL into the YOUR-UNIQUE-ID area (replace it). In our example that would look like this:


if you were to use ASP – where < %=Request.QueryString("unique")%> is the ASP call to grab the “unique” value from the URL string. That will render first server-side, such that when the HTML is loaded into the browser it will replace < %=Request.QueryString("unique")%> with person@email.com or whatever you chose, and record that into HitsLink.

Now you’ve just eliminated the chance for having your HitsLink skewed with duplicate leads from person@email.com, and you’ve also made it easier to match up the lead that was delivered to you with their campaign, search engine, search phrase, or whatever other data you want in the “Latest Transactions” report in HitsLink.

Wow that took a long time to write! I hope this helps someone or several someones!

My Other Posts About HitsLink:

By the way, I just did a Google search on hitslink and saw that their URL displayed is showing a source=Alexa parameter. In practice, that would make it look as though every visitor that actually came to their site from Google with that search (their name) was recorded as being from the “Alexa” campaign.

As a general rule of thumb I advise ONLY using source= or other campaign tracking codes on links that won’t be indexed – such as when imbedded in a script via a banner ad or on a pay-per-click ad. Those URLs aren’t indexed, and thus won’t skew your stats. HitsLink is great at making a good product, though not so sure they are great at using their own product!!! πŸ™‚

Client-Side (Cookie) Tracking vs. Server-Side (Log File) Visitor Tracking

I’m a wordy person. Email me about something I care about or have a conversation with me about most topics and you’ll find that out – perhaps to your dismay. Anyhow, this is what I’d like to do a bit more of… Use this blog to publish comments that I make in emails or other communications that may only be seen by one or a few people, and leverage that time I spend constructing those ideas by making them available here for my small but very valued readership πŸ™‚

As such, I’m pasting some recent comments I made on a post on Jason Dowdell’s Marketing Shift blog post, entitled “Cookies vs Flash for Client Side Storage“.

Cookies vs. Server Logs in Tracking

I agree with Eric’s comment. In fact, I’ve seen even greater than a 25% difference in the few large-sample-size cases I’ve studied. More like 30-45% in some instances when comparing a basic log file record versus cookie-based client side tracking.

I just switched over one site last week that gets between 6,000 and 12,000 unique visitors per day, depending upon which method you go by. The difference really was that big, which surprised me – right about a 45% lower figure with the cookies vs. the log files only. When I looked at the log files I could indeed account for maybe 20-40% of that difference as search engine bots and spiders, but couldn’t really figure out the rest.

In using the same two measurements on another fairly large site about 6 months ago I noticed a 35-40% difference – that much lower with the cookie tracking. I also used the cookie tracking to measure actual sales, (which is a metric we actually know for sure, for benchmark purposes) and it was only off by 3-4%.

Thus, its my experience that cookie methods (client side data collection) might be off in their accuracy from the “real” number of visitors by maybe 5% or so (understating totals), but log-file only (in my case I’m using this to me logs compiled from requests to the server, not client side data) methods seem to overstate traffic by as much at 40% in some cases. That’s almost too high to be even moderately meaningful!

HitsLink Campaign Tracking Issues? Try This…

First, let me just say that I love HitsLink. HitsLink is an ASP (aka hosted) web stats and visitor tracking provider. Basically, they are a competitor of sorts of WebTrends, Omniture, Coremetrics, ClickTracks and all the smaller web traffic stats companies out there. HitsLink is a bit on the lower-end in terms of price and robustness of their offering, but for most small businesses its more than adequate.

Their e-commerce version (“Enterprise” I believe is its official title) is what you really want though. Instead of just pumping money into PPC campaigns at Google and Yahoo Search Marketing (formerly Overture), as well as shopping search engines, banner ads, emails, etc. – you can now utilize HitsLink campaign tracking feature to tie actual sales to the ad campaign that drove that visitor to the site. Thus, after collecting data you learn what campaigns produce great ROI for you – and thus maybe warrant a larger budget – as well as which campaigns are real dogs and should be tweaked or shut down alltogether.

Anyhow, enough of the explanation. I use HitsLink on a number of sites, and typically the installation part is like 5 minutes, one-time, and then you never think about it again. However… I noticed an issue in moving from their “professional” edition to the “e-commerce” edition. I assumed I could keep the same script they require on each page for sending them the data. I saw nothing saying otherwise, but then again I’m not the most careful reader. I set up my campaigns with the normal syntax that had worked so well for me for other sites:


The Solution

Basically you use that link with the “?source=CampaignABC” at the end and that tells HitsLink what campaign to associate the visitor and any resulting sale with. Fair enough. Worked great for me on several sites. But for some reason for a couple of sites that I upgraded from the base version to advanced (base does not have campaign tracking feature) I couldn’t get it to work…

Then the lightbulb went off. Maybe the script on each page is different, depending upon the version of HitsLink you have. Bingo. The change in the roughly 20 line javascript is very small, but it is something. As soon as I went back and refreshed my scripts on each site with what was in the HitsLink interface and published the changed files to the sites they began picking up campaign activity. Thus, if you seem to have trouble getting campaign tracking to actually show any campaign traffic and sales stats, it may not be your URLs but rather the main javascript that goes in your footer. Try replacing it with the most current one that should be in your Account > Setup > Get Tracking Script menu in your HitsLink interface.

Traffic + Conversion = Success

An “SEO” focuses about getting more qualified traffic to a website. A “Conversion Specialist” focuses on doing a better job in producing results with the traffic a site already gets. A successful internet marketer realizes the best case scenario is to address both issues, although most (including myself) will generally advise starting with the scales tipped towards improving conversion, and then gradually tip them more towards generating more traffic, while always making strides in both areas.

An excellent point well worded by Howard Kaplan:

It’s pure lunacy to change your site to accomodate the recommendations of a firm whose stated goals are to provide more qualified traffic, when you’ve previously displayed an utter inability to close on the qualified traffic you currently enjoy. (view post)

Web Analytics: Log Files vs. Cookie-Based Tracking

A few days ago I sent this off to Jason Dowdell in response to his post about the recent cookie tracking scare/frenzy. By the time I finished the email I began to think it might make a decent post…

Hi Jason,

I just recently came across your blog (although I’ve known of it for a little while) and specifically your post on using cookies vs. log files vs. flash for tracking. (http://www.marketingshift.com/2005/03/cookies-vs-flash-for-client-side.cfm#comments)

IMO (and probably most everyone else’s) the deletion of cookies and possible need for an alternative means of accurate, deep methods of visitor tracking has got to be one of if not the most important SEM and internet marketing issues over the next year or two.

Personally I’m quite fond of a third-party cookie-based tracking service called HitsLink, which has grown a great deal in popularity over the past year. For about the past two years I’ve run my own private SEO firm and utilized this as my main means of tracking and statistic analysis. As most of my clients are small in size and simply need basic traffic and campaign/conversion stats, it has proved a great value.

Here’s where you may actually be interested though πŸ™‚ I recently began working for a large firm as their in-house SEO specialist. My first action in my role has been to improve the stats we’ve been using, which up until a few weeks ago was an older version of WebTrends. It gave us virtually no conversion stats (only traffic) and I highly questioned its accuracy, especially regarding search engine referral numbers (esp. for certain key phrases). However, this I believe can be a common issue with all log file analytics, not just WebTrends.

Its still early, but using cookies our traffic reported by the cookie-based method is literally about 50-60% of what WebTrends was reporting using only the log files. I suppose the good news is that our conversion rate is higher than we thought!

I expected a difference, but almost half? In trying to determine the reasoning for this I came across the same initial conclusion that Eric Peterson from Jupiter Research noted in your comments section – spiders, bots, etc. This certainly accounted for a large portion of the discrepancy, but no matter how I crunch the numbers I can’t seem to have crawlers justify more than 10-12% of total visitors reported by the log files. Surely some visitors as reported by the cookie method will not have JS or cookies enabled, but again I don’t see how that is any more than 5%, even by aggressive estimates.

Anyhow, wish I could wrap this up with some sort of revelation, but really the main point that I though might interest you is that we didn’t notice a 25% difference, but much closer to a full 50% difference between the two methods.

I believe that the cookie method is closer to the actual “truth”, as I did a mini-study using our Google AdWords campaigns… Our cookie-based tool shows X visitors over a given time period from our AdWords campaigns (we used a ?source= variable in the URL), and the numbers reported by Google in their interface (the number of clicks they say they have sent us and are thus billing us for) is consistently within about 5% – very close to each other. Thus, in this case I’m using Google’s measure as the “truth” (which admittedly may be flawed), but figure that they are counting clicks going out, and we are counting them coming in – two different methods, both reporting similar figures. Thus, until reason otherwise, I believe our cookie method is more accurate than the log files, and happens to report just over 50% of the unique visitors we had previously thought were on the site.

Keep up the good blogging! I’ve just added your blog to My Yahoo for tracking and such.

Kind Regards,

Jon Payne

PS – I may recycle this comment on my blog at www.jonpayne.net. Writing this email got the juices flowing…