currently for connectors i can :
a) use a simple connector Action, and send ALL data to the connector. or,
b) use advanced Action, and be very specific and create my payload structure through a template
I need to combine the above, I need to :
a) send ALL attributes (I dont want to spend days mapping each one individually). AND
b) I need to add custom attributes to the payload.
use case: in Audience Stream, I want to send full payload to my connector. I also want to send the Source ("which Audience caused this payload"), and 'WHEN' ("this payload was triggered by a joined_audience action").
the above two could be added in a smart way, but if we can add custom attribute mappings to the connector action (when sending ALL data), then we could also just hardcode these two values as attributes into my payload.
(the same should also then be added to eventstream, so we can pass the filtered-stream-name as an attribute, when sending All attributes in a payload to connector)
We noticed that the ID's created by the Google cookie matching service tag are device ID's. So one user can have multiple ID's, instead of one. Because of that, we can't use these ID's for cross-device stitching and cross-device retargeting for our Google ads.
To tackle this issue we would like to be able to send multiple Google ID's to Google via Audience Stream. In Audience Stream we're able to capture all known Google ID's and create an array of these ID's. If we could send this array to Google our problem would be solved, and we could create cross-device audiences.
Hello! A simple idea I have is to have labels sorted alphabetically. We have probably over 300 extensions and it is a real pain whenever we have to tag a new extension with the correct label.
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..
When mapping attributes in the connectors you can not see the full names in the connector mapping. It cuts off rather than make the text size shortened or wrapped. See below image example, in this picture the UDH attributes are different names but you can not see them. The font size here should be smaller to fit or wrapped so I can see at a glance what the attribute name is.
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)
I have often seen the need to identify wether an object has been seen over a period of time or how often that has happened. E.g. which article_ids have been encountered over the last 7 days, what has been the most popular category_id for a user over the last month, etc.
I believe this could be easily achieved by storing Strings (article_id, category, ..) in a Timeline.
I would suggest the following Enrichments (in decreasing order of importance for me):
I have a complex construction for this including counting these values in a tally with session scope, storing the tally in a timeline at end of session and have a summary tally that is initialized from the timeline tallies and incremented by the session tally. At every event. That works - but I find it to be very cumbersome for a relatively frequent pattern.
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.
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.
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.
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.
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.
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.
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.
According to this page an account manager is the only person who can reset a user's MFA code. If you have a new device you have to bother the account manager to be able to change your account's MFA code. Also, if you are an account manager yourself you can not change your own account so it's impossible to change without a support request? Also what happens if you are attached to multiple accounts? All the account managers from all accounts can reset my MFA token?
I'm not understanding the purpose of why only the account manager can reset this. There doesn't seem to me to be any sort of security advantage of doing this or documentation that explains why?
- 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...
The title says it. The text editor is more or less useless.
13 lines of code visible, no resizing of the editor window
Some sort of distraction free text editor that spans most of the visual area would be great.
We have multiple launches occuring each week - some in the development phase, some in testing/QA and some ready to be migrated to production. And its a long process each week to identify a list of items to migrate from Dev to QA, and QA to Prod. This process includes identifying specific data layer items, extensions, tags, tempates, etc.
Would like to propose a concept of a bundle for launch management. A bundle could consist of a tag, tag template, data layer element, data layer element added to a tag and/or an extension(s) that are specific to a particular project. So, ideally changes can be associated/applied to a bundle within the dev environment. When ready for launch, the bundle can be migrated to other environments, as needed vs. individual items that are required for the launch/migration.
Please vote if you like the enhancement.