Anonymous Activites not reporting when lead is known?

[Grégoire_Miche2]

Hi Jean-Pascal,

I see a weird parameter in your munchkinit function:

customName: 'Office-365-partner-profit-ebook'

And cannot find it in the doc.

Are you sure of this?

Sanford Whiteman​ skills might be needed here

-Greg

[SanfordWhiteman]

A split cookie tracking problem is when you are generating a new Munchkin tracking cookie when moving between pages, instead of reusing the existing one.

This can happen because of incorrect Munchkin initialization options (for example, not setting the domainLevel correctly for your parent private domain) or because you are moving between parent domains (far more complex to fix, since cookies are always bounded by the uppermost private domain: moving between sherweb.ca and sherweb.com, for example).

That said, looking at your two domains info.sherweb.com and www.sherweb.com, I do see the same cookie correctly shared across both. A visitor to www.sherweb.com will get a cookie that is reused when they fill out a form on info.sherweb.com, so web activities on both domains should be associated.

Can you post the ​Visited Web Page ​log for the lead ​teknkl01@blackhole.io ?

You should see:

www.sherweb.com

www.sherweb.com/cloud/

www.sherweb.com/veaam-cloud-connect/

www.sherweb.com/domain-registration

info.sherweb.com/Office-365-partner-profit-ebook.html/

info.sherweb.com/Office-365-partner-profit-ebook-thank-you.html

info.sherweb.com/Office-365-partner-profit-ebook-thank-you.html

info.sherweb.com/start-selling-office-365.html

www.sherweb.com

There's one minor mistake in your Munchkin install.  This isn't causing a problem, just an extra asset load: you have the Munchkin bootstrapper (munchkin.marketo.net/munchkin.js) loading twice on www.sherweb.com. The second load is disregarded, though.

Oh, and your SPF record is broken: you have include:spf.mandrillapp.com twice (once via nested include).  So you effectively have no SPF protection.

[Jean-Pascal_Mer]

Hi Sanford,

I do see all those visits in the log.

What strikes me as weird though, is that I never have leads that visited the website and then converted days after their first visit.

It's like the cookie resets after 1 day.

[SanfordWhiteman · Accepted solution]

The cookie is being managed with the expected 2-year inactivity expiration, it's not happeniung automatically.

It's possible (though non-traditional!) that you could have code on www.sherweb.com that expires the cookie. It's a first-party cookie, so you could have a line of PHP that sends back a Set-Cookie header. I don't see any JS that's doing this, but I can't see your PHP.

I'll see if the cookie in one of my test browsers is still around in 24 hours.  If it's gone then you will have to look at your server code, just to chase down that possibility.

[Jean-Pascal_Mer]

Ok, I might be crazy after all and nothing is wrong.

I went through the latest leads and on page 4, I found one where there was visits for 3 days before we got to know him.

That's 200 leads to finally find one... We might be really good at catching up a name on Day 1 then.

[SanfordWhiteman]

In your first post it seemed like you were getting no retroactive activities at all, so we've gradually honed in on the truth: overwhelmingly intra-day (but not instant) conversions.

Fix that SPF, though!

[Jean-Pascal_Mer]

About that SPF, which tool did you use to see it was duplicated?

We looked into it and only see one include for the spf.mandrillapp.com.

[SanfordWhiteman]

Hand-inspection.

Check the second include and you'll see spf.mandrillapp.com again.

[SanfordWhiteman]

No tools, hand-inspection. (Well, dig is a tool.)

Check the second include, servers.mcsv.net: it re-includes spf.mandrillapp.com.

There are many broken records out there due to the detailed requirements of the SPF spec, so you're not alone.

[Jean-Pascal_Mer]

Thanks, we fixed it.