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

[Jon_Wu]

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 https://example.com/_event/#path=/form.html&eventName=Filled+out+promo+form?path=/form.html&eventNam.... 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?

[SanfordWhiteman]

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_Wu]

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]

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.)

[Jon_Wu]

Are you on Munchkin v2? I was speculating that maybe a v2 upgrade could fix our issues, but if you're on v2, perhaps there's no immediate hope.

If Munchkin is going to have a case of the Munchkin-Maybes, we'll probably just re-implement basic event tracking through Salesforce and create  new Salesforce object for each would-have-been Munchkin activity to trigger our campaigns instead.

Not ideal, but I don't see any good ways forward since we can't depend in web page view activities being logged, AND once they're logged, they don't always trigger correctly (Are there known gotchas where Smart Campaign triggers always fail on certain page views? ).

[Jon_Wu]

So frustrating, they closed my case, said everything works fine, and we can pay professional services for help. Infuriating!

[SanfordWhiteman]

Oh that really ticks me off.

I assume our (totally reproducible) case may get summarily closed as well.

How could they possibly explain why you can see the req going up in Dev Tools but never appearing in Activity Log?

[Jon_Wu]

I don't know, but it's super ridiculous. Just check out their response:

Hello Jon, per Tier 3 they can see that munchkin tracking is working as expected. Since you are saying, that not all the web page visit activities are not showing for an invalid/fake website (per your testing), then this will be considered a request for us to trouble shoot your custom code on your website. Unfortunately, this is not within the parameters of our support. Per Tier 3, you will have to work with your account manager to put you in touch with our Professional services team to debug your code.

I suppose they're trying to say that it's expected for Munchkin to only work sometimes?

In addition, I'm pretty offended that they call our production website "invalid/fake" per the tests I did on production website, in which I included a screencast and showed the dev tools and activity log side by side. This makes me want to start blogging about our Marketo experiences.

[SanfordWhiteman]

If you do, link me to it and I'll follow up on my blog, too. That is really insulting. All you're saying is you're hand-crafting valid potential URLs and seeing them fail. They're not fake in any way that should matter for a tracking library. It's the same kind of testing anyone should do for such strange problems, like we did when we saw that abc=true worked (for awhile) but abc=true&def=false didn't get logged correctly.

[Jon_Wu]

Thanks for the offer, I hope I don't get there, but you never know. The worst part is, in my screencast, it's the fake URLs that do work, and the real URL that doesn't work. Oh well, hoping we'll find somebody to bump the case back into play. Please let me know if you hear any good updates in yours.