When you set Thank You pages using JS, don’t forget the 'aliId' param

One of my favorite moments as a know-it-all subject matter expert is saying “Looks like your developer forgot the aliId, bad move.”

The aliId query parameter, unique to every form fillout, is automatically attached to Thank You URLs. You’ve probably seen it hundreds of times and wondered what it means:

https://pages.example.com/whitepaper-thank-you.html?aliId=eyJpIjoiWVdlaDg5K1wvNGFaaVVzamQiLCJ0IjoiKys4Z01jVWZ6SVU1aVwvSENTelQ0WEE9PSJ9

What is that thing?

The aliId is a one-time-use token that allows you to use native {{lead.tokens}} on Thank You pages[1]. Without it, since there’s no guarantee the Munchkin session will be associated with the person record by the next pageview, you will have an unreliable user experience.

In engineer-speak, the aliId brings Read-After-Write (RAW) consistency to form fillouts, meaning the data you just wrote can be read immediately, even if it’s still in the process of saving to the furthest back end database.

Again, all this happens automatically.

That is, unless you override the Thank You action using JavaScript.

Take this common bit of Forms 2.0 JS that reads the base Thank You URL from a JS variable[2], instead of using the Thank You from Form Editor:

const overrideThankYouHref = "https://pages.example.com/thank-you-whitepaper-1234";

MktoForms2.whenReady(function(readyForm){
  readyForm.onSuccess(function(submittedValues, originalThankYouHref){    
    document.location.href = overrideThankYouHref; 
    return false;
  });
});

originalThankYouHref contains the aliId, but it’s never copied to overrideThankYouHref. As a result, tokens will not be reliably displayed on /thank-you-whitepaper-1234.

It’s easy to transplant the aliId, especially now that the URLSearchParams API is available in all browsers:

const overrideThankYouHref = "https://pages.example.com/thank-you-whitepaper-1234";

MktoForms2.whenReady(function(readyForm){    
  readyForm.onSuccess(function(submittedValues, originalThankYouHref){
    const originalThankYouURL = new URL(originalThankYouHref);

    const overrideThankYouURL = new URL(overrideThankYouHref);
    
    const hasAliId = originalThankYouURL.searchParams.has("aliId");
    if(hasAliId){
      overrideThankYouURL.searchParams.set("aliId", originalThankYouURL.searchParams.get("aliId"));
    }
     
    document.location.href = overrideThankYouURL.href; 
    return false;
  });
});

Worth learning how to use URLSearchParams fluently. Delete your custom query parsing code (which is likely buggy) and join the standards-based club!

Notes

[1] Naturally, the aliId’s presence/absence only matters when Marketo LPs are used as Thank Yous, since non-Marketo pages don’t understand {{lead.tokens}} in the first place.

But — trust me on this! — you never know when you’re gonna switch between Marketo and non-Marketo pages. That’s ultimately based on your web team’s backlog. The correct practice, even though I violate it myself on occasion, is to always copy the aliId.

[2] The overrideThankYouHref would likely correspond to a page-level variable in your CMS, or might be fetched from a Google Sheet or other service. It wouldn’t truly be hard-coded… though it could be.