VWO

Before writing any FlutterFlow code, set up the experiment in VWO's dashboard. Log in to VWO, navigate to FME (Feature Management & Experimentation) in the top nav, and click Create Feature Flag. Give the flag a clear, machine-readable key name like `checkout_flow` or `new_home_screen` — this is the flagKey you will reference in your Custom Action code, so avoid spaces or special characters. Use lowercase letters and underscores. Define your variations. VWO always includes a Control variation (the default experience). Add one or more additional variations — name them descriptively like `variant_a` or `single_page` rather than generic names like `B` or `v2`. These names are what getFlag will return, and you will reference them in FlutterFlow's Conditional Visibility rules. Set the traffic split: the percentage of users assigned to each variation. Start with a 50/50 split for a new experiment. You can adjust this in the VWO dashboard without releasing a new app build — this is one of the key advantages of FME over hardcoded feature branches. Find your SDK key: in VWO's FME section, go to Settings → SDK Keys (the path may vary slightly by plan — look for Environments or Integration). The SDK key is associated with a specific environment (production, staging). Copy the production SDK key and your account ID. Note that the SDK key is environment-scoped: using a staging key in production assigns users to staging experiment configurations, which is a common source of test contamination.

In FlutterFlow, open the left nav and click Custom Code. Click + Add and select Action. Name the action InitVWO. In the Dependencies field, add the VWO FME Flutter/mobile SDK package. Search pub.dev for the current VWO FME Flutter package — look for an official VWO package under the VWO or vwoFME namespace. Add the exact package name and FlutterFlow will resolve the version from pub.dev. In the Dart code editor, write the initialization. The VWO FME SDK initialization is asynchronous and returns a VWO client object. Store this client in a Dart-level static variable so subsequent Custom Actions can call getFlag on it. Wrap the entire function with a `kIsWeb` guard — VWO's mobile SDK is native-only and the web preview will not resolve variations. Import `package:flutter/foundation.dart` for `kIsWeb`. Initialize the SDK with your SDK key and account ID. You can include these directly in the Custom Action code — the SDK key is environment-scoped and is designed to be distributed in client apps (it is analogous to a publishable key: it can be used to look up experiment configurations, but it cannot modify VWO experiment settings or access your account data). Even so, the RapidDev recommendation is to route conversion events through a proxy if you want to eliminate any risk of users spoofing events. Wire the InitVWO Custom Action to your app's root widget or initial page's On Page Load action in FlutterFlow. The SDK fetches a configuration file from VWO's CDN on startup — this is a fast CDN request and does not add meaningful startup delay, but the configuration is cached after the first fetch. Custom Actions do not run in FlutterFlow's web-based Test Mode. Always test on a real device or Run Mode build.

1import 'package:flutter/foundation.dart';
2// Import the VWO FME Flutter SDK package
3// (check pub.dev for the current official VWO FME Flutter package name)
4import 'package:vwo_fme_flutter_sdk/vwo_fme_flutter_sdk.dart';
5
6// Store the VWO client as a module-level variable
7// so GetVWOFlag Custom Action can access it
8VWOClient? _vwoClient;
9
10Future initVWO() async {
11  if (kIsWeb) return;
12
13  final vwoInitOptions = VWOInitOptions(
14    sdkKey: 'YOUR_VWO_FME_SDK_KEY',
15    accountId: YOUR_VWO_ACCOUNT_ID, // integer, no quotes
16  );
17
18  _vwoClient = await VWO.init(vwoInitOptions);
19}

Create a second Custom Action named GetVWOFlag. This action is the core of the integration: it asks VWO which variation to show for a specific user, then stores the answer in a FlutterFlow App State variable so Conditional Visibility rules can use it. The action needs two String arguments: flagKey (the VWO feature flag key you created, like `checkout_flow`) and userId (your app's unique user identifier — the same stable ID you use across Firestore or Supabase). The userId is the basis for VWO's variation assignment: a given userId always receives the same variation for the lifetime of the experiment, ensuring consistent experiences across app sessions. Never use a random ID generated fresh on each app launch — that would assign users to random variations every session. In the function body, build a VWO UserContext object with the userId. You can optionally add custom attributes to the context (like userPlan, country, or accountAge) that match VWO targeting rules you configured in the VWO dashboard for the flag. Then call `_vwoClient?.getFlag(flagKey, userContext)` — this returns a Feature Flag object from which you call `.isEnabled()` to check if the flag is on, and `.getVariable(variableKey, defaultValue)` to get the specific variation name or value. In FlutterFlow, create an App State variable before writing this Custom Action. For a binary test, create a boolean named `showVariantA`. For a multi-variant test, create a String named `checkoutFlowVariant` with a default value of `control`. Set a return value or use the Custom Action's output to update the App State variable. Wire GetVWOFlag to fire On Page Load of the screen where the experiment lives — pass the flagKey and the signed-in user's ID as arguments. If the VWO client is not yet initialized when getFlag is called (because the InitVWO call is still in progress), the SDK returns the default variation. This is graceful degradation — the user sees the control experience, not a blank screen.

1import 'package:flutter/foundation.dart';
2import 'package:vwo_fme_flutter_sdk/vwo_fme_flutter_sdk.dart';
3
4// Reference the module-level client from InitVWO
5extern VWOClient? _vwoClient;
6
7// Arguments: flagKey (String), userId (String)
8// Returns: String (variation name, e.g. 'control' or 'variant_a')
9Future<String> getVWOFlag(
10  String flagKey,
11  String userId,
12) async {
13  if (kIsWeb) return 'control'; // always show default on web
14
15  if (_vwoClient == null) {
16    return 'control'; // graceful fallback if SDK not ready
17  }
18
19  final userContext = VWOContext(userId: userId);
20
21  try {
22    final flag = await _vwoClient!.getFlag(flagKey, userContext);
23    if (flag.isEnabled()) {
24      // Get the variation variable — 'variation_name' must match
25      // the variable key you defined in the VWO flag settings
26      return flag.getVariable('variation_name', 'control') as String;
27    }
28    return 'control';
29  } catch (e) {
30    return 'control'; // always fall back to control on error
31  }
32}

With the variation stored in App State, you can now drive the UI branch in FlutterFlow without writing more Dart code. This is entirely visual configuration in FlutterFlow's UI builder. For a binary test (two variants), the simplest approach is to add two Container widgets to your screen that contain the different UI layouts — one for control, one for variant A. Select the control Container, open its Properties panel, and find the Conditional Visibility section. Add a condition: App State variable `checkoutFlowVariant` equals `control`. Do the same for the variant A Container, with the condition checking for `variant_a`. Now FlutterFlow will show only one Container at a time based on the App State value. For a boolean flag (feature on/off), use a single App State boolean like `showNewHomeScreen`. Wrap the new design in a Container with Conditional Visibility checking `showNewHomeScreen == true`, and wrap the old design with `showNewHomeScreen == false`. If you have more than two variants, stack multiple Containers each with their own Conditional Visibility rule checking the variation String value. This scales to three or four variants cleanly — beyond that, consider restructuring the experiment into multiple binary flags. Test the UI branching in FlutterFlow's web Test Mode by manually changing the App State variable value in the State panel — you can switch between variant values and see the Conditional Visibility update live in the preview canvas even though the actual VWO flag fetch does not run in Test Mode. This is the recommended way to verify your UI branching logic before testing on a real device.

Conversion tracking closes the experiment loop: VWO needs to know when a user completed the target action (purchase, sign-up, feature activation) so it can compute conversion rates per variation. Without trackEvent calls, you can see which variation users were assigned to, but you cannot measure which variation performs better. Create a third Custom Action named TrackVWOConversion. It takes two String arguments: eventName (matching the conversion event name you defined in the VWO FME dashboard) and userId (same stable identifier used in GetVWOFlag). In the function body, call `_vwoClient?.trackEvent(eventName, userContext)` where userContext is a VWOContext built with the same userId. Add the kIsWeb guard and a null check for the client. Wire TrackVWOConversion to the On Tap action of the target widget in your experiment — for a checkout test, this is the 'Place Order' button. For a sign-up experiment, this is the 'Create Account' success callback. Pass the correct event name and the signed-in user's ID. For the web preview fallback: since Custom Actions do not run in FlutterFlow's web Test Mode, your experiment screen would show whichever variant is the current default App State value (which you set to 'control' as a safe default). This means the preview always shows the control variant — which is correct expected behavior. Add a visible note in your FlutterFlow canvas comment: 'Variation set by VWO FME SDK — test on device.' This prevents future confusion when team members wonder why the preview always shows the control. Finally, add a 'settings loaded' flag to prevent UI flicker. Create an App State boolean named `vwoSettingsLoaded` with a default of false. Set it to true at the end of InitVWO. Add a Conditional Visibility rule on the experiment section of your screen: show it only when `vwoSettingsLoaded == true`. While the VWO settings are loading, show a loading indicator or the control UI instead of a blank screen.

1import 'package:flutter/foundation.dart';
2import 'package:vwo_fme_flutter_sdk/vwo_fme_flutter_sdk.dart';
3
4extern VWOClient? _vwoClient;
5
6// Arguments: eventName (String), userId (String)
7Future trackVWOConversion(
8  String eventName,
9  String userId,
10) async {
11  if (kIsWeb) return;
12  if (_vwoClient == null) return;
13
14  final userContext = VWOContext(userId: userId);
15  try {
16    await _vwoClient!.trackEvent(eventName, userContext);
17  } catch (e) {
18    // Log but do not rethrow — conversion tracking failure
19    // should never block the user action itself
20    debugPrint('VWO trackEvent error: $e');
21  }
22}