Adobe analytics not refreshing on page redirection in the react application due to "history.push" method.

[vishali]

Adobe target script is working fine if we are using  “a tag (hyperlink)” for page redirection, but in many places in our application, we are using history.push method to load the content for another page. 

Currently, it is working perfectly on only the current page , if we click on any other page URL then latest target data is not loading on Adobe debugger tool due to history.push in single-page application, when I refresh the page then only it is loading the latest data.

How we can resolve this issue?

[Jennifer_Dungan]

What is your current rule trigger?

There is a History Change trigger, which should detect when your code forces a change into the browser's history:

Is this what you are using and you say it's not working? Or is your rule set up for something like Window Loaded or DOM Ready? Neither of which will trigger on subsequent pages in an SPA site...

Keep in mind, you will need a trigger for those to catch the first PV... you should be able to add both triggers into one rule (Window Loaded OR History Change), but this might trigger the rule twice on the first page (you will have to test that)... if it does, you can add a Max Frequency constraint condition:

Unfortunately, 1 second is the smallest increment... but changes are, people won't move onto the next page for at least that

[yuhuisg · Accepted solution]

history.push is unreliable with SPA websites, because of the way that the JavaScript frameworks (e.g. React) use it.

Your best option is to have your developers send Direct Calls when rendering a "page", then you trigger your page view beacons with those Direct Calls.

[Jennifer_Dungan]

I know that the history push is the main rule used in GTM for SPA sites... if the site is already live, that's the option for now.... I hadn't heard of any unreliability on that method...

Personally, I like have an explicit call like @yuhuisg said, that means that our developers can trigger it once all the content of the page is loaded, all the data I need to track is ready, etc...

The problem with this is that the tracking event can fail if there are cascading JS issues on the page, or if the developers forget to trigger the event (however, with proper test cycles this should be okay). I had multiple QA builds that broke all tracking on a few occasions, or new pages that failed to trigger tracking... but as long as you are diligent in your testing cycles, this approach is the best one as your developers have more control on timing your tracking to correspond to the content loading.