Preference Center and 300 new fields

[Michael_Florin]

Hi all,

we're just discussing how to build a preference center in the best possible way. And when I read about this, people usually say: Create Boolean fields for the various preferences. Okay, I understand that, and it seems to to be the ideal way, both from a customer facing form perspective and from internal handling and segmentation perspective. BUT: My current case has 20 business lines and each business line has up to 15 preferences. That would make 300 new Boolean fields in Marketo.

Is that a problem from any point of view? Performance-wise?

Thanks!
Michael

[Darshil_Shah1]

I haven't heard about Marketo having a hard limit on the number of custom fields that you can create. I've worked with clients who literally had over 1000 Marketo-only custom fields. Of course, they were not able to manage the data integrity, hygiene, etc. for most of the fields. I think the ability of marketers and Marketo to be able to keep up with the increasing hygiene and data integrity needs as one goes on about creating more and more custom fields is more so of a concern (and, a bottleneck too) when it comes to creating and managing the custom fields. 

Instead of creating 300 custom fields for managing people's preferences, would it be possible to aggregate preferences for a few similar business lines together and try managing the preferences in lesser complicated and powdered form with fewer fields? Worse comes to worst, you may also need to create campaigns (mostly triggers) to manage and update the email compliance fields (tracking, history, last opted-out date, marketable fields, etc.) as these opt-in fields get updated for each preference and/or business line.

Happy to hear what others here in the community have to say/advise regarding this.

[Michael_Florin]

---

Instead of creating 300 custom fields for managing people's preferences, would it be possible to aggregate preferences for a few similar business lines together and try managing the preferences in lesser complicated and powdered form with fewer fields?

---

Yes, I was thinking about that too. Using a field like "BL A Preferences" as the Checkboxes type on a form looks certainly viable. It saves various values as a semicolon-separated string which allows for segmentation via "BL A Preferences contains..." But: We also need to import these preference and the import data look more like 

Preference A - true

Preference B - false

So that would need to be substantially re-formatted first.

I also thought about storing preferences in Static Lists or in Program Member Custom Fields, but nothing really convinces me.

[SanfordWhiteman]

With that much complexity I'd choose Marketo Custom Objects. The catch being that you have to build an intermediate gateway to read and write them, of course. But the Marketo user experience is much, much smoother, and you can easily bulk import.

[Darshil_Shah1]

CO approach sounds like a good option here, given that you're able to build the intermediate gateway (as Sandy talks about in his comment) to read and write data to it in the coalesced format. Also, you'd not be able to do list imports directly, you would rather need to update the data via the gateway. And of course, you'd be limited to only 50 fields on the CO and you'd certainly not be able to create as many as 300 fields unlike on the lead object.

Also, not a fan of a Static list or PMCFs for storing the preferences as they are not as durable as a custom field, FYR, you can only create up to 20 custom PMCFs as of today and, as you'd know, the data gets scrubbed off from them when a member is removed from the program.

[SanfordWhiteman]

---

Also, you'd not be able to do list imports directly, you would rather need to update the data via the gateway.

---

? You can do Custom Object list imports via the UI. You would do a Lead Import first (since you're associating via Email Address) but no reason to use the gateway for that.

---

And of course, you'd be limited to only 50 fields on the CO and you'd certainly not be able to create as many as 300 fields unlike on the lead object.

---

Each Subscriber CO is a distinct record, no worries about field limits. If you need 50 fields to describe the nature of someone's subscription to a single list you've done something wrong!

[Darshil_Shah1]

Yes, thank you, Sandy! So it is either run the raw data through the gateway or create the csv file to have preferences stored in the coalesced format and then do the LI via the UI. Also, if OP doesn’t plan on to stacking preferences together, then they’d probably end up needing 300 fields (15 preferences for 20 business lines), which doesn’t sound very optimal. Apologies, if I’m missing out on anything here.

[SanfordWhiteman]

Don't know what you mean about the coalesced format - you have one row per Subscriber CO. (One person can have unlimited Subscriber COs.)

[Michael_Florin]

I thought about Custom Objects too. And I agree it's usually the best way to represent any 1:many relationship. Yet, I foresee requests that COs can't handle easily: "Give me a list of all my subscribers by preferences" or "please add the preference A to person B - they talked to Sales" - I might be able to do that using the API, but my client certainly does not.

Thank you for commenting! I'll twist and turn this item in my head for a little longer.

[SanfordWhiteman]

---

Yet, I foresee requests that COs can't handle easily: "Give me a list of all my subscribers by preferences"

---

What’s the problem w/creating that Smart List?

---

"please add the preference A to person B - they talked to Sales" - I might be able to do that using the API, but my client certainly does not.

---

Yes, you’d have to control all the entry points. You could create a hidden page that does this (using the same gateway that the public preference center uses). Or have a webhook that runs when a certain Person field is changed.