1

I am auditing the xDB configuration on a site based on Sitecore 7.5.

  • The setup is plain with no custom interactions being registered.
  • We are dealing with the last scenario here, "Content delivery cluster with a non-sticky load balancer".
  • There are two load-balanced CD servers.

Previously, there was an error in the configuration, where shared session state was set to "InProc". The private session state has always been pointing to the MongoDB session database.

This was fixed recently, and the shared session state is now also stored in MongoDB. Ever since then, the number of interactions has declined sharply in the analytics database (from about 1.5M per month to around 200K). This makes sense to me, but I haven't found any documentation to back that up.

So the question is: if one mistakenly sets the shared session state to "InProc" in a load-balanced scenario, can that result in an artificially high number of interactions? And if not, what else could be causing this?

Improve this question

1 Answer 1

Reset to default
2

Storing the session vs. storing the interaction data is a different thing, although both can be stored in Mongo.

And yes, you are correct, if, in a load-balanced environment (with no sticky session), you set the session state to be InProc, you would have a much higher number of concurrent sessions, since if the user went to a different server, then they would start a new session on that server. So one user would have multiple sessions on-going. Once those sessions would end, then yes, it would be written as separate entities into Mongo. And this I am not 100% sure, but I doubt that Sitecore would combine those records, i.e. you would end up with a record for each server per user.

But drop from 1.5m records to 200k, seems extreme (unless you have 7 CD servers), unless for some reason the user moving from one server to the next would cause each interaction to end after each page load. That would explain that drop.

Does your Sitecore analytics numbers still map roughly correctly to your Google Analytics or other analytics data? If so, then you shouldn't have a problem.

One way to validate this would be to look at the records in Mongo from the inProc time, those records would have less interactions, and also, you should see multiple records (from the different servers) for all individual visits.

Improve this answer
4
  • I agree that the drop seems extreme. I'll update my question to note that there are only two CD servers. I am trying to get my hands on the GA numbers for comparison. But since the audit is still ongoing, there are other aspects that need to be improved before we can reach any conclusion. For instance, the VisitorIdentification tag is missing (and has never been present). One thing's for sure, the decline in numbers coincides exactly with the date the shared session configuration was changed.
    – maz
    Commented May 17, 2017 at 17:42
  • Yeah, the one thing that could explain that (not sure), is if it keeps creating a new visit for every time the user moves to a new server. So if the user first hits server 1, then server to 2 and then goes to server 1 again, that it would still create a new session at that point because the server 2 changed the analytics cookie.
    – Jarmo Jarvi
    Commented May 17, 2017 at 17:56
  • I've decided to accept that hypothesis. There remains an element of uncertainty, but I don't have time to reproduce the previous environment in order to validate. As you mentioned, the more important thing is that the new numbers more closely reflect reality. Right now they are below expected level, but with the addition of VisitorIdentification, we should be right there. (And 1.5k was well above expected numbers which should be between 200k and 300k per month.)
    – maz
    Commented May 19, 2017 at 14:26
  • And keep in mind that the numbers of course will never fully match to a separate analytics system of course :)
    – Jarmo Jarvi
    Commented May 19, 2017 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.