One more vote to get this dynamic report date off the backlog list and
into reality. Would save us SO MUCH TIME in building custom timeframes.
This is preventing us from being able to turn a lot of dashboards over
to our project managers.
This is doable inside of workspace right now. Go up to "components" >>
"date ranges" and create a date range where the start day is fixed, and
the end day is rolling. Then use this as the time segment for your "pre"
It would also be very helpful if the timeframes are more customizable
than just day, week, month. We have products that have an average usage
cycle of two or three weeks, and it would be very helpful to be able to
display retention calculated based on those timeframes as well.
We NEED the ability to drag and drop events or dimension values into a
visualization, and have workspace generate a visitor retention graph
based on those different dimension values, with the visitor's first
instance of that dimension counting as day 0 or the "inclusion
metric".This would be especially helpful for evaluating tests, where
visitor's are served different experiences, and we want to see which
experience results in more visitors returning to the site in the n-th
jr-seattle-campfire, when you drag a dimension in to create a quick
segment, it does so at the hit level, from what you're explaining, I
would bet that the segment you're creating is either at the visit level
or visitor level. This would explain why your numbers are different, as
these containers will pull drastically different numbers.
Multiple full IPs would bevar res =
you just want to match "starts with" you can drop the "$" at the endvar
res = /^(192.236)|^(192.237)|^(192.238)$/.test(strIp);
Hmm... So we have a web based report suite (uses VisitorID but no
timestamps), and an app based report suite (uses VisitorID and
timestamps).If using s.visitorID does not change the timestamp used to
generate ordering, then if we combine these report suites into a
timestamp optional report suite, wouldn't the web data rely on
hit_time_gmt, and the app data would rely on cust_hit_time_gmt? That's
what we want, but Adobe's documentation says the timestamped hits might
come in out of order.
I'd love an answer on this one too.Does using s.visitorID on timestamped
report suites force the processing to rely on hit_time_gmt rather than
cust_hit_time_gmt? Depending on the answer, it may be worth it to have
slightly out of order data, if it means we're able to see usage across
multiple platforms by the same users.
If you capture customer account number in an eVar, and then the same
customer account number visits your site on 3 separate devices, a
segment that looks for visitors with that specific customer account
number would capture all 3 of my visits & unique visitors on the site.
You won't be able to combine these 3 different devices into the same
unique visitor, but as long as the customer logged in on all 3 devices,
you'll be able to see them with a "visitor" level segment.