Feature Thought - Delayed TrackEvent

Apr 9, 2010 at 7:44 PM
Edited Apr 9, 2010 at 7:55 PM

I was wondering if you have considered delayed TrackEvent feature.

In some of my client cases, we would probably get flooded with HTTP posts for TrackEvents in ServiceOrientedAnalytics endpoint, if we would react to each trigger and raise  TrackEvent individually to endpoint.

Although, we would still be interested in to know all considered events, as they can give some vital information of user UI behavior.

What would help in this case, although you could go Azure/or 3rd party Analytics, is the feature that would allow to store raised TrackEvents on the client side, and fire them off to endpoint with a single Pulse event.

Furthermore, if the ServiceOrientedAnalytics endpoint `` Service '' could be able to tell the client collector how many TrackEvents should be collected in client site for each pulse. This could create more reliable service collector, without losing too many events when ServiceOrientedAnalytics endpoint gets busy.

Although, this is not that complex to build top into the current framework but I think this can make sense to quite many in-house analytics endpoints and therefore have it as a standard feature would not heart.


Ps. I just saw that you probably have a workitem for this. But not sure if WorkItem (#11696)"Add a web message dispatcher to queue web messages." is to cover this above feature? 

Apr 9, 2010 at 9:03 PM


That's a great idea!  Can you please create a work item for it with as much details as possible.  It would fit nicely within the ServiceOrientedAnalytics class.  You would probably make a batch size or where you define the # of events to batch in a POST message or use a timer or both.

The work item is for something different - it's so network traffic doesn't get backed up.

Apr 10, 2010 at 8:24 PM
Edited Apr 10, 2010 at 8:42 PM

I created a new work item as "Enable ServiceOrientedAnalytics to batch TrackEvents in single POST message based on a timer or number of items."

I added some motivations and forces, which I can oversee from my clients. Please check, comment and VOTE.


Apr 10, 2010 at 10:19 PM

Great!  Let's see if anyone is interested in developing and using this feature proposal.

Thanks for your participation in the process.

Apr 10, 2010 at 11:05 PM

I think when using in-house SeriviceOrientedAnalytics for reason or another. You may learn much later, such as in the stress test phase of the solution that you need something like this.

Otherwise you would not have any other options than going back to shareholders and reevaluate the hardware requirements, or reduce the track events in order to collect them accurately, or in purpose allow losing some of them by server 500 Error.

Which even happens to some of the biggest analyst providers today, or what else could be the reason they have different numbers of events?

It’s more costly to raise each TrackEvent individually to endpoint than processing batch of TrackEvents.

Anyhow, I am also curious to know what others think about this. J