UTM Parameters not get updated via background forms submission | Community
Skip to main content
R
rajanikantsaner
New Participant
December 23, 2020
Solved

UTM Parameters not get updated via background forms submission

  • December 23, 2020
  • 1 reply
  • 5154 views

Hi Team,

 

On website forms, we have added background form submission code to submit data to Marketo. once someone fills the forms also we are tracking utm parameters, same time we want to send notification to internal team with forms fills data also tracking UTM parameters. User fills data and UTM parameters get captured properly within Marketo but when we set smart campaign to send notification to internal team we created email template with token of forms fields added within email to send dynamic data but its pulls the previous data and sent within notification.

For. X user comes with UTM parameters like utm_source=XYZ, utm_campaign=123, utm_medium=ABC its stored within marketo and send in notification email but if next time UTM parameters values changes or UTM parameters are blank then it will not reflected within email notification its will pulled old UTM values from marketo and send in notification email which is wrong. Can you please suggest how we can achieve this so we can get updated values of UTM parameters it might contain different value or may be blank same should be updated in marketo as well as in notification email.

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

Hi ,

I still not clear how to manage blank or different value changes in sending internal alert.

 

Waiting for your reply.

 

Regards,

Rajanikant


Set the default value for all those fields to NULL (the four-letter string "NULL").

 

If the fields still don't get cleared, it's because you've blocked field updates in Admin.

1 reply

Katja_Keesom
Katja_Keesom
Community Manager
December 23, 2020

Hi there,

There are two things that come to mind straight away:

  1. A field on a form that is not populated will not overwrite a value that was already there to NULL. That explains the blanks not being blank.
  2. When it comes to a data value change, the actual processing of this can take a little bit of time. If you have confirmed the data value change was actually processed on the lead record, but the internal alert showed the old value my suspicion is the alert is sent out before the data value change is processes. If you insert a wait step in your flow just before the Send Alert of a few minutes that should do the trick.

Hope this helps!

SanfordWhiteman
SanfordWhiteman
New Participant
December 23, 2020

I wouldn't advise a Wait step here.

 

A simple Filled Out Form is synchronized with the data value changes from that submission.

 

It's not necessarily sync'd with changes from additional nearby submissions for the same lead, and with complex cases of constraints and choices, race conditions are a definite concern.

 

Most likely the problem is (1) as you said, or that field updates are blocked (not at all a bad idea with UTM fields, unless they are separately moved into history/multitouch fields).

Katja_Keesom
Katja_Keesom
Community Manager
December 29, 2020

Good point. That still has me wondering though. The original question not only refers to value to blank changes (which is expected behaviour), but also value to different value changes that is not shown in the internal alert.

As you are right about the fact that the form values are stamped in the log just before the actual form fill activity, this value change should have come through at the time of sending the alert.

 

As an aside: You could start using program specific fields for this purpose from next month, so your utm values are stored for each program separately. That would also solve the value to blank scenario. With the new January release you can use PMCF fields as tokens, so you can populate your alert with the values. There still are some drawbacks where it comes to reporting, but I know the team are also working really hard on solving those.

Terms & ConditionsAccessibility statement

Loading footer...