Adobe Experience Platform

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. 

In Adobe Mobile Services, we are building acquisition links and each time we build a link “path” (based on devices, OS, etc.) we have to rebuild it again and again. Is there a way to sort of “copy & paste” that path we continue to use so that it can save time and reduce possible human error when building these links via the mobile services link builder. If not, could this be an enhancement please?  Thanks! 

Clicks are virtually the first thing we get asked for when looking at campaign activity.However, at the moment tracking of 'clicks' is next to useless:It's only available in mobile services in a separate report (not in Analysis Workspace)It only reports the click volumes for the last 30 days'clicks' can't even be trended!...so you literally just get an aggregated number of clicks for the last 30 days per link.Please can you consider making 'clicks' available as a proper metric in Analytics?(Realize this metrics wouldn't tie back to a visitor ID so couldn't be segmented etc.  However, this would be no different to a data sources metric, and would be a vast improvement on what we have today).

Add the ability to define rule priority. This can be used to control the order that rules will fire if multiple rules are matched.

Currently in DTM and Launch, events can only be set either empty for increment by 1 or serialized from value. But with the Numeric type an event can also have an actual value. So I'd like to have two input fields in the event section of the "Set Variables" Action Type from the Analytics Extension.Serialize from value (optional) -> as isValue (optional) -> newSo option 1 would create a an event like "eventN:%serializedFromValue%" and option 2 "eventN=%value%"Currently this can only be done with custom code which I would like to use as little as possible and here I have to add the event to s.linkTrackEvents whereas the one set with the gui are added automatically:s.linkTrackEvents = 'event10';s.events += ',event10=' +value

with GDPR coming in place, the call to the Experience Cloud ID service is coming into discussion. Several legal consultants in companies are claiming that the call only may be issued if there is a consent from the visitor to be tracked.The current implementation of the standard extension, will always fire the call.It would be very helpful if the extension would be able to do a cookie check, as such a consent cookie could be set, and the rule would only fire if the consent cookie is on an adequate level.Stefan

In DTM,  _satellite.getVar will honor the "window." prefix in the first argument.In Launch, this is not supported. For example :_satellite.getVar("window.digitalData.page.pageInfo.pageName")It is fairly common practice in DTM to use the above as it will fail gracefully if any part of the nested object is undefined.The same problem exists for "param.", "event.", "rand", and "target." prefixesThese may present migration hurdles for some DTM implementations.The DTM to Launch Migration Assessment at https://www.searchdiscovery.com/solutions/partners/adobe/adobe-launch/dtm-launch-assessment/  presently flags these cases as issues that will need to be fixed when migrating.

In the creation of the Data Layer Manager, SDI Tooklit, and AA Product String extensions,  I have created or worked with various new data elements that are expected to have return types other than simple string values.One example is the Malformed URL Error data element of the SDI Toolkit which can return an Array of Strings.Another is the Data Layer Manager's Contextual Data Element which can return a JSON object, an Array of JSON objects, boolean, number, or string depending on how it is configured.As more Launch extensions are created, it is inevitable that new Data Element Types will be introduced with a strong possibility of different expected return types.As this happens, it would be incredibly valuable for extensions using data element selectors to be able to filter the data elements returned to include only those that meet the needs of the extension. THE IDEA:1) In the configuration of a Data Element instance, allow the author to specify the expected return type by selecting fro

My team is beginning Adobe Launch implementations for web and mobile apps.  On the web, we are finding the ContextHub extension very useful.  I am requesting that a ContextHub extension be added for Adobe Launch mobile app implementations.