Product ideas | Community
Skip to main content

10000 Ideas

AbhishekDhami
AbhishekDhamiNew Participant

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
DavidRa14New Participant

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
bjoern__kothNew Participant

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.