Have beacon URL update on Single Page Apps

[#1]

Currently, on a single page app, my first beacon will have the correct URL. But if I navigate to another page, and there is a history/state/URL change without loading a new DOM, my URL does NOT update- my "g" parameter in my beacon still reflects the first page loaded.
These days, most single page apps DO update the URL as the user navigates around; it would be good to have that URL reflected in analytics.
I often manually force this by doing something like "s.pageURL=document.location.href" in doPlugins or similar, but it would be great to have it be built in- folks get confused when they see my workaround because they think "isn't that what pageURL is automatically?" (answer: not on a single page app).

[#2]

The problem here is that you should be using direct call rules to then allow the single page app to fire beacons as need when users navigate around the APP. Very good user case for this is Angular based Apps.... Then its just a matter if developer building app correctly to accommodate (pageview like reporting).

[#3]

This applies even when using DCRs. I know how to update pageName and custom variables and all of that on a new page view- and I do know how to manually override the URL to have the new beacon reflect the new url, using s.pageURL. What I'm asking for in this idea is for the url to update automatically.

For instance, currently, when my SPA loads, my first beacon might have:
g = http://www.mydomain.com/home.html
pageName = home
events= event1
prop1= D=g

Then the user browses to a new page (http://www.mydomain.com/products.html), I update the data layer, fire _satellite.track("page view") or somesuch, and my next beacon would have:

g = http://www.mydomain.com/home.html

pageName = products

events= event2
prop1= D=g

The appMeasurement library does not update the url to http://www.mydomain.com/products.html but rather just holds on to the URL from when the DOM first loaded.

The current work around is to add to your DCR/EBR, or to doPlugins, something like this:
s.pageURL=document.location.href

But a lot of folks don't know to do that.

[#4]

I see some of the dilemma. In this case the data layer via the app needs to be changed to reflect the new (virtual URL).

Again the pagename and URL variable(g) parameter for that matter can be modified for the state change of the APP. Its all relying on the APP to update as needed the variables. Its really a case of the APP developer building an infrastructure to allow the Direct call rules to fire when needed and then ensure things like(present URL, previous URL) are set at the correct time.

GLTU

[#5]

I think you may still be missing the idea I'm proposing here. The appMeasurement library automatically sets the URL into the "g" parameter. The problem is, the logic that does this may be outdated as it doesn't work well in SPAs, where a single DOM may change states/URLs multiple times. In these cases, appMeasurement doesn't realize the URL has changed and continues setting the "g" parameter with the original URL.
A developer who is aware of this problem can get around it easily enough by manually overwriting that G parameter- I already know how to do this. I'm proposing Adobe update the appMeasurement logic so that the "g" param always reflects the current url.

[#6]

On another note, this also impacts getQueryParam functionality- I believe s(.Util.)getQueryParam takes advantage of s.pageURL, so unless you're updating s.pageURL currently, you might inflate tracking on query params.