I am new to processing rules and trying to find some good source for understanding. First of all trying to understand differences between processing rule, vista and classification. I also read somewhere that many stopped using processing rule. Is it true?
Any help on this would be appreciated.
The first thing is to understand the order in which your tags are processed.
1. Site Tags / Mobile App Context Variables
2. Processing Rules (still very much relevant to tagging needs, particularly when it comes to mobile apps)
3. Vista Rules (these have to be set up by Adobe and come with additional cost to configure)
4. Classifications (these can be used in a non-destructive way to apply values on top of your stored data)
Your actual tagging step should be pretty straight forward. You set your props, eVars, events, etc. In an ideal implementation, you are correct in thinking that maybe Processing Rules and Vista rules aren't needed... but IF you are doing mobile app tracking... you can't actually set the props, evars, etc directly. Some items, yes, would be set directly.. but for the most part you will want to send context variables to Adobe, then use your processing rules to set them.
After your tags, this is where processing rules fall into place. This is primary where I use processing rules.. to map my context variables to actual prop/eVar data for our mobile apps. I also use this to set some rules based on User Agent, this way I don't have to try and get the rules for web (Adobe Launch that I control), AMP Pages (which developers control), Mobile Apps, etc all coordinated... I can just set one processing rule and it works consistently for all the variants.
There is a word of caution here: Processing Rules change the values of your data, so make sure that any rules you set up are fully tested before adding them to production.
Vista Rules are similar to Processing Rules, but I believe there is most control that can be applied (as well as manipulating data to send to multiple suites - as in I could have a value in eVar1 in Suite A, that uses Vista Rules to manipulate the value in some way and sent to eVar2 in Suite B for example). Vista Rules are controlled by Adobe Support and I believe the setup of such rules have a cost associated to them.
Both Processing Rules and Vista Rules change the data that is stored in your reports.
The last part is classifications.. Classifications allow you to create (for lack of a better term) "sub-props" or "sub-eVars". Essentially, the data as recorded in your prop/eVars remains as is, but you can create rules to map different/more readable/parsed out values based on the originally recorded values... These also aren't permanent... the data is processed every 4-6 hours, and IF something doesn't work as you expect it to, you can change the rules and reprocess up to 6 months of back data.
To give examples... maybe someone in your marketing team is using some UTM values which are coded (bfs_123 for "black friday sale" and the 123 is tied to a specific date range or product). You can create Classification Rules (using the classification rule builder, if you have only a few specific rules that you are looking for; or if there are hundreds of permutations you can use the classification rule importer which allows you to create large scale mappings based on a csv file).
Or maybe you are getting really diverse values in your UTM Sources... like "facebook", "facebook.com", "fb", fbook", facebok", etc ... you may have to keep tabs on the variations, but you could create some rules on this to create a classification for "facebook" so that it's easier to pull reports.
The other thing that classifications are good for is to send multiple pieces of information all together in one proper or evar like "value 1|value 2|value 3|value 4"... you can use regex rules in your classification rule builder to extract the first part "value 1" and give it a classification dimension "something A", and extract the second value "value 2" and give it a classification dimension "something else", etc (obviously you would call "something A" and "something else" appropriate names based on the type of data you are collecting... I use this method for internal search functionality, tracking the page number, number of results per page, number of total results returned and sort order. So I can minimize the number of dimensions being used, but still have each of these values in separate usable dimensions that I can correlate and use in more advanced reporting.
I hope this helps
First Question:
Now coming to classification rule builder whatever rule we build will it take effect on existing data ? Also what will happen if I delete an existing rule in classification rule builder?
This is correct. When you create a classification, there is a "lookback window" that will default to 1 month, but can be extended to 6 months. Each time you modify or delete a rule, the classifications will "deactivate".. when you reactivate them they will need to reprocess (it will warn you that processing can take up to 24 hours).
Technically speaking, you won't actually affect the value in your prop/eVar. It will be treated like a sub-prop or sub-eVar (or rather... kind of like a "Virtual" dimension, instead of a virtual suite)
For instance, let's use your example and pretend this is stored in eVar1.
eVar1 has the following values:
product details: x
product details: y
product details: z
When you create a classification, you must first set up a classification for it (this is what will hold the new value). Then create rules to point to that classification (only values driven by the parent classification can actually be set into it).
You can even correlate the original eVar or Prop to the classification that you created. This also helps to troubleshoot potential issues in your classification rules is something comes out as an unexpected value.
In the example I used from my own use above, my Search Results data, I configured the following classifications:
So my "main" prop/eVar will always hold the originally tracked value. The classifications I set up will hold the values specified by my rules.
prop10 for me would have values like:
1|25|2565|date_desc (page 1 | 25 items per page | 2565 results returned | date desc order)
1|25|366|date_asc (page 1 | 25 items per page | 366 results returned | date asc order)
2|25|552|rel (page 2 | 25 items per page | 552 results returned | ordered by relevance)
These values will always be available to me... but in my classifications, I get the extracted values based on regex rules extracting them for the position.
This way I can see how many people are getting to page 2 or page 3, etc easier than creating a segment on "starts with 1| or 2|".. and since segments don't really allow for regex rules, extracting the rest of the info would be tricky, but having the classifications do it for me, allows me to use only one tracking param in our site, but leverage multiple correlatable dimensions in my reports.
If I look at my available dimensions in Workspace, I can see my original prop10, and the Entries/Exits dimension that goes along with it... but then I can also see all my classifications (along with their Entries/Exits)... you will notice on the real dimension, I can see the "(prop10)", but on the classifications you instead see the name of the prop/eVar in the ( ) next to it.
All of these should return if you search for "propX" or "eVarY", but it also may not hurt to add a reference in the name or description back to the original dimension.
It should be noted, IF your company is using Raw Data Feeds, classifications will not be included... as these values aren't processed immediately, and they can be changed at any time by changes to the Classification rules - they aren't "locked in" so to speak. I don't believe they are available in Data Warehouse exports either...
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
