The spreadsheet consists of three worksheets: Dev Guide, Method & Field Reference, and Limits & Quotas. Basically, I wanted a quick way to get the information I needed and get on with my life. Granted, I could have just as easily Googled the method or have bookmarked the dev guide (which I still do), I still like having a simple spreadsheet of all the possible options in a single location.

For the Universal Analytics Dev Guide Cheat Sheet, you’ll find references for: Advanced Configuration, Page Tracking, Event Tracking, Ecommerce, Social Interactions, User Timings, Custom Dimensions & Metrics, and Domains & Cookies. I didn’t include Cross Domain Tracking as it’s very different from ga.js, and I recommend you read Googles documentation on Cross Domain Tracking.

The Universal Analytics Method & Field Reference Cheat Sheet contains information on Object Methods, Create Only Fields, Traffic Sources, System Info, Hit, Content Information, App Tracking, Event Tracking, Social Interactions, Timing, and Custom Dimensions/Metrics.

Lastly, the Universal Analytics Limits & Quotas Cheat Sheet contains both property specific and client library quotas and limits.

Again, I’m not creating anything new here. I’m just putting the information that is readily available in Google’s Universal Analytics documentation into a Universal Analytics Cheat Sheet for easy reference.

Note: This my first attempt at a Universal Analytics Cheat Sheet, so if you have any recommendations, or would like permission to organize/add content, please reach out to me.

The post Google Analytics – Universal Analytics Cheat Sheet appeared first on SwellPath.

For the first ever SwellPath Presents, we’re talking about something that I’m really excited about; Responsive Web Design and Mobile SEO. Before we get deep into any of that, let’s take a journey back in time to see what led up to making RWD so important and then go back to the future and learn all about what you need to know about mobile SEO in 2013.

How it all began

Back when I first started doing stuff online, web design was easy! You could just fire up Microsoft Frontpage, insert some tables, fill the cells with text and images, and embed a couple style rules. After you hit publish, you’d have a nice site that’d look pretty fantastic on your 800px by 600px screen. Who’d even heard of the term “multiscreen experience” or “mobile UX”?

At that time, a lot of us made calls on a brick. I feel sooo old saying this, but back in my day, cell phones were for phone calls and computers were for browsing the Internet. If we were lucky enough to have a phone that could surf the web, you probably got a nice text-based WAP (Wireless Application Protocol) site. Not too exciting.

Then scumbag Steve made everything a whole lot more complicated. We all started getting the iPhone. A good number of people already had web-enabled phones before that, but I consider the iPhone launch to be the catalyst took mobile browsing over the edge. Later on we got Android (the Android G1 was my first smartphone). Then these tablet things started to take off. Today, between the hundreds of thousands of devices we can choose from to browse the web, we have at least 30 major screen resolutions that websites need to look good on.

So today those WAP sites aren’t cutting it any more. And those “normal” desktop websites aren’t cutting it either.  That artifact that was built using tables and hardcoded style rules isn’t getting anyone excited…about anything. And don’t even get me started on Flash websites.

Sure, our mobile devices have cool features like tap-to-zoom, reader functions, and 3rd party readability apps, but isn’t it kind of embarrassing when we have to rely on someone else’s app or device to try to fix our broken mobile experience? I’m a big believer is “as few clicks as possible”. Why make users click extra buttons just so they can read your website? Couldn’t we just start things off on the right foot and just give users what they want without them having to ask for it?

And we’re only talking about content readability here. We haven’t even touched on ecommerce. 

But in any situation, we know what users want when they’re on mobile; a great mobile experience. When they’re on a mobile device, they want something that looks great on mobile. It’s a really simple idea, but executing on that idea is still a challenge that a lot of us face.

Even though it is a big challenge, we certainly can’t just ignore it, even though maybe we’ve pushed it to the bottom of our list for a few years. This “mobile thing” is a big freakin’ deal. I can’t imagine how this trend is news to anyone. Each following year, we’re seeing a huge increase in the volume of mobile traffic that hits our sites; a huge increase in the amount of time people spend browsing on mobile devices; a massive increase in how many ecommerce transactions occur outside of the desktop environment.

Put yourself in the shoes (or fingers) of a typical user. Or, just think about when you’re not actually doing stuff for work, but you’re looking for information online or trying to buy something. You expect to have a good mobile experience; users expect to have a good mobile experience; our potential customers expect to have a good mobile experience.

Yet most of the time, they don’t get it. Check this out! “79 percent of online shoppers who experience a dissatisfying visit are less likely to buy from the same site again while 27 percent are less likely to buy from the same site’s physical store” (source) Holy crap! Those kind of findings strike fear into my heart, because I still know people who have mobile site’s like this. ::gasps from the audience::

And it gets worse, 57% of users said they expect a mobile site to load nearly as fast, if not faster, than a desktop site (source)! Even though we might think expectations like that are unrealistic, it falls to us, as marketers and developers, to make sure users get the experience they expect on mobile. Otherwise, we may be left scrambling to explain why our mobile conversion rate is through the floor.

Indeed. What about SEO? Out of all inbound channels, organic search has the potential to be any site’s topic traffic driver. Search engine optimization is a huge opportunity to attract people who aren’t familiar with your site or make sure people who already know about you can get to your site easily through search. Without mobile SEO, only the folks who have your site bookmarked or click on an inbound link will know about your sweet mobile experience. SEO is what allows more people to get to your site through mobile search.

However, even if you know the basics of optimizing your site for search, mobile SEO can be a whole different animal. The search engines have known for years that the needs of someone on a mobile device are different than those of someone who’s searching from a high-powered desktop, with a high-definition monitor, and a strong Wi-Fi connection. Google and Bing both have dedicated mobile spiders that allow the engines to rank your site differently in mobile search than they do on desktop search. For better or for worse, we have to satisfy two different types of crawlers if we want to do modern SEO right. What that means is that we need to make sure our mobile experience looks good to users and to search engines. Wow. That sounds like a lot of work.

The reality is that it’s super freaking hard to provide that user-focused, search engine-friendly experience. I mean, building a world-class desktop website is enough of a challenge as it is. As a marketing team, you want a nice cohesive, branded experience. As developers, your biggest priorities are making sure the website is stable, that the different systems are integrated cleanly, that the site is cross-browser compatible. We’re not even talking about mobile yet!

So when we can finally give a moment’s consideration to mobile design and SEO, we’re overwhelmed by options. What’s even worse is that we’re overwhelmed by a abundance of professional options. Many of which actually contradict other expert opinions. So which one is right? How do we solve the problem of the mobile user experience?

Well, I think we can all think this through together and decide what’s going to work the best based off of what provides the best experience for users, for our website teams, and for search engines. So think about your mobile browsing over the last month. If you can, try to recall a few different experiences. Let’s go over three types: the good, the bad, and the totally awesome.

Let’s say I’m doing a search for “Game of Thrones Episode Recap” and I click on a result I like. The site takes a little while to load, but when it finally pulls up, I notice that I’ve been redirected to a mobile version of the site (m.hollywoodreporter.com). Since it’s a dedicated mobile site, the text is formatted to fill my phone’s screen, non-vital images are small, and the navigation is condensed. It’s pretty nice, even if the user-agent detection and redirections did add a bit of lag.

For another experience that I’d consider good/decent, I did a search for, appropriately enough, “mobile SEO” and click through on an SEOmoz blog post. The site loads up quickly and even though it’s definitely a desktop site, I can just hone in on the main content block, double tap, and it zooms into the content. On mobile safari, I can even hit Reader and bring up just the clean text (I do that a lot). With this one, I can get the information I need but I’m kind of indifferent to the whole experience. Sure, wasn’t really optimized for mobile, but I can deal with that. Not having a mobile experience at all is by far the most common way to deal with mobile users.

For this example, I clicked on a link that someone I follow on Twitter had posted. I click through his shortened link on Twitter and my browser starts to redirect to the article I’m trying to read (something on company culture). Halfway though the page load, I can see that another redirect kicks in and I get a loading screen for about 5 seconds (eternity on a mobile device). Studies say that 40% of customers will abandon a site if it takes longer than 3 seconds to load. Luckily, I have pretty low expectations when it comes to mobile site speed, so I hang around

I wait and wait and when I finally get a page I realize that it’s not even the article I was trying to read; it’s the site’s mobile homepage. The homepage has all their top stories, but I can’t find the article I was trying to get to. Some people could try in vain to navigate to what they were looking for or dig for a search functionality, but at this point, I’m done.

The site essentially has a rule that says to, no matter what page is requested, redirect all mobile traffic to the mobile homepage. If you do this, I hate you. It’s just like the ultimate in lazy BS. I’m sorry, but it’s true. There’s no reason to ever do this.

Let’s take this one step further: I click through on that link, and instead of getting to my content, or even the homepage, I end up with this hard-to-close popup that tells me I should download the companies app. I’m on a mobile device and by nature, my interactions and my attention span are already lightning quick. Not to mention, my connection isn’t the best. You want me to click install, wait for the app store to open, download your app, and then figure out how I’m supposed to find the content I was originally looking for? Fat chance. Good luck with your mobile bounce rate. I kind wish these companies would check that once in a while.

Thank you to Will Hattman for suggesting this wonderful XKCD comic that sums up the experience perfectly.

For this example, I searched Google for “Portland Nightlife”. The site loads in 2 seconds and without any redirection or “loading” screen, the text wraps to width of my phone. The content is the highlight, with an unobtrusive icon for an expandable navigation. There aren’t any social icons and the images are all small and don’t slow down the page’s load time. I decide bookmark that post for latter and I realize it’s just a regular URL, the same thing I’d see on the desktop site. How cool!

Another notable thing here is that the page showed up well (#1) in Google’s mobile search results. Was it coincidence that it was good content and a good experience? I’ll let you be the judge of that (spoiler alert: it’s not a coincidence).

Overall, once the page loaded (and loaded quickly) it looked great. All the unnecessary elements were gone and the content filled and wrapped to my phone’s screen. Later when I open that same link on my tablet, it has some extra stuff I can tap on that the mobile site didn’t have, but it still looks fantastic. In a week, I can open that link again from my laptop and it looks amazing there as a full-featured site. See where I’m going with this? One single page that looks great on every device I want to use to check it out with.

• The mobile-specific site and the desktop site gave me what I’d call a good experience. Maybe it was just decent, but I’ll upgrade it to a “pass”.
• The mobile site that redirected me to the homepage (or some other ridiculous thing) was a nightmare.
• The magic one-page-fits all gave me an awesome experience. So what the hell was that?

Was it worth the wait for me to finally get to the point? I hope so. Responsive Web Design (or #RWD) is an approach to web design where we architect a single site to provide an optimal viewing experience on any device. We have one domain (www.swellpath.com) and one code base, but all the rules that determine the visual presentation (layout, font size, imagery, and more) are responsive. The style rules respond to the width of whatever browser is being used to view the site.

We can figure out what the width is with this incredible feature of CSS3 called media queries. So on any modern website, most of your styling is specified in an external Cascading Style Sheet. CSS3 media queries allow you to detect the browser size of the device that’s currently accessing the site and the fire up the appropriate section of your stylesheet. And this is all done on the client side so that each user’s experience is tailored specifically to how they’re browsing your site.

That’s amazing! We’ll get into the specifics in a bit, but RWD basically allows us to provide an awesome mobile experience on any device. We’re only limited by our creativity and our ability anticipate browsing conditions.

Ethan Marcotte first coined the term “responsive web design” in 2010. His original piece on A List Apart is a great intro to responsive and certainly worth reading. He also wrote a book, by the same name. When Ethan first called for responsive, he predicted that mobile browsing would outpace desktop web access in three to five years. That’s very interesting since in about two weeks, it’ll be three years since he made that prediction. In arguing for responsive web design, he noted that client requests like, “build me a mobile website”, let us, as designers and developers, compartmentalize and avoid the problem of dealing with a multi-screen reality in an elegant way.

Now one methodology that predated Responsive was this “mobile first” approach with “progressive enhancement”. “Mobile first” centers on building a basic, yet functional mobile experience, and then progressively enhancing that basic foundation; adding in other elements and styling for desktop display.

Now we have Responsive web design that allows us to have a happy medium; the best of both worlds. We have a singular code base and we can style it completely differently for mobile, tablet, desktop, high-def television, or anything else.

Let’s take a look at what responsive looks like. First, we’ll start with the most basic of basic examples. Consider this demo page I put together at mikearnesen.com/rwd/. Looks like a pretty standard, stripped down site. We have a navigation bar, a few headings, and a little bit of text, with each element surrounded by a black border.

Let’s pull up the code so you can see the singular code base; the stable foundation that responsive sites are built off of. Take a look at the body tag first. There’s our H1 heading, the h2 heading, a few simple paragraphs of text. I’m personally a fan of putting your content at the top of your source code with the navigation on top, so the <nav> shows up at the bottom.

If we look at the <head> now, it’s all pretty standard. The important thing to pay attention to is the stylesheet link. That external file handles all the styling for this page. Before we hop into it and look at how the mechanics of responsive work, let’s go back to the user-facing side.

We start of in full screen; a standard desktop display. Since we have plenty of room, the navigation is at the top and our content spans most of the screen.

Then if we resize now let’s resize the window to simulate the width of a small desktop monitor. When we hit this “break point”, a new style rules kick in! The border around out content turns blue! Completely unimpressive, I know, but it illustrates the breakpoint clearly enough.

Let’s take it to standard tablet width. We resize until the breaking point and then BAM! Not only do we get a new border color but the nav also drops down to below the content. This is a very simplistic handling, but we know users on an tablets (and other smaller mobile devices) are primarily concerned with getting to the content, so we make that the highlight. We also see that the font got a bit bigger.

Let’s take it to the final, narrowest width for iPhones and we see that the nav turns square, the headings shrink to fit the smaller width, and the paragraph font size gets bigger so it’s easier to read.

So what exactly made all of that possible? Let’s pull up the code again and open up that stylesheet we talked about. Check it out; after some universal style rules that apply to all screen sizes, we have this “very small screens” comment. That @media on the next like is what makes the magic happen.

The “@media only screen” is a CSS3 media query and allows your site to check what the browser’s current screen size is. You can specify a max and/or a minimum and then everything within that section gets fired off only when those size conditions are met. So in this example, we have a CSS3 media query that specifies what rules go with browsers under 400px in width. The next covers everything from 401px to 800px, the next covers 801px to 1000px. You can break it down into any number of chunks. If you want to get super crazy, you can even specify “oretiation : portrait” or “orientation : landscape”. The standard best practice today is to have at least three “breakpoints”, that’s the point at which Responsive kicks in to reformat things. You want one standard style for your desktop site, one breakpoint to respond to a smaller window, another breakpoint to respond to a tablet, and a third breakpoint to respond to mobile.

Now let’s check out another example that’s not just a demo. Screaming Frog makes an awesome SEO spider tool, which we love at SwellPath, and they also have a beautifully responsive site. Let’s see it in action -> Screaming Frog’s awesome website.

We don’t have time to get into this, but you should be aware that there’s also a step up from RWD known as RESS. RESS stands for Responsive web-design with server-side components. I’m not sure if anyone has a proper explanation for why that got condensed into RESS? RE-sponsive web design with Server Side components? Anyhow, what this involves is using responsive CSS in conjunction with server side scripting (think PHP or ASP) to detect the device that’s requesting a page, then deliver a customized code foundation, which then gets responsive applied to it. It’s basically Inception.

The beauty of responsive is that users don’t even have to think about anything we just went over. All they know is that the site looked awesome on every device they’ve ever viewed it on.

All in all, responsive web design gives users the great mobile experience that they expect. It also makes them more likely to stay on your site; to read your content; to convert. Responsive also allows your site to be super flexible, since you only have one code base to deal with. When a new device comes out, you just need to determine if looks good with your current set up or, if it doesn’t, just add another breakpoint to cover it.

However, what interests me more than any of that, is how responsive performs in terms of SEO. As it turns out, it performs incredibly well. In order to illustrate why responsive is so good for SEO performance, let me break down some of the issues we’ve seen in the past with non-responsive sites.

Let’s consider a brand that has a desktop site and a mobile site, like m.brand.com. That mobile site provides a decent experience for most users but the SEO cost is potentially pretty high. Unless you have your SEO completely dialed, you’re essentially giving search engines two copies of the same site to look at. We know how search engines feel about duplicate content and without proper SEO handling, we’re leaving it up to the engines to figure out the association between these two sites and figure out which one makes sense to return in desktop search and which one makes sense to return in mobile search. That usually doesn’t work out so well. In many cases, I’ll see both versions of the site show up in desktop search. So great, you’re competing with yourself.

Another pitfall is that there’s a potential for dilution of link equity. If people are linking to and sharing URLs from your desktop and your mobile site, that means the SEO authority you’re building is being split up rather than being consolidated in one place.

Another one that we see all to often is faulty redirects. Mobile sites usually rely on detecting the user-agent of a device and then redirecting that visitor to the mobile site, but it only works if the device is recognized. In some cases, we see that Googlebot mobile doesn’t get redirected to the mobile site properly, so Google still thinks you just have a desktop site that isn’t usable on mobile devices. Another downside of relying on redirections is that each one adds additional load time and site speed, which is an increasingly important ranking factor.

If you’re stuck with this configuration though, you can still make the best of it. First, you’ll want to make sure that both Googlebot and Googlebot Mobile can access both versions of the site. As a general rule of thumb, you rarely want to tell Google it can’t access content that your users can. Search engines definitely don’t like that.

After you make sure that both sites are accessible, you need to specify the relationship between those two sites, since they’re basically just duplicates of each other. This is absolutely necessary and will save you a lot of SEO headaches down the road. The way we specify the relationship is through rel=”alternate” and rel=”canonical” tags. Whenever Googlebot crawls the desktop site, we want it to know that there’s also a mobile equivalent of whatever pages it’s on. Rel=”alternate” lets us tell Googlebot that the page it’s crawling has an alternate mobile version. The most important thing to understand here is that every page needs to link to its actual equivalent; you can’t just point everything to the mobile homepage.

The rel=”alternate” tag looks like this.

<link rel=”alternate” media=”only screen and (max-width: 640px)” href=”http://m.example.com/page-1″ >

Take a look at that media attribute. Pretty similar to our CSS3 media query, eh?

Now on the mobile side, we want to have a “canonical” tag that points back to the desktop equivalent. Again, this always needs to point to the actual equivalent, not just the desktop homepage. The tag looks like this:

<link rel=”canonical” href=”http://www.example.com/page-1″ >

Broadly speaking, the canonical tag is used to tell Google about pages that are very similar to each other or exact duplicates. That’s pretty much what we’re doing here, but the rel=”alternate” tag gives Google the signal that we have a mobile-to-desktop relationship.

Now I feel like inserting these tags is pretty easy to do in PHP, but if you don’t have the ability to make code changes, you can also add these notations in the desktop site’s XML sitemap. It looks pretty much the same, except you’re adding these tags in bulk instead of putting them in the source code. However, even with this handling, you still have to add the canonical tags into the source code of the mobile site. It sucks, but you can’t get around it. All in all, making a mobile specific site SEO-friendly is kind of a pain.

Responsive web design is a huge step up from having two sites for mobile and desktop.

• Now duplicate content is a non-issue.
• Any links or social shares automatically pointing to the same place regardless of whether someone gave you that link via desktop or mobile; it’s the same site, so no dilution of link equity.
• Page load time is still quick, since we don’t have to rely on redirects.
• Better yet, we don’t have to worry about our redirects not working or having Googlebot mobile end up going to the wrong site.
• Finally, you never have to worry about adding mobile SEO tags into your source code or building out notations in your XML sitemap.

But perhaps my favorite part about Responsive Web Design for SEO is this. It’s what the world’s top search engines are recommending. Now I’m not saying that everything that Google or Bing says is absolute law, but in the vast majority of cases, it really pays off to follow their guidelines.

Search engines have always had pretty clear goals. I don’t think it’s a surprise to anyone that that goal isn’t making sure SEOs have an easy job. Their goal is to provide search results that give searchers a great experience. That way, people keep using their engines and click on their ad placements. Yeah, Google and Bing are businesses. They just happen to strive to achieve their business goals by delighting their users. It’s a pretty brilliant and all-to-often forgotten philosophy.

Anyhow, both Google and Bing have publicly recommended that you use Responsive Web Design if you want to do well in mobile search. And they aren’t talking about this, but I’m seeing tests like this more and more. These were around of a little bit, special notations in mobile search for sites that were responsive.

At SMX West this year, both Matt Cutts of Google and Duane Forrester of Bing agreed that in the next few years, both search engines feel that there will be little incentive for them to return non-responsive websites.

Overall, Responsive Web Design is far superior for SEO than any other mobile experience delivery option. It consolidates link equity, eliminates technical SEO issues, makes the site equally accessible to Googlebot, Googlebot Mobile, and any other variation of Googlebot that may launch in the future, it keeps your site loading quickly, and gives Google the good user experience that they’re going out of their way to ensure mobile searchers get. I could realistically see Google using the responsiveness of a site as a ranking factor in-and-of-itself in the future. The time to go responsive is right now.

Still, no matter how excited we get about RWD, there can be big obstacles to going responsive. For one, it’s a big development cost to re-architect a site’s code base so that it can be responsive. In a lot of cases, it’s going to be easier to just launch a new responsive site than try to fix the existing desktop one. That’s change is going to be hard sell to management or your C-level clients. It probably won’t win you any friends on the dev team either.

I tried to identify the other major objections I hear to responsive, so here are few realities of the responsive conversation.  The first thing that I hear is that, in responsive design, code that isn’t used in your mobile layout still gets downloaded no matter what, because you still need it for desktop. The CSS3 media query doesn’t affect which sections of code actually get downloaded; it just tells the browser how to display that code. So many developers will argue that this is a major flaw. That’s a point we have to concede. It’s a reality of responsive design, unless you’re using RESS to change the code base that gets delivered on a device-by-device basis.

Second, I commonly hear that a downside of responsive is that it relies on resizing images for mobile layouts. Of course, any image that is embedded in a blog post or a news story needs to be of sufficient resolution to look good on desktop; responsive then needs to scale it down. That’s definitely a reality of responsive, but it’s also a reality to a mobile specific website (unless your CMS creates a low-res copy of every uploaded image to use on the mobile site). Overall, I think it’s a valid concern that I can’t argue with.

Third, I’ll often hear that a lot of mobile devices don’t recognize CSS3. I’m not going to say that they’re wrong, because there are plenty of devices out there that don’t recognize CSS3, specifically media queries. However, to me, that’s like saying you should dumb down your site to make sure that it always works on IE6 and IE7, since a lot of people are still using it. I think the more important question to ask is “how much of our site traffic comes from devices that honor CSS3 media queries?” I’ll stake my reputation on it being the vast majority of your site traffic.

Personally, I’d counter all of these objections with pointing out the long term cost of supporting multiple platforms and the business consequences of putting your company at risk of having customers receive a bad experience when they don’t get to the correct site and the risk of having terrible mobile SEO and losing out on free site traffic every week.

If you want to make the case for responsive with some data, take a look in Google Analytics. There’s a default “advanced segment” that lets you see mobile traffic only. Fire that up and check out your reports. How’s your bounce rate for the mobile visitors? What about your pages per visit? How about goals completions and e commerce transactions? Are they comparable to your desktop users? While your desktop site will typically have more engagement, you shouldn’t be seeing 95% bounce rate from your mobile site. That’s bad. Real bad.

Then take a look at the percentage of organic traffic out of the site total that’s coming to your site. Is the percentage of mobile organic on your mobile site comparable? If not, that may be a big issue that indicates some big problems in mobile search. Take those reports to your boss and let the data tell the story.

I believe that responsive design is the future of search marketing. I’m looking forward to the day when mobile search volume becomes equal to or even overtakes what we now think of as traditional, desktop search. Maybe that’ll force the “laggards” to move on this whole “mobile experience” thing.

Yet this isn’t just about the future; responsive design is also the present of search. I see more experiments in Google’s SERP presentation on mobile than I do on desktop these days. They’re putting a huge effort behind optimizing the mobile search experience and so is Bing. Lucky for us, we have the advantage of knowing what they think is best for users. It’s responsive. When we’re looking to improve our mobile SEO, providing what the search engines ask you to provide is a pretty safe bet.

Responsive design makes the web a better place. It makes the web faster and cleaner. It makes the web more accessible, readable, and digestible. Responsive design delights customers and that’s the ultimate for any marketer.

And responsive brings us one step closer to the future. Why? Because it’s exactly that: responsive. Building our sites on a clean and logical foundation, and allowing it’s presentation to respond to browsing conditions is incredibly future facing. How long do you figure we have until we need to optimize for the Google Glass user experience and Google Glass search. How about in-car dashboard browsing once we have self-navigating cars? How about transparent screen, projected image, Tony Stark madness? Responsive web design allows us to respond to the evolution of the web, remain agile, adapt to new technologies.

Yes. Converting your site to responsive is an investment. It’s hard work, but scalable tactics and strategies in marketing tend to require hard work. Stop looking for the quick fix; the plugin, the mobile-specific website; the phone app Band-Aid for a broken mobile experience. We’ve had to suffer bad mobile websites for long enough. They don’t give us the experience we want as users; they don’t give us the results we want as webmasters and marketers.

It’s time to step up our game, go responsive. Through responsive, we can meet the challenge of creating an awesome mobile experience that gives customers what they want. And you know what happens then? We’re suddenly giving search engines the site that they want to return at the top of their search results. The title of this presentation is “Responsive Web Design, Mobile SEO, and the Future of Search Marketing”. Well, I think that responsive web design is mobile SEO and the future of search marketing.

If you missed the presentation and want to relive the magic, check out the entire slide deck below!

The post Responsive Web Design, Mobile SEO, & the Future of Search Marketing appeared first on SwellPath.

The post SwellPath Presents: Responsive Design, Mobile SEO, and the Future of Search Marketing appeared first on SwellPath.

The Challenge

When Norm Thompson came to us looking for help optimizing the site content for three of their brand’s websites, NormThompson.com, Solutions.com, and Sahalie.com, we turned to a customer-centric, research-backed approach to developing and implementing a keyword strategy. Right off the bat, one of the major challenges of this SEO project was bringing all three sites up to speed with current SEO best practices and optimizing their content using insights into their customers, all before the busy 2012 holiday shopping season.

The Solution

SwellPath used available materials and additional customer research to inform strategy and program development, including accepted SEO best practices, current and future site structure and design, and stakeholder input. Prioritization was given to developing content for product categories that would have the largest impact during the 2012 holiday season.

Using the research gathered in the initial phases of the project, the SwellPath SEO team developed a keyword strategy for all of the main categories and subcategories. In addition, the team crafted 50 to 60 key-word optimized custom meta descriptions for each site and handed them off to Norm Thompson for implementation.

You can read the full story in our SEO Case Study online, or download the case study to print or share.

Do you need help optimizing your website? Contact us to see how a research-backed keyword strategy can help you optimize your content.

The post New SEO Case Study: Turning Customer Insights into Keyword Strategy appeared first on SwellPath.

A Timeline of My Personal Relationship with Emoticons

• 1994 or so: I see this image :) for the first time—probably in an AOL chat room—and understand it pretty much immediately. I find it clever and economical, and as someone who always carried a fondness for the traditional smiley face seen on buttons and stickers, finding opportunities to integrate this simple, functional ASCII version into my online communication proves easy.
• 1995: My vocabulary of these glyphs expands to include :( ;) :/ :D and more, I learn that their proper name as a group is “emoticons,” and my deployment of emoticons in email and IMs—a deployment forever earnest and unencumbered by self-examination—rapidly reaches a fever pitch.
• 1996: A gender gap emerges in emoticon use among my friends, i.e. the female contingent starts laying the smileys on heavy, leaving fifteen-year-old me with no choice but to dismiss emoticons as hopelessly “for girls” and run the other direction.
• ca. 1997–2007: I still avoid emoticons pretty diligently, though now for a more high-flown reason: because they’re “not serious” and therefore would undermine the deadly serious air I’m working so hard to cultivate by way of blog posts about the sorry state of the mid-decade Lakers and disappointing cookware. Throughout this span, my “internet text”—however casual the context—is pretty much indistinguishable from the formal text that I write for classes, clients, and cover letters, i.e. it’s all equally staid and flat.
• 2008-ish: Something funny happens to the way I use exclamation points in emails, web comments, and these “text messages” that I find myself writing more and more in lieu of talking to people on the phone: they (exclamation points) start showing up at the end of nearly every sentence that carries any risk at all of being interpreted as sarcastic. Sentences that I would never have considered deserving of the enthusiasm conveyed by an exclamation point if written in a formal letter or essay—and that never would have inspired me to raise my voice if I spoke them aloud—suddenly qualify for the exclamation point owing to this risk. Let me show you what I mean.
  • Nice shirt, dude.
  • Nice shirt, dude!

  Which of those two sentences do you trust more?

SIDEBAR: Sarcasm in Writing

Between our emails, text messages, and social media missives, we are now carrying out a huge share of our ordinary daily personal communication in writing, and this is the first time in all of human history that this has ever been the case. For bazillions of years, the only kind of personal communication that our species knew was the face-to-face kind. The ironclad condition that people had to be physically together in order to communicate was the condition in which our species evolved, and our language with it. It should therefore come as no surprise that we came to rely on the nonverbal dimensions of communication—body language, facial expression, tone of voice—as crucial ingredients of every exchange, at least as important as the words themselves. After all, long before there were words, our ancestors had established, out of pure necessity, a elaborate nonverbal vocabulary (if you and your Homo erectus buddies were hanging out around the fire one night and one of them suddenly took on a look of terror and started jumping up and down and screaming, you’d probably think to turn your heads to see what he was seeing, and fast). Words came later, and in the historical perspective look more like a fine tuning of communication than like the breakthrough itself. For a contemporary and readily accessible analog to our pre-linguistic situation, you need only study the rest of the animal kingdom (though of course, in many cases, their means of communication are more complex than they appear).

Now, in writing, we necessarily miss out on body language and facial expression. We have to be willing to let go of those dimensions of communication if we want to communicate in writing at all, and we did, long ago. As to the third crucial nonverbal element, tone: it’s not as if there’s no way of conveying tone in a written statement, provided that the statement is meant sincerely. Read a sentence in an email from your mom—a sentence that you can safely assume is sincere—and you can probably imagine the tone of voice she would have spoken it in. However, the development of sarcasm—a phenomenon wherein the actual meaning of a statement is the opposite of its literal meaning—confounds this idea terribly, as, in the simplest of scenarios, a sincere statement and its sarcastic inverse will appear identical on paper, the difference hinging completely on the tone of the spoken delivery. You can imagine both a sincere and a sarcastic delivery for “nice shirt, dude” right this second with no guidance from me, simply because you’re a product of a culture that understands this stuff. You’d have no trouble sorting out which was which. Since sarcasm is as old as the hills and our culture seems to become more saturated with it as time goes by (proving this gets incredibly arduous, but it’s not like you don’t know what I’m talking about), it now becomes clear what sort of trouble we’re in: our use of sarcasm in communication and our use of writing in communication are increasing simultaneously, and we have no way of managing the former by way of the latter. We can neither purposefully imbue a written statement with sarcasm in a foolproof way, nor, more alarmingly, can we hedge against the potential risk of a sincerely intended statement being interpreted sarcastically. Since sarcasm is usually intended to sting (the very word comes from the Greek sarkasmos which means “to tear flesh, bite the lip in rage, sneer”), there is a pronounced danger with every written message you send of a warm intention being warped by the medium’s limitations into something quite the opposite of warm in the mind of the reader.

Here’s where our friend the exclamation point rushes to the rescue (for a while, anyway)! Sarcasm is usually dry and deadpan, and an exclamation point indicates enthusiasm! An unambiguous mark of enthusiasm will inoculate any sentence preceding it against sarcastic interpretation! So we’re golden!

Or not. My timeline continues.

• 2009-ish: Use of the exclamation point for the express purpose of guaranteeing sincerity becomes a cultural norm and a standard feature of business emails and customer-directed form emails. Accordingly, I start seeing way more exclamation points per day than ever before, and I start tiring of it, for three reasons,
  1. simple enthusiasm overload;
  2. mounting frustration with the fact that enthusiasm is the only thing it can convey—it’s got no range—and
  3. the growing realization that enthusiasm and sincerity are not actually the same thing.

  Speaking to my third point, imagine you texted a friend to tell her you were looking to get rid of something semi-trivial, something nice but not all that nice (a duplicate record, some old magazines), and you were wondering whether she might want it, and she texted back:

  Gee, thanks!

  Would the exclamation point in that sentence make you feel confident that she was being sincere? Or would you grit your teeth at that word “gee,” because it’s way too wholesome to carry any possibility of ever being meant sincerely? In short: if it wasn’t clear to you already, my above statement about how the exclamation point can inoculate any statement preceding it against sarcastic interpretation was full of holes. It’s just not all that simple after all.

• 2010-ish: Salvation arrives in the unlikeliest package: :)

The Emoticon Has Unique Value

At some point a couple of years ago, I found myself wanting to leave a comment on a friend’s Facebook status. The status concerned some small tragedy and I wanted to offer words of small encouragement. The smallness of it all left me facing two problems that seemed difficult to reconcile: 1. though I don’t remember what precise words I’d settled on, I knew that I was happy with them, but that they did leave a door open to the possibility of being read as sarcasm, 2. an exclamation point in this serious a setting would have been vulgar, and, quite contrary to the underlying spirit of the mark’s overuse in preceding years, would have actually risked cheapening my message. As I sat there reading over the message and pondering how to end it, I found myself smiling, both at the thought of how much I cared for my friend, and at my confidence that this was little more than a bump in the road and she would surely be just fine in time. Then I wished she could see my smile, because she might find it uplifting and smile in return. By that point, the solution was practically screaming at me.

I learned that day that the emoticon has unique value, and since then, my emoticon use has been profligate, giving 1995-me a run for his allowance money. In our collective quest (or at least my own) for a tool that could adequately convey tone in writing, I found a tool that goes a step further and conveys a more precious nonverbal communication element, and one whose absence from writing we made our peace with long ago: the facial expression. If you can stop seeing the smiley as the only emoticon (though it’s often still the most useful one), and see past the smiley’s traditional relegation to the province of kitsch, you’ll find the emoticon is something we can all use to inject real feeling and clarity into our daily torrent of written messages. Rather than the smiley being a weapon within a campaign to bulldoze over all our real emotions with a sugary, prepackaged simulation of the kind of happiness that most of us only enjoy for a few minutes here and there in our entire lives, it can be a useful vocabulary of simulations of our real emotions, to indicate what our real faces would look like if only we were right there with the message’s recipient to have the conversation in person. The key is to use them honestly. This may seem obvious, but I don’t think it is: the smiley face has been bogged down in trappings of kitsch for way too long to register immediately as a simulation of a real human smile. But it can be. It can represent any emotion you’re feeling, as long as you’re honestly feeling it. Want a sincerity indicator that’s actually unambiguous and infallible, one that will adjust to suit whatever mood you’re sincerely in at the moment while still allowing you to be writerly with your punctuation? Emoticons are the answer. Observe:

• Let me know when you get in. :)
• That sucks, man. :(
• I just get more confused every time I read it. :/

And here’s a spectacular bonus: what if you actually wanted to convey sarcasm in your writing? Emoticons FTW:

• No thanks, I don’t really like having an awesome time. :)
• Your day just keeps getting better, doesn’t it? :(
• Quantum physics totally makes sense. :/

So, what do you think? Does this fly with you? Do you use emoticons, and if so, are they context-specific? If not—if you hate them—why? And, perhaps the biggest question of all: if you’re a part of the business world, are you seeing the emoticon following the same trajectory that the exclamation point traced a few years back? Are they starting to pop up in your correspondences with co-workers? What about superiors, or better yet, clients? Let me know in the comments! And I mean that enthusiastically! :)

The post In Defense of Emoticons appeared first on SwellPath.

Last month, I talked about how to configure the Google Analytics Core API Report Automation Script, and how to run a query using it. In this post, I’ll show you different tricks to clean up the Google Analytics data and how to automate your Google Analytics reports.

Report Automation Overview: Starting with the End

The way I think about automating is: how do I get the data I want, in the format I want, by simply pressing a button, or even easier yet, having a report emailed directly to me automatically on the day I need it? Well, in the words of Jack Dorsey, “It’s really complex to make something simple.” Automating isn’t necessarily “easy” to do, honestly, it can be very complex at times, but once it is setup, you gain a tremendous amount of time back from efforts.

I’ve only been working with Google Analytics for a few months, but one thing I learned early when putting together analytics strategies with our team is that, in complex situations, you start with the report and work backwards to figure out how you’re going to collect the data. For example, sometimes we start with just pencil and paper, and sketch out the report with the dimensions/metrics we want to find. From the sketch, we can begin to think strategically about how we need to implement Google Analytics tracking on the website to give us that data.

Really, automating your report is a very similar approach: start with the end result (usually a table or graph), and work backwards until you get to the data in the API. However, 99% of the time, the API will give us raw data, that is ugly and hard to digest. It’s not until that data is put into a table or graph, that we can begin to gain insights. I call this process of putting raw data into a readable form, “cleaning,” so I may refer to it as such.

The first half of this blog post will give you a practical example of how I “clean” data to be readable and usable. The second half of the post will show you how to automate and send report to your email on the first of every month. Let’s get started.

How to get Articles with largest increase (by volume): Month over month

Report: Client is looking for the top five articles with the greatest increase over the last month.

What queries we’ll need to run: Articles for previous month, articles for current month

Overview: So you’ll have noticed by now, that when you create a new Core API report, it creates a corresponding tab in the spreadsheet.

*Note: I use spreadsheet and tab interchangeably.

However, every time you run a query, the data in this tab gets overwritten, so we’ll want to create a new spreadsheet that we can reference our queried data. I usually call this spreadsheet something like Articles w/ Increases. In this new Articles w/ Increases spreadsheet, we’ll be bringing in data from both articles for previous month, and articles for current month.

The Setup:

Column 1 (ga:pageTitle): Referencing the pageTitle column in the articles for current month.
- Example: =’articles for current month’!A13

Column 2 (ga:pageview): References the, you guessed it, current month pageview. So this will correlate with article in column 1.
- Example: =’articles for current month’!B13 (not too hard)

Column 3 (ga:pageview): References the, you guessed it again, previous month pageviews. However, it’s not that easy. We will need to do a VLOOKUP to correctly match the pageTitle to the pageview.
- Example: =VLOOKUP(A3,’articles for previous month’!$A11:$E$260,2,false)

*To break this down even further, A3 references Awesome Article you’d like to find the pageview for; ’articles for previous month’!$A11:$E$260 references the table array you’d like the vlookup to look for your pageview (Note: you’ll see that I went up to row 260, if you have more than 260 articles, this number will be higher, possibly significantly higher); 2 references the pageview column in the array; and false tells the vlookup that we’re looking for an exact match, not an approximate.

Column 4 (difference): This is a simple subtraction of the current month pageview from the previous month pageviews.
- Example: =B3-C3

Alrighty, we’re getting our articles and we are able to see the differences between pageviews, month-over-month; however, we still need to sort (hint, hint) ascendingly by difference.

Google Spreadsheets SORT function: =SORT(Array, key_1, ascending_1,…)
- Example: =SORT(C13:F22,4,false)

This function creates a new table, sorted by column 4 in ascending (false) order. Conversely, to get Articles with largest decrease (by volume): Month over month, we can simply create a new sort function, reference the same array and key, and just sort by descending (true).
- Example: =SORT(C13:F22,4,true)

*Note: I say create a new sort function because this will create another table. If we’d like this automated, we don’t want to be changing the tables every time we have to run the report. The column on the left is the from our first table, and is not apart of the sort.

Granted this example may seem pretty simple on the Google Spreadsheets function-side, I really just wanted to get you thinking on how we can use queries and spreadsheets to start automating your data.

Using Triggers and Classes to Automate your Google Analytics Spreadsheet Delivery

Recently (like yesterday), I got the chance to play with some of the Google’s Script Services Classes to do some very helpful and slick automation.

I wouldn’t call myself lazy, but I like being as efficient as possible. So I started to think, instead of logging into all of these reports and updating the dates and clicking run, why can’t the report just get sent to my email when it’s ready.

Here is what I needed it to do:

1. Update the dates in the report to do a month-over-month analysis.
2. Send me an email with a link to the completed report.
3. Setup a trigger to run on the first of every month

First Step: Update the dates

To do this, I used a few Google Spreadsheet functions: TODAY, EDATE and EOMONTH. Let’s look at these a little more closely:

TODAY: Today is seems pretty obvious, and it is. To use it, just type =TODAY(); and this will return 4/23/2013.

EDATE: The result is a date a number of Months away from the given Start_date. Only months are considered, days are not used for calculation. To use it (I’ll reference the cell that has the TODAY function i.e. A1), type =EDATE(A1, -1). This will return 3/23/2013. Pretty sweet for doing month-over-month reporting, eh?

EOMONTH: This is a beaut! This functions returns the last day of the month for the month entered. To use it (referencing TODAY again), type =EOMONTH(TODAY,-1). This will return 3/31/2013. Awesome! Super close to having our month-over-month comparison.

Note: I’ve provided both the dates and the formulas, so you can see how this is working. I’ve also manually set the TODAY() date to 5/1/2013 to better illustrate how this would run.

So, it’s the first of the month and we’d like our data to do our analysis. We can easily open up the spreadsheet on the first and click ‘Get Data’, and our tables would propagate with fresh data. Done. But I want to take it a step further, and have the report come to me.

Second Step: Send me an email with a link to the report
Alright, so you may need a little coding experience for the next part, but it’s completely doable for you beginners. Heck, I still consider myself to be a beginner.

I’ll start with the function:

So, I created a new function and put it at the bottom of our Google Analytics Report Automation (magic) script.

What the function is doing is getting the URL of the spreadsheet; getting the email of the owner of the spreadsheet; *Note: you could use getEditors, to send to all the folks who have access to edit the spreadsheet, and finally, using GmailApp to send us an email.

Now, we want to call the function. This call will go in the getData function, as we’d like to call it after we’ve gotten the data. That is it. Just remember to save.

Sweet, so once that is setup, we can actually go back into to the spreadsheet and go up to the Google Analytics toolbar menu item, and click “Get Data”.

Viola! An email in our inbox with a link to the report:

Third Step: Setup a trigger to run on the first of every month
Hang in there, we’re almost ready to set it and forget it, but first we need to setup a trigger that will run our getData function on the first of every month.

This is the easiest step by far. You’ll need to go into your Google Analytics Report Automation (magic) script and go to the “Resources” tab > “Current project’s triggers”.

Next, we’ll set up trigger. So click the ‘Add a new trigger’, and select the ‘getData’ function.

Because this is a trigger that we only need to run every month, we’re going to select the Time-driven trigger, and specify month and the day of the month, in our case the first of the month, or 1. Next, set the time interval you’d like the trigger to run between. I choose 6am to 7am, so it’s sitting in my inbox when I check my email in the morning.

Bam, we’re done! Yes, it was really that easy. However, if you’re not convinced, you can set up a report to run for tomorrow using the data I’ve provided. It’s so cool getting to work in the morning and seeing a link to a fully automated report.

Conclusion:

If you’ve read this far, then I hope you were able to take away something new about automating your reporting using Google Spreadsheets and the Google Analytics Report Automation (magic) script. I’m fascinated with automating. It provides efficiencies and valuable time-savings for marketing managers to digital strategists to developers. Happy automating!

The post Google Analytics Report Automation using Google Spreadsheets and Scripts appeared first on SwellPath.

So allow me to introduce you to Google+ Interactive Posts!

Interactive Posts, meet Marketers.

Marketers, meet Interactive posts.

Before I leave you two to get to know each other better, let me tell you a bit about Google+ Interactive Posts, their background, and why they’re so dang awesome.

What Google+ Interactive Posts Are All About

Interactive posts on plus allow you to enhance your existing sharing by embedding a clickable Call to Action in your post. They’re pretty easy to set up and I hope that after this tutorial, you’ll be able to get running with them right away.

Here’s Why Google+ Interactive Posts Rock My Socks

I’ve praised the visual markup options on Google+ for a long time (the ability to use bold and italics to compose a remarkable post), but the new interactive post is exponentially more impressive. If you haven’t seen an interactive post on Google+ yet, they look like this:

Yep. That’s a CTA embedded directly in a Google+ post! When you set up Google+ interactive posts, you can create a custom share button that allows you to share a page to Google+ and leverage a custom CTA that links to the same or different URL. Yeah, you can share a blog post about an event announcement and link off-site to eventbrite.com so people can sign up!

You can even deep link to a specific location within a mobile app, a la Twitter’s recent Twitter Card enhancement. Implementation gets a bit trickier for mobile apps, but what else is new?

About CTAs for Interactive Posts

When you configure an interactive post for Google+, you get to set the CTA. Right up front, you can only choose from a limited (yet extensive) list of Call to Action “labels”. Now, what could be seen as a drawback initially is, in my opinion, actually a huge benefit for scalability and reach. The reason that you can’t write your own CTA text is that Google wants to be able to translate that CTA into the native language of every Google+ user who views it. If you’re involved in international SEO (or any aspect of international digital marketing for that matter), this is a godsend. You also never have to worry about how that button renders because Google+ takes care of QAing it for you. As someone who did time at MySpace towards the end, I can tell you that the over-customization of social networks is seldom a good thing for user experience.

Getting back to the point, there are a ton of “label” options to chose from. There’s a full list over at Google, but here are few cool ones:

• ADD_TO_CART – Select this label when you want to link to a dynamic URL that adds the product you’re talking about to the user’s cart on your site.
• ADD_TO_CALENDAR – Use this if you’re talking about an event and you’re linking to a calendar invite file like a .ics.
• ANSWER – You can link out to Quora questions! Sweet!
• ATTACK or DEFEND – Google recommends using this for game apps, but I just want to use it for EVERYTHING! :-)
• BOOKMARK – Click to bookmark a webpage.
• COMMENT or DISCUSS – If you’re sharing a blog post, you can include a CTA that links directly to the comments section.
• COMPARE – Link to a page that compares to two different products.
• CONTRIBUTE or GIVE or HELP- Great for taking people to a donation form.
• DOWNLOAD – Perfect for whitepapers and such.
• INSTALL – If you want to direct mobile users to download your app.
• LEARN or LEARN_MORE or READ or READ_MORE – Pretty decent generic option for a blog post or tutorial or case study.
• PIN_IT – Google is, apparently, down with Pinterest in a big way. Pin it up!
• RATE – Direct users to rate a product, movie, experience.
• REGISTER or RSVP or SIGN_UP – Send user to a page where they can register for an event.
• SUBSCRIBE – Use Google+ to grow your email subscribers. Nice.

Select Use Cases

So what exactly can you DO with Google+’s new interactive posts? Let’s explore options using some examples.

Event/webinar Information and Signup

Scholarship announcement and application

Interview with a designer and buy now

SaaS Overview page and Get a Quote (Lead Capture)

Political Issue and Take Action

There’s a lot you can do with the new Interactive Posts and, at the risk of sounding cliché, you’re only limited by your imagination.

How To Use Google+ Interactive Posts

Itching to get this set up? While there aren’t many easy options for dynamic, site-wide implementation as of yet, I put together a pretty nifty tool that you can use to get the full benefit of this awesome new opportunity sooner rather than later. The biggest benefit of Interactive Posts is their customizability and I’d imagine most site-wide implementations would either need to be pretty rigid or 100% customized on a page-by-page basis. The solution I worked on involves using a central Interactive Posts Command Center that your team can use to create and push out Google+ Interactive Posts on the fly.

This Command Center is free to download and completely open source. Experiment with it and let me know what you think.

DOWNLOAD or check out the DEMO (note that you can’t change the values in the demo).

Step One

Download the Command Center and upload it to your website (or your client’s site if that’s who you’re using it for). I’d look into setting up some password protection on that directory since anyone who knows the URL can compose and push posts from it.

Step Two

Open command-center.php in a text editor and enter your Google+ API Client ID at the top of the file and then save it. To grab your API Client ID, or set one up if you don’t have one, head over to the Google APIs Console. Your client ID is just the number listed on the first line under “Client ID for Web Applications”.

Note that the “Product Name” gets displayed when you share Google+ Interactive Posts, so make sure it aligns with the name of your website.

Finally, make sure that the “JavaScript origins” is set to include the site you’ll be using your Interactive Posts Command Center from. If this doesn’t align (pay attention to http vs. https), you’ll get an error. (UPDATE) Note that when you create a new API Project, you need to set the JavaScript Origins. It’s not filled out by default and you’ll get an error if it’s not set.

(UPDATE) Step Two: Part II

You’ll also need to enable Google+ API as a “service” while you’re in the Google APIs Console. When you’re in the console, click on “Services” on the left-hand side menu, then scroll down to Google+ API and turn it on. It may take a few minutes to kick in.

Step Three

Fire it up in a web browser by going to www.yoursite.com/optional-directory/command-center.php or similar.

You have all the options to play with when you go to compose a post.

• Content URL: The primary page that you want to point to. This is the link you’d use for a standard Google+ post. The meta description and on-page images from this page are what get pulled in for the standard Google+ rich snippet.
• Prefill Text: This is the message that will be pre-composed when you hit “Share”. Not really 100% necessary since you’ll be managing this on your own, but you could embed the output into your own pages and leverage that prefill text.
• Call to Action Label: The CTA label that you pick from the list of Google’s available options.
• Call to Action URL: The page that the CTA directs visitors to. Can be a static or dynamic URL.
• Button Text: Optionally, change the text that shows up on the actual button.

Note that some variables aren’t user-facing, notably “data-cookiepolicy” and “data-clientid”, which you won’t need to change unless you’re customizing this. Also, I’ve disabled the fields for Mobile App deep linking, since this is a web-based tool and, if you’re setting up Interactive Posts for a mobile app, you probably know this stuff better than I do.

Once you understand the above, you can go ahead and start pushing out Interactive Posts from your new Command Center!

Step Four (Optional)

You can also hit the checkbox at the end of the page to grab the embed code for whatever Interactive Post you come up with. You can then follow the simple instructions to drop that into the HTML of your site wherever you want.

More Interaction, Higher Engagement, Better ROI

I think Google+ Interactive Posts are an amazing opportunity to take what you’re doing on Google+ to the next level. The new CTAs allow you to not only share your content to a growing audience, but also direct users on what to do next. However, don’t starting thinking putting a CTA in everything you share on Google+ is some magic formula that leads directly to higher user engagement; you still need to work hard at building an audience, establishing trust and authority, and giving your users a reason to engage. Once you do that, Google+ Interactive Posts dramatically streamline the process of connecting interested users to their end destination.

I’m sure we can expect plugins for easy WordPress integration soon enough, but you should now have everything you need to hit the ground running. As with all the tools that Google gives marketers (especially SEOs), use it for Good and not Evil. Remember, Google knows who you are (you just registered to get a Google API Client ID) so they can easily take away your privileges if you’re spamming Google+ non-stop with your affiliate links and not being a, you know, real company/person. But what else is new? #AmIRite?

Let me know in the comments if this worked out for you, how you’ve been using it, and whether or not you have any feedback on the Command Center tool.

Good luck and happy optimizing!

The post Get Up and Running with Google+ Interactive Posts appeared first on SwellPath.

Eco-Friendly Commuting

Transit Passes for Employees

Over half the office commutes to work on mass transit every day, and we’ve made that easier by subsidizing transit passes for our employees that need them. By taking the bus, light rail, or the streetcar to and from work everyday, we’re helping cut down on the number of cars on the road, not to mention the hassle of parking downtown.

Biking to Work

Portland is indisputably a bike-friendly city. In fact, Bicycling Magazine named Portland America’s Most Bike-Friendly City in 2012. SwellPath employees take advantage of dedicated bike lanes, bike boxes at intersections, and tons of bike corrals around the city. Portland has definitely made it easy to get around on two wheels. We even have our weekly Whiteboard Wednesday lunches delivered by bike messenger.

Green Kitchen

Non-Disposable Dishes

The SwellPath office is stocked with non-disposable dishes and silverware to cut down on waste. Providing reusable items for food and beverages means they’ll be around for years to come, and we’ll save money by not having to buy plastic dishes and silverware every month. We also keep dish towels in the kitchen to cut down on paper towel usage.

Recycling (Almost Everything)

We’ve got a pretty sweet recycling set up in the office, and while it may take a few extra seconds to figure out where everything goes, it’s worth it in the long run. We have bins set up for recycling paper, metals, glass, and plastics. Our awesome Operations Coordinator provides  great visual cheat sheets for us, which makes it easier to know where everything goes.

Compost

In addition to recycling we also have a composting bin in the kitchen. All of our food scraps and food-soiled paper go into the composter, in addition to the copious amounts of coffee grounds we go through each day.

Eco-Friendly Office Practices

Going Paperless

As a digital agency we basically live on the web, which means we’re not printing or using paper wastefully. Most of the time we’re sharing and editing documents online. Services like DropBox and Google Docs make it easy to go virtually paperless. Plus, we’re saving money by not having to refuel the office printer as often.

Adding Some Literal Green

We’re big fans of plants in the office. Every room at SwellPath houses some type of plant life. We’ve found they brighten up the office quite a bit and as an added benefit can provide a natural solution for cleaner indoor air. Check out this organization for more information on the benefits of adding plants to your office.

Conserving Energy

We try to be consistent about conserving energy in the office by turning lights off in rooms we’re not using and switching off our computers, wireless mice, and other electronics at night. These are quick actions that can go a long way to helping cut down on energy waste in the office.

Arm Yourself with Green Information

Education About Green Practices

When we started our new recycling and composting program, our Operations Coordinator who leads the green team at SwellPath gave us a presentation on the new practices and listed the information in our kitchen on the bulletin board. That education can extend to not just the workplace, but also to your practices at home as well.

Resources for Your City

If you’re in the city of Portland, this website has tons of great resources on it for making your office space or home green. Check with your local city government website to learn about recycling resources and how you can make your office more green.

Happy Earth Day!

The post How We Make the SwellPath Offices Green appeared first on SwellPath.

When Google launched Tag Manager back in October, we were excited to be able to offer our clients a free tag management solution that is incredibly easy to implement and maintain. Google Tag Manager offers a number of built-in benefits. In addition to being scalable and extensible, GTM integrates easily with Google Analytics, and is customizable to the needs of each business.

One of the first clients we worked with on tag management was Jive. Jive was using over ten different advertising and marketing automation scripts for measuring conversion including Google Analytics, display, remarketing, and retargeting networks, audience measurement scripts, and social sharing tools. SwellPath’s challenge was to transition all the disparate tracking tools into one system, Google Tag Manager.

You can read the full story in our Tag Management Case Study online, or download the case study to print or share.

Are you considering tag management? If you’re wondering whether or not a tag management system is something you need, call or email us today. Or you can download our Tag Management Checklist to see if you can benefit from Google Tag Manager.

The post New Tag Management Case Study Available appeared first on SwellPath.

What Are Enhanced Campaigns?

In February, Google announced the release of Enhanced Campaigns, their new approach to mobile search advertising. By upgrading from Legacy campaigns to Enhanced campaigns, advertisers are consolidating their device targeting to include desktops, tablets, and mobile devices. No more duplicating campaigns to track mobile usage separately, and (hopefully) no more leaving mobile out of the equation all together.

With this new system advertisers are being forced to give mobile search the same consideration as their desktop campaigns, no longer accepting that “mobile traffic just doesn’t convert.” Sure, there are still ways to exclude your mobile traffic (more on this to come), but Google has made this process much more labor intensive than unchecking a box within your settings, which in many advertisers case may be enough to make them reconsider.

When Will I Be Impacted By This?

In perhaps the most surprising move, this Google update is being rolled out slowly with considerable written notice and ample time for user feedback before fully taking the plunge. Not a common practice for anyone familiar with Google’s usual “act first, announce later” approach.

Released in February, Enhanced campaigns should now be an available upgrade for all those who wish to manually update their campaigns. In a recent announcement, Google stated that campaigns will begin automatically updating on July 22, 2013. But this is no time to procrastinate (says the guy writing this blog post at 2am). By letting Google’s system automatically update your campaigns for you, you are giving up control over your bids, and worse yet, putting it in the hands of the one who stands to profit. I’ve haggled at flea markets enough to know that if you’re looking for a bargain, you don’t put all your cash in the vendor’s hand and ask what he thinks is fair.

These next 3 months will be critical time to get up to speed on all things “Enhanced”, including key features, differences in bidding strategies, and how to navigate the new interface.

So What’s Different?

There are several new features to Enhanced Campaigns, some of which serve to simplify targeting and increase mobile adoption, and some of which are carrots to offer advertisers feeling like they are losing control over their sophisticated campaign structures.

Campaign level bid adjustments by device

Mobile devices will no longer be parsed into separate campaigns (as was the best practice up until now). Instead, a percentage bid adjustment will be made at the campaign level that applies to all keywords being queried on a mobile device.

If a keyword has a $3.00 bid and you want to reduce the bid to $1.50 on mobile devices, a -50% bid modifier would be placed for that campaign. As mentioned above, if you still wish to remove all mobile targeting, a -100% bid will do the trick.

Google has announced that in mid-May, bid adjustments by device will be available at the Ad Group level rather than just the Campaign level. This may have already been in the roadmap, or may be in response to feedback from early adopters. Proof that you should get on board now and voice your concerns.

Bid Adjustments by Location, Time-of-Day

For time and geographic location, you will be able to modify your bids between -100% and +300%. This is particularly important for any businesses with a brick and mortar presence. Retailers may want to increase bids within a specified radius around their stores, a pizza place could increase their mobile bid during dinner hours, or a brand operating a call center can schedule their mobile ads to only appear during business hours.

Ads Customized for Mobile

By default, the ads you create for your desktop targeting will now be served to mobile as well. To remedy this, you can create mobile specific ads which will override your standard ad when served on a mobile device.

This change will also apply to ad extensions, meaning you can designate which extensions (sitelinks, social extensions, call extensions, etc) will appear in mobile vs. desktop/tablet.

Calls Can Now be Counted as Conversions

If Google is to increase mobile adoption, they must also improve mobile tracking. One step in that direction comes in the form of calls being recorded as conversions. Now you will be able to import calls with specific attributes (such as calls over 60 seconds in length) as a conversion, helping to bridge the gap between perceived and actual mobile performance.

Ad Extension Scheduling and Additional Tracking

The first carrot comes in the form of additional targeting and reporting options for ad extensions (specifically sitelinks). You will now have the ability to schedule your ad extensions to appear by time of day, giving greater control over your messaging. A B2B organization with various resources might target whitepapers by day, but their video content in the evenings where users can consume data more easily on their mobile devices.

Sitelinks will now be available at the Ad Group level rather than Campaign level, and reporting will be based on each individual sitelink rather than the group. No longer are the days of aggregated numbers and guess work as to what is your strongest messaging.

Ad Group Level Bid Adjustments for Display Targeting

If we’re offering up carrots, we can’t neglect Display campaigns. With Enhanced Campaigns you will now be able to set bid adjustments based on any display target type, including placements, topics, remarketing lists, etc.

Why is This Happening to Me?

It’s true, change can be difficult to handle sometimes, especially when it is forcefully imposed upon you. Hopefully this post will arm you with the basic understanding of Enhanced Campaigns and how you can take advantage of the new features to comfortably and effectively navigate this changing landscape.

In part two of this series we will discuss the true intentions behind this change, how marketers have responded in this first 60 days since the announcement, and what these changes will ultimately mean for you and for digital marketing as a whole.

The post What Google’s Enhanced Campaigns Mean for You – Part 1 of 2 appeared first on SwellPath.