Batch loading events

Batch Download Specifics

The visitorEvents API method solves the problem of maintaining the order of user events. For example, when the connection to the Internet is lost, when events cannot be transmitted in real time, but actions are performed in the application. As soon as the application has access to the Internet, it is important for us to receive these events, but if we send them using ordinary calls to view, addToBasket - there is a possibility of losing order, due to the fact that each of the calls to view, addToBasket will be processed by a different server. To save the order of actions, there is the visitorEvents method, which accepts a set of events and guarantees that the events will be saved in the order in which they are passed.

Features of use

❗️

To send two batches of events containing different behavior of the same user, you need to send the first one, wait for the successful response status, and then send the second one;

❗️

You cannot make more than one call in parallel, in which there are events for one user - this can break the order;

🚧

Due to the need to return confirmation of saving events and order, the response time of visitorEvents, usually, several times longer than the response time of normal (non-batch) tracking calls and can take up to 1.5 seconds or more. Therefore, batch loading events should not be used to send realtime events;

📘

You can pass events for different users in one call (sessionExternalId);

📘

You can call visitorEvents in parallel with packages for different users, because order is important only within a single user;