Custom Object - Product Table

[Gilbert_Cereno]

We're new to Marketo and wanting to see how other clients are using their post purchase campaigns - pulling products dynamically in their email.

In my old world, Product Table is not connected to Leads/Customers but it's a sole (in some cases maybe multiple) table that we can link to order history table. It seems like this is not the case in Marketo. We created a Custom Object called Product Table and had to connect it to a lead, which in this case, it's either it pushed all the 10K items per each lead which is not ideal or just partially send the items that were just order. For some reason when we tested this, only 1 lead was updated and the others won't update.

Can anyone shed light on this? Or how you're personalizing your email and pulling products dynamically?

Thanks!

Gilbert

[Grégoire_Miche2]

Hi Gilbert,

You can create 2 tables. The Product Table (not directly linked to the lead table) and a join table that will link the lead and the product and cary the historical information.

The key question are how you will upload the data to Marketo and how you will leverage it in Marketo, to trigger or filter as well as to produce product information inside assets (such as emails).

In some case, modelling lead's products as a JSON object stored in a text area field can also be a viable solution. This will not allow the same volume of information are the table based schema above, but it would me much easier to update.

Amongst other things, the business you are in, and the data volume (how many products per person) will also be a driver ion the decision.

-Greg

[Justin_Norris1]

In addition to Greg's points, I would add a note of caution when considering using a separate product table and a junction object (i.e., many-to-many structure). Velocity cannot access the data on the custom object that is not directly connected to the person, and so you won't be able to pull from those records to personalize emails.

The docs erroneously state you can access second-level objects in velocity but it's not true, unfortunately.

Therefore, this limitation forces you towards a flatter data model where all the product information is repeated in each transaction record if you want it accessible in velocity, which I know is counter-intuitive for those who think in terms of relational DBs.

[SanfordWhiteman]

We made this point at the same time, Justin!

[Justin_Norris1]

[Grégoire_Miche2]

Great minds think alike !

[SanfordWhiteman]

Further to Greg's point, only first-level objects (linked directly to the person) can be output in emails.

This can be confusing, because second-level relationships via junction objects are honored in Smart Lists, but only the most local objects can actually be read out of the db.

So a flatter model is the only way to use the data in all locations.

[Gilbert_Cereno]

Thank you all for your input on this! We will definitely look into these suggestions.