Tracking UTM parameters cross-domain for mobile users

[Kristin_Carideo]

Hi Marketo Users,

I searched the community for an answer here and couldn't find one that specifically dealt with the issues around mobile.

I need to track some UTM parameters across two domains, from a click on a CPC campaign, into an ungated page and then into a gated asset page.

The ungated page is not on the Marketo domain and the gated page is.

90% of the traffic from the CPC campaign is mobile, and we've discovered that the cookie one would normally use to do this doesn't work for mobile users.

In theory, I have a solution for this but it's not super scalable (add a piece of code onto every link off the ungated page to the gated page that drags the UTM parameters with it), but I'm wondering if anyone has encountered this before and if so how to solve? We've implemented a custom js cookie into a non-Marketo page that captured UTM parameters before, but, again, it doesn't work on mobile browsers.

TIA!

[SanfordWhiteman]

The ungated page is not on the Marketo domain and the gated page is.

Whether either domain is hosted on Marketo or not isn't really the question.

The question is whether they share a parent domain.  Assuming you have the Munchkin domainLevel set correctly (it will be automatically set correctly for .com domains), then subdomain1.example.com and sudomain2.example.com will share their Munchkin cookie. subdomain1.example.com and subdomain2.example.co.uk will not share their cookie(s).

90% of the traffic from the CPC campaign is mobile, and we've discovered that the cookie one would normally use to do this doesn't work for mobile users.

I don't understand what you mean by the cookie "doesn't work."  Mobile browsers support cookies just fine.

a custom js cookie into a non-Marketo page that captured UTM parameters before, but, again, it doesn't work on mobile browsers.

Again there is something off with this phrasing.  I doubt the mobile browser is your problem.

[Kristin_Carideo]

Yeah sorry. This is a marketer trying to explain something from my dev team. Bear with me .

Both have the same domain but one is a Wordpress blog site on a subdomain and one is a Marketo subdomain. Not sure if that matters.

My understanding was that these two properties couldn't share a cookie for mobile users and now that I'm doing digging, I believe the problem is specifically with mobile Safari. I'm working on getting the dev to actually write up the dev-y problem for me.

Just wondering if cross-sub-domain cookie tracking issues within mobile rang any bells here.

[Kristin_Carideo]

Also, not talking about the Munchkin tracking or anything like that (that works just fine on any device). Specifically talking about the situation in which data (captured UTM values) has to be shared from the wordpress subdomain to the marketo subdomain.

[SanfordWhiteman]

Also, not talking about the Munchkin tracking or anything like that (that works just fine on any device). Specifically talking about the situation in which data (captured UTM values) has to be shared from the wordpress subdomain to the marketo subdomain.

The same rules apply.  Do the subdomains share a parent domain, and is the cookie being set for that parent domain (.example.com)?

[Kristin_Carideo]

Here's what I got back from the dev team. Is there something basic we're missing? We've seen this behavior play out during testing.

The issue is that third party cookies don’t work in mobile safari. So, if the first touch was set on a Marketo page and then they left and later came back and filled out a Marketo page form the cookie would parse into the form as normal. But first touch will not set or read on the pages where forms are embedded or are otherwise not hosted on Marketo.

Basically that takes all traffic not on a marketo page coming through mobile safari out of the equation. We could do a few things to help capture some of those values, but ultimately anytime someone goes from a Wordpress page to a marketo page or vice versa, in safari mobile, the cookie is lost. We could set things up where anytime mobile safari is detected we set the hidden form values as something like “safari-mobile-no-cookie”, but as far as I can see in mobile safari we’re always going to have a dark spot as far as recording the cookie.

Although to answer your initial question, they are on the same domain, unless that gets tricky when you bring wordpress into it. The blog is hosted on blog.DOMAIN.com and the Marketo pages are marketo.DOMAIN.com (well, not that, but you get the picture).

[SanfordWhiteman · Accepted solution]

The issue is that third party cookies don’t work in mobile safari. So, if the first touch was set on a Marketo page and then they left and later came back and filled out a Marketo page form the cookie would parse into the form as normal. But first touch will not set or read on the pages where forms are embedded or are otherwise not hosted on Marketo.

Marketo does not use third-party cookies, so the premise is faulty.  No modern web technology relies on transmitting or saving third-party cookies.

When Munchkin runs on blog.example.com, it sets a first-party cookie for the parent domain .example.com, or uses an existing cookie if there is one.

When Munchkin runs on marketo.example.com, it similarly sets a first-party cookie for the parent domain .example.com or uses a preexisting one.

Since they share a parent domain and the cookie was set at the parent level, a cookie set on either site will always be transmitted to the other site, so an associated session on Site 1 will also be associated on Site 2 ("associated"  = "web actions linked to a known lead").

[Note: the above is automatically true for a registered domain that ends in .com, .net, .org, or another TLD that has 3 or more letters.  It is not automatically true, by counterexample, for a .to domain, which requires manual configuration -- simple, but manual.]

There must be something wrong with the test environment to lead to the faulty conclusion that Marketo uses anything other than first-party cookies.  It's true that Safari was the first browser to block third-party cookies by default, but that's irrelevant. Marketo cookies are not set on .marketo.com (nor .mktoresp.com or .mktoweb.com). They are set on your domain.

The significant difference between [1] an embedded Marketo form on a non-Marketo page and [2] that same form on a Marketo-hosted LP is that the former does not support form value Prefill.  Thus, even if Munchkin is correctly tracking activities (page views, link clicks) and linking them to a known lead in Marketo -- that's views and clicks on Marketo pages and on your third-party site -- when the lead visits a third-party page with an embedded form, the form will always appear blank (unless it has been set in the Form Editor to display the Known Lead HTML instead, which is another configuration option).  Perhaps seeing a blank form misled your developer into thinking the cookie was not present.

[Kristin_Carideo]

Thank you for that very helpful explanation!

I took this answer, dug a little deeper and pushed back on the developer and apparently the data loss is seen solely on clicks from Facebook paid ads within the Facebook mobile app. That's a significant portion of our traffic, but it's also a much narrower issue that I think we can solve basically by only running lead gen campaigns that go directly to a Marketo page in our Facebook ads, and then go back to using the native cookie parsing available in Marketo forms to take care of the data loss across the other channels. Thanks again for walking me through it so I could have the conversation with the dev team.

[SanfordWhiteman]

Glad you're getting some clarity!  But what's left still doesn't quite make sense.

It sounds like the issue was never Mobile Safari but rather a WKWebView (Safari-lookalike/actalike web browser window) within the FB app.  As far as I know -- though I'm not an iOS developer -- WKWebView has no inherent problem with cookies set via JavaScript, like the Munchkin cookie..

It's true that the WebView's cookie store isn't shared with the Mobile Safari cookie store, which can create gaps in tracking (you think you've filled out a form in "Safari," but in real Safari you're still anonymous). But this behavior actually makes sense (the idea of a WebView is to be isolated and under the app's control).

Either way, the concept that site entry via a WebView opening a Marketo-hosted LP behaves differently from site entry that's also via WebView but a non-Marketo LP doesn't compute.  Munchkin and Forms initialize the same way in both contexts -- literally the same script. I feel there's some other quirk that's affecting the developer's perception (or something that shouldn't really be expected to work, like sessions being preserved across WebView and real Safari).