Workspace and Partition Munchkin lead tracking | Community
Skip to main content
New Participant
June 13, 2022
Question

Workspace and Partition Munchkin lead tracking

  • June 13, 2022
  • 2 replies
  • 3142 views

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.

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

2 replies

Colby_Dix
New Participant
June 20, 2022

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.

ooooh shiny.
Darshil_Shah1
Community Manager
June 14, 2022

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.

 

New Participant
June 15, 2022

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
New Participant
June 15, 2022

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.