Instead of a total limit of 100 characters applying to a list prop, it
would be ideal if the limit was per each part of the delimited string.
This is already how list vars function. So, the idea here is to mirror
that treatment with list props. This would allow sites to pass larger
strings so that they do not have to rely upon SAINT to classify smaller
values that woudl have to be placed into a list prop.
I've ran into this problem with "full" attribution this week. We're
going to have to explicitally set the list var on all page views and
link clicks and expire on the page view to make use of the variable.
Woudl be nice if it would just be last touch and override the previous
value.
This is badly needed. A common reason for people considering GA is
because of the complexity of SiteCatalyst. And to recently find out that
I couldn't copy over reports designed to make things more intuitive for
users was very disappointing. I now have to go and do the same thing for
a client across 4 report suites, essentially quadrupling my workload.
This basically renders this feature useless for large organizations that
have multiple report suites.
SAINT processing status woudl also be nice. In fact, I might imagine
that a "data processed up to" solution might be challenging and
misleading when there are SAINT calssificaitons and data sources in use.
I have many clients that want linear, first, and/or last touch
allocation in addition to different expiration periods for marketing
channel analysis. The rule-based Marketing Channel Reports are
fantastic, but offer only first and last touch allocation. And, there is
only one selectable expiration period. I would like to see this tool
modified in such a way that all you have to do is create the processing
rules in the admin console and nothing else. At that point, I would like
to see two dropdow...
Many sites have friendly URLs that allow for the use of the getPageName
plug-in. It would be great if there was a configurable portion of the
admin console that would translate the configuration options of that
plug-in into a nice UI where a SiteCatalyst admin could setup page and
content naming rules without having to implement a JavaScript plug-in.
I'd also like to see this tool have the ability to override specific
rules so that specific page names could be set. Some of this could be
done wit...
There are many simple plug-ins for SiteCatalyst such as time parting and
previous page name that simply place values into variables. With the
advent of processing rules, it would be great if all of the
functionality of these plug-ins could be transitioned into the
processing rules so that coding is not required in order to implement.
At this time, the Genesis integrations will send data to the s.campaign
variable and also automate the creation of classifications within the
standard campaign report (or other eVar). The tracking codes generated
by Genesis integrations such as DART or Email can at this time be pulled
into Adobe's new Channel Report that was released in SiteCatalyst 14.8.
However, the auto-generated classifications cannot be pulled into the
Channel Report (aside from doing so manually). The idea here is for
Adob...
When launching a new site to be tagged with SiteCatalyst, there can
often be significant work in setting up automated Data Warehouse
requests. The problem is that once a series of automated Data Warehouse
requests are built and tested within a development/qa report suite, they
have to be recreated all over again for the production report suite.
There is another idea here in the Idea Exchange for allowing us to edit
DW requests, but I wanted to voice the need for the ability to copy the
request t...
For many analyses in Discover I find that it is useful to copy a report
to another workspace. But what if there are 10 reports that we want to
copy to another workspace so that we can drop a different segment/filter
over those same reports? This is why the ability to copy an entire
workspace (as opposed to just a single report) would be a good feature
to add that would assist in workflow when using Discover.
At this time there are list props, but nothing along that line for an
eVar. So, I have seen many clients end up using the s.product variable
for a lot more than just product reporting and measurement. It would be
valuable if there were additional variables that functioned the same as
s.products so that this other data did not have to be co mingled with
the data of the standard s.products variable.
There's a plugin, getTimeToComplete, that will actually do this. You
just config the plug-in to track the time between two specific custom
events. If you wanted it for each visit you could just fire an event
upon the initiaion of a new visit and then fire the second event on
whatever your conversion event is.
