Optimizely will be sunsetting Full Stack Experimentation on July 29, 2024. See the recommended Feature Experimentation migration timeline and documentation.

Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket

Event batching

This topic describes how the Optimizely JavaScript (Browser) SDK uses the event processor to batch impressions and conversion events into a single payload before sending it to Optimizely.

The Optimizely Full Stack Javascript (Browser) SDK l batches impression and conversion events into a single payload before sending it to Optimizely. This is achieved through a new SDK component called the event processor.

Event batching has the advantage of reducing the number of outbound requests to Optimizely depending on how you define, configure, and use the event processor. It means less network traffic for the same number of Impression and conversion events tracked.



By default, event batching is enabled in the JavaScript SDK version 3.3.0 or 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.

Basic example

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.

let optimizelySdk = require('@optimizely/optimizely-sdk');

  // other options
  eventBatchSize: 100,
  eventFlushInterval: 3000,

By default, batch size is 10 and flush interval is 1 second.



The maximum payload size is 3.5 MB. Optimizely rejects requests with a 400 response code, Bad Request Error, if the batch payload exceeds this limit.

The size limitation is because of the Optimizely Events API, which Full Stack uses to send data to Optimizely.

The most common cause of a large payload size is a high batch size. If your payloads exceed the size limit, try configuring a smaller batch size.

The followoing table defines these options and lists general recommendations. On the browser Optimizely recommends 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 decide and track calls happen back-to-back.

NameDescriptionRecommend Value
eventBatchSizeMaximum size of batch of events to send to Optimizely. Default: 1010
eventFlushIntervalThe maximum duration in milliseconds that an event can exist in the queue before being flushed.
Default: 1000

For more information, see Initialize SDK.

Side effects

The table below describes other functionality related to event batching.

LogEventWhenever 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.
Notification ListenersLOG_EVENT notification listeners are triggered when a LogEvent is passed to the event dispatcher

Register LogEvent listener

To register a LogEvent notification listener:

// Using notificationCenter to register logEvent listener

  .addNotificationListener(optimizelyEnums.NOTIFICATION_TYPES.LOG_EVENT, (logEvent) => {});


Represents the batch of impression and conversion events we send to the Optimizely backend.

urlURL to dispatch log event to
httpVerbThe HTTP verb to use when dispatching the log event
paramsContains the event batch

Close Optimizely on application exit

If you enable event batching, it is 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.



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.

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.