Product ideas | Community
Skip to main content

Filter by idea status

10000 Ideas

v-tiwri
v-tiwriNew Participant

Workspace: Allow users to share items with their entire team (user groups)New

Current Issue: Right now, users (non-Admins) are limited to being able to share items (projects, segments, calculated metrics) to individual users one at a time. This means that if a user wants to share out an item to their entire team, then have to manually "check the box" for each individual team member at a time. When accounts have 100's of users to select from, this is quite a laggy process and time consuming, and not the most efficient or streamlined method. Only Admins have the ability to share items to user groups, which is not efficient either.Proposed Idea/Solution: All users should the ability to share out items (projects, segments, calculated metrics) to their entire user group (team). Users will be empowered to share items to their teams, which will save them time, and enable team collaboration. This will de-centralize the functionality so that users don't have to ask Admins to share out components to their user group. Please note that users should only be able to share out items to user groups that they are member of, so that they don't spam other team's items.This is somewhat similar to the request here: Allow Non-Admin Users to share Components with configured Groups  However I want to extend it beyond components to also encompass sharing workspace projectsBenefit:This will greatly increase the team collaboration and help enable all users of the Adobe platform with more streamlined collaboration.

MichaelWon
MichaelWonNew Participant

Bounce Rate Does Not Work on Product StringNew

Disclaimer - Please discredit this if I am incorrect, but I do not think I am. The out of the box 'bounce rate' metric, which is calculated as 'bounces / entries' does not work when used with the product string.  the reason is that 'entries' does not work with the product string, but bounces do.   after some discussion with client care I was told the following as it relates to the entries metric.  From Help SectionEntries represents the number of times a given value is captured as the first value in a visit. Entries can occur only once per visit. However, it is not necessarily the first hit if the variable is not defined. From discussions with client carethe product string can contain multiple products.  if the entry server call contains multiple products, only the first product in the string will get credit for the entry.  all other products in the string will not have an entry associated with it. We often drive people to landing pages that contain multiple products on the page, thus we set a product string with multiple products.  So when we aggregate our products we end up with bounce rates way over 100% because bounces end up higher than entries, something that should never be the case. My idea is as follows: 1-Can we make the entries metric work for the product string?  this would change the definition of entries, but i do not think it is clearly definied in any documentation I have found.2- if we cannot do the above, can we create a new entry metric related to the product string alone?  this would allow us to create a new bounce rate metric for products. A couple of workarounds and their issues: A short term work around I came up with to calculate bounce rate for the product variable is to divide bounces by single page vistis.  this will work but it is not perfect for the following reason:  we have instances where an event, containing the product string is the first server call of the visit.  this would cause that product to not have a 'single page visit' associated wtih it. Note - page name does not work so well for me because we have a site that has over 10 million products, so we very quickly run into uniques exceeded issue.  we have the same issue with the produt variable but we have been allowed to increase this limit into the millions. let me know your thoughts

jean-marcb76525
jean-marcb76525New Participant

Modular user rights with Product ProfilesNew

Currently, it is not possible to manage user rights for Adobe Analytics in a truly modular way. I am speaking about Product Profiles in Admin Console. I would like to grant access to Analytics based on two main aspects:User skill level and role: Beginner / Intermediate / AdvancedThis defines the Metrics, Dimension and Tools the user has accessOrganizational: Company divisionThis defines the Report Suite(s) the user has access toI would create different Product Profiles for each entity and combine these. E.g. Product Profile "Beginner" has access to a very limited set of Dimensions and Metrics and only to Reports & Analytics, but not Workspace. Product Profile "Japan" has only access to the Japan Report Suite. A beginner in the OU Japan would get both these Product Profiles assigned.In the Admin console, there are five areas where permissions are defined:Report SuitesMetricsDimensionsReport Suite ToolsAnalytics ToolsReading this, I understand it should be possible to grant access to Report Suites independently:https://helpx.adobe.com/enterprise/using/manage-products-and-profiles.html Quote: "A user could belong to multiple product profiles, each conferring different licenses to the user. A user's final eligibility is the union of all licenses conferred by each Product Profile to that user."Yet, it is not. That's why I am writing this ;-) Adobe Engineering confirmed that permission to Report Suites must always be set in the same Product Profile where permission to Dimensions and Metrics is set.I consider this a lack of functionality, especially for the Enterprise segment Adobe prides itself to cater to. Large companies with various report suites want to restrict access to those while metrics and dimensions would be the same for a specific user group (like the "Beginners").The only workaround I can think of is to create product profiles "Webanalytics Beginner" for each of the countries with identical permissions except for the report suite. What if there are 30 countries and I want to grant access to a new dimension to "Webanalytics Beginners"? You would have to edit 30 (almost identical) profiles. Not efficient.

Andrew_Wathen_
Andrew_Wathen_New Participant

Rapid re-purposing of dimensions: Alternative to deleting data?New

IssueDeleting data is incredibly problematic (and expensive!) in Adobe analytics. One of the impacts is on our agility - we have several dimensions that are tied up as they contain historic data that is no longer relevant and we are waiting for that data to disappear through the standard data retention deletion process before we reuse - This is something we really struggle with. RequirementsThe requirement is to be able to quickly re-purpose variables/dimensions, thus increasing the flexibility/agility of the Adobe Analytics tool. For this scenario the requirement is to prevent end users seeing the historical data (rather than deleting the data).  Therefore I was wondering if there was an alternative approach which would allow us to free up dimensions quickly for new purposes.   Possible solution?The problem with deleting data seems to be unpicking all the processing that has happened.  My thinking is this unpicking could be avoided by having virtual variables (much like a "virtual track" on a digital multi-track recorder) Each prop/eVar would have say 3 "virtual" versions.  The admin console would allow admins to switch between which virtual version of a prop/eVar is in use. This would mean only one virtual version of a prop/eVar would be available at one time to record new data into and retrieve data from. At a time when the original purpose for a prop or eVar is no longer relevant the admin could simply cut across to a new/fresh version of the prop/eVar - allowing immediate re-purposing. This would be different to deleting data as all virtual versions would continue to exist in the background but only one available at any one time (i.e. no data is actually deleted) From a storage/infrastructure perspective it should also be different to just giving us loads more props/eVars as only one virtual variable could be recording new data at any one time (so storage requirement should be less)  NOTE: this sort of already exists for eVars in the way that switching between different attribution types (linear/first touch/last touch) cuts across to a different instance/version of the eVar