Join leads from two domains without email (using another primaty key)

[Anonymous]

Ok, so I have this problem I don't know how to solve. My company sells an e-commerce system that is developed by another company. A white-label deal.

When the user purchases the subscription, they use an email address as username. Then this user is directed to our control panel, where they create a username (a string, not an email) to access the actual e-commerce system, at the other website, which is hosted at another domain, not a subdomain of mine.

Like this:

There's no way I can provide access to the user's email on the "ecomsystem.com" domain, but we can share a unique Id, like a user ID, or some other unique data, just not the email.

Is there any way to make another field the primary key, so I can feed the lead created in the first step when the user gets to step 3?

Thanks.

[Josh_Hill13]

I'm a little confused, where is Marketo in this process? Is it at the end?

You can use the API to pull in the data you want. I have heard it is possible to re-key the Marketo DB, but it is not recommended. Is there a reason the email address is not available to you from the ecom system?

[Anonymous]

Marketo is in the whole process. There's munchkin tag in all the pages, however, since they're different domains, marketo generate different cookies, different leads.

It's beyond my scope why the ecom system doesn't have access to the email, I think it's something about us not wanting to share the user's emails with the other company.

[SanfordWhiteman]

Share the Munchkin cookie.

I had to put that in italics because it's the obvious line of attack.

If you can transfer the Munchkin cookie via the e-commerce system, then read that out on the other domain and set it as the Munchkin visitorToken.

Or, just as easy since you own buy.mycompany.com, generate the Munchkin hash key (this must be generated on your server not in the browser) and then share that key and pass it to Munchkin::associateLead.

[Anonymous]

The thing about sharing the cookie is, since the marketo cookie is first-party, so the second domain won't have access to that cookie generated for the forst domain.

About the hash key, I understand you're talking about the sha1 of the api key + the email, right? I tried that and it didn't work. I'll debug and see if there's any problem in the process.

Thanks.

[SanfordWhiteman]

I don't think you're following.  The partyness of the cookie is irrelevant.

You said you "can share a unique Id" between systems without having to use HTTP for transport, that is, you can push the id into the user's account on the e-commerce system and pull it out when the user logs into the e-commerce system.  Therefore you have access to the string on the other side -- whether it was originally a cookie on domain A is immaterial, because you are using the application's proprietary account system to transport it.  Then on domain B you can set that string as the cookie.  Since it is already associated with the lead, you don't have to do anything else.  At no time is the cookie being read across domains via HTTP or JS.

Yes, with the hash key I am talking about the SHA-1 hash used by Munchkin::associateLead.  Obviously for associateLead to work, you also have to transfer the email address itself, but this is easily encoded into one big Base64 string.

Again, either of these will work if it's really true that you "can share a unique Id" via the e-commerce system as you indicated and that unique id is treated as an opaque string.

[Anonymous]

Ok, I wasn't following.

I think I got it now. Will get to work with that and see if I'm able to pull it off.

Thanks a lot.