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