{"id":19541300,"url":"https://github.com/wingify/vwo-fme-ruby-sdk","last_synced_at":"2026-04-02T12:59:14.828Z","repository":{"id":286580216,"uuid":"951161042","full_name":"wingify/vwo-fme-ruby-sdk","owner":"wingify","description":"VWO Feature Management and Experimentation SDK for Ruby","archived":false,"fork":false,"pushed_at":"2025-06-12T08:37:52.000Z","size":145,"stargazers_count":2,"open_issues_count":0,"forks_count":1,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-07-12T18:42:16.830Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://developers.vwo.com/v2/docs/fme-ruby","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/wingify.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2025-03-19T08:56:22.000Z","updated_at":"2025-06-12T08:37:56.000Z","dependencies_parsed_at":null,"dependency_job_id":"46877fe8-eaf7-4fbb-b213-eb5f8d1a0a7f","html_url":"https://github.com/wingify/vwo-fme-ruby-sdk","commit_stats":null,"previous_names":["wingify/vwo-fme-ruby-sdk"],"tags_count":3,"template":false,"template_full_name":null,"purl":"pkg:github/wingify/vwo-fme-ruby-sdk","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/wingify%2Fvwo-fme-ruby-sdk","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/wingify%2Fvwo-fme-ruby-sdk/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/wingify%2Fvwo-fme-ruby-sdk/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/wingify%2Fvwo-fme-ruby-sdk/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/wingify","download_url":"https://codeload.github.com/wingify/vwo-fme-ruby-sdk/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/wingify%2Fvwo-fme-ruby-sdk/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":265080042,"owners_count":23708103,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-11T03:09:35.556Z","updated_at":"2026-04-02T12:59:14.812Z","avatar_url":"https://github.com/wingify.png","language":"Ruby","funding_links":[],"categories":[],"sub_categories":[],"readme":"# VWO Feature Management and Experimentation SDK for Ruby\n\n[![Gem Version](https://badge.fury.io/rb/vwo-fme-ruby-sdk.svg)](https://rubygems.org/gems/vwo-fme-ruby-sdk)\n[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0)\n[![Build Status](https://github.com/wingify/vwo-fme-ruby-sdk/workflows/CI/badge.svg)](https://github.com/wingify/vwo-fme-ruby-sdk/actions)\n[![Coverage Status](https://codecov.io/gh/wingify/vwo-fme-ruby-sdk/branch/master/graph/badge.svg)](https://codecov.io/gh/wingify/vwo-fme-ruby-sdk)\n\n## Overview\n\nThe **VWO Feature Management and Experimentation SDK** (VWO FME Ruby SDK) enables Ruby developers to integrate feature flagging and experimentation into their applications. This SDK provides full control over feature rollout, A/B testing, and event tracking, allowing teams to manage features dynamically and gain insights into user behavior.\n\n## Requirements\n\n- **Ruby 2.6 or later**\n\n## Installation\n\nAdd this line to your application's Gemfile:\n\n```ruby\ngem 'vwo-fme-ruby-sdk'\n```\n\nOr install it directly:\n\n```bash\ngem install vwo-fme-ruby-sdk\n```\n\n## Basic Usage Example\n\nThe following example demonstrates initializing the SDK with a VWO account ID and SDK key, setting a user context, checking if a feature flag is enabled, and tracking a custom event.\n\n```ruby\nrequire 'vwo'\n\n# Initialize VWO client\nvwo_client = VWO.init({\n    sdk_key: '32-alpha-numeric-sdk-key',\n    account_id: '123456'\n})\n\n# Check if feature is enabled for user\nuser_context = { id: 'unique_user_id' }\nflag = vwo_client.get_flag('feature_key', user_context)\n\nif flag.is_enabled\n  puts 'Feature is enabled!'\n\n  # Get feature variable\n  value = flag.get_variable('feature_variable', 'default_value')\n  puts \"Variable value: #{value}\"\nend\n\n# Track an event\nvwo_client.track_event('event_name', user_context)\n\n# Set attribute(s)\nvwo_client.set_attribute({ attribute_key: 'attribute_value' }, user_context)\n```\n\n## Advanced Configuration Options\n\nTo customize the SDK further, additional parameters can be passed to the `init` method. Here's a table describing each option:\n\n| **Parameter**                | **Description**                                                                                                                                             | **Required** | **Type** | **Example**                     |\n| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | -------- | ------------------------------- |\n| `account_id`                 | VWO Account ID for authentication.                                                                                                                          | Yes          | String   | `'123456'`                      |\n| `sdk_key`                    | SDK key corresponding to the specific environment to initialize the VWO SDK Client. You can get this key from VWO Application.                              | Yes          | String   | `'32-alpha-numeric-sdk-key'`    |\n| `poll_interval`              | Time interval for fetching updates from VWO servers (in milliseconds).                                                                                           | No           | Integer  | `60000`                            |\n| `gateway_service`            | A hash representing configuration for integrating VWO Gateway Service.                                                                                      | No           | Hash     | see [Gateway](#gateway) section |\n| `storage`                    | Custom storage connector for persisting user decisions and campaign data.                                                                                   | No           | Object   | See [Storage](#storage) section |\n| `logger`                     | Toggle log levels for more insights or for debugging purposes. You can also customize your own transport in order to have better control over log messages. | No           | Hash     | See [Logger](#logger) section   |\n| `integrations`               | A hash representing configuration for integrating VWO with other services. | No           | Hash     | See [Integrations](#integrations) section |\n| `threading`                  | Toggle threading for better (enabled by default) performance.                                                                               | No           | Hash     | See [Threading](#threading) section |\n| `batch_event_data`           | Configuration for batch event processing to optimize network requests. | No           | Hash     | See [Batch Events](#batch-events) section |\n| `proxy_url`               | Custom proxy URL for redirecting all SDK network requests through a proxy server. | No           | String     | See [Proxy URL](#proxy-url) section |\n\nRefer to the [official VWO documentation](https://developers.vwo.com/v2/docs/fme-ruby-install) for additional parameter details.\n\n### User Context\n\nThe `context` object uniquely identifies users and is crucial for consistent feature rollouts. A typical `context` includes an `id` for identifying the user. It can also include other attributes that can be used for targeting and segmentation, such as `customVariables`, `userAgent` and `ipAddress`.\n\n#### Parameters Table\n\nThe following table explains all the parameters in the `context` hash:\n\n| **Parameter**      | **Description**                                                            | **Required** | **Type** | **Example**                       |\n| ----------------- | -------------------------------------------------------------------------- | ------------ | -------- | --------------------------------- |\n| `id`              | Unique identifier for the user.                                            | Yes          | String   | `'unique_user_id'`                |\n| `customVariables`| Custom attributes for targeting.                                           | No           | Hash     | `{ age: 25, location: 'US' }`     |\n| `userAgent`      | User agent string for identifying the user's browser and operating system. | No           | String   | `'Mozilla/5.0 ... Safari/537.36'` |\n| `ipAddress`      | IP address of the user.                                                    | No           | String   | `'1.1.1.1'`                       |\n| `bucketingSeed`  | Custom seed for bucketing. Overrides user ID in the hashing algorithm to control variation assignment. Must be a non-empty string. | No | String | `'account-xyz'` |\n\n#### Example\n\n```ruby\nuser_context = {\n  id: 'unique_user_id',\n  customVariables: { age: 25, location: 'US' },\n  userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36',\n  ipAddress: '1.1.1.1'\n}\n```\n\n### FME Web Connectivity\n\nFME Web Connectivity allows you to keep visitor identity and sessions in sync between the Ruby SDK and VWO Web Insights.\n\n#### Using web UUID from `context[:id]`\n\nWhen **web connectivity is enabled**, if you pass a valid VWO Web UUID in `context[:id]`, the Ruby SDK will **use it directly as the visitor UUID** instead of hashing/generating a new one.  \nYou can then read the same UUID from the flag result via `flag.get_uuid` (for example, to pass it to the web client or other services).\n\n```ruby\nrequire 'vwo'\n\nvwo_client = VWO.init({\n  account_id: 123456,\n  sdk_key: '32-alpha-numeric-sdk-key'\n})\n\n# Default: SDK generates a UUID from id and account\ncontext_with_generated_uuid = { id: 'user-123' }\nflag1 = vwo_client.get_flag('feature-key', context_with_generated_uuid)\nuuid1 = flag1.get_uuid\nputs \"Visitor UUID (generated): #{uuid1}\"\n\n# Use your own UUID (e.g. from VWO Web SDK) by passing a valid web UUID in context[:id]\ncontext_with_custom_uuid = {\n  id: 'D7E2EAA667909A2DB8A6371FF0975C2A5' # your existing VWO Web UUID\n}\nflag2 = vwo_client.get_flag('feature-key', context_with_custom_uuid)\nuuid2 = flag2.get_uuid\nputs \"Visitor UUID (from context[:id]): #{uuid2}\"\n```\n\nIf `context[:id]` is not a valid web UUID, the SDK falls back to server-side UUID derivation based on `id` and `account_id`, and `flag.get_uuid` will return that derived UUID.\n\n#### Working with `sessionId`\n\nThe Ruby SDK also exposes the session identifier via `flag.get_session_id` on the flag result, which is useful for aligning sessions with the VWO Web SDK or other systems:\n\n- If you **provide** a `sessionId` in the context (as an `Integer`), the SDK uses it as-is.\n- If you **omit** `sessionId`, the SDK automatically generates one using the current Unix timestamp.\n\n```ruby\n# Reuse a session ID from your web layer\ncontext_with_session = {\n  id: 'user-123',\n  sessionId: Time.now.to_i # or a session ID from your web client\n}\n\nflag = vwo_client.get_flag('feature-key', context_with_session)\nsession_id = flag.get_session_id\nputs \"Session ID: #{session_id}\"\n```\n\n### Custom Bucketing Seed\n\nBy default, the SDK uses the user `id` to determine which variation a user receives. The `bucketingSeed` option in the context lets you override this with a shared identifier (e.g. a company ID), so all users sharing the same seed are bucketed into the same variation.\n\n| Parameter       | Description                                               | Required | Type   | Example         |\n| --------------- | --------------------------------------------------------- | -------- | ------ | --------------- |\n| `bucketingSeed` | A custom string used for bucketing instead of user `id`   | No       | String | `'company-abc'` |\n\n#### Example Usage\n\n```ruby\n# All employees of company-abc will get the same variation\ncontext = {\n  id: 'employee-123',\n  bucketingSeed: 'company-abc'\n}\nflag = vwo_client.get_flag('feature-key', context)\n```\n\n### Basic Feature Flagging\n\nFeature Flags serve as the foundation for all testing, personalization, and rollout rules within FME.\nTo implement a feature flag, first use the `get_flag` API to retrieve the flag configuration.\nThe `get_flag` API provides a simple way to check if a feature is enabled for a specific user and access its variables. It returns a feature flag object that contains methods for checking the feature's status and retrieving any associated variables.\n\n| Parameter     | Description                                                      | Required | Type   | Example              |\n| ------------ | ---------------------------------------------------------------- | -------- | ------ | -------------------- |\n| `feature_key`| Unique identifier of the feature flag                            | Yes      | String | `'new_checkout'`     |\n| `context`    | Hash containing user identification and contextual information   | Yes      | Hash   | `{ id: 'user_123' }` |\n\nExample usage:\n\n```ruby\nflag = vwo_client.get_flag('feature_key', user_context)\nis_enabled = flag.is_enabled\n\nif is_enabled\n  puts 'Feature is enabled!'\n\n  # Get and use feature variable with type safety\n  variable_value = flag.get_variable('feature_variable', 'default_value')\n  puts \"Variable value: #{variable_value}\"\nelse\n  puts 'Feature is not enabled!'\nend\n```\n\n### Custom Event Tracking\n\nFeature flags can be enhanced with connected metrics to track key performance indicators (KPIs) for your features. These metrics help measure the effectiveness of your testing rules by comparing control versus variation performance, and evaluate the impact of personalization and rollout campaigns. Use the `track_event` API to track custom events like conversions, user interactions, and other important metrics:\n\n| Parameter          | Description                                                            | Required | Type   | Example                |\n| ----------------- | ---------------------------------------------------------------------- | -------- | ------ | ---------------------- |\n| `event_name`      | Name of the event you want to track                                    | Yes      | String | `'purchase_completed'` |\n| `context`         | Hash containing user identification and other contextual information   | Yes      | Hash   | `{ id: 'user_123' }`   |\n| `event_properties`| Additional properties/metadata associated with the event               | No       | Hash   | `{ amount: 49.99 }`    |\n\nExample usage:\n\n```ruby\nvwo_client.track_event('event_name', user_context, { amount: 49.99 })\n```\n\nSee [Tracking Conversions](https://developers.vwo.com/v2/docs/fme-ruby-metrics#usage) documentation for more information.\n\n### Pushing Attributes\n\nUser attributes provide rich contextual information about users, enabling powerful personalization. The `set_attribute` method provides a simple way to associate these attributes with users in VWO for advanced segmentation. Here's what you need to know about the method parameters:\n\n| Parameter          | Description                                                            | Required | Type   | Example                |\n| ----------------- | ---------------------------------------------------------------------- | -------- | ------ | ---------------------- |\n| `attribute_map`   | A hash of attributes to set.                                          | Yes      | Hash   | `{ userType: 'paid'}` |\n| `context` | Hash containing user identification and other contextual information   | Yes      | Hash   | `{ id: 'user_123' }`   |\n\n```ruby\nvwo_client.set_attribute({ userType: 'paid' }, user_context)\n```\nSee [Pushing Attributes](https://developers.vwo.com/v2/docs/fme-ruby-attributes#usage) documentation for additional information.\n\n### Polling\n\nThe `poll_interval` is an optional parameter that allows the SDK to automatically fetch and update settings from the VWO server at specified intervals. Setting this parameter ensures your application always uses the latest configuration. The polling interval can be configured in three ways:\n\n1. Set via SDK options: If `poll_interval` is specified in the initialization options (must be \u003e= 1000 milliseconds), that interval will be used\n2. VWO Application Settings: If configured in your VWO application settings, that interval will be used\n3. Default Fallback: If neither of the above is set, a 10 minute (600,000 milliseconds) polling interval is used\n\nSetting this parameter ensures your application always uses the latest configuration by periodically checking for and applying any updates.\n\n```ruby\n# poll_interval is in milliseconds\nvwo_client = VWO.init({ account_id: '123456', sdk_key: '32-alpha-numeric-sdk-key', poll_interval: 60000 })\n```\n\n### Gateway\n\nThe VWO FME Gateway Service is an optional but powerful component that enhances VWO's Feature Management and Experimentation (FME) SDKs. It acts as a critical intermediary for pre-segmentation capabilities based on user location and user agent (UA). By deploying this service within your infrastructure, you benefit from minimal latency and strengthened security for all FME operations.\n\n#### Why Use a Gateway?\n\nThe Gateway Service is required in the following scenarios:\n\n- When using pre-segmentation features based on user location or user agent.\n- For applications requiring advanced targeting capabilities.\n- It's mandatory when using any thin-client SDK (e.g., Go).\n\n#### How to Use the Gateway\n\nThe gateway can be customized by passing the `gateway_service` parameter in the `init` configuration.\n\n```ruby\nvwo_client = VWO.init({\n  account_id: '123456',\n  sdk_key: '32-alpha-numeric-sdk-key',\n  gateway_service: {\n    url: 'http://custom.gateway.com',\n  },\n});\n```\n\nRefer to the [Gateway Documentation](https://developers.vwo.com/v2/docs/gateway-service) for further details.\n\n### Storage\n\nThe SDK operates in a stateless mode by default, meaning each `get_flag` call triggers a fresh evaluation of the flag against the current user context.\n\nTo optimize performance and maintain consistency, you can implement a custom storage mechanism by passing a `storage` parameter during initialization. This allows you to persist feature flag decisions in your preferred database system (like Redis, MongoDB, or any other data store).\n\nKey benefits of implementing storage:\n\n- Improved performance by caching decisions\n- Consistent user experience across sessions\n- Reduced load on your application\n\nThe storage mechanism ensures that once a decision is made for a user, it remains consistent even if campaign settings are modified in the VWO Application. This is particularly useful for maintaining a stable user experience during A/B tests and feature rollouts.\n\n```ruby\nclass StorageConnector\n  def get(feature_key, user_id)\n    # Return stored data based on feature_key and user_id\n  end\n\n  def set(data)\n    # Store data using data[:feature_key] and data[:user_id]\n  end\nend\n\nvwo_client = VWO.init({\n    account_id: '123456',\n    sdk_key: '32-alpha-numeric-sdk-key',\n    storage: StorageConnector.new\n})\n```\n\n### Logger\n\nVWO by default logs all `ERROR` level messages to your server console.\nTo gain more control over VWO's logging behaviour, you can use the `logger` parameter in the `init` configuration.\n\n| **Parameter** | **Description** | **Required** | **Type** | **Example** |\n| ------------- | --------------- | ------------ | -------- | ----------- |\n| `level`       | Log level to filter messages. | No | Symbol | `DEBUG` |\n| `prefix`      | Prefix for log messages. | No | String | `'CUSTOM LOG PREFIX'` |\n\n#### Example 1: Set log level to control verbosity of logs\n\n```ruby\n# Set log level\nvwo_client = VWO.init({\n    account_id: '123456',\n    sdk_key: '32-alpha-numeric-sdk-key',\n    logger: {\n        level: 'DEBUG'\n    }\n})\n```\n\n#### Example 2: Add custom prefix to log messages for easier identification\n\n```ruby\n# Set log level\nvwo_client = VWO.init({\n    account_id: '123456',\n    sdk_key: '32-alpha-numeric-sdk-key',\n    logger: {\n        level: 'DEBUG',\n        prefix: 'CUSTOM LOG PREFIX'\n    }\n})\n```\n\n### Integrations\n\nVWO FME SDKs help you integrate with several third-party tools, be it analytics, monitoring, customer data platforms, messaging, etc., by implementing a very basic and generic callback capable of receiving VWO-specific properties that can then be pushed to any third-party tool.\n\n```ruby\ndef callback(data)\n    puts \"Integration data: #{data}\"\nend\n\nvwo_client = VWO.init({\n    account_id: '123456',\n    sdk_key: '32-alpha-numeric-sdk-key',\n    integrations: {\n        callback: method(:callback)\n    }\n})\n```\n\n### Threading\n\nThe SDK leverages threading to efficiently manage concurrent operations. Threading is enabled by default, but can be disabled by configuring the `threading` parameter during initialization. This gives you control over the SDK's concurrency behavior based on your application's needs.\n\n| Parameter | Description | Required | Type | Default |\n| --------- | ----------- | -------- | ---- | ------- |\n| `enabled` | Enable or disable threading. | No | Boolean | `true` |\n| `max_pool_size` | Maximum number of threads to use for background event processing. | No | Integer | `5` |\n| `max_queue_size` | Maximum number of events that can be queued for background processing. | No | Integer | `10000` |\n\n**About `max_pool_size`**\n\nThe `max_pool_size` parameter sets the upper limit for the number of background threads the SDK can use to process events concurrently.\n\n- **Short summary:** It controls how many events can be processed in parallel by background threads.\n- **Detailed explanation:**\n  - When threading is enabled, the SDK uses a thread pool to process events (such as tracking calls) in the background.\n  - `max_pool_size` determines the maximum number of threads that can run at the same time.\n  - If all threads are busy, new events are placed in the queue (up to `max_queue_size`).\n  - Increasing `max_pool_size` can improve throughput for high-traffic applications, but may increase resource usage (CPU, memory).\n  - Setting it too high may overwhelm your system; setting it too low may cause event processing delays.\n  - Adjust this value based on your application's concurrency needs and available resources.\n\n**About `max_queue_size`**\n\nThe `max_queue_size` parameter controls how many events can be waiting in the background processing queue managed by the SDK's thread pool.\n\n- **Short summary:** It sets the upper limit for how many events can be queued for background processing.\n- **Detailed explanation:**\n  - When you use threading (enabled by default), events such as tracking calls are placed in a queue to be processed by background threads.\n  - `max_queue_size` determines the maximum number of events that can wait in this queue.\n  - If the queue is full (all threads are busy and the queue has reached its limit), any new event will be processed immediately in the main thread (blocking it until done) until space becomes available in the queue.\n  - This mechanism helps balance throughput and resource usage, ensuring you don't lose events but also don't overload your system.\n  - You can adjust this value based on your application's expected event volume and performance needs.\n\n#### Disable Threading\n\nWhen threading is disabled, all tracking calls will block the main execution thread until they complete. This means your application will wait for each VWO operation before continuing.\n\nExample showing blocking behavior:\n\n```ruby\n# By disabling threading, the SDK will wait for the response from the server for each tracking call.\nvwo_client = VWO.init({\n    account_id: '123456',\n    sdk_key: '32-alpha-numeric-sdk-key',\n    threading: {\n        enabled: false\n    },\n})\n```\n\n#### Enable Threading (Default)\n\nThreading in the VWO SDK provides several important benefits:\n\n1. **Asynchronous Event Tracking**: When enabled, all tracking calls are processed asynchronously in the background. This prevents these network calls from blocking your application's main execution flow.\n\n2. **Improved Performance**: By processing tracking and network operations in separate threads, your application remains responsive and can continue serving user requests without waiting for VWO operations to complete.\n\nExample of how threading improves performance:\n- Without threading: Each tracking call blocks until the server responds\n- With threading: Tracking calls return immediately while processing happens in background\n\nThe SDK uses a thread pool to manage these concurrent operations efficiently. The default pool size of 5 threads is suitable for most applications, but you can adjust it based on your needs:\n\n```ruby\n# By default, threading is enabled and the max_pool_size is set to 5.\n# you can customize the max_pool_size by passing the max_pool_size parameter in the threading configuration.\nvwo_client = VWO.init({\n    account_id: '123456',\n    sdk_key: '32-alpha-numeric-sdk-key',\n    threading: {\n        enabled: true,\n        max_pool_size: 10\n    },\n})\n```\n\n### Batch Events\n\nThe `batch_event_` configuration allows you to optimize network requests by batching multiple events together. This is particularly useful for high-traffic applications where you want to reduce the number of API calls.\n\n| **Parameter**         | **Description**                                                         | **Required** | **Type** | **Default** |\n| --------------------- | ----------------------------------------------------------------------- | ------------ | -------- | ----------- |\n| `request_time_interval` | Time interval (in seconds) after which events are flushed to the server | No           | Integer   | `600`       |\n| `events_per_request`    | Maximum number of events to batch together before sending to the server | No           | Integer   | `100`       |\n| `flush_callback`       | Callback function to be executed after events are flushed               | No           | Function | See example |\n\nExample usage:\n\n```ruby\nrequire 'vwo'\n\n# flushCallBack method\ndef call(error, data)\n    # custom implementation here\nend\n\n# Initialize VWO client\nvwo_client = VWO.init({\n    sdk_key: '32-alpha-numeric-sdk-key',\n    account_id: '123456',\n    batch_event_data: {\n        events_per_request: 50, # Optional: 50 events per request (default is 100)\n        request_time_interval: 60 # Optional: send events every 60 seconds (default is 600 seconds)\n        flush_callback: method(:call) # Optional: callback to execute after flush \n    },\n})\n```\n\n- You can also manually flush events using the `flush_events()` method:\n\n```ruby\nvwo_client.flush_events()\n```\n\n### Proxy URL\n\nThe `proxy_url` parameter allows you to redirect all SDK network calls through a custom proxy server. This feature enables you to route all SDK network requests (settings, tracking, etc.) through your own proxy server, providing better control over network traffic and security.\n\n#### How to Use Proxy URL\n\nThe proxy URL can be configured by passing the `proxy_url` parameter in the `init` configuration.\n\n```ruby\nvwo_client = VWO.init({\n    sdk_key: '32-alpha-numeric-sdk-key',\n    account_id: '123456',\n    proxy_url: 'https://custom.proxy.com'\n})\n```\n**Note:** If both `gateway_service` and `proxy_url` are provided, the SDK will give preference to the `gateway_service` for all network requests.\n\n## Version History\n\nThe version history tracks changes, improvements, and bug fixes in each version. For a full history, see the [CHANGELOG.md](https://github.com/wingify/vwo-fme-ruby-sdk/blob/master/CHANGELOG.md).\n\n## Development and Testing\n\n```bash\nchmod +x ./start-dev.sh\nbash start-dev.sh\nbundle install\n```\n\n## Running Unit Tests\n\n```bash\nruby tests/run_all_tests.rb\n```\n\n## Contributing\n\nWe welcome contributions to improve this SDK! Please read our [contributing guidelines](https://github.com/wingify/vwo-fme-ruby-sdk/blob/master/CONTRIBUTING.md) before submitting a PR.\n\n## Code of Conduct\n\nOur [Code of Conduct](https://github.com/wingify/vwo-fme-ruby-sdk/blob/master/CODE_OF_CONDUCT.md) outlines expectations for all contributors and maintainers.\n\n## License\n\n[Apache License, Version 2.0](https://github.com/wingify/vwo-fme-ruby-sdk/blob/master/LICENSE)\n\nCopyright 2025 Wingify Software Pvt. Ltd.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwingify%2Fvwo-fme-ruby-sdk","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fwingify%2Fvwo-fme-ruby-sdk","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwingify%2Fvwo-fme-ruby-sdk/lists"}