Passing Values into Hidden Fields via Cookie & Parameters | Community
Skip to main content
June 5, 2018
Solved

Passing Values into Hidden Fields via Cookie & Parameters

  • June 5, 2018
  • 3 replies
  • 13274 views

I've read just about every article about this, and it seems so easy in the Marketo docs, but I just can't get it to work. I'm trying to pass a value into a hidden field on a form via a cookie. I'm quite technical, but I must be overlooking something and I'm getting bizarre results. Here's my issue(s):

I set a cookie for anyone landing on the website with a specific parameter. I've verified the cookie is getting set and is present throughout testing.

Here is my test:

I've created two hidden fields, one that pulls from the URL Parameter, the other pulls from the Cookie Value.

My results:

  1. When the user comes from deeper within the site (indirectly to the Marketo landing page), and the parameter is no longer in the URL, it is somehow still passing into a hidden field via the Get Value From: "URL Parameter".
  2. When the user comes in directly to the Marketo landing page with the form present (and the parameter in the url), it is not picked up by either the "URL Parameter" or the "Cookie Value" - both of which are present.

So, the parameter is getting passed by the URL Parameter, when none is present - (maybe somehow it's pulling from the cookie?), and is not when both the URL parameter and cookie is present.

Any ideas?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman

Your current approved LP only has the single cookie mapping (cookie gclid → field GCLID__c). I assume you didn't reapprove the LP, if you've made that change in Form Editor.

With that considered, the form is behaving as expected. Once the cookie exists (after the first load) then the hidden field is Auto-Filled.

Also, you generally want to turn off Pre-Fill (not Auto-Fill) for these attribution tracking fields, because otherwise you can get very confused while debugging (leaving a field empty if it's not supplied by the session context is more clear, and that empty field will be ignored by the db when posted, so you don't have to worry about clearing fields accidentally).

P.S. You really should do some refactoring in the other form code on the page -- while it's not related to the behavior you're reporting, it's hard to read through in order to rule it out.

For one example:

if (isUnSubscribed!=undefined && isUnSubscribed!='' && isUnSubscribed!=null && isUnSubscribed=='false') {

} else if (isUnSubscribed!=undefined && isUnSubscribed!='' && isUnSubscribed!=null && isUnSubscribed=='true') {

This code path can never be different from:

if (isUnSubscribed=='false') {

} else if (isUnSubscribed=='true') {

Also: any element selector should be scoped to the Marketo <form> element, not to the document. Remember that you can have multiple forms and you don't want to change values across forms. And value changes should be done with the forms API setValues() whenever possible, not DOM updates, or else you can break visibility and validation rules.

3 replies

Victor_Herrero
New Participant
November 19, 2018

Sorry, but I don't understand why two fields are necessary for this. Perhaps because I don't have a technical background.

Shouldn't it be enough to grab the information from the cookie?

Is this cookie not generated / updated automatically every time someone clicks on a google ad?

Creating two fields sounds like a bad practice (although if necessary, I guess I could create a MKTO only one that grabs the info from the url and updates the SFDC one if empty through a campaign).

SanfordWhiteman
New Participant
November 19, 2018

The 2 touches mean different things.

One is, depending on nomenclature, the Acquisition Touch or Conversion Touch: the touch that represents the pageview during which the form was filled out.

The other is an earlier visit to the site, which was stored in a cookie for later comparison/cross-reference.

Victor_Herrero
New Participant
November 19, 2018

The way google suggests you implement this, it only asks for you to create one GCLID field in SFDC, so i'm not sure the intended use of this is multi-touch attribution, but rather last-touch attribution, to whatever ad click happened just before a desired conversion.

From what I gather using url parameters or getting the info from the cookie, feels like a matter of preference.

Also, GCLID (L) is what SFDC would call a field if you were to create it twice with the same name, so it seems like in JP LaCount​'s organization they created the field twice. Perhaps by mistake, perhaps on purpose to have redundancy in the GCLID implementation (url parameters can get lost or altered and cookies deleted, so having both can help...)

So I'm still not sure if duplicating the fields is necessary or  i'm not understanding your answer, @Sanford Whiteman​. Thanks for the response in any case.

This whole GCLID is a bit unclear to me. We are currently implementing it. Therefore the questions.

The way I understand this is: every time someone clicks on an Ad, they are redirected to the desired page (which may or may not contain a LP with a form). A GCLID cookie is generated every time as each Ad has its own. The value is updated in DB with every ad click and form submission, and Adwords analytics will look at the latest GCLID value whenever the desired conversions take place, so that the conversion can be attributed to the ad the current GCLID value belongs to.

Did I get it right? Am I missing dome deeper analysis you can do from Adwords with the GCLID cookie and the values it may have had in the past? After all, not all ads need to lead to a LP with a form...

Grégoire_Miche2
New Participant
June 5, 2018

And please also provide a screenshot of your form design (form in editable mode).

-Greg

SanfordWhiteman
New Participant
June 5, 2018

You don't read Form Descriptorese yet, Greg?

SanfordWhiteman
New Participant
June 5, 2018

Please provide a link to your page w/form.

What you're describing isn't normal behavior -- especially the idea of the forms library mistaking URL params for cookies.