Whenever you create an A/B test, you want to pay attention to your response handlers - particularly when changing your input fields. This guide gives you a detailed explanation of how Heyflow handles input fields and response handlers in an A/B test.
The Setup
Create your flow as you usually would
Create an A/B test
System behavior - Use cases
These two behaviors are always true when creating A/B tests:
Any input that originates from the baseline will remain matched with the response handler, no matter if you rename the label or screen.
In the dropdown to match a field, the system will show all fields for the Baseline first and then the screens that are exclusive to the Variant.
Use Cases
Depending on the changes that you are making to the input fields after creating your A/B test, the system behaves as follows:
No changes in the input fields (Default)
All fields are matched between Baseline and Variant.
On the field matching screen, you will see that all fields are tagged as
Both versions.
No changes in the input fields, but changes in the screen name
All fields remain matched between Baseline and Variant:
The field will remain matched with the response handler.
After renaming a screen (or multiple) the full mapping will still work and show the updated name of the screen, based on the screen name of the Baseline.
On the field matching screen, you will see that all fields are tagged as
Both versions.
Changing the label of an input field
All fields remain matched between Baseline and Variant:
The field will remain matched with the response handler.
After renaming a label (or multiple) the full mapping will still work and show the two fields as separate entities. Upon selecting one of them for matching with the response handler, the other will automatically be selected as well.
On the field matching screen, you will see that all fields are tagged as
Both versionssince the system does not differentiate between them.
Adding a new field to one of the versions
❗ The new field needs to be matched with the Response Handler manually.
All other fields remain matched between Baseline and Variant.
On the field matching screen, you will see that the new field is tagged as
BaselineorVariant(dependent on where you added the field) under the respective screen.
Breaking a single-screen form into three screens
The normal approach is to duplicate the respective screen twice, delete the obsolete fields, and then rename the screens.
❗ By default, 2 out of the 3 input fields will have a new label (e.g. Email1 and Phone2). Those are now new fields that are not matched and need to be matched manually.
Upon matching those Heyflow fields to the same response handler field twice, you will receive a notification which - in this instance - is safe to ignore.
On the field matching screen, you will see that these new fields are tagged as
BaselineorVariant(dependent on where you added the field) under the respective screens.
Deleting a field from a version
The data will no longer be sent to the response handler.
❗ Check if the field is required by your response handler. If so, it cannot receive the response and will throw errors, e.g. Salesforce and Recruitee indicate if a field is mandatory, HubSpot does not.