Temporal Conditions

Temporal conditions

Along with just managing the tags in a single place, TDI allows specifying various conditions, randing from simplest to most complex affecting the tags activation. Here we'd show how to specify the temporal conditions, e.g. those related to timing.

Activity periods and overriding

The containers, tags and rules all have an input field labeled "Activity periods and schedules". By default the object won't have any activity period nor schedule - this means the object would stay active all the time assuming all other constraints are met (like switching "Enabled" on). By clicking the "Add period/schedule" button it's possible to specify one or more date/time ranges when the object should stay active. Each range may have a starting date/time, the ending or the both. When no values are entered, the object is about to be active all the time; when there's a starting value but no ending, the object would only activate after the starting timestamp; if only the ending one is specified, the object would deactivate after the ending timestamp; obviously, if both are specified, the object would be active only in the specific time frame. If several periods are specified the object would be activated if the current date/time matches at least one period.


The activity period works in conjunction with other conditions within the object, like logical "AND", e.g. the object would be come active only if the current timestamp falls into one of the activity periods AND other conditions are met. This particularly affects how the activity period of some container, a tag in that container and rule specified in that tag work together. Imagine we have several nested object, each with one activity period added:

  • a container with the period of Jul 1 to Jul 30 of 2014
  • a tag in that container with the period of Jun 15 to Jul 15 of 2014
  • a single rule attached to that tag with the period of Jun 10 to Jul 10 of 2014

This particularly means the following:

  • the tag within the container will only activate if the container activates; thus limiting the activity period to the intersection of the container's and the tag's one, e.g. Jul 1 to Jul 15.
  • but the rule limits it even more, giving the intersection of Jul 1 to Jul 10; so the tag would activate for those 10 days only (assuming all other conditions are true)

Activity schedules

Besides specifying a simple activity period, one may want to define a more complex rule, like "activate the tag every Friday that's the 13th during the winter months only" for that specific period. The activity schedule, appended just below every activity period, makes it possible to define the rules in the form somehow similar to how it's done in the *NIX cron scheduler.

The schedule is applied to the specific period above it, so one may have multiple periods with different schedules. By default the schedule has "any" values for all columns meaning the object would be active any time during the corresponding activity period (assuming other conditions are met). Imagine you need to implement the schedule pattern from the above paragraph. Let's do it step-by-step:

  • Click "Add period/schedule" button to create a new activity period. Optionally fill in the activity period or leave it empty for the schedule to apply to any date/time.
  • The initial schedule be empty by default, like on the screenshot:
All values are "any", so no restriction are applied.
- Now click the "Day of week" column and select Friday only (same way you may select several days of week, like Monday, Wednesday and Thursday), "13" for "Day" and "December, Januray, February" for "Month". The resulting image would like the following:

If you need to specify something like "any time expect hours since 2:00 to 4:00 AM", just use the exclusive range, e.g. "0-1,4-23".


Due to the fact the tags are about to be activated in the user's browser located in the random place on the globe, it important to understand that the time would differ depending on where the user is located. The TDI system allows to specify the timezone to properly convert the activity period/schedule input to the actual time.

By default the website visitor's browser timezone is selected, e.g. the date/time values entered are not abolute and would depend on the user's local timezone. Like "9:10 AM" would be different absolute time for New York and Berlin website visitors, though it would still be "everyone just came to the office" time for both - e.g. the tag would activate at different absolute time for NY and Berlin. Most TDI users would probably stay with this default setting as most intuitive.

Alternatively a predefined timezone from the list may be selected, this effectively makes time calculations absolute, regardless of the website visitor location - the tag would activate at the same absolute time. So "9:10 AM" with the timezone set to "EST" (Eastern Standard Time, NY) would be the same absolute time for all users, but Chicago visitors would have their local "8:10" when the tag would activate, and Berlin would have "15:10". Note however that the timezone isn't a N hours difference constant over the time, like different countries may apply Daylight Saving Time at different dates adding or subtracting a hour from the difference; the TDI however takes care of any such changes, so "9:10 in New York" always "9:10 in New York" regardless of whether it's winter or summer.

Same as with activity periods, timezones are inherited from container to tag and down to rule. Initially the container is set to the user browser timezone, the tag inherits the one from the container, the rule inherits it from the tag it's about to be used it. It may be changed at the tag or rule level not to inherit but rather to specify a predfined timezone.

Have more questions? Submit a request


Please sign in to leave a comment.