Adobe Experience Platform

Is there any reason why the default embed code for Akamai type Adaptor (Hosted by Adobe) still uses a protocol relative URL? I can think of none.

In the Adobe Analytics Set Variables screen, a user still has to refer to a local SDR copy or jump into Adobe Analytics admin to know which prop/eVar/events to set.It would be great to provide a report suite name to automatically pull in the friendly names and descriptions from the AA admin area.Might be more difficult when sending to more than one report suite, but the option would be nice.

This is just a nice to have, but Oh Boy! would it be nice to have a Command-S shortcut on the text editors within Launch. \There are probably more like this - I just want to start the conversation.

It's nice to see the title of the library and timestamp of when it was published, but it would add a lot of value to have a free-form text field that can be updated along with that library.There have been idea requests in the past asking for a 'notes' section for everything that can be updated/saved, such as revisions for data element, rules, extensions...  But that could get out of hand since a new revision is created every time you hit save.  Within the platform, you could link to published changes via the libraries including those items, and then view the notes in that section for the additional detail.Example: For an audit trail for a data element, I should be able to select the data element -> hit 'history' , and then see the published libraries that contained revisions of this data element.  From there I can view the notes of the library to know why I made those changes.

Hi,I was recently in contact with Adobe Support about the Experience Cloud ID Service 3.2.0 and a critical issue that caused Adobe Analytics beacons not to fire. I'd like to suggest that Adobe remove versions (like ECID 3.2.0) with critical issues (or at least make them not selectable) in DTM tools (like the AA, Target, and ECID) such that users can't select a version known to have major issues.

Go to Rules. Under EVENTS, click the + icon to add a new condition. In the Event Configuration, choose:Extension: CoreEvent Type: Custom EventThis is for triggering a rule based off a custom event listener to be dispatched elsewhere.  Exact syntax depends on details, but assumeCustom Event Type: someEventElements matching the CSS selector value: documentThe rendered js is basically this:document.addEventListener("someEvent", function(evt) {     /* other stuff from rule placed here */});Custom Events have ability to have data payloads passed to the receiving callback function when they are dispatched.  Here is a generic example:CustomEvent - Web APIs | MDN// add event listener for custom event "someEvent"document.addEventListener("someEvent", function(evt) {     console.log(evt.detail); // output: {'foo':'bar'}});// payload of data to pass to custom eventvar data = {  'foo' : 'bar'};// create and dispatch custom event, including the payloadvar ev = new CustomEvent('someEvent',{detail:da

***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