Munchkin tracking all non-Marketo pages without the need to Refresh page?

[Ronn_Burner]

Munchkin script has been successfully added to our website (Non-Marketo pages) which I know because the Visit Web Page and Clicked Link on Webpage is being logged on a known record Activity Log as it should.

The problem is only the first page is being logged – rather than each page of the process with each corresponding webpage appended with these identifiers: …/shopplan, …/planlist, …/select-dental, …/review-quote, and …/viewplandetails.

However, it does capture that page activity if you manually refresh the page. From what I understand, the platform is a Single Page Architecture (SPA) application, and it doesn’t do page refresh for every step.

I’m being told by the web team, “This will need adjustments on Marketo configuration to capture DOM level changes to identify and apply flows in platform and capture all pages. Rather than have a “Page Refresh,” we would recommend reconfiguring to identify a “DOM activity,” for a single-page architecture, as the trigger.”

How and where do I configure/solve for this – to get the Visit Web Page and Clicked Link on Webpage to be logged on known records activity log for each page they visit?

[SanfordWhiteman]

---

I’m being told by the web team, “This will need adjustments on Marketo configuration to capture DOM level changes to identify and apply flows in platform and capture all pages. Rather than have a “Page Refresh,” we would recommend reconfiguring to identify a “DOM activity,” for a single-page architecture, as the trigger.”

Hmm... they think they’re making sense 🙂 but kind of aren’t.

Yes, an SPA where the “pageview” activities are all virtual content replacement, without truly navigating to a new document, needs special treatment.

No, the treatment certainly isn’t to listen for native DOM Mutation events: this is a heavyweight process and far more resource-intensive than should ever be necessary. (It’s less resource intensive than it used to be because of the Mutation Observer API, but still crazy overkill for analytics tracking.)

The right treatment is to capture the single non-native event their code fires when switches to a new URL (i.e. the use of history.pushState which changes the URL without actually “going” to another URL in the traditional sense). Don’t they have an event they already fire when they change from /someurl to /anotherurl? Then we can listen for that and send a custom Munchkin event.

[Ronn_Burner]

Thanks, Sanford! As usual, it turns out you are spot on as the Developer team seems to agree with you. But one final thing just to be clear, is it a true statement to say that these hooks or changes you suggest can only be added at the application level (website) and not within the Munchkin JavaScript?

[SanfordWhiteman · Accepted solution]

---

As usual, it turns out you are spot on as the Developer team seems to agree with you. But one final thing just to be clear, is it a true statement to say that these hooks or changes you suggest can only be added at the application level (website) and not within the Munchkin JavaScript?

---

Right, you’d never be altering the Munchkin JS itself nor its built-in config: it doesn’t have an option that automatically hooks into other events. But it has methods you can call at any time, like:

history.pushState({},"","https://example.com/go/somewhere");

Munchkin.munchkinFunction("visitWebPage", { url: document.location.href });

history.pushState({},"","https://example.com/go/somewhere/else");

Munchkin.munchkinFunction("visitWebPage", { url: document.location.href });

Your team needs to make sure to call munchkinFunction() like that after a new state is pushed.

[Ronn_Burner]

Got it! Thank you sou much!