Best Practices for Hidden Fields in Forms

[Elise_Stieren]

Is there a resource for marketers on the best practices for form hidden fields?

I am the marketo lead at a growing company (just raised series D) and want to start collecting more attribution information as our marketing campaigns grow more robust. 

We currently capture the basic information via hidden fields:

utm_source

utm_medium

utm_term

utm_name (campaign name NEW)

contact us original referral URL (NEW)

But now are building out new non marketo web landing pages and are running various google display and search campaigns, all with marketo forms. There's lots of varied information out there in different forums, so hoping for a reference guide or two for the fields we should be capturing, as well as an understanding of how the cookie hidden field operates. 

Like I said, we're a growing company so we're a small team, but we do have a developer and digital marketing lead who I can lean on for deeper understanding. I am the lead on Marketo.

Any suggestions?

[SanfordWhiteman · Accepted solution]

---

But now are building out new non marketo web landing pages and are running various google display and search campaigns, all with marketo forms. There's lots of varied information out there in different forums, so hoping for a reference guide or two for the fields we should be capturing, as well as an understanding of how the cookie hidden field operates. 

---

There's no one-size-fits-all practice here.

If using GA (or another analytics package that supports the utm_* field set for compatibility) then you want to get all 5 of those.  Some grab the gclid, which has no meaning in Marketo itself but is useful if you're building a marketing data warehouse offline.

If using another analytics package, you might have other fields/syntax that substitute directly for the ubiquitous (but not actually standard) utm_* set.

Beyond that, any query param on your website potentially could be relevant to attribution, as could the pathname/filename itself. Or might not be. For example, if someone fills out a Contact Us form on the page with productId=12345 then that product on your catalog may be important to modeling the person's journey. While sortorder=ascending may not be important at all, sortorder=new-releases might be.

But the far bigger question isn't what part(s) of the environment you want to stamp for a single touch, it's about creating multi-touch attribution logic. Which means not just a static field with a singular "this person's utm_medium was..." but a true one-to-many relationship between a person and all their touches. Those touches can (as of quite recently) be stored in Program Member Custom Fields, which is a good fit that doesn't require any back-end development. As for the front end, you absolutely, positively need a JavaScript-based touch recording library.

[Elise_Stieren]

Thanks @SanfordWhiteman, following your reply. I'll check in with digital re field substitutions- my assumption is no on substitutions. 

I recall coming across your posting re multi-touch attribution logic. If you're able, can you link here please as well as anything else you've written on the topic. 

[Elise_Stieren]

Also and perhaps a separate thread. In marketo instance I inherited, these SFDC fields were set-up and added as hidden fields in some of our global forms. The value is set-up for null so they are not grabbing any information, but I wonder how I can start using and optimizing them...

What operational programs should I establish?

How best to use with forms?

 

[SanfordWhiteman]

These field names are frustratingly vague. Presumably, the ones without "original" are meant to be most recent touch? (A two-touch system, in other words, not multi-.)

In any case, it sounds like they are meant to be used in concert with some JS-based cookie persistence code.

[SanfordWhiteman]

Unfortunately, due to Community Guidelines the most important link is one I can't post. Too bad.