The user flow I have is as follows:
CTA is displayed on page > user clicks CTA> directed to privacy agreement page > agrees to the terms and conditions > directed to experience.
I do not have tracking for the last part of this journey, only up until they click agree.
Furthermore, once they have clicked 'agree' once, they will never need to do that again, so the next time they click the CTA they are directed straight to the experience.
Now I am trying to get an understanding of how many users are getting to the experience on a weekly basis.
But, I can't quite figure out how to design this segment. It won't just be clicks on the CTA, because that misses people who clicked on the CTA but didn't agree to the privacy rules.
It also won't be people who clicked the CTA AND agreed to the privacy terms, because that misses out people who have previously agreed and just get directed straight ahead to the experience. So, given my two components here:
1) Tracking clicks on the CTA, defined as link_name = special_offer30
2) Tracking users who complete the privacy agreement link_name = privacy_completed
How would I design this segment to account for both scenarios of:
1) First time clicking the CTA and has also agreed to the privacy conditions, so is directed to the experience and
2) Previously agreed to the privacy rules, so after clicking the CTA they are directed to the experience straight away
Views
Replies
Total Likes
The problem here is that Visitor segments only apply to the reporting time frame... so while you can create a segment that looks at the Visitor "agreeing", it will only return visitors who did do within your reporting window and not before.....
So let's say you are looking at "This Month" in your report, and the user agreed last month, they won't be included...
Now, you could try to use something like a non-expiring eVar (but this could be dangerous if the user later removes or loses their acceptance of the terms).
Since this is tied to a privacy agreement, surely your developers know the current state of the user... can you not work with them to grab the current state, instead of trying to rely on a past action?
Thanks for the suggestion, it definitely seems like this should be the case, as previously consented users don't see the privacy page popping up. I will investigate this route, but I am confused as to how I would include this in the dashboard itself, if not using a non-expiring evar?
Views
Replies
Total Likes
Not exactly the same, but on our sites we have login states and entitlement states... since either of these can change within the same visit...
i.e. not logged in > login page > successful login > navigate the site > logout
or
not entitled > go to sub page > purchase a subscription > navigate the site'
etc
I can't even rely on "visit" level attribution... now I know that some people for a user login would retain that user id for the entire visit, but we feel if a user manually logs out and the id is cleared, that we should also treat it as such.... (I can always apply custom attribution)
So for both of these states, I pull the data on each page (and retain it through any actions on that page).
Now to your situation, I would also be looking at pulling the "agreed" (or not agreed" state on the page, and not worry about attribution. You could even track an initial "unknown" state for before the user accepts or rejects the policy. Then in your reporting you could just create segmentation around hit with the accept state, or you could look at visits that have the accept state... or users that reject after accepting, or any combination of the above...
If the privacy screens are already in place, since you would be grabbing the "current state" on any page, users who have already gone through this will still have tracking because once you launch the tracking, the devs already know the state of the user and that can be tracked along with all the new users...
Views
Replies
Total Likes
Views
Likes
Replies