Re: Landing page tracking twice

Anonymous · ‎08-16-2017

I have built a custom HTML landing page with a Marketo Form. I left the templates default setting of allowing Munchkin tracking. When viewing an instance of this template, it is tracking two views for a single view of the page. I went back into the editing the template and disabled the Munchkin tracking, approved it, went back to the instance of the template, approved its new draft (created from updating the template), approved it, and viewed the page again. Even after disabling the tracking, it still showed two additional views after I viewed the page once. I have viewed the page in Incognito mode of my primary browser (Chrome), I also viewed it in Firefox and IE11. One time it actually showed three additional views for a single view.

Any ideas?

Edit: When I have set Munchkin tracking to be disabled at the template level (the only place that you appear to be able to control this), it tracks 1 view per single page view (correct on the count). When I have tracking enabled, it tracks 2 views per single page view.

SanfordWhiteman · ‎08-17-2017

Just as a reference, I have been looking at "Statistics: 69 Views, 3 Filled out Form (4%)" in the instance of the landing page settings under the Design Studio (where you have Status, Type, Editing Mode, Statistics, Template, Form, Redirect Rule, URL). Are those stats not correct or not the right place to be reviewing the stats of the landing page?

You don't want to be using those Views because they count all HTTP-level GETs of the Landing Page, which is to say, a superset (sometimes a vast superset) of the true user-interactive pageviews that are logged by Munchkin, the JS-based web analytics library. Those Views include bots and any other user agent context requesting the page.

In other words, those Views aren't Munchkin views, they're more like pure web log lines, which are, if not necessarily useless, merely directional about the amount of traffic seen by a page.

You should use a Web Page Activity report to get accurate stats.

But what's interesting about you peeking in this other area is that it highlights an error in your code.

Look at this CSS rule in one of your inline <styles>:

Using an empty string as the background-image causes an extra GET of the current document. That's where your extra pageview is coming from. Remember, an empty string and background-image: none aren't the same!

View solution in original post

SanfordWhiteman · ‎08-16-2017

Doesn't make much sense.

Are you deploying this page in an IFRAME?

Please provide the URL so we can troubleshoot.

Anonymous · ‎08-16-2017

argus metals

No iframe. This is using the Marketo system to create a landing page from custom HTML.

SanfordWhiteman · ‎08-16-2017

Def'ly should not troubleshoot LPs using a *.marketo.com hostname as this absolutely leads to unexpected Munchkin behavior. You should always test using your custom LP domain. Not to say that explains that particular issue, but we need to uncomplicate testing.
Please show me a page where you don't have tracking turned off on the template, and have not made any other changes on the derived LP.
Are you positive you have not pasted Munchkin.init() into your HTML, at the base of the <body>?
Even repeated calls to init() with the same parameters don't result in multiple Visit Web Page events (Munchkin controls for this error) so something else is going on besides simply init()ing twice.

Anonymous · ‎08-17-2017

And how do you make custom URLs? I can't seem to change the automatic one that was generated.

SanfordWhiteman · ‎08-17-2017

Change the pagename under

Landing Page Actions >> URL Tools >> Edit URL Settings

But I was referring to the LP domain, which is set up in Admin (and in concert with your DNS admin).

Anonymous · ‎08-17-2017

I don't have access to that as my account is not an admin level account.

SanfordWhiteman · ‎08-17-2017

Also, please move this thread to Products before marking my answer correct. ("Central" is supposed to be for general, non-product-specific discush.)

SanfordWhiteman · ‎08-17-2017

You must find out what your LP domains are to test with those. Because of the way cookies work, testing analytics with the built-in *.marketo.com domain will not work as expected (but this isn't related to your current question).

Anonymous · ‎08-17-2017

I actually have the tracking enabled at the moment and since yesterday when I asked for help. I was just explaining one thing I had tried. I do absolutely do not have my own tracking code added. If you look at the rendered source code of the page, you will see there is only one Munchkin.init() call being made and it is at the bottom of the page being inserted by Marketo.

SanfordWhiteman · ‎08-17-2017

It's not currently logging multiple views (at the network level).

Anonymous · ‎08-17-2017

Just as a reference, I have been looking at "Statistics: 69 Views, 3 Filled out Form (4%)" in the instance of the landing page settings under the Design Studio (where you have Status, Type, Editing Mode, Statistics, Template, Form, Redirect Rule, URL). Are those stats not correct or not the right place to be reviewing the stats of the landing page?

Thank you for your assistance.

SanfordWhiteman · ‎08-17-2017

Just as a reference, I have been looking at "Statistics: 69 Views, 3 Filled out Form (4%)" in the instance of the landing page settings under the Design Studio (where you have Status, Type, Editing Mode, Statistics, Template, Form, Redirect Rule, URL). Are those stats not correct or not the right place to be reviewing the stats of the landing page?

You don't want to be using those Views because they count all HTTP-level GETs of the Landing Page, which is to say, a superset (sometimes a vast superset) of the true user-interactive pageviews that are logged by Munchkin, the JS-based web analytics library. Those Views include bots and any other user agent context requesting the page.

In other words, those Views aren't Munchkin views, they're more like pure web log lines, which are, if not necessarily useless, merely directional about the amount of traffic seen by a page.

You should use a Web Page Activity report to get accurate stats.

But what's interesting about you peeking in this other area is that it highlights an error in your code.

Look at this CSS rule in one of your inline <styles>:

Using an empty string as the background-image causes an extra GET of the current document. That's where your extra pageview is coming from. Remember, an empty string and background-image: none aren't the same!

Anonymous · ‎08-17-2017

While greatly I appreciate the insight (and the CSS correction), I doubt that is where the extra view is coming from because there are over a dozen GETs between the images and JS files being loaded. I'm a developer working at an agency building out multiple landing pages and emails for Argus Media to be deployed through Marketo and this is my first time working with this system, so it is all new to me. And because the sub-account they created for us isn't an Admin account, there are apparently quite a few things I am losing access to, like the LP domains and control over URLs.

I really appreciate the help you have provided me. The URLs may be something we just have to let the client setup after all the landing pages have been created.

SanfordWhiteman · ‎08-17-2017

No, my answer is correct. If you remove the CSS line with an empty string as the image source, you'll see this change immediately in your browser's Network tab.

An empty string means the current document will be loaded. This has always been true in CSS url() and HTML src/href contexts from the beginning of these technologies. Nothing unexpected here.

Please mark my answer Correct when done.

Anonymous · ‎08-17-2017

That is absolutely fascinating. After I uploaded the new HTML to the template, approved it, and then approved the newly created draft on the instance, it worked.

SanfordWhiteman · ‎08-17-2017

Yep... need to look under the hood to see what resources a browser is actually hitting.

[a] resources successfully fetched and rendered and [b] resources that cannot be fetched aren't the whole story. There are also [c] resources that are fetched from a remote server but are invalid for the element they're supposed to populate, so they're thrown away, but the hit still remains.

I explored a related case here a few months ago: Flop-timized: Marketo LPs and the case of the 300KB favicon

SanfordWhiteman · ‎08-17-2017

No, that wouldn't be where we'd typically report. I think I know now where your confusion stems from. Have to step out for a bit but will update later today.