Create an interesting moment off of Custom Object

Hi Michael,

The trigger will work (provided you convince the support to enable it for you ), but you will not be able to use the value of the field to populate your IM text.

So, as I wrote, you will have to create one smart campaign with this trigger for each new value that the field can take if you want to use this value in the text of the interesting moment.

-Greg

PS: Michel is my last name, which is why I sign my posts "Greg"

Hi Michael,

1/ quick question: are you accessing the Marketo API from the client side or the server side of your website? Please be very careful that doing it from the client side is very dangerous: it publishes to the open world your API key, meaning that anyone can use it to post data to you Marketo instance or to simply saturate your daily API quota and create a DOS attack.

2/ if you are publishing the data to lead fields, then you can immediately use these values to populate an Interesting Moment. As you point out, this will not create any history, but at least it makes the creation of the IM very simple.

3/ in email scripting, you can use Custom objects as well as lead fields, so this should not be much of an issue.

If I may suggest another architecture for the whole thing:

1. Post the data to lead fields only using the forms 2.0 client side API. This will not create any security issue and will not eat you daily API quota
2. In a "fills out form" smart campaign, create the IM with the content values and also call a webhook, passing to it the content title and URL
3. Have the webhook to post the CO in Marketo in an asynchronous/batch way using the REST API, not lead by lead, but in batch mode, so that you significantly reduce the number of API calls and save ion your daily quota.

-Greg

Yeah, I socialized your concerns (as also indicated in my previous discussion about UTMs) about the DOS attacks to our Web Team. They will be looking at that to ensure we are working around that risk.

It's impossible to work around, though. You have so few calls to give that metering them means your form becomes unusable.

For example, Marketo Forms are tuned to real-world legit activity and allow up to 30 form posts per minute per source IP. (You have to bear in mind that many people share the same IP addresses, in corporate networks and perhaps more notably at trade shows and other gatherings.)

30/min = 43,200/day = 4 times the base API limit of 10,000  (and that's making the huge and even irrational assumption that you aren't using the API for anything else). And that's for a single IP address! There's no way a system can enforce a posting limit that is low enough to stay under the API cap, while still allowing real-world use.

Sanford, doesn't the JSON array get overwritten every time though? I'm not clear on how we would get it there...I'll reread the docs and links you provided yesterday on the UTM discussion.

Nope, you use two fields: one for the individual JSON custom object as it comes in, another history field that's an array of all the past JSON objects.

The history field can either be append-only (if you use Marketo) or its internal objects can be updated (have to use FB for the updates).

A guide to how JSON interacts with Velo is here (also linking for Greg in a sec): http://blog.teknkl.com/marketo-json-fields-in-velocity/

On a related note, anything I should be reading up on to get better at dev? I read some people saying java, jquery, sql, etl, javascript, etc. Any other suggestions?

That's a tough one!  jQuery: no. It makes you a worse developer to learn jQ before you learn JavaScript. I'm not sure anyone ever recovers from jQ. (Source: I interview developers. )

Native JS: absolutely. First priority IMO.

Java: Tough language to start with. Within the Marketo ecosystem, the advantage of knowing Java is that it will skyrocket your Velocity skills. But starting with Velocity and understanding which parts are equiv. to Java is probably better.

SQL: Hard to say. Database design and writing elegant SQL can take a decade to get right. Within the martech world (as a consumer of martech services, as opposed to authoring new services) I'm not sure this has much of a place.

ETL: A broad discipline. At the low level, includes SQL, REST/SOAP APIs, and even FTP and other file transfer stuff.  At the higher level, it means becoming a power user of a package like MuleSoft, Boomi, et al. I think looking at the higher level is a good call, but I know that before I was a developer (I used to be a purely systems guy) those apps made a lot less sense to me.

If it were up to me, I'd recommend:

• Native JavaScript for the browser, meaning understanding the interaction between the HTML DOM, HTTP/Ajax requests, and JS. This has an immediate payoff in powering up Mkto forms and LPs.
• Native JavaScript without the browser, as in what you'd use in FlowBoost or other headless environments. It's exactly the same language, but since you're attacking pure data without the visual distractions, can feel totally different. Understanding objects and arrays... crucial.
• Velocity deep dive. So good for beefing up Marketo functionality. But not only that, it also helps you adopt efficient, collection-centric (heavy use of arrays/objects) coding practices that can be used in any modern language. If you don't code efficiently, Velo is really hard to maintain.