At a lower level than formal load rules, it should be possible to build conditions, generally simple combinations of a variable and a value, and give them friendly names for re-use.
This would then allow less tech-savvy users to build load rules out of a set of pre-configured re-usable building blocks, as well as enable quick re-use of conditions across multiple extensions etc.
So within my own organisation, I might have a condition "Lloyds Brand", which could be defined as:
b.Brand == "Lloyds" || (b.Brand === undefined && b.url.indexOf("lloyds") >= 0)
Then any extensions that need to be scoped to that brand alone can just re-use that condition, which in the backend would be stored as a reference to the condition rather than as the code itself, meaning a single change to the definition of that condition would be reflected in any load rules or extension conditions that referenced it.
For Load Rules, this could then be a way of getting to a cleaner implementation of and/or conditions. The fact that the default behaviour of multiple load rules is an AND operation means that if I wanted to scope a tag to five out of my twenty brands, I have to have an explicit load rule that articulates those, I can't just have five brand load rules and OR them together. But re-usable conditions that can be evaluated to booleans and then glued together using any number of logic operations would make it easier to build simple load rules, but also possible to build complex load rules using logic gates etc. if you wanted..
This would also make it easier to build a true GUI for load rules, with users dragging in pre-configured components and building decision trees. Extra points if you can build a decision tree that describes multiple load rules - each terminating point in the tree could be described as an individual load rule, so in its most simple case, an "This is a Test Site" condition in a one-step decision tree could output a "Test Site" load rule, and a "Live Site" load rule. Then you could nest further conditions under the Live Site to create further divisions within that, giving you say "Test Site", "Live Site", "Live Site Authenticated" and "Live Site Unauthenticated" as load rules that are all described by a single decision tree.
In principle, it's not unlike the concept of building segments/filters in analytics tools.. extra points if you can use conditions within conditions, so creating compound conditions, but obviously the pain of handling infinite loops may not be to your taste..
It would be great if the Load Rules UID is also displayed in the TAG tab section just how the TAG's UID is displayed in the Load Rules tab section. Also if you can add a link to go to the load rules directly from the TAG tab just like how it has been enabled in the Load Rules section.
In my Tealium setup I have some rules that will only trigger after a session end (so 30 minutes after visit end) or after for example 15 days. These are difficult to check using trace as you have to wait this amount of time in real-time.
Could an option be added to fast forward trace time with x hours/days, to make these checks easier?
I need to be able to test campaigns/initiatives. When the visitor is qualified for more than one thing in the same medium/placement, I would want to test them up against each other to figure out which one performs the best. In my setup, the campaigns can occur in any combination.
The only ways I could figure out to get AudienceStream to select one at random were clunky at best. It gets complicated because any one visitor can be qualified for 0-10-ish campaigns in any combination. I could build a random selection logic around a fixed number of campaigns that are always the same. Making it dynamic makes it a lot more complicated.
If I could just add all the campaigns to a set of strings or a tally, and then enrich a string with a random value of that set of strings, then that would do the trick. Alternatively, if I could select a specific item of a tally/set of strings, then I could do so with a random number as the selector. That would be the second best sollution.
If you happen to know of a way to achieve this through the existing features then please drop a comment.
New data enrichment for the number attribute which will set the number to the specific (dynamic key) value in the Tally.
|Tally Key||Tally Value|
"Tally Clothes (favourite)" = "Pants"
Set number "x" to the tally value with a dynamic key of "Tally Clothes (favourite)".
x = 10
This will be useful for lead scoring and many other use cases.
Under each connector, you can view the last 10 errors.
It would be great if you could get this as a CSV output like you can for EventStore and AudienceStore in the Data Access section with time periods.
It's important for us to track this in case key suppression data isn't being sent to Vendors in time due to a failed call.
The current implementation of visitor stitching relies on setting a unique identifier on an attribute for a visitor that never changes. So this is a 1 to 1 relation of a visitor with a unique identifier.
Sometimes a visitor has multiple different values for the same identifier. This would be a 1 to n relation of a visitor with a specific type of identifiers (phone numbers, email addresses, order ids, basket ids, session ids).
1. Multiple baskets filled without being a customer yet and the sale is completed through a channel that can't know another unique identifier for that basket, other than the basket ID (such as an abandoned email, sms, social, etc.)
2. Multiple email addresses for the same person.
3. Deduplication of customer IDs within a CRM.
The promise of the timeline attribute is a very powerful. Store a set of attributes on a specific moment. For example; store all the baskets, orders, purchased etc for a visitor. However when applying rules to timelines you find out that there's actually only one thing you can do; check if it assigned or not. Then when you do want to use it in a connector (eg. a webhook with trimou templates) you find out that all the attributes you've stored in an entry are only retrievable through their IDs, instead of their names.
To unlock the timeline attribute fully I think the following would be benificial:
- Check if timeline has entry between dates or on specific timeline.
- Get (first,latest,all) timeline entries that have an attribute that matches a rule from the types that are applicable to that attribute type.
- Remove timeline entries that have an attribute that matches a rule from the types that are applicable to that attribute type.
- Check if timeline has entry that have an attribute that matches a rule from the types that are applicable to that attribute type.
- Use the names of an entry's attribute not the IDs
- Be able to interleave the data from an entry's attributes into hierarchical JSON data, like you can with regular attributes.
Quite often we need to change tag templates to be able to run them with utag.link() function.
Except that we don't really touch tag templates. It would be great to be able to add support for utag.link:
directly from configuration menu (see attachment)
On an array of numbers the following rules are allowed: is assigned and is not assigned. I would like to see the addition of the following rules: contains number less than, contains number less than or equal to, contains number greater than, contains number greater than or equal to, contains number equal to.
For a set of ages check if there is an age between 0 and 18 (child), for this use case we currently have to create a rule with 19 separate OR statements. (let alone the different types adults 18-30, 41-50 etc.)
When using specific calculations or similar rules there might be generic values that change every season. Whenever that change happens you manually need to find all the entries for that value and update it. This is error prone and tedious. If it was possible to create profile or account level attributes, you'd then be able to reference those thoughout the implementation and change them from a single point.
Idea Description : A checkbox at the top of the page in TAGs, LoadRules, Extensions to automatically select/deselect all checkboxes
Reason: In our WFC profile we have 1000s of extensions that we have to toggle on/off for testing purposes. so it would be nice to have this checkbox at the top of the table to select/deselect all the extensions.
Idea Description : It would be nice to have an option in the LoadRules and Extensions section to allow users to add loadrules or extensions with OR conditions within AND condition which would generate code such as below:
if(app_id === 'test' && (product_code==='AA' || product_code==='BB' ))
Currently this is not an option and we end up configuring conditions like below:
if((app_id === 'test' && product_code==='AA') || (app_id === 'test' && product_code==='BB' ))
I would like to propose a more comprehensive list of variables treated as device variables and available for use in rules and mappings
There are quite a few variables I use that have the same name for querystring, path, dom, etc. When trying to create loadrules in AS, the dropdown or icon does not indicate what type of variable it is unless I have the rule and physically click on the variable to go to the variable properties. This is time consuming and can cause rules to not function properly.
A simple option to duplicate an extension to another profile(s).
This is not possible today - and that is a strange limitation.
To prevent failures, the extension can just be disabled by default when duplicated to other profiles.
Today the actual UI for mapping datalayer to tag in TiQ seems as one of the weakest features. It's in a small modal, with no sorting options etc.
Optimal this was in a tab, with the option to show multiple tags at the same time, sort on columns, batch edit etc. This would provide a much better overview than today.
(Quick mock based on exsisting UI)
It can also be included in the Data Layer tab, where it already shown if a parameter is mapped to a tag, but it does not show the details.
- User 1 logs in to AS, starts making changes on V1
- User 2 logs in 10 minutes later, starts making changes on V1
- User 1 publishes its changes with all its hard work, V2
- User 2 publishes changes, but these are changes on V1, so when user 2 publishes V3, it will overwrite everything from V2 from user 1
A simple merging system would be nice, and that only starts complaining when 2 versions have conflicting changes.
Currently we workaround this by having a chatgroup in which somebody says they are going in and out of AS, so you know when you can and can't use it, bit medieval...