Hi everyone,
I am trying to implement a personalization use case for users who have visited a specific Product Detail Page (PDP) at least 3 times during the same visit.
I created the audience in Adobe Analytics via the Segment Builder, published it to the Experience Cloud, and selected it in Adobe Target. However, after testing and waiting for the processing time, the user is not qualifying for the activity.
Here is my current setup:
1. Adobe Analytics Segment Configuration:
Goal: Target users who view the same URL 3 times in a single session.
Definition: I am using the (vX) s.pageName dimension with the condition contains /selected-url/.
Implemented Logic: To attempt to capture the "3 times" frequency, I stacked the same condition 3 times using the "AND" operator.
Container/Scope: Visit.
Publishing: The option "Publish this segment to the Experience Cloud" is checked.
2. Adobe Target Configuration:
The audience is selected in the Activity.
The activity is active (Live).
3. Testing Methodology:
I performed the navigation actions in a standard browser window (not incognito) to ensure the ECID was preserved.
I navigated to the specific URL mentioned above 3 separate times within the same visit.
I verified in the Adobe Experience Platform Debugger that the variable v1 is firing correctly on each view.
I waited more than 24 hours after the navigation to account for backend processing time, then returned to the site using the same browser/cookies to check for qualification.
4. Result / Issue: The user does not qualify for the experience.
Question:
Beyond solving this specific use case, my goal is to fully understand the internal mechanics when a segment is published to the Experience Cloud. I have specific questions regarding the architecture:
Latency and Processing: What actually happens on the backend when a segment is shared? Is it technically possible for an Analytics segment to activate an audience in Target within the same visit, or is the latency inevitable due to batch processing?
IDs and Synchronization: Does the speed or reliability of activation change if we base the segment on an ID eVar (Customer ID) instead of relying on the standard ECID/Visitor ID?
Sequential vs. Boolean Logic: To count frequency, how does the backend interpret the repetition of "AND" rules? Is it necessary to strictly use sequential segmentation ("THEN") for the system to recognize distinct hits, or is the issue purely related to propagation timing?
Any technical explanation to help me fully internalize this data flow between AA and Target would be greatly appreciated.
Thanks!
Solved! Go to Solution.
Views
Replies
Total Likes
Yes, client care would be the next step... but you might end up waiting a few weeks for something simple that the Target users might know what the issue is...
Check every potential source of help that you can!
Views
Replies
Total Likes
Analytics segments when published to experience cloud from analysis workpsace reaches to Target but note that there is a latency of 24 to 48 hours as it is a batch processing. qualification happens after data processing, not during the visit.
https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-16471
I would recommend for this type of use case (frequency based, same session personalization), Target profile attributes are the best approach. Target updates profile attributes near real time when the visitor interacts with the site & unlike Analytics segments, profile attributes are evaluated client side and stored in Target’s profile instantly.
If you are using adobe web sdk, then send profile attributes under the __adobe.target so they persist in the Target profile.
Example create this data element in custom code
// with some counter logic, here am using localstorage
var pdpCount = parseInt(localStorage.getItem("pdpCount") || 0);
pdpCount++;
localStorage.setItem("pdpCount", pdpCount);
var data = {
__adobe: {
target: {
"profile.visitedPDP": pdpCount
}
}
};
return data;and sendEvent by updating data object:--
Then also test in experience platform debugger to see the audience qualification or go to the interact call on n/w tab to see whenever the PDP loads, the counter increments in the 'data'. The updated value is sent to target via Web SDK.
then simply create the audience in Target, it should work near real time.Refresh the page to view the experience.
If not using web SDK similar logic you could do for updating mbox profile parameter and it would work similarly.
I think @Sumit-Kumar covered a lot there, which is good, I don't have Target...
But, I did want to ask if you confirmed your ECID showed up in Adobe Analytics using your segment? It's always a good idea to confirm the segment (no matter how simple), that it is properly working.
The latency sounds like it's probably the issue here... but double checking wouldn't hurt.
Views
Replies
Total Likes
Hi @Sumit-Kumar and @Jennifer_Dungan,
Thanks for the inputs. To clarify our current stack and constraints:
Stack: We are using at.js (legacy), we do not have Web SDK implemented yet.
Requirement: We need to target based on historical behavior (returning visitors), not just real-time session logic using Profile Scripts.
Environment: We do not have AEP (Adobe Experience Platform) in our stack.
Update on Troubleshooting:
Verification: I manually confirmed that the test ECID is present inside the Analytics Segment definition.
Latency: We have waited over 48 hours for the original segment, and the user still does not qualify in Target.
New Test: I created a generic "simple" segment (based on a single page view) to rule out logic errors. After 12+ hours, this has not synced to Target either.
Question: Given that the ECID exists in the AA Segment but isn't propagating to Target after 48 hours, and considering we don't have AEP: Is there any specific "handshake" or sync configuration between AA and Target (Legacy Core Services) that might be broken? Or is there any alternative method to load historical Analytics audiences into Target in this environment?
Thanks.
Thanks for the additional information... I too am on at.js, though, that shouldn't make a difference for something like this... the concept of "hitting the same URL 3 times in the same visit" should work regardless of the technology used to track it...
Glad you confirmed that your segment worked in AA; but that leaves a larger mystery of why it's still not appearing in target after 48 hours...
Sadly, I don't have Target... so I am not sure how much help I will be... however, have you also tried posting this in the Target forum? Maybe someone over there has experienced this and can help support from that perspective?
https://experienceleaguecommunities.adobe.com/t5/adobe-target/ct-p/adobe-target-community
Good luck!
hi @EJCS
even with no AEP and no Web sdk it is fine, you can still achieve this using at.js profile parameters Pass Parameters: Target.
The issue with AA segments not syncing after 48 hours suggests that the Core Services audience sharing might be broken (e.g., ECID sync issues etc or something with the integration) because normally, even with latency, the audience should appear in Target after processing.
I understand you want to use AA segment since your requirement is based on historical behavior but you should also do this for real time qualification, by just using Target profile parameters:
With this at.js targetPageParams code below logic, it can be tried to the PDP page if using adobe tags/Launch or directly in your site code.
// Increment PDP view count
var pdpCount = parseInt(localStorage.getItem("pdpCount") || "0", 10);
pdpCount++;
localStorage.setItem("pdpCount", pdpCount);
// Pass profile parameter via targetPageParams
targetPageParams = function() {
return {
"profile.visitedPDP": pdpCount // This persists in Target profile
};
};
Or use in adobe tags/launch with this extension of adobe target to add page param:--
Then create a Target audience based on this mbox profile as shared before with profile.visitedPDP >= 3
This will qualify the user on the next page load after the audience qualification.
Also, you can debug by using experience Platform Debugger - Target -Profile tab.
or just enable 'Target Trace' to confirm the profile parameter (visitedPDP) is being sent and updated.
You’ll see the activity in the next visit once the audience qualification is met.
When I had AAM I used profile viewer https://experienceleague.adobe.com/en/docs/audience-manager/user-guide/features/visitor-profile-view... to check if the same aam uuid/mid qualifies for the analytics audience.
If you don’t have AAM, Go to your Experience Cloud - People - 'Audience Library' How to Create an Audience in Audience Library
check if your audience appears here with historical counts, you can also create an audience here (real-time with AA variables or based on shared Experience Cloud to see the count). Because these should also sync to Target if then all is working.
If this still doesn’t work, it’s worth checking with Adobe Target forum as suggested by @Jennifer_Dungan or Customer Support team to confirm if the audience sharing integration is correct or not, so this is worth checking with adobe Support.
Yes, client care would be the next step... but you might end up waiting a few weeks for something simple that the Target users might know what the issue is...
Check every potential source of help that you can!
Views
Replies
Total Likes
Hi @Sumit-Kumar and @Jennifer_Dungan,
Thanks again for the detailed follow-up.
Regarding the Profile Parameter solution: We have tested the approach you suggested (local storage + targetPageParams), and it works perfectly for the real-time use case. We will implement this for capturing behavior moving forward.
However, regarding the AA Segments: My persistence with the Analytics integration is because we have a critical business requirement to target retroactive audiences (users who qualified in the past 60 days), which we cannot achieve with the real-time profile script alone.
Update on my tests: Since my last post, I ran a deeper diagnosis:
Simple Segments: I created very basic segments (e.g., Page View = URL A) using different scopes (Hit, Visit, and Visitor) to rule out logic errors.
Wait Time: I waited 72 hours to carry out the tests in Target.
Result: None of them worked. The user is still not qualifying.
Key Observation: I noticed that the test ECIDs took nearly 48 hours just to appear in the Segment reporting within Analytics itself. This leads me to suspect a data latency issue in the data processing.
To confirm this, I am currently running a side-by-side test with a "Historic ECID" (Browser 1) vs. a "Fresh ECID" (Browser 2) to see if the delay behaves differently.
Next Steps: As suggested by Jennifer, I will post this specific scenario in the Adobe Target Community before opening a formal ticket with Client Care.
I will update this thread once I find the root cause or a solution.
Thanks for the help!
Thanks!
Views
Replies
Total Likes