List Vars (s.list1, s.list2 and s.list3) are common enough variables
(moreso than Hierarchy, I suspect) but right now we have to move to
custom code to set them. I understand it gets trickier because of the
list-y nature of them, but in most cases my Data Element is making the
properly-delimited list I want, and I just need a way to reference it in
my rules. Also, it's odd to have Transaction ID in the interface, but
not purchaseID- they're very similar, and it would be nice to be able to
set th...
This is another small thing but it keeps messing me up. If I type
"eVar3" it shows me a dropdown of all eVars that match, which is
nice:The problem is, at that point, if I say to my self "nah, eVar3 is
what I need" and just hit tab or enter to leave the field, it won't
stick- the field goes back to "select eVar", because I didn't select
something from the dropdown. This is true of pretty much all the fields
(props, events, etc).
I have a hard time believing there isn't already an idea post for this,
but I did look. It would be wonderful if the Adobe Analytics extension
could use the API to pull down variable/event names- something like
this:This would help so much with making sure data element are aligning
with the correct variables (and that variables are enabled, etc).
In a way, this is similar to Automatically Update Names of Data Elements
Used in DTM Rules , but I think they difference is, instead of (or in
addition to) making it so if I change the name of a Data Element, it
automatically updates anything referencing that data element, you're
saying you want to also see "where is this data element referenced"? If
so, count me in!
This is a little thing that would make a surprisingly big difference for
me. Right now, in Launch I can only view 10 Rules or Data Elements at a
time, with a "Next>" button to get to rules 11-20. There isn't a way to
really now how many rules I have overall, which is also a very minor
complaint.Ideally, I could define how many elements to see- 10, 20, 50,
view all... An eternal scroll feature would be nice too. The real use
case is this: I may not remember exactly the name of the rule I'm
lookin...
I think you may still be missing the idea I'm proposing here. The
appMeasurement library automatically sets the URL into the "g"
parameter. The problem is, the logic that does this may be outdated as
it doesn't work well in SPAs, where a single DOM may change states/URLs
multiple times. In these cases, appMeasurement doesn't realize the URL
has changed and continues setting the "g" parameter with the original
URL. A developer who is aware of this problem can get around it easily
enough by manual...
This applies even when using DCRs. I know how to update pageName and
custom variables and all of that on a new page view- and I do know how
to manually override the URL to have the new beacon reflect the new url,
using s.pageURL. What I'm asking for in this idea is for the url to
update automatically.For instance, currently, when my SPA loads, my
first beacon might have:g = http://www.mydomain.com/home.htmlpageName =
homeevents= event1prop1= D=gThen the user browses to a new page
(http://www.myd...
Currently, on a single page app, my first beacon will have the correct
URL. But if I navigate to another page, and there is a history/state/URL
change without loading a new DOM, my URL does NOT update- my "g"
parameter in my beacon still reflects the first page loaded. These days,
most single page apps DO update the URL as the user navigates around; it
would be good to have that URL reflected in analytics. I often manually
force this by doing something like "s.pageURL=document.location.href" in
...
I'v managed to get adobePrivacy.js working outside of DTM/Launch, just
using straight-up javascript, but I haven't worked out how to do it
using the Launch Privacy extension. Specifically, I'm not sure what I
need to do with Data Elements to Retrieve/Remove Identities. The
interface is less-than-clear:And the only documentation I could find on
it was even less
helpful:https://docs.adobelaunch.com/extension-reference/adobe-privacy-extension
I've done more advanced, code-based things in DTM/Launch...
This is a small thing, but for folks spending a lot of time in Launch,
would be really helpful. When I'm editing the configuration of something
within a rule (action, condition, etc), it would be great if that screen
included visibility into the name of the rule I'm currently working on.
Right now, if I'm setting up a lot of rules all in a row, it's easy to
get confused about which one I'm currently looking at. Nothing in the
action configuration screen indicates which rule is potentially being
...
I've had very similar problems, even with rolling date ranges. I
detailed some example problems at Workspace "Compare" columns with more
flexibility ...
This is something folks have been asking for/fighting for for years (see
also Analysis Workspace:We need analytics on Analytics! and Track usage
of Adobe Analytics among users ). And I've heard from Adobe they see the
reason folks are asking, but it's never been high enough on the priority
lists. But now that folks are in workspace more and more, the old
usage/access logs (which were already barely useable) now really just
don't cut it, but we still try to use them to figure out how we need to
...
Another limitation with "Compare Time Periods": if I do "Compare Time
Periods>This week last year to this time range":It nicely goes back in
time to the right week:But if I update the date range on the panel, the
comparison does not update:...Making it very hard to create a dynamic,
update-able report.
Kind of? The current "analytics on analytics" (if you're referring to
the usage logs) only includes Reports and Analytics- not Ad Hoc, not
Workspace, not API/DW requests. It also takes a bit of tweaking to get
into a useable format, if you want to see how many folks viewed the
campaign report, for instance. And unless something has changed, the
login part of the usage logs doesn't work well with marketing cloud
logins, only my.omniture.com logins.
To show some examples:Currently, if I right click on a column (in
certain circumstances), I get a "Compare Time Periods" report. I have a
few clients that use this feature A LOT. When you do, you end with
something like this, where a column appears to the left with a date
range over it (which I can re-create in other ways), and a column to the
right with a percent change between the two (which is what I WANT to be
able to create in other ways):There are a few critical limitations with
this featu...
I currently love and use the "Compare Time Periods" option frequently,
but it only works in certain situations (for instance, it isn't an
option if I have "days" as a dimension in the report), and I can't drag
in Time Periods I've already created. I frequently want that sort of
"compare" functionality on all sorts of different columns.What I would
love is to always be able to create a column that compares two other
columns in the table. Summary change is nice but not if you have a lot
of items i...
Yep, I know Segments and Virtual Report Suites are a workaround for
this. But those have a few potential problems too: You have to have been
capturing IP into a custom variable. Unless folks have been doing that
already in their RS, it has the same retroactivity problem- it would
only work for data going forward. Moving an already established org from
the main report suite to a VRS can be really hard, especially if they
already have a lot of workspace/ad-hoc reports set up and such. I think
I've...
In most cases, folks create new Bot Rules specifically because they've
uncovered a bot that has been messing with their data... unfortunately,
by the time you've identified the problem and created the rule, it's too
late: the bot has already done damage.The workarounds are pretty
drastic- applying a segment to every report, or moving entirely into a
Virtual Report Suite that doesn't include the bot traffic
retroactively.Bot rules working on historical data would be a huge help.
It would be awesome if, when I have multiple metrics/columns in a
freeform table, I could add some sort of visual divider between columns.
It would serve no purpose other than to make it easier to view. So
this:Could become this:
Good idea, and I love your example! Though in Workspace, allocation can
also be based on your metrics (for instance, an eVar with Linear doesn't
show as linear in workspace unless you have a metric you've set to be
linear- see Followup Post: Allocation in Analysis Workspace | Digital
Data Tactics
