As an update, I put a breakpoint inside the core launch code
(customEvent.js section), and the listener does get executed and the
evaluateListener function is called, but my rule is never executed.
Has anyone been able to get this to work? I have code that is firing an
event and a rule set up with a CustomEvent trigger listening to it. I
have tired all sorts of different combinations with no luck. I wrote a
listener by hand and it is getting invoked, so I know the event is being
fired.I could never get this to work the way I thought it should in DTM,
either, so maybe Adobe and I have different ideas on how to handle
events...Anyone have an example or some tips?
Quick update. I wrote an extension that has an action that will create a
window-level object that has the various utility functions. Seems to
work OK (VERY limited testing) - I was able to execute commands from the
console. The only downside is you have to run the action in, say, a page
load rule to make them available. Is there a place to put code in an
extension that runs regardless of whether or not an action is called?
I know Extensions have shared modules where they can be shared with
other extension code. Can the same structure be used in a piece of
custom javascript code deployed as an Action?We have been developing a
set of utilities (similar to what we did in DTM) that we are calling
"Useful Things Adobe Should Have Cooked Into Launch" (granted, it needs
a less unwieldy name!). We can load in in custom JS and make the
functions available at the window level, but if we could cook it all
into an Extension i...
Oh - much pain, my friend. The format of the products string is an
absolute nightmare.Worst case, they could make it possible to set the
value in the action configuration and then we could do the heavy lifting
from a data element definition. A "format product string" action would
be better, but making that general purpose and configurable might pose a
challenge.
We LOVE the idea of libraries. The ability to create one, add related
rules to it and then promote them as a group is a big plus for Launch.I
envision creating libraries named after the JIRA story that requests the
work. Again, a huge step in being able to track requirements through
implementation.It would be great if there was a comment field available
at the library level similar to what we have for rules. That way, more
detailed information about what is in the library can be added.
Something...
One of the challenges we face in DTM is knowing when a tag is no longer
firing. This can mean that it is now safe to remove the rule or that
there is a problem because the tag really should be firing. We have to
visit the impacted pages and see if all of our tags are firing. This is
is particularly troublesome in places like our order confirmation page,
where you actually have to make a purchase to get there.It would be a
huge help - especially in our media tag deployments - if Launch would
prov...
A couple of us are working on developing rules changes in different DTM
properties, and both are seeing the build date get updated when we
reload our pages, but not all rule changes are being included. We use
Akamai for our DTM files.I have had this happen with both Direct Call
and Page Load rules. Sometimes I can make a minor edit and get the build
to pick it up, but that does not always work.We are at a standstill.
We wrote a Chrome plugin to do better syntax and code checking in DTM. I
was hoping to retire it with launch, but the current editor needs a lot
of improvement, most notably Sarah's request to do syntax checking at
the very least.Also, those of us who have obtained a certain level of
maturity would REALLY appreciate the ability to make the font less tiny.
For those of us who manage a lot of different properties (which means
development inevitably includes the wrong embed code from time to time),
having a built in variable or function to return the property name would
be a huge help and, I would think, very easy to implement. Trying to
match embed codes against multiple property definitions is a
nightmare.In our DTM implementation, I created data elements in each
property called "dtmPropertyName" and could always do a getVar() on it
to figure out ...
A little of both. I put the browser, os and device type info into my
data layer. I use that to decorate some of our API performance logging.
I also use it in a couple of DTM rules. It is a handy way to get some
basic info without having to parse the userAgent string myself. It won't
be killer if it is not available in Launch, but it sure is
convenient.And speaking of the new cookie() function - where is the
documentation on that? I looked, but no luck.
Will the _satellite.browserInfo object be available in Launch? Our
current implementation utilizes this information in many places, giving
us a common definition for browser, OS, device, etc.
I've searched around with no luck, so I am asking here...I am pretty
well-versed in the s_code and AppMeasurement,js ways of doing things,
but am still new-ish to mobile apps.When a user clicks a link inside our
app that takes them to a mobile web page, I would like to record that
like a lnk_e would on the web. Is there a way to set the app equivalent
of linkType in the trackAction() or trackState() calls?Thanks -Jim
We have been using the MC Visitor ID Service for some time now. When we
first hooked it up, the advice given regarding setting customer ids was
not to bother because they weren't used for anything at that time. I
found this same information on some blogs written by Adobe folks and in
talking with our internal Adobe contacts.Is this still the case? It
seems that if I associated, say, my customer'd account number with the
the call that the service could use that to associate that same user
across ...
