Skip to main content

Ideas

Filter by idea status

10000+ Ideas

BYOIDLevel 3

Flexible conversion attribution period to evaluate A4T activities in Adobe AnalyticsNew

Hi,This idea is related to a question I posted : Incorrect attribution of conversions to Target activities in Analytics(?)It would be great to be able to choose the attribution period. Currently there is no expiration, which means that conversions are attributed to a past activity even long after this activity was live. So, doing your Target activity evaluation one week after your test or one month after your test or 2 months after your test might result in ending up with a wrong conclusion related to that test (because of being impacted by many other external factors, campaigns & tests).Some people might now think "but you can do this in the Segment builder by creating a segment on visit level and selecting Activity (Analytics for Target) exists THEN conversion exists" (cfr next screenshot). But no.. the result will still be that conversions are attributed to activities that were active even long ago. Reason: the IF condition 'Activity (Analytics for Target) exists' does not expire. It does not refer to the actual (one and only) impression.Ideally we would be able to select the actual impressions only and then select/define the evaluation period that is required for a certain test. This can be next hit, same visit, within a week,... since the type of conversion (a click or a sale) probably defines the length of this evaluation period.Kind regards,Sarah

jdonleyLevel 8

Better Processing Rules ManagementNew

Please please PLEASE provide a better interface for managing existing processing rules.   Our options are 1) wholesale wipe and overwrite everything to target rsids2) append individual PRs to target rsids But there is no "overview" to see which PRs are currently where.  So let's say I have 100 rsids, and they are grouped up in different groups.  And I have some "global" PRs common to all of them.  So I add a PR and append to all.  What happens when I need to update later?  My choices are: a) Append a NEW PR that overwrites the previous one.  This is not good, because we're supposed to write PRs to passively pop stuff as a best practice (e.g. "if not set, then set")  b) Go through every rsid individually and update/delete the PR Neither one of these options are good.   Also, currently PRs are not exposed with Rest/Soap APIs so I can't just make my own interface  Ideally I want a PR management interface where it gives an overview of all of the processing rules across all report suites, and which report suites they are associated with, and a button next to each report suite listed for the PR that I can click to remove association with it.  Also a field where I can add one or more.  Or maybe alternatively, each PR would show all of them in a multi-select box (like you have on the current copy interface) that I can simply (de)select which one(s) I want the PR to be active for.   In other words, the overall principle is to only have a single list of PRs and you choose which rsid(s) to associate it with.    That by itself would go a LONG way towards making PR management, well, manageable.   Please?