[3.1.0-beta1] - March 6th, 2019

[3.1.0-beta1] - March 6th, 2019

Changed

• New APIs for setting logger and logLevel on the optimizelySDK singleton (#232)
• logger and logLevel are now set globally for all instances of Optimizely. If you were passing
  different loggers to individual instances of Optimizely, logging behavior may now be different.

Setting a ConsoleLogger

var optimizelySDK = require('@optimizely/optimizely-sdk')

// logger and logLevel are now set on the optimizelySDK singleton
optimizelySDK.setLogger(optimizelySDK.logging.createLogger())

// valid levels: 'DEBUG', 'INFO', 'WARN', 'ERROR'
optimizelySDK.setLogLevel('WARN')
// enums can also be used
optimizelySDK.setLogLevel(optimizely.enums.LOG_LEVEL.ERROR)

Disable logging

var optimizelySDK = require('@optimizely/optimizely-sdk')

optimizelySDK.setLogger(null)

[3.0.1] - February 21, 2019

Changed

• Expose default loggers, errorHandlers, eventDispatcher and enums on top level require.
• createLogger and createNoOpLogger are available as methods on optimizelySdk.logging
• Added optimizelySdk.errorHandler
• Added optimizelySdk.eventDispatcher
• Added optimizelySdk.enums

Release 3.0.0

[3.0.0] - February 13, 2019

The 3.0 release improves event tracking and supports additional audience targeting functionality.

New Features:

• Event tracking (#207):
  • The track method now dispatches its conversion event unconditionally, without first determining whether the user is targeted by a known experiment that uses the event. This may increase outbound network traffic.
  • In Optimizely results, conversion events sent by 3.0 SDKs don't explicitly name the experiments and variations that are currently targeted to the user. Instead, conversions are automatically attributed to variations that the user has previously seen, as long as those variations were served via 3.0 SDKs or by other clients capable of automatic attribution, and as long as our backend actually received the impression events for those variations.
  • Altogether, this allows you to track conversion events and attribute them to variations even when you don't know all of a user's attribute values, and even if the user's attribute values or the experiment's configuration have changed such that the user is no longer affected by the experiment. As a result, you may observe an increase in the conversion rate for previously-instrumented events. If that is undesirable, you can reset the results of previously-running experiments after upgrading to the 3.0 SDK.
  • This will also allow you to attribute events to variations from other Optimizely projects in your account, even though those experiments don't appear in the same datafile.
  • Note that for results segmentation in Optimizely results, the user attribute values from one event are automatically applied to all other events in the same session, as long as the events in question were actually received by our backend. This behavior was already in place and is not affected by the 3.0 release.
• Support for all types of attribute values, not just strings (#174, #204).
  • All values are passed through to notification listeners.
  • Strings, booleans, and valid numbers are passed to the event dispatcher and can be used for Optimizely results segmentation. A valid number is a finite number in the inclusive range [-2⁵³, 2⁵³].
  • Strings, booleans, and valid numbers are relevant for audience conditions.
• Support for additional matchers in audience conditions (#174):
  • An exists matcher that passes if the user has a non-null value for the targeted user attribute and fails otherwise.
  • A substring matcher that resolves if the user has a string value for the targeted attribute.
  • gt (greater than) and lt (less than) matchers that resolve if the user has a valid number value for the targeted attribute. A valid number is a finite number in the inclusive range [-2⁵³, 2⁵³].
  • The original (exact) matcher can now be used to target booleans and valid numbers, not just strings.
• Support for A/B tests, feature tests, and feature rollouts whose audiences are combined using "and" and "not" operators, not just the "or" operator (#175)
• Updated Pull Request template and commit message guidelines (#183).
• Support for sticky bucketing. You can pass an $opt_experiment_bucket_map attribute to ensure that the user gets a specific variation (#179).
• Support for bucketing IDs when evaluating feature rollouts, not just when evaluating A/B tests and feature tests (#200).
• TypeScript declarations (#199).

Breaking Changes:

• Conversion events sent by 3.0 SDKs don't explicitly name the experiments and variations that are currently targeted to the user, so these events are unattributed in raw events data export. You must use the new results export to determine the variations to which events have been attributed.
• Previously, notification listeners were only given string-valued user attributes because only strings could be passed into various method calls. That is no longer the case. You may pass non-string attribute values, and if you do, you must update your notification listeners to be able to receive whatever values you pass in (#174, #204).
• Drops window.optimizelyClient from the bundled build. Now, window.optimizelySdk can be used instead. (#189).

Bug Fixes:

• Experiments and features can no longer activate when a negatively targeted attribute has a missing, null, or malformed value (#174).
  • Audience conditions (except for the new exists matcher) no longer resolve to false when they fail to find an legitimate value for the targeted user attribute. The result remains null (unknown). Therefore, an audience that negates such a condition (using the "not" operator) can no longer resolve to true unless there is an unrelated branch in the condition tree that itself resolves to true.
• setForcedVariation now treats an empty variation key as invalid and does not reset the variation (#185).
• You can now specify 0 as the revenue or value for a conversion event when using the track method. Previously, 0 was withheld and would not appear in your data export (#213).
• The existence of a feature test in an experimentation group no longer causes A/B tests in the same group to activate the same feature (#194).

Release 2.3.1

[2.3.1] - November 14, 2018

Fixed

• fix(bundling): Publish the unminified UMD bundle along with the minified one. (#187)

Release 2.3.0

[2.3.0] - November 14, 2018

New Features

• Allow sticky bucketing via passing in attributes.$opt_experiment_bucket_map, this more easily allows customers to do some async data fetching and ensure a user gets a specific variation.

const userId = '123'
const expId = '456'
const variationId = '678'
const userAttributes = {
  $opt_experiment_bucket_map: {
    [expId]: {
      variation_id: variationId
    }
  }
}

var selectedVariationKey = optimizelyClient.activate('experiment-1', userId, userAttributes);

3.0.0-rc

This is the release candidate version of the 3.0 SDK:

New Features

• Support for boolean combinations of audiences on experiments (#175)
• Added PR template and commit message guidelines (#183)

Fixes

• Updated dependency versions (#180)
• Suppressed unwanted console output in tests (#181)
• Update project config to handle latest 3.0 datafile format (#182)

3.0.0-alpha

This is the alpha release of the 3.0 SDK, which includes a number of improvements to audience targeting:

New Features

• Support for number-valued and boolean-valued attributes (#174).
• Support for audiences with new match conditions for attribute values, including 'substring' and 'exists' matches for strings; 'greater than', 'less than', 'exact, and 'exists' matches for numbers; and "exact" and 'exists' matches for booleans (#174).

Breaking Changes

• Previously, when a 'not' audience condition was applied to a malformed attribute, it was possible for the condition to evaluate to true. We’ve corrected this behavior, so that malformed attributes always evaluate to null and are ignored (#174).

2.2.0

[2.2.0] - September 26, 2018

Fixed

• Track and activate should not remove null attributes (#168)
• Track attributes with valid attribute types (#166)
• Prevent SDK from initializing if the datafile version in invalid (#161)
• Updating lerna to latest version (#160)

Changed

• Change invalid experiment key to debug level (#165)

Release 2.1.3

[2.1.3] - August 21, 2018

Fixed

• Send all decisions for the same event in one snapshot. (#155)
• Give Node.js consumers the unbundled package (#133)

Deprecated

• The UMD build of the SDK now assigns the SDK namespace object to window.optimizelySdk rather than to window.optimizelyClient. The old name still works, but on its first access a deprecation warning is logged to the console. The alias will be removed in the 3.0.0 release. (#152)

2.1.2

chore(release): 2.1.2 (#126)

* Fix(nodejs/event_dispatcher): update error/resp handlers (#123)

- (nodejs) Prevent crash when `http`/`https` emits an error by adding an 'error' listener
- (nodejs) Fix `requestCallback` to conform to its role as a 'response' listener; notably, ensure it is called when the first argument is interpeted as the `http.IncomingMessage`, and _not_ called in the event of an error (as expected by `Optimizely#_sendImpressionEvent`/`Optimizely#track`).

Tested that this version (as 2.1.2-0) _does_ emit the messages expected in the demo app.

Fixes #122
Fixes #124