Implement a User Storage Service

User Storage Service (USS) is a caching layer to persist data about your users. This is helpful in ensuring that variation assignments are always sticky even if you update the campaign settings.
For example, you can create an implementation that reads and saves user-campaign data mapping from backend services such as Redis, Memcache, MongoDB, or any other storage service.

How to Implement User Storage Service

User Storage Service is optional while instantiating the VWO SDK. However, to ensure sticky variation assignments, we recommend implementing one.

User Storage Service should expose two methods: get and set.

Check the following example to know more about how to implement your own User Storage Service.

class VWO
  # Abstract class encapsulating user storage service functionality.
  # Override with your own implementation for storing
  # And retrieving the user.

  class UserStorage

    # Abstract method, must be defined to fetch the
    # User storage dict corresponding to the user_id.
    #
    # @param[String]        :user_id            ID for user that needs to be retrieved.
    # @return[Hash]         :user_storage_obj   Object representing the user.
    #
    def get(user_id, campaign_key)
      # example code to fetch it from DB column
      JSON.parse(User.find_by(vwo_id: user_id).vwo_user)
    end

    # Abstract method, must be to defined to save
    # The user dict sent to this method.
    # @param[Hash]    :user_storage_obj     Object representing the user.
    #
    def set(user_data)
        # example code to save it in DB
        User.update_attributes(vwo_id: user_data.userId, vwo_user: JSON.generate(user_data))
    end
	end
end

# Now use it to initiate VWO client instance
vwo_client_instance = VWO.new(account_id, sdk_key, custom_logger, UserStorage.new)

Format for the userStorageData

userStorageData is a map where data is being stored with respect to a unique user ID and a unique campaign key.

The following keys are expected in the map:

🚧

Note:

VWO SDK validates the variationName and checks whether the variation exists in the campaign having the campaignkey or not. If the variation is found, SDK will use without looking into the User Storage service. If the variation of not found, SDK will jump onto the process of checking whether the user is eligible for the campaign or not and returns accordingly from the SDK API.

Below is an example:

{
  userId: 'User ID',
  campaignKey: 'unique-campaign-key',
  variationName: 'Variation-1'
}