Product ideas | Community
Skip to main content

Ideas

Filter by idea status

10000+ Ideas

Extend Adobe Analytics 2.0 APIs to Support Report Suite Configuration and Processing RulesNew

DescriptionCurrently, Adobe Analytics 1.4 API provides several powerful endpoints that allow administrators to manage report suite configurations programmatically. These include the ability to:Fetch and update eVars, props, events, and classifications.Retrieve configured processing rules for a given report suite.Adobe has announced that the 1.4 API will be deprecated in favor of the 2.0 API next year. However, these configuration-level features are not yet available in the 2.0 API. Once 1.4 is removed, these critical capabilities will be lost.For many enterprise-scale implementations, this functionality is not just convenient — it is essential. Proposed ideaExtend Adobe Analytics 2.0 API to include endpoints for:Variable Management: Create, update, and fetch eVars, props, events, and classifications at the report suite level.Processing Rules: Fetch and (if possible) update processing rules for a given report suite.Cross-Suite Comparison: Provide efficient ways to compare variable configurations between report suites via API.This would ensure continuity for projects currently relying on 1.4, while aligning with the modernized API framework. Benefits / Use CasesScalability: Easily update or configure variables across multiple report suites in bulk instead of relying solely on the UI.Transparency: Retrieve all processing rules in one call, making it much easier to audit mapping when there are 100+ rules.Consistency: Compare variable configurations across report suites to ensure alignment in enterprise environments.Efficiency: Save time and reduce manual effort by automating repetitive admin tasks.Call to ActionPlease consider adding these configuration endpoints to the 2.0 API roadmap to avoid losing critical functionality when 1.4 is deprecated. This would greatly benefit customers managing multiple report suites and complex implementations.

DavidRa14
DavidRa14Level 2

Allow Versioning/Replacement of Documents in linked AEM Assets foldersNew

Description - Allow the versioning of or the replacement of documents that are in a folder in a Workfront project that is linked to AEM Assets. Why is this feature important to you -Our marketing teams use Workfront to route their materials for review and approval. There are situations where minor changes are needed to be made to documents after that are approved and moved into a folder in their Workfront project that is linked to AEM Assets. These changes are typically made by external agency partners and loaded into Workfront for review and approval routing by those agencies. Once the changes are approved, the marketers must move those changed files into the linked folder, either replacing or creating a version of what’s there. Today this functionality does not exist. The Marketer must use the following workaround:Download the document(s) from Workfront.Upload or drag/drop the document(s) into AEM Assets - they either replace what’s there or create version(s).To avoid duplicate documents, delete the document(s) from the Download location.This creates extra unnecessary steps and also creates the potential for duplicate documents if the user forgets to delete the document(s) from the download location, impacting our single source of truth.   How would you like the feature to work -The users would like to drag one or more documents (that have the same names as what’s already present in the linked folder), from one folder in their Workfront project into the project's linked folder. They should get a message, like in AEM Assets, to either replace the document(s) in the folder or create version(s).  Current Behavior - Once documents have been moved into the linked folders in a Workfront project, users are no longer able to edit, delete, replace, version, or move those documents.

bjoern__koth
Community Advisor and Adobe Champion
bjoern__kothCommunity Advisor and Adobe Champion

Support sending Profile data through WebSDKNew

Description - right now, WebSDK only supports sending data to Experience Event schemas/datasets. This is reflected in the WebSDK data elements, where only Experience Event schemas are shown.   Usecase: build up a Profile when the user fills out e.g., a newsletter form. It's a CDP and this should be a standard feature and it cannot be that one must set up some server-side API connection to make this work somehow. This approach is way(!) too complicated and should be possible to be done in the Tag Manager like sending page view or other events. I found threads from years ago where Adobe said it would come and is on the roadmap. So, ...?   Why is this feature important to you - I cannot be that you must be or ask a programmer to send any kind of Profile-related information to the CDP, whereas you can easily send interactions through the WebSDK.   How would you like the feature to work - allow the user to create Profile-schema XDM data elements and also give the user the choice to send this information to the Profile dataset e.g., through a dedicated "Update Profile" event type or similar.   Current Behaviour - All WebSDK sendEvent calls end up in the Experience Event dataset. If a custom code sendEvent is used and Profile attributes added to the XDM, they are dropped since they are not in the Experience Event schema.   Side note: to achieve the Profile update through Launch and not needing to ask a CMS dev, I had to come up with a solution that puts any Profile-related data into the "data" section and use Launch SSF to pick up this data and send it to the AEP HTTP API. Obviously it is less than ideal that you must to either have the SSF SKU or implement it on your own webserver through customiz APIs implementations.

Marti_ANew Member

AA/CJA - Enhance component & segment governance and traceabilityNew

Hi there, I'd like to raise a feature request on AA/CJA segments & components. DescriptionI’d like to suggest a few improvements related to traceability and governance of key components in AA and CJA, specifically for segments, derived fields, and Data Views. Why is this feature important to youThese features would greatly enhance collaboration across teams, improve auditability, and enable safer and more transparent management of assets within Analytics. In environments with multiple users and frequent changes, it's essential to track who made what changes and when, and to be able to recover previous versions if needed. How would you like the feature to workSegment change history: Ability to view a log of changes for each segment, with the option to restore previous versions. Ideally, this could be enabled selectively for specific segments to avoid unnecessary data load.Author and last modifier for derived fields: Each derived field should display who created it and who last modified it, along with timestamps.Timestamp and user tracking in Data Views: Every component added to a Data View (dimensions, metrics, filters, etc.) should record the user who added it and the time it was added.Current Behaviour Currently, there is no version history for segments, nor clear traceability of who created or modified derived fields or Data View components. This makes collaborative management and troubleshooting more difficult in complex environments.