When creating an audience to target experiences based on an mbox
parameter value, there is very limited functionality for how the mbox
parameter can be evaluated.It is only possible to directly compare an
mbox parameter with a static value, which limits the ability to easily
do personalisation on a segment-of-one basis. Meanwhile, it is possible
to compare profile scripts and other attributes directly to attributes.
See the below screenshot as an illustration of the two differences.Our
need is t...
Our Launch Properties are used across multiple domains. In the AAM UUID
Cookie configuration in the AA extension we need to be able to set the
UUID Cookie Domain to be variable depending on the hostname of the page
which is being viewed. Unlike most configuration values in the
extension, this one does not allow the use of a Data Element and so
we're not able to achieve this.
Yep you inspired me.Unfortunately this has gone from nice-to-have to
must-have for us.We tried to do a manual deployment and it killed our
CMS because the path was too long.So, we are forced to manually edit the
files generated by launch and modify all the paths in order to reduce
the path to something which can be deployed on our platform.
The archives created for manual deployments contain redundant folders
(redundant in a self-hosting environment where you already know where
you want to host the file and usually have a specific folder for it),
and creates chaos for people using deployment tools or a CMS for
publishing (regardless of which CMS it is). Our ops team are going to
very quickly hate me because of the large amount of work this is
creating for them every time we do a release.We need the ability to set
an option so that ...
When we download an archive to do a manual deployment, the pair of files
in the root directory are also duplicated in two sub-folders, the PR
subfolder and the BL subfolder.Why is this the case?
Does your rule with the order of 20 (which is firing late) have a custom
code action? I am seeing that custom code actions appear to execute
somewhat asynchronously and cause rules to fire out of order, I'm
wondering if you are seeing the same thing.
We're able to access certain event properties via the data element macro
- such as the %event.detail.[abc]% object - but we can't seem to use
this same approach for other components of the event object - such as
event.target and event.elementIs there a particular reason for this, and
is there anything which shows exactly what is and isn't available
through the data element macro?
I've achieved this by stacking rules, and pushing all analytics track
events down through a single direct call which has a number of different
rules listening, in a specific order. Some rules are conditional, some
aren't - so this way, I can control certain variables that apply to
everything, and certain variables that are conditional. The last rule
fires the beacon. Maybe not ideal, but it works well for us.This also
allows us to reference analytics variables in a specific order: for
example, w...
It's impossible for us to keep on top of CMS changes, and when using the
VEC this can have wildly unexpected results when a change occurs to the
page and the content authors can't test the page against all experiences
being applied to the page.In the activity list/browser, we should have
an easy way of identifying all active activities where the VEC is in use
and there has been a change to the page/selectors and re-validation or
adjustment is required. Alerts would also be highly useful.
