Are there known gotchas where Munchkin page views with certain params don't get recorded? | Community
Skip to main content
Level 4
July 31, 2017
Question

Are there known gotchas where Munchkin page views with certain params don't get recorded?

  • July 31, 2017
  • 1 reply
  • 5061 views

I've been trying to track down some problems for weeks, and have some support cases open, but in the meantime, I wanted to see if the community had seen issues like I'm having.

I have a similar question where activities are logged (Are there known gotchas where Smart Campaign triggers always fail on certain page views? ), but campaigns aren't fired, but it seems these could be different issues, although they both break our automation consistently in certain scenarios.

Background

Using the Munchkin JavaScript API, we log events as a "page view" to log activities we can trigger off of. Imagine we have a non-Marketo form where we collect info, then fire a page view that looks something like example.com/_event/#path=/form.html&eventName=Filled+out+promo+form?path=/form.html&eventName=Filled+out+promo+form. We repeat the data in the hash and query string to allow boolean AND matching (For a Visit Web Page trigger, how do you match multiple querystring conditions with AND logic? ).

We're on Munchkin v1.

Problem

For a given virtual page view, sometimes the activity never shows up in the lead's Activity Log. In one such example, let's say the event didn't work where the path was form.html. These variants worked:

- form.htmlXX
- form.htmlXXXXX
- form.ht
But these didn't:
- form.html (the original test case)
- form.htmlX
- form.htm
- form.htML
However, the behavior is so flakey and inconsistent, that I can't figure out what's up. On other .html pages, the same event does get recorded.
I say not recorded, because in all cases, I've verified in the Chrome network inspector that the event is sent to the server, and the server replies with an HTTP 2XX success code.

Anybody seen this behavior?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

1 reply

SanfordWhiteman
Level 10
July 31, 2017

Funny that you ask this, Jon, because I have an insane Support case open which is -- if not identical -- wacky in the same way.

In our case we discovered that some URLs, while being logged by Visit Web Page unlike yours, are being classified as "Webpage ID 1" (i.e. the first indexed Munchkin page) despite (a) having nothing in common with that URL and (b) being different from each other by only minor ways, like a single character in the query string.

So I would not be at all surprised if there is a related root cause (such as a malfunctioning indexer that in your case is seeing something as a duplicate timeseries point, and in our case mistakenly deduping against another record).

Jon_WuAuthor
Level 4
July 31, 2017

Very interesting Sanford! For your weird URLs, does a given URL + querystring combo break consistently, or does it seem random?

The breakage feels random but appears to deterministic from what I've observed in our case so far.

Since I can't figure out what's going wrong, I've been unable to find a workaround because it seems like when I change some random things in the URL, one page starts to get logged, then another stops getting logged. It's like playing whack a mole.

Random hypothesis: perhaps the activities are getting sharded, but one node is failing?

I'm stumped on what to do for now.

SanfordWhiteman
Level 10
July 31, 2017

Since I can't figure out what's going wrong, I've been unable to find a workaround because it seems like when I change some random things in the URL, one page starts to get logged, then another stops getting logged. It's like playing whack a mole.

That's exactly the type of thing we've observed. Over the long haul it's probably deterministic but kind of like a seeded RNG is deterministic.

Random hypothesis: perhaps the activities are getting sharded, but one node is failing?

I like it! (But have no actual idea.)