When a page loads, the AB Tasty tag verifies the targeting conditions. At this point, the URL of the page, the elements used to trigger the campaign (ID/Class/Element option), the segment and the defined trigger can be detected. The campaign is only displayed to visitors who meet the targeting conditions.
However, some elements are called after the page has initially loaded, with a slight delay, or after the visitor completes a certain action.
In this case, you must determine how the verification will be performed in order to detect the appearance of these elements/actions on the page(s) and thus to let AB Tasty display the campaign.
Only the following criteria may require a customized type of verification:
- The code trigger
- The CSS selector trigger
- The Data layer and JS variable triggers
- The Action tracking segment
⭐ Good to know
The verification method used to be selected at the targeting level. It can now only be customized for the criteria mentioned above. To know more about this change, refer to Why did we remove the “wait until” mode from the targeting?
If the previous “at regular intervals” option used to fit one of your use cases that none of our alternatives cover, you can still build up your own. To do so, you can set up a setInternal or setTimeout function in the code criterion and let it loop as long as you need. Keep in mind that you might degrade your website performance if your loop is not configured properly.
Code trigger criterion
This criterion enables you to trigger a campaign depending on the presence of a specific JS instruction. As this instruction may not be present when the page loads, the verification must be done ‘at regular intervals’.
As a replacement to the previous method, you can use JS Promises directly within the code criterion. This method is easy to use by developers.
CSS selector trigger criterion (id/class/element)
This criterion now uses a mutation observer instead of a simple DOM element query. This only impacts the backend behavior of our tag and won’t change the way you use this criterion.
A check box enables you to decide if this criterion can change or not (default) over time.
- When the box is not checked: the criterion is verified when the page loads.
- When the box is checked: the criterion will be triggered when we detect that the element has appeared or disappeared for the first time. This can be useful if you know your element will appear or disappear after a while.
If your goal is to make this validation work on an SPA, you are better off using the Automatic reload of the framework option.
Data layer and JS variable trigger criteria
While some data layers are available on page load (such as Google Tag Manager or Tag Commander), this is not always the case, particularly if you are using your own in-house data layer. To handle all situations, you can choose to verify the targeting criterion:
- When the page loads
- At regular intervals
Choose your looping interval between three values (100/500/1000 milliseconds) and the loop will stop after 10 iterations.
- According to a JS event.
From the data layer or anywhere else, you can now throw an event to our tag to validate your campaign targeting (or part of it). This way, you can make sure our tag will check its value at the most appropriate time only.
For more information, refer to our developer portal article. Read more here.
Action Tracking segment criterion
All targeting criteria coming from AB Tasty actions (or events) are now handled on our side, meaning that when one action is performed, our tag will automatically reevaluate the corresponding targeting criteria (if any) to be able to display the campaign.
This includes the Action Tracking criterion, but also transaction-based, segment-based or item-based criteria (such as Last Purchase, Purchase Frequency, e-commerce, etc.).
In this case, you don’t have to configure anything on the platform.
⭐ Good to know
For performance purposes, we strongly advise that you manually update your live campaigns using the ‘at regular intervals’ option and apply it directly within the criteria that require it. You can find the list of campaigns using this option in the Performance Center.
⭐ Good to know
Based on our observations and knowledge, we considered that the cookie criterion didn’t require a verification alternative. Indeed, a cookie doesn’t change during the visitor’s browsing and even if it does, there are multiple ways to cover this situation, such as using a code targeting or firing an event. This criterion will thus be verified when the page loads.
Need additional information?
Submit your request at firstname.lastname@example.org
Always happy to help!