The segment settings allow you to customize how Wingify segmentation and targeting criteria apply to a test running on your website and how visitors are evaluated to qualify for a specific segment.
To configure the settings for your segments, go to your campaign > Targeting > Segments and click Settings. Using this option, you can manage the following:
- Set up how Wingify should check visitors’ segment conditions.
- Decide when to display the modified elements.
- Until when should Wingify look for the specific changes in the code.
For example, Wingify stores information when a visitor becomes a part of any test. This information is stored when the visitor qualifies for a segment and becomes a part of a test for the first time. Whenever the visitor lands again on the test pages, Wingify will look for the cookie rather than checking the segment conditions every time. With the Settings option, you can configure how you would want to check the segment conditions of the visitors.
Check Targeting Conditions for a Visitor
In this section, you can choose how you would require Wingify to check for the targeting conditions for your website visitors. The option Once is selected by default, which means the visitor segment condition is only checked once, and the same variation is served to the visitor on every subsequent visit.
If you choose Every time, the visitor is evaluated against the segment condition on every visit to the website (every page reload). Also, the visitor is evaluated for the segment conditions on all goal pages as well. This typically means that when visitors click a button or visit a page defined as a goal in your test, they must satisfy the segment conditions for their conversion to be recorded.
For example, you have created a personalization campaign that shows specific content to all the visitors landing on your website from a Google ad. Now, you want to ensure that visitors who do not come from this ad are not shown this content. For such cases, please choose the option Every time to check visitor eligibility on every page they visit to make sure that the changes are implemented and displayed only when the visitor qualifies for the segment. This way, the campaign goal is triggered only after a visitor qualifies and will collect accurate report data.
Note: If your targeting condition contains Behavior options, the visitors are evaluated for all conditions excluding the defined behaviour (like clicking on an element). The variation is displayed to the visitors only after fulfilling all other conditions and becoming eligible for the test.
Make Modified Elements Visible When
When you make any changes using Wingify’s visual editor, Wingify tracks all the elements that are changed. When a visitor lands on the test page, Wingify first hides all the changes during page load, fetches the changes that you made to the element, applies those changes, and then displays the modified content to the visitors. This ensures that there is no flickering effect on the page while Wingify is loading the changes for the visitor.
The Make modified elements visible when field lets you specify when to show the modified elements to the visitors by using one of the following options:
- Campaign executes: Display the changed elements as soon as Wingify evaluates the eligibility of the visitors for the segment. This is the default option when the segment does not involve behavioural conditions.
- DOM Ready: Elements are displayed when the HTML is loaded fully and parsed. To learn more about DOM Ready, refer to DOMContentLoaded event.
- Custom Event: You can define a custom event according to which the changes load. For example, you may want to display the elements only after a visitor acts on the page, or after a certain time gap, and so on.
- Always (elements are not hidden): The modified elements are not hidden during page load. On selecting this option, visitors may experience a flickering effect on the page reload when the original content is updated. This is the default option if the segment involves any Behavior condition (like clicking on an element or the user is trying to close the page).
Note: By default, elements are not hidden for Behavior targeting options (like clicking on an element). This is because Wingify doesn’t know when the website visitor will click that defined element or exit the page. Hence, the elements are not hidden on the page by default. You can change this option per your test requirements.
Poll Until (applies to javascript variable and cookie value)
If you use a JavaScript variable or a cookie value for setting targeting conditions, Wingify will check the segment condition until DOM Ready. This ensures that all variables/cookies are initialized on the page.
Note: The Poll Until option is disabled if you are not using a cookie or JavaScript value for segment conditions.
The Poll Until lets you configure when to stop polling for a variable/cookie by using these options:
Polling Disabled: Use this option to disable polling for a JavaScript variable and a Cookie value. It means that Wingify will not wait for all the variables/cookies to initialize and evaluate the visitor segment condition as soon as Wingify SmartCode executes on the page.
Note: You may find this condition selected for tests created before this feature was launched.
- DOM Ready: This is the default selection where polling ends only when the HTML is loaded fully and parsed. To learn more about DOM Ready, refer to DOMContentLoaded event.
- Custom Event: Using this option, you can define a custom event until which the polling should run. For example, you may want to continue polling until your CRM variables are loaded on the page.
- Condition is true: Choosing this option ensures that polling runs until the specified JavaScript variable/Cookie value conditions are met for the visitor. When this option is selected, the condition is periodically evaluated for an infinite time. Therefore, it should be used with discretion.