Set webReferrer. URL for SPA pages | Community
Skip to main content
Xingu13
Xingu13
Level 2
April 21, 2025
Solved

Set webReferrer. URL for SPA pages

  • April 21, 2025
  • 1 reply
  • 842 views

Hi everyone,

We’ve been troubleshooting an issue with our marketing channel processing in Adobe Analytics, where some of our paid search landing pages are incorrectly showing up under the "Organic Search" channel. (Here’s the original post for context: link).

After digging into it, we realized that one of the culprits might be how our SPA (single-page application) handles the webReferrer.url value.

Originally, we were just using the default document.referrer value for every pageview rules (page load and SPA view rules), including SPA route changes. The problem? Even after the user landed via Paid Search, the subsequent virtual pageviews were still showing www.google.com as the referrer, which messed up our channel attribution.

Example flow:
Paid Search → Landing Page (full page load) → Next Page (SPA route change)
→ Referrer still shows www.google.com = bad attribution.

We’ve looked around the forums and haven’t found a clear best practice for setting webReferrer.url specifically for SPAs. Some folks suggest overwriting it with the current page URL, others say to leave it blank with SPA route change—but there doesn’t seem to be a solid consensus.

Has anyone figured out the ideal way to handle webReferrer for SPA pageviews to avoid these attribution issues?

Thanks in advance!

Best answer by Jennifer_Dungan

SPAs have always had that problem.... I actually really hate SPAs for that reason.

 

Depending on your setup, my preferred method to deal with this is to have the developers write the referrer info into the Data Layer..

 

So, on the first page, if there is a document.referrer, then set that, if it's direct, leave it empty. Then, as the user navigates screen to screen, since their code should be updating the history in the browser, and updating the current URL, they should be able to maintain and set the last page URL...

 

Instead of reading the document.referrer, you read it from the Data Layer and rely on your developers to ensure the proper values.

 

 

If you can't get your developers to do this, there is the less precise method of setting your own session storage or cookie values.

 

On the initial page load, you can use the document.referrer, then you need to store the current URL into one of the above methods. Then when you navigate to the next screen, you need to pull that stored value and set it as the referrer, once you have used this and sent your beacon, you need to replace the old value with the new current URL (for use on the next page). If the user refreshes, then you should read from the cookie/session storage... so basically, check if you have a stored value, if you do, use it.. if you don't, then use the document.referrer.

1 reply

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
April 22, 2025

SPAs have always had that problem.... I actually really hate SPAs for that reason.

 

Depending on your setup, my preferred method to deal with this is to have the developers write the referrer info into the Data Layer..

 

So, on the first page, if there is a document.referrer, then set that, if it's direct, leave it empty. Then, as the user navigates screen to screen, since their code should be updating the history in the browser, and updating the current URL, they should be able to maintain and set the last page URL...

 

Instead of reading the document.referrer, you read it from the Data Layer and rely on your developers to ensure the proper values.

 

 

If you can't get your developers to do this, there is the less precise method of setting your own session storage or cookie values.

 

On the initial page load, you can use the document.referrer, then you need to store the current URL into one of the above methods. Then when you navigate to the next screen, you need to pull that stored value and set it as the referrer, once you have used this and sent your beacon, you need to replace the old value with the new current URL (for use on the next page). If the user refreshes, then you should read from the cookie/session storage... so basically, check if you have a stored value, if you do, use it.. if you don't, then use the document.referrer.

    Xingu13
    Xingu13Author
    Level 2
    April 23, 2025

    thanks @jennifer_dungan for responding. Always good to have your take on marketing channel related questions! 

    we do have developers set up the datalayer and pass the referrer for previous page or external referrer. we updated our webReferrer.url with this value, so 

    when first page load happens, webReferrer.url shows external referrer (www.google.com). 

    For subsequent page views, webReferrer.url is set with the value of previous page. 

    so for 

    first page --> page load (referrer URL: www.google.com)

    2nd page --> SPA pageview (referrer URL: first page)

    3rd page --> SPA pageview (referrer URL: 2nd page) 

     

    However, we are still seeing paid landing pages showing up under organic search,which made me think if we set the webReferrer.url wrong. So is the above the correct set up for webReferrer.URL? 

    Jennifer_Dungan
    Community Advisor and Adobe Champion
    Jennifer_DunganCommunity Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    April 23, 2025

    Hi @xingu13 ,

     

    What you have described looks correct... basically instead of relying on the document.referrer (which doesn't update in an SPA), you have transferred the information into your data layer, setting the previous page's URL... exactly how the document referrer works on a standard website.

     

    If all your testing indicates it's working as you described, then that should be good.

     

    Now, if you are having issues with your Marketing Channels, you might need to review those rules.. There may be an issue there?

    Terms & ConditionsAccessibility statement

    Loading footer...