Tracking Users coming from a certain source

Question

I'm giving promotions to users who sends us other visitors. This is done on the client side.

I can do this using dynamic GET parameters, e.g. http://www.mysite.com?app_source=user_id or I can do this using the hash, e.g. http://www.mysite.com#app_source,user_id.

Are there any pros and cons for any of these methods?

How is the tracking accomplished if it's done on the client side? — j08691, Jul 12 '12 at 17:38
This is a third party app. We parse the `document.location` object and POST to our servers, just like Google Analytics — CamelCamelCamel, Jul 12 '12 at 17:40

score 8 · Answer 1 · edited May 23 '17 at 11:48

The standard way to do this for a GET request would be to simply use a query string.

http://www.mysite.com?app_source=user_id

If you use a URL anchor such as

http://www.mysite.com#app_source,user_id

The anchor portion (#app_source,user_id) is not sent to the server

For example, see this related question.

Here's another related question

The anchor is merely a client-side flag to tell the browser where to navigate on the page.

To address your redirect concerns, you can process the query string before redirecting, add/remove and key/value pairs you want, and then redirect.

PHP gives you direct access to the query string with $_SERVER['QUERY_STRING']

Rails uses request.uri which you can parse

Also, when you see fanciful things like facebook.com/#stuff, the anchor portion is handled with client-side javascript. So you can do this, but you'll be writing ajax code that is sending normal GET requests like the one recommended at the top of this answer.

Why add complexity? Do you just like the look of the # better than the ? ?

This is a third party script. Redirections - and parsing dynamic arguments before redirection - are not possible. Other third party scripts, like AddThis, use the hash and not dynamic parameters. — CamelCamelCamel, Jul 12 '12 at 19:05

score 7 · Answer 2 · answered Jul 12 '12 at 17:44

Use the ? approach. Why? Because that's how you should pass arbitrary data across pages.

# is specifically used for page anchors.

Semantics and best practices aside, there is also a practical reason for this. Think about what happens when a user sends a visitor to an anchor on a page. You would not be able to use the hash approach (at least not in a simple way).

So I would follow the approach outlined here:

function $_GET(q,s) {
    s = s ? s : window.location.search;
    var re = new RegExp('&'+q+'(?:=([^&]*))?(?=&|$)','i');
    return (s=s.replace(/^?/,'&').match(re)) ? (typeof s[1] == 'undefined' ? '' : decodeURIComponent(s[1])) : undefined;
}

var app_source = $_GET('app_source');

Then you can have URLs like this: http://www.mysite.com?app_source=user_id#anchor

score 5 · Accepted Answer · answered Jul 12 '12 at 17:42

Query String

Google Analytics, server logs, et al will have a record of the URL, which may be beneficial for later analysis.
Multiple URLs make caching harder and have a slight chance of confusing the Google

Hash

Analytics and server logs will not see/pay attention to hash params

The more semantic way of handling this is probably through a query string parameter, but it's not very strong. If none of the above-listed points is relevant, I would probably just stick with query strings because it is more common.

If you mean that you are building a service that other people integrate, and you don't want them to have to pass information back to their application (via query string), then using hash params seems like a solid option.

score 3 · Answer 4 · edited Jul 12 '12 at 17:53

3

W3C says here:

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

edited Jul 12 '12 at 17:53

user7116

63,008
17
141
172

answered Jul 12 '12 at 17:51

Hesham Saeed

5,358
7
37
57

Maciej Pyszyński · Answer 5 · 2012-07-13T14:43:44.413

Use HASH.

Why?

Because you develop 3rd party plugin, and don't know if any of the arguments are NOT user by site developers. When you override one of used get parameters, you can destroy some important information passed to the server by native app devs. Also you don't want to make app holder having duplicated pages like: http://somepage.com/ and http://somepage.com/?app_source=user_id will be duplicates and as many users will refer that page, you will create many of them.

Hash is the most safe option and can be used on every page.

score 2 · Answer 6 · answered Jul 17 '12 at 16:07

Hash is the way to go.

There are only 2 choices, one is GET Parameter and 2nd is #.

? GET PARAMETER

The get parameter can be indexed by search engine and two URLs http://www.yoursite.com/ and http://www.yoursite.com/?app_id=123 can be 2 seperate pages

On one of my sites I have used this and I get emails from google stating While crawling your site, we have noticed an increase in the number of transient soft 404 errors around 2012-06-30 22:00 UTC (London, Dublin, Edinburgh). Your site may have experienced outages. These issues may have been resolved. Here are some sample pages that resulted in soft 404 errors:

The links they mentioned are working properly without any issue, but still I am started to get these errors.

# HASH

Hashes are better as they dont change the behavior of any SEO thing (many ppl will say that it does have impact but i dont think so)

At the end you just need to get the app_source and to pass it to your server using Javascript. So you can as what you like. If I were you, i would surly use HASH

score 1 · Answer 7 · answered Jul 12 '12 at 18:14

1

Neither of your methods are good. The ultimate way to do this is to use URL Segments:

If you want to differentiate by App and UserId:

http://www.mysite.com/appName/UserID/

Or only by UserId:

http://www.mysite.com/UserID/

But I personally would go by both AppName and UserName:

http://www.mysite.com/appName/UserName/

answered Jul 12 '12 at 18:14

Registered User

3,669
11
41
65

Totally wrong - he's developing 3rd party javascript plugin, and don't want to mess up app URL's. You don't even know if this app wont throw 404 error using you approach. – Maciej Pyszyński Jul 13 '12 at 09:11
@MaciejPyszyński Not sure what you mean by "mess up", also 404 is thrown on the server and has nothing to do with JavaScript. – Registered User Jul 13 '12 at 10:12
Yes. do if base url is http://somepage.com/page-ulrname and only this is url format is supported by App, and this guy is developing 3rd party plugin, so he cannot add parameters to URL. Other case is when app use parameter appName, so he may provide wrong input. Another one is hash can be used on every page, without any flaws (if application don't use hash to restore some state) – Maciej Pyszyński Jul 13 '12 at 14:43
Well, now you have completely lost me because I don't understand your English. Try to formulate your sentences in more clear manner. – Registered User Jul 13 '12 at 16:54
Sorry was in hurry. If base url is http://somepage.com/[page-ulrname] and this is only supported format. You will get 404 error. Moreover this guy is developing 3rd party plugin, so he cannot add parameters to URL or enforce dev team to do so. We run in another problem when app use parameter "appName", so it can provide wrong input (by URL). Also hash can be used on every page, without any flaws (if application don't use hash to restore some state) – Maciej Pyszyński Jul 13 '12 at 18:07
If OP doesn't have control over the URL, then my answer is not relevant. – Registered User Jul 13 '12 at 18:33

score 0 · Answer 8 · answered Jul 12 '12 at 17:40

0

Based on some modern web applications today that have promoted the "#" sign is very useful to support SPA (Single Page Application) like Twitter. Please just use the "?" sign.

answered Jul 12 '12 at 17:40

Christian Tjhai

111
6

If the website will redirect to another page I will lose the dynamic parameters but I won't lose the hash information. See http://fb.com/#stuff as an example – CamelCamelCamel Jul 12 '12 at 17:42
@CamelCamelCamel, I addressed your redirect concern in my answer. – maček Jul 12 '12 at 17:46
That's why I have suggested you to use the ? GET parameter sign and not the # HASH. Good luck. – Christian Tjhai Jul 18 '12 at 17:20
Well, if you really think about it. No matter if you are going to use the ? GET PARAMETER or the # HASH, somewhere you'll make an ajax request to actually deal with sessions and updating your database, thus updating your app state. The ? GET PARAMETER is just more natural for me and maybe for most developers. – Christian Tjhai Jul 18 '12 at 17:32

Frederik.L · Answer 9 · 2012-07-13T07:43:27.017

0

The simple way is to use a GET parameter with a userID to verify if it's been referred by someone.

http://www.mysite.com/?ref=1128721

Then if you want to know more about the referral, you can also check from which url the user actually clicked your link by using $_SERVER['HTTP_REFERER'] (if you use php). This way, you can ensure that your link wasn't in a junk place or "auto-visited".

edited Jul 13 '12 at 07:43

answered Jul 13 '12 at 07:36

Frederik.L

5,522
2
29
41

Tracking Users coming from a certain source

9 Answers9

Query String

Hash