Skip to main content

Filter by idea status

10000+ Ideas

Sequential Segments: Replace "Only Before/After Sequence" options with enhanced options for desired data returnedNew

Replace the current "Only Before Sequence" and "Only After Sequence" options with these options:"Apply to [First/Last] sequence match (Required)"Currently this is not configurable. "Only Before Sequence" setting is applied to (and includes) the first hit of the last matching sequence and everything before. "Only After Sequence" setting is applied to (and includes) the last hit of the first matching sequence and everything after.Presenting this option would also help users understand how "match first/last sequence" is necessary part of how sequential segments work when there are multiple sequence matches within a visit/visitor. "Include data from [All/First/Last] hit(s) within the matched sequence in the results (Optional)""I only want my sequential segment to return just the first/last hit from the sequence." has got to be a common desire among analytics users, as others have requested this in other idea submissions. The "Include First/Last hit in the sequence" option would enable that use case, and the "Include All hits" and No selection (unused) options enable many other use cases.Currently this is not configurable. As previously mentioned, the "Only Before Sequence" setting includes the first hit of the last matching sequence, and the "Only After Sequence" setting includes the last hit of the first matching sequence."Include [All/<number of>] hits of data from [Before/After] the sequence match (Optional) in the results""I want my sequential segment to show me what the user encountered just before/after they encountered <desired sequence>" also has got to be a common desire among analytics users.Currently this is not configurable. The "Only Before/After Sequence" options return everything before/after the sequence from the visit or visitor, plus the first/last within the sequence (as previously mentioned).I think these options would dramatically improve the capability and value of sequential segments, and make it easier for users to understand exactly what data is potentially included in their segment results.

FrederikWerner
FrederikWernerNew Participant

Add option to build non-minified libraries for non-prod environmentsNew

Description - Adobe Experience Cloud Experience Platform Dynamic Data Collection Launch, by Adobe Tags minifies code when a library is built. That feature is super helpful for production environments, where site owners usually want to minimize the impact of loaded libraries. And that is great! Except for when you are actually trying to read the code afterwards. For example, minification turns my horrible, hacky, readable and commented code... into this horrible, hacky, unreadable and uncommented code: While the size advantage justifies the less readable code on production, practically every developer I've ever worked with complained about the minified code on any non-prod environment. If you just want to see what a piece of code does and why it won't work, minification does not help a lot. The usual solution is to remove the .min from the Launch library's file name, but that requires a) knowledge of the feature and b) some manual intervention, browser plugins, or other effort. Even worse, if the library file name would ever change due to changed environments in Launch, an unknown number of people would need to update their already configured stuff too. That's not very cool. In my personal experience, there is a general tendency per environment for either the minified or un-minified version to be preferred. Minified is fine for prod, but un-minified is what you want everywhere else. For that reason, I want to propose an additional toggle in the environment settings that would disable the minification during build, along the lines of this:  Disabling this toggle would change the URL in the field below to the un-minified variant and cause all references to other code pieces, like Custom Code Actions, to also not be minified. While it would be enabled by default for all environments, it would give us an easy option to make everyone's life on non-prod a lot easier. Why is this feature important to you - Because I like efficiency How would you like the feature to work - See above Current Behaviour - 😖

Make Date Annotations more visual within our graphsNew

Description -  It's great that Adobe added data visualizations to our graphs a few years ago, but the way they display isn't very visually impactful...    It's a little flag that shows in the X-Axis, leaving the users to still try to identify where exactly that point lies on the graph.     Of course, users can hover to have a line show up for the annotation.. but that doesn't really work for PDFs.. and if there are a series of annotations you can only see one at a time... let's say you are reviewing the impact of a multi-site migration rollout, you might want to see each point where sites were migrated and the impact over time of all the sites together...   Having the ability to show a permanent visual indicator would allow everyone to see at a glance where the impacts are, and users can still check the annotation details one at a time.   Why is this feature important to you - Making the annotations more visible at a glance, and being able to see multiple annotation markers at once allows the data to be ingested by users easier.   How would you like the feature to work - This could be an optional checkbox to show or not show the intersections all the time.. as I know that if there are a large number of annotations this could get busy and make the visuals overwhelming.. but for a few annotations this would be a handy visual to have.   Right now, in order to have a visual representation, I have to create a custom date/date range, a segment from that custom date, a calculated metric using that segment in an IF statement, and then graph my metric and calculated metric as an area chart:   (See https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/graphics-edition/td-p/605264)   If we could get a more visual annotation out-of-the-box it would save a lot of time, and I think be beneficial to all.   Current Behaviour - It's just a flag that when you hover shows a vertical for individual dates, or a mid-point vertical and an extremely pale range line for date ranges:   When it comes to ranges, the user has to use their best judgement trying to understand where on the line the range actually starts/stops because the indicator is separate from the actual data... they can see "in general" where the range is, but don't have the detailed specifics of the intersection.

cvergesLevel 5

Improve condition builder in FusionNew

Description - The condition builder in Fusion supports a very simplistic Boolean logic, allowing simple expressions such as (A && B) || (C && D).  This is functional under many circumstances, though forces a lot of duplication of checks on the UI side. The following is an example of a condition that would be problematic: ID = "foo" && (Error 1 = true || Error 2 = true || Error 3 = true || Error 4 = true) In the existing condition builder, it results in something that looks like this: (ID = "foo" && Error 1 = true) || (ID = "foo" && Error 2 = true) || (ID = "foo" && Error 3 = true) || (ID = "foo" && Error 4 = true) If we have to change the value of "foo", this creates a risk whereby a human may miss all instances of "foo".  (This risk increases with increasingly complex conditions.) The ask is to improve the condition builder to allow for full Boolean logic.  We have a similar version built into our own product, and I'm attaching an example of what that type of UI might look like as a concept to showcase how to think about the proposal. Why is this feature important to you - We are currently having to implement such complex conditions through either (1) duplicating values/checks or (2) a series of Router and Set Variable modules that perform the evaluation using edge filters between modules.  Either way, it's a cost/risk introduced due to a UI that is limited in its current form. How would you like the feature to work - Anywhere that conditions are allowed (event watchers, edge filters, etc.), use the same enhanced UI mechanism.  Allow a user to create a Boolean expression similar to how a developer would do it -- through nesting and grouping of logical operators.  If the backend needs to translate that down to a simpler form for evaluation, that can be transformed internally. Current Behaviour - Described above in the Description.

cvergesLevel 5

Add "429"-related retry controls to the Adobe Workfront Custom API module in FusionNew

Description -The Adobe Workfront custom API module (or any other Workfront API module) is often used to query various API endpoints.  That module doesn't appear to have any built-in mechanisms for handling a retry when a 429 (API rate limit exceeded) occurs, though this is a fairly standard and common occurrence in high-volume systems.The existing way to handle this in a reasonable fashion is to:Make the API call with the custom API moduleSet an error handler from the moduleOn the error handler path:Sleep for some amount of timeRetry the API call with a second custom API module that's configured the same way as the firstSet a success handler on that "Resumes"Set an error handler on that second moduleOn that error handler path:Do the same as on the first, and continue nesting this for as many attempts as you want/needThis is super unwieldy and means that the module configuration is duplicated or triplicated, meaning future changes need to be done multiple times, which is risky due to human error being a normal thing. Why is this feature important to you -Given how common the use of the Adobe Workfront modules are and how common the 429 error is, it would make sense to have a mechanism built into the module to allow for retries and some kind of backoff sleep time to be just part of the module's advanced configuration.  It reduces the cost to build and maintain these Fusion scenarios. How would you like the feature to work -Have at least one numeric entry in the Advanced Config section of the Workfront modules for "Number of retries if too many API requests", default to "1" to allow for compatibility with existing scenarios.Optionally have another numeric entry in the Advanced Config section that allows for setting the sleep time.  It would be most ideal if there were options for constant sleep, linear sleep (increasing by "constant" times the retry count), exponential sleep, and/or random sleep between some range of numbers.If the module exceeds the retry count, execute the error handler path as currently supported. Current Behaviour -See the description above.  The following image also shows how a chain of 429 retries gets to be unwieldy after even just a few API calls.  Imagine having to propagate a series of changes -- this creates 2x the work, all for a simple "retry" handling.