SOLVED

Effect and usage of the domainlevel munchkin Initialization Parameter

Go to solution
Highlighted

Re: Effect and usage of the domainlevel munchkin Initialization Parameter

Hi Sheila,

No, you do not have to activate Muchkin Beta.

The code on your page works fine and the cookie is posted to the domain, not the sub domain.

If you have old cookies in your browser, from previous navigations, clean before testing.

But you munchkin call are at the bottom of the body and you are using a synchronous version.

You should rather use an unsynchronous version of the code and post it before the </head> tag.

-Greg

Highlighted
Level 10 - Community Moderator

Re: Effect and usage of the domainlevel munchkin Initialization Parameter

The code on your page works fine and the cookie is posted to the domain, not the sub domain.

Actually, Sheila's right. It's setting at .info.247.ai.

The reason is the code needs to look like this:

var tldinfo = findPrivateSuffix({cache:false}).domainLevel;

not just

var tldinfo = findPrivateSuffix({cache:false});

Highlighted

Re: Effect and usage of the domainlevel munchkin Initialization Parameter

HI Sanford,

Weird, on my Mac, it appears to be set correctly

pastedImage_0.png

May be it's because my computer is so used to 2 letters TLD that it now automatically fixes the bug If only this could be true.

-Greg

Highlighted
Level 10 - Community Moderator

Re: Effect and usage of the domainlevel munchkin Initialization Parameter

Sheila wants it at 247.ai, though.

Highlighted

Re: Effect and usage of the domainlevel munchkin Initialization Parameter

Ho, my bad I probably need to go to bed...

-Greg

Highlighted

Re: Effect and usage of the domainlevel munchkin Initialization Parameter

Now that I'm back from Thanksgiving... hope you both took a few days off too.

Thanks for responding. I made the fix on the page and I'm getting it set to .247.ai now.

Just to make sure I'm clear, without implementing your nifty code, _mkt_trk is being set to .info.247.ai on the Marketo landing pages and .www.247.ai on the main website. Only the info.247.ai has forms making it the only place for a lead to become known. This means we are loosing the activities from the main website which is the whole reason to go to the trouble of adding in your nifty code. I'm a bit confused as to what is happening once the person becomes known... there are comments at the bottom of your blog post that indicate that once they become known, we'll loose all previous activities but that moving forward the activites for both will be logged in Marketo. Am I interrpurting this correctly?

Also, there is a comment "rest assured that there's a way to merge the activities and it's not too difficult. I'll put up a follow-up post w/the recipe." Did that follow-up post happen? I've looked for it but didn't find it. Did you ever create the follow-up post?

Lastly, would you recommend that I implement the climbDomains routine to clear out the other sub-domains? If so, does it matter where on the page I put it - specifically before or after call to findPrivateSuffix?

Thanks again! You are awesome.

Sheila

Highlighted
Level 10 - Community Moderator

Re: Effect and usage of the domainlevel munchkin Initialization Parameter

Just to make sure I'm clear, without implementing your nifty code, _mkt_trk is being set to .info.247.ai on the Marketo landing pages and .www.247.ai on the main website. Only the info.247.ai has forms making it the only place for a lead to become known.

Actually, they could become known on www.247.ai if they clicks email links to your main website. But regardless of the method used to make the session associated, that association cannot carry across sites unless the cookie is set at the shared parent domain.

there are comments at the bottom of your blog post that indicate that once they become known, we'll loose all previous activities but that moving forward the activites for both will be logged in Marketo. Am I interrpurting this correctly?

It's not that once they become known you'll lose previous activities. It's that once you set the cookie at the correct parent domain and delete the old cookie:

  • If they had an existing anonymous cookie at the wrong domain, then anonymous activities logged previously will not be part of the new session, since their cookie will have been regenerated for the right domain.  And when the new session becomes associated (by link click or form fillout) those old activities will not be merged into the Activity Log.
  • If they had an existing associated cookie at the wrong domain, then their previous activities will remain in their Activity Log. They won't go anywhere. But the freshly generated cookie at the right domain will be anonymous until it, too, is associated.

Also, there is a comment "rest assured that there's a way to merge the activities and it's not too difficult. I'll put up a follow-up post w/the recipe." Did that follow-up post happen? I've looked for it but didn't find it. Did you ever create the follow-up post?

I did not blog it yet. It's actually not as easy as originally thought, so decided to play it close to the vest on that one... clients only for now!

Lastly, would you recommend that I implement the climbDomains routine to clear out the other sub-domains? If so, does it matter where on the page I put it - specifically before or after call to findPrivateSuffix?

It doesn't really matter -- I recall it runs totally standalone. You just need to ensure (test!) that you put 247.ai as the domain to skip over.

And you should run climbDomains because on pages that have forms. That's where it matters because forms are confused by multiple cookies.

Highlighted

Re: Effect and usage of the domainlevel munchkin Initialization Parameter

Thanks so much for your explanations Sanford. I implemented and tested the climbDomains and it works like a champ. Yes, I tested! 

Thanks for always for being so willing to share your knowledge and help others out!

Regards,

Sheila