Workspace and Partition Munchkin lead tracking

[tfrancoeur]

Hi,

We are setting up workspaces and partitions since we have a new acquisition (we bought another company) and we are facing multiple issues with making it work as we would like to.

Preface: Our leads from our original company (company1) need to exist in both partitions separately (through dedupe rules) some people will be clients with us for company1 but are at the prospect stage for company2.

1st. we created a new workspace and partition for company2

2nd. we added dedupe rules for List Import/Web form fill out

3rd. we added munchkin tracking code in both websites

4th. created a landing page in company2 workspace

We have an issue where some actions don't seem to go in the right partitioned person. As an example below; LeadA and LeadB are the same person with same email address (through partition deduplication rules) but use content from both companies

1. leadA filled out form on company2 website

     LeadA is created in company2 partition

2. LeadB filled out form on Company1 website

     LeadB is created in company1 partition

3. LeadA filled out landing page from company2 workspace

     LeadB is is updated instead of leadA

How can we fix the issue with the actions not being logged in the right partitioned person?

Ultimately, we want the person to have the activity in the partition associated with the workspace where the asset was created. I.e. LeadA is updated when consuming content from Company2 workspace and LeadB to Company1 workspace.

[Darshil_Shah1]

Well, I think this is a known issue - regardless of the custom dedupe rules set, the person whose cookie is present in the browser will be updated regardless of which form they fill. Ex. - if leadA fills out the landing page (from company2 workspace) from the browser that has munchkin cookie created by the leadB, the leadB will receive the update even though the LP and form belongs to the company 2 WS which is mapped with the partition where the leadA is present.

[tfrancoeur]

Interesting, thanks for the info. 

Does that mean there is no work around this issue because its cookies based and doesn't have to do with Marketo or is there some way to make it work via another path?

We wanted to test further by adding the domain of Company2 landing pages but after reading a bit more on the subject even the "default domain" stays the original and adding another domain is just to have a different url for the user so doesn't seem like it would help with Munchkin API either.

[SanfordWhiteman]

---

even the "default domain" stays the original and adding another domain is just to have a different url for the user so doesn't seem like it would help with Munchkin API either.

---

If your domain alias has a different private domain suffix (i.e. pages.example.net where the default domain is pages.example.com) that’ll absolutely change the behavior.

Cookies are not shared across private suffixes, so even if they’re known on example.net they’ll be anonymous on example.com until they fill out a form on or click a tracked link to example.com. And the 2 records will be tracked independently.

[tfrancoeur]

Good to know, though, while both of our company domains are different, the TLD is the same ".com"

[SanfordWhiteman]

---

Good to know, though, while both of our company domains are different, the TLD is the same ".com"

---

The TLD isn’t directly relevant, just the private suffix.

example1.com and example2.com will not share a cookie under any circumstances. They are as different as example.net and example.com (for this discussion).

[Darshil_Shah1]

Well, with the domains for both the workspaces being exactly the same - I don't think there would be a possible workaround for this behavior since you'd not be able to tell to which lead (leadA or leadB) the existing munchkin cookie is associated to and whether the cookied lead's partition and the workspace in which the LP/form asset that he's currently viewiing/filling are mapped or not.

[tfrancoeur]

It would be different domain names, one's company1.com, the other one is example2.com does that make a difference?

[Colby_Dix]

not exactly a helpful answer i know, but...

do you really need partitions? because 99.9% of the time, they are more hassle than whatever perceived benefit there may be. i work with a number of enterprise clients and always STRONGLY recommend against it due to duplications, tracking, and the myriad issues that arise.

whatever difference there is in the handling of your Person records regarding interest in multiple products, verticals, or divisions, i can promise you that it is far easier to solve for than going with partitions. basically, unless there is a legal reason for having them, i say no. ironically, having a legal justification for using them still leads to increased legal/compliance risk because of the potential (likelihood) of duplicates in the segmented system.

anyway, i know it doesn't help you with your current issue, but for real, partitions are awful. every time.