<!-- Content Here -->

There is no partial credit in digital marketing

• You sweated over SEO but forgot to set your robots.txt to allow. Fail.

• Your content is brilliant but you can't drive traffic to it. Fail.

• You bought all the right keywords but your content stinks. Fail.

• You have the content that a visitor wants but you show him something else. Fail.

• You target the right content to a visitor but the display gets in the way of his enjoyment of it. Fail.

• Your content goes viral but your site crashes. Fail.

• Your visitors are devouring your content but you wouldn't know because your analytics isn't tracking properly. Fail.

• Your visitors are ready to engage but they can't find a call to action. Fail.

• Your visitor fills out a form but the data goes nowhere. Fail.

• You are capturing leads but nobody is doing anything with them. Fail.

• You have valuable data but no actionable insight. Fail.

​

We have all been there. We focus on one aspect of digital marketing but neglecting another critical step eliminates our impact. To be successful, you have to be good at lots of things and pay attention to the details. It is better to be proficient in all of the dimensions of digital marketing than to be excellent in any one. So much for the hope that you are just "one viral video" away from achieving your most ambitious marketing goals. Welcome to the grind.

The Website is Launched, the Journey Begins

We have all been there. We launch a new website and, interspersed with general praise and appreciation, there are some hysterical complaints about trivial things like a word-wrap or a punctuation mark. The tone on these emails is similar to someone who just received their huge wedding invitation order and saw that their name was misspelled. They are mad and want immediate resolution to avoid mortal embarrassment on their special day. Ironically, it doesn't seem to matter that the old website was a total disaster. This site is new. It should be perfect.

If you are on the receiving end of one of these complaints, you know how easy the issue is to fix. You know it is nothing like re-printing 500 wedding invitations with gold leaf on expensive paper. You just edit the content in your CMS and republish. In fact, you fixed the problem in the two minutes that elapsed between receiving the urgent-flagged email and the frantic follow-up call. You also know that the content that is the target of the complaint has a shelf life of only a couple of days. In fact, you consider the entire website to be dynamic and constantly evolving. What you launched was not a bunch of static pages but new layouts, branding, and infrastructure to support your dynamic digital marketing program.

In retrospect, it is easy to see where the disconnect started. The internal audience for the site had not seen anything since they fell in love with the mockups. And the mockups were perfect — artificially perfect. The designer put in just enough text to make the layout look full, but not crowded. The PDFs that were distributed didn't depend on a specific screen resolution or browser. The audience was expecting to see those polished PDFs sitting in their browser on launch day; but what they got wasn't exactly the same. Add that to the fact that the web team appeared to vanish after the last site was launched and their anxiety is understandable.

How do we correct this? The number one thing you need to do is keep up the pace. You can't take a break after the new site is launched because that leaves the impression that the site is "complete." You know that launch day marks the beginning of a new phase of your digital marketing program, but if you act like you think your are done, you are bound to get into discussions with people trying to prove to you that you are not. The conversation invariably focuses on the site being "defective" rather than what it really is: a work in progress. Keep the site changing and be transparent with your road map. Regularly communicate with people who have ideas and update them on your progress.

Also, justify your decisions with data. When you relaunch a site, people will often look for their old content to make sure it is still there. If you removed it or re-organized their content, be prepared to explain why. The traffic was low, the content was redundant, the page was competing with more important pages on search results… these are all good reasons to retire a page. The fact that you can respond in this way shows that you are still engaged and moving forward in a thoughtful way. This will further re-enforce the idea that this is a journey and you are a competent and attentive driver.

Depending on your organization's culture and history, breaking out of a "print-final website" mindset might be easy or hard. Generally, the more web savvy your internal audience is, the easier it will be to change people's minds. The older guard will be more difficult to convince. Your line of reasoning should go like this:

Remember how perfect the last website seemed at launch? Well, it only seemed perfect because it was rigid. The designers got it just right and then locked it down through QA. But it was also brittle and it started to crumble from the moment we started to change content. New browser versions and platforms only hastened its decay. This new website is part of a program that involves continuous improvement. It will improve, rather than degrade, over time.

The key is to sell internal stakeholders on the idea that your website is a constantly evolving asset that will never be perfect but will be always be good (or even great). The site will adapt to changing organizational goals and audience expectations. Like the original meaning of the term "launch," putting up a new website should be considered the beginning of a journey, not the end of a project.

Related: Your Website is not a Project.

How frequently should we update our homepage?

I recently overheard a discussion that should have gone extinct years ago:

"We try to update our home page twice a month … you know … to keep it fresh"

In my early CMS days I used to hear this type of thing all the time when people were trying to justify the need for a CMS by quantifying how much they edit the site. Even then, I thought the idea that people would be pleased by homepage "freshness" was a quaint little fantasy. In the real world, nobody who matters cares about the fact that a home page has changed. The absurdity of the idea is reflected in this Onion article "Man Cruises By William H. Macy's Website To Check Out The Latest" (hat tip to Deane Barker for mentioning it at the Now What Conference).

There is only one reason to change your home page and that is to make it better. What do I mean by better?

• More Current

  Obviously, you don't want to have any outdated information on the homepage. If you were promoting an event, you want to replace that promotion when the event has passed. You may even want to replace it when it is too late for an attendee to consider going. If you have a new product that you want to push, that product should get top billing. If you have changed the way you describe your organization, that change needs to be reflected in the language on the home page. Being current is keeping up with with your content marketing strategy.

• More Compelling

  As I have said before, the only reason why someone visits your home page is because he does not know where to go. More intentional visits will come from deep links from search engines and other sites. Use this indecision to your advantage by driving the visitor to your goals. What content is the most compelling? You will never know until you test and that is where analytics and multivariate testing comes in. By the way, never do simple A/B testing. Always use an "epsilon-greedy" approach that allows the more effective option to automatically bubble to the top.

The simple rule is to never change content unless you have something better to show. But just because the rule is simple, it doesn't mean it is easy to practice. To follow the rule, you need to be producing current content that is in line with what your organization is doing; and you need to be hyper-aware of how your content is performing so you can continually improve it. Capriciously changing for the sake of change may make you feel productive and dynamic, but it isn't doing your organization any good. Never changing your home page is not a good thing either. It is a symptom of a stagnant organization and that is not something that you fix by regularly scheduled homepage changes.

Portfolio Rot

Image Source: There I Fixed It.

Jake Dimare, over at The CMS Myth, has a great post that speaks to the frustration that agencies feel after turning over websites to the incapable hands of their clients. Back in my agency days I used to call this phenomenon "Portfolio Rot." It was so bad that we used to take screen captures of new sites before they started to look like something you would see on There I Fixed It.

As bad as portfolio rot is for agencies, it is even more embarrassing customers. The discomfort builds over time as the site degrades until it ultimately reaches a tipping point that triggers urgency and budget for an expensive overhaul project. Tragically, the only thing that the project does not fix is the underlying problem: lack of operational capacity. At Lionbridge, we call the work of maintaining a site Global Marketing Operations. and I will be talking about all that goes into marketing operations at the upcoming Now What Conference. I hope to see you there!

Predictive Analytics for Marketing

As a consumer, the article "Predictive Analytics: The Power Behind Next-Gen Marketing"  sounds very encouraging.  To date, most marketing technology has focused on increasing the capacity of marketing departments: more marketing emails, automated interactions ..., which leads to a marketing strategy of throwing more at the consumer and looking for response.   Unfortunately, the most likely response a marketing organization is going to see is disengagement. After all, it is much easier to see an unsubscription than a conversion - particularly in a traditional business where details about purchase information are difficult to get.

At first this is going to feel invasive.  We hate the industry examples that the author presents (particularly credit scoring and health insurance); but I am hoping that predictive analytics will help marketers target their message to receptive customers who can genuinely benefit from the product or service.  Maybe this science will even help companies discontinue programs that nobody would want.

Localizing the Long Tail

Choosing the first few markets to localize your website for is relatively easy: look for the ones with the most obvious market potential. A U.S.-based company may start with U.S. Spanish and Canadian French and then expand into some of the larger European and Asian markets. A company that has some history as a global business, may already have a physical presence in those high-potential markets. Subsequent waves of expansion, however, create some trickier choices. Should your next market be Poland or Brazil? Maybe the Korea holds the most promise. The thing is that you just don't know true market potential until you try and it may take a while to realize whatever potential exists.

At Lionbridge, we recommend grouping your markets into three tiers:

• Tier 1: Highest Revenue

• Tier 2: Fastest Growing

• Tier 3: Everyone Else

Tier 3 represents the greatest strategic challenge. You want to have a good quality presence in as many markets as possible. After all, outside of your home market, every market starts out as a Tier 3. If you enter a market, you need to do it right with an effort that is worthy of your brand. You also need to commit to maintaining that site into the future, otherwise you will fall into the "time capsule syndrome" where your local market sites look like they were frozen in time ages ago. But you have limited resources and you don't want to divert spending away from markets where you are succeeding.

To get into as many markets as possible without breaking the bank, you need to manage your localized sites extremely efficiently. The best way to meet that challenge is to use a translation proxy in a pattern that I call "International Mini-Site."

When you use a translation proxy, untranslated content is going to show through in the source language. In an earlier post (Preventing Source Language Bleed-Through), I talked about preventing this from happening. But that assumes that you want to pay to translate everything into all of your languages — and your Tier 3 sites may not justify that expense (not yet, at least).

The international mini-site pattern is like the "international snapshot" pattern but, instead of translating the full site, you proxy a much smaller site that is designed to have just enough information to get traffic and build business. Brevity, efficiency, and quality are key themes here. The international site should be cleanly branded (adjusted for culture, of course), search engine optimized, and ruthlessly edited to remove content that has organically grown over the years on your main site. If your main site (with all of its press releases, careers section, case studies, etc.) is 1,000 pages, your international site could be as little as five pages. Just explain what business you are in, describe your products, and direct customers where to buy. I often see this pattern in conjunction with using a platform like Marketo for marketing campaign landing pages (which can also be translated with a proxy).

Once you have your international mini-site, you can easily manage your translation spend. You can make choices about whether to make a global edit that you will have to translate into all languages, or do some locale specific rewording to improve search result placement in a local market search. Most importantly, you can manage your Tier 1 and Tier 2 sites without worrying about the cost implications of having to translate new content into all of your Tier 3 languages.

Just because the international site is small, it doesn't mean it is not important and you don't have to manage it. On the contrary, you need to pay as much or more attention to it. Because you have less content to work with, every word needs to count. This is where many companies go wrong. They treat their international sites as redheaded stepchildren rather than strategic assets with potential to uncover new growth opportunities.  By staying small, you can be more agile and responsive.  You can focus more on each page to optimize the impression it gives.  You might even find that your main sites would be better served by a major Spring Cleaning.

Preventing Source Language Bleed-Through

When considering a translation proxy to localize a website, people often ask "if we change the content on the site, what will visitors see while the translators are working on the new translations?" Unless you are using machine translation as a backstop for untranslated content, your source language is going to show through. This is because a translation proxy doesn't cache full pages. Instead, they apply translations one fragment at a time. If it doesn't have a translation for a fragment, the translation proxy will register it as a new string to translate and send the original text through. This is a necessary trade-off to support dynamic websites. You can shorten the period of bleed-through by increasing your translation responsiveness and throughput, but to prevent bleed entirely you need apply one of the following techniques.

These two techniques are really just variations on the same theme of pointing the proxy at two versions of your site: one for content discovery and another one for production.

International Snapshot

The "international snapshot" approach is where you create a non-current snapshot of your production site for international audiences. Depending on your translation velocity, this could be anywhere from a day old to a month old or more. Content discovery and translation is still done on the live site. But when an external visitor browses the site, they are getting a proxy-translated view of the snapshot. There is no bleed-through from the snapshot site because by the time the snapshot is refreshed, all of the translation rules have already been published. Here is a picture

This is what we are doing for the new www.lionbridge.com website. We wrote some scripts to do a full snapshot of the site (code, database, and other files) to another virtual host on the same servers. If you are using a more sophisticated platform than Wordpress, you could probably set up another publishing target and just publish there when you want to update your snapshot.

Translate Staging

The "translate staging" option follows the same pattern as international snapshot. With translate staging, however, you do your content discovery and translation on the staging server (which has content which hasn't been published yet) so your translations are ready before you publish your content. Once your translation queue is down to zero, you can publish your source content to your live site and the translation rules will be waiting to be used.

With "translate staging," you need to make sure:

1. Your staging site is publicly accessible. You will not be able to view the site through the proxy unless it is available on the public internet. For security reasons, you can limit access with a firewall and also add authentication to the staging site.

2. Your staging site only contains translation ready content. If you have are using your staging site for your editorial process, you might wind up discovering draft content that will never be published. Since this is obviously a waste of time and money, it's best to create a staging instance that only has content that is ready for publishing.

Here is a summary of the process

What to choose?

Which approach is right for you depends on your requirements. If, because of regulations or communications policy, you are required to publish new content to all languages simultaneously, you need to go with the translate staging option. If, like it is with us, you can allow your localized sites to lag behind the primary site, the international snapshot option is usually most attractive. And, of course, letting source content leak through may be acceptable if your site is less formal. The most important thing is that you have options.

Marketing I.T. in the Cloud

For a long time, I have been advocating that marketing organizations build technology capabilities. Marketing I.T. and Enterprise I.T. have totally different mindsets. Marketing I.T. is more like product development with an emphasis on opportunity and innovation. Traditional I.T. prioritizes stability and cost control. Increasingly I have seen ownership of digital marketing technology moving from I.T. to marketing. Now I have a front row seat.

One of the unexpected aspects of my job here at Lionbridge is that I run Marketing I.T. In particular, I manage our hosting infrastructure and work with teams developing new sites and applications on it. Given that many marketing organizations are inheriting this responsibility, I figured I would share some of the tools/services that I have found useful. I am going to talk about a lot of different products here. I am not endorsed by any of these companies and I am only mentioning products that I like.

• Hosting: Amazon Web Services (AWS) and Rackspace Cloud

  We do everything in the cloud. We set up a multi-server infrastructure on AWS using Elastic Compute Cloud (EC2: virtual servers), the Elastic Load Balancing service (ELB), and Relational Database Service (RDS). Both ELB and RDS span multiple physical data centers which is good for availability. We have EC2 instances in multiple data centers too. Our sites are also replicated to infrastructure hosted on Rackspace Cloud so that if AWS has a major problem, we can re-route traffic over to Rackspace. We test our sites on Rackspace weekly. Both AWS and Rackspace are great. AWS has many more features but the tech support is very limited. You need to pay extra for support and it can take a while to get an answer. Rackspace support is amazing. If you don't have a decent sysadmin, I would go with Rackspace.

  Ylastic makes administering AWS services much easier. The UI is not pretty but it is much better organized for doing specific tasks like managing backups and migrating and configuring servers. Ylastic also gives some insight into the health of the overall AWS infrastructure. The mobile UI is a big step up over the AWS management console on the little screen. We just use the basic level. At higher levels, you get some functionality to help manage your spend.

• Monitoring and Alerting: ServerDensity, CloudWatch, and PagerDuty

  AWS comes with its own monitoring service called CloudWatch. We have set up notifications to fire if the load balancer removes one of our servers because it isn't responding. We also wanted to have external monitoring services running so we could look at our RackSpace servers. Plus, it's a good idea to have your monitoring service independent from your hosting infrastructure in case your hosting infrastructure is too compromised to send an alert. We learned this the hard way when an AWS outage took out our monitoring as well. Most of our monitoring is done with a service called ServerDensity. This keeps track of internal server health metrics and we have it pinging the sites to make sure they are responding. Pingdom is also useful for checking if a site is up. We would use that if we didn't have ServerDensity

  We do all of our alerting through a service called PagerDuty. While all monitoring services can send out pages and emails, the nice thing about PagerDuty is that you can set up on-call schedules and escalation pathways. This is important because I have a really small team and everyone has other jobs (which can require travel). Even a non-techie can be on the "site may be down" alert. Usually this is a false positive because one of the servers in the cluster bounced in and out of the load balancer. Whoever gets the notification checks the site and texts a resolution code back (resolve, acknowledge, or escalate). I have trained non-techies to update the DNS to send traffic to Rackspace in the case of an emergency.

• Code Management: BitBucket

  We have lots of different people building sites for us. Some are on staff, others are contractors or external agencies. We use BitBucket (with Git) for source code management. This allows me to easily bring in a contributor but thoroughly review his/her code before merging it into our code base. We follow the classic "Fork/Pull Request model". Some developers/agencies get it better than others. I am weeding out the folks who don't get it because it makes my life harder. I don't want to deal with zip files of directories and worry about coordinating the changes from different people. With a pull request, I can see every change and easily merge.

• People

  While all of this technology is great, it's the people that make it go. As I mentioned earlier, my team is small. We get a lot of design and development help from outside contractors and agencies. I share sysadmin work with a really good contractor that knows much more than I do about managing servers. Having a "virtual team" is nice for scalability but it sometimes presents challenges for scheduling. I found a web project manager (with the help of my one field job application) who can handle a lot of basic tech tasks like running deployments and migrating sites. She has SSH access to all of our servers and can do things like restart Apache. She only started a couple of weeks ago and she is already making a huge contribution.

• Process

  We track all of our work in a ticket tracking tool called DOT (which we also use for our GMO clients). We also use DOT for tracking time so we can see how much effort we spend on various development projects. We group infrastructure projects into milestones that represent maintenance windows. Leading up to a maintenance window, we prepare the fixes and test them on a QA environment. We defer tickets that we are not confident that we can complete. Once the milestone is locked down, we send out an email to stakeholders explaining what we are doing, when we are doing it, and how it could possibly affect them. Then, after we complete the maintenance window, we send out a completed email, reminding of any relevant changes.

Overall, I am impressed with what a small team can do on a limited budget. By using cloud-based technologies, we can afford levels of redundancy and sophistication that would be prohibitively expensive to buy up-front: multiple data centers, generators, alerting systems, source code management… People-wise, we probably have around .5 FTE spread across several people (internal and external) managing and extending this infrastructure. These people have other responsibilities such as building and managing our services and products.

The best part of this whole arrangement is that we can be ultra-responsive. If something is important to a marketing initiative, we can act on it immediately. Our work does not go into a larger queue, where it may be misassigned or assigned to someone who doesn't have the complete context to do the work properly. The social dynamic is different as well. We are part of the team. Our motivations are aligned and we don't have those defensive postures that I.T. needs to fend off the entire organization. When we push back, we do so as peers and can explain why in terms that our peers can relate to. I think all mid to large sized organizations need a marketing I.T. team and this seems like a good way to structure it.

Gilbane 2012 Slides Posted

Last week I presented a session about Marketing Operations at the Gilbane Conference. The big idea is that marketing technologies are like bicycles.  If you commit the effort, the right technologies will help you get far.  But you can't just buy the equipment and expect success.

[slideshare id=15524408&doc=gilbane20122-121206155136-phpapp02]

For more information, you can read two whitepapers that I wrote (with Ahava Leibtag @ahaval): Building a Marketing Operations Program and Operationalizing your Content Marketing.

Building a Marketing Operations Program

Ahava Leibtag (@ahaval) from Aha Media Group and I just published a sequel to our first white paper ("Three First Steps to Operationalizing Your Content Marketing"). This one is called Building a Content Marketing Operations Program and takes off where the first one ends — getting into deeper detail about process. I am particularly happy with the content lifecycle diagram that we developed and Seth Gregory designed.

What I like about the diagram is that it is simple. Other content lifecycle diagrams show a lot of detail that tends to overwhelm in non-academic settings. The key points that this diagram highlights are that:

1. Marketing operations should be an iterative process that uses results to guide continual improvement.

2. The lifecycle operates within the context of your overall content marketing strategy (who you want to reach and how) and governance (your constraints like style guide, budget, regulation compliance).

3. Publishing is more than just saving content in your CMS. There is a very important "promotion" element to make content findable, usable and actionable.

The white paper digs into those three themes and discusses the types of roles and skills that are necessary to be successful. Go ahead and download it. If you are intrigued and want to learn more, you can email me directly here or hit me up on any of the social networks that I participate in.