Proxy Redirect

Atherton213

[H]ard|Gawd
Joined
Dec 21, 2004
Messages
1,863
Not sure if this should be here or the networking forum.

What im trying to do is setup a webserver that only hosts a redirect file, reason is for advertising. We want to be able to see how well its working and track access to that redirect (like a counter).

Ill give an example.

Company sells pens and has pens.com ...they do a big advertising campain and want to see how well it works so in the add they have "buypens.com" when you go to "buypens.com" it just redirects you to the normal pens.com.

What we want to do is be able to track how many times someone has accessed buypens.com Now the pens.com isnt hosted by us, but buypens.com (only the redirect file) will be.

Is there software available to do what im asking?
 
What im trying to do is setup a webserver that only hosts a redirect file, reason is for advertising. We want to be able to see how well its working and track access to that redirect (like a counter).

Ill give an example.

Company sells pens and has pens.com ...they do a big advertising campain and want to see how well it works so in the add they have "buypens.com" when you go to "buypens.com" it just redirects you to the normal pens.com.

What we want to do is be able to track how many times someone has accessed buypens.com Now the pens.com isnt hosted by us, but buypens.com (only the redirect file) will be.
You could do a redirect from the webserver's configuration to route from "buypens.com" to "pens.com".

However, you are wanting to track the initial "hit" to "buypens.com", and likely have that feed into some tracking or 3rd party analytics system. So I think the better suggestion is to host a single page on "buypens.com" that includes your Javascript analytics snippet (or some server-side hit registration logic), plus some extra Javascript to redirect people to "pens.com" after a brief delay.


Edit:
Is there software available to do what im asking?
There isn't a single software application to do this. In fact, the implementation solely depends on whatever you need to register a website "hit".

If you are looking for suggestions on what to use to track hits, then look into Google Analytics. If you are unsure how this all works, then a better starting point would be the Google Webmaster Tools, and reading through their materials.
 
You could do a redirect from the webserver's configuration to route from "buypens.com" to "pens.com".

However, you are wanting to track the initial "hit" to "buypens.com", and likely have that feed into some tracking or 3rd party analytics system. So I think the better suggestion is to host a single page on "buypens.com" that includes your Javascript analytics snippet (or some server-side hit registration logic), plus some extra Javascript to redirect people to "pens.com" after a brief delay.


Edit:

There isn't a single software application to do this. In fact, the implementation solely depends on whatever you need to register a website "hit".

If you are looking for suggestions on what to use to track hits, then look into Google Analytics. If you are unsure how this all works, then a better starting point would be the Google Webmaster Tools, and reading through their materials.

yeah I knew of google analytics, havent looked to deeply into it as this project might be scaling up to about 500+ websites... (its for an advertising company... they want to prove to clients that there advertising is working) So if i have to create an account for each its gonna take a while lol
 
The number of unique analytic IDs you create solely depends on your needs. For example, would you need to know (or even care) if "buypens.com" routed more traffic than "buymypens.com" to the final destination URL of "pens.com"?

If your concern is from the thought of maintaining 500+ static "index" pages, there are alternative options that would reduce the maintenance time. For example, a webserver could hold the definition of the 500+ domain names, but all be physically mapped to the same directory with a single file. Then, on page load, you dynamically determine what the URL is, and do a lookup against some data source (database, flat file, XML, etc.) to inject the correct analytics ID. Client's process the returned markup as usual. You would only build out your admin toolset as needed.
 
The number of unique analytic IDs you create solely depends on your needs. For example, would you need to know (or even care) if "buypens.com" routed more traffic than "buymypens.com" to the final destination URL of "pens.com"?

If your concern is from the thought of maintaining 500+ static "index" pages, there are alternative options that would reduce the maintenance time. For example, a webserver could hold the definition of the 500+ domain names, but all be physically mapped to the same directory with a single file. Then, on page load, you dynamically determine what the URL is, and do a lookup against some data source (database, flat file, XML, etc.) to inject the correct analytics ID. Client's process the returned markup as usual. You would only build out your admin toolset as needed.

for the first part... the company is gonna be sending out mailer advertisements and they want to prove to the customers that people actually read the mail and visit the website... so basicly they dont care how many people are going to pens.com or anything else... only want to track exactly what they put on the mailer which for the example was buypens.com

and on your second part do you mean 1 index "page" that basicly has list of all the domains... ie. buypens.com > pens.com and in the same page as an example has buypencils.com > pencils.com basicly the page automaticly sees that your coming from 1 site and sends you to the correct "real" site? as well as inputs the correct ID...
 
If your webserver is apache you could create a site configuration that uses mod_proxy to redirect buypens.com to pens.com and parse the apache access log for statistics. there are a number of tools you could install on your server that can parse the apache access log, such as AWStats. http://awstats.sourceforge.net/
 
If your webserver is apache you could create a site configuration that uses mod_proxy to redirect buypens.com to pens.com and parse the apache access log for statistics. there are a number of tools you could install on your server that can parse the apache access log.

thats most likley what we will be using to do this, this is exactly what we would need really nothing overly complicated.

sounds easy but I seems that once we get it all running for 1... the issue is scaling it 500-1000 times...

edit: awstats looks perfect! only issue again is scaling it for hundreds....

edit again: These stats don't need to be complied into 1 giant spreadsheet or anything. Just need to be able to access each site and view its stats. If the buypens customer says hey hows the adds working... you can pull up that unique "stat" and show them.
 
Yeah, assuming you have 500-1000 separate servers that could definitely be annoying to deploy. If your company only runs 1 server, though, it would be fairly easy to write a script to generate the site configurations.

Perhaps a side-benefit to using this method is you could make it a permanent redirection (as in the url does not change to pens.com but remains as buypens.com) and keep statistics of total overall traffic generated by campaigns.
 
Yeah, assuming you have 500-1000 separate servers that could definitely be annoying to deploy. If your company only runs 1 server, though, it would be fairly easy to write a script to generate the site configurations.

Perhaps a side-benefit to using this method is you could make it a permanent redirection (as in the url does not change to pens.com but remains as buypens.com) and keep statistics of total overall traffic generated by campaigns.

I did see that awstats showed "time on site" which could be nice.

its going to be 1 server that is going to host just this "redirect" page really. The permanent redirection... would I have to change anything on the actual pens.com host? because that type of stuff we wouldn't really have access too... and on a scale would be almost impossible.


this type of stuff isnt my area of expertise so thank you everyone for the help

and if you have any direction as to what to even search for when looking for how to create a redirect... i guess database?
 
The permanent redirection... would I have to change anything on the actual pens.com host? because that type of stuff we wouldn't really have access too... and on a scale would be almost impossible.
Depends on the types of links pens.com has. If they are absolute links (i.e. they specifically say go to http://www.pens.com/shop.html) then nothing can be done. However, if they are relative links (i.e. they just go to relative "shop.html"), then no additional effort is required on your part to track statistics on how many buypens.com folks visit buypens.com/shop.html .
 
Parsing the web server's logs can be done, but there are some caveats compared with using a client-side registration model. The biggest caveat that I see is with (potential) caching opportunities between the client's browser and the web server that wouldn't result in an actual webserver hit.

Regardless, do let us know what you finally settled on as the final implementation/workflow, and the reason(s) you settled on it.
 
Depends on the types of links pens.com has. If they are absolute links (i.e. they specifically say go to http://www.pens.com/shop.html) then nothing can be done. However, if they are relative links (i.e. they just go to relative "shop.html"), then no additional effort is required on your part to track statistics on how many buypens.com folks visit buypens.com/shop.html .

ok... really would depend on all the websites then so it would work for some probably not all. Excellent thanks for the help

Parsing the web server's logs can be done, but there are some caveats compared with using a client-side registration model. The biggest caveat has to do with (potential) caching opportunities between the client's browser and the web server.

dont think that would really matter, I think the main idea is to see that 100 people went to it based of the mailer, dont think they are worried if 100 people go and 40 go back again.
 
dont think that would really matter, I think the main idea is to see that 100 people went to it based of the mailer, dont think they are worried if 100 people go and 40 go back again.
It's not the repeat visitors I am referring to.

Think more of a caching server that sits between your web server and the site visitor. The first visitor hits your webserver, and the static page gets pulled down to the cache server and is passed to the requesting user. This hit is registered on your web server. Then, so long as the page is still cached on the caching server, any further visits (regardless of who it actually is) is pulled from the cache server -- all without touching your webserver. You'd never see those subsequent hits until the cache expires or is refreshed.

Whether this is a concern for your customers or not can only be answered by you. But it is something to keep in mind.
 
It's not the repeat visitors I am referring to.

Think more of a caching server that sits between your web server and the site visitor. The first visitor hits your webserver, and the static page gets pulled down to the cache server and is passed to the requesting user. This hit is registered on your web server. Then, so long as the page is still cached on the caching server, any further visits (regardless of who it actually is) is pulled from the cache server -- all without touching your webserver. You'd never see those subsequent hits until the cache expires or is refreshed.

Whether this is a concern for your customers or not can only be answered by you. But it is something to keep in mind.

ahhh gotcha... yeah that would be a concern since we need to register every hit to the buypens.com to keep track. Now these sites are most likely small local businesses that don't get a lot of traffic to begin with. I think I still need to do a lot of research on this topic. Like I said this is way outside what I normally do...
 
Back
Top