Event batching for the JavaScript (Node) SDK prior to v6
The JavaScript (Node) SDK lets you batch events and includes options to set an event batch size, event time interval and event flush interval. The benefit of event batching is less network traffic for the same number of impression and conversion events tracked.
Note By default, event batching is enabled in JavaScript (Node) SDK versions 3.3.0 and newer.
Event batching works with both out-of-the-box and custom event dispatchers.
The event batching process does not remove any personally identifiable information (PII) from events. You must still ensure that you are not sending any unnecessary PII to Optimizely.
Configure event batching
Optimizely provides two options to configure event batching: eventBatchSize and eventFlushInterval. You can pass in both options during client creation. Events are held in a queue until either:
- The number of events reaches the defined eventBatchSize.
- The oldest event has been in the queue for longer than the defined eventFlushInterval, which is specified in milliseconds. The queue is then flushed and all queued events are sent to Optimizely in a single network request.
- A new datafile revision is received. This occurs only when live datafile updates are enabled.
const { createInstance } = require('@optimizely/optimizely-sdk')
const optimizely = createInstance({
// other options
eventBatchSize: 100,
eventFlushInterval: 3000,
});The following table defines these options and lists general recommendations for browser and server default settings. On the browser you should using a small eventBatchSize (10) and a short eventFlushInterval (1000). This ensures that events are sent in a relatively fast manner, because some events could be lost if a user immediately bounces, while gaining network efficiency in cases where many decisions calls happen back-to-back.
For the server, these numbers are more flexible and should be set based on your organization's traffic and needs. Contact Optimizely support for recommendations for your specific implementation.
Name | Default value | Description |
|---|---|---|
eventBatchSize | 10 | The maximum number of events to hold in the queue. Once this number is reached, all queued events are flushed and sent to Optimizely. * \*Note\*\*: By setting this value to 1, events are not batched and event requests behave exactly as in pre-3.3.0 JavaScript (Node)SDKs. |
eventFlushInterval | 3000 ms | The maximum duration in milliseconds that an event can exist in the queue before being flushed. |
Note The maximum payload size is 3.5 MB. If the resulting batch payload exceeds this limit, requests is rejected with a 400 response code, Bad Request Error.
The size limitation is because of the Optimizely Events APIOptimizely Events API, which the SDK uses to send data to Optimizely.
The most common cause of a large payload size is a high batch size. If your payloads are exceeding the size limit, try configuring a smaller batch size.
Close Optimizely on application exit
If you enable event batching, you must call the Close method (optimizely.close()) before exiting. This ensures that queued events are flushed when possible to avoid data loss.
Warning Because the Optimizely client maintains a buffer of queued events, you must call close() on the Optimizely instance before shutting down your application or whenever dereferencing the instance.
Method | Description |
|---|---|
close() | Stops all timers and flushes the event queue. This method will also stop any timers happening for the datafile manager. * \*Note\*\*: You should connecting this method to a kill signal for the running process. |
You can hook into the SIGTERM event to ensure that close() is invoked, guaranteeing that all events in the queue are sent.
// respond to SIGTERM and close optimizely
process.on('SIGTERM', async () => {
console.log('SIGTERM signal received.');
await optimizely.close()
process.exit(0)
});