Disclaimer: This website requires Please enable JavaScript in your browser settings for the best experience.

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 GuideLegal TermsGitHubDev CommunityOptimizely AcademySubmit a ticketLog In
Dev Guide
These docs are for v2.0. Click to read the latest docs for v3.0.

Customize an SDK

We've designed Full Stack SDKs to be highly general and work in many different environments. To support this flexibility, many key pieces of an SDK are implemented as plugins that you can customize for your specific requirements. You can optionally replace built-in functionality in an SDK, filling in your own implementations for components like:

  • Event dispatcher– Configure how an SDK sends events to Optimizely.
  • Logger– Configure how an SDK logs messages when certain events occur.
  • Error handler– Configure how errors should be handled in your production code.
  • User Profile Service– Configure what user state is persisted by an SDK.

The SDKs provide default implementations of event dispatching, logging, and error handling out of the box, but we encourage you to override the default behavior if you have different requirements in your production application. To edit the default behavior, see the reference implementations in an SDK's source code for examples.

In mobile applications, you can configure these settings when you initialize the iOS SDK or Android SDK. In the other SDKs, you can set them up when you Instantiate a client.

In many cases, the default implementation is appropriate for a Hello World example but not for a production environment. For guidance on setting up these components for real traffic, see Implementation checklist: Prepare Full Stack for production.