Skip to main content

Ideas

Filter by idea status

10000+ Ideas

Cloud Manager Content Sync EnhancementsNew

Cloud Manager’s Content Sync capability is an important tool for keeping lower environments aligned with production. However, in its current form, the process can feel unnecessarily broad in scope and operationally inefficient. I believe there are several enhancements that could make the feature significantly more effective, flexible and performant.Intelligent indexing and comparison A valuable improvement would be the introduction of an indexing or comparison mechanism during content sync execution. At present, the process appears to operate as a full content copy. In scenarios where Production and Pre-Production both contain large volumes of content — for example, 10,000 files in each environment — it would be far more efficient to compare the target environment against the source before initiating the transfer. Such a mechanism could assess whether each file already exists in the target environment in an identical state. Where no difference is detected, the file could be excluded from the sync. In reality, this may reduce a 10,000-file sync to only the relatively small number of files that are genuinely out of date. This would reduce unnecessary data movement, improve efficiency, and likely shorten sync durations considerably. A practical way to introduce this would be as an optional setting within Content Sync, perhaps via a checkbox labelled “Enable Comparison”. If enabled, the sync would perform a comparison-driven transfer; if disabled, it would continue to run the existing full copy behaviour.   Granular and targeted synchronisation Another highly valuable enhancement would be the ability to perform more targeted sync operations. For example, users could be given the option to select an individual file through a “Browse” function and sync only that file to a lower environment. Similarly, users could select a folder and sync all associated child pages or assets within that structure. In addition a ‘Claim dependencies’ button would be helpful where if it is ticked it also grabs any dependencies such as assets, references or content fragments that are required for the selected page or folder and children of that folder.  This would provide much greater precision and control, allowing teams to refresh only the content they actually need rather than relying on broader synchronisation tasks.   Combined Author and Publish execution Finally, while the separate Author and Publish options should remain available, it would be beneficial to introduce an additional “Both” option. This would allow users to initiate a single action that executes both Author and Publish syncs sequentially, removing the need to trigger each process independently and improving the overall user experience.Thank you for your time and consideration.

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.

bjoern__koth
Community Advisor and Adobe Champion
bjoern__kothCommunity Advisor and Adobe Champion

Analysis Workspace - Dynamic "Previous Date Range"New

Description - (I am sure this has been asked many times, so I just wanted to revive the idea) We need an automatic "Previous Period" date range component that automatically creates a dynamic lookback window relative to the selected date range on the panel.   Why is this feature important to you It is basically not practicable to have fixed previous date range components in place that only work until one changes the panel date range. Example Freeform table using the last 7 full days (Panel date range) vs the previous 7 days (custom date range in the workspace project). Now, someone decides to change the date range on the panel to "last 30 full days" Result the custom date range still displays only 7 days, the rest is 0 the comparability between panel date range and freeform table is completely useless this becomes even more obvious / erroneous if you are applying a summary change visualization on the two columns, not taking the same number of data points into consideration How would you like the feature to work The "Previous Period" date range automatically calculates the previous x days  / weeks / months before the currently selected date range, based upon that value. Should I change the panel date range, this will automatically update the data that has been filtered by this date range e.g., in a "Summary change" visualization Current Behaviour once you change the panel date range, your data is messed up, becoming unusable this is extremely annoying for all levels of analytics consultants. I don't know how many times I have explained this to clients or had the same issues myself other analytics tools like Looker Studio do not seem to have that problem, see https://support.google.com/looker-studio/answer/9272806?hl=en For an analytics solution as mature as Analysis Workspace, this should be a standard feature.   @ericmatisoff your two cents on this idea would be amazing. You seem to have the best connections to the product team

mariusvf
mariusvfLevel 2

API 2.0 Missing Feature Parity with 1.4 – Report Suite Configuration & eVar Metadata (Migration Blocker)New

 🧾 Description We are currently migrating from Adobe Analytics API 1.4 to 2.0 and have identified critical gaps that prevent us from fully deprecating API 1.4. API 2.0 does not provide feature parity with 1.4 in terms of report suite configuration and variable metadata, which creates a blocker for automation, governance, and documentation use cases.  🚨 Key Gaps  1. Missing eVar Metadata The API 2.0 /dimensions endpoint does not return essential configuration fields such as:  expiration_type expiration_custom_days merchandising_syntax allocation_type  These fields were available in API 1.4 and are critical for:  Automated documentation Data governance Attribution validation Migration verification   2. Missing Admin / Configuration Endpoints API 2.0 does not support:  Creating or updating eVars, props, events Managing Marketing Channel rules Accessing or modifying Processing Rules  Equivalent functionality existed in API 1.4 via ReportSuite.* endpoints.  🎯 Impact This is not a minor limitation — it is a migration blocker. We currently:  Cannot fully migrate to API 2.0 Must continue using API 1.4 in parallel Lose visibility into critical configuration logic   ✅ Requested Solution  Option A (Preferred) Extend existing endpoints to include missing metadata fields.  Option B Provide new endpoints for full report suite configuration management (parity with 1.4).  💬 Additional Context This is not a request for new functionality, but for feature parity with API 1.4, which is still required for enterprise use cases.

API 2.0 needs to handle creation/modification of variables (props, eVars, events)New

The Adobe Analytics API 1.4 is scheduled for decommissioning this summer, yet critical endpoints from this legacy API have not been integrated into API 2.0. This creates a significant gap in functionality that will impact many organizations relying on programmatic management of Adobe Analytics configurations.Missing Critical Functionality:The most important missing feature is the ability to programmatically:Create new Adobe Analytics variables (props, eVars, events) Modify existing variable configurations Delete variables when no longer neededCurrently, API 2.0 forces users to manually manage these variables through the Adobe Analytics interface, which is:Time-consuming for bulk operations Error-prone for complex configurations Incompatible with automated deployment workflows Difficult to integrate with CI/CD pipelinesBusiness Impact:Without this functionality in API 2.0, organizations will lose the ability to:Automate variable management across multiple report suites Maintain consistent configurations through code Integrate Analytics setup into their development workflows Scale variable management efficientlyRequested Solution:Please add endpoints to API 2.0 that provide full CRUD (Create, Read, Update, Delete) operations for Adobe Analytics variables, matching or exceeding the functionality currently available in API 1.4.This is essential for maintaining operational efficiency and preventing workflow disruptions when API 1.4 is discontinued.En savoir plus :1image.png

API support to start/stop/pause/resume campaigns/journeys in AJONew

Hi Team, Below are the details :  Detailed Use CaseThere are multiple scenarios in which source data for batch campaigns or journeys is delayed. In such situations, we are required to manually start, stop, pause, or resume all related journeys and campaigns. This significantly increases operational overhead.Once the data issue is resolved, the same set of journeys and campaigns must be manually resumed, meaning the effort is duplicated for every data disruption. As a result, each data failure forces us to perform the same manual operational task twice, which is both inefficient and error-prone.Business JustificationProviding API-level capabilities to start, pause, stop, and resume journeys or campaigns would enable full automation of this process. This would lead to substantial reductions in manual effort and operational burden, while also minimizing the risk of human error.When handled manually, it is very easy to accidentally miss a journey or campaign, which can directly impact revenue as well as customer experience. Automation through APIs would ensure consistency, reliability, and faster response times during data-related incidents. Feature DetailsThe API should support the ability to start, stop, pause, and resume multiple journeys and campaigns simultaneously, rather than requiring individual actions per journey or campaign. This bulk-control capability is essential for effective operational management at scale. Thanks,Mithil