Evar and filters

[VirginieRe2]

On my site users are able to use filters to filter products by color, size, price etc...

Currently, each time a user checks a filter, the page reloads and an evar is set with the value of the filter.

For example : evar10 = `color`(if the user filtered by color) or evar10=`size` (if the user filtered by size)

The evar allocation is original (first) and expiration is set to visit.

Now, I am not sure if this implementation meets my needs.

I want to be able to know how many page views loaded with evar10 set to `size`as opposed to `color``.

There are no events fired along with the evar.

If a user, in the same session, activates multiple filters, for example `color`, then `size`...is that correct that, because of the evar allocation set to original, the second filter selected would NOT show in my reports?

[MandyGeorge]

It depends on what you're using as your success event. If someone uses colour, then size, then places an order, if your attribution is first touch and your success event is orders, then yes, only colour would be given credit. But if you're using a metric such as "page views" or the evar instances metric, you would see both of them, because each page view has a different value, so each value would get credit for the page it was seen on. It's the same case for the evar instances metric. That tells you the number of times the evar fired, so it will show you that for each of the values. 

[VirginieRe2]

What if my page url and page name stayed the same, regardless of the filter used? 

Would I still see both evar values if i built a report with evar as a dimension and evar instances as a metric?

[Jennifer_Dungan]

As Mandy said, you are right... with an allocation of "original (first)"... within the visit, the eVar will always return the first value it sees... so:

• Page 1
  • eVar10 set to "color"
• Page 2
  • eVar10 retains value "color"
• Page 3
  • eVar10 set to "size" (Adobe will still defer to "color" as the original value)
• Page 4
  • eVar10 retains value "color"

The next question I have to ask is, does the user keep building onto the filters? Or replacing them?

In the scenario above, on Page 3, when the user adds a size filter, are the results now only based on size? Or based on color and size?

I am trying to ensure that we are looking at the bigger picture, as well as the one you asked about... This might be a candidate for using a list variable, where you can pass multiple values based on all the filter criteria.

Also, your statement:

There are no events fired along with the evar.

---

Isn't strictly true... you don't have a custom event being set, but every time an eVar is set, there is a standard Adobe event for that eVar that is also triggered... this is called the eVar Instance metric. So if your eVar10 is called "Filter Option" then the corresponding metric will be called "Filter Option Instances".

Using the same scenario above, here is where those events will be included:

• Page 1
  • eVar10 set to "color"
  • eVar10 Instance event triggered
• Page 2
  • eVar10 retains value "color"
• Page 3
  • eVar10 set to "size" (Adobe will still defer to "color" as the original value)
  • As I never use Original Allocation, I am not sure if eVar10 will be set here, I suspect that it won't as the value is being ignored
• Page 4
  • eVar10 retains value "color"

These Instance metrics are only visible in post-processed data, which is why you don't see them when testing your tracking implementation.

Anyway, given your description, I think you probably want Last allocation, whether the filters are replaced or appended... I think the last option used makes more sense...  and if the list is appended, using a list to pass both "color" and "size" gives you that much more information.

[VirginieRe2]

Thanks! this is helpful.
To answer your question, the filters keeps building...so as you add more filters, there is a new parameter added to the query string but only one evar.

I had no idea about this: "Isn't strictly true... you don't have a custom event being set, but every time an eVar is set, there is a standard Adobe event for that eVar that is also triggered... this is called the eVar Instance metric. So if your eVar10 is called "Filter Option" then the corresponding metric will be called "Filter Option Instances".

This is very helpful to know that. 

I have tried in the past to build a segment for a page where an evar was set (and not for a page where an evar persisted from a previous page and therefore sill existed)?

So my segment was a hit container where evarXYZ existed.

However, based on the results, it seems to me that it was showing me all hits where the evar was either set on the page OR all hits where the evar was present because it persisted from a previous page..

Would using the evar instance metric be a solution to isole hits where an evar was set? (hit container where evarXYZ instances exists)

[Jennifer_Dungan · Accepted solution]

Ah,so basically, if the user does color then size, you will get eVar10="color,size"... but if they do the opposite, size then color, you will get eVar10="size,color"

		Page Views
eVar10		4
	color	1
	color,size	1
	size	1
	size,color	1

This is good if the order of operation is important, cause you can see it at a glance... but it does mean a lot more diverse data as these will count against separate rows... and the more filter options you have, the more variations you could end up with.

A list variable is useful because it keeps each item a separate row, so if you have colour > color,size > size > size,color; you will get:

		Page Views
list1		4
	color	3
	size	3

Both method have merit, just proposing an option you might not have considered.

---

I have tried in the past to build a segment for a page where an evar was set (and not for a page where an evar persisted from a previous page and therefore sill existed)?

So my segment was a hit container where evarXYZ existed.

However, based on the results, it seems to me that it was showing me all hits where the evar was either set on the page OR all hits where the evar was present because it persisted from a previous page..

Would using the evar instance metric be a solution to isole hits where an evar was set? (hit container where evarXYZ instances exists)

---

This is exactly right! There are two ways to do this... you can leverage the Instance Metric directly:

Or, you can use the gear on your eVar to set behaviours:

Repeating is the default, this means it will return all the hits where the eVar equals the value (whether explicitly set, or persisted)

Instance will only return the hits where the value was explicitly set (i.e. eVar10="x")

Non-Repeating Instance is interesting, it will return the instances of where the value was set, unless the same value was set in a row, it will exclude the repeats.... for example:

• Page 1 - eVar10="x"
• Page 2 - eVar10="x"
• Page 3 - eVar10 persisted value of "x"
• Page 4 - eVar10="y"
• Page 5 - eVar10="x"

Pages 1 and 5 will be returned, but page 2, despite being an instance, will be ignored because the previous value was also "x" and therefore it repeats. I believe, that if the value is set again after a persisted (i.e. set, persisted, set again to the same value) that this second instance might be ignored... I don't use the too often... I know where I have values set, and where they are persisted, and mostly I just want all or instances... 

Hope this helps!

[VirginieRe2]

Yes, it is very helpful!!

[gautham_madala]

Instead of eVars why dont you use props ? 

Props (traffic variables) are hit-based, so they record the value exactly at the time the page loads. This makes them ideal for your use case: tracking how many page views had filters like color, size, price, etc. applied.

s.prop10 = 'color|size';
Split the string in Adobe Analysis Workspace using classification or calculated metrics.

[Jennifer_Dungan]

Not a bad idea, assuming they aren't at risk of having the values truncated... I use eVars (with a Hit expiry) in lieu of props all the time, to get around the 100 character limit in props.

Given the ever growing list of values, if all filters are eventually selected, this could very easily exceed the character limit of a prop.

[Jennifer_Dungan]

One more thing... splitting this with classifications wouldn't work well... at least not without some prefix for each value (which would use even more characters, risking truncation even sooner)... since there is no defined order... unless you are just using generic buckets like "first", "second", "third", etc... but that would make the information really hard to use effectively since "color" could be in any of the buckets....

Or you would have to have a placeholder in each position for each possible filter option (i.e. "na|na|color|na|size....") and then you will always have a value set even when no filters are in use....

[gautham_madala]

Agreed!  definitely some limitations. It totally depends on the use case and character limit and which implementation style you wanna do, so Trying different approaches could work. 

[Jennifer_Dungan]

Yes, and this might kick off some additional needs and discovery into the implementation... 

[Josh__Stephens]

Adding more to the eVar party! 🥳 If you want to determine which filters were used for specific products that were ordered, you can use Merchandising eVars & finding methods. This lets you tie specific eVars to specific products. If an order is placed with multiple products, each one can be attributed to the value that influenced that particular product.