Event batching for the React SDK
How the Optimizely Feature Experimentation React SDK uses the event processor to batch impressions and conversion events into a single payload before sending it to Optimizely.
The React 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.
By default, event batching is enabled in React SDK.
Note
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 Feature Experimentation.
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 Feature Experimentation in a single network request. - A new datafile revision is received. This occurs only when live datafile updates are enabled.
import { createInstance } from '@optimizely/react-sdk';
const optimizely = createInstance({
datafile: window.datafile // assuming you have a datafile at window.datafile
// other options
eventBatchSize: 100,
eventFlushInterval: 3000,
});
const optimizelySdk = require('@optimizely/optimizely-sdk')
optimizelySdk.createInstance({
// other options
eventBatchSize: 100,
eventFlushInterval: 3000,
})
The table below defines these options and lists general recommendations for browser and server default settings. 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 events are generated back-to-back.
For the server, these numbers are more flexible and should be set based on your organization's traffic and needs. Contact support for recommendations for your specific implementation.
Name | Description | Browser | Server |
---|---|---|---|
eventBatchSize | The maximum number of events to hold in the queue. Once this number is reached, all queued events are flushed and sent to Optimizely Feature Experimentation. Default: 10 Note: By setting this value to 1, events are not batched and event requests behave exactly as in pre-3.3.0 version of the React SDK. | 10 | Based on your organization's requirements. |
eventFlushInterval | The maximum duration in milliseconds that an event can exist in the queue before being flushed. Default: 1000 ms in the browser, 30000 ms in Node.js | 1000 | Based on your organization's requirements. |
Warning
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 Feature Experimentation 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.
Close Optimizely Feature Experimentation 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 as soon as possible to avoid data loss.
Warning
Because the Optimizely client maintains a buffer of queued events, you must call
close()
on the Optimizely Feature Experimentation 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 that are happening for the datafile manager. Note: Optimizely recommends that you connect this method to a kill signal for the running process. |
On the browser side, optimizely.close()
is automatically connected to the pagehide event, so there is no need to do any manual instrumentation.
Updated 11 months ago