Skip navigation

Enhance Processing Rule/Server-side Implementation Flexibility

score 1
You have not voted. New Idea

We are testing and planning to implement server-side tracking for the following reasons. 

 

1. We have seen an increase in the percentage of blocked traffic due to ad blockers and only expect this to grow as extensions, addons, and plugins expand to mobile. 

2. Browsers like Firefox are now blocking Adobe Analytics and other trackers by default.

3. Our product teams are moving toward single page apps.  Tag managers are more reliant on data layers especially as these sites move towards 'minified' classes.

5. We would like to enrich the data we send to Adobe with data not available to our clients at the time of data capture.

 

Much like a native app implementation, an Adobe server-side implementation currently is less flexibility than a datalayer/tag management implementation.  Given this I would like to provide the following ideas.

 

  1. Add the ability to 'kill' or 'delete' a server call.  There are always cases (i.e. bugs) where we may want to prevent data from hitting collection servers since it can't be deleted.
  2. Similar to the above, add the ability to 'approve' a server call before it can be sent to a 'production' report suite.  In this case, there would have to some identifier used to define a specific page or event.
  3. Add the ability to work with JSON, OBJECTS, ARRAYS, XML, or other standard forms of data.  This would provide analytics admins WAY MORE FLEXIBILITY to implement an analytics solution.  And it would reduce the effort required by developers and engineers to implement Adobe Analytics as they would not have to learn Adobe's syntax.  For example, the product string cannot be set or managed via processing rules.
  4. A UI refresh would definitely not hurt anyone.

 

Happy to chat if anyone is interested.

 

Thanks,

Michael

Comments

Vote history