Adobe Experience Platform

***Moderator Note: This idea is centered on two different products. Neither of which are owned or managed by Adobe. Fortunately, It looks like Search Discovery found this thread and has made the necessary changes***we just started our first migration test from DTM to Launch. We used the SearchDiscovery assessment tool prior to the migration - and this is very helpful.But with the first "environment" test we already ran into the issue that the DTM switch is pointing to our DTM libraries, and does not recognize our Launch environments. As SearchDiscovery states on their help website for the DTM switch:As this isn't working, the workaround is to overload the DTM library with the Launch library through remote mapping with Charles. And this works fine... you can then choose your Launch environment to overload - and thus test...Would however be much more practical for testing if the DTM switch would handle this case...  I assume more customers will start migrating and will run into the

Hi,as we have different domains (white label, with slight changes) for basically the same platform, I need almost the same set of Launch Rules multiple times. It would be great if there was a way to copy or even somehow sync the Launch Properties (as I was told was possible with DTM).Is that kind of feature planned?RegardsSara**Moderator Note **Archived idea since a similar idea was linked in the comments.

In DTM when you look at the rule details, you see if the analytics part contains custom code before you open the accordion containing the details. I miss this featue in Launch. Currently I would have to define a naming convention for the action so it is clear that it contains custom code.

Currently have to use custom bridging methods to get the Mobile SDK to work in React native mobile apps. Would be great to have an Adobe approved method. Adobe mobile service with React-native-app

From the Publishing tab, when I click on a built library to view its contents, then click a Rule to verify that changes to the rule are present in the build I get an out of date view of the rule on this Edit Rule screen. Here are some notes I took on what I ran into and how I eventually worked around it;July 30- Rules tab, Adobe Target says it was last modified Mar 26, this is wrong, an action in this rule was modified last week.Open the "Adobe Target" rule and the actions contain the latest updates (Actions, note the order: "Adobe Target - Add Params to Global Mbox" > "Load Adobe Target" > "Adobe Target - Fire Global Mbox"), despite not having changed anything I Keep Changes and Save. Last Modified remains unchanged. :-/On Publishing tab, latest published library was published Jul 25. If I view its contents it shows the Actions in the wrong order ("Load Adobe Target" > "Adobe Target - Add Params to Global Mbox" > "Adobe Target - Fire Global Mbox"), I don't believe this is

Using Adobe Launch Async script will cause many crawl errors in Google Search Console (Google Webmaster Tools).We implemented Adobe Launch using async on 75 websites in early May and each one is receiving 70-150 crawl errors being generated from the launch script. When using Adobe DTM scripts we never received the crawl errors and now we do. Adobe Support confirmed that Google is parsing assets.adobedtm.com incorrectly and making it look like our websites have extra urls which then return 404 errors. Support said this is not widely spread since Launch is a newer product but if anyone uses Launch async without listing every one of the 404 urls in their robots.txt file then they will receive the crawl errors from Google. This can be impacting organic search reputation and rankings.I'm hoping this ticket can get votes as we really like Adobe Launch and want to continue using it on 200 plus websites we own but not if the crawl errors continue to happen.

From SarahEOwen​I REALLY, REALLY like in DTM that when I make a silly mistake - like forget the ending " in my console.log() in the below screen shot - that I am warned and notified of the line of code that is causing an issue (see screen shot 1 below).But, it looks like this wonderful feature is not in Launch (see screen shot 2 below)Screen Shot 1 :: DTM Saving MeScreen Shot 2 :: Launch Not Saving MeI put the same typo here -- missing the closing " in my console.log() -- but there is no warning. I can save this action and then save the entire rule.

Our security department doesn't trust anyhting hosted on the cloud, so we use the "Create archive" option for the environments to download a ZIP file which we then manually load into AEM DAM. This is cumbersone as it seems the folder name hashes change from time to time and the DAM transforms all folder names to lowercase, so we have to use CRX DE to change them back to the upper case ones or else the AppMeasurement.js can't be found.So my idea would be to have an additional flag:"Create AEM content package" with a text field to where the script should be deployed. But keep the "Self-hosted Path to Library" as this might not be the same path as the one of the content package due to ResourceMapping.

I know there is a staging environment for a very good reason but there are cases where the staging library just isn't needed and approving then building for staging is nothing more than additional clicks for the launch user. For instance in the initial development stages when the production embed code hasn't even been published yet. The idea here would be add an option for users with sufficient access to build to production from the development library menu.

This is another small thing but it keeps messing me up. If I type "eVar3" it shows me a dropdown of all eVars that match, which is nice:The problem is, at that point, if I say to my self "nah, eVar3 is what I need" and just hit tab or enter to leave the field, it won't stick- the field goes back to "select eVar", because I didn't select something from the dropdown. This is true of pretty much all the fields (props, events, etc).

For those of us who manage a lot of different properties (which means development inevitably includes the wrong embed code from time to time), having a built in variable or function to return the property name would be a huge help and, I would think, very easy to implement.  Trying to match embed codes against multiple property definitions is a nightmare.In our DTM implementation, I created data elements in each property called "dtmPropertyName" and could always do a getVar() on it to figure out which had been included on a page.  That works, but I think it would be something a lot of people would use if it was a part of the product.

I've found it unnecessarily difficult to delete anything in Launch.  Before I can delete anything, I must first disable it and ensure that the disabled item is published to production.  Once it has been published to production, I can then go and delete it and push it through the publishing process.  I'd like to just delete it.

Have conditions as separate entity will help to reuse condition across Rules. Currently its more of rewriting same across onn Rules( which can help to trigger diffrent tags on same set to cinditions).Hope it make sense.

One challenge I have found with Adobe Launch is debugging custom rules. The custom code in Adobe Launch is put into JSON strings and evaluated resulting in the code not being available in Developer Tools for debugging.I found a feature in Chrome Dev Tools that allows a local override and a “SourceURL” to be set.If I modify the script file by adding something like this to the end. “//# sourceURL=someUniqueName.js”Then I can find “someUniqueName.js” in sources and browse the code and set breakpoints.Request ideaAdd a checkbox in the Environments tab of Adobe Launch “Turn on SourceURL” for Dev and/or Staging scripts.When checked. It would add this “//# sourceURL={uniqueFileName}.js” To the end of every generated script.This could greatly simplify debugging.

would be nice to know what the warning or error messages are in the custom code section. Can't see what the issues are, just shows warning signs.

Today, we have many in page tagging rules which do not require a page load to fire.  I can add code to our s_code or Global rule section but those only fire when a page load is triggered.  I have a need to load variables for every event that occurs and it would be great if either the s_code or global rule section would fire for ANY rule event.  This would eliminate redundant code and make maintaining these rules easier.

It would be great to add an s.clearVars(); option to each rule. We are moving toward a single page app framework with multiple events firing on a page. It would be nice to have the option to either globally or locally set s.clearVars to rules. As of now we are manually adding it at the top of custom code in each rule where it is required.

In DTM it didn't matter which order you put in the s.props once you saved they resorted into order. So for example you could enter them in s.prop1, s.prop23, s.prop2, s.prop11.  And when you saved and reloaded the rule it would sort them s.prop1, s.prop2, s.prop11, s.prop23.   Which is really handy when you are scanning for something.  Launch doesn't do this so as the implementation changes and grows you need to manually reorder variables (unless I have missed something)

I know that this was basically impossible to do in DTM, but I'm wondering how feasible it would be to allow the property administrator to configure Launch's primary object from _satellite to another string so that multiple properties could coexist on the same page. My reason for wanting this is to allow a configuration where two or more Launch instances are deployed on the same page.I have come across scenarios in the past when this would be absolutely ideal (especially if both were driven from the same event-centric data layer).Example 1: A holding company wishes to collect analytics data globally on all of its brand websites.  The individual brands also wish to collect analytics data but don't want to be bound by the SDR of the holding company.   Having multiple Launch properties on the page would allow this. Example 2: A solution is designed for a website that is fully driven from data layer events but the organization's IT staff will not be able to deliver the application modificat

It would be useful to have some tiered access control on Launch rules (and perhaps data elements). I would like to be able to create a baseline set of rules that can be viewed by others but not changed. The scenario for this is an environment where Launch is triggered by various application events such as "Page Loaded", and "Product Viewed". There would be book-end rules that are created for each event, say "Product Viewed - 10" and "Product Viewed - 90".  These rules would be triggered by the same custom event, but would be set up with event order of 10 and 90 so that one runs early and the other runs late. The early rule that runs on 10 would have an AA Action of Clear Variables, followed by an AA Action of Set Variables. The late rule that runs on 90 would have an AA Action of Send Beacon. These book-end rules might be created via the Launch API and would provide the basic tagging needed by this and many other properties. If a person wanted to extend this solution with additional AA

This idea comes from a question asked on the community:The community member would like to see Session Storage added as a Data Element option in addition to Local Storage.

Ideally Launch would include the same functionality to mimic the _satellite.dtmRuleStackArray functionality that is in DTM.  Doing so provides a great audit mechanism, as well as a way to perform a gap analysis for rules that are not in use.

We should have the ability to control default lifecycle metrics behavior in the Mobile SDK configuration. This would include toggling whether or not events such as app launches automatically trigger lifecycle tracking, so that they might be manually sent or disabled entirely.

Since we have multiple environments wherein multiple rules, data elements and even entire properties can be tested. What if we create such features to schedule the rule publish from the test to dev environment and if we are successful in this migration then to prod environment.At times we test the things in stage in live websites by switching the library to point to stage for a rule or data element. When we know that the testing is positive for an update then we can schedule the publish for that rule/data element and property to next day or near to go-live dates.

I can create a Data Element of type javascript variable, or custom code, that references/returns an array.  However, Launch (and DTM) doesn't have any functionality baked in to take advantage of this.  Instead, it ultimately expects a string value returned (and type casts the value to string when parsing %data_element% syntax references to enforce it).  Meanwhile, you have for example Adobe Analytics hier variable, which would benefit from being able to reference an array.  As of right now you just provide 4 fields and i can reference 4 separate data elements (or hardcode 4 separate values).  But in practice, I can have more than 4 levels in a hier variable.  I think it should be a pretty easy update to the Launch interface to just have the hier[n] variables be a single field to reference a data element that returns an array, and a field to specify a delimiter (already implemented), and then under the hood, check if the returned data element value is an array and then join by delimiter