Hi Team,
I have a requirement to display a banner/teaser once per session using a Profile Script in Adobe Target. This functionality is needed for multiple use cases.
Could you please provide guidance on how to implement this across the various use cases?
Thank you!
Best regards,
Devakrishna R S V
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
@DevakrishnaRa2 Sorry, try this instead - i was a bit too quick on the previous one:
// Profile script to control session-only display of a banner
if (user.sessionId != user.getLocal('sessionIdBannerShown')) {
// First time in this session, allow the banner to display
user.setLocal('sessionIdBannerShown', user.sessionId);
return false; // Indicates banner can be shown
} else {
// Banner has been shown already in this session
return true; // Indicates banner should not be shown again
}
Here's a quick demo of it in action: https://www.loom.com/share/db450c90641c4e8fa940b535b28a87f1?sid=32e84a1b-1beb-498e-a929-b3c33e06ed30
I think it should something like this:
// Profile script to control session-only display of a banner
if (user.sessionId !== profile.sessionIdBannerShown) {
// First time in this session, allow the banner to display
profile.sessionIdBannerShown = user.sessionId;
return false; // Indicates banner can be shown
} else {
// Banner has been shown already in this session
return true; // Indicates banner should not be shown again
}
Please note, that i haven't tested it.
In order to implement it, step 1) is to create the profile script. Step 2) is to create an audience which looks at the profile script (find it under visitor profile) and set it to contain/equal false. Step 3) apply this audience to your activity.
An alternative approach could be controlling it inside the experience by using a script and sessionStorage. You would apply this as custom code in the experience and you would then have to inject the banner as part of the script:
// Custom script to run in Adobe Target
if (!sessionStorage.getItem("bannerShown")) {
// Display the banner and set a flag
document.getElementById("your-banner-id").style.display = "block";
sessionStorage.setItem("bannerShown", "true");
} else {
// Hide the banner if already shown
document.getElementById("your-banner-id").style.display = "none";
}
Probably not optimal as you won't be able to exclude on audience level, but wanted to mention it anyway.
Thank you @kandersen ,
I tried the above code but it's not working any other suggestions, for implementing the scenario using profile scripts?
Note: we have integrated Target using WebSDK.
Regards,
Devakrishna R S V
@DevakrishnaRa2 Sorry, try this instead - i was a bit too quick on the previous one:
// Profile script to control session-only display of a banner
if (user.sessionId != user.getLocal('sessionIdBannerShown')) {
// First time in this session, allow the banner to display
user.setLocal('sessionIdBannerShown', user.sessionId);
return false; // Indicates banner can be shown
} else {
// Banner has been shown already in this session
return true; // Indicates banner should not be shown again
}
Here's a quick demo of it in action: https://www.loom.com/share/db450c90641c4e8fa940b535b28a87f1?sid=32e84a1b-1beb-498e-a929-b3c33e06ed30
thank you @kandersen ,
The code is working as expected and i have extended the session duration to 1 hour. However, when using the same audience across multiple activities, we are unable to see changes of one of the activities within the same session, as the profile state remains consistent. Is there a way to address this issue?
// Get the current timestamp in milliseconds
var currentTime = new Date().getTime();
// Retrieve the last visit timestamp from local storage
var lastVisitTime = user.getLocal('lastVisitTime');
// Define your custom session timeout (in milliseconds, e.g., 60 minutes = 3600000 ms)
var customTimeout = 60 * 60 * 1000;
// Check if the last visit time is undefined or if the custom session timeout has elapsed
if (!lastVisitTime || currentTime - lastVisitTime > customTimeout) {
// New session detected, update the last visit timestamp
user.setLocal('lastVisitTime', currentTime);
// Allow the banner to be shown
return false; // Indicates banner can be shown
} else {
// User is within the custom session timeout
return true; // Indicates banner should not be shown again
}
Views
Replies
Total Likes
Is it correct understood that the script works, and also works across multiple activities - except one activity?
Assuming that is the case, then it sounds like it is more a configuration of that specific activity, rather than the profile script. But I'm not sure if I've understood it correct?!
Views
Replies
Total Likes
Sorry @kandersen , if my statement have confused you, then let me put it in this way.
We have two separate activities—Activity1 for the homepage and Activity2 for the Contact Us page. Both activities use the same audience profile script, which we’ve configured to display a banner once per session. When a user visits the homepage (Activity1), they see the banner as expected. However, if they navigate to the Contact Us page (Activity2) within the same session, the banner does not appear there, as the session remains consistent.
This scenario is just one of several use cases where multiple activities rely on a once-per-session audience. We’re looking for a solution that would allow the "once per session" profile script to function individually per activity, enabling the banner to display in each new activity even within the same session.
Could you provide any recommendations for achieving this?
Views
Replies
Total Likes
@DevakrishnaRa2 If i understand it correct you would like to ensure the profile script is per activity. So that in your example, activity #2 should still be shown because it is a different activity.
In order to do this, the profile script would need to have access to which activity/experience is shown. This is possible, but isn't as simple - at least to my knowledge. Remember that profile scripts are designed to run globally and are processed before activity content is returned. By run time of the profile script there isn't anything related to what activity is returned. In the profile script you can use user.activeActivities, however, it is returning an array of all the activities the user is a part of and therefore wouldn't help.
The ideal approach is probably to pass the activityId or experienceId as an mbox parameter - this can be achieved by using Response Tokens, however, there will be a timing issue on the first page of the visit. But by combining Response Tokens mbox parameters and profile scripts you should be able to achieve what you're looking for.
I'm not sure whether your requirement is worth the effort of implementing a mbox parameter. The simplest way is creating multiple profile scripts that all does the same, but are used in different Audiences, which you then apply to the relevant activities. If it is for less than a handful of activities, I would most likely have taken this approach.
There might be people smarter than me who have a better way of achieving this - could be @Ryan_Roberts_ or @Gokul_Agiwal ?
Views
Replies
Total Likes
Hi @DevakrishnaRa2 Sorry, somehow I've missed this thread. However an interesting discussion here.
Thank you @kandersen sir - learnt something new again from you.
So @DevakrishnaRa2 - finally is this resolved? did you get a chance to work on your objectives to show the result "once per session".
If this still open and you're looking for answer then I would recommend you to check this blog from my friend @Rajneesh_Gautam_ which mainly talked about the concept called "Frequency Capping" and see some of the interesting discussion over there - that gives you direction to achieve this use case.
Tuesday Tech Bytes - The Art of Balance: Using Fre... - Adobe Experience League Community - 630903
Frequency capping is a technique used in digital marketing to limit the number of times a specific marketing message is shown to the same visitor within a defined time period. In simpler terms, it's about preventing your audience from being bombarded by the same experience over and over again.
Hope this helps and let us know once you implemented.
Thanks,
Views
Replies
Total Likes
Views
Likes
Replies