Adobe Experience Platform

When editing a Rule, the user cannot see which rule is currently being edited! Very annoying, as you always need to step out of the configuration to make sure you're not working on the "wrong" rule...

In current versions of the SDK (v4 and AEP), trackAction events do not include the name of the Screen or State the action occurred on - by default the pageName parameter is populated by the App Version, and this appears to be discarded on processing.Because of this, there is no out-of-the-box way to report on Action Name (or other dimensions set on a trackAction) against the Screen/Page/State that the action occurred on - a very common, straightforward report. This forces implementations into bulky workarounds such as including Page Names in the Action Names or creating a second Page Name custom dimension.If trackActions captured the actual Page Name, this would make a very common scenario much easier to implement & report on.

In DTM the delay link activation breaks the JS-based links and in some instances anchor links functionality.The request is to either:1. Have an option to disable the delay link activation on links that are pure anchors, contain the URL of the existing page + an anchor, or contain javascript commands.2. Revise the functionality of delay activation so that the delay just delays the activation of the link, not stops it and then takes user to that URL.Including a sample code that successfully can achive both of these requests:/**  * The functions executes for x milliseconds.  * @param  {Integer} ms  Number of milliseconds the function should run.  * @return  */ export default function waitMilliseconds(ms) {   var start = new Date().getTime();   var end = start;   while(end < start + ms) {     end = new Date().getTime();   } } /**  * Delays the links from moving forward on click by 1 second  * to allow the data to go into analytics successfully without the delays.  */ export default func

Hi,we are working on continuous deployment and to help follow the same process here, we would like to enable the user of informing a system when a library changes from development to "ready to build in staging".  this would help ensure we follow the same process here while having full control over the development portion.  By doing this, when we have a build that is approved to go into staging, we can approve it and then the system will notify our process that it can begin the automated tests to verify that this new build passes our control tests before being published.  This will help improve our own systems and reduce the possibility of error of the system approving a development project instead.

To manage Adobe Launch I have related online documentation which includes any javascript code we are using and an overview of the rules and what is fired with each. It's particularly useful if I need to find something within a data element as it means I don't have to click into every single one on what is currently a little bit of a clunky interface. But this means every time I change my code I have to also update my documentation.It would be great if there was a quick export of all rules or data elements. So I could then upload this file somewhere and perform text searches on it and share it with others.

In DTM was possible to add subdomain path or protocols when you configure the UPL in the property but in Launch this is not possible.It will be great if we have this Feature in the near future.Can someone advise how to set up similar to this URL in Launch Property?Tampa.com/bamboo/eisThanks in advance!

Guess this is both feedback and a suggestion...but I really think the communication around Adobe Launch needs improving. (Admittedly...this could just be that I'm not looking in the right places for information).Yesterday I was trying multiple times to build a library and it was failing for no particular reason. It was only when I was coincidentally on a call later in the day with customer care that I was informed there were issues with Akamai meaning builds were failing and the engineering team were looking to resolve them.This sort of information should be communicated to customers better...and you would think could be an easy update notification within the Launch CMS.Generally the information around build failures is not great..ideally it would tell you which rule/data element has caused the failure...but this means the above is even more important.The other is notifications about potential issues. There has been an issue with Adobe Launch whereby variables were not clearing properl

It could be that I'm missing it, but it would be great to have a note field to describe in plain language what each build contains.

When the marketing team requests a pixel(s) be added to the site, they must provide the date that the pixel can be removed. Right now, I put a reminder on my calendar to delete the end-of-life pixels. Note: There are a few pixels that don't have an end date....but those are far-and-few between.It would be so super nice if there was a feature in Launch that allowed me to put a start date and an end date (i.e. effective date range) for each action. So, when the start date hits, the action would fire off the pixel (or chunk of logic within it). And when the end date hits, the action would be deleted automatically.I ask for it to be deleted versus commented out, because we saw gains when we commented out end-of-life pixels....and then we saw more gains in performance when we completely removed the pixel code.Thanks -Sarah

DTM allows us to put custom  JavaScript and HTML. codes; however, it will be very hard to find a specific html tag or javascript codes later.There should be "code search" function in DTM so that we can find specific line of the codes in DTM. Thanks,

Prompted by Embedding third party JS Tracking for my siteIn some cases you just need to embed a script on your site. Yes, you could do it via a "Core - Custom Code" action but I also wonder if it warrants a "Generic Embed" extension. If the provider of the script is a small company who will likely never create/maintain an extension, it would be nice to still have an easy way to add the embed code. In this case, you likely don't care about it providing any configuration, rule component types or data elements so a generic embed is probably what you are after.

Adobe DTM has a feature to enable both Akamai and FTP Delivery. We found this very useful on our project's implementation where we need to address some security vulnerabilities and access limitation to external servers. This also help us to fully automate the update of the self hosted JavaScript and have a fail over to akamai for scenarios that automated update is not possible. Currently, this feature is not supported by Adobe Launch. Would it be possible to have this feature available on the future release of Adobe Launch?Source image file 21571 not available

At the moment environments are controlled by JavaScript tag that is deployed.  i.e. dev, staging, and production environments have different tags and this determines what code is delivered.However, often we find ourselves wanting to test our development code against the 'live' environment (obviously before publishing to the live environment!).This may be because other environments are not available or because other environments are not fully reflective of the live environment.Please can you consider developing a way to test code in the live environment?Adobe Target already provides this kind of capability so shouldn't be too hard for you to do

Would be great to be able to edit or unpublish Libraries in Adobe Launch.  In learning the tool and getting more advanced with it, it is easy to make mistakes or just not have the optimal setup right from the beginning.  For example, in our instance, we have 4 separate libraries that are in the published state just for Adobe Target extension and base rules.  Ideally, this would be (and should be) in 1 library.   But since they are published, there is no way to pull back the 4 different libraries and redeploy them in a single library (which would be much cleaner and more efficient). I cannot image how much Launch will get cluttered up as we deploy more extensions, add additional rules, create data elements (that the rules will then pull from), etc.

In Adobe DTM, there was a robust system that allowed side-by-side comparison of any pair of revisions of a single rule. I am now deeply missing that functionality in Adobe Launch.Currently, I am able to easily access a revision of a rule that's in an Upstream library (for example, while I'm developing updates to a rule, I can see the current 'live' version of the rule) - but I have no indication of what changes have been made. Furthermore, I can't find a way to review an older, non-published revision of a rule without creating a new library and specifically adding that old revision (which, in of itself, seems like an issue).Being able to easily see changes in Events, Conditions, Exceptions, and Actions would be tremendously helpful in diagnosing issues - especially in projects with multiple team members. Ideally, it would be nice to get to a level of detail similar to the current DTM tool that even gives a full DIFF of a custom code block. That said, even just knowing if a condition ha

As a developer, I would like to create an App that uses OAuth to properly identify a user to perform Launch API actions on their behalf.  Currently, JWT is the only Authentication/Integration method supported.  But the limitation is that we can't properly identify the user performing the action and audit logs no longer are useful for identifying who performed actions.The ask would be to enable OAuth integrations with the API.  This could be via 3-legged authentication.

It would be a a great feature to have something like a "timeline" showcasing what orders may overlap.Ex. Many page view events all have the same order. When creating the rule and selecting the event, you can see what if another rule is set to the same order.DOM Loaded Event<-----------"order 10" has 3 overlapping rules------"order 20" has 1 rule"------"order 40" has 5 overlapping rules-------DONE->

I would like to explicitly define the return types of each Data Element. Preferably, this could be done using a TypeScript interface, JSON schema or similar.Potential types: number, string, array, Promise (for async actions), boolean, any (default) or custom object (requiring input schema). A void/undefined type or an empty string could represent an error thrown or an invalid value.Additionally, adding a type-checker or data validator based on these definitions could help provide tighter, safer output for these DEs.

I would like to drag and drop successfully built (green dot) libraries through the publish process. I think the swim lane design affords this pretty well and would save some clicks and scrolling.

We need to be able to asign a role that has no admin rights, but with the possibility to create aquisition links. Currently, Mobile Services users can either get admin rights or read-only access. In order to create aquisition links, users need admin rights, which is not compatible with our team setup.

Right now an extension developer can only save settings for the currently viewed item, whether that's the extension configuration page or a rule action. It'd be nice if developers could dynamically create or update data elements, rules, actions, etc. Use cases:I'm allowing multiple accounts to be added within my extension. If a user wants to disable or remove a specific account, I want to be able to update all of the rule actions and remove the account from the saved settings automatically to prevent unnecessary bloat in the bundled Launch library. Right now this is a manual process that can take quite some time depending on the number of rules the Launch user has setup. In my extension the Launch user can specify the name of a window-scoped JS variable and function that are required. Within my extension configuration I'd like to be able to create a data element that references this function / JS variable when the Launch user clicks a button to create the data element.

The publication flow is powerful and awesome, but it can be overly complicated.... even for those who need all the steps.It would be nice if "Submit for Approval" were greyed out or not shown as an option if clicking it will only result in this error/prompt:Better yet, if the option became "Build for Development and Submit for Approval", that would save some time/clicks. 

One of the principles behind Launch is to bundle only what you need to keep the library light and fast for the end user. While developing extensions I've made sure to keep as few items loaded and kept the settings objects as small as possible. But there are also times where I want to save settings/preferences that should not be bundled in the Launch library.The two main use cases I see here:Partially disabling a feature within an extension where we want to keep the settings for when the user wants to re-enable the feature. For example, the Adobe Analytics plugin - if I disable the exit link tracking, I still want the list of internal domains to be saved, but I don't necessarily need it output on my site since we're not using it. Right now I have to choose between saving the settings and having unnecessary (albeit small) bloat in the bundled lib, or not saving the settings and when the user comes back to re-enable the feature they have to re-setup everything.User interface preferences,

I ran into some odd behavior today and wanted to report it as potentially needing a fix.I created a new library and made sure I had it selected as my working library. I then added a second condition to an existing rule. When I clicked the "Save to Library and Build" button the build failed. The reason given was that revision x was already in the upstream. I checked the upstream and sure enough, the upstream contained revision x and my attempted build contained revision x (latest). I then looked at the rule and selected "Compare Revisions" in the left pane it showed revision x without my change, and in the right pane it showed latest with my change. At a loss I deleted the new condition from the rule, then recreated it and the build succeeded.I needed to add the same condition to a second rule, and again ran into the same issue. This time I deleted the new condition and successfully rebuilt the library. I then added the condition a second time and the build succeeded.

It would be very helpful to be able to use virtual report suites in Mobile Services as we have 5 apps all passing data into our global report suite. Without this, mobile services only adds value for organisations who use a different report suite for each app. We as a company are reluctant to do this because we want to view our entire digital offering in one report suite and view cross device, cross platform journeys.