Product ideas | Community
Skip to main content

10000 Ideas

FelixGomez
FelixGomezNew Participant

Avoid sent SDK App trackState or trackAction with Adobe LaunchNew

 How many times a trackAction is activated with an ID that is not registered or is entered incorrectly within the native app code.Taking into account that the development cycles for the deployment of applications within the different STORES (Android & IOS) can take months, these trackActions are dirtying the data and can sometimes increase the useless consumption of SERVER CALLS in your company.This can cause unwanted SERVER CALLS billing.Currently, the "CONTEXT DATA" data in the event we want can be modified through Adobe Launch, enriching the event from "Adobe Launch", but we cannot prevent a "SERVER CALL" from being executed even if we do not need it in our implementation. How would you like the function to work?Ideally, to avoid unwanted "SERVER CALLS", we would include an option in the "MOBILE CORE" where we could prevent the execution of a "trackAction" or a "trackState", conditioning based on its "action name" and/or contextData (in Adobe Launch UI). Current behaviorThere is no way to prevent a "SERVER CALL" from being consumed and counted, even if it is not controlled, or has been included by mistake within the source code of the mobile application through the "trackAction" / "trackState" events. There are some issues in the community regarding this that are quite old.This feature should be a "MUST" to better control the data that reaches the Report Suites, it would give a lot of flexibility and control over the data.

stevew79063868New Participant

Feature request: The new Update Variable action in the AEP Web SDK Launch extension would be a lot more helpful if you could start with an existing XDM data element and update thatNew

The new Update Variable action in the AEP Web SDK extension would be a lot more helpful if you could start with an existing XDM data element and update that, rather than having to start with an empty XDM object every time.In the scenario where you’ve got a lot of fields that you want to set on every event (e.g. domain, customer id, whatever), I’d want to start with an XDM object that’s already got all those fields populated, and then update that. Likewise, if I've got a lot of ecommerce events, I would want to start with an XDM object where the basic productListItems array is already defined, and then just update that with the relevant additional fields for the particular event (product view, basket add, etc)Currently, you have to start with an empty object in every rule, so you end up repeating a lot of work if you have rules that share a lot of fields.Another, perhaps better, option would be if you could just do the equivalent of the Merge Objects data element in rules. For example, if I've got some default 'global' fields that I want to set in every event, and I've got some standard ecommerce fields that are set on all ecommerce events, a simpler workflow would be:Create an XDM data element that contains all my global dimensions.Create an XDM data element that contains all my standard ecommerce fields.In my 'cart add' rule:Start with the 'global' XDM data elementMerge it with the 'ecommerce' data elementUpdate it with a few fields that are specific to the cart add (e.g. carts adds metric)Then I could just duplicate this rule for all my ecommerce events, and just tweak the final 'update' action depending on if its a product view, cart remove, etc. This would be much cleaner than the current situation where you eitherHave one XDM data element per rule, where you're repeatedly setting the same 'global' and 'ecommerce' XDM fields.Have layers of 'merge object' data elements, where you build up the object before putting it in the rule (e.g. global + ecommerce + cart add)Use the Update Variable action where, again, you're repeatedly setting the same XDM fields over different rules.

cvergesNew Participant

Allow for running other Fusion scenarios within the same scenario processNew

From time to time, we have one Fusion scenario call another Fusion scenario in order to centralize things like authentication token management.  (An example of this is when we call NetSuite, where NetSuite requires a specialized token process that isn't supported out of the box by Fusion's credentials mechanism.)  Adobe PS recommended we put the token generation/retrieval process be put in its own scenario, and then call that scenario in whichever scenarios we'll be doing further business logic (such as calling NetSuite for some specific API calls using that token gathered before).The issue we're finding is that Fusion sometimes returns an "Accepted" response rather than the intended webhook JSON.  Basically, it looks like Fusion webhooks are not guaranteed to execute when called but may be queued under some loading conditions.  Retrying isn't necessarily guaranteed to fix this, either.What's really needed is the ability to execute that dependent/child scenario _within_ the runtime of the parent scenario.  That is, we should be able to avoid the "Accepted" error if we can directly execute a second Fusion scenario rather than having to call it via a webhook.So the ask is for some kind of Fusion module or other implementation to allow for temporarily suspending the current scenario, calling a specified scenario (and passing in appropriate parameters), having that second scenario return a response, and then start executing the original scenario using the response returned as a data point.