Setting up a targeting verification “at regular intervals until the conditions are met” for your campaigns

In September 2022, the “wait until” mode of the targeting has been removed for all new campaigns, including the duplicated ones.

NOTE: this feature can be referred to with multiple names: “wait until” mode, asynchronous targeting, targeting until conditions are met, AJAX mode. They all refer to the exact same feature that used to be available in the targeting step of your campaigns:

Why did we remove this option?

In the targeting options for a campaign, you used to have two choices for the verification frequency. It was either “when the page loads” or “at regular intervals until the conditions are met”, also known as “wait until” mode.

The first option (“when the page loads”) was useful if you wanted your targeting to be checked as soon as possible when the page loads but not after because you know your targeting criteria will either be valid or not at this particular moment.

The second option (“at regular intervals”) was useful if you knew that the condition could be true after the loading of the page, especially on single-page apps.

By using the “wait until” mode, you had a universal way to ask our targeting engine to “wait” and constantly look for your targeting condition(s) to be true.

However, during our research on the tag performance, we’ve measured that in some situations this mode can have a tremendous impact on the overall performance of both our tag and your website. We’ve literally found situations where this feature could lead to multiplying the execution time of our tag by 27 (!!).

While this mode is convenient to wait for the extra hundreds of milliseconds needed for your targeting to be valid on the targeted pages, the downside is also that the targeting will be constantly verified on all pages until conditions are valid… Even if there is absolutely no chance that it comes true.

If you set a URL targeting to loop until it is true, it is easy to understand that whatever happens, this criterion will never be true unless it has been validated in the very first times of the page load.

That’s obviously an illustrative dummy example. We have already added, ages ago, counter-measures to make sure that our tag won’t loop for impossible criteria to happen. Unfortunately, there are scenarios where we can’t make sure of this, even legit scenarios where the tag will be looping for seconds before validating your criteria.

This is where the logic of building a universal and unique solution arrives at a dead-end. Although we understand this mode was easy and convenient to use, we had to split it into multiple alternatives to make sure we keep offering you the same abilities without sacrificing your website performance.

For months, we’ve gathered feedback and analyzed our data to understand how you are using this tool. Then, we’ve designed, one after another, alternatives to allow you to do the exact same thing, but differently (and more efficiently).


Alternative options

Code targeting

We are supporting JS Promises in the code targeting. This fully replaces the use of the “wait until” mode in an easy way for developers.


Selector targeting (id/class/element criterion)

This criterion is using a mutation observer instead of a simple DOM element query.

If this sounds too technical for you, don’t worry! This only impacts the backend behavior of our tag and won’t change the way you are using this criterion.

You can keep using it as usual and the behavior will be the same.

We added an option where you can decide if this criterion can change or not (default) over time. This can be useful if you know your element won’t be there at first but will appear after a while.

This is technically the switch between the “at page loads” option and the “wait until” mode but at the criterion level.


Keep in mind that if your goal is to make this validation works on a SPA, you better get interested in the [Automatic reload of the framework] option which would cover this use case.


Datalayer and JS variable targeting

While some data layers are available on page load (Google Tag Manager and Tag Commander do, for example), it is not always the case, particularly if you are using your own in-house data layer.

To handle each of the possible situations, you now have three options:

  • Check availability at page load
  • Check availability at regular intervals

It is a direct copy of the “wait until” mode but it is limited in its impact. Choose your looping interval between three values (100/500/1000 milliseconds) and the loop will stop after 10 iterations.

  • Use an event. 

From the data layer or anywhere else, you can throw an event to our tag to validate the entirety or a part of a targeting. By setting up a hand-shake between your data layer and our tag, you will make sure to let our tag check its value only at the most appropriate moment.

Read more here.


Action Tracking targeting

Every targeting coming from AB Tasty actions will be handled on our side. This includes Action Tracking targeting, but also transaction-based, segment-based or item-based targeting.

When one of these actions will be performed, our tag will reevaluate the corresponding targetings, if any.

Recreating previous behavior

You can still build up your own “wait until” mode. To do so, simply create a code targeting, set up a setInternal or setTimeout function in it and let it loop as long as you need!

Keep in mind that you might degrade your website performance if your loop isn’t appropriately designed.


Cookie targeting support

Based on our observations and knowledge, we’ve considered there wasn’t a need for an alternative for the cookie targeting. A cookie shouldn’t change during the navigation and in the event it does, there are multiple ways to cover this situation, starting with a code targeting or by firing an event.


What about live campaigns using this mode?

If you still have campaigns running with the “Ajax” mode, we recommend pausing or duplicating them. When duplicating these campaigns, if you still want to verify the targeting at regular intervals, you will need to use one of the methods explained above, as an alternative.

You can find the list of campaigns using this mode in the Performance Center.

Note that campaigns shouldn’t be running for more than one year, as this truly impacts the performance of your tag.
From the beginning of July, we will completely remove this part in our tag to speed up its overall performance, and your campaigns containing “Ajax” mode will be automatically paused.

However, all of your new campaigns, including the duplicated one, won’t have this setting available.

Was this article helpful?