Storytelling 301: Site Content as Story

Posted by Isla_McKetta

Feel like you’re already over the term “storytelling” without ever really having understood how you can successfully apply it to your writing? You aren’t alone. Like so much jargon, this amazingly powerful and useful word is in serious danger of being consigned to LinkedIn profiles and marketing parody.

Even storytelling guru Annette Simmons is over the way we’re teaching storytelling as a content cure-all.

“We need to stop ‘telling stories’ that oxytocin or the magic of a ‘narrative arc’ explain storytelling. It’s much bigger than science can explain. Storytelling is an art – subjective, emotional, and as variable as humanity is diverse.” – Annette Simmons

We can do better. Instead of yet another “stories=good” post, today we’re going to apply the logic of storytelling to site content. After you’ve read the last word, you should have the tools you need to draw a concrete map of how to tell your brand “story” with site content.

Note: I’m not knocking storytelling here. I’m a novelist. That’s illegal. I am knocking throwing the latest buzzword at our marketing and pretending like using the word makes us better at our jobs.

Why storytelling

I promised not to flog you with the “stories are engaging so be engaging by telling stories” line, but if we dig just a little deeper we can understand one of the concrete arguments for storytelling: persuasion.

In her compelling book, The Story Factor, Annette Simmons reminds us that we can throw facts and figures at people all day long, but stories hold the real power to change someone’s mind.

“Your story needs to take [potential customers] on a tour of the aspects that step by step convinced you to believe so they can step by step come to believe the same things” – Annette Simmons

Take a moment to check this against your own experience. When was the last time someone truly shifted your perspective? If they did so using anything other than a story, it’s okay to stop reading here and find a tactic that you think will work better. But my guess is that some sort of story was involved.

The six types of story

Simmons outlines six types of stories we can use as humans and marketers to overcome objections:

“Who I am” stories and “why I am here” stories establish the groundwork you need to build trust with your audience. They naturally assume you’re in it for yourself and these stories allow you to share your motivations. If you get human enough, your audience might find common ground on which to connect with you.

Vision stories tell how things could be. This type of story shows your audience what’s in it for them. If you’re holding an all-hands meeting, your vision story might include a tale about how the company has triumphed over obstacles in the past. If you’re marketing a product, your vision story might speak to a future state where a problem (that your product solves) no longer has to exist.

Teaching stories give your audience an opportunity to learn from a mistake without ever having to make it. They also help you shape that audience’s understanding of the potential solutions available to them. For example, if I were to tell you that a site audit can help you understand all the content resources you have available to you and use Moz Content as my auditing tool, I’d be pointing you in the direction of a solution for you and also making it easy for you to choose our solution.

Values-in-action stories are similar to vision stories and teaching stories, but they focus on the core values you want to reinforce and provide examples. Simmons suggests focusing on positive value stories rather than “war stories.” One way to do this would be if a wedding dress company that prided itself on proper etiquette wrote a blog post about a bridal consultant who hand-wrote a thank-you card to every bride who purchased a dress from her.

The final type of story, the “I know what you are thinking” story, allows you to neutralize concern without that concern ever being raised. It’s relatively easy to anticipate an objection from your audience and to use this kind of story to get ahead of it.

Applying storytelling to site content

This is where I wish I had a gorgeous illustration of the marketing funnel and that I could neatly fit these six story types in and presto change-o, poof! Your site content is perfectly optimized for storytelling and conversion.

Alas, life is a little harder than that. But we can get a good sense of which types of content are best for telling which types of stories. I’ll use Moz as an example because that’s close to my heart.

Who we are and why we’re here

Moz is about three things: helping people be better marketers, building a strong community, and being TAGFEE. Free educational content has been a huge part of who we are since the very beginning when Rand was blogging about everything from the Google Link Command to Sandbox. That strong community is here because all of you make it happen, and because we work to make TAGFEE happen every day.

You can see our desire to help people be better marketers and to connect with the community right up at the top of our site. Click on “Learn & Connect” to bring down a bucket of resources like our beginner’s guides to SEO, Content Marketing, and Social Media, as well as our webinars, blog, and Q&A.

We also share who we are on our about, TAGFEE, and team pages.

You’ll note that all of this content is front and center because it helps our audience get to know us. Our audience becomes acquainted with our slightly quirky personality through our voice and the style of our imagery. We put our values out in the open for all to see so we can hold ourselves accountable and so our audience can know what to expect. And you can tell a lot about Moz by the fact that everyone who wants to be is listed on our team page (not just a selection of the top execs) and that each individual Mozzer’s page has their own voice.

Help your potential customers get to know you by sharing “who you are” and “why you’re here” stories in the content and form of your home, about, and team pages.

Our vision

The homepage is a perfect place to introduce an audience to your vision story:

But to really shape their expectations about what life could be like if only they’d use your products, you’ll want to flesh out that vision story in content such as product descriptions and white papers.

Notice that all the vision stories, no matter where they are on the site, elaborate on and reinforce the same vision. Some pieces will speak to a greater ecosystem and others will pinpoint how your products bring that vision to life. Which role they play depends largely on where that piece of content sits in your funnel.

Teaching

You’re reading teaching story content right now. I’m not trying to sell you anything at all, but I am trying to give you a new way of thinking about the work you do – to help you make better marketing. I’m also, on a meta level, teaching you about how Moz thinks about marketing, including how we see value in going beyond superficial monikers like “storytelling” and “keywords” to provide actual applied insight.

Although I mentioned our beginner’s guides as “who we are”-type stories, they are also teaching stories. You may have noticed that we don’t have a beginner’s guide to pay-per-click advertising. That’s not because PPC isn’t important, but it is because our story is about the difference you can make with SEO, content marketing, and influencer marketing.

Big content can also be part of your teaching story. We use our Search Ranking Factors and Local Search Ranking Factors surveys to explore and share the changing nature of search, which helps focus our potential customers on asking the right questions about ranking better (instead of “where can I buy links?”).

Mozcast plays a similar role by pointing people’s attention to potential signs of shifts in Google’s search algorithm. It is a useful tool, yes, for monitoring and predicting the search climate. It’s also a story that teaches how much the algorithm changes and that SEO is not a one-and-done project.

Depending on who you are, your teaching stories might help your audience see fashion from the lens of accessories, understand that the value of your products is in sending matching items to the developing world, or see how essential connection speed is to saving money. Shape that conversation on your blog and in your big content.

Values in action

Our blog also tells values in action stories. We do this both through the teaching that is so core to who we are but also through the tone of content on the blog. This goes back to TAGFEE. Rarely (if ever) will you see a brand or competitor called to the carpet on our site. And our product and company updates are just as likely to tell you the ugly side of why we made the improvement as they are to celebrate the update, like this announcement of Keyword Explorer:

You’ll also find values in action stories in our help documentation as we try to provide straightforward but fun information to help you be the best marketer you can be.

http://fast.wistia.net/embed/iframe/2gwfjaajuk

Demonstrate your values in action by telling the story of efficient project management with a datasheet that doubles as a purchasing checklist to help your buyer overcome internal objections. Or teach your customers how to use the spices you sell by turning help documentation into recipes.

We know what you are thinking

Wow, that’s a lot of talk about us. Most of our audience would be wondering right now if we can really live up to that hype. That makes this the perfect moment to share a “we know what you are thinking” story. Some of the best site content forms for putting the proof in your pudding are social proof (in the form of testimonials) and case studies.

Your turn

Ready to put storytelling into your site content? The framework is universal, but the application of it will be very individual to your experience. I’d love to hear how you’ve incorporated these six types of stories into your site, along with what’s working for you and what isn’t.

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!

The Search Marketer’s Guide to ItemRef & ItemID

Posted by Mike_Arnesen

Structured data has never been more important than it is today. We’ll talk about why briefly below, but that’s not what this post is about. This post is about giving you a new tool to add to your semantic SEO tool belt. My goal is to empower you implement semantic markup and structured data with greater ease and enable you to architect a more robust and complete web of linked data on your website (and beyond).

Structured data is more important than ever

I don’t think that’s an exaggeration. When Schema.org launched in June of 2011, search marketers gained access to an incredibly powerful tool: an extensive vocabulary, agreed upon by the world’s leading search engines, with which we could give our data meaningful structure.

However, there were two things holding us back from realizing the dream of a truly semantic web.

  1. The difficulty of actually implementing said markup on our sites.
  2. The markup’s limited utility in actually achieving some kind of tangible SEO return on our investment.

I believe JSON-LD’s big day at Google was a watershed moment in making implementation less daunting and, hopefully in the coming years, ubiquitous across the web (well, at least more so). Now that we have rapidly growing JSON-LD support from Google and powerful semantic attributes like Itemref and Itemid, the ability to give structure to the unstructured is within everyone’s reach.

The tangible SEO return has also never been greater! Beyond tried and true rich snippets for star ratings, pricing, availability, and breadcrumbs in search, we’re seeing richer and richer results, previews, and cards show up in Google. These are powered by, you guessed it, structured data and, more often than not, the recommended format is in JSON-LD. In light of Google’s recent launch of Rich Cards (starting with Recipes and Movies, but sure to be expanding to other Schema types soon), Top Stories with AMP, and Knowledge Panel Critic Reviews (which is currently by request and with Google approval only), we need flexible models for structuring bigger and bigger data sets.

Through using itemref and itemid, you’ll be able to mark up your data that much easier to keep up with the rapid evolution of semantic SEO. You’ll also be positioned to fully capitalize on new search features, regardless of whether or not they require JSON-LD or in-line microdata (remember that while Google is now all about JSON-LD, they’re not the only game in town).

That’s enough of an intro; let’s talk itemref and itemid.

What are itemref & itemid?

At their core, itemref and itemid are just HTML attributes. They’re actually very similar to other attributes that you’re already familiar with if you’ve worked with semantic markup before.

The 3 most common attributes in semantic SEO

Let’s quickly recap what itemscope, itemtype, and itemprop do. Feel free to skip to the next section, though it never hurts to brush up.

Itemscope: an attribute without a value that defines the scope of an semantic entity within your data. Everything within that itemscope is considered a part of that entity and everything outside of it is separate.

Itemtype: an attribute that goes hand-in-hand with itemscope and that does have a value. The value of the itemtype attribute is going to specify the type of entity you’re marking up and is most commonly a link to a URL on schema.org.

Itemprop: an attribute used to declare specific attributes of your entity (e.g. itemprop= “name”, itemprop=”description”, etc.)

Mike Arnesen

The 2 hidden attributes in semantic SEO

It’s fairly easy to guess what itemref and itemid are just by looking at their names, but it’s a little harder to figure out how to use them (don’t worry, we’ll get to that part later).

Itemref: an attribute that allows you to reference other data points outside of the itemscope.

Itemid: an attribute that allows you to give an entity a unique identifier. This entity can then be used to flesh out another entity as an embedded entity.

<div itemid="http://www.upbuild.io/#upbuildOrg&quot;

itemscope itemtype=”http://schema.org/Organization&#8221; >

But why do we even need these?

The challenge with inline markup

The challenge we face with inline microdata is that it’s brittle and breaks easily. It’s also very rigid in terms of implementation. Itemref and itemid help us overcome that!

Consider the page below:

inline-microdata-is-rigid.png

The primary entity that you want to mark up on this page is a Product, but you’ll likely want to mark up the BreadcrumbList as well. Assuming that each highlighted area lives in its own

tag, you have some potential issues.

  1. If you declare your itemtype=”product” on the overarching
    that contains all three areas, you forfeit the opportunity to mark up breadcrumbs. Why? Because a BreadcrumbList isn’t a valid a property of a Product.
  1. If you declare your itemtype=”product” on the blue
    , you can still mark up the breadcrumbs on the red

    , but you won’t be able connect the data in the green

    to your main Product and your structured data won’t validate since offers (AKA, the price) is required.

Traditionally, you’d have a make a non-ideal compromise or have a developer change how the whole page was structured. There’s no way around it; that sucks!

How itemref and itemid empower you

With itemid and itemref, you can write semantic markup that reaches across disparate

tags and pulls in the data points you need without requiring any restructuring.

So what’s the difference between these two tags and when do you use one over the other?

  • Use itemref when you need to populate itemprops in your primary entity. For example, if the commentCount of a blog post was written in a
    outside of the main post’s body.
  • Use itemid when you need to populate itemprops where the expected type (more on expected types from Schema.org) is another entity (not just a simple data point). For example, if you wanted to declare the publisher of a blog post, you’d want to point to a complete Organization entity (complete with a name, logo, URL, and perhaps even founder, address, contact points, etc.)

How to use itemref

An easy way to conceptualize the use of itemref is to imagine connecting a data blob to the semantic entity you’re working on. I first heard the term “data blob” from Jarno van Driel, someone who I’d consider my Itemref and Itemid Sensei, and I think it’s a fitting description.

Data blob

noun | \ˈdā-tə- bläb\

a blob of data that just hangs around doing nothing special, until it’s called into service by another entity. More formally, a discoverable resource within a document.

Screen Shot 2016-06-29 at 1.58.41 PM.png

To keep this brief, let’s assume you’ve already marked up your Primary Entity to the best of your ability and, for the purposes of demonstration, let’s say we’re marking up a blog post (AKA, BlogPosting). Furthermore, let’s say that the one itemprop data point we can’t get at using traditional means is the commentCount for the blog post; it’s in a

that’s completely outside the scope of the blog post’s body.

Screen Shot 2016-06-29 at 1.57.38 PM.png

In order to solve this, we’ll want to mark up the commentCount as a data blob that contains an unlinked and unused commentCount property. There are three main steps:

Step 1: In the

, , or other HTML element that contains the commentCount, add an itemscope attribute. That’s it. In a deviation from the norm, you don’t want to follow that by specifying an itemtype. That’s why it’s called a data blob; it’s independent data without a type. In fact, when you eventually test this in Google’s Structured Data Testing Tool, you’ll see it pick up on an “Unspecified Type.” That’s fine; just ignore it.

Screen Shot 2016-06-30 at 2.07.28 PM.png

The finished tag should look like this:

Step 2: Wrap a new tag around the comment count itself and specify what itemprop this is going to be. At this point, it’s a property of nothing and that’s okay.

Now the finished tag should look like this:

108

Step 3: Lastly, you’ll want to create a unique identifier for this data blob (so you can reference it later). To do that, just add a basic id to the tag.

The updated tag will look like this:

108

Sidenote: Can Itemref Be Used with Meta Tags? Yes! Just go through Step 2 and Step 3 on meta tags in your and you can reference them from an entity in your tag using itemref! However, with meta tags there’s no need to add an itemscope; skip Step 1.

Now we come to my favorite part: hooking the data blob into the main entity. It’s incredibly simple.

Step 4: Find and edit the itemscope/itemtype declaration for your Primary Entity. In this case, it’ll look like this:

Step 5: Within that tag, add the itemref attribute and reference the unique id that you created in Step 3 above.

The finished tag will look like this:

Bonus: You can reference more than one data blob in the same itemref attribute! Just add them one after the other, separated by spaces.

E.g., itemref=”comments wordcount citation alternativeHeadline”

Boom! Now you’re cooking with itemref! Where before you had a pantry full of data that didn’t really go together, now you have an entity that is completely baked and you’re ready to roll.

Screen Shot 2016-06-29 at 3.23.21 PM.png

How to use itemid

Using itemid is actually very similar and may even involve less new code than itemref. Since you use itemid when you want to reference another complete entity, this might be an entity that’s already on the page. If that’s the case, you just add a quick bit of markup and you’re good to go.

In the visual below, what we want to do is use the Secondary Entity to populate an itemprop of the Primary Entity.

Screen Shot 2016-06-29 at 2.52.34 PM.png

Using our blog post example, let’s say we want to reference an Organization entity to populate the publisher itemprop of the BlogPosting entity.

Screen Shot 2016-06-29 at 2.52.41 PM.png

Here’s how we do that:

Step 1: Mark up the Secondary Entity just as you normally would. If you already have that entity on your page and it’s fully marked up, that’s less work for you!

Step 2: In the opening itemscope/itemtype declaration of that entity, add an itemid attribute and give this secondary entity a unique fragment identifier.

It should look like this:

And now we make the magic happen!

Step 3: Within your Primary Entity, add a tag wherever you want to call in the Secondary Entity and specify the itemprop you want your Secondary Entity to populate. Use a simple href attribute to point to the fragment identifier from Step 2.

It should look like this:

Bonus: You can reference this secondary entity from multiple other entities and populate multiple itemprops, too! If this post were a company announcement on moz.com and Moz were both the publisher and the author, both of those properties could reference #mozOrg.

That’s it! Now, regardless of where these two entities live in the DOM (i.e., in your page’s source code), they’ll be linked together and can create something awesome.

“By your powers combined, I am a great blog post!”

Screen Shot 2016-06-29 at 3.11.39 PM.png

Extending the power of itemid to JSON-LD

I can hear some readers asking, “The days of microdata are over! Now that Google’s going to support JSON-LD for everything, who cares?”

First, Google isn’t the only game in town and they don’t yet support JSON-LD for all Schema.org types (but, honestly, I think they will soon). That said, I still think it’s good practice to continue implementing structured data that less evolved crawlers can use.

Second, even though itemref can’t be used within the JSON-LD data model, itemid most definitely can, although in JSON-LD the property is called @id! And boy, does it come in handy.

Let’s talk about why you would use this and then we’ll get into how.

Why @id is great with JSON-LD

The why is pretty straightforward – just like when you’re using microdata, you are likely to have multiple JSON-LD entities on your site and, quite frequently, these will be housed in different scripts in the source code (or in different tags delivered via a tag management tool). Using @id, you can maintain your JSON-LD for each semantic entity separately and just make references between each entity as needed.

For example, consider the blog post you’re currently reading which has structured data for a BlogPosting delivered in JSON-LD. You could avoid having to include all the data for your publisher (the Organization known as Moz) in your JSON-LD script and instead reference a dedicated JSON-LD script for it.

You could host two independent JSON-LD scripts in your page and link them using @id.

Screen Shot 2016-06-29 at 3.55.10 PM.png

In this example, using @id is more cool than useful; it doesn’t save that much time or effort. In fact, it’ll add a bit more code to the page if you’re including two separate JSON-LD scripts (for a BlogPost and an Organization) on every page rather than doing it all in one tag.

Dealing with repetition

But what about when a single entity can be used to populate multiple properties in your JSON-LD? That’s where @id could save you a ton of time and hassle.

Imagine you have an Article page where you want to include structured data about the article’s publisher (#publisher), a video pertaining to the article (published by #publisher), and the article’s author (who worksFor #publisher). Suddenly, having the ability to leverage a single definition of the Publisher entity is very valuable!

Going deeper

If you’re not already sold on @id yet, here’s where it gets crazy. When you use @id with JSON-LD, you can extend its utility massively.

You can use @id in a JSON-LD script to reference

entities on other pages and even other websites!

Let that sink in.

Screen Shot 2016-06-29 at 4.11.50 PM.png

What this means is that you can deliver JSON-LD on every blog post that references an Organization JSON-LD tag on the homepage. You don’t need to repeat that data on each page or update every instance if a datapoint ever changes.

Here are just a few use cases in which you’d want to host JSON-LD for specific entities in centralized locations and reference them throughout your whole site.

  • Hosting your Organization JSON-LD on your company homepage and then using it as:
    • The publisher property on BlogPostings
    • The worksFor property on Person (on your team profiles)
  • Hosting Person JSON-LD for key personnel on your About page and then using those entities as:
    • The author properties on BlogPostings
    • The performer properties on Events
  • (If you’re a local business) Hosting Place JSON-LD about your city on a dedicated landing page and using it as:
    • The areaServed property on LocalBusiness
    • The eligibleRegion property on Offer
    • The foundingLocation property on Organization
    • The jobLocation on property JobPosting

With all of these scenarios, you can use @id to reference entities on other pages to create a literal web of linked data on your website!

How to use @id in JSON-LD

Here’s how to use @id in your JSON-LD.

Step 1: Edit your JSON-LD and give the entity a fragment identifier (e.g., #eru). This uses essentially the same format as the @type property, so you pretty much just copy that. Repeat this process for every JSON-LD script that defines an entity that you want to be able to reference.

The modification to your JSON-LD should look something like this.

{

“@context”: “http://schema.org&#8221;,

“@type”: “Organization”,

“@id”: “#mozOrg”,

“name”: “Moz”,

}

Step 2: In order to reference one of those entities from JSON-LD on another page, provide an @id in the place of a value for the property in question. For example, instead of just providing a text string of “Moz” for the “publisher” on this BlogPosting, we’d refer to the uniquely identified entity by using its @id.

The modification to your JSON-LD would look a bit like this:

{

“@context”: “http://schema.org&#8221;,

“@type”: “BlogPosting”,

“publisher”: {

“@id”: “#mozOrg”

}

}

Now, if the entity you’re pointing to lives on a different page, just use the absolute path rather than the relative one. “#mozOrg” becomes “https://moz.com/#mozOrg”

But wait. There’s more!

This is the part that really blew my mind. Remember that you can reference entities not just on your own website, but on OTHER websites as well. Doing so is really simple, though you do need to have the ability to slightly modify the JSON-LD on both sites.

The possibilities here are insane! Just picture the semantic associations we’re forming on this post alone!

Screen Shot 2016-06-30 at 4.23.31 PM.png

The good news

The process is exactly the same as what’s described above (using @id on your own website), but you definitely need to use the absolute path.

The bad news

This is super hard to validate without building your own web crawler. By their nature, the structured data validation tools that are available to us (like Google’s Structured Data Testing Tool, the Structured Data Linter, or Yandex’s Structured Data Validator) only fetch the one URL that they’re fed. They’re not going to go out and crawl the URLs where the other linked data lives and show you the full picture that their crawlers may be able to get.

In the future, I’m hoping to share concrete proof that Google recognizes linked structured data across domains. Until then, the more cross-site structured data we create, the better our chances are of showing that this works!

Itemref & itemid in action

This wouldn’t be a very good tutorial if it didn’t leave you with something to fiddle with. The code example below will show you how to use itemref in microdata, itemid in microdata, @id to reference entities on the same page, @id to reference entities on other pages (hint: there may be a really cool entity over at https://moz.com/rand/about/#rand if you want to check it out), and @id to reference entities on other websites.

See the Pen The Search Marketer’s Guide to Itemref & Itemid by UpBuild (@upbuild) on CodePen.

http://assets.codepen.io/assets/embed/ei.js

You can even run this example’s URL through the Structured Data Testing Tool to see how Google interprets all the associations. Click here to see!

Screen Shot 2016-06-30 at 5.14.21 PM.png

Until we meet again

I hope that this post has either given you some new tools that will help solve your structured data problems or has stoked your curiosity to see what’s possible with advanced JSON-LD. Good luck out there and happy optimizing!

{

“@context”: “http://schema.org&#8221;,

“@type”: “BlogPosting”,

“mainEntityOfPage”:{

“@type”:”WebPage”,

“@id”:”https://moz.com/blog/search-marketers-guide-to-itemref-itemid&#8221;

},

“headline”: “The Search Marketer’s Guide to Itemref & Itemid”,

“image”: {

“@type”: “ImageObject”,

“url”: “https://dc8hdnsmzapvm.cloudfront.net/assets/images/blog/categories/advanced-seo.png&#8221;,

“height”: 440,

“width”: 880

},

“datePublished”: “2016-07-07T00:16:00-07:00”,

“dateModified”: “2016-07-07T19:30:25-07:00”,

“author”: {

“@id”: “http://www.mikearnesen.com/about#arnesen&#8221;

},

“publisher”: {

“@type”: “Organization”,

“@id”: “#mozOrg”,

“name”: “Moz”,

“logo”: {

“@type”: “ImageObject”,

“url”: “https://d2eeipcrcdle6.cloudfront.net/brand-guide/logos/moz_blue.png&#8221;,

“width”: 134,

“height”: 39

},

“url”: “https://moz.org&#8221;,

“founder”: {

“@id”: “https://moz.com/rand/about/#rand&#8221;

}

},

“description”: “This post is about giving you a new tool to add to your semantic SEO tool belt. My goal is to help you implement semantic markup and structured data with greater ease and enable you to create a more robust and complete web of linked data on your website (and beyond).”,

“sourceOrganization”: {

“@id”: “http://www.upbuild.io/#upbuildOrg&#8221;

},

“copyrightHolder”: {

“@id”: “#mozOrg”

},

“wordCount”: “3126”

}

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!