Tag Archive | "they"

These 4 Copywriting Techniques Work Really Well … Right Up Until They Don’t

Search on Google and you’ll find hundreds of thousands of pages devoted to copywriting secrets, tips, tricks, and techniques. Go…

The post These 4 Copywriting Techniques Work Really Well … Right Up Until They Don’t appeared first on Copyblogger.


Copyblogger

Posted in Latest NewsComments Off

When Bounce Rate, Browse Rate (PPV), and Time-on-Site Are Useful Metrics… and When They Aren’t – Whiteboard Friday

Posted by randfish

When is it right to use metrics like bounce rate, pages per visit, and time on site? When are you better off ignoring them? There are endless opinions on whether these kinds of metrics are valuable or not, and as you might suspect, the answer is found in the shades of grey. Learn what Rand has to say about the great metrics debate in today’s episode of Whiteboard Friday.

When bounce rate browse rate and ppc are useful metrics and when they suck

Click on the whiteboard image above to open a high-resolution version in a new tab!

Video Transcription

Howdy, Moz fans, and welcome to another edition of Whiteboard Friday. This week we’re chatting about times at which bounce rate, browse rate, which is pages per visit, and time on site are terrible metrics and when they’re actually quite useful metrics.

This happens quite a bit. I see in the digital marketing world people talking about these metrics as though they are either dirty-scum, bottom-of-the-barrel metrics that no one should pay any attention to, or that they are these lofty, perfect metrics that are what we should be optimizing for. Neither of those is really accurate. As is often the case, the truth usually lies somewhere in between.

So, first off, some credit to Wil Reynolds, who brought this up during a discussion that I had with him at Siege Media’s offices, an interview that Ross Hudgens put together with us, and Sayf Sharif from Seer Interactive, their Director of Analytics, who left an awesome comment about this discussion on the LinkedIn post of that video. We’ll link to those in this Whiteboard Friday.

So Sayf and Wil were both basically arguing that these are kind of crap metrics. We don’t trust them. We don’t use them a lot. I think, a lot of the time, that makes sense.

Instances when these metrics aren’t useful

Here’s when these metrics, that bounce rate, pages per visit, and time on site kind of suck.

1. When they’re used instead of conversion actions to represent “success”

So they suck when you use them instead of conversion actions. So a conversion is someone took an action that I wanted on my website. They filled in a form. They purchased a product. They put in their credit card. Whatever it is, they got to a page that I wanted them to get to.

Bounce rate is basically the average percent of people who landed on a page and then left your website, not to continue on any other page on that site after visiting that page.

Pages per visit is essentially exactly what it sounds like, the average number of pages per visit for people who landed on that particular page. So people who came in through one of these pages, how many pages did they visit on my site.

Then time on site is essentially a very raw and rough metric. If I leave my computer to use the restroom or I basically switch to another tab or close my browser, it’s not necessarily the case that time on site ends right then. So this metric has a lot of imperfections. Now, averaged over time, it can still be directionally interesting.

But when you use these instead of conversion actions, which is what we all should be optimizing for ultimately, you can definitely get into some suckage with these metrics.

2. When they’re compared against non-relevant “competitors” and other sites

When you compare them against non-relevant competitors, so when you compare, for example, a product-focused, purchase-focused site against a media-focused site, you’re going to get big differences. First off, if your pages per visit look like a media site’s pages per visit and you’re product-focused, that is crazy. Either the media site is terrible or you’re doing something absolutely amazing in terms of keeping people’s attention and energy.

Time on site is a little bit misleading in this case too, because if you look at the time on site, again, of a media property or a news-focused, content-focused site versus one that’s very e-commerce focused, you’re going to get vastly different things. Amazon probably wants your time on site to be pretty small. Dell wants your time on site to be pretty small. Get through the purchase process, find the computer you want, buy it, get out of here. If you’re taking 10 minutes to do that or 20 minutes to do that instead of 5, we’ve failed. We haven’t provided a good enough experience to get you quickly through the purchase funnel. That can certainly be the case. So there can be warring priorities inside even one of these metrics.

3. When they’re not considered over time or with traffic sources factored in

Third, you get some suckage when they are not considered over time or against the traffic sources that brought them in. For example, if someone visits a web page via a Twitter link, chances are really good, really, really good, especially on mobile, that they’re going to have a high bounce rate, a low number of pages per visit, and a low time on site. That’s just how Twitter behavior is. Facebook is quite similar.

Now, if they’ve come via a Google search, an informational Google search and they’ve clicked on an organic listing, you should see just the reverse. You should see a relatively good bounce rate. You should see a relatively good pages per visit, well, a relatively higher pages per visit, a relatively higher time on site.

Instances when these metrics are useful

1. When they’re used as diagnostics for the conversion funnel

So there’s complexity inside these metrics for sure. What we should be using them for, when these metrics are truly useful is when they are used as a diagnostic. So when you look at a conversion funnel and you see, okay, our conversion funnel looks like this, people come in through the homepage or through our blog or news sections, they eventually, we hope, make it to our product page, our pricing page, and our conversion page.

We have these metrics for all of these. When we make changes to some of these, significant changes, minor changes, we don’t just look at how conversion performs. We also look at whether things like time on site shrank or whether people had fewer pages per visit or whether they had a higher bounce rate from some of these sections.

So perhaps, for example, we changed our pricing and we actually saw that people spent less time on the pricing page and had about the same number of pages per visit and about the same bounce rate from the pricing page. At the same time, we saw conversions dip a little bit.

Should we intuit that pricing negatively affected our conversion rate? Well, perhaps not. Perhaps we should look and see if there were other changes made or if our traffic sources were in there, because it looks like, given that bounce rate didn’t increase, given that pages per visit didn’t really change, given that time on site actually went down a little bit, it seems like people are making it just fine through the pricing page. They’re making it just fine from this pricing page to the conversion page, so let’s look at something else.

This is the type of diagnostics that you can do when you have metrics at these levels. If you’ve seen a dip in conversions or a rise, this is exactly the kind of dig into the data that smart, savvy digital marketers should and can be doing, and I think it’s a powerful, useful tool to be able to form hypotheses based on what happens.

So again, another example, did we change this product page? We saw pages per visit shrink and time on site shrink. Did it affect conversion rate? If it didn’t, but then we see that we’re getting fewer engaged visitors, and so now we can’t do as much retargeting and we’re losing email signups, maybe this did have a negative effect and we should go back to the other one, even if conversion rate itself didn’t seem to take a particular hit in this case.

2. When they’re compared over time to see if internal changes or external forces shifted behavior

Second useful way to apply these metrics is compared over time to see if your internal changes or some external forces shifted behavior. For example, we can look at the engagement rate on the blog. The blog is tough to generate as a conversion event. We could maybe look at subscriptions, but in general, pages per visit is a nice one for the blog. It tells us whether people make it past the page they landed on and into deeper sections, stick around our site, check out what we do.

So if we see that it had a dramatic fall down here in April and that was when we installed a new author and now they’re sort of recovering, we can say, “Oh, yeah, you know what? That takes a little while for a new blog author to kind of come up to speed. We’re going to give them time,” or, “Hey, we should interject here. We need to jump in and try and fix whatever is going on.”

3. When they’re benchmarked versus relevant industry competitors

Third and final useful case is when you benchmark versus truly relevant industry competitors. So if you have a direct competitor, very similar focus to you, product-focused in this case with a homepage and then some content sections and then a very focused product checkout, you could look at you versus them and their homepage and your homepage.

If you could get the data from a source like SimilarWeb or Jumpshot, if there’s enough clickstream level data, or some savvy industry surveys that collect this information, and you see that you’re significantly higher, you might then take a look at what are they doing that we’re not doing. Maybe we should use them when we do our user research and say, “Hey, what’s compelling to you about this that maybe is missing here?”

Otherwise, a lot of the time people will take direct competitors and say, “Hey, let’s look at what our competition is doing and we’ll consider that best practice.” But if you haven’t looked at how they’re performing, how people are getting through, whether they’re engaging, whether they’re spending time on that site, whether they’re making it through their different pages, you don’t know if they actually are best practices or whether you’re about to follow a laggard’s example and potentially hurt yourself.

So definitely a complex topic, definitely many, many different things that go into the uses of these metrics, and there are some bad and good ways to use them. I agree with Sayf and with Wil, but I think there are also some great ways to apply them. I would love to hear from you if you’ve got examples of those down in the comments. We’ll see you again next week for another edition of Whiteboard Friday. Take care.

Video transcription by Speechpad.com

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!


Moz Blog

Posted in Latest NewsComments Off

They Won’t Bite: How talking to customers helped Dell EMC turn its content strategy around

Taking the time to pause production and speak with our customers about the kind of content they want to see is one of those “why didn’t we do this sooner?” moments we talk about so much in marketing.
The Dell EMC had just such a moment. It stopped producing content that was seeing absolutely no traction and began not only focusing on content that customers actually wanted but also getting it in front of them.
Watch this Media Center interview with Lindsay Lyons, Director of Global Content Strategy, Dell EMC, to gain insights into how her team was able to transform their internal processes to produce effective, customer-first content.

MarketingSherpa Blog

Posted in Latest NewsComments Off

Pet Peeves from the Copyblogger Editorial Team, and What they Reveal

"No one can nurse a good peeve quite like a group of writers." – Sonia Simone

We’ve written quite a bit lately about identifying core values in your content.

Creating content around a positive value like integrity, fairness, humility, or faith will attract an audience that shares those values — and that fosters a powerful sense of unity.

But our friend negativity bias tells us that the flip side of that will probably be more compelling. In other words, talking about the things that bug you will build an even faster bond with your audience.

For today’s post, I asked our editorial team to let us know their peeves — the things that irritate, bother, and annoy them.

I’m going to try to tease those out and figure out the values behind them — and see what that might say about who we are as a company and a community.

So let’s get peevy.

Stefanie Flaxman’s peeve

Stefanie is our editor-in-chief, and as you’d expect, she has a healthy list of grammar and usage peeves.

But an editor is much more than a proofreader. It’s one thing to misplace a comma — it’s another to come at a post in a fundamentally flawed way. Here’s Stefanie’s peeve:

Hype/extremes/absolutes: Writing voices that are heavy on absolutes tend to simultaneously lack substance and speak to the reader as if they know what’s best for them … which isn’t a combination that builds credibility.

For example, earnestly referring to any flesh-and-blood human being as a “guru” is typically too vague or a sign of hype. If the person is an expert, top scholar, or highly respected professional, use those labels instead — they’re more specific.

What it reveals

Putting this post together reminded me that an Allergy to Hype has always been at the core of Copyblogger’s message. Since Brian founded the blog in 2008, Copyblogger has always stood in contrast to the hype-slingers who substitute flash for value. We believe that substance matters.

Robert Bruce’s peeve

Ten-dollar words: This is an old one, but a good one, and for good reason. Most writers have moderate-to-severe mental problems. I am, obviously, no psychologist, but the attempt to unnecessarily project one’s “intelligence” through the use of big words — when plain words can do the job — seems to be clear evidence of this.

What it reveals

Besides the obvious fact that Robert wins a lifetime “get off my lawn” achievement award, I think this shows how passionate we are about Quality. Quality of information, quality of business practices, quality of writing.

Loryn Thompson’s peeve

You’ve only seen Loryn on the blog once (so far), but she’s crucial to our editorial success. She’s the data analyst who looks at the numbers behind what we’re writing, and helps us to get our message out more effectively.

Here’s Loryn’s peeve:

Using “over” with numbers (instead of “more than”) : As Rainmaker Digital’s data analyst, this one comes up for me a lot. Every time I catch myself writing “over 5%…” in a report, I go back and change it to “more than.” 

 

Now, the Associated Press said in 2014 that both “over” and “more than” are acceptable to use with numeric comparisons — as in, “There were over two hundred people at the event.” But you know what? It still bugs the crap out of me. 

In my mind, “over” mixes the abstract world with the physical realm. For example, if you were to say, “We flew over 6,000 miles …” you could be saying that you flew more than 6,000 miles. Or, you might mean that you were literally above the earth for 6,000 miles.

What it reveals

I picked this one precisely because the team doesn’t agree on it. Some of us are “more than” folks (me, Loryn) and some aren’t. Stefanie tries to remain agnostic.

While it can be fun to give in to that eye twitch when someone makes a style choice we don’t like, I think it’s smart to keep some perspective. There are usually good arguments to be made for different usage choices, so I’ll go with Diversity as a value for this one.

My take is that it’s more important to be thoughtful about your choices than it is to be didactic. Although alot is never going to be a word and you can’t make it one.

Twitch, twitch.

Jerod Morris’s peeve

Jerod’s a person with a strong moral compass, and I was interested to see his peeves. Here’s the one I chose from his:

Misspellings of names: It’s especially bad when the name is a common one that’s misspelled in an obvious way. But any name misspelling shows a lack of basic respect for the subject you’re writing about. It’s not really grammar, but it still makes me cringe. Find out for sure.

What it reveals

Misspelling a name in content is a classic example in failure of what Jerod calls Primility (the intersection between pride and humility). It’s both sloppy (lack of pride) and disrespectful (lack of humility). I think it’s fair to say that Primility is a core value for Jerod, and that’s probably one of the reasons he’s been such a great asset to our company.

We are, make no mistake, proud of the work we do at Copyblogger. We love producing the blog, and we try hard to make it excellent. But we know that humility’s important, too. We’re under no illusion that this blog is perfect, and we try to challenge each other to always make it more relevant, more useful, and more interesting.

Sonia Simone’s peeve

You may feel like you already know more than you need to about my peeves. For today, I revisited a favorite:

Boring content: This one just makes me sad … seeing site after site after site that utterly fails to stand out in any way.

When I see a site with a genuine, passionate voice — even if there are a few usage errors — I may cringe a little, but mostly I cheer. I’d much rather see a site with plenty of G.A.S. than a grammatically perfect one that has no soul.

What it reveals

Individuality is absolutely a core value at Copyblogger. We’ve never endorsed the paint-by-numbers approach to marketing and online business … partly because that would be very boring, and mostly because it just doesn’t work.

And then there’s the Oxford comma

If you aren’t familiar with the Oxford comma (also known as the serial comma), it’s that final comma in a collection of items in a sentence.

Here’s a visually amusing example of the same sentence with and without one.

I like the Oxford comma because it’s always clear. Jerod gets downright fierce about his support. That renegade Loryn, though, has come to prefer dropping it.

“I used to be a staunch Oxford Comma advocate, but now I prefer the way short lists flow without it.” – That Renegade Loryn

Either is correct, but do be consistent. (Although the late Bill Walsh, noted Washington Post usage stickler, advises that if a serial comma is important for clarity, go ahead and put one in there, even if it’s not your usual style.)

A note about peeves and unity

I mentioned when we started that talking about the negatives will build a connection with your audience more quickly — and it will. But keep in mind that a steady diet of negativity will give almost anyone indigestion.

Don’t shy away from talking about the good stuff, too. An honest values system includes both positive and negative points of view.

How about you?

What sets your teeth on edge when you see it in a blog post or hear it in a podcast? What do you think that says about you and your values?

Let us know in the comments!

The post Pet Peeves from the Copyblogger Editorial Team, and What they Reveal appeared first on Copyblogger.


Copyblogger

Posted in Latest NewsComments Off

Introducing Progressive Web Apps: What They Might Mean for Your Website and SEO

Posted by petewailes

Progressive Web Apps. Ah yes, those things that Google would have you believe are a combination of Ghandi and Dumbledore, come to save the world from the terror that is the Painfully Slow WebsiteTM.

But what actually makes a PWA? Should you have one? And if you create one, how will you make sure it ranks? Well, read on to find out…

What’s a PWA?

Given as that Google came up with the term, I thought we’d kick off with their definition:

“A Progressive Web App uses modern web capabilities to deliver an app-like user experience.”
Progressive Web Apps

The really exciting thing about PWAs: they could make app development less necessary. Your mobile website becomes your app. Speaking to some of my colleagues at Builtvisible, this seemed to be a point of interesting discussion: do brands need an app and a website, or a PWA?

Fleshing this out a little, this means we’d expect things like push notifications, background sync, the site/app working offline, having a certain look/design to feel like a native application, and being able to be set on the device home screen.

These are things we traditionally haven’t had available to us on the web. But thanks to new browsers supporting more and more of the HTML5 spec and advances in JavaScript, we can start to create some of this functionality. On the whole, Progressive Web Apps are:

Progressive
Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet.
Responsive
Fit any form factor: desktop, mobile, tablet, or whatever is next.
Connectivity independent
Enhanced with service workers to work offline or on low quality networks.
App-like
Feel like an app to the user with app-style interactions and navigation because they’re built on the app shell model.
Fresh
Always up-to-date thanks to the service worker update process.
Safe
Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
Discoverable
Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
Re-engageable
Make re-engagement easy through features like push notifications.
Installable
Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
Linkable
Easily share via URL and not require complex installation.

Source: Your First Progressive Web App (Google)

It’s worth taking a moment to unpack the “app-like” part of that. Fundamentally, there are two parts to a PWA: service workers (which we’ll come to in a minute), and application shell architecture. Google defines this as:

…the minimal HTML, CSS, and JavaScript powering a user interface. The application shell should:

  • load fast
  • be cached
  • dynamically display content

An application shell is the secret to reliably good performance. Think of your app’s shell like the bundle of code you’d publish to an app store if you were building a native app. It’s the load needed to get off the ground, but might not be the whole story. It keeps your UI local and pulls in content dynamically through an API.
Instant Loading Web Apps with an Application Shell Architecture

This method of loading content allows for incredibly fast perceived speed. We are able to get something that looks like our site in front of a user almost instantly, just without any content. The page will then go and fetch the content and all’s well. Obviously, if we actually did things this way in the real world, we’d run in to SEO issues pretty quickly, but we’ll address that later too.

If then, at their core, a Progressive Web App is just a website served in a clever way with extra features for loading stuff, why would we want one?

The use case

Let me be clear before I get into this: for most people, a PWA is something you don’t need. That’s important enough that it bares repeating, so I’ll repeat it:

You probably don’t need a PWA.

The reason for this is that most websites don’t need to be able to behave like an app. This isn’t to say that there’s no benefit to having the things that PWA functionality can bring, but for many sites, the benefits don’t outweigh the time it takes to implement the functionality at the moment.

When should you look at a PWA then? Well, let’s look at a checklist of things that may indicate that you do need one…

Signs a PWA may be appropriate

You have:

  • Content that regularly updates, such as stock tickers, rapidly changing prices or inventory levels, or other real-time data
  • A chat or comms platform, requiring real-time updates and push notifications for new items coming in
  • An audience likely to pull data and then browse it offline, such as a news app or a blog publishing many articles a day
  • A site with regularly updated content which users may check in to several times a day
  • Users who are mostly using a supported browser

In short, you have something beyond a normal website, with interactive or time-sensitive components, or rapidly released or updated content. A good example is the Google Weather PWA:

If you’re running a normal site, with a blog that maybe updates every day or two, or even less frequently, then whilst it might be nice to have a site that acts as a PWA, there’s probably more useful things you can be doing with your time for your business.

How they work

So, you have something that would benefit from this sort of functionality, but need to know how these things work. Welcome to the wonder that is the service worker.

Service workers can be thought of as a proxy that sits between your website and the browser. It calls for intercept of things you ask the browser to do, and hijacking of the responses given back. That means we can do things like, for example, hold a copy of data requested, so when it’s asked for again, we can serve it straight back (this is called caching). This means we can fetch data once, then replay it a thousand times without having to fetch it again. Think of it like a musician recording an album — it means they don’t have to play a concert every time you want to listen to their music. Same thing, but with network data.

If you want a more thorough explanation of service workers, check out this moderately technical talk given by Jake Archibald from Google.

What service workers can do

Service workers fundamentally exist to deliver extra features, which have not been available to browsers until now. These includes things like:

  • Push notifications, for telling a user that something has happened, such as receiving a new message, or that the page they’re viewing has been updated
  • Background sync, for updating data while a user isn’t using the page/site
  • Offline caching, to allow a for an experience where a user still may be able to access some functionality of a site while offline
  • Handling geolocation or other device hardware-querying data (such as device gyrpscope data)
  • Pre-fetching data a user will soon require, such as images further down a page

It’s planned that in the future, they’ll be able to do even more than they currently can. For now though, these are the sorts of features you’ll be able to make use of. Obviously these mostly load data via AJAX, once the app is already loaded.

What are the SEO implications?

So you’re sold on Progressive Web Apps. But if you create one, how will you make sure it ranks? As with any new front-end technology, there are always implications for your SEO visibility. But don’t panic; the potential issues you’ll encounter with a PWA have been solved before by SEOs who have worked on JavaScript-heavy websites. For a primer on that, take a look at this article on JS SEO.

There are a few issues you may encounter if you’re going to have a site that makes use of application shell architecture. Firstly, it’s pretty much required that you’re going to be using some form of JS framework or view library, like Angular or React. If this is the case, you’re going to want to take a look at some Angular.JS or React SEO advice. If you’re using something else, the short version is you’ll need to be pre-rendering pages on the server, then picking up with your application when it’s loaded. This enables you to have all the good things these tools give you, whilst also serving something Google et al can understand. Despite their recent advice that they’re getting good at rendering this sort of application, we still see plenty of examples in the wild of them flailing horribly when they crawl heavy JS stuff.

Assuming you’re in the world of clever JS front-end technologies, to make sure you do things the PWA way, you’ll also need to be delivering the CSS and JS required to make the page work along with the HTML. Not just including script tags with the <code>src attribute, but the whole file, inline.

Obviously, this means you’re going to increase the size of the page you’re sending down the wire, but it has the upside of meaning that the page will load instantly. More than that, though, with all the JS (required for pick-up) and CSS (required to make sense of the design) delivered immediately, the browser will be able to render your content and deliver something that looks correct and works straightaway.

Again, as we’re going to be using service workers to cache content once it’s arrived, this shouldn’t have too much of an impact. We can also cache all the CSS and JS external files required separately, and load them from the cache store rather than fetching them every time. This does make it very slightly more likely that the PWA will fail on the first time that a user tries to request your site, but you can still handle this case gracefully with an error message or default content, and re-try on the next page view.

There are other potential issues people can run in to, as well. The Washington Post, for example, built a PWA version of their site, but it only works on a mobile device. Obviously, that means the site can be crawled nicely by Google’s mobile bots, but not the desktop ones. It’s important to respect the P part of the acronym — the website should enable features that a user can make use of, but still work in a normal manner for those who are using browsers that don’t support them. It’s about enhancing functionality progressively, not demanding that people upgrade their browser.

The only slightly tricky thing with all of this is that it requires that, for best experience, you design your application for offline-first experiences. How that’s done is referenced in Jake’s talk above. The only issue with going down that route: you’re only serving content once someone’s arrived at your site and waited long enough to load everything. Obviously, in the case of Google, that’s not going to work well. So here’s what I’d suggest…

Rather than just sending your application shell, and then using AJAX to request content on load, and then picking up, use this workflow instead:

  • User arrives at site
  • Site sends back the application shell (the minimum HTML, JS, and CSS to make everything work immediately), along with…
  • …the content AJAX response, pre-loaded as state for the application
  • The application loads that immediately, and then picks up the front end.

Adding in the data required means that, on load, we don’t have to make an AJAX call to get the initial data required. Instead, we can bundle that in too, so we get something that can render content instantly as well.

As an example of this, let’s think of a weather app. Now, the basic model would be that we send the user all the content to show a basic version of our app, but not the data to say what the weather is. In this modified version, we also send along what today’s weather is, but for any subsequent data request, we then go to the server with an AJAX call.

This means we still deliver content that Google et al can index, without possible issues from our AJAX calls failing. From Google and the user’s perspective, we’re just delivering a very high-performance initial load, then registering service workers to give faster experiences for every subsequent page and possibly extra functionality. In the case of a weather app, that might mean pre-fetching tomorrow’s weather each day at midnight, or notifying the user if it’s going to rain, for example.

Going further

If you’re interested in learning more about PWAs, I highly recommend reading this guide to PWAs by Addy Osmani (a Google Chrome engineer), and then putting together a very basic working example, like the train one Jake mentions in his YouTube talk referenced earlier. If you’re interested in that, I recommend Jake’s Udacity course on creating a PWA available here.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!


Moz Blog

Posted in Latest NewsComments Off

3 Unexpected Ways Writers Deliver Value (So They Can Charge More)

writers-charge-more

In today’s world, the writer runs the show.

Not just any writer, of course. The pennies-a-word scribe may barely scrape by. But the quality professional writer — the writer who demonstrates high value and trust from the moment of first contact all the way through to delivery of the final word — that person writes his own ticket to success.

Quality professional writers command attention online, whether they do it for themselves or for the businesses they represent. Writers influence behavior, help form opinions, and drive people to take action.

Great writers are the modern-day stonemasons of any online presence. Our words form the very foundation of all online content, whether those words become a blog post, a podcast, or a video. Writers rule the online world!

And successful professional writers do things differently.

They don’t stop at writing with authority. That’s just where they start. They also deliver outstanding value even in the most unexpected moments in their interactions with clients.

In today’s post, we’ll cover how successful writers deliver value in all three stages of a project: before, during, and after.

Value Phase #1: Before the first project begins

Writers set the stage for a quality customer experience before they write a single word for a new project. How can you do this in your own work?

Before you begin

  1. Listen between the lines. Tune in to your client’s underlying frustrations. Take notes on his current situation. Listen closely when you hear your client talk about long-term goals and desired results.
  2. Be flexible. Take your client’s current needs into account and offer payment solutions like retainers when they make sense.
  3. Think strategy. Add value to your services by stepping back and seeing the big picture. Solve a strategy problem; don’t just fulfill a word count.

When presenting your proposal

  1. Be crystal clear when setting expectations. We’re not delivering pizza in 30 minutes or less — clients deserve to understand exactly how long a project will take, what the milestones will be (and when the writer will hit them), and what form the final product will take.
  2. Offer terms of service that explain how you work. Craft rock-solid proposals that protect your time and energy and spell out exactly what will happen if the project doesn’t proceed as expected. (This happens a lot!)

Some clients may view writing as a nebulous, indefinable service that can’t be pinned down.

But when you set expectations clearly and leave nothing up to chance, your client will feel more confident about signing a contract and starting to work with you.

Specifics make something that is abstract seem more concrete. Use them!

Value Phase #2: Working on and delivering the project

If a project is going to have a quick turnaround, it might be enough to set the deadline and get to work. But if a project is going to stretch beyond a week — especially if it’s a first project for a new client — it’s a good idea to establish some milestones and keep the client updated as you go along.

While you work

  1. Use your client’s preferred mode of communication to provide updates. How often and where would your client like his updates? Email? Slack? A quick phone call? Find out how he wants to hear from you and keep him abreast of your progress.
  2. Format for ease of use. During the information-gathering stage, nail down how the copy you write will be used so you can deliver it in a ready-to-use format the client can plug right in. Does the client prefer you deliver the copy formatted with HTML? Does he expect a copy deck? (Read this to learn what a copy deck is.)
  3. Deliver more. One major sign of quality is when you over-deliver on what you promise. Do extra competitive research. Deliver the project a day early. Make a few extra suggestions about how your client could use your work.

Again, the idea with these tips is to make an abstract service seem more like a tangible product by delivering extra communication and value every step of the way.

Value Phase #3: After the project wraps up

You’re done! You’ve delivered on your promise and (hopefully) gone above and beyond your client’s expectations.

But you’re not done delivering a quality experience.

To wrap up your project with a remarkable bow, put these ideas into practice:

  1. Have a post-sale follow-up system in place. If you’re delivering web copy, give it a look once it’s published online and send a quick note to your client to let him know it looks great. If you’re delivering print copy, ask for a sample and send feedback once you review it.
  2. Send a survey (or a few follow-up questions). New clients may have feedback on your process after your first project with them. Ask them for feedback soon after you finish the project and be sure to include some open-ended questions. Try, “What would have made my service easier to use?” or “Anything you’d like to add?”
  3. Offer related products or services based on the client’s goals. Once you’ve worked with a client, you may see other ways you can help him meet his needs. Don’t expect your client to be familiar with everything you offer: you do clients a favor when you let them know other ways in which you can help.

Build a profitable freelance writing business

Inside our Content Marketer Certification program, we’ve got a lot more for writers.

We designed this program to help writers make the most of their careers — to help them position themselves and their offerings, so that they can build profitable freelance writing businesses.

And we’re opening the program soon. Drop your email address below and you’ll be the first to hear about it.

Find out when our Certified Content Marketer training program reopens:

What are your value phases?

Service providers become successful when they find ways to deliver value during every stage of communication — even the unglamorous ones like estimating the price of a new project or following up after a project wraps.

Look at your client interactions and use the tips here to find new ways to add value.

What have I missed? If you’ve found a way to stand out (and you’re willing to share it), let me know in the comments section.

The post 3 Unexpected Ways Writers Deliver Value (So They Can Charge More) appeared first on Copyblogger.


Copyblogger

More Articles

Posted in Latest NewsComments Off

How Solar Energy Systems Work and How They Benefit You




style="display:inline-block;width:250px;height:250px"
data-ad-client="ca-pub-7815236958543991"
data-ad-slot="8717335615">

All around the world and especially in the US, people are adopting lifestyles that benefit the earth by limiting chemical use, power use, and just all around choosing to “go green”. One of the ways that people are changing their lifestyles is by using alternative forms of energy that save money. Today you can learn how systems fueled by solar energy can be useful in your own household. Utility expenses will dramatically decrease and you’ll be able to save big time. You will also have peace of mind from knowing that your lifestyle is benefiting your environment and health by utilizing natural resources.

If you are wondering what solar energy is and how it works, here’s your chance to find out. This type of energy basically comes from the sun. Yes, the same yellow fire ball that sits up in the sky shining down on us all can be used as a source of energy right inside your own home. Of course the sun is used for more than just providing beautiful days outdoors. Today there are different sun fueled systems that you can choose from for your house that will effectively run the daily activities of your home in a more cost effective manner.

To explain things simply, panels can be installed upon the top of your house. The sunlight that shines upon the rooftop will then be transformed into electricity. This electricity from the sun can then be converted into the exact electricity that you use in your household. It is quite simple. As mentioned earlier, there are different types of sun fueled energy systems that can be installed within the home. Other systems include the sun energy system that controls the hot water in your home. This process involves the sun’s heat warming liquid through the roof and heating the water tank then traveling back to the roof to continue the cycle.

There are many great benefits to having solar energy systems in your home. As mentioned earlier it will be cost efficient. Your electricity bill will not be the same because you are using natural power. Another great benefit is that it is safe, natural, and harmless. Energy from the sun does not produce chemicals or gases that pollute the environment at all. And as long as the sun exists, there will always be this type of energy available. It’s priceless. And because of how the sun works, this type of energy is available anywhere, even away from your home.

You have always been aware of the sun, but you probable have never thought fully about all that it can do. The sun provides you with warmth, light, and beauty. But it can do this in so many ways. Making the switch to solar energy systems can be the best decision you will make for you and your family. The costs to install these systems are well worth it. You will see results and also save so much money. And you will also be contributing to a healthier earth.

Latest solar news

Posted in Latest NewsComments Off

Oh No They Didn’t: European Parliament Calls For Break Up Of Google

Today many Americans are busy preparing Thanksgiving meals or getting ready to travel to the homes of friends and family to celebrate the holiday. But Google certainly won’t be giving thanks for the European Parliament’s vote in favor of a resolution to “unbundle”…



Please visit Search Engine Land for the full article.


Search Engine Land: News & Info About SEO, PPC, SEM, Search Engines & Search Marketing

Find More Articles

Posted in Latest NewsComments Off

IPv6, C-Blocks, and How They Affect SEO

Posted by Tom-Anthony

You have probably heard about IPv6, but you might remain a bit confused about the details of what it is, how it works, and what it means for the future of the Internet.
This post gives a quick introduction to IPv6, and discusses the SEO implications that could follow from the IPv6 roll-out (touching specifically on the concept of C-Blocks). A quick caveat: This stuff is hard, so let me know if you spot any missteps!

A very brief intro to IP addresses (v4) & c-blocks

You’re likely familiar with IP addresses; they are usually written in the following format:

 

Example IP address (IPv4).

This format of an IP address is the common format in use everywhere, and is called IPv4. There are four bytes in an IP address like this, with each byte separated by a period (meaning 32 bits in total, for the geeks). Every (sub)-domain resolves to at least one such IP address (it might be several, but lets ignore that for now). Nice and simple.

Now a main SEO concept that comes out of that is the idea of C-Blocks (this shouldn’t be confused with Class C IPs; a different thing people often confuse for C-Blocks), which is a concept that has been around in the SEO space for a decade or more. Very simply, the idea is that if the first 3 bytes of the IP address are identical, then we consider the two IP address to be in the same C-Block:

Two example IP addresses in the same C-Block (blue).

So why is this interesting to us? Why is this important to SEO? The old-school logic is that if you have two IPs that are in the same C-Block, then the sites are quite likely related and thus the links between these sites (on average) should not count as strongly in terms of PageRank. My personal opinion is that nowadays there are many many other signals available to Google to make these same sorts of connections and so the C-Block issue is far less important than it once was.

So, as it turns out (surprise!) the two IP addresses above are indeed related:

Disney and ABC have a near identical IP address, both in the same C-Block.

Sure enough they are both companies in the Disney family. It makes some sense that links between these two domains probably shouldn’t indicate as much trust as links from similarly large, but unrelated, sites.

Introducing IPv6

So, there is a problem with IP addresses in the format above (IPv4); there are “only” 4 billion of them, and we have essentially exhausted the supply. We have so many connected devices nowadays, and the creators for IPv4 never envisioned the vastness of the Internet 30 years from when it was released. Luckily enough, they saw the problem early on andstarted working on a successor, IPv6 (IPv5 was used for another unreleased protocol).

IPv6 address format:

IPv6 addresses are much longer than IPv4 addresses, the format looks thus:

An example IPv6 address.

Things just got serious! There are now 8 blocks rather than 4, and rather than each block being 1 byte (which were represented as a number from 0-255), each block is instead 2 bytes represented by 4 hexadecimal characters. There are 128 bits in an IPv6 address, meaning instead of a measly 4,000,000,000 like IPv4, IPv6 has
around 340,000,000,000,000,000,000,000,000,000,000,000,000 addresses.

In the next few years we’ll be entering a world where hundreds of devices in homes will all be capable of networking and needing an IP address and IPv6 will help make that a reality. However, we are also going to see websites starting to use IPv6 addresses more and more commonly, and a few years from now we’ll start to see website that only have an IPv6 address.

CIDR Notation

Before we go any further, it is important to introduce an important concept for understanding IP addresses, which is called CIDR notation.

IPv6 exclusively uses CIDR notation (e.g. /24), so the SEO community will need to understand this concept. It is really simple, but normally really badly explained.

As we mentioned, IPv4 IP addresses are 32 bits long, so if we were sick and twisted we could look at the IP address as binary:

Example IPv4 IP address shown in dot decimal format and as binary.

Colloquially, CIDR notation could be described as a format to describe a group of closely related IP addresses, in a similar fashion to how a C-Block works. It is represented by a number after a slash appended to a partial IP address (e.g. 199.181.132/24) which states how many of the initial bits (binary digits) are the identical. CIDR is flexible and we could use it to describe a C-Block would be /24 because the first 24 bits (3 groups of 8 bits) of the address are the same:

Two IP addresses in the same C-Block. The first 24 bits (3 blocks of 8 bits) are identical.

This can be represented in this case as 199.181.132/24.

Now CIDR notation is more refined and more accurate than the concept of C-Block; in the example above the two IP addresses are not just in the same C-Block they are even more closely related as 6 bits in the last block are also identical. In CIDR notation we could say both these IP addresses are in the 199.181.132/30 block to indicate that the 30 leading bits are identical.

Notice that with CIDR the smaller the number after the slash, the more IP addresses in that block (because we’re saying fewer leading bits must be identical).

IPv6 & C-Blocks?

Now CIDR /24 is not exactly catchy and so someone made up the name “C-Block” to make this easier to talk about, but it doesn’t extend so easily to IPv6. So, the question is, can we generalise something similar?

The point of a C-Block from Google’s perspective and the perspective of our SEO is solely to identify whether links are originating on the same ISP network. So that should obviously remain the focus. So my best guess would be to focus on how these IPs are allocated to ISPs (ISPs normally get large continuous blocks of IP addresses they can then use for their customers’ websites).

In IPv4 ISPs would own bunches of C-Blocks, and so if you could see multiple links originating from the same C-Block it implied the sites were hosted together, and there was a far greater chance they were somehow related.

Illustration of an “ISP Block” (/32); the blue part of the address is stable and

indicates the ISP. The red part can change and represents addresses at that ISP.

With IPv6, I believe that ISPs will be given /32 blocks (the leading 32 bits will be the same, leaving 96 bits to create addresses for their customers), which they will then assign to their users in /64 blocks (I asked a few people, this tends to be what is happening, but I have read that this might sometimes be /48 blocks instead). Notice that ISPs now have an order of magnitude more IP addresses (each) than the whole internet had before!

This also means each end user will get more IP addresses for their own network than there are in total IPv4 IP addresses. Welcome to the Internet of things!

These ISPs may be serving home users so each house gets a block of IPv6 addresses (for the techies: IPv6 does away with NAT for the most part, I believe – all the devices in your house will get a ‘real’ IP) for their devices. In the other scenario the ISP is for servers, and here the servers get assigned a /64 block; this is the case we are interested in.

Illustration of a “Customer Block” (/64); the blue part indicates a particular customer.

 The red part can change and represents addresses belonging to that customer.

So, I think the equivalent of a C-Block in IPv6 land would be a /32 block because that is what an ISP will usually be assigned (and allows them to then carve that up into 4 billion /64 blocks for their users!).

Furthermore, in IPv6 the minimum allocation is /32 so a single /32 block cannot run across multiple ISPs as I understand it, so there is no way two IPs in the same /32 could belong to two different ISPs. If our goal is to continue to examine whether sites are more likely related than two random sites, then knowing they are on the same ISP (which is what C-Blocks do) is our goal.

Also, if you chose /64 then each ISP has 4 billion of these blocks to give away, and that is way too sparse to identify associations between sites in different blocks.

However, there is a counter argument here. Note that a single server having a /64 block of IPs means that every website should have a different IPv6 address (even if it shares an IPv4 address).

Geek side note: indeed, the “host” http header accepts an IPv6 address to distinguish which site on the server you want.

So now a single server with multiple sites will have a separate IP for each of those sites (it is also possible that the server has multiple IPv6 blocks assigned, one for each different customer – I think this is actually the intention and hopefully becomes the reality).

So, if I am running a network of websites I’m interlinking with one another then it is quite likely that if I just have a single hosting account that all these are in the same /64 block of IPv6 addresses. That should be a very strong signal that that sites are linked closely. However, I’m fairly sure that those trying to be manipulative will try to avoid this scenario and end up trying to get in another block of addresses for each site. But if they are with the same ISP then they’ll still be in the same /32 block.

My recommendation on an IPv6 C-Block

So, if you followed all that then I’d suggest:
  • Sites in the same /32 block as before would be equivalent to the same C-Block as previously.
  • Sites in the same /64 block either are on the exact same server, or belong to the same customer, so are even closer related than C-Block level.
These need easier more accessible names, how about:
  • “ISP Block” for /32 blocks.
  • “Customer Block” for /64 blocks.
Then we would be able to say things like:
  • In IPv6 IP addresses in the same ISP Blocks most closely resemble the relationship of IPs in the same C-Block in IPv4.
  • In IPv6 IP addresses in the same User Block are likely very closely related, and probably belong to the same person/organisation.

What should I take away from all this?

As I mentioned further up, I’m not convinced that IPv4 C-Blocks are as important from Google’s perspective as they once were, as they can likely access multiple other signals to tie sites together. Whilst still useful as a substitute for those signals for SEOs, who don’t have all Google’s resources, they aren’t something that should guide your decision making. If you are running legitimate sites, you shouldn’t be concerned about hosting them on the same C-Block. In fact, I’d advise against that as it could look manipulative to Google (who will likely work it out anyway).

With IPv6, I think the “Customer Blocks” could be a very important SEO feature, as it is an even closer relationship than C-Blocks were, and this is something that Google will likely make use of. It is still going to take a while until IPv6 becomes prevalent enough that all of this is important, so for the moment this is just something to have on your radar as it will begin to increase in importance over the next couple of years.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!


Moz Blog

Posted in Latest NewsComments Off

Content Marketing: How to serve customers when they shouldn’t buy from you

Content marketing is about serving customers, not pushing product. Only once you serve those customers (and build up trust) can it become an effective vehicle for selling. Read this MarketingSherpa Blog post for two ideas for serving customers when your product isn’t right for them.
MarketingSherpa Blog

Posted in Latest NewsComments Off

Advert