Knit One, PURL One: Merge Marketo PURL Records with Anonymous Records

Direct mail is a powerful, personal marketing touchpoint that often makes a memorable impact on recipients, and Marketo has a feature to associate direct mail response to known Marketo Person records: PURLs.

PURLs are valuable.

PURL is an acronym for Personalized Uniform Resource Locator. Perhaps more recognizably, it is a Personalized URL. A PURL in Marketo will typically follow this format: 

  • https://landing-page-subdomain.example.com/landing-page-name.html/RecipientName

These examples show what this might look like in print to a direct mail recipient. (Note that the “.html” portion of your Marketo landing page URLs is optional and can be safely omitted to make a cleaner, easier-to-type URL.)

  • info.companydomain.com/freegift/JonBourne 
  • lp.abccompany.com/fishingtrip/JaneDoe2
  • pages.acmeco.com/jeepride/JohnSmith12

The last part of the PURL comes from a Marketo system field called Marketo Unique Name. Each Person record, whether known or anonymous, has a unique Marketo Unique Name value, so by including this field’s value in a URL, the individual Person record that corresponds to it can be identified.

And in a perfect scenario, the PURL references a known Person record, and lead tokens can consequently be rendered on the page to personalize the experience to the recipient of the direct mail piece to which she is responding—Hi {{lead.First Name:default=there}}!

But there’s a catch.

Certain scenarios surrounding the use of PURLs with Marketo can leave the marketer in an unfortunate dilemma. The scenarios all center on the recipient of the direct mail piece also having a Munchkin cookie in their browser; if they visit a PURL in a browser that already has a Munchkin cookie, lead tokens rendered on the page will reflect the cookied Person record and not the PURL record.

If the cookie corresponds to an anonymous Person record in Marketo, lead tokens are blank, so the PURL’s promise of personalization remains unfulfilled. Clearly, “Hi there!” doesn’t deliver on the personalization the marketer was hoping for.

If the cookie corresponds to a known Person record that is different from the PURL record, then the known Person record’s data will populate the lead tokens on the page. If the direct mail respondent types a PURL ending in JaneDoe, it is possible that she might instead see “Hi Stephanie!” on the landing page.

Although unlikely, and aside from the obvious user experience faux pas these scenarios represent, the consequence of this unexpected gotcha is that the direct mail response cannot be properly measured. In Marketo, the Web Page Visit activity is recorded on the cookied Person record rather than the PURL record.

A hidden PURL gem.

Happily, Marketo provides a simple but little-documented way to overcome this obstacle. Marketo has a mechanism to merge anonymously cookied records with PURL records using an intuitively named cookie called _mkto_purl. When the _mkto_purl cookie is present and true, Marketo allows the PURL record to override the anonymous cookied record. It simply renders tokens for the PURL Person record and merges the cookied anonymous Person record, if present, into the PURL record.

So that works great if the cookied record is anonymous, but what if the cookied record is known? 

And for that matter, how do we even know from just the Munchkin cookie ID whether the cookie represents a known or anonymous Person?

Well, if the Person has an email address, it’s safe to say that they’re known. Conversely, if the Person does not have an email address, it’s reasonable to say that the record is anonymous. (There are likely exceptions to both of these presumptions in most Marketo instances, but we’ll i proceed with them nonetheless!)

But Marketo landing pages themselves don’t natively allow for this kind of if-then logic. What to do?

There’s a script for that.

Fear not, valiant marketer! JavaScript can save the day! With a clever bit of script-trickery, we can check for the various scenarios and respond appropriately with actions to remedy them.

  1. Scenario #1 — No Munchkin cookie
    If there is no cookie in the browser, then no action is necessary; the PURL will function as expected, the page can be customized as expected with lead tokens, and the form will prefill with the correct information.
  2. Scenario #2 — Anonymous Munchkin cookie
    If there’s an anonymous Munchkin cookie in the browser, all we need the script to do is set the _mkto_purl cookie and reload the page. After reload, the PURL field values will display on the page via tokens and prefill the form as expected, and on the back end, the anonymous record will be automagtically merged into the PURL record.
  3. Scenario #3 — Known Munchkin cookie that matches PURL
    Clearly, if the cookied record is the same as the PURL record, then there’s no action necessary. The marketing response will accrue to the correct record, and the page personalization and form prefill will align with the direct mail piece that the person received.
  4. Scenario #4 — Known Munchkin cookie that does not match PURL
    This is the least ideal situation: when the cookied Person is both known and different than the PURL Person. Cue sad trombone—wha, wha, wha, whaaaa. (There may be a larger issue to investigate here, but that’s outside the scope of this post.) In this case, we want to delete the Munchkin cookie, set the _mkto_purl cookie, then reload the page. The PURL functionality will work as expected, but the prior web activity will accrue to the other known record.

Knit One, PURL One

So, how do we set up this script to knit one (anonymous) Person record together with a PURL record? (That’s a knitting reference/joke, in case you’re not in on it. YouTube it.)

What’s in the script?

First, Part A of the script must be place directly into your Marketo landing page (or template). It can go in the head section of the page, either by editing the landing page template or in the Marketo landing page editor under Landing Page Actions > Edit Page Meta Tags > Custom HEAD HTML.

Second, Part B script should be saved as digitalpi-knit-purl.js in your Design Studio. Then, include the file in a script at the bottom of your landing page, just before the closing body tag. (This is where it probably makes more sense to add it to your landing page template, but you could also place it in an editable text area at the bottom of the page. If you don’t have an editable area on the page, it should work in the same Custom HEAD HTML box where you placed the Part A script.) Alternatively, you could deploy this script in Google Tag Manager, Adobe Dynamic Tag Management or similar tool, if you’re so inclined, but such a deployment is out of the scope for our purposes here.

And that’s it! The script(s) will do the rest from there.

Your marketing technology experts.

At Digital Pi, we use technology to connect revenue to marketing efforts. We fuse marketing strategies, processes, data and applications to make marketing technology solutions work for clients' businesses.

Learn More
Share this resource
Facebook
Twitter
LinkedIn
Tags

Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.