Apr 9, 2010 at 8:44 PM
Edited Apr 9, 2010 at 8: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?