CODEWITHSUNDEEP
asp.net.netgoogle-analytics
Pietro
Pietro

Reputation: 781

Detect unique users with simultaneous visits

Imagine a simple html page with 3 iframes pointing to the same url:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>
</head>
<body>
    <iframe src="http://www.mydom.com/mypage.aspx"></iframe>
    <iframe src="http://www.mydom.com/mypage.aspx"></iframe>
    <iframe src="http://www.mydom.com/mypage.aspx"></iframe>
</body>
</html>

My goal is to track unique visitors in mypage.aspx code behind. Sounds simple but the following:

if (Request.Cookies["myc"] == null)
{
    // New visitor!
    Response.Cookies["myc"].Value = myval;
    Response.Cookies["myc"].Expires = DateTime.Now.AddYears(10);
}
else
{
    // Returning visitor
}

has a problem. Visiting the html page with the 3 iframes I get three simultaneous hits to mypage.aspx and Request.Cookies["myc"] is null all three times while I should understand that it is the same user (1st hit: new visitor, 2nd and 3rd hits: returning visitor for a total of one visitor/user). Any ideas how to fix this?

Upvotes: 4

Views: 1037

Answers (4)

Vladimir Estrada
Vladimir Estrada

Reputation: 1

Do not use iframes, Use Master Pages. Create a Master Page, and put this code on the top of your "mypage.aspx"

<%@ Page Language="C#" MasterPageFile="~/Site1.Master" ...

Upvotes: 0

Pietro
Pietro

Reputation: 781

All you have to do is to put the same code in a [webMethod] instead of in PageLoad then call the [WebMethod] from client via js (XMLHttpRequest), you will receive the three calls in sequence. No more probs due to simultaneous hits.

Upvotes: 1

JDB
JDB

Reputation: 25855

A very intriguing question!

The core problem is that the internet is an asynchronous, anonymous place.

The browser may submit one of these requests at a time, or all three at the same time, so there is no way to control the order of events on the user's machine.

In addition, the browser does not make any special effort to uniquely identify the user. Any identification system must be jerry-rigged into the request/response cycle. GA uses cookies to tag users and can pull that information with each and every request. Essentially, GA tags the user before they visit your site, thus allowing that service to identify the user on the "first" hit.

Your problem is that you want to implement your own identification solution. You need to somehow include the user's identity in the request. But, until they visit the site, you have no way of doing that. And, given that each simultaneous request will have a different identity embedded in the response, you cannot guarantee that a user will be tagged with a single identity.

Basically, to the best of my knowledge, there is no solution which will allow an anonymous user to be automatically and uniquely identified by your site.

You may be tempted to use IP addresses and that can work in some situations, but it's a very bad solution. Right now I am behind my employers firewall. If you were to use the IP address currently visible to you to identify me, you would see me and the 5,000 other people who work here as a single user. That's a very dangerous system to rely on.

If you really, really need a single identity for each user - one that cannot be circumvented or accidentally trodden on via multiple simultaneous requests, etc - then your only solution is to require the user to explicitly identify themselves on their first request via a value embedded in the POST or GET query or a cookie created during a previous visit.

In your scenario, all three responses could generate a cookie with a unique ID (three ids in succession, each overwriting the previous value). The landing page could be a generic "welcome to my site" page, or something like that. The user could then click a link to visit the site, at which point the last generated cookie (with the last generated id) would be embedded in the request. While you cannot guarantee that only one ID will be generated per user, you can at least be fairly confident that they will be identified by a single ID after the initial round of requests (and before they visit the main content portion of your site).

Of course, you could use a complicated AJAX solution where the response for unidentified users is essentially a container (without an ID). The AJAX could then set a flag within a cookie indicating that it is retrieving an ID, then it could submit the first request. Subsequent AJAX containers would see this cookie and then enter a polling state, waiting for the flag to be cleared. When the first response comes back, the first AJAX container could set the ID in the cookie and change the flag. Then, the remaining containers will detect the flag change and can retrieve the ID from the cookie (rather than sending their own requests).

Once the AJAX container has an ID, it could send a request for content along with the unique ID. Your site could then respond, filling the container with the appropriate data (or simply redirecting to the appropriate page).

This solution, if properly implemented, would more or less guarantee that a user is assigned only one ID. But really, is it worth it? Remember, the cookie and the request "belong" to the user. The user can pretty easily edit both. While there are techniques for detecting an edited identity (most involving some form of encryption), you cannot prevent a user from "anonymizing" themselves if they so choose. Sometimes a halfway solution is sufficient.

Upvotes: 4

Lars Holdgaard
Lars Holdgaard

Reputation: 9976

That makes good sense. The request for all of these does not have any cookies the first time, so it will be null in all cases. Remember it should do this as async as possible, it's necessarily linear (it might be, I am not expert at how the flow is).

Instead, look at the Ip address and timestamp. If it is the same, you can work as if it is the same user.

Yes, that solution is not perfect, but it's better than the cookie solution.

Upvotes: 0

Related Questions