Why we removed the “wait until” mode from targeting

On the 5th of July 2022, the “wait until” mode of targeting was removed for all new campaigns, including duplicated ones.

⭐ Good to know

This feature is also referred to as asynchronous targeting, ‘at regular intervals until conditions are met’, or AJAX mode. They all refer to the exact same feature:

What was the “wait until” mode?

When you select your campaign targeting options, you have two choices when it comes to the verification frequency:

• When the page loads
• At regular intervals until the conditions are met (also known as “wait until” mode).

If you want 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 point, you are going to select the first option.
However, if you know that the condition can be true after the loading of the page, especially on single-page apps, then you are going to select the second option.
By using the “wait until” mode, you have a universal way of asking our targeting engine to “wait” and constantly look for your targeting condition(s) to be true.

Why did we remove this option?

However, during our research on tag performance, we measured that, in some specific cases, this mode can have a significant impact on the overall performance of both our tag and your website. We have found situations where an inappropriate usage of this feature had a sensible impact on our tag execution time.
While this mode is convenient to wait the extra hundreds of milliseconds needed for your targeting to be valid on the targeted pages, the downside is also that targeting will be constantly verified on all pages until conditions are valid, even if there is absolutely no chance of this happening.

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 is validated the very first seconds the page loads.
A few years ago, we added counter-measures to make sure our tag won’t loop for impossible criteria to happen. Unfortunately, there are scenarios where we can’t make sure this does not happen, 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 comes to a dead-end. Although we understand this mode is 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 have gathered feedback and analyzed our data to understand how you were using this option. Now, we have designed alternatives to allow you to do the exact same thing, but differently (and more efficiently).

Which criteria should not be verified during page loading?

Only the following criteria may require a different type of verification:

• The code trigger
• The CSS selector trigger
• The Data layer trigger
• The JS variable trigger
• The Action tracking segment

They usually include some elements that are called after the initial loading of the page, with a slight delay, or after the visitor completes a certain action.
For more information on how to configure a customized verification, refer to Defining targeting criteria verification.

Is it possible to keep the looping feature?

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.

What about the Cookie criterion?

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 only.

What happens to the live campaigns that use this mode?

The live campaigns that use the ‘previous’ method will keep working as usual. We have deprecated this feature but we are not removing it from our tool. However, this option won’t be available for new campaigns (including duplicated ones).

For performance purposes, we strongly recommend that you manually update your live campaigns using the ‘at regular intervals’ option and apply this option directly within the criteria that require it. You can find the list of campaigns that use this option in the Performance Center.

We can’t guarantee that, at some point, we won’t completely remove this feature, even for live campaigns, to speed up the overall performance of our tag. However, you will be warned long before and we are not planning on removing it anytime soon.