Once per visit never launches

‘Once per Visit’ operates as ‘Once per Session’, meaning that within the scope of a single PX session ID, the engagement will only launch once. So if the PX session in which you’re testing the engagement already includes a View event for that engagement, you won’t see the engagement again until you have a fresh session.

The shortcut is to use dev tools in your browser to locate and refresh the apt.sid cookie (for testing purposes). Application > Storage > Cookies in Chrome, then select the apt.sid cookie that corresponds to your product tag key, and click delete. On your next click, a fresh PX session and apt.sid cookie will auto-generate.

Once that new session is active, you should see your engagement again, assuming you meet the audience criteria.

It’s also worth noting that this cookie manipulation is not something that your end users will have to contend with. PX sessions will expire automatically after 30 minutes of inactivity. So in the normal course of product usage, your end users’ sessions should be regularly refreshing, requalifying them for ‘Once per Visit’ engagements. The cookie delete is just a way for you to quickly force the session refresh for yourself when testing live engagements.

Thanks for helping​@rschlette.

Deleting the apt.sid cookie (associated to your application’s domain) is a quick way to end a PX session, and the next PX-tracked event (page refresh/click) will create a new PX session.

You could also just open a new incognito browser window each time that you want to test this “once per session” Engagement to achieve the same.

The issue is the engagement never launches for any user when set to Once per visit. I am thinking it might be related to the scope qualifications. My theory is there are not enough specifics in the qualifications to show the engagement, so it looks for the right place to show the engagement, and then doesn’t show it as it is not finding the linked element. Is that possible? I tried to watch for logs in the console, but I am not seeing them.

There’s a lot of stuff that could be happening, but insufficient audience logic is unlikely. I think Admin Console will be your friend in this case.

Here’s how I would troubleshoot:

1. Verify that the engagement is Active in the environment you’re testing in
2. Verify that your test user meets all of the audience logic criteria
3. In a fresh session (as described above), open the dev tools network log before navigating to where the engagement should launch. Upon the action (url change or click) that is intended to trigger the engagement, you should see 2 requests to the JavaScript SDK. One will be the ‘command’ request that sends the url and/or click data to PX. The other will be the ‘inapp’ request that reflects the evaluation for PX engagements. If the response status for the ‘inapp’ request is 200, the user qualified for the engagement; if the response is 204, the user did not meet any active audience logic in that environment (or they have been disqualified by engagement throttling).

IF the response status for the ‘inapp’ request is 200:

1. go to  Admin Console  and check the Engagement Monitoring tab for errors like ‘mapped element not found’
2. if there are no errors, double check the Collisions tab for competition, but you’ll have seen another engagement if that was the issue

IF the response status for the ‘inapp’ request is 204:

1. make sure Engagement Throttling isn’t preventing the view event
2. double check that the test user’s User Preferences aren’t set to disable engagements

If get through all of that without surfacing the issue, open a PX support ticket and the team can step through the above with you on a call