MarTech Hacks – Dealing With Landing Pages

Those dread words:

“We’re gonna need a fresh landing page for this”

can mean countless hours of fighting over field definitions, working with IT admins and web developers to get the landing page installed and a fulfillment page in place, and then everything thoroughly tested, because making corrections in the middle leaves holes in your data set. You probably need a new landing page for every single campaign, yet there is never enough time allotted before launch to actually put it together without some serious anxiety.

Why are these so much harder to create than blog posts or tweet campaigns? Is there any way to make it easier?

Yes, with a better understanding of the connections that must be made and where the work has to be done, it is possible for determined marketers to do some of the work themselves, better explain their needs, and allow an appropriate amount of time for everyone to finish their work well in advance of campaign launch.

That’s a lot to promise. This is not a technology paper, the intent is to explain in simple terms the workings of this critical front-end lead gathering system simply called the Landing Page. We will show small amounts of code that we explain thoroughly, and there will NOT be a quiz, so relax, please.

Of course, there are many software platforms that incorporate the capability to create forms and landing pages, so we will stick to fundamental functions that are roughly the same over all systems, because in the end, they all have to produce some HTML to go on a web page.

Let’s get started….

We know that a landing page is where potential buyers are taken when they click the call to action link in an email message or some other promotional material, usually because they were promised some valuable content or service. The landing page has a form that the visitor fill out. The Visitor is then taken to a fulfillment page where he/she is usually able to download the content promised. In the meantime, the Visitors inputted info is stored in a database accessible by a marketing system that will market product to the Visitor.

That’s how it all works. Now WHY does it work?

HTML forms and how they work

A web form is just HTML with a very few special features. When a browser encounters a form, it displays the fields and the action button. If a Visitor fills out the form and hits the button, the browser packs the submitted field information along with associated field names into what is called a POST string and sends it to whatever URL is specified by the form for processing. A POST string in essence is just a series of field name/value pairs and the landing page the visitor is directed to after submitting the form. In this case the URL usually specifies not just the server that is receiving the POST string, but the actual process on that server responsible for processing the POST data. The most common thing for that process to do is store the data in a database for use by the website owner. Often the POST string contains identifier fields hidden from the Visitor who filled out the form, items like the unique identifier for the website owner who maintains the form.

That was a lot of explaining in a short paragraph. Let’s take the example of a company with a website that wants to use a form to collect leads that will go in a Customer Relationship Management (CRM) system. Like most such systems today, the CRM is cloud-based, so it is running on servers the company does not control. In order for the company’s form to get processed by the CRM, the company’s form has to know the right URL to send the POST string to and often a user ID supplied by the CRM vendor. Field names in the form have to map exactly to fields in the CRM database. Last, the company and the CRM have to agree on the URL that the Visitor will be sent to for fulfillment after the form is completed.

The easiest way to get all this done is for the CRM vendor to supply the form code. Virtually every CRM, marketing automation platform, online email house and payment gateway has a form generator that is typically very easy to use. The form generator produces the HTML for a form with the correct action URL, identifiers, field names, return URL etc. all that need to be done now is paste the code in a web page and style it so it looks like it belongs on the site. This last is probably a job the Developer needs to do, and it depends very much on how the form code supplied by the vendor is “wrapped” in markup tags, and whether or not it has it’s own style sheet. Vendor to vendor there are a wide variety of approaches, the online mailhouse AWeber provides extensive style sheets, while Salesforce provides only the bare bones code.

So here’s the hack….

learn to generate the forms and hand them off to your Developer. Work with the Developer to build a few practice forms and test them until you understand the system. Some of the systems in use will actually email the code to a developer for you if you supply an address.

Because YOU are the one who knows what fields need to go in the form, you can speed up development considerably by taking on this task. The work you do on the front end will be more than compensated by less frustration in execution.

In my next post, I will discuss the dreaded opt-in, and why it works the way it does.