UTM tracking cross domain between Marketo and WordPress pages | Community
Skip to main content
M
mwmarketing
New Participant
February 23, 2022
Solved

UTM tracking cross domain between Marketo and WordPress pages

  • February 23, 2022
  • 1 reply
  • 2158 views

Hi all,

 

I've implemented the following cookie tracking in this article: https://nation.marketo.com/t5/product-documents/utm-tracking-marketo-part-deux/ta-p/250332

 

I'm using these hidden cookie fields to track UTM parameters for our Google Ads to measure which search terms and ad groups are performing for my SEM agency. This has been working flawlessly for me when directing individuals directly on my Marketo LP's. 

 

Here's the issue, I now have the desire to push ads directly to our WordPress pages. However when an end-user lands on these WordPress pages, clicks an anchor tag or clicks a CTA button switching to our subdomain hosted Marketo pages all the UTM's clear off the URL string. This causes the converted lead record  to loose all this valuable hidden field meta data I'm trying to keep on form submit conversion. Is there a JS solution that would maintain the cookies for us?

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

First, “cross-domain” (though technically correct) may not be the best way to describe navigation between a private domain and a subdomain of that same private domain, or between 2 domains that share a common parent private domain (like www.example.com  and pages.example.com).

 

The reason the term can be misleading is that when speaking of cookies, there’s no security barrier between these domains. They’re effectively the same domain from a cookie perspective, since a cookie can be set at example.com and read by everything at/under that domain.*

 

The cookie security policy differs significantly from the cross-origin policy governing LocalStorage, Referrer, Ajax (XMLHttpRequest) and other more modern types of cross-site communication.  In a cross-origin context, https://www.example.com,  http://www.example.com, https://pages.example.com and https://example.com are different and require specific exceptions to be allowed to communicate.

 

Now, to your question!

 

Yes, it’s absolutely possible to persist UTMs (or any query params) to a cookie, then restore that cookie on the other domain, as long as the cookie is set at the parent (example.com). Alas, due to community rules I can’t recommend a specific JS library.

 

 

 

 

* assuming either [a] all sites are running over SSL or [b] all are not running over SSL

1 reply

SanfordWhiteman
SanfordWhitemanAccepted solution
New Participant
February 24, 2022

First, “cross-domain” (though technically correct) may not be the best way to describe navigation between a private domain and a subdomain of that same private domain, or between 2 domains that share a common parent private domain (like www.example.com  and pages.example.com).

 

The reason the term can be misleading is that when speaking of cookies, there’s no security barrier between these domains. They’re effectively the same domain from a cookie perspective, since a cookie can be set at example.com and read by everything at/under that domain.*

 

The cookie security policy differs significantly from the cross-origin policy governing LocalStorage, Referrer, Ajax (XMLHttpRequest) and other more modern types of cross-site communication.  In a cross-origin context, https://www.example.com,  http://www.example.com, https://pages.example.com and https://example.com are different and require specific exceptions to be allowed to communicate.

 

Now, to your question!

 

Yes, it’s absolutely possible to persist UTMs (or any query params) to a cookie, then restore that cookie on the other domain, as long as the cookie is set at the parent (example.com). Alas, due to community rules I can’t recommend a specific JS library.

 

 

 

 

* assuming either [a] all sites are running over SSL or [b] all are not running over SSL

Terms & ConditionsAccessibility statement

Loading footer...