Web SDK decisioning.propositionFetch Causing CJA Session Starts and Marketing Channel Mismatch | Community
Skip to main content
Level 3
March 3, 2026
Solved

Web SDK decisioning.propositionFetch Causing CJA Session Starts and Marketing Channel Mismatch

  • March 3, 2026
  • 4 replies
  • 63 views

Hey there!

After implementing the Web SDK guided events, CJA reporting and setup are impacted by decisioning.propositionFetch events. We currently have to exclude this event type via segments to align CJA with AA, but doing so breaks Session Starts and our Internal Domains logic. 

Impact in CJA (we are using raw AEP data, no Adobe Analytics Source Connector):

  • Sessions / Page Views / Session Starts 

    • With an event-level exclusion segment (eventType = decisioning.propositionFetch): 

      • Sessions ≈ AA Visits 

      • Page Views ≈ AA Page Views 

      • Session Starts much lower than AA Entries 

    • Without the exclusion segment

      • Sessions and Session Starts are higher than AA 

      • Page Views still align with AA 

      • At a dimension level (e.g., Canonical URL, Marketing Channel), we sometimes see Sessions > Page Views, which should not occur 

    • Root cause: decisioning.propositionFetch fires first, so CJA treats it as the session-start event. Excluding it via segment removes most “first hits,” so Session Starts collapse. 

  • Internal Domains (Marketing Channel) 

    • Internal Domains in CJA is defined as: 

      • Session Starts is set (to mimic AA “Is First Page of Visit”), AND 

      • Web Referrer URL in a list of internal domains (e.g., www.mywebsite.com, etc.) 

    • With the exclusion segment: 

      • Overall Session Starts and Internal Domains metrics are much lower than AA. 

    • Without the exclusion segment: 

      • Total Sessions/Session Starts are higher than AA, and Internal Domains Page Views are extremely low vs. Sessions/Session Starts, indicating non-pageview events are acting as session starters. 

What’s the recommended setup approach to achieve CJA parity with Adobe Analytics for Visits/Entries and Internal Domains—without relying on exclusion segments that remove most first hits? Or should we avoid exclusion segments altogether and accept expected variance between platforms?

 

Thank you!

Leyla

Best answer by Leyla-1

Hello ​@hegi90 , ​@sreeCharan73 , and ​@Jacinda E 

Thank you all for your insights. 

Since we need to support reporting on overall web performance in CJA as well as Target activities, we actually thought of exploring routing decisioning.propositionFetch to a separate datastream. We’ll need to assess any downstream impact first. Conceptually, if we prevent decisioning.propositionFetch from flowing into the web dataset that powers our CJA connection, it shouldn’t affect CJA metrics—because CJA can only report on events contained in the dataset(s) included in the connection. That said, we’ll validate this with testing before moving forward. 

Whenever we make progress with the solution, if interested and this ticket is still open, I can report back here with the update.

 

Thank you guys for your support!

 

4 replies

bjoern__koth
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
March 4, 2026

Hi ​@Leyla-1 

have you tried using guided events in your proposition.fetch Web SDK events?

https://experienceleague.adobe.com/en/docs/experience-platform/tags/extensions/client/web-sdk/actions/send-event#

Cheers from Switzerland!
Leyla-1Author
Level 3
March 5, 2026

Hi ​@bjoern__koth , thank you for your response! 

We are using the Web SDK guided event Use guided events.  Our issue seems to be downstream? Because decisioning.propositionFetch is the first event before the page view, it’s impacting CJA sessionization/entries. We’re exploring routing it out of the Web dataset that feeds into our CJA data view to prevent inflation. Any additional thoughts/ideas you may have?

Thank you!

 

bjoern__koth
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
March 6, 2026

are you using your proposition data in your CJA connection?

If so, this may indeed impact the session calculation if it is stitched to the succeeding page view call.

Cheers from Switzerland!
Level 3
March 11, 2026

From my experience, decisioning.propositionFetch was auto excluded in Adobe Analytics, but unfortunately not in CJA. So for personalization reporting you don’t need decisioning.propositionFetch in CJA. I exclude these requests on dynamic datastream, so they don’t mess up metrics in CJA. 

sreeCharan73
Level 3
March 11, 2026

@Leyla-1 This is a common issue in my projects. I try to forward these events to a different dataset in platform using dataset override in the webSDK tag and not onboard them to the CJA, unless required. Because most of the session based metrics are actually calculated at DataView, even when tried to exclude them using the Data View settings. Hope this helps.

Jacinda E
Community Manager
Community Manager
March 11, 2026

Hi ​@Leyla-1 - just following up here. Did any of the responses here help solve your issue? If so, please consider selecting a best answer to help others with a similar question find help in the future 🙏

Leyla-1AuthorAccepted solution
Level 3
March 11, 2026

Hello ​@hegi90 , ​@sreeCharan73 , and ​@Jacinda E 

Thank you all for your insights. 

Since we need to support reporting on overall web performance in CJA as well as Target activities, we actually thought of exploring routing decisioning.propositionFetch to a separate datastream. We’ll need to assess any downstream impact first. Conceptually, if we prevent decisioning.propositionFetch from flowing into the web dataset that powers our CJA connection, it shouldn’t affect CJA metrics—because CJA can only report on events contained in the dataset(s) included in the connection. That said, we’ll validate this with testing before moving forward. 

Whenever we make progress with the solution, if interested and this ticket is still open, I can report back here with the update.

 

Thank you guys for your support!