Marketo not tracking "clicks link on web page" activity for about 10-15% of leads

[Dan_Stevens_]

We're hosting an event next week and noticed that there were five people that "accepted" an RSVP invite weren't listed among the 40 leads that are members of the event program.  These are the two buttons/links that are contained on the main RSVP page:

This is the trigger that we used to move people into the program status of "accepted" in the program (the blurred out URL is the URL of the ACCEPT button, without the "https://":

5 of the 45 leads never qualified for the trigger campaign since the highlighted "click link" activity was missing from their activity log:

The only way to get to the "rsvp-accept" page would be to click on the link within the main RSVP page.  So those users' activity log looks like this:

Notice the highlighted "Click Link" activity is missing.  Any thought as to what could be going on here?  These are all Marketo LPs.  Now we're wondering if this is something that's happening across all of our event programs.

Sanford Whiteman​

[SanfordWhiteman]

Dan, there are a few closely related conditions that can cause this.  I'd like to see if there's any similarity in the User-Agent across the failures.

Usually, the root cause is that the Munchkin endpoint was overloaded and taking a long time to return from (synchronous) click tracking calls, and old browsers actually fail more gracefully than newer ones under these conditions. (Our Munchkin Enhanced library brings those better coping mechanisms to modern browsers.)

[Dan_Stevens_]

Sandy, here is the UA info for all five records:

• Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko
• Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
• Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2)
• Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393

And here's a sample of those that were tracked properly:

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
• Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
• Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; managedpc; rv:11.0) like Gecko
• Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

To ensure we're able to capture all activity, we probably need to also include an extra "visits web page" trigger (which is not desirable, as it adds an additional trigger to many of our event programs; and further complexity (and chance for error) when setting this up.

[SanfordWhiteman]

Consistent with expectations. First group is all IE/Edge variants.

I wouldn't say you should have an extra Visits Web Page trigger. That should become your sole trigger.  Tracking clicks on non-exit links is a waste of resources anyway (you're specifically slowing down page-to-page navigation, even though the next page will generate a VWP.)  It has its place but should be used conservatively.

[Dan_Stevens_]

Good to know, Sandy.  I wish Edge never existed - have so many issues with it (beyond Marketo).  BTW, I also got this reply from Support:

I have been able to isolate the behavior that reproduces this result. Using either a right click and open in new tab or the center wheel click will result in the click link not being recorded. A control+left click will record.

I just can't imagine a user taking this sort of action - especially when it's for an event they've been invited to attend.  It would be different if it was a link that they weren't so sure about; or one that appeared as a phishing attempt.

The only issue in using the "Visits web page" as the sole trigger is that, if for whatever reason, a user navigated to this page somehow without clicking on the link, they would be counted as someone who's "accepted" the RSVP, even though they didn't attend to do so.  Obviously a very low chance of that happening, though.

[SanfordWhiteman]

Yeah, I deliberately didn't bring up right-click and similar actions because they didn't provide sufficient explanation in this context.

When using ​Visits Web Page, ​you can check the Referrer. For the click path between LP URL + TY URL that's a safe a check.

[Dan_Stevens_]

That's right, since the "Referral URL" - except when looking at it as part of "Fills Out Form" or "Clicks Link" activities - is truly the referring page.  I got so used to thinking "Referral URL" was the activity that took place on that page - since we really only use this with a "fills out form" trigger.

[SanfordWhiteman]

Yep!

[Dan_Stevens_]

We're running into this same issue for another similar type of activity - but this time it's to track click activity on a link to download a PDF after the user has submitted a form on the previous page (part of a paid advertising campaign):

• Landing Page: ERP Reimagined - Avanade and Microsoft Dynamics 365 for Operations
• Confirmation Page (with the link to download the PDF): ERP Reimagined - Avanade and Microsoft Dynamics 365 for Operations

I initially tested it about an hour ago and there was no click activity.  I tested it again just now and there was click activity.  I think there's something more going on here.  I'm using the latest version of Firefox (during both tests).

[SanfordWhiteman]

If no part of your site has changed, and you're testing in the same browser, then that would mean the Munchkin endpoint was either not responding during the initial period, or was not committing activities to the Marketo db (technically a different action).

Right now, I see activities being sent and your endpoint responding reasonably (< 300ms from NYC). This is in FF 52b5.

What kind of times are you seeing?

Sometimes I have seen loaded instances still trickle in activities far after the fact (rather than losing them forever).