Passing Values into Hidden Fields via Cookie & Parameters

[Anonymous]

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?

[Victor_Herrero]

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]

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]

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...

[SanfordWhiteman]

The way google suggests you implement this

Which doesn't apply to all deployments by any means -- Google is not the place to look for robust integration advice because they couldn't care less as long as they're getting paid.

Also, GCLID (L) is what SFDC would call a field if you were to create it twice with the same name

Or if you deliberately had fields for each object type.

Again, bottom line is each session has a new gclid.  Since a thorough tracking + persistence library will store a separate copy of all tracking variables for each session, it would be expected that if you store the gclid at all you would have multiple variations stored.

[Grégoire_Miche2]

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

-Greg

[Anonymous]

Here is a link to one of the landing pages using the form:

Make Sellers an Extension of Marketing

The form is very long, but here is a screenshot of the fields in question:

[SanfordWhiteman · Accepted solution]

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.

[Seth_Wood]

Hi Sanford,

Your answers are always so helpful. We've been knocking about with this, unsuccessfully, and are hopeful that you might get pinged from this old thread if we follow up to your solution.  We are also very hopeful that you would be willing to toss a little advice our way on the matter. 😉

We can get it working just fine with the URL parameter method, but we definitely want the value of the GCLID on the cookie, so we attribute in case someone comes back and eventually submits the form. We believe we've set everything up correctly with the form for the cookie tracking on the hidden field, and are at a complete loss why the GCLID won't pass to Marketo. It never shows up on the person record.

Any ideas at all are more than welcome.

[Grégoire_Miche2]

On top of Sandy's points, the recommendation it really to handle these fields with some JS in the LP templates so that the end use designing the form do not even have to thing about it.

-Greg

[Anonymous]

Ahh- Thank you Sanford! Of course it was something as simple as approving the Landing Page. Still getting used to the intricacies of Marketo.

[SanfordWhiteman]

You don't read Form Descriptorese yet, Greg?

[SanfordWhiteman]

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.