SOLVED
Build a Segment Based off Visitors' Most Recent eVar Value
1 Accepted Solution
Correct answer by
So this solution might seem a bit crazy.. but you have 2 values "opt-in" and "opt-out", and the user can change their value at any time.. so if you want to pull back UVs where the last value collected was "opt-in", you can do so with a calculated metric:
Using the IF function, you can use custom attribution on the "eVarX Instance" for "Last Touch | 30 Days" (or whatever period you need)
and a segment looking at eVarX equals "opt-in", if true, then return UVs metric, otherwise, return a static value of 0:
You can change the attribution of the metric here by clicking on the gear:
This way you can get the last touch for a specific value (i.e. opt-in)
If you just use the attribution model directly in the freeform, depending on your breakdown dimension, you could still be getting previous values as they were the "last value set on that dimension"... so you need to be careful that you aren't getting inflated values...
Those last touch attributions are great when you are looking at things like purchase conversions... but you are trying to get a sense of the current opt-in rate, and that complicates matters.
Correct answer by
So this solution might seem a bit crazy.. but you have 2 values "opt-in" and "opt-out", and the user can change their value at any time.. so if you want to pull back UVs where the last value collected was "opt-in", you can do so with a calculated metric:
Using the IF function, you can use custom attribution on the "eVarX Instance" for "Last Touch | 30 Days" (or whatever period you need)
and a segment looking at eVarX equals "opt-in", if true, then return UVs metric, otherwise, return a static value of 0:
You can change the attribution of the metric here by clicking on the gear:
This way you can get the last touch for a specific value (i.e. opt-in)
If you just use the attribution model directly in the freeform, depending on your breakdown dimension, you could still be getting previous values as they were the "last value set on that dimension"... so you need to be careful that you aren't getting inflated values...
Those last touch attributions are great when you are looking at things like purchase conversions... but you are trying to get a sense of the current opt-in rate, and that complicates matters.
Thank you for the continued effort. Also, I was just comparing the calculated metric to total unique visitors, and they have the same value. It appears to me that the metric tests if any visitor's last selection is opt-in, and then returns all unique visitors, whereas we want the sum of currently opted-in visitors.
We've had the cookie category eVars for a little more than a month - there should be at least a handful of visitors who have opted in and out, even if they're members of my team. I also tried @jeff_bloomer's second suggestion (Attribution panel), but I'm not sure that I'm setting it up or interpreting the data properly. The amount of last touch | visitor cookie instances is greater than the amount of unique visitors; ideally they'd be matching or close to matching. I may have to try Jeff's first suggestion (reconfiguring the eVar), though I'll have to convince some team members, so I'd prefer to exhaust other methods first.
I believe that's correct. I've only seen it that you can use segments in calculated metrics, but not the other way around.
Jeff Bloomer
Hi @bhutton!
This is definitely a fun question, and I mean that honestly. I believe this can be tackled in a number of ways.
First off, you could have your eVar expiration for the cookie variable categories tied into a secondary variable, which would happen each time the customer updated their opt-in/opt-out status.
Second, you could then use ATTRIBUTION, to then manage your your reporting against said eVars to then understand how these values are being set.
https://experienceleague.adobe.com/docs/analytics-learn/tutorials/analysis-workspace/using-panels/un...
Jeff Bloomer
AH! Looks like my post got delayed in the page load earlier. All of a sudden I'm seeing 8 responses from Jen above mine. This is what happens when your computer decides to lag way behind in between policy updates and security patches. I should know better than to try and do this when all that is going on behind the scenes.
Jeff Bloomer
Try a sequential "visitor" segment using non-repeating instances your dimension (with "Only after sequence" applied to the segment). Most* of the data in the dimension report should be the "last one in" in the date range you have selected.
*It's "most" but not "all" because any additional opt-in/out selections made after the first opt-out>opt-in pair will all be returned for that visitor in this segment, but I can't imagine that very many people would do that.
Yep, I agree my original segment is imperfect. As I mentioned, additional opt-in/out selections made after the first opt-out>opt-in pair will all be returned for that visitor in my original segment. @bhutton here's an updated segment that I think will give you what you're looking for:
Change the segment to a "hit" segment and add two "visitor" containers (with an "AND" between the two containers).
- The first container is an "only after sequence" visitor container containing "Onetrust Function Cookies equals 'functional cookies = off'" THEN "Onetrust Function Cookies equals 'functional cookies = on'". This container in the segment matches the underlined portion of this sequence: A > A > B > B > B > A > A
- Note: The "non-repeating" portion of my original segment wasn't actually needed, so I've removed that setting in this updated segment.
- The second container is an "only before sequence" visitor "Exclude" container containing "Day exists" THEN "Onetrust Function Cookies exists". This container in the segment matches and excludes all but the last "Onetrust Function Cookies exists" hit for the visitor:
A> A > B > B > B > A >A- Shoutout to @Urs_Boller who I shameless stole the concept for this second container from in his accepted solution to a question posted years ago.
The combination of these two containers in a "hit" segment should return the last "Onetrust Function Cookies" value within visitors that selected opt-out then opt-in at any time within your selected date range.
For me, the key to understanding how each of these sequential segment containers work is the fact that the "only after sequence" and "only before sequence" settings names are a bit misleading (at best) because they also return one of the hits within the matching sequence.
- The "only after sequence" setting actually returns data starting with and including the last hit in the FIRST sequence match and all the data after that hit (including any other matching sequences after the first sequence match)
- The "only before sequence" setting actually returns data starting with and including the first hit in the LAST sequence match and all the data before that hit (including any other matching sequences before the last sequence match)
@philschmidt @Jennifer_Dungan I've tried troubleshooting this and I think it more accurately describes "Visitors formerly opted out and currently opted in". In order to test it, I created another segment with the order reversed - "Visitors formerly opted in and currently opted out". They unfortunately have 12 visitors in common, so I have a some more tweaking to try.
Another point of confusion is that some of the VisIDs showing up in common between the segments only have an opt-in or opt-out on record, not both.
After these are squared away, I should be able to use them with [OR (Currently Opted In AND Never Opted Out)] to get the original ask of the whole Currently Opted In segment, and then iterate for opt-out and the other categories.
