How We Ranked a Single Page for 2.6K Keywords Driving 30K Monthly Searches [Case Study]

Posted by KristinTynski

For the last decade, I’ve touted the enormous long-term value of a dualistic approach to content marketing for SEO.

By leveraging data-centered campaigns, paired with personalized outreach to top publishers, we regularly garner earned media placements for our clients.

In rare cases, we create content that generates results so far beyond what was anticipated that a single project can greatly move the needle.

I’m going to walk through one such instance to reveal how it all works together, what can be learned from this experience, and the type of result it can achieve.

While typically you need to invest in ongoing content generation and promotion, extraordinary examples like these demonstrate the impact this kind of work has over the long-term.

Content marketing + digital PR case study: ADT

ADT is a household name with good domain authority, providing a great base to start from.

We knew that the content we’d create would likely have a leg up in terms of ranking potential, especially if that content addressed many potential high-intent keywords.

Content production

After speaking with ADT, we determined our joint goal was to create a piece of content that could earn dozens to hundreds of links from top publishers, with another focus on earning links from local news publications.

The client had the idea to create a crime map tool for ADT.com, and it fit the bill for everything we typically look for in a piece of content. But for the purpose of this article, I’ll examine what makes it ideal.

Say you were starting from scratch. You can start with a simple Google search of “crime,” which would serve as a reminder of how localized the topic is.

Just from this search alone, you can identify the desire for crime maps specifically, and you can consider why someone would search for a crime map:

• To identify crime in their area
• To investigate the crime in places they’re looking to visit
• To investigate the crime in places they’re looking to move

Because people might not want to know just about the areas right around where they live, it was a strong idea to create a comprehensive, interactive crime mapping tool that gives users the ability to search local areas and see detailed, local-level crime statistics.

This concept had a high chance of success for other reasons as well, including:

1. It has a practical use. Not all content necessarily needs to be practical — it depends on the industry you’re in and whether you can get by with entertainment value. If it’s not practical, it should reveal insights that speak to the human experience and inform a reader about their context in the world. We actually added this element in the crime map project by building in functionality where you can compare the crime rate in your area to national averages.

However, having a practical element (or actionable advice) means your content has built-in value. It communicates that you care about the person reading it, and they engage with the content more because they feel like they can do something with the information.

2. It's data-based, making it authoritative and accurate. It’s very difficult these days to pitch publishers anything that isn’t data-based. Not only does it add credibility to what you’re working on, but showing that you did your research also indicates that you’re an authority (or becoming an authority) on the subject. I’ll dive into more on this toward the end of the article.

3. The data can be tailored to countless local angles. If your goal is to build as many valuable links and as much general brand awareness as possible, you should always consider how to localize your content. 

This has to happen at the beginning when you’re collecting your data. Ask yourself: Is the data set comprehensive enough that insights about different segments, like geographic locations, can be gathered? The more people who can connect with and “see” themselves in your content by having it be as personalized as possible, the better.

4. It invokes emotions like safety and concern for loved ones. Tapping into emotional concepts is always a good strategy when creating content. Crime and security inherently come with some obvious emotions: fear, concern, pride in protecting your family, etc. If you’re in a niche that doesn’t seem to have straightforward ties to emotion, ask yourself these questions to reveal the emotions at work in the background:

• Why do people care about this?
• What is our audience’s biggest struggle?
• What might our audience worry most about?

For example, while it doesn't seem so on the surface, personal finance can be extremely emotional. It involves the way people lead their lives and is tied to the guilt of not saving enough, the pride of being on top of their finances, the fear they won’t have enough money to retire, etc. No matter what vertical you’re in, there are emotions involved, and tapping into them with empathy can make your content exponentially more compelling and helpful.

5. As a security company, it makes perfect sense for ADT to be the brand that’s offering a resource where people can check the crime rates all over the country. When you have this sort of brand alignment with an idea, it's clear to publishers and readers alike why the brand created it, and it helps build trust.

Always consider these types of criteria when you move forward on a content concept.

Digital PR

Because of the local/regional aspect of the interactive, our outreach approach was to pitch regional news publishers with the exclusive coverage.

We customized pitches for publishers by state for our initial outreach. Here is a sample pitch similar to the one that successfully landed coverage:

Hi [Website Name] team,

In the wake of natural disasters like Hurricane Florence, fears of looting and other forms of crime are often heightened. The newly released ADT crime map wants residents to be aware of crime hot spots in their neighborhoods and use precautionary measures to prevent being victims of crime, especially during hurricane season.

The interactive map allows users to look up specific crime data and compare it to national averages to determine how much crime is happening in their area. For example, Florida’s overall crime rate is 1.21x higher than the national average. That said, the murder rate is relatively low when compared to the rest of the nation (0.03x less).

To explore your city using the ADT Crime Map, please visit https://www.adt.com/crime.

Interested in covering this so that your readers can stay as safe as possible under any circumstance? If so, feel free to use this press release or graphics from the map. We just ask that you attribute ADT by linking to the Crime Map somewhere in your coverage.

Best,

[Your Name]

Each pitch was personalized by adjusting the first and second paragraph to include locally relevant details for that area.

This regional outreach strategy had a high chance of success because:

• The content was highly relevant to local news publishers
• Local news publications are often the best syndicators
• We put together a new, exclusive resource that many consumers would find helpful
• Offering content as an exclusive makes it especially newsworthy and appealing to writers

In this case, the exclusive was given to ABCActionNews.com, a Tampa Bay, Florida ABC affiliate.

Luckily, the publisher liked the story so much, they decided to include it in that day’s nightly news coverage. As one of the largest local news affiliates in that area, this coverage was likely seen on over 25,000 local televisions.

We continued pitching the story, attempting to exhaust our pitch list and support syndication of the exclusive picked up by ABCActionNews.com.

After roughly a month, we compiled a report on all coverage and syndications. We were happy to report to our client that the story was picked up by dozens of local news publishers, eventually generating links from 127 unique linking domains per Ahrefs.

The impact on search

A graph of acquired links shows a very organic progression — something we see often when a story syndicates well across many domains.

Almost immediately the page began ranking — likely a result of the ADT site’s awesome existing domain authority, topical relevance of the project related to the domain, and the massive injection of new unique links to the crime maps page.

Don’t have high domain authority?

While having an authoritative brand can make this whole strategy a bit easier, that doesn’t mean it can’t work for you if you are newer or are trying to keep up with huge, household-name competitors.

It just means it’s even more important that you use data-focused content. We’ve always thought that using data as a foundation for content was the best way to build authority, but a recent study we did with BuzzStream about authoritative content confirmed that.

Having an authoritative methodology can increase the chances people trust your content — and thus your brand — by extension. And when you’re trying to get attention in competitive spaces, every authority signal matters.

Regarding promotions, all of the tips I’ve provided in this article should work for you. Perhaps when pitching, you can provide a sentence or two describing your brand. It’s also best practice to have someone at your company, either the person who knows the most about the topic or the person who did the research, ready to answer questions that writers may have about the content.

But in general, promotional success will be heavily based on the quality of the content you’re pitching, especially if the writer isn’t familiar with who you are.

Conclusion

Is this type of strategy easy? No. It’s much simpler to pay for links or churn out quick blog posts.

But if you’re looking for long-lasting, sustainable, never-to-be-penalized, link-and-authority-building content, this is your best route.

As we can see here, a combination of existing domain authority, an injection of a large number of new high-authority links, and a topically relevant/related piece of content for the brand can generate huge numbers of new ranking keywords extremely quickly.

If you don’t have that level of domain authority, don’t worry! This strategy can still work for you — just don’t expect it to happen overnight (as that’s so rarely the case for anyone).

It’s an investment, but as we’ve seen time and time again, it pays off exponentially.

---

To learn more about keyword research, visit the Keyword Research Master Guide!

THE KEYWORD RESEARCH MASTER GUIDE

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!

from The Moz Blog https://ift.tt/2xtaeUi
via IFTTT

Creating a Gauge in React

You should really look at everything Amelia does, but I get extra excited about her interactive blog posts. Her latest about creating a gauge with SVG in React is unreal. Just the stuff about understanding viewBox is amazing and that’s like 10% of it.

Don’t miss her earlier posts like the one on CSS Cascade or React Hooks either.

Direct Link to Article — Permalink

The post Creating a Gauge in React appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2NMBMth
via IFTTT

Phuoc Nguyen’s One Page Wonders

I keep running across these super useful one page sites, and they keep being by the same person! Like this one with over 100 vanilla JavaScript DOM manipulation recipes, this similar one full of one-liners, and this one with loads of layouts. For that last one, making 91 icons for all those design patterns is impressive alone. High five, Phuoc.

This is my favorite sort of marketing. Some of the products aren’t free, like the React PDF Viewer. How do you get people to know about your paid thing? Give a bunch of useful stuff away for free and have the paid thing sitting right next to it.

The post Phuoc Nguyen’s One Page Wonders appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2KP1F9A
via IFTTT

React Integration Testing: Greater Coverage, Fewer Tests

Integration tests are a natural fit for interactive websites, like ones you might build with React. They validate how a user interacts with your app without the overhead of end-to-end testing. 

This article follows an exercise that starts with a simple website, validates behavior with unit and integration tests, and demonstrates how integration testing delivers greater value from fewer lines of code. The content assumes a familiarity with React and testing in JavaScript. Experience with Jest and React Testing Library is helpful but not required.

There are three types of tests:

• Unit tests verify one piece of code in isolation. They are easy to write, but can miss the big picture.
• End-to-end tests (E2E) use an automation framework — such as Cypress or Selenium — to interact with your site like a user: loading pages, filling out forms, clicking buttons, etc. They are generally slower to write and run, but closely match the real user experience.
• Integration tests fall somewhere in between. They validate how multiple units of your application work together but are more lightweight than E2E tests. Jest, for example, comes with a few built-in utilities to facilitate integration testing; Jest uses jsdom under the hood to emulate common browser APIs with less overhead than automation, and its robust mocking tools can stub out external API calls.

Another wrinkle: In React apps, unit and integration are written the same way, with the same tools. 

Getting started with React tests

I created a simple React app (available on GitHub) with a login form. I wired this up to reqres.in, a handy API I found for testing front-end projects.

You can log in successfully:

…or encounter an error message from the API:

The code is structured like this:

LoginModule/
├── components/
⎪   ├── Login.js // renders LoginForm, error messages, and login confirmation
⎪   └── LoginForm.js // renders login form fields and button
├── hooks/
⎪    └── useLogin.js // connects to API and manages state
└── index.js // stitches everything together

Option 1: Unit tests

If you’re like me, and like writing tests — perhaps with your headphones on and something good on Spotify — then you might be tempted to knock out a unit test for every file. 

Even if you’re not a testing aficionado, you might be working on a project that’s “trying to be good with testing” without a clear strategy and a testing approach of “I guess each file should have its own test?”

That would look something like this (where I’ve added unit to test file names for clarity):

LoginModule/
├── components/
⎪   ├── Login.js
⎪   ├── Login.unit.test.js
⎪   ├── LoginForm.js
⎪   └── LoginForm.unit.test.js
├── hooks/
⎪   ├── useLogin.js 
⎪   └── useLogin.unit.test.js
├── index.js
└── index.unit.test.js

I went through the exercise of adding each of these unit tests on on GitHub, and created a test:coverage:unit  script to generate a coverage report (a built-in feature of Jest). We can get to 100% coverage with the four unit test files:

100% coverage is usually overkill, but it’s achievable for such a simple codebase.

Let’s dig into one of the unit tests created for the onLogin React hook. Don’t worry if you’re not well-versed in React hooks or how to test them.

test('successful login flow', async () => {
  // mock a successful API response
  jest
    .spyOn(window, 'fetch')
    .mockResolvedValue({ json: () => ({ token: '123' }) });


  const { result, waitForNextUpdate } = renderHook(() => useLogin());


  act(() => {
    result.current.onSubmit({
      email: 'test@email.com',
      password: 'password',
    });
  });


  // sets state to pending
  expect(result.current.state).toEqual({
    status: 'pending',
    user: null,
    error: null,
  });


  await waitForNextUpdate();


  // sets state to resolved, stores email address
  expect(result.current.state).toEqual({
    status: 'resolved',
    user: {
      email: 'test@email.com',
    },
    error: null,
  });
});

This test was fun to write (because React Hooks Testing Library makes testing hooks a breeze), but it has a few problems. 

First, the test validates that a piece of internal state changes from 'pending' to 'resolved'; this implementation detail is not exposed to the user, and therefore, probably not a good thing to be testing. If we refactor the app, we’ll have to update this test, even if nothing changes from the user’s perspective.

Additionally, as a unit test, this is just part of the picture. If we want to validate other features of the login flow, such as the submit button text changing to “Loading,” we’ll have to do so in a different test file.

Option 2: Integration tests

Let’s consider the alternative approach of adding one integration test to validate this flow:

LoginModule/
├── components/
⎪   ├─ Login.js
⎪   └── LoginForm.js
├── hooks/
⎪   └── useLogin.js 
├── index.js
└── index.integration.test.js

I implemented this test and a test:coverage:integration script to generate a coverage report. Just like the unit tests, we can get to 100% coverage, but this time it’s all in one file and requires fewer lines of code.

Here’s the integration test covering a successful login flow:

test('successful login', async () => {
  // mock a successful API response
  jest
    .spyOn(window, 'fetch')
    .mockResolvedValue({ json: () => ({ token: '123' }) });


  const { getByLabelText, getByText, getByRole } = render(<LoginModule />);


  const emailField = getByLabelText('Email');
  const passwordField = getByLabelText('Password');
  const button = getByRole('button');


  // fill out and submit form
  fireEvent.change(emailField, { target: { value: 'test@email.com' } });
  fireEvent.change(passwordField, { target: { value: 'password' } });
  fireEvent.click(button);


  // it sets loading state
  expect(button.disabled).toBe(true);
  expect(button.textContent).toBe('Loading...');


  await waitFor(() => {
    // it hides form elements
    expect(button).not.toBeInTheDocument();
    expect(emailField).not.toBeInTheDocument();
    expect(passwordField).not.toBeInTheDocument();


    // it displays success text and email address
    const loggedInText = getByText('Logged in as');
    expect(loggedInText).toBeInTheDocument();
    const emailAddressText = getByText('test@email.com');
    expect(emailAddressText).toBeInTheDocument();
  });
});

I really like this test, because it validates the entire login flow from the user’s perspective: the form, the loading state, and the success confirmation message. Integration tests work really well for React apps for precisely this use case; the user experience is the thing we want to test, and that almost always involves several different pieces of code working together.

This test has no specific knowledge of the components or hook that makes the expected behavior work, and that’s good. We should be able to rewrite and restructure such implementation details without breaking the tests, so long as the user experience remains the same.

I’m not going to dig into the other integration tests for the login flow’s initial state and error handling, but I encourage you to check them out on GitHub.

So, what does need a unit test?

Rather than thinking about unit vs. integration tests, let’s back up and think about how we decide what needs to be tested in the first place. LoginModule needs to be tested because it’s an entity we want consumers (other files in the app) to be able to use with confidence.

The onLogin hook, on the other hand, does not need to be tested because it’s only an implementation detail of LoginModule. If our needs change, however, and onLogin has use cases elsewhere, then we would want to add our own (unit) tests to validate its functionality as a reusable utility. (We’d also want to move the file because it wouldn’t be specific to LoginModule anymore.)

There are still plenty of use cases for unit tests, such as the need to validate reusable selectors, hooks, and plain functions. When developing your code, you might also find it helpful to practice test-driven development with a unit test, even if you later move that logic higher up to an integration test.

Additionally, unit tests do a great job of exhaustively testing against multiple inputs and use cases. For example, if my form needed to show inline validations for various scenarios (e.g. invalid email, missing password, short password), I would cover one representative case in an integration test, then dig into the specific cases in a unit test.

Other goodies

While we’re here, I want to touch on few syntactic tricks that helped my integration tests stay clear and organized.

Big waitFor Blocks

Our test needs to account for the delay between the loading and success states of LoginModule:

const button = getByRole('button');
fireEvent.click(button);


expect(button).not.toBeInTheDocument(); // too soon, the button is still there!

We can do this with DOM Testing Library’s waitFor helper:

const button = getByRole('button');
fireEvent.click(button);


await waitFor(() => {
  expect(button).not.toBeInTheDocument(); // ahh, that's better
});

But, what if we want to test some other items too? There aren’t a lot of good examples of how to handle this online, and in past projects, I’ve dropped additional items outside of the waitFor:

// wait for the button
await waitFor(() => {
  expect(button).not.toBeInTheDocument();
});


// then test the confirmation message
const confirmationText = getByText('Logged in as test@email.com');
expect(confirmationText).toBeInTheDocument();

This works, but I don’t like it because it makes the button condition look special, even though we could just as easily switch the order of these statements:

// wait for the confirmation message
await waitFor(() => {
  const confirmationText = getByText('Logged in as test@email.com');
  expect(confirmationText).toBeInTheDocument();
});


// then test the button
expect(button).not.toBeInTheDocument();

It’s much better, in my opinion, to group everything related to the same update together inside the waitFor callback:

await waitFor(() => {
  expect(button).not.toBeInTheDocument();
  
  const confirmationText = getByText('Logged in as test@email.com');
  expect(confirmationText).toBeInTheDocument();
});

Interestingly, an empty waitFor will also get the job done, because waitFor has a default timeout of 50ms. I find this slightly less declarative than putting your expectations inside of the waitFor, but some indentation-averse developers may prefer it: 

await waitFor(() => {}); // or maybe a custom util, `await waitForRerender()`


expect(button).not.toBeInTheDocument(); // I pass!

For tests with a few steps, we can have multiple waitFor blocks in row:

const button = getByRole('button');
const emailField = getByLabelText('Email');


// fill out form
fireEvent.change(emailField, { target: { value: 'test@email.com' } });


await waitFor(() => {
  // check button is enabled
  expect(button.disabled).toBe(false);
});


// submit form
fireEvent.click(button);


await waitFor(() => {
  // check button is no longer present
  expect(button).not.toBeInTheDocument();
});

Inline it comments

Another testing best practice is to write fewer, longer tests; this allows you to correlate your test cases to significant user flows while keeping tests isolated to avoid unexpected behavior. I subscribe to this approach, but it can present challenges in keeping code organized and documenting desired behavior. We need future developers to be able to return to a test and understand what it’s doing, why it’s failing, etc.

For example, let’s say one of these expectations starts to fail:

it('handles a successful login flow', async () => {
  // beginning of test hidden for clarity


  expect(button.disabled).toBe(true);
  expect(button.textContent).toBe('Loading...');


  await waitFor(() => {
    expect(button).not.toBeInTheDocument();
    expect(emailField).not.toBeInTheDocument();
    expect(passwordField).not.toBeInTheDocument();


    const confirmationText = getByText('Logged in as test@email.com');
    expect(confirmationText).toBeInTheDocument();
  });
});

A developer looking into this can’t easily determine what is being tested and might have trouble deciding whether the failure is a bug (meaning we should fix the code) or a change in behavior (meaning we should fix the test).

My favorite solution to this problem is using the lesser-known test syntax for each test, and adding inline it-style comments describing each key behavior being tested:

test('successful login', async () => {
  // beginning of test hidden for clarity


  // it sets loading state
  expect(button.disabled).toBe(true);
  expect(button.textContent).toBe('Loading...');


  await waitFor(() => {
    // it hides form elements
    expect(button).not.toBeInTheDocument();
    expect(emailField).not.toBeInTheDocument();
    expect(passwordField).not.toBeInTheDocument();


    // it displays success text and email address
    const confirmationText = getByText('Logged in as test@email.com');
    expect(confirmationText).toBeInTheDocument();
  });
});

These comments don’t magically integrate with Jest, so if you get a failure, the failing test name will correspond to the argument you passed to your test tag, in this case 'successful login'. However, Jest’s error messages contain surrounding code, so these it comments still help identify the failing behavior. Here’s the error message I got when I removed the not from one of my expectations:

For even more explicit errors, there’s package called jest-expect-message that allows you to define error messages for each expectation:

expect(button, 'button is still in document').not.toBeInTheDocument();

Some developers prefer this approach, but I find it a little too granular in most situations, since a single it often involves multiple expectations.

Next steps for teams

Sometimes I wish we could make linter rules for humans. If so, we could set up a prefer-integration-tests rule for our teams and call it a day.

But alas, we need to find a more analog solution to encourage developers to opt for integration tests in a situation, like the LoginModule example we covered earlier. Like most things, this comes down to discussing your testing strategy as a team, agreeing on something that makes sense for the project, and — hopefully — documenting it in an ADR.

When coming up with a testing plan, we should avoid a culture that pressures developers to write a test for every file. Developers need to feel empowered to make smart testing decisions, without worrying that they’re “not testing enough.” Jest’s coverage reports can help with this by providing a sanity check that you’re achieving good coverage, even if the tests are consolidated that the integration level.

I still don’t consider myself an expert on integration tests, but going through this exercise helped me break down a use case where integration testing delivered greater value than unit testing. I hope that sharing this with your team, or going through a similar exercise on your codebase, will help guide you in incorporating integration tests into your workflow.

The post React Integration Testing: Greater Coverage, Fewer Tests appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/35n3BPT
via IFTTT

Enable Gatsby Incremental Builds on Netlify

The concept of an “incremental build” is that, when using some kind of generator that builds all the files that make for a website, rather than rebuilding 100% of those files every single time, it only changes the files that need to be changed since the last build. Seems like an obviously good idea, but in practice I’m sure it’s extremely tricky. How do you know what exactly which files will change and which won’t before building?

I don’t have the answer to that, but Gatsby has it figured out. Faster local builds is half the joy, the other half is that deployment also becomes faster, as the files that need to move around are far fewer.

I’d say incremental builds are a pretty damn big deal. I like seeing these hurdles get cleared Jamstack-land. I’m linking to the Netlify blog post here as getting it going on Netlify requires you to enable their “build plugins” feature which is also a real ahead-of-the-game feature, allowing you to run code during different parts of CI/CD with a really clean syntax.

Direct Link to Article — Permalink

The post Enable Gatsby Incremental Builds on Netlify appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/34Y4I8E
via IFTTT

Building Better Customer Experiences - Best of Whiteboard Friday

Posted by DiTomaso

Are you mindful of your customer's experience after they become a lead? It's easy to fall in the same old rut of newsletters, invoices, and sales emails, but for a truly exceptional customer experience that improves their retention and love for your brand, you need to go above and beyond. In this popular episode of Whiteboard Friday, the ever-insightful Dana DiTomaso shares three big things you can start doing today that will immensely better your customer experience and make earning those leads worthwhile.

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

Video Transcription

Hi, Moz fans. My name is Dana DiTomaso. I'm the President and partner of Kick Point, and today I'm going to talk to you about building better customer experiences. I know that in marketing a lot of our jobs revolve around getting leads and more leads and why can't we have all of the leads.

The typical customer experience:

But in reality, the other half of our job should be making sure that those leads are taken care of when they become customers. This is especially important if you don't have, say, a customer care department. If you do have a customer care department, really you should be interlocking with what they do, because typically what happens, when you're working with a customer, is that after the sale, they usually get surveys.

- Surveys

"How did we do? Please rate us on a scale of 1 to 10," which is an enormous scale and kind of useless. You're a 4, or you're an 8, or you're a 6. Like what actually differentiates that, and how are people choosing that?

- Invoices

Then invoices, like obviously important because you have to bill people, particularly if you have a big, expensive product or you're a SaaS business. But those invoices are sometimes kind of impersonal, weird, and maybe not great.

- Newsletters

Maybe you have a newsletter. That's awesome. But is the newsletter focused on sales? One of the things that we see a lot is, for example, if somebody clicks a link in the newsletter to get to your website, maybe you've written a blog post, and then they see a great big popup to sign up for our product. Well, you're already a customer, so you shouldn't be seeing that popup anymore.

What we've seen on other sites, like Help Scout actually does a great job of this, is that they have a parameter of newsletter at the end of any URLs they put in their newsletter, and then the popups are suppressed because you're already in the newsletter so you shouldn't see a popup encouraging you to sign up or join the newsletter, which is kind of a crappy experience.

- Sales emails

Then the last thing are sales emails. This is my personal favorite, and this can really be avoided if you go into account-based marketing automation instead of personal-based marketing automation.

We had a situation where I was a customer of the hosting company. It was in my name that we've signed up for all of our clients, and then one of our developers created a new account because she needed to access something. Then immediately the sales emails started, not realizing we're at the same domain. We're already a customer. They probably shouldn't have been doing the hard sale on her. We've had this happen again and again.

So just really make sure that you're not sending your customers or people who work at the same company as your customers sales emails. That's a really cruddy customer experience. It makes it look like you don't know what's going on. It really can destroy trust.

Tips for an improved customer experience

So instead, here are some extra things that you can do. I mean fix some of these things if maybe they're not working well. But here are some other things you can do to really make sure your customers know that you love them and you would like them to keep paying you money forever.

1. Follow them on social media

So the first thing is following them on social. So what I really like to do is use a tool such as FullContact. You can take everyone's email addresses, run them through FullContact, and it will come back to you and say, "Here are the social accounts that this person has." Then you go on Twitter and you follow all of these people for example. Or if you don't want to follow them, you can make a list, a hidden list with all of their social accounts in there.

Then you can see what they share. A tool like Nuzzel, N-U-Z-Z for Americans, zed zed for Canadians, N-U-Z-Z-E-L is a great tool where you can say, "Tell me all the things that the people I follow on social or the things that this particular list of people on social what they share and what they're engaged in." Then you can see what your customers are really interested in, which can give you a good sense of what kinds things should we be talking about.

A company that does this really well is InVision, which is the app that allows you to share prototypes with clients, particularly design prototypes. So they have a blog, and a lot of that blog content is incredibly useful. They're clearly paying attention to their customers and the kinds of things they're sharing based on how they build their blog content. So then find out if you can help and really think about how I can help these customers through the things that they share, through the questions that they're asking.

Then make sure to watch unbranded mentions too. It's not particularly hard to monitor a specific list of people and see if they tweet things like, "I really hate my (insert what you are)right now," for example. Then you can head that off at the pass maybe because you know that this was this customer. "Oh, they just had a bad experience. Let's see what we can do to fix it,"without being like, "Hey, we were watching your every move on Twitter.Here's something we can do to fix it."

Maybe not quite that creepy, but the idea is trying to follow these people and watch for those unbranded mentions so you can head off a potential angry customer or a customer who is about to leave off at the pass. Way cheaper to keep an existing customer than get a new one.

2. Post-sale monitoring

So the next thing is post-sale monitoring. So what I would like you to do is create a fake customer. If you have lots of sales personas, create a fake customer that is each of those personas, and then that customer should get all the emails, invoices, everything else that a regular customer that fits that persona group should get.

Then take a look at those accounts. Are you awesome, or are you super annoying? Do you hear nothing for a year, except for invoices, and then, "Hey, do you want to renew?" How is that conversation going between you and that customer? So really try to pay attention to that. It depends on your organization if you want to tell people that this is what's happening, but you really want to make sure that that customer isn't receiving preferential treatment.

So you want to make sure that it's kind of not obvious to people that this is the fake customer so they're like, "Oh, well, we're going to be extra nice to the fake customer." They should be getting exactly the same stuff that any of your other customers get. This is extremely useful for you.

3. Better content

Then the third thing is better content. I think, in general, any organization should reward content differently than we do currently.

Right now, we have a huge focus on new content, new content, new content all the time, when in reality, some of your best-performing posts might be old content and maybe you should go back and update them. So what we like to tell people about is the Microsoft model of rewarding. They've used this to reward their employees, and part of it isn't just new stuff. It's old stuff too. So the way that it works is 33% is what they personally have produced.

So this would be new content, for example. Then 33% is what they've shared. So think about for example on Slack if somebody shares something really useful, that's great. They would be rewarded for that. But think about, for example, what you can share with your customers and how that can be rewarding, even if you didn't write it, or you can create a roundup, or you can put it in your newsletter.

Like what can you do to bring value to those customers? Then the last 33% is what they shared that others produced. So is there a way that you can amplify other voices in your organization and make sure that that content is getting out there? Certainly in marketing, and especially if you're in a large organization, maybe you're really siloed, maybe you're an SEO and you don't even talk to the paid people, there's cool stuff happening across the entire organization.

A lot of what you can bring is taking that stuff that others have produced, maybe you need to turn it into something that is easy to share on social media, or you need to turn it into a blog post or a video, like Whiteboard Friday, whatever is going to work for you, and think about how you can amplify that and get it out to your customers, because it isn't just marketing messages that customers should be seeing.

They should be seeing all kinds of messages across your organization, because when a customer gives you money, it isn't just because your marketing message was great. It's because they believe in the thing that you are giving them. So by reinforcing that belief through the types of content that you create, that you share, that you find that other people share, that you shared out to your customers, a lot of sharing, you can certainly improve that relationship with your customers and really turn just your average, run-of-the-mill customer into an actual raving fan, because not only will they stay longer, it's so much cheaper to keep an existing customer than get a new one, but they'll refer people to you, which is also a lot easier than buying a lot of ads or spending a ton of money and effort on SEO.

Thanks!

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!

from The Moz Blog https://ift.tt/35nCHHy
via IFTTT

The Hero Generator

Sarah:

I’ve had to implement the same hero for several years now, so like a good lazy programmer, I figured I’d automate it.

Direct Link to Article — Permalink

The post The Hero Generator appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2x9U7Lc
via IFTTT