I've been studying up on marketo objects and am wondering how I can leverage this.
Any great use cases out there?
Or is it really just custom per business.
Solved! Go to Solution.
In theory, any N:1 Thing:Person relationship, where Thing is not a high-density time series but rather a relatively static characteristic or dimension, might be implemented as a Marketo CO.
In reality, the opacity of the REST API and other limitations have made COs more of a last resort in our experience. We do use them: examples are multiple Area of Interest records for a lead; multiple Season Tickets held; multiple Stock Positions, Products Registered, Courses Requested, and UTM Events. But almost always we wish we had used a different implementation. For example, for storing multiple product interests on a lead, a single JSON-formatted text field is far more efficient and easier to update than creating a new CO each time.
The limited number of COs (10) that you get to access from Velocity has proven a major obstacle. If I want to customize someone's emails based on currently held warranties, better to store records in a textarea field, where if each record is just a couple of string fields there could be hundreds of entries instead of just 10. And for any data you want to display on an LP ("Welcome back, here are your holdings") you can't use COs at all.
YMMV, but a thorough review of what you're trying to do is the only way to decide if COs are the only choice.
In theory, any N:1 Thing:Person relationship, where Thing is not a high-density time series but rather a relatively static characteristic or dimension, might be implemented as a Marketo CO.
In reality, the opacity of the REST API and other limitations have made COs more of a last resort in our experience. We do use them: examples are multiple Area of Interest records for a lead; multiple Season Tickets held; multiple Stock Positions, Products Registered, Courses Requested, and UTM Events. But almost always we wish we had used a different implementation. For example, for storing multiple product interests on a lead, a single JSON-formatted text field is far more efficient and easier to update than creating a new CO each time.
The limited number of COs (10) that you get to access from Velocity has proven a major obstacle. If I want to customize someone's emails based on currently held warranties, better to store records in a textarea field, where if each record is just a couple of string fields there could be hundreds of entries instead of just 10. And for any data you want to display on an LP ("Welcome back, here are your holdings") you can't use COs at all.
YMMV, but a thorough review of what you're trying to do is the only way to decide if COs are the only choice.
+1 on Sanford's.
I would add a couple of other major obstacles:
-Greg
o
Here is a use case from B2C side.
We helped a publishing house with the implementation of custom objects in Marketo. The leads could be interested in multiple books. Also, a single lead could have purchased some books and would be interested in other books. We wanted to run drip campaigns, where the email would include a table with the list of the books which the lead is interested in. We started storing the data in the Marketo Custom Object via the API. The fields from the custom object were inserted in the email using a scripting token.
Custom objects are good to use where you can not use custom Salesforce objects in Marketo to fetch data or use them in emails. The use cases would vary for different business processes.
We started storing the data in the Marketo Custom Object via the API. The fields from the custom object were inserted in the email using a scripting token.
Right, this is an okay fit for COs but a far better fit for JSON storage, since you have all of the benefits and none of the drawbacks (API limits, script access limit of max 10 COs, no LP use).
In fact, the only limit with JSON storage is the size of the long text field in Marketo, which is 32k, AFAIK.
-Greg
Right! And if you find yourself going over that, you can [a] compress all or selected parts of the JSON (depending on how you're going to consume it -- Velocity can't use compressed JSON, as far as I've been able to discover yet, but JavaScript can) or simply [b] stretch into an additional field.
Even in a single field, you can easily support 100+ objects, depending on their inner structure, and everything is just... better.