on identify(id, props) or the appcues:session_started event - a 50ms timer is started to allow analytics that occur immediately after, to be batched together into the same activity payload to the API.
the expected use case would be a group(id, props) called immediately after identify(id, props) resulting in a combined payload with the new user and the current group - this prevents any chance of state group information being used during the resulting qualification on the server for the new user update or session start qualification
all other analytics are unaffected, unless they also happen within that 50ms window (in which case they would go in this immediate batch as well)
This is an example of what this result would look like, for a new user landing on a login page, signing in, and then triggering the resulting user profile update, the session_started event, and an immediate group update to identify that user's current group and props.
This is implemented by adding a new priority queue to our AnalyticsQueueProcessor - the 50ms queue. We still have the 10 sec background batching queue for flow events as well. If a new priority update comes in (identify or session_start) it will flush anything in the queue existing, and start this new 50ms queue to gather up all immediately subsequent updates.
Couple of edge cases:
There is already a 50ms queue going for another user - could happen if you made multiple identify(id) calls for different user ids, in rapid succession. This will result in the existing priority queue being immediately flushed, stopping any existing timer, before processing the new one.
There is a 50ms queue running while an otherwise immediate event is triggered (a screen or track event) - this will result in the normally immediate event having some delay of < 50ms, as it is merged into this queue (hopefully rare).
This is a similar update to what was recently done in the web sdk in https://github.com/appcues/javascript-sdk/pull/613
identify(id, props)
or theappcues:session_started
event - a 50ms timer is started to allow analytics that occur immediately after, to be batched together into the same activity payload to the API.group(id, props)
called immediately afteridentify(id, props)
resulting in a combined payload with the new user and the current group - this prevents any chance of state group information being used during the resulting qualification on the server for the new user update or session start qualificationThis is an example of what this result would look like, for a new user landing on a login page, signing in, and then triggering the resulting user profile update, the session_started event, and an immediate group update to identify that user's current group and props.
This is implemented by adding a new priority queue to our
AnalyticsQueueProcessor
- the 50ms queue. We still have the 10 sec background batching queue for flow events as well. If a new priority update comes in (identify or session_start) it will flush anything in the queue existing, and start this new 50ms queue to gather up all immediately subsequent updates.Couple of edge cases:
identify(id)
calls for different user ids, in rapid succession. This will result in the existing priority queue being immediately flushed, stopping any existing timer, before processing the new one.