MKTO + AdWords - UTMS, Query Strings, and Multiple Forms | Community
Skip to main content
Spencer_Philli1
Level 3
March 20, 2018
Question

MKTO + AdWords - UTMS, Query Strings, and Multiple Forms

  • March 20, 2018
  • 2 replies
  • 4243 views

Hi all,

My team recently launched our first Adwords campaign. We created specific landing pages per ad group, and used a new Adwords-specific form thinking that people will land, fill that form out, and we'd be able to attribute lead source to AdWords. Easy, right?! That thinking turned out to be too good to be true...

In reality, we are finding that people land on the landing page, don't fill out the Adwords specific form, browse around, then fill out our "general" site wide form on the site...which makes sense!

The problem with this is that the UTM params are not carrying over from the page they initially land on over to the "general" form they end up filling out.

My solution was the following: I added a constraint to the general form, with the constraint being query string = to our UTM code, then in the Flow, inserting a change data value where if UTM Source = Adwords then attribute lead source to Adwords.

I know there are many posts on this, and many ways to achieve this but am wanting to know if this is 1. a feasible way to attribute lead source and 2. if there are any reccos on how to do this differently and or better.

Below our some screenshots:

1. Our sales alert with the UTM params section of the email empty - sad but not really surprising. I believe this is because the UTMs were "lost" when this person left the Adwords landing page, then went to to our general form. Please correct me if that is not the case.

2. Lead details: Same thing - UTMs not populated due to the fact that they did not transfer across our URLs. The default sources populated.

3. Activity log, first activity of "Visit Web Page": UTMs fully tracked in Query Params!

Why would the UTM params be full tracked in the Query Parameter section but not captured by my hidden UTM fields on the general form - is it because of what I think it is: The UTMs don't carry from one URL to another so the general from doesn't populate them? How would I go about capturing UTM regardless of which page the land on?

Secondly, is my solution of adding the restraint of query string to the general form and changing data value of lead source to Adwords based on query param the right way to go about this?

Thank you!

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

2 replies

Josh_Hill13
Level 10
March 20, 2018

There are several threads on passing parameters from the first page across to others.

You need your script to handle this.

SanfordWhiteman
Level 10
March 21, 2018
March 23, 2018

Hello, Sandford. My name is Claire and I work with Spencer here at Opal as the web developer. I implemented the code that you wrote which saves the UTM codes in local storage yesterday. What we are wondering is once that information is saved onto local storage, is it automatically being populated to Marketo or do I have to add some additional code? We received a form fill this morning from someone who landed on our AdWords page and ended up filling out the form on our homepage. The UTM params did not pass through to Marketo as we had hoped.

I put your code between our script tags that are specific to the adwords landing page because I didn’t want to install it globally and have local storage be burdened with multiple UTM captures.

Where is the data falling through the cracks - would implementing code globally fix this issue?

@Sandford Whiteman​

Dan_Stevens_
Level 10
March 23, 2018

You will still need to physically capture those values in hidden form fields (and probably create smart campaigns to process them even further).  The reason why it's advisable for additional processing is to keep those values persistent when those leads respond to future campaigns - and overwrite their original value.  In our instance, we have three custom fields for each UTM parameter: one for first touch (once written to, it's locked); one for last touch (rewritable) and a history field for multi-touch.  We actually adopted many of @Erik Heldebro​'s best practices here: First, Last and Multi Touch attribution for UTM parameters and auto tagging emails .  There are several other docs and ideas around UTM management here on the community.