The [Optimizely Full Stack Javascript SDK](🔗) lets you batch events and includes options to set a maximum batch size and flush interval timeout. The benefit of event batching is less network traffic for the same number of Impression and conversion events tracked.
The event batching functionality works by processing impression events from [Activate](🔗) and conversion events from [Track](🔗) placing them into a queue. The queue is drained when it either reaches its maximum size limit or when the flush interval is triggered.
By default, event batching is enabled in JavaScript SDK version 3.3.0 or newer.
Note
Event batching works with both out-of-the-box and custom event dispatchers.
The event batching process doesn't remove any personally identifiable information (PII) from events. You must still ensure that you aren't sending any unnecessary PII to Optimizely.
## Basic example
We provide 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.
By default, batch size is 10 and flush interval is 1 second.
The table below defines these options and lists general recommendations. On the browser we recommend using a small `eventBatchSize` (10) and a short `eventFlushInterval` (1000). This ensures that events are sent in a relatively fast manner, since some events could be lost if a user immediately bounces, while gaining network efficiency in cases where many decisions or [Track](🔗) calls happen back-to-back.
| Name | Description | Recommend Value |
| **eventBatchSize** | Maximum size of batch of events to send to Optimizely. Default: 10 | 10 |
| **eventFlushInterval** | The maximum duration in milliseconds that an event can exist in the queue before being flushed. Default: 1000 | 1000 |
For more information, see [Initialize SDK](🔗).
## Side effects
The table below describes other functionality related to event batching.
| Functionality | Description |
| **LogEvent** | Whenever the event processor produces a batch of events to be dispatched, a LogEvent notification object is created, which contains the batch of conversion and impression events. This object will be dispatched using the provided event dispatcher and also it will be sent to the notification subscribers (see below). |
| **Notification Listeners** | LOG_EVENT [notification listeners](🔗) are triggered when a LogEvent is passed to the event dispatcher |
### Registering LogEvent listener
To register a LogEvent notification listener
### LogEvent
It represents the batch of impression and conversion events we send to the Optimizely backend.
| Parameter | Description |
| **url** | URL to dispatch log event to |
| **httpVerb** | The HTTP verb to use when dispatching the log event |
| **params** | Contains the event batch |
## Close Optimizely on application exit
If you enable event batching, it's important that you call the Close method (`optimizely.close()`) prior to exiting. This ensures that queued events are flushed as soon as possible to avoid any data loss.
Important
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 pending timers or in-flight requests related to datafile management. |
On the browser side, optimizely.close() is automatically connected to the [pagehide event](🔗), so there is no need to do any manual instrumentation.