How to set-up targeting verifications
Last updated
Was this helpful?
Last updated
Was this helpful?
We are supporting in the . This fully replaces the use of the “wait until” mode in an easy way for developers.
This criterion is using a 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.
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.
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.
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.
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.
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.
Read more .