@VaniBhemarasetty, we followed this implementation and now our native
code is appending the ECID and our Adobe Org ID in the webview URL. We
can't observe the URL directly, but we can see it in development
reporting. I did have one quick question. I tried to test this by
appending the query string that I got from our development reporting to
one of our webpages and I wasn't seeing the resulting s.t() or s.tl()
call replacing the ECID with the one from the URL. Is this a viable way
of testing thi...
@Sebastiane_Edberg_, so what happened to your implementations? Did the
Old DTM codes overwrite your new Launch embed codes or were the Launch
embed codes correct but you were still getting served your DTM
production libraries? I chose not to link our production Launch code to
our production DTM code too so I am interested in hearing more about
this. Have you tried disabling your old DTM property now that you have
migrated over to Launch? This might solve your issue by disallowing the
We have used the DTM to Launch property migration button to get several
of our properties migrated over from DTM to Launch. Upon closer
examination of the Launch property today, it looks like rules that were
inactive in DTM were not copied over to the newly created Launch
property. Has this happened to anyone else, or is this something that is
unique to our company?
@Haran_Huang, the vast majority of our event based rules have values
that are hardcoded like the example above and do not use data elements.
Also, even when you are using data elements in this field, it still gets
truncated with a (...) when your data element is longer than 27
characters. Since we have quite a few data elements whose names are
longer than this, these would get partially obscured in the value field
It would be great if we could make the input field for the Evar/Prop
string wider so you could see more characters. This would save time as
it would reduce the number of times a user would have to spend moving
the cursor further to the right and help make it easier to spot typos
that are off screen when a user opens up the Set Variables component of
a particular rule.
Currently, you can build/advance a library from the publishing tab as
there is a dropdown menu with three horizontal dots that allows you to
do this without opening up that specific library. However, you still
need to open the library up in order to remove or add an environment
when the library is in the development column. It would be nice if you
could remove and add environments from development libraries in a
similar way without having to individually open each library to remove
or add enviro...
@courtneya707225, you should be able to use the same host for multiple
environments. I have three embed codes for most of my Launch properties
and I use a single host that I set up for all three of those
environments. One host can work for multiple properties as Launch
doesn't force you into having a 1:1 relationship between host and
properties. You can have one host for five different environments or you
can use different hosts for each of your environments.
It would be great if the rule search feature in launch was case
sensitive. Currently, we use abbreviations like "CC" in the rule names
that have custom code in them. When you search that in Launch you get
both that acronym and rules that contains words with "cc" in them.
Example Rule Name: "Medicare Plans - Patient Plans Accordion" would come
up if you inputted "CC" in the search box.
Yes, I am not sure if this was where you were going but it would be
great if the name field could default to some combination of the
Identifier Used + Identifier Type when you add something in that field.
Here are some examples of what I was thinking below. Currently, I am
doing this manually by editing the name field for each rule but it would
be awesome if it was done automatically.
Currently only the libraries in the published column display the date
they were published. It would be very helpful if libraries that have
been built to development or staging displayed the date they were last
built in the same manner. This would save a lot of time since you
wouldn't have to go open up each library in order to see what date it
was built last. In some of my Launch properties I have 10-12 libraries
waiting in the development queue for code fixes from our developers. If
this was im...