Skip to main content

Filter by idea status

10000+ Ideas

bjoern__koth
bjoern__kothNew Participant

Analytics Extension - add support for dynamic events e.g., resulting from a data elementNew

Description - the Analytics extension's action to set event variables is quite limited, assuming you know the events to set, requiring writing custom code. It would be amazing if an to-be-evaluated Analytics event can be added as a result of a Data Element evaluation. Example: I have a lookup table the generates a string "eventX,eventY" for me that has to be set on the extension. In order to do so, I must write custom code which is tedious and error prone, since I must append these to s.events, append them to s.linkTrackVars and s.linkTrackEvents. Assuming in most cases events are counters and have a value of 1, why not have a possibility to add one or more dynamic events through an input field in the setVariables action, additionally to the standard functionality? Why is this feature important to you - for many clients I have worked around this issue with custom code that is potentially error prone whereas the built-in event-add functionality is quite convenient if you know which events you are supposed to always fire. However, often I want to add additional events which are only determined by the context of the passed data. Having something that saves time and reduces room for errors would be amazing. How would you like the feature to work - have an additional text field where a Data Element can be used. This can either be a single event or a list of events which will implicitly set all required fields on the AppMeasurement library. The same way the standard functionality works. Current Behaviour - I can only set predefined events, no flexibility to set other events ad hoc based on the evaluation of a Data Element. Hope I am not alone on this. CheersBjörn

Support tag based invalidation in dispatcherInvestigating

Request for Feature Enhancement (RFE) Summary: Add 3rd invalidation processing mode in AEM dispatcher based not on paths but tags. Use-case: Currently dispatcher supports either statfile level based or ttl based page invalidation. Those two approaches can't be reliably combined (with dispatcher 4.3.5) and are too inflexible for big multinational websites. AKAMAI has concept of tag based invalidation where each page supplies list of tags when it's cached and those tags can be used during invalidation. Current/Experienced Behavior: stat file or TTL based page invalidation Improved/Expected Behavior: 3rd mode where a list of tags (arbitrary ascii strings) is supplied from publisher with a cacheable page in a custom header. The tags are stored and indexed along with cached resources (e.g. in a page.html.tags file) in the dispatcher cache. Then when some resource is invalidated an osgi service installed on publisher is invoked by flush agent to supply a tag value. That tag value is passed on with the invalidation http request to the dispatcher (again in a custom header) which in turn invalidates all files that have this tag stored. As with stat files mode this shall indeed be invalidation not complete removal.   Examples how to use tags. 1. Product collection  - all pages pertaining to product collection supply the tag, all pages are thus invalidated together, regardless of the website structure on crx. 2. Path dependencies - components report crx resources they used as tags (e.g. resource path hash), when the resource is invalidated all pages that used it are invalidated too immadiately (e.g. all carousels, menus, footers immediately react to page name change) limiting need for less agile mechanisms like TTL and providing more flexible alternative to stat files. Environment Details (AEM version/service pack, any other specifics if applicable): Apache dispatcher 4.3.5. Both could and on premise dispatcher could implement this mode. Customer-name/Organization name:   Screenshot (if applicable):   Code package (if applicable):