Delay in form data writing to database

[Anonymous]

Has anyone experienced a problem with form data being delayed between the submission of the form and the follow up landing page?

We rely on passing token data through our forms when someone submits, and for the last 2 days we've had an issue where the thank you page loads faster than the form fill data gets written to the database, so where we use tokens shows either no information or old information. ex. "Thank you for downloading [XYZ asset]" now shows either the default value for the token, or the value of the previous asset the person downloaded.

In order to slow down the page load and give the form data time to get through, we created a redirect from a our default TY landing page to a clone of it, and that is working for the most part.

Marketo is working on the issue but taking a very long time, wondering if anyone else has experienced or has a better fix.

[SanfordWhiteman]

There's never been a guarantee that the lead would be associated and up-to-date on the very next pageview. On loaded instances, it's not uncommon to experience such delays.

If the data you're displaying comes from the form post itself, just use the onSuccess event to populate the Thank You URL, since all the current values are always available there.

[Anonymous]

Hi Audrey Van Norman​

I experienced this issue and I found the strange workaround.

At Landing Page Editor, change "Follow-up Type" to "Landing Page" and set Thank-you page to "Follow-up Page".

I don't know the reason why this problem is fixed by this workaround.

And I tried onSuccess event handle but it was still happen.

Example

<form id="mktoForm_1234"></form>

<script>MktoForms2.loadForm("//app-ab07.marketo.com", "999-XXX-999", 1234, function(form) {

    //Add an onSuccess handler

    form.onSuccess(function(values, followUpUrl) {

        // Take the lead to a different page on successful submit, ignoring the form's configured followUpUrl

        location.href = "http://pages.domain.com/thankyou.html";

        // Return false to prevent the submission handler continuing with its own processing

        return false;

    });

});

</script>

[Anonymous]

Thank you for your info Takehiro! I've posted the response I got from Marketo support, it might shed some light on your case too.

[Anonymous · Accepted solution]

For anyone who experiences the same issue in the future - this turned out to be an issue with our TY landing page. The telltale sign is the allid parameter - if you have this issue and see your follow up pages loading without that parameter in the URL, double check that your landing page hasn't been cloned and there are not two entries for the URL.

Here is the explanation from Marketo support:

The allid parameter is appended to follow-up URLs after a form is submitted, and it allows for the page to query the lead data and populate the tokens accordingly. The only scenario when we don't add this parameter, and therefore the page doesn't "wait" until it has the lead data, is if the follow-up page is not a marketo landing page.

To determine whether a follow-up page is a marketo landing page or not, we use the internal web_asset table, which holds entries for every web page known to marketo. There are two ways that web pages end up in this table:

1- A marketo landing page is created; the associated URL is created as a web_asset entry. For this particular example, the is_landing_page value is set to true, meaning it's a marketo landing page.

2- A non-marketo landing page has the Munchkin code in its source, the first time the page is loaded on a browser, the URL is created as a web_asset entry. For this scenario, the is_landing_page value is set to false.

So, when a form is submitted and we prepare to serve the follow-up page, we look into the web_asset table to determine whether the URL is a marketo landing page or an external. The way the code is written, when we find a matching URL, we stop looking and we serve the page.

In this case, when we look at the web_asset table, we can see that there are two entries with the same URL of Download-TY, as follows:
web_asset Id = 15304 | is_landing_page = false | created_at = 2016-10-10 10:32:50
web_asset Id = 15496 | is_landing_page = true | created_at = 2016-10-10 19:26:13

The first entry, was created via the Munchkin code. In other words, there was a page in your domain with the URL of Download-TY, and because the Munchkin code was in its source code, it was added as a web_asset.

The second entry, was created when the landing page with Id was created, at the exact same time:
Landing page = XYZ
created_at = 2016-10-10 19:26:13

The flow then becomes the following:
a- Form is submitted
b- We look up the follow-up URL in the web_asset table
c- We find the first one, because it was created first
d- Because the matching URL is external, we do not append the allid parameter.

Finally, I cannot tell whether there was another landing page with the same URL before this one was created, but based on the data in this table, our conclusion is that the page was first known via Munchkin, and this caused the issue. This was probably done while testing the URL or something along those lines.

As far as why this was working before, we are unable to find any data that suggests that the same URL existed before and that it was working, but it could also be that it did exist but was renamed at some point, so what we see in the database is not an accurate representation of what the data looked like before the issue was reported.