Expand my Community achievements bar.

Find the most recent value of an evar/prop

Avatar

Level 3

Hi, 
I received this question: 'We have clients using our App and we want to know what is most recent version used, so we know what can be decommissioned'

In the tagging of our App, we capture the App version in each call send.
And it look like this:

robinl39529461_0-1714050871345.png

The total of unique visitors is ok but with a breakdown on App version, the sum exceeds the total because a visitor can have multiple App version due to historical total.
So how to find the most recent ones?

 

I think I found a way by creating a segment to filter the data (based on this doc: https://experienceleague.adobe.com/en/docs/analytics/components/segmentation/segmentation-workflow/s... Part about 'Only Before Sequence and Only After Sequence') for which I'd like to have your advice.
So example of the data I can have about a visitor:

robinl39529461_2-1714051463036.png

 

But as I don't know in advance what will be the value of the dimension App version, I will play with 'App Version exists' to have a common value.
So the data will be interpreted like this:

robinl39529461_3-1714051547890.png

And what I want to have is the last info of my session 3.

 

So by creating a segment with the condition App version exists and playing with the info After/Before sequence, it's something that seems feasible.
Ex:

robinl39529461_4-1714051950693.png

As 'Only before sequence' is doing the opposite of what I want, I can invert it with an exclusion to isolate the value I want (in grey above).
So the segment will look like this:

robinl39529461_5-1714052240052.png

By looking to a specific visitor (here the marketing cloud ID), it seems to work: only the most recent occurence of the most recent session (visit number) is part of the segment:

robinl39529461_6-1714052371311.png

 

And so, only the most recent 'App version' info:

robinl39529461_9-1714053025540.png

 

 

And the final result:

robinl39529461_8-1714052915750.png

Same total amount but with different figures in the breakdown. 

 

Does it sounds logical to you ?

If yes, I hope it can help others.
If not, please shoot to help.

 

Thanks for your help.

 

Robin

 

 

 

 

4 Replies

Avatar

Community Advisor

How about this:

  1. Remove all of your segments and leave behind your original report showing the App Version and Unique Visitors.
  2. Change your report's date range to the last 30 days, or a slightly longer/shorter date range as desired.
  3. Run the report.

My reason for doing this is based on the original question: "...we want to know what is most recent version used..." I've bolded "most recent" because that, to me, means they want to know the app version that people are using now or close to now, and they don't care about the combinations of app versions that people are using over their lifetimes.

Avatar

Level 3

Thanks for your comment
Yes, but with this I have 2 issues:

- what if the user didn't log in the last 30 days?

- what if user made an update in the last 30 days, it will be counted more than one time

 

But you are right, my question is maybe confusing.
It should be: "What is most recent version used for each visitor?"

Thanks for your reply

Avatar

Community Advisor

Do you need a report that covers all of your unique visitors? I personally think that I would be comfortable with a report that covers the majority (eg >85%) of unique visitors.

Also, if a user made an app update, then that means the older version can be decommissioned, right? So again, you only need to know what is the most recent, last used app version, without any regard for the previous version.

Avatar

Community Advisor and Adobe Champion

I agree, if a user isn't really an "active" user, how important is it that you know the last version used if it was from months ago?

 

We tend to look at our app traffic even more simply... first off, we will look at simple page views over the last 30 days by version to get a basic usage report, and we can use a line graph to see the top versions over time to see how the usage falls off for older versions, and grows for newer versions.


We can also do this by UVs.

 

If you are looking at the top 5 versions, and the lowest of that is already at a "safe" level of saturation to decommission, then the versions below that would also be safe. If your top 5 are all too large, then you can look at the next 5, or 5 after that...  basically find what you want to deem your cutoff point in recent traffic.

 

We know that some users will have updated in those 30 days, that's where the graph shows us the where old versions fall off and new versions pick up.

 

 

Ultimately though, a lot of decisions about what versions to decommission come from what features have been rolled out, or compatibility with the app stores... When SDKs become too old, the app stores will start to complain, those versions, regardless of users have to go since they are preventing us from complying with standards.

 

We tend to let older versions run far longer than they probably should...  but if you are doing cleanup, I don't think you need to make it complicated... users on older versions of the app should be prompted to update I believe.