One-to-Many Data Options in Marketo Engage: Marketo Data Architecture for the Non-Data Architect

[Michaela_Iery3]

One-to-Many Data Options in Marketo Engage: Marketo Data Architecture for the Non-Data Architect

As the old marketing expression goes – Content is King. But I posit that Data runs the empire!

Think about it – think about the sheer volume of data that each one of us generates every day, being captured in what we visit, what we order, what we look at, what we respond to. I promise you it’s all being captured somewhere. I know, a little creepy right? But here we are, that’s the world we live in  –and we can at least use our powers for good! By creating:

• Experiences with our prospects and customers
• Using the data they’re sharing with us to
• Provide relevant, useful information to them that
• Drives engagement, sales, and ultimately, brand trust

But it’s all driven by data – what we know, what we don’t know, where it lives and how we access it in our marketing. Which means that as marketers, we’ve got to understand the data in Marketo Engage and how we want to use it and translate that for our IT stakeholders.

When we talk about Marketo Engage, you will often hear, “Marketo is a database of People.”

All of the data objects within Marketo Engage – accounts, opportunities, program membership, etc. must have a relationship to the Person object to be usable in Marketo.

As you can see in this diagram, every data object is linked directly or indirectly to the Person.

But what you see in the Marketo user interface is a very “flat” architecture.  What do I mean by that? In Marketo, all those objects connected to the Person are in the background, “behind” the Person record.

Whatever you query in Marketo will ultimately give you a list of person records - person records with certain company names, certain opportunities, etc. Unlike CRMs that expose all object records, with Marketo you cannot go inspect records on each object. It’s part of what makes Marketo easy to use when it comes to marketing to People, but it can be a little confusing for folks who are used to other data architectures and it requires you to think a little differently when it comes to the idea of data that has a “one-to-many” relationship with the person record in Marketo Engage.

The Person object is great for capturing things that are binary – a “1-to-1” fit, like demographic data such as name, address, preferred language, lead source, most recent campaign, etc.

But when someone can have multiple data points of a type (such as multiple events to attend or multiple products they can purchase), and you don’t want that data to get overwritten, creating Person-level fields for each possible data point (so they don’t get overwritten) is not scalable or best practice.

When you hear “one record” and “many” similar data points, it’s time to consider Custom Objects, Custom Activities or Program Member Custom Fields. Let’s take a look at each one:

Custom Objects

So what’s a custom object? Well, it’s custom built – duh, right? But actually, it’s a table that allows you to link multiple data records to one person. I think of it as an Excel spreadsheet. Each data point we want to capture is a column in the spreadsheet, and a person is logged as a record on a row in that spreadsheet for each time they have those data points. And you can be on this spreadsheet more than once!

I like to try to make data concepts relatable to personal experiences first, plus I will literally use ANYTHING as an opportunity to talk about pets, so the example here is a custom object where we are tracking people and their pets as part of a veterinarian’s database. In this case, you can see that there are 7 fields of data we are capturing – email address of the human parent (they pay the vet bills after all!), what type of pet they have, the breed, the pet’s name, a unique ID for the pet, their adoption date and the date of their last appointment.

And what you can see is that I am on this object three times, one for each pet – this is how I, a single record, can be related to 3 different data sets – one for each of my pets.

Email	Pet Type	Pet Breed	Pet Name	Pet ID	Pet Adoption Date	Last Appointment Date
michaelaiery@mkto.com	Dog	Basset	Violet	Violet1108	11/08/08	11/23/22
leanneb@lbxyz.com	Cat	Mixed	George	George0316	03/21/16	12/17/23
michaelaiery@mkto.com	Dog	Basset	Eleanor	Eleanor0410	04/16/10	04/16/22
brianl@brianl.org	Reptile	Iguana	Beans	Beans0922	09/22/22	09/22/22
fredstone@adobe.co	Bird	Macaw	Feathers	Feathers0719	07/15/19	01/31/23
michaelaiery@mkto.com	Dog	Mixed	Bentley	Bentley0123	01/27/23	01/30/23

As with all things Marketo, a custom object must link back to a Person Record, so we need to select a field that links each record (row) on the custom object table back to a person in Marketo. In this case, Email is our link field but it could be an account number or something else unique to a person record.

Since a person can have multiple records on a custom object, we also need a dedupe field – otherwise how would Marketo know if it needs to create a NEW entry or update an existing one – we don’t want the custom object to show Michaela having three dogs each named Brentley (though he IS a very good boy I’m sure!). So here, we use Pet ID to differentiate between the 3 different pets that Michaela has. (You can have up to 3 fields be dedupe fields, FYI.)

What’s great about a custom object record is that they can be updated, such as Last Appointment Date here. That’s why that dedupe criteria is so important – we don’t want the system to create a NEW record with Brentley’s last appointment date, we want system to update the current record of Brentley, related to Michaela, with his most recent appointment date. The custom object here reflects the most current data for each pet owner for each of their pets.

So that’s a B2C example, but the same idea applies in B2B with any data type that might have multiple records per person and need to be updated:

• Product purchase and warranties
• Product interests
• Contact ownership when there are multiple sales owners of one record
• Event registrations (many of our event partners leverage Marketo Engage custom objects for this purpose – updating when someone registers for an event vs. attending it)

Custom object data can also be used in email for personalization (using email velocity script) as long as they are one-to-many (many-to-many custom objects or child custom objects from your CRM cannot leverage velocity script). And custom object data can be created or updated via list import in the UI of Marketo Engage.

Custom Activities

Custom activities are similar to custom objects in that they also allow a one-to-many relationship between a person record and data. What’s different is that a custom activity is create-only, you cannot update it. You’re really using it to log a single time that "a thing" happened. It’s just like Marketo’s own activity table on the person record, except in this case you’re building a custom version to track the activities you’re interested in.

There are critical differences between custom activities and custom objects: custom activities cannot be updated, they are not available for velocity scripting and they can ONLY be created in Marketo via API from another system. Having said that, they are terrific for point-in-time tracking of activities that are happening to your person record that aren’t tracked by Marketo Engage via the standard activity table.

In another pet-related example, perhaps our veterinary office sends out an NPS survey to its human parent after each appointment for each pet. We can use a custom activity to track the results from this external survey system:

Lead ID	Email	Activity Date	Activity Type	Score
12345	michaelaiery@mkto.com	01/15/23	NPS Survey	10
53341	leanneb@lbxyz.com	01/15/23	NPS Survey	5
12345	michaelaiery@mkto.com	02/28/23	NPS Survey	8
09879	brianl@brianl.org	03/01/23	NPS Survey	9
75853	fredstone@adobe.co	03/17/23	NPS Survey	3
12345	michaelaiery@mkto.com	03/18/23	NPS Survey	9

While this example has minimal data, you certainly could include things like what appointment type it was, or which pet it was for, in order to further target your audience. But, as with all data you’re bringing into Marketo Engage, you want to focus on only the data that would be useful.

For example, you might want to send a follow up email if an NPS score was very low, but maybe send a different email depending on whether that score was low for a wellness visit vs an emergency visit, where emotions tend to run high!

Again, B2B examples might not be any different. You might collect survey results from a third-party system. I’ve also seen this used by my clients to collect email send activity from another email system so that they have a record of all emails sent to their database, not just the ones being sent from Marketo. Many marketing tools that integrate with Marketo Engage leverage its custom activity functionality to capture third-party activity in Marketo.

Program Member Custom Fields

I often refer to program member custom fields (PMCFs) as the “chicken or fish” field type as they were born of a use case that we saw often with our Marketo Engage clients. Many times, Marketo Engage users would need to capture data that might change depending on which program it was in – for example, a live event where you are capturing meal preferences. One person might register for several events and at one event, they want chicken for their meal but at another event, they want fish. Prior to PMCFs, my Marketo Engage clients would create custom fields on the person object – maybe several – in order to capture this data per event, but there was a risk, of course, that one event might override the other if they were using the same custom field within the same time frame.

Unlike custom activities or custom objects, PMCFs are custom fields that you can add to an existing data object – the program member data object. The program member object is rather like a custom object table, it’s just specific to program membership – you can be a member of multiple programs, all with different statuses, and as your status is changed in a program, your program member record can be updated.

PMCFs extend the existing program member table by allowing you to create up to 20 additional fields on that object, where you can store additional data specific to each program about a program record.

You can see here that we’ve added 4 PMCFs to our table – three specific to events and so obviously being leveraged by Event programs, but not being leveraged by non-event programs, like ad retargeting. And we have a PMCF that’s more about the ad source that brought someone to a program, which, obviously is being used by the ad programs and not by the event programs.

Additional PMCF considerations:

• There is a maximum of 20 PMCFs across the entire Marketo instance – this is a hard cap – and PMCFs are available for use by all Marketo program types
• You cannot change a program member custom field type (string, data, Boolean etc.) once created so plan carefully before building!
• PMCF values for person records are only available to view in the user interface within the Members tab of the program
  • You won’t see their various program member data values on a tab on the person record
  • You would see the data change and detail in their activity log
• You can’t report on PMCF values (except as smart list filters in Marketo report types that support smart lists, like email and people performance reports)

The TL;DR

As marketers using Marketo, we are responsible for understanding Marketo’s data architecture and our marketing use cases, translating both to the data available outside of Marketo Engage.

The Person object is great for capturing things that are binary – a “1-to-1” fit – and is the object you’ll likely use the most in Marketo (along with Company).

But when one Person can have multiple data points of one type, leveraging one of Marketo’s ”1-to-many” data objects may make sense

Each of the 1:M objects available in Marketo have different features to consider, as shown below.