Skip to main content

Filter by idea status

10000+ Ideas

Processing Rules: Add Events to the line item conditionsNew

With the release of Processing Rules where all Admins have the ability to leverage processing rules to increase their data accuracy and completeness, it would extremely helpful if we added Events to the line item conditions.Use Case - We currently have a DTM Javascript heavy based implementation of Adobe Analytics and have been working with our IT department to reduce the size of both the JS files (DTM's satelliteLib and AA's s_code) as well as reduce the size of the client side beacon calls / hits to the Adobe servers.we are looking for ways to achieve these size reduces without sacrificing our tracking / metrics capabilities.  so we thought processing Rules would be a great place to start, as we can set our metrics and define our props/evars based on the end user's URL and the Defined Page Name.Since this is a migration strategy and not a new install, we have to use conditions like set prop14 = name when prop14 is not set.  which means processing rules are simply filling in the gaps when the information is missing.but when it comes to setting events there is no 'when' option.  So we can't say set event100 when event100 is not set.  the 'when' statement seems to be limited to just props and evars.  Currently when you use this set event options it will set the event regardless of what events are already there so if you have it both in the javascript and the processing rule the event gets counted twice, obviously that is not accurate.because of this limitation we are limited in our ability to reduce our dependency on the client side javascript and a large percentage of the data we send to Adobe, especially since Adobe has given everyone 1000 events to set within their properties, are individual events for each page and user action.so it would super helpful if we could add events to the 'when x is not set' conditions in the processing rule line items.  this would enable customers to set events or to fill in events gaps when the javascript happens to miss them.

emcgallLevel 2

Give Clients the Ability to Align Classifications Across Multiple Report SuitesNew

We have 38 actively used report suites.  Classifications require back end div IDs to be aligned across all 38 in order to create a classification on a variable. When one report suite is misaligned, there is no way to easily identify which report suite is misaligned or to update all report suites with new classification or div values at the same time. You would need to manually click through all report suites to identify the delta, delete, and realign. ALL manually.Occasionally as well, you may have a report suite with the same friendly named classifications, but the back end div IDs could be out of sync depending on how they were created in the past.  There is no way to see the div IDs in the client facing UI to know which one is misaligned. Again, the only way to correct this is to delete all classifications in all report suites and start over. I would LOVE to see new functionality in this area of the admin UI.  Something similar to processing rules where you can work in one report suite and copy to multiple report suites would be ideal, or at the very least exposing the div IDs and a difference view across report suites (similar to the variable portion of the UI where you can click on "multiple" to see the differences by report suite).For all our report suites, length of time our account has been around, and amount of classifications we use, this would be a HUGE time saver for us and client care.Thanks,Erin

adarshsLevel 2

A4T issue: Page URL report where Target activities exists [Incident: 181220-000198]New

REQUIREMENT:Report the personalized pages where the Target activities are running.SITECATALYST REPORT:To pull the list of Personalized pages, we used the following conditionsDimension - “Page URL CC - v38”Segment 1 – “Target Activities exists” to exclude non-personalized pagesSegment 2 -   Excluded the activities “PROD_0701_NAPR_US_TCMS_ARSW_MUL_XT_HOME” and “PROD  || POC -  LPV profile script - OMNI-825” in the segment by using “exclude container”. Those 2 activities are not related to PZN campaigns.Report Link : https://sc5.omniture.com/x/5_7pnd6Issue Noted: Non-Personalized pages are listed in the reporting line items. E.g.https://blogs.vmware.com/euc/2018/10/infographic-android-enterprise.html & https://www.vmware.com/site_maintenance.htmlREQUESTED ADOBE CLIENT CARE SUPPORTAdobe Incident 1: 181015-000031As per Incident: 181015-000031, due to hash collision the non-personalized pages are appearing in v38 report. Solution proposed by client care is increasing the unique values of prop38/ evar 38 unique variable to 1M from 550k.Adobe Incident 2: 181105-000067Extending the variables limits from 550K to 1MAdobe Incident 3: 181220-000198==============Issue: Non-personalized pages still in v38 report after fixing the hash collision issueCo-ordinated with support team to understand why non-personalized pages are appearing in v38 report after increasing the unique limit for evar38 and prop38 to overcome hash collision issue.Adobe Response: Non-Personalized pages for evar38 / Prop 38 are returning in the reports even though it does not qualify the segment condition is because of hash collision. Recommendation provided by adobe support team doesn’t help us to meet the reporting requirements.souhardahn​,