Import GA information to Salesforce – Part 4, Setting up Salesforce and GA

With Salesforce you can create a web form to create up to 500 leads daily from data entered via your website; the information ist posted to Salesforce, and the user is directed back to a page in your website. To make this work you need to create some custom fields for the lead entity – one to store a key that can be used to join Google Analytics data together, the others as empty fields that will be filled in with the information pulled via the GA API.

Setting up Custom Fields in Salesforce

To create custom fields for lead you need the appropriate permissions (in the Developers edition you are admin by default, in an productive environment you’d have to ask your admin). Next click the small “setup” link in the upper right, scroll down until you find the “build” section in the lefthand menu, expand first the “customize” and then the “lead” section and then click the first item in that submenu which should be “fields”. Click here, and on the resulting page scroll down a bit until you see a headline “Lead Custom Fields & Relationships”. Click “new”.

Next you’ll see a selection of possible field types. I will not go into any detail – you are looking for the “text” type, since you need to store single line strings (“Text” should be way down in the list between “Picklist” and “Text Area”, which is a multiline input).

On the next page you see a form with the inputs marked red – these are the required inputs, the other fields are optional. The “Label” is the name by which the field appears in the SF interface. Length is max. length of the string you can store in this field. Name is the internal name of the field – it must not contain whitespace or special characters. If you leave this empty SF will generate a name based on the label. The input is supposed to be unique per lead, so we have to tick the “unique” checkbox (and to make sure we make this case insensitive).

First we need a field to store an id that is used to join the data from GA, so somewhat unimaginatively I’ve named this “gaid” for the purpose of this tutorial:


Note the checkbox where is says “Set this this field as a unique record identifier from an external system”. For our gaid field this must be checked, as it indicates that we want to use this as a key to join Salesforce data with external data sent via the API.

The next two screens are to set permissions (i.e. what users roles are allowed to look at or edit the field) and page layout (i.e. where in the lead edit interface is the field located). Simply click “next” and “save” respectively.

Repeat the process for three more fields and name them “source”, “medium” and “campaign” respectively, only this time make sure the “unique” checkbox is cleared (campaign info is by definition not unique, else we could not use it to aggregate data) and the “set as unique identifier” ist not checked.

Setting up a Web to Lead Form

The HTML needed for the lead form can be generated from within Salesforce. This makes sure that the form action and the field names are all correct. In the build/customize/lead submenu click the item labeled “Web to lead”, and then click the button that says “create Web to Lead-Form”.

On the next page you can choose which fields should be included in your form. For this tutorial I’ve limited the field to first name, last name and e-mail. You also need to include the custom gaid field (but not the source/medium/campaign fields which will be filled in later by our program).

The “Generate” button then produces the necessary HTML code.

Note that this has automatically created a hidden input with a name of “oid” – the string in there identifies your particular Salesforce instance, to make sure the data is stored into your account. To make this more compact we can remove the comments, plus your should make the “gaid” field a hidden input since it is not intended to be filled in by the user (it is not actually called gaid here but has a cryptic name, but you can identify it by its label).

The result should look something like this:

<form action="" method="POST">

<input type=hidden name="oid" value="00D24000000jJhn">
<input type=hidden name="retURL" value="">

<label for="first_name">First Name</label><input id="first_name" maxlength="40" name="first_name" size="20" type="text" /><br>

<label for="last_name">Last Name</label><input id="last_name" maxlength="80" name="last_name" size="20" type="text" /><br>

<label for="email">Email</label><input id="email" maxlength="80" name="email" size="20" type="text" /><br>

<!-- this is the custom gaid field -->
<input id="00N2400000Hgnfq" maxlength="255" name="00N2400000Hgnfq" size="20" type="hidden" /><br>

<input type="submit" name="submit">


You add can add your own css classes and HTML markup to change the layout, but do not change the field names.

Setting a Value for the Key Field

Now we have almost arrived at the good bit, where we actually import the data. One last thing is the value for the key field.

In theory you can use any string, but you have to make sure that there are no collisions (i.e. that the same string is not used more than once), and you must not use personally identifiable data (PII). The value for this field will be stored in both SF and GA, and Google’s term of service do not allow to store PII within Analytics.

As we need an unique id, so the best idea would be to generate a string in the UUID format – however in this example I have given sequential ids in the format “ua12345” (it’s less to type than a UUID).

You need to set the value to the custom gaid field in the Web-to-Lead form , if possible via some serverside mechanism:

<!-- this is the custom gaid field -->
<input id="00N2400000Hgnfq" maxlength="255" name="00N2400000Hgnfq" size="20" type="hidden" value="ua12345" /><br>

Next you set up a custom dimension in Google Analytics. The process is a bit similar to setting up a custom field in SF. Go to Admin, Property, Custom Definitions, Custom Dimensions and click “new”.

Enter a name (it’s easiest, but not necessary to use the same name you used in SF) and select “hit” as the dimensions scope. This means the dimension is stored for a specific interaction, not for all user interactions within a session.

If you want to send a custom dimension you do not refer to it by it’s name – that is only used in the interface. Instead you use a numeric index (first custom dimension is 1, last in a free GA account is 20) and prefix this with the word “dimension”.

Now if you attach the following event tracking code to the submit event of your Web-to-Lead form:

ga('send', {
hitType: 'event',
eventCategory: 'Lead',
eventAction: 'submit',
eventLabel: 'Some Lead !',
'dimension1': 'ua12345'

and pass the same value to “dimension1” as you have assigned to the gaid field in the form you have created, via a field with the same value, a connection between the recorded data in GA and the newly created lead in Salesforce.

We are finally approaching the point where we can join one dataset to the other. The next part will show the completed Python program with information on how to configure and run it. Subsequent installments will break the script down step by step to discuss which lines are responsible for what action.

Tutorial Table of Contents

2 thoughts on “Import GA information to Salesforce – Part 4, Setting up Salesforce and GA

  1. Great Article, very helpful. This is exactly what I want to do. But there is one thing I do not get. How do I create a custom dimension that is filled by a random ID? Do I have to add code to a cookie? And what is that ua12345 exactly?

    1. “ua12345” is just some random value. The format is not important (as said in the text, a UUID would be make sure that two people don’t get the same id, but really any random value will suffice), the important thing is that it is the same in Google Analytics and in Salesforce, because this is the key by which the data will be joined later. On easy way to get a unique value would be to use the value from the Google Analytics (_ga) cookie. Btw. be warned that while the principle is sound the tutorial is not necessarily up to date – this uses a p12 file for OAuth credentials, I think recent version of the Client library accept only JSON, so you’d need to adapt that bit.

Leave a Reply to Paulien Cancel reply

Your email address will not be published. Required fields are marked *