Regarding counter type eVars and how to use them

[Sebastiane_Edberg_]

Hi community, regarding counter evars, short use case: increment a counter evar by 1 if a user swipes a menu either to the left or right in mobile view. It has been setup with two different direct calls (for swipe direction left or right) and each time the respective evar is incremented by 1, (in custom code s.evarX = "+1"). 
Now the idea is to use these two evars and breakdown visitors in containers based on how much they swipe. 
First of, if this evar is dropped on a freeform table the "occurences" column will show how many times that evar was incremented by 1 during the selected timespan right? By doing that we see a reasonable amount of occurences on mobile devices at least.
The problem arises when trying to make a segment that for example says that if the value of the evar for a mobile device visit is greater than 10 (the user swiped more than 10 times), no matter what the segment builder cant seem to find any visitors where there´s even a value exists in these evars, so what have we missed?

 

[Jacob-DDdev · Accepted solution]

Hi @Sebastiane_Edberg_ ,

Not sure if occurrences is sufficient for the use you are mentioning unless you are sure to set the evar to expire on each hit.

As an alternative, to reduce evars and allow cleaner reporting, have you considered just one evar for direction and then an event for when someone has swiped in the app? Then it would look like dragging a single evar onto a table with a breakdown of "Left" vs "Right" and a specifically named metric just for app swipes.

In fact, you could avoid adding any evars by sticking the direction into another evar with information on the page/panel being viewed. That is, if they swiped right from page 3 to page 2, a developer could put into a pagename variable the value of "Page2<delimiter>R", or if someone swiped left from page 4 to page 5 "Page5<delimiter>L". Then using classifications on this variable, you could break it apart at the delimiter for normal reporting. So the left side of the delimiter can be grouped into a classified pagename and the right can be classified into a swipe direction variable.

[Sebastiane_Edberg_]

Hi, thanks for replying, i might have missed something important here, hope you can help me understand. The evars are set to expire after visit, wouldnt that mean that the evar value for a visitor that swipes 10 times would be 10 for that visit? As it is incremented by +1 each swipe? Or maybe that is not how the counter evar type works?

[Jacob-DDdev]

Hi @Sebastiane_Edberg_ , looks like I was somewhat incorrect in my statement: Given that counter evars are meant to be used against success events, they should, in-fact, be visit based. It does mean that on your development/tagging side, you should be certain that the evar is cleared before sending successive beacons. That is, if someone swipes, send a beacon with the "+1" value for the counter evar, but if they do anything else on the screen that would trigger a beacon, it is important that that value of "+1" is cleared.

Related to my other comments, this is a very heavy use of an evar and may be excessive unless you implementation has many to spare and/or swiping is something you suspect contributes significantly to the success event. If you just need to know, within a timeframe/visit how many swipes and how many success events occurred, there are options to leave a smaller footprint, but if you specifically wanted to know the number of right swipes before a success event or the number of left swipes before a success event then your method sounds correct.

Regarding your questions:

1. Occurrences wouldn't necessarily be correct unless the variable expired on a hit, ref, since the counter evar would need to persist to be attributed to success events. Instead you will want to use "Instances of ..." which should exist for all enabled evars including the counter evar.

2. Do you just mean that no one is swiping more than 10 times or that any segment based on any number isn't working? Also, are your segments set to include "visit"?

[Sebastiane_Edberg_]

Hi again, im not really friends with this counter evar, mainly because i feel maybe i dont fully grasp the concept. Given how the solution is described, eg everty time a swipe occurs the tracking beacon sends the incremental +1 value to the evar, shouldnt i be able to find a visit based on the total value of this evar (value here being the sum of swipes +1 occuring during the visit) after the visit expires? The evar is set to counter and expires after visit. What am I missing

[Jacob-DDdev]

So my team doesn't use very many counter evars either (I'd be hard pressed to find a current example, but I know they exist). As is the nature of any visit-based evar, their convenience is their ability to tie-out to events/metrics that don't necessarily happen on the same hit. So if you had a specific success event you would be able to find all the visits that had X swipes leading up to that event, but it is only tied to the event in consideration.

Consider this example:

You have a swipe-based, counter evar and two success events (maybe event1 is registering an account and event 2 is purchasing an item). The user swipes twice before registering, 4 more times before they purchase something, and then the swipe 8 more times, then triggers a click beacon without swiping, and finally their visit expires. In Workspace, you could select the evar as the dimension with the metrics "Occurances","Instances of <that evar>", event1, and event2. If this was the only user, it may display something similar to

evar	Occurances	Instances of	event1	event2
2	1	0	1	0
6	1	0	0	1
14	2 (an extra value from the click tracking that wasn't a swipe)	1	0	0

So it is the same user, but you can't necessarily create a segment for the user's whole visit off the evar alone.

It looks like there is discussion of something that would solve your reporting requirement here:

https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/report-only-the-maximum-v...

[Sebastiane_Edberg_]

thanks for all the extensive info in your posts so far, the problem for me seems to be more on the reporting part so i'll have another go at workspace