Campaign IIS Log Analysis

[arthernan]

We have a working application which uses Server session variables as a
means to identify the user.

My boss want to start looking at the IIS logs to understand what our
users do. On our website we have occasional users and also customers
for which we have an ID. We would like to be able to link IIS log data
to internal data via the customer ID, even when we know it is not the
100% of our users.

I'm not sure if I should replace the Session("CustomerID") for a
MySession("CustomerID") that also writes a Cookie which will in turn
be logged in IIS. Or write the ASP.NET_SessionID along with our
CustomerID to a table in the database. And if I do should I mess with
the current page inheritance or just make the call like
MyLib.MySession(Me, "CustomerID") .

For security reasons I just don't want to use an ID returned from a
browser.

Has anybody dealt with this? Will sombody come forward and give a
suggestion? Please?

 

[Alexey Smirnov]

We have a working application which uses Server session variables as a
means to identify the user.

My boss want to start looking at the IIS logs to understand what our
users do. On our website we have occasional users and also customers
for which we have an ID. We would like to be able to link IIS log data
to internal data via the customer ID, even when we know it is not the
100% of our users.

I'm not sure if I should replace the Session("CustomerID") for a
MySession("CustomerID") that also writes a Cookie which will in turn
be logged in IIS. Or write the ASP.NET_SessionID along with our
CustomerID to a table in the database. And if I do should I mess with
the current page inheritance or just make the call like
MyLib.MySession(Me, "CustomerID") .

For security reasons I just don't want to use an ID returned from a
browser.

Has anybody dealt with this? Will sombody come forward and give a
suggestion? Please?

The first approach with a cookie is the easiest and quickest, I think.

 

[arthernan]

The first approach with a cookie is the easiest and quickest, I think.

OK, let's assume I do, Should I code it like MyLib.MySession(Me,
"CustomerID") and avoid dealing with inheritance. Or should I code it
MySession("CustomerID")

 

[Alexey Smirnov]

OK, let's assume I do, Should I code it like MyLib.MySession(Me,
"CustomerID") and avoid dealing with inheritance. Or should I code it
MySession("CustomerID")- Hide quoted text -

I think all what you need is to set a cookie

Response.Cookies["CustomerID"].Value = Session["CustomerID"];

Note, you will need a reporting tool which could read that values from
the IIS log.

 

[arthernan]

OK, let's assume I do, Should I code it like MyLib.MySession(Me,
"CustomerID") and avoid dealing with inheritance. Or should I code it
MySession("CustomerID")- Hide quoted text -

I think all what you need is to set a cookie

Response.Cookies["CustomerID"].Value = Session["CustomerID"];

Note, you will need a reporting tool which could read that values from
the IIS log.

It's just easy to miss. I'd like something more foolproof.

 

[Alexey Smirnov]

I think all what you need is to set a cookie

Response.Cookies["CustomerID"].Value = Session["CustomerID"];

Note, you will need a reporting tool which could read that values from
the IIS log.

It's just easy to miss. I'd like something more foolproof.

What would make it more foolproof?

When you save a cookie, the cookies will be logged in IIS log among to
other data, making them available together to be used in your
reporting. If you gonna save that CustomerID somewhere else, like in a
database, you will have a problem to link the ID and IIS log.

 

[arthernan]

OK, let's assume I do, Should I code it like MyLib.MySession(Me,
"CustomerID") and avoid dealing with inheritance. Or should I code it
MySession("CustomerID")- Hide quoted text -
I think all what you need is to set a cookie
Response.Cookies["CustomerID"].Value = Session["CustomerID"];
Note, you will need a reporting tool which could read that values from
the IIS log.

It's just easy to miss. I'd like something more foolproof.

What would make it more foolproof?

When you save a cookie, the cookies will be logged in IIS log among to
other data, making them available together to be used in your
reporting. If you gonna save that CustomerID somewhere else, like in a
database, you will have a problem to link the ID and IIS log.- Hide quoted text -

OK, I did not make mysefl clear. The line:

Response.Cookies["CustomerID"].Value = Session["CustomerID"];

Could be easily missed during programming. We don't have a strong
testing team here, and we would en un with pages that are not being
tracked

 

[Alexey Smirnov]

OK, let's assume I do, Should I code it like MyLib.MySession(Me,
"CustomerID") and avoid dealing with inheritance. Or should I code it
MySession("CustomerID")- Hide quoted text -
I think all what you need is to set a cookie
Response.Cookies["CustomerID"].Value = Session["CustomerID"];
Note, you will need a reporting tool which could read that values from
the IIS log.
It's just easy to miss. I'd like something more foolproof.

What would make it more foolproof?

When you save a cookie, the cookies will be logged in IIS log among to
other data, making them available together to be used in your
reporting. If you gonna save that CustomerID somewhere else, like in a
database, you will have a problem to link the ID and IIS log.- Hide quoted text -

OK, I did not make mysefl clear. The line:

Response.Cookies["CustomerID"].Value = Session["CustomerID"];

Could be easily missed during programming. We don't have a strong
testing team here, and we would en un with pages that are not being
tracked- Hide quoted text -

- Show quoted text -

Ah, got it! You should set the cookie only once, in your
authentication form (e.g. login.aspx). The default expiration date of
a cookie is the current session. It means this cookie will expire when
the session is ended. Or you can explicitly set the date, for example
+1 year. It could help to track existed customers who has not
authenticated.

You can also use global.asax, e.g. Application_BeginRequest() method
(for all requests) or Application_AuthenticateRequest() (for
authenticated users only).

 

[arthernan]

OK, let's assume I do, Should I code it like MyLib.MySession(Me,
"CustomerID") and avoid dealing with inheritance. Or should I code it
MySession("CustomerID")- Hide quoted text -
I think all what you need is to set a cookie
Response.Cookies["CustomerID"].Value = Session["CustomerID"];
Note, you will need a reporting tool which could read that values from
the IIS log.
It's just easy to miss. I'd like something more foolproof.
What would make it more foolproof?
When you save a cookie, the cookies will be logged in IIS log among to
other data, making them available together to be used in your
reporting. If you gonna save that CustomerID somewhere else, like in a
database, you will have a problem to link the ID and IIS log.- Hide quoted text -

OK, I did not make mysefl clear. The line:

Response.Cookies["CustomerID"].Value = Session["CustomerID"];

Could be easily missed during programming. We don't have a strong
testing team here, and we would en un with pages that are not being
tracked- Hide quoted text -

- Show quoted text -

Ah, got it! You should set the cookie only once, in your
authentication form (e.g. login.aspx). The default expiration date of
a cookie is the current session. It means this cookie will expire when
the session is ended. Or you can explicitly set the date, for example
+1 year. It could help to track existed customers who has not
authenticated.

I thought we had multiple points of entry, and that they could
increase. But it's not the case.

I think, I complicated myself on this one.

You can also use global.asax, e.g. Application_BeginRequest() method
(for all requests) or Application_AuthenticateRequest() (for
authenticated users only).- Hide quoted text -

This is a good suggestion too. I'll keep it in mind.

Thanks