Real-life landing page stories: Checking "Serviceable area" based on lead zip code

This is part of an ongoing series, “What can LiveBall do?”, where we explore unique ways that our customers use LiveBall to solve technical and marketing challenges.

One of ion’s long-time customers has developed a robust landing page program in LiveBall for multiple service-oriented brands. Their landing pages generate leads for major, national brands that provide services like house cleaning and pest control. A while back, they were faced with an obstacle because a significant percentage of leads were being exported to the sales field that did not live in a ‘serviceable’ location. The customer needed a way to prevent these bogus leads from reaching the field and also a way to create a positive user experience for the audience that isn’t serviceable.

In order to accommodate, LiveBall would need to know if the zip code the respondent provided is a serviceable location, in real time. No problem!

LiveBall can communicate with web services or third-party systems that manage data. This is accomplished by performing an http POST of the key data, and in turn, the external system returns a result in an XML response. In this case, LiveBall immediately POSTs the respondent’s zip code upon form submission. The customer’s web service then returns a “true” or “false” value that indicates if the respondent lives in a serviceable area or not.

Advanced rules (a LiveBall no-code set of logic) are used to control the experience based on the XML response. If the response is “true”, the lead is included in an immediate export to the sales field. They are also served-up with a confirmation page indicating they will be contacted shortly. If the value is “false”, the respondent data is not exported to the sales field. These non-serviceable respondents are then served-up with a targeted page that explains they do not live in an area where the services they’re interested in are offered. It’s a much better user experience for this audience to be informed immediately that they aren’t serviceable, and also saves the field from making calls that will never result in a sale.

This awesome integration was recently leveraged even further! Since the web service already knows the city and state the lead lives in based on zip code, these fields are also returned in the XML response. For those respondents that return a “true” value, their city and state will automatically be parsed from the XML response and included in the data export! This is excellent for a few reasons, but mainly because it reduces the length of the form the respondent is asked to complete (the form no longer needs to include city and state fields).

We’re excited to see what the shortened form does for this customer’s conversion rate. We’re also excited to see how other customers will use the ability to communicate with external platforms to create optimized and targeted experiences for their respondents!

Real-life landing page stories: Capturing, storing and deleting sensitive data

Data security is of the upmost importance to LiveBall customers. We recently onboarded a new LiveBall customer that came to us with restrictions around how their data is managed. They were concerned their corporate legal requirements for storing user data might prevent them from using a Software-as-a-Service solution like LiveBall. 

These requirements have been a marketing obstacle in the past—essentially a roadblock to using external tools and vendors for landing page creation & testing. But the customer knew they needed an agile process for managing their landing pages. The marketing team’s goal was to find an automated solution that could accommodate legal’s requirements and cut-out the legwork they were currently faced with. Here’s their requirements (a.k.a time-consuming obstacles for the marketing team):

1. Any user data being stored, even temporarily, must be encrypted.
2. Data must be deleted immediately upon delivery to their back-end system, and in an automated fashion.
3. Although the personal visitor data (like name, email, etc) couldn’t be stored, aggregate analytics & metrics needed to be stored so that landing pages can be tested and optimized.

LiveBall was the solution!

To everyone’s delight, described below are the features that accommodate these data requirements: 

1. Data fields in LiveBall can be marked for encryption. LiveBall uses the AES-256 encryption standard. The NSA defines this level of encryption secure enough to protect national security data classified as TOP SECRET. So, your data is safe with LiveBall and you can hand-select which fields need to be encrypted. Encrypted fields will automatically decrypt upon data export.
2. Manually deleting data after it is exported to a CRM or back-end system would be time consuming, unmanageable and risky. LiveBall offers some awesome options that do the work for you. You can mark your data collection fields as “sensitive” and with a click of the button tell LiveBall to delete this data after it’s been stored in the console for a certain amount of time. The time window for storage ranges from 24 hours to 4 weeks. A good deal of LiveBall customers immediately export visitor data upon form submission. If this is sensitive data that must be deleted immediately, you can use an advanced rule (a no-code set of logic) to tell LiveBall to delete the lead’s data immediately after a successful data export.
3. Being able to encrypt and delete predetermined data automatically is amazing, but how will this impact your optimization efforts? You need to hang on to visitor records so that you can split test and run multivariate experiments long enough to determine winners, analyze your results and optimize! The beauty of LiveBall’s data-deletion features is that your sensitive data is removed, but the visitor’s base record will remain.

You can still use all of your super powerful performance gauges to analyze results. You may have your split tests and MVT experiments set-up to run with the “automatic optimization” feature. If so, LiveBall will use statistical significance, based on a confidence level you select, to determine winning creatives and/or page combinations. These tests will not be affected when you choose to have LiveBall delete your sensitive data automatically!

Extremely strict data requirements can be a challenge to meet. LiveBall’s feature set gives you the tools to protect and delete predetermined, sensitive data automatically, which is a powerful bonus. This bonus can put “the suits” at ease and, best of all, interactive marketers can still work towards their conversion optimization goals by testing! You don’t need to let corporate data requirements stand in your way. 

Real-life landing page stories: FaceBook "don't allow" testing and tracking

Have you ever started to use a Facebook app, but were scared away by the “Request for Permission” message that you’re required to “Allow” before you can proceed?

If you want to play a game or use an application, you’ll be asked to allow the app access to your personal information and the app will request permission to send you emails. You may ask yourself, “Do I really want use the The Golden Girls Quote Generator that badly?” Probably not, but what if we twisted your arm just a bit? 

Facebook allows you to control the page the user lands on after they click “Don’t Allow.” Typically, one that clicks “Don’t Allow” will be directed to their profile’s home page. One of our customers (that is in no way, shape or form related to the Golden Girls) came to us with a neat request. The conversion metric for this customer is when a user allows the application then completes a game tutorial in Facebook. The customer wanted to test serving-up a landing page to respondents that click “Don’t Allow” against the redirect to their profile’s homepage. No problem!

In LiveBall, we have landing page templates that meet the spec size requirements for Facebook’s tab i-frame. A landing page was rolled out using this template. Messaging on the page assured the user that their personal information wouldn’t be shared and reinforced how cool the app is. The page also included a social widget that lets the user go ahead and “like” the app. If the user decides to proceed, the landing page links them back to the “Request for Permission” screen. Pretty neat, right?

The customer is able to track Facebook conversions back to their LiveBall console by placing a LiveBall tracking pixel on the final page of their tutorial. They can also see if a user drops-off during the multi-step tutorial by adding a tag pixel to each step in the process. The way the respondent navigates through their funnel and the conversion metric can all be kicked-back to LiveBall in real-time and analyzed to create optimized version of the “Don’t Allow” page.

The cool thing about pulling LiveBall creative into Facebook’s i-frame editors is the ability to easily test and optimize. Testing pages in Facebook is as straightforward as testing a standard landing page. To split test, you can allocate traffic across a test group with just a couple clicks. LiveBall will split the traffic for you at the URL. You can easily set up Multivariate tests for your Facebook pages too.

In this case, we needed to see if the 50% of users that are driven back to their Facebook homepage ever decide to allow the app after all, without the gentle arm twisting of the landing page. Setting up the test was a breeze. Here’s how we guided the customer through the set up:

1. The customer added LiveBall’s tag and conversion pixels to their app.
2. They created a tracking URL in LiveBall that allocates half the traffic to the Test page and the other half to an automatic redirect to the user’s Facebook home page. 
3. This tracking URL was pulled into Facebook via their i-frame editor and we let the testing begin! 

We’re seeing more and more customers leverage LiveBall for testing in Facebook and we see a steady stream of customers adding social proof to their pages.

LiveBall supports FaceBook Connect, which allows users to post to their FaceBook news feed from your landing page. There are also really slick and easy-to-use LiveBall widgets available so visitors can “like”, tweet and share across social platforms. I don’t know what Blanche, Dorothy, Rose and Sophia would say about this since I never allowed that Golden Girls app, but we here at ion think it’s awesome.   

Real-life landing page stories: routing web leads based on zip code

We were recently onboarding a new LiveBall customer when they approached us with a request that would alleviate a major pain point for them if we could solve it. This customer had always wanted zip code lead routing implemented for their web leads but hadn’t been able to get this functionality in place previously. When we heard what they needed we were confident we could come up with an efficient solution with their LiveBall console.

The request:

Based on the zip code a lead enters on the landing page form, the customer wanted an immediate notification to be delivered to the corresponding sales agent in the field. There are thousands of field agents, and each have about ten to twenty postal codes assigned to them.

There’s definitely urgency around getting a lead to the appropriate sales agent while they’re still hot. Working with an extremely large serviceable area as well as a large field of sales agents can create a delay in lead routing and assignment, especially if you’re relying on an outside vendor or platform to sort and deliver these leads. We wanted to assist in making this process as automated, seamless and fast as possible—making sure the lead was in the field reps hands right away.

The solution:

In LiveBall, you can send an immediate, automatic lead notification to a set of email addresses, but delivering the lead notification based on something as granular as postal codes required a unique solution. To tackle the customer’s request, we decided to use LiveBall’s Lookup Table feature to manage relational data right within the LiveBall console, combined with a Scriptlet (a custom piece of Javascript that helps non-technical marketers accomplish advanced functionality in LiveBall). Here’s how it works:

1. A .csv file was uploaded to the customer’s LiveBall console that contains all the applicable postal codes and a corresponding column with the sales agents’ email addresses.
2. We created a Scriptlet that calls the appropriate email address from the Lookup Table, based on the lead’s zip code.
3. Simple advanced rules (no, that’s not an oxymoron—it’s true!) were added to the form to run the scriptlet and deliver the notification. 

Here’s what the rules looked like:

It may look like greek to you, but we walked the customer through this simple set up and they were good to go!

So, with three simple steps this advanced functionality was implemented—powerful stuff without complex, custom coding. The end result:  A visitor submits a form and immediately the sales agent assigned to that visitor’s zip code receives an email containing the information the lead submitted.  

LiveBall’s LookUp table feature is flexible and can accommodate a variety of advanced functionality. In turn, a Scriptlet can be used to call data managed in the table and perform actions based on it. Aside from lead delivery, super cool things like conditional content substitution can be accomplished.  

It’s always fun to see how LiveBall customers leverage these powerful features. 

Real-life landing page stories: don't let the back button go back

Don’t you love last-minute landing page problems? It usually goes like this: everything is all set to launch and then at the last minute a few extra technical requirements are thrown in to the mix. How you adapt to those last-minute wrenches can make or break your launch timeline and even your campaign results. Here’s a real-world example of one such last-minute showstopper that happened this week for a LiveBall customer and how they overcame it.

The background: This is a long-time LiveBall customer—running about 150+ landing pages across about 50 unique traffic sources at any one time. They create a lot of pages and move with tremendous velocity. Each landing page launch is met with “Now, let’s get started on the next one”. Essentially, all of their campaign traffic across PPC, Social and Mobile goes through landing pages that they test & optimize. This customer has about 10 brands. They have a single set of custom page templates that they use across the 10 brands—using themes to easily rebrand any template with another brand as needed. This enables them find page layouts that are effective for one brand and then roll it out instantly to the other brands by switching out the brand-specific content and swapping the theme.  

The situation: This week they were launching a new product and had developed a set of landing pages for paid media. The pages for this launch were focused on capturing registrations. Once the visitor filled out the registration form they would go on to a download page where they could install the product. In order to execute this launch in LiveBall the customer did the following:

• Created a new brand theme and uploaded it to LiveBall.
• Applied the new theme to some  existing LiveBall templates that they knew would work well from previous tests in other brands. 
• Added their content into the templates (images, copy, a video, etc).
• Created a form in LiveBall (no-code required, of course!) for the registration and added it to the page.

Of course, no code needed for any of the above, except for the creation of the brand theme which their designer created and uploaded to LiveBall (they create it once and then re-use it over and over across all the pages they create for this product).

So far so good…pretty straight forward stuff. Until…

The problem: The day before the scheduled launch the customer called to say they had encountered what they thought might be a show-stopping wrench. They wanted to see if we had any ideas of how to get around this obstacle. The executive team in charge of the product launch informed them that the product couldn’t be downloaded by visitors who were under the age of 13. They needed to add age verification to the form. Plus, they needed to ensure if someone completed the reg form and was under 13 years of age, if they hit their back button they couldn’t get back to the registration page and just change their birthday to gain access by faking their birthday. 

Hm, so a standard registration landing page quickly turned into a landing page that needed to verify the visitor’s age and prevent access to the download page for those under the age of 13. 

The solution: Under normal circumstances requirements like these would require some last minute coding from a developer. But with LiveBall, both requirements could easily be accommodated, without code or developers. The account team was even able to guide the customer through set up of this functionality in about 30 minutes. Here’s what the customer did in LiveBall to make it happen:

• Added fields to the form to collect date of birth. 
• Added a “scriptlet” to the form that calculates age, based on the form field. Scriptlets are tiny snippets of code that live in your LiveBall library and can be added to your LiveBall pages as needed through a simple drop down. In this case, we already had a standard scriptlet for checking age, but if we hadn’t, the customer, or the ion team, could have simply created a custom one to handle it.
• Added a no-code advanced rule to the form that said:
  • If the age of the visitor is greater than 13, send visitor to the “download” page.
  • If the age is equal to, or less than, 13, then redirect the visitor to the “don’t allow” page. 

LiveBall advanced rules allow you to create custom if/then logic to your LiveBall pages without needing any code or developers. The “download” page was the standard thank you page that a visitor would arrive on after registration where they could then download the file. The “don’t allow” page was a page that informed the visitor that the download was only available to users older than 13. 

And there’s one more thing that needed to happen (isn’t there always?). If the age of the visitor was 13 or under, the customer didn’t want visitors just hitting their back button on the “don’t allow” page to get back to the registration page where they could just fake their date of birth to gain access. No problem, they just:

• Added an advanced rule to the initial landing page that said:
  • If the age of the visitor is equal to, or less than,13, then redirect the visitor past the registration page back to the “don’t allow” page. 

Here’s what it looks like in LiveBall to set something up like this:

No-code advanced rules let you create custom logic for your landing pages

So, although the blog post is long, the steps to create the solution actually only took about 30 minutes to set up and QA, including changing the form, adding the scriptlet, setting up the advanced rules and testing it all to make sure it worked as expected. The customer didn’t need to bother their already overloaded IT team to develop a solution and were able to meet their launch deadline, despite the last minute requirements. Voila, problem solved!