that we had to build into the platform. So we had to bring engineering in the room because


How to Operationalize Growth for Maximum Revenue [MozCon 2017] — Joanna Lord

we couldn't just build something hacky in the beginning and not have it built into the


back end. So we had to bring in the engineering stakeholders. And then we realized we needed


oops. Then we realized we needed to bring in the analysts, right? Because all this data


had to flow full funnel and I had to understand everything from beginning to end to then come


with a recommendation on how we were going to grow the company. And the real problem


there is that's four different teams with four different roadmaps and four different


stakeholders. And all of them feel responsible for the outcome of growth. And we'll talk


about all the dynamics that come from that and ways to organize around it, but this is


a fundamental shift that just wasn't there ten years ago.


The second biggest change is the organizational structure itself. I'm always shocked by this


because I'm lucky enough in fact we just heard from Matt and he mentioned Reforged, which


is a great community of growth leaders, and we get in a room often and I fly to San Francisco


to sit down with these people and you're like what is this room going to talk about? All


these people that are solving growth at their own independent companies. It's always organization.


Who sits where? Who works with what? Who owns what roadmap? It's always about how do you


organize? What's the title? What type of person do you hire in? And it's hard. This was one


of the first published team formats. LinkedIn came out with it many years ago about what


their growth team looked like. And look, it looks fundamentally different. It's not a


traditional map that we would expect a team to see. You've got SEO as a squad. It owns


SEO, CRO, public profile. You've got network growth as a squad. People you might know,


virality connections. You've got onboarding as its own squad with activation, early life


and intent discovery. And then you've kind of got comms, which is basically touch point


management with push and resurrection. Now these four squads are very different. They're


cross-disciplined. They've got product. They've got marketing. They've got CX or customer


experience. And the real challenge is LinkedIn publishes something like this and they agree


very fast. And our CEOs hand us this and are like, build the team. And I'm like, but I


don't even like work at LinkedIn. We're not even a marketplace. You know, like, and you're


like, okay, I need to organize differently, but I don't know how. And we can't find the


right roadmap. We try to look at our bag of tricks of how we've organized teams in the


past and it's not quite working. And that's a huge challenge that faces us. What we have


to end up doing is actually thinking about the functional skills. When you build these


independent squads and we'll talk more about it, you need to have someone who's creative


so understands customer experience. You need to have analysts represented, someone who


can think through how the data is going to be collected and leveraged. You need to have


someone who's technical in the room so they can tell you if it can be built and how long


it will take to scope that out. And then you need to have someone, and I like to call this


loosely intuition. This is a big mistake a lot of companies make. They have these people


at companies that have proprietary knowledge that know all the things that were tried,


all the things that weren't tried and all the gaps in the way they track in the systems.


And they put that person on a legacy product. They don't bring them into the new exciting


ideas or the new products or features because they know it so well. And the problem there


is that person has the best intuition in the room. That person has the proprietary knowledge


that can help solve some really big problems. So these new squads that you form as you organize


around growth have to have all of these stakeholders represented. And that's really hard to do.


The third biggest change that's happened around us is you need to know who to hire. I mean,


we're all incredibly lucky. Everyone in this room is in a discipline that is needed right


now. All of you get jobs every day I'm sure offered to you. We know a domain that is going


to grow and scale with the world ahead of us, and that is an exciting time. The problem


is all of the other companies are also hiring really great people. They're also hiring all


of us. And we're competing with the best and brightest minds because it's an exciting domain


for people to get into. We do need to hire different people. And Rand actually introduced


this to me a couple years ago. I've since used it many times, which is the idea of the


T‑shaped marketer. We all know that pretty well. Where in marketing you're really deep


in one domain but broad in most. I actually extend that to be a T‑shaped hire in general


and I make the really deep domain marketing and broaden the rest. So what you'll actually


see is the best people to put against growth initiatives or to organize around culturally


for growth tend to be someone who knows either product or marketing or analytics really deep,


but they tend to also understand product and engineering and CX and ops and finance and


pricing. And they have a much broader skill set. They have curiosity about them, and that


does a couple things. One, it builds a lot of empathy and you're going to need that because


all of these teams are going to have challenges when they roadmap and score. It also builds


a lot of interest on how you can grow together and how things can integrate. And that's when


really magical things happen, right? When we integrate all of our different platforms


and we get views and insights that our competitors don't have. And that takes a different type


of hire. It's someone who wants to step outside their domain. So all we have to really do,


right, like fundamentally, change how we organize, how we roadmap and plan and who we hire. That's


like not that hard. Oh, yeah, we also have to do this with beautiful marketing on a budget,


with limited resources, quickly, effectively, and better than anyone else in the world.


Feel free to just freak out. You all just read the asterisks. But it's so hard. I mean,


I'm still also trying to do the best SEO in the world, the best PPC. I'm trying to stand


up the best campaign for holiday. I'm trying to understand if I should refresh my brand


or not. I'm still trying to coordinate with CX on who owns social CX. I'm doing all of


that. And I'm trying to reorganize my team, find new hires that have a growth mindset


and systematically set up to scale faster than any company in my domain. That's why


it's so hard. The good news is it can be done. And even better, there are patterns. The fastest


growing companies in the world have similar patterns. And what's so great about today's


sharing economy of information is that they share it. They do retrospectives on what


and how they grew their company so fast. And they share it. And so we can actually look


back at these companies that we want to emulate. And you see that they invested similarly at


the beginning. They didn't invest similarly at the beginning. They organized similarly


at the beginning. They hired for certain types. They culturally created different systems.


And that's what I want to talk about today. That's where we're going to go. So I'm going


to throw a ton of tactics at you right now. Things that I've seen work, things that I've


personally experienced that didn't. Again, if we have questions at the end or if we have


time later tonight, we can dig in on it. First and foremost, the fastest growing companies


in the world invest in the views that matter. And they did it very early. Very early in


their company. It became a DNA fabric for them. This is the most useless graph in the


world. I hate this graph. And the crazy part about it is this is a growth graph. It's up


and to the right. We get them every Monday. Our team sent us these graphs. Don't worry,


guys. It's growing just like it did last week, week over week at 2.24%. This is the second


most useless graph in the world. It just compares channels. It just says don't worry. That channel


is still 2.5X more than that other channel. And it's kind of crazy to me that we're still


reporting on this. In fact, we heard a little bit about this yesterday during one of the


e mail presentations where Jordan kind of said it's not about the vanity metrics or


the things that are working, but are you turning your eyes to the metrics that aren't? Are


you turning your eyes to the metrics you're not even tracking right now that could fundamentally


help you understand the system better? And this is the real reason. It's not even so


much that the graphs don't help us identify what's not working or what we should be looking


into. It's the time that's wasted. And this is the theme of fast growing companies. If


every Monday your channel owners are reporting out on those useless graphs because that's


what you always do and you need to know if something's changed, they lose half a day.


Half a day every week is two days every month, which is 24 days a year, which is a month.


You just lost a month of someone you hired to run a channel to grow your company. And


your competitor, if they don't lose that month because they figure out a different way to


look at the data and a way to do it in just a better, more holistic way, which we'll talk


about in a second, that's a real problem. That's how you lose. That's how you lose your


arena. So what does that look like for real? Let's talk about it. First and foremost is


the full funnel view. And I can't stress this enough. In fact, somewhere in this room is


Matt Park, who is our director of growth operations on my team. His team is responsible for so


much of the success you're going to hear me talk about today. And what he's been able


to do is bring analysts, data scientists and integration specialists to the marketing team


and connect our systems. Every platform over here for acquisition is now tied to my engagement


metrics for my product. I know the LTV of my paid advertising creative. I know the referral


of the customers that come off a certain campaign and promotion. I need to know this. That's


where you identify the magic, the full funnel view. And that's hella hard to stand up and


maintain and do it in a way that everyone around you knows how to do it and where to


look for it. So you have to bring the front dashboard to all the data. Every marketer


needs to be able to see the full funnel. If they only know their channel or their silo,


they won't be able to see the magic. And these smart people need to be able to see it to


come with the great ideas. You need to have the cohort views. You need to revisit your


attribution. Many of us still work on last touch because it's really hard to redo attribution.


You have to work with your finance team. You have to redo your historical views. All your


reporting has to be recategorized. That's why it's hard. That's why the best companies


do it. And that's why they win. Six months of redoing your attribution model is six months


of redoing your attribution model. It's exactly what it is. Sign up for it. Do it with vigor.


Like it's so worth it, you know? You have to be able to understand things like network


effect and virality. We work with our product teams and they're actually working on network


effect, which is bringing someone in adds value to the product and they start to organize


around that in early life and onboarding where they capture information to make the product


more accessible and better. What they don't necessarily build for is virality or K factor.


And that's the idea that when someone comes in, they bring in more value than themselves.


So one equals one N. It's a referral. It could be a share. It could be some sort of moment


that's going to drive my acquisition funnel into a higher and more fast track momentum.


If you aren't working with your product team to think about that in the first couple moments


of your product platform, you're in trouble. Because the companies that do that do best.


And that builds a flywheel that I could never buy into. My cap could never be as low as


that moment. Right? You have to build into that. You need to understand your growth mix


and cannibalization. How do your tiers play against each other? We always say to ourselves,


especially in subscription business, but every model has it, upsell. Get them to use it more.


What if it's actually better if someone's low usage to drive them down and redistribute


them in a different monetized way? Take that money, reinvest it in your margin and grow


in a different way. You need to understand the full system. You can't just assume best


practice of moving them up or getting more money from them. You might actually need to


put them where they need to be and find a different way to help that serve your business.


So all of these things are really hard to do, but these are the views that matter. The


tenure journeys you do, we often think about early life, midlife, late stage, LTV. Maybe


something like an RFM analysis is important with recency, frequency and monetary. Maybe


you think about what their MPS is and if you move them from a six to a seven, what that


means for their ambassadorship and their referrals and their social networks. Those are the views


that we have to like challenge our teams to systematically standardize and then report


on in our frontend dashboards. This shouldn't be impossible to get to. This should be Tuesday


morning over coffee reviews. Because we're smart people and if we see this, our synapses


are going to fire in great places. The second one, and this is one I learned the hard way,


because I was the opposite for like seven years. Growth as a decentralized responsibility.


Very provocative statement. Half of people in the room are probably like, no, growth


is a centralized responsibility. But it's not true. In my opinion, how you organize


is either going to fuel or kill growth. There's no way around it. Oftentimes I sit down with


someone over coffee and they talk about how am I going to set up for growth. And I'm like,


how are you organized? Who owns growth? How does it look like? And it tends to be sitting


in this one team. They want to hire a VP of growth or chief growth officer and that person


is going to have tentacles in all these other teams. That's very hard to organize around


long term. And instead then you kind of start to look like this. It's just the very standard


right. Every team has a roadmap, has a leader, has their own marching orders, their own OKRs.


And the problem with this is it might wrap around to be the same two or three big levers


for the company, but probably not. The chances of one of these squads fighting with the others


and actually doing OKRs that wash each other out is probably what's going to happen. Instead,


you need to organize like this. Growth is a decentralized responsibility. Knowing the


two or three levers that matter most for your business, and when I say levers, I mean what


metrics that you move will give you the most margin to play with and redistribute into


your business to fuel growth. I'm not sure if you guys have read the book The One Thing,


but I love it. It's a great book. It basically asks the question, what's the one thing you


do today that will make everything else easier? That's the metric that you decentralize, bring


your squads from cross disciplines around and work toward. So we did this actually in


January of this year. We wanted to make runs against our CAC, our churn and our burn at


Class Pass. We wanted to have a transformational year against these three metrics. So we blew


up every team's roadmap. That was terrifying, by the way. A lot of emotions to work through,


but it felt like the right thing to do. We brought the whole company together and we're


like, we are not letting these three metrics incrementally approve for the rest of the


year. We're going to fundamentally change them in the next 90 days. So what we did is


we gave each of them a czar, the program manager. Then we gave them each their own


working teams, cross disciplinary, CX, plans and pricing, product, engineering, marketing,


creative, product design, ops. We put them into rooms. We got out of the way. The leaders


got out of the way. We said come back with the waterfall of ideas that you think can


actually move the needle on these metrics. It was beautiful, the ideas they came up with.


The way they leveraged each other's teams' tools and hacks and manual processes, the


way they offered up help, the way they traded temps even. It was beautiful. In 90 days we


transformed all three of these metrics. CAC dropped by over $25. Churn dropped by multiple


basis points to the headline. Burn improved over $400,000 a month. It was because they


could see areas because they're closest to it. I got out of the way. I shouldn't have


to approve these ideas. I don't know it as well as they do. But you have to create different


products. It's like this feels culturally scary to a lot of companies. It feels impossible


for big companies. But why? Why is it actually impossible? So how do we do this? You have


to identify the metrics that matter. The whole company needs to know those three or five


things. And you have to agree on them. There can't be ten. You need to have a full stack


team for autonomous support. You need to have some sort of driver for this road map management


because someone does need to be accountable for progress and lack thereof. Some of the


best meetings we had is when what we thought would happen out of one of the tactics didn't.


Got everyone back in the room. We met once every week with the full squad. That's an


expensive meeting. Best meetings we had. You make real progress. You have real debate.


You disagree and you commit as a group and you move forward. You have to decentralize


the approval cycles. I can't be involved because I can't scale. You have to be able to move


faster than any one approver can go. You have to productize experimental design. So this


is super important. Every company in here needs to understand what does it mean to run


a test. And then make sure that all your squads understand what it means to be stat SIG, how


we're going to leverage it, how quickly we're going to run against it. Do we need to validate


it? Does there need to be a second test? Is it MSA specific? What control group exposure


are we going to use? And then once you have the experimental design, every team can run


more tests autonomous, which is what you're really after. And then you're gated by OKR


achievement. Until you hit the metric, you don't move on. Because it's the most important


metric. It's not quarterly. It's not half a year. It's the most important metric. It's


your life blood. So hit it and then move on. The third one, which is something ClassPass


learned and many companies learn and it's the hardest, is that nothing is precious.


The fastest growing companies in the world know that nothing is precious. Not a person,


not a product, not a feature, not an audience, not a community, not a city. They're ruthless


in how they prioritize because they do what's best for the business at every turn. Often


the hardest and most complicated business decision is the one you have to make and you


have to make it right now. And I guarantee you, many of you in the audience had something


just pop into your head and you're like, oh, it's like she's talking to me. Yes, that decision,


go back to your team, make it. Stop putting it off. Stop kicking the can down the road,


which is what we do. Oh, that's just so complicated. I can't get to it. It would be too painful.


It would be a horrible press day. I can't go there. That's where your growth is sitting.


It's taxing your brain. It's taxing your time. It's taxing your resources. ClassPass had


this, a little story here, I guess. Still very emotional to talk about, but we had this


amazing product. It's the product we were famous for. Many of you might know it because


we're actually in Seattle. $99 unlimited product. So you could go to any studio fitness in your


area as many times as you wanted in a month for $99. Beautiful. NPS of north of 70. Double


digits month over month. Scaling to all these cities. Tons of press support. Tons of beautiful


lengths and ambassadorship and just good, awesome consumer love. One small little problem.


That was an unprofitable plan for us. It was sinking our business. And even more so, to


try to get around that, we had to go to our amazing product team, these epically bright


minds, and say, can you build features that stop people from working out? Can you go against


the very mission in which our founder started this company? And it killed everyone every


day to try to scope out product features that hurt our customers. And so we tried for a


year to figure out how to make this work. And it was a taxing decision. We launched


new plans, we launched new features, and we just needed to sunset the product. We needed


to kill the product. We needed to trust that we had value outside one product and that


we could build other plans the world wanted. And that's what we started to work on. And


that worked. It was a hard day that led for a couple of hard weeks. I put up some of my


favorite tweets. We have a very creative community. Beautiful gifts. Very humorous. It was a really


hard day. Honestly, the hardest day of my whole career. Mainly because I had to watch


200 awesome class passers experience what it feels like to let down the people they


wake up to serve. And I would do almost anything to never experience that again. Except for


that I would do it again. Because it's what the business needed. You have to make that


hard decision. There was no way around it. You just got to sign up for that tour of duty


and get it done. You have to manage the dynamics, manage the people, manage the customers, manage


the press, the partners, the board. It's hard. A lot of other companies have done this, right?


Pinterest was tote. The founder wanted to build tote. The problem was mobile payments


weren't ready. That wasn't a real thing back then. He had to shift his point of view. He


had to serve the world in a different way. Twitter has been a million things. They've


made a million executive decisions, hires and fires, bringing people back in. They're


making the right decision, the hard decision, the best they know with the information they


have at the time. And we can't judge them for that. Because there's a lot of other companies


that don't stand up and make the decision. And if you want to be a fast growing company,


you have to trust that you will figure it out and make the hard decision. How do we


do that for real? You have to get ruthless on product prioritization. If there's a feature


in your feature suite that is built just because you wanted to build it but customers don't


love it, stop investing in it. Sunset it. Or some people love it and those people are


special, let them know it's going away and you'll find a way to make them happy.


Revisit prices often. Most companies only revisit prices one to two times a year. You


should be doing it at least every quarter. If you have established pricing power in your


industry, raise your prices. If you have that much value for the world, let the revenue


be the proxy for the value you've built. Take that money, reinvest it back into the product


and serve them even better. Don't be afraid. You built something valuable. You can't lose


yourself in partnerships. I've done this at multiple companies where especially when you're


early or you're a consultancy and you're serving clients, you trade on the logos. You get that


one great logo, that Fortune 500, Fortune 1000 and it buries your company because it


takes all your services, all your creative, all your time, all of your management has


to spend your time with that one partner because they expect them to be in the room. Fire that


partner. Fire that Fortune 500. Trade on other logos. Trust that you'll figure it out. This


next one is probably the hardest. It's fire the wrong people. Hire the right ones. Time


and time again, we get caught up in this one or two people are the people or the five people


or the ten people. And when I talk to someone, you hear this because they say they go into


a room and that's a great idea. We should do that but so and so won't like it. So and


so will never get on board. So and so will hate that idea. Do yourself a favor and fire


so and so. Thank you. Didn't expect to clap but I appreciate that. It's so hard but it's


better for them, it's better for you and you have to trust that your company is better


than any one or two or five or ten people. And you have to do that. Great leaders make


the decision. You have to structure on the outcome and not the people. That's the other


thing I often have done in my past. I've loved a certain person, they're really good at their


job and I structure my team around them. No. I have to structure on the business. My rule


is, I need to do what's right for the business while trying to do what's right for my people.


And that's the hierarchy I've signed up for as a leader. It's the hierarchy that is expected


of me to drive growth. The fourth one, you have to play to your advantages obsessively.


This one is again something I didn't do early that now I'm like all about. And you see this


time and time again. Fast growing companies point to this as what they did early. They


do not build for building sake. You come in as a growth leader, you're like, ah, I could


stand up all these channels, I'm going to have a really diversified acquisition portfolio,


it's going to be beautiful, we're going to have redundancy in case anything happens or


there's a penalty, it's going to be great. You start hiring people and specialists and


standing it all up and it's beautiful. That's not how companies grow inflection opportunity


growth. Instead, they go deep on what's proprietary to their company. What do you have the opportunity


to win at that your competitor could never touch? Go deep on that. Exploit it. Get such


a handhold on it that no one else could get there, then you move on and you stand up the


beautiful acquisition portfolio. So when I got hired at ClassPass, here are the things


I did not do in my first year as CMO. Pretty much marketing. I just didn't do the marketing.


And in fact, I killed a lot of things that were in flight. For a consumer company that


has a ton of excitement and brand equity, I shut down the influencer strategy, the ambassador


program, I killed corporate programs and partnerships, which I got a ton of inbound interest on,


killed events, shut down conversations on out of home, redistributed my brand investment.


I basically shut it all down because I wanted to invest in what I knew no one else had.


Word of mouth. People that work out love to tell the world they worked out. Humble brag,


I do it every day. If I get out of bed at 7 a.m., I'm telling you I got out of bed at


7 a.m. I also bring people I know love to work out and we work out together because


it's a communal thing. It's an exciting, endorphin-driven thing. That's what our business has. You have


your own thing. And I went deep. I built the refer friend V2, V3, we launched sprinkles,


social trust throughout the product, we launched a social layer connection so I could see where


people were working out what studios they were favoriting, book with friends features


so we could book together. I rewrote the reservation system with my product team as a marketer.


I gave my engineers to those features because I knew that it would play into my acquisition


flywheel. That's what you have to do. You have to go deep in the thing your company


has to build yourself the runway and the margin to go broad. The best companies in the world


have done it. Dropbox with referrals, Etsy with partners, LinkedIn with CRO, Wayfair


with SEO, Pinterest with affiliates. You think about that first two or three years that they


got an unexpected advantage in market, they went deep in a channel that worked for them


and they got a stronghold on the market and then they went back and stood up marketing.


Which is hard. So how do we do that for real? This is probably the hardest part. For one,


like most importantly, stop building just because people tell you you should build or


because we tell ourselves we should build because we're builders. It's really hard to


see a channel that's not beautiful and just be like, I'm sorry, you're not beautiful.


Good luck. You know? And it's really hard to sit in a room with the board member where


they tell you that their other acquisition portfolio company has crushed it in ABC and


why aren't you doing ABC and you stand there and you're like, because I'm not. You know?


That's the standing up. That's kind of, you know, it's the conversation, what Tara's talking


about, being the CEO, having the spine to stand up and say I know what I'm doing and


I'm doing it and it's going to work. You need to know your proprietary advantage. You know,


ClassPass has this beautiful set of reviews. We're going to go deep in what that can do


for our business because no one else has these reviews. You need to educate your teams on


these levers so that they can see, again, the open green field, the magic opportunities.


You need to organize around these proprietary advantages. We're going to have an entire


set of squads and teams around reviews and UGC because that's an advantage to us and


we've already done this. In fact, I was talking with Matt and he's going to stand up his own


focus around understanding K factor and virality because that's one of our advantages. I need


to know everything there is to know about that metric at our company so that we can


think at a level that no one else can compete with. So those are just some of the ideas.


The fifth and last one, the kind of pattern that you see, and this concept, we actually


heard a little bit about it today, which is evergreen testing to make your case. This


is just a straight up tactic to take back. And here's the problem. We as marketers align


to the product team and so we actually do our roadmaps when they do theirs and that


could be on a three month or a six month or a one month rolling basis. So then you get


just done with a quarter, you start another quarter and you're starting to do your roadmap


and all of a sudden they're like so what should we build and you're like we need to build


this, that's where the growth is and they're like what's your proof and I was like I just


know it and that's not enough. How long will it take, is it small, medium or large and


you're like I don't know, I haven't scoped it and they're like okay, I can't plan for


this so let's just revisit it next quarter. Three months gone, your competitor just built


it, you just lost. You need to be ahead of every planning process at your company as


a marketer, which means you have to allocate a percent of your time every quarter throughout


the quarter for evergreen testing and business case making. Then you come into the product


planning process and you're like data, look at what it could do for us, here's the business


case, here I scoped it with you for a brief, I've done some light wire frames, let's go


build it and they're like let's do it. Here's a great example, this was the example of the


Q2 roadmap against growth at ClassFast in 2016 and it's nine things. There were nine


very awesome important things but they were nine things. This was the Q2 roadmap for 2017,


everything in yellow was growth. And it's because we spent a year figuring out how to


pre-plan and make business cases. This is done through manual tests, bringing in temps,


customer surveys and what you see is I have some of the acquisition squad on growth, the


engagement squads on growth, the planning pricing squads on growth, the systems teams


on growth, I stole some engineers from the studios team and they're on the B2B side.


You just make the case for it and the company will mobilize around the most important case.


But we have to do this for them. It's what we owe them as a partner. So how do we do


this? Organizing thesis based brainstorms cross team is super important because what


you don't want to do is bring a great idea that has had no one at the company involved


but marketing. So something like I think we should open up the app because right now it's


locked. What does it mean to open up the app? Let's bring in anyone that wants to talk about


that and think about all the great apps we love and the different ways that they're open


platform. Model home, tour, freemium, let's talk about all the models and all the things


we love. Coming out of that brainstorm, you've already got buy in, you've got interest, you've


got passion, you're already way ahead of the game. We also need to be allocating about


20% of our ongoing central resources to testing. So central resources, copy, creative, could


be analytics. About 20% of my creative stack is constantly testing against next quarter's


roadmap. So that might be something on onboarding, it might be email, it might be abandoned cart


campaigns, whatever it is. So I can go to product and say I need to productize this.


I've been running it with manual temps. We're seeing a point in Lyft or two point reduction


to headline churn. This could be huge. You need to build the preprioritization roadmaps.


You need to scope the product to ask for them. Ian talked about this yesterday in content.


We are a partner to these teams. We owe them what's in our brains. They're not asked to


solve it for us. We owe them every idea and every great benchmark out there that we can


find. We package it up and we're like let's have a conversation about this. That's us


being a good partner to them. You need to map to more than one OKR, multiple ones is


best to make the really strong business case. That's growth. Three levers. Try FECTA if


you can affect all three. Those are the features your company should be building. And then


this kind of evangelism, right? Everyone on my marketing leadership team is expected to


spend a good amount of their bandwidth working with peers, educating them on what we're excited


about, the areas we're nervous about, the gaps we're behind, what our competitors are


doing and why we think we could win if we just did X. That's them with drinks and coffees


and lunches and walk bys. It's all the things you need to do and you can't ignore it. Because


this is a team, you know? So wrapping this party up, it isn't about the tactics. We know


this. It's not about the platforms. We know what growth isn't. We know it in our hearts.


But what it is is hard. It's investing in growth as a machine. It's hiring these creative,


resourceful, low ego people that want to solve a problem and run super fast. Relentless execution.


Obsessive reinvestigation of what they're prioritizing. Not precious about it. Obsessed


with having impact. And it touches everything. But when you do it, you crush it. Because


your competitors don't want to put in this time. They don't want to manage emotions around


the team and partner with someone and rethink about everything they've done and how they


know how to do their job. They don't want to sunset their best product and have that


conversation. So stand up and do it. You'll win. And the best part is you'll win, you'll


get more from your customers to reinvest and then you'll win and do even better by them.


Which is like magic, right? It's everything we wake up to do. So hopefully this was helpful.


I did put up my information. If anyone wants to talk about it, please reach out. Thank


Comment Marketing: The Benefits of Community Participation - Whiteboard Friday

Howdy, Moz fans, and welcome to another edition of Whiteboard Friday.


This week we're going to chat about comment marketing.


We talked about this actually five or six years ago, but it is time for a refresher


because there are a lot of things that have happened in the world of online marketing,


so this deserves a new take.


Comment marketing has not lost any of its power and influence.


In fact, because fewer people are doing it today than were five or six years ago, especially


in the digital marketing world, it's actually become increasingly influential.


There's a limited number of blogs and communities in most sectors and spaces that have audiences


that engage in the comments, but where they do, you find incredible levels of participation,


of amplification, of opportunities for press and for links and for social following.


I'll show you how that works and then I'll talk about some tactics in terms of how to


create great comments and a strategy to build around it.


So first off, why do comments help so much and how do they help?


Well, it turns out that if you leave great comments on other folks' sites, they may lead


to visits to your website through your profile, through links that you leave, through people


clicking on your profile and then following that link, which can lead to links in future


posts by the authors of the site where you commented or in future content pieces created


by people who read that site.


If they see that your comment is particularly insightful, it brings up a great example,


shows off a resource that is sorely lacking, especially when you are either leaving links


or commenting about things, if you do so in a very respectful, diplomatic way.


For example, one of the best strategies, best tactics I've seen for leaving a comment with


a link in it is to say, hey, I want to make sure that this blog accepts links in the comments,


but I figured I should point to X. Editor, feel free to remove if links are not appropriate.


That way you're saying, hey, I recognize that dropping a link in the comment could be a


little sketchy or you could say something like, we've actually been doing this on our


site.


If you go to our website, you can check out the link via my profile so you're not even


leaving it in there.


You're saying, go check it out from there, then you can see this other thing that I want


to show off in relation to the content here.


But those can lead to great links to your site in the future.


Commenting can also lead to indirect links through exposure and exposure itself, meaning


things like you leave consistent quality comments, people start to recognize you.


You sort of see that profile picture again.


You go, I know that brand from somewhere or I know that person from somewhere.


I have some positive association with them adding value.


That can lead to a better chance of engagement with you, your personal brand, or your corporate


brand in the future, which can mean a better chance of future conversion.


It can also lead to social following growth.


You have lots of great comments.


People will check out your social profile from your profile in those comments, and that


can often lead to follower growth.


You can, of course, juice this a little bit by choosing, rather than linking to your personal


site if you so choose, you could link directly to the social account that you are trying


to promote or grow followership with.


So if you say, hey, I'm trying to grow my Facebook page.


I'm going to make my Facebook page my profile link in here.


That works just fine.


That can grow your Facebook audience.


That may be how you're best reaching your audience, or it could be you're doing it on


your website or through Twitter or Instagram or another way.


But all of these things basically follow the same format.


People see those comments.


If they're engaging and they draw them in, it can lead to very good results.


What is it that makes a comment great?


Basically, every single one of these start with, you must leave consistent, high quality,


great comments.


And greatness in a comment means a few things, right?


So first off, it's got to be on topic, meaning that while you may have lots of very interesting


things to share, if you go off topic, you will, even if you provide great value, tick


off the moderators of the community.


You will often turn off a lot of folks who are reading those comments.


It's just not what people are there for.


So you've got to keep it on topic.


You should be respectful to the author and other commenters.


And I say respectful because what I don't mean is you can't disagree.


In fact, I think it is great to say, hey, I really love this post.


I think you made some great points.


But point number three and four that you made here or this one and that one, I disagree


with and here's why.


This is my experience or I have this data or I conducted this survey or I want to show


you this information, right?


Go check it out over here.


That is just fine.


As long as you're respectful and kind, I think you're in a great position to disagree and


to add value.


Disagreement actually does add a lot of value.


Speaking of value, we are trying to provide unique value here, right?


We want to provide unique value through our comments.


When I say unique value, what I mean is you can't just say things that were already in


the post itself, things that have already been mentioned in other comments or things


that are sort of common knowledge.


Anyone could find them out or they're instantly recognizable.


They're sort of already known.


We want insight or tactics, help, context, examples, data, whatever it is that is not


found in the original piece or through common knowledge.


That's what makes a comment truly stand out.


That's what makes people vote up a comment, click on the profile, go check this person


out.


They seem really smart and intelligent and helpful.


There's a few other items.


We want to be well written, so grammar, spelling, language issues, and well formatted, right?


You should use spacing and paragraphs, bullet points if they're available in the markup


effectively, right, to try and convey your point so that it doesn't just look like a


bunch of jammed together words and sentences.


If you have a very long run on paragraph in a comment, it can turn people off from even


starting to read that.


Finally, this is important, transparent.


You should not try and pull the wool over people's eyes in a comment.


We want to not hide our intent or our associations.


Even if you are doing comment marketing, specifically as a commenting strategy to try and attract


people, you can be totally upfront about that.


You can say, hey, full disclosure, I work for company X, right, and I wrote this piece,


but I think it's relevant and helpful enough that I want to bring it up here.


With permission, hopefully, I'm linking to it.


Editor, feel free to remove this link if it's not appropriate, right?


Here's why I'm linking to it.


Here's what the value is that it provides.


Now you've been transparent about your intentions and motivations, your associations, what you're


doing, you will get a lot more both forgiveness and leeway to leave comments that are valuable


if you do that.


Final thing, if you've decided based on the couple of things we've talked about here that


comment marketing is something you want to try and engage in in 2017 or for the future,


I would urge you to build a true strategy around it, not just tactically say, well,


maybe a couple of times I'll leave a few comments.


That's fine too, but you can get the most benefit from this strategy if you truly invest


in it by following a process like this.


Determine the goals you want to get out.


Maybe that's build exposure to get links.


Maybe that's to grow a social audience.


Maybe it's to try and get influencers to engage with you so that they become brand proponents


for you in the future.


You want to build some measurements around that.


Comment marketing is tough to measure, very, very tough to measure because you can't see


how many people saw your comment.


You only see the results of it.


But you can look at traffic and visits that are referred to your site from the site on


which you left the comments.


You can look at growth in your social following.


You could look at new links from sites in which you engage with in comment marketing,


those kinds of things.


Then you should identify a list of the sites or communities that you want to engage with.


Those sites and communities, it is best if you don't say, hey, I'm going to try and leave


one comment this year on each of 200 communities, not valuable.


Pick the top 10, choose to leave 15 to 20 comments on each of them.


You want to build up a reputation in these communities.


You want that consistency so that people who are in those comments and the authors of them,


the influencers who write them, consistently see you in there and build a positive association


with you.


Then you want to do some research.


I'm urging you not to comment the first few times you read through it.


Go through the backlog, look through their archives, read and see what other people have


commented on, see what other people have enjoyed and appreciated, see what comments do well


and get noticed, see what the community is like.


Then create some sort of an alert system.


This could be subscribing to updates via email or using RSS or if you follow them on Twitter


and you get pinged every time they launch a new post, whatever it is, because early


comments tend to do best.


Right when a post is published, if you can comment in the first, let's say, 30 minutes


to three hours, that's the best opportunity you're going to have to be seen by the most


people reading that post.


Finally, I would urge you to use social media, especially Twitter because that's where most


publishers are, to amplify and spread your comments.


Meaning you go leave a comment and it's really high quality, then tweet, hey, I just left


a comment on at Randfish's post here about blah, blah, blah.


Now I'm probably going to see that via Twitter, even if I don't see it via my comment alert


that I get through email.


I'm going to know, hey, this person's not only promoting their comment, they're also


promoting my post.


That's great.


Now that builds further engagement with the people you're trying to reach.


All right, everyone.


Hope you give this comment marketing strategy a spin.


If you have other tips, things you've seen be successful, feel free to leave a great


comment in the comments down below.


We'll see you again next week for another edition of Whiteboard Friday.


Indexing on Fire: Google Firebase Native and Web App Indexing Presented by Cindy Krum

Like he said, my name is Cindy Crum.


I'm the CEO of a company called MobileMoxie based in Denver, Colorado.


We do mobile SEO and mobile app consulting.


And I am super excited to be talking to you today about app indexing.


That's going to be web app and native app indexing.


And then I'm going to talk a little bit about Google's new app


platform called Firebase.


It's all super exciting.


And I know from the previous speakers that you guys have already


heard some stuff about mobile.


But I also know that a lot of people think mobile's a bit scary.


It's new and different and tiny.


And lots of people are having problems because of mobile.


And so I'm empathetic.


But I can feel you in your seats.


And I think you might be thinking, like, come on, Cindy.


I'm just a caveman.


I'm just an SEO or a marketer or a copywriter.


I don't know how the developers make the websites with the pictures


and the videos that light up those little devices or the apps that


make the pew pew noises.


It's magic.


Magic.


But ladies and gentlemen, I also am just a caveman.


I'm just an SEO.


I'm not a developer.


Sometimes the things developers say frighten and terrify me


and confuse me.


But what I do know is the stuff that's happening in apps is important.


And I have spoken to the Google gods above.


And they told me that understanding this


is critical to understanding the future of the internet as a whole.


And they told me a story that I'm here to convey to you.


In the beginning, there was nothing.


There was darkness.


Google didn't even try to crawl apps or complex websites with JavaScript.


They were locked out.


Historically, Google hasn't even gone into those things


because they were worried that they might execute malicious code.


So they didn't even try.


But then over time, they realized that really important, engaging stuff


was happening in JavaScript websites and native apps.


So they started to crawl it.


They decided that it must be indexed.


So they started with JavaScript.


And they crawled JavaScript.


And they got better.


Because if it's not crawled and not indexed, it can never rank.


And they wanted to provide users a good experience.


So they got better and better at crawling JavaScript.


And then they started crawling Android apps.


Because Android was their platform, so they


knew they could teach their crawlers to understand the code.


Then after a while, they started crawling Apple apps, iOS apps,


and indexing them.


And what they found out was that crawling JavaScript websites


and crawling native apps is actually quite similar.


It's done primarily with lists and mapping documents and APIs.


And in fact, it's less about crawling and more


about ingesting this mapping information


and associating it with existing web content


that they already know how to evaluate,


that they're already good at ranking.


And so they indexed this stuff.


But the crawling is still a bit primitive.


It's still mostly based on an association with a website.


But at least it's there.


It's especially hard for iOS apps


because they don't control that code base.


And Apple is super secretive.


But it's indexed.


And you can index not only the app itself,


but the content within the app.


And that's super, super exciting as an SEO.


So we've reached this state of semi-enlightenment,


where the content is getting indexed,


but it's not super sophisticated.


It's mostly based on lists and associations with web content.


But that's OK.


So what I want to explain to you today


is I want to start by telling you about the two


different kinds of app indexing that there is.


There are two basic kinds of apps.


There are web apps, and there are native apps.


Web apps live on the internet.


They're not necessarily something


that you would download from an app store.


And there are a lot of different names for web apps.


The ones that I like are called progressive web apps.


And I'm going to talk more about those in a minute.


But there are a lot of terms that developers throw around


that kind of mean something similar.


They'll say progressive web apps, or just web apps,


or HTML5 apps, JavaScript apps, dynamic websites,


stuff like that.


And all of those essentially mean something similar.


They mean that it's a website that


relies heavily on JavaScript and specifically Ajax.


And what the Ajax does is it creates


an ongoing communication between the web page and the server.


Ajax stands for asynchronous JavaScript and XML.


It means that when the first page loads,


it might only load the first bit of content


that it needs to have a good experience.


And then it'll load more things based


on what the user requests by clicking around


on the website.


So that's been around for a while.


And now developers have built out all these different code


bases to make web apps and dynamic websites feel


more interactive, feel more like a native app.


Because as it turns out, people really


love native app experiences.


They're more fluid, and they just feel better.


So this code, it gives you things


like plus boxes and continuous scrolling.


So you don't always have to load a new page.


And that's a great experience.


It's more appealing to the audience,


and they don't have to wait for things as much.


The problem is with all this new code,


the pages got bloated and inefficient.


Because the code does lots of really cool stuff,


but it trades off.


It creates a good user experience for part of it


design-wise, but then slows everything down


because it has to load all this extra code,


and it's inefficient.


But some of it does really important things.


So we use JavaScript to do things


like make websites responsive.


When you have a responsive website,


it uses JavaScript and media queries


to pull the different rendering instructions


so that the page knows how to display


on all the different devices.


So that's really important.


But what we know is that over time, pages, the file size,


is getting larger and larger, even though the devices


that we're trying to display it on are smaller and smaller,


and often on less than reliable connections,


perhaps like what we're trying to deal with sometimes in here


or in a subway.


You have spotty connections trying to download massive


pages, and that's a problem.


So Google decided that they wanted


things to be mobile-friendly.


And they started by saying, hey, we need you to be mobile-friendly,


so we need you to make your JavaScript and your CSS


crawlable, and then you can have the mobile-friendly tag.


But recently, they rolled that back because why?


80% of us did exactly what they asked us to because they


created this incentive.


They said, if you're mobile-friendly,


you have a much better chance of ranking on a mobile search


result than if you're not.


So now only 20% of the sites out there are not mobile-friendly.


So I'm wondering, is there going to be now a negative incentive?


They tested this slow tag here.


They clearly care about the speed,


and they want the speed to be fast.


So it's an interesting thing to see,


how are they going to incentivize us to get there?


But what you can't deny is that Google


wants to crawl that JavaScript.


That was part of the incentive.


But if you're an SEO, you might have missed this.


Google actually now explicitly endorses, not endorses,


allows JavaScript redirects.


As long as you have a rel alternate tag,


it's OK to have a JavaScript redirect


to handle mobile traffic to get them


to the right version of the page.


They say, this is fine.


Rel alternate.


They don't even mention the rel canonical, which is rare.


It's interesting.


So what I want to talk to you about


is Google's favorite kind of web app,


and it's called a progressive web app.


And these are extraordinarily cool and extraordinarily fast.


The reason is they put a middle layer between the server


and the website.


It's called a service worker.


And what it does is it pre-fetches and pre-renders


and caches all of the stuff that that heavy JavaScript controls


to make it feel like what's happening on your website


is instant, to make it feel like a native app,


like something that you've downloaded.


But it's just all because of this service worker that's


handling and pre-caching and pre-fetching everything.


It's super cool.


And if you've read anything about AMP,


you might remember hearing about the AMP JavaScript runtime,


which is also a middle layer that does nearly exactly


the same thing.


So if you've seen how fast AMP pages are,


then you know the value of this service worker.


Very similar.


I think that AMP is basically like a progressive web


app without an app shell.


But actually, just recently, they


launched this new thing where they


have the AMP viewer, which is kind of like a full-on


progressive web app.


To do this, though, to have a service worker,


you have to be on HTTPS.


It's a requirement for AMP, and it's


a requirement for a progressive web app.


Fascinating other similarity.


Now, if you're a progressive web app,


the next thing that you have to have


is called a web app manifest.


And just like a plain manifest that


tells you who's on the plane and the vital details of the plane,


this file tells you the vital details of the web app.


It tells you things.


It looks like this.


And it tells you things like the app title, a short and a long


title, the icon.


Where do they find it?


What does it look like?


The app shell.


What color should it be?


The outside of the app when it's in its own window.


And where should this app start?


On the website.


So they link to the first view of the app, the default view.


So that's a web app manifest.


And all you do is you write that manifest,


and you link it from your website.


And you create your service worker.


And then you have a progressive web app, or PWA.


And this is very, very cool stuff,


because in the manifest, you can do fun things like have


the app load with a browser address bar,


without a browser address bar.


You can have it load standalone without that browser address


bar, or you can have it load full screen like a game.


So just like any game that you're


used to playing, like Angry Birds or something like that,


where you don't have the controls on the side,


you can have your website load like that.


That's cool.


Who knew you could do that?


Anyone?


Right.


It's awesome.


The other thing you can do when you have a PWA


is you can send push notifications.


So most websites can't send push notifications.


Only apps can, because everyone worries that they


might send something malicious.


But since PWAs have to be on HTTPS,


they know you're not going to send anything malicious,


because you can't.


And so PWAs allow you to send push notifications to anyone


that's downloaded the PWA, just like any native app would.


So what does that mean?


Download the PWA?


Well, it's a bit confusing.


But since it's a website, you can get to it from a browser,


like any other website.


But once you've visited the same website a couple of times,


it can remember and show you this little banner that says,


hey, you've been here a couple of times.


Maybe you want to download our app.


And then it can download the PWA instead


of downloading a native app.


It'll download the PWA.


All that means is it's downloading the app manifest


and a service worker.


So it's really fast download.


It's nearly instant.


And then you get an app icon, just like any other app icon


from a store that you might have downloaded.


You say, yes, I want this on my home screen.


And you get an app, right?


Nearly instantly.


It's beautiful.


When that happens, instead of accessing the PWA


from a browser, you can access it


on its own in its own little app shell in its own window.


You can toggle between the browser and your PWA app,


because it's got the color.


It's got the logo.


It's got the splash screen.


And it's got the service worker managing


everything that's happening.


Anyone know you could do that?


This guy.


OK.


Now, the other cool thing that might blow your mind is,


this works offline.


Anything that the service worker has in its cache


is local to the phone.


So you can visit it and interact with the JavaScript


offline when you don't have a web connection.


So you can have a messaging app that'll


wait until it gets a connection.


And then it'll pass your messages


and pull down messages.


Or you can have a news app that's


cached all the stories that you've looked at


and all the sections that you've looked at before.


And you can interact with it, even when you


have no web connection at all.


So I'm going to show you a video.


And I think you're going to be impressed.


Maybe.


Oh, no.


You guys.


They're going to get the video going in the back.


Aren't you?


All right.


So we open up a browser.


And we navigate to wapoo.com slash pwa.


So when sections load, they start caching stories


for offline reading.


And when you tap on the sections that you're interested in,


those sections will also become available offline.


As a result of this caching, tapping on an article


feels instant because it's coming from the cache


and not from the network.


You can also swipe back and forth


to move between articles in the same section.


And that feels instant too.


But what happens if we go offline?


So we go into airplane mode.


And now you can see that sections,


which I haven't visited yet, are marked as such.


But the sections that are in the cache can still be viewed.


So lastly, if we keep using this app,


Chrome will eventually prompt us to keep it to my home screen.


So let's go back to it.


Ah, there we are.


Now you can add it to the home screen.


And we've got an icon.


And launching it from the home screen


brings me to an immersive version of the Washington Post


reading experience.


But we didn't actually have to ship a different app


or upload it to the App Store.


That's rad, right?


Yeah!


Come on!


That's awesome!


Cheryl likes it?


It's awesome.


And remember, that's all a website.


And all you had to do was add the service worker and the app


manifest.


It's pretty awesome.


So this is Alex Russell.


And he's a Google guy.


And he talks a lot about progressive web apps.


And what he says is these apps aren't packaged and deployed


through stores.


They're just websites that took all the right vitamins.


They progressively become apps.


So I think this is super duper cool,


because it gives you the app experience


without having to download it.


You still get super fast stuff.


Or you have the option to download it.


So that's really cool.


What's even better about it is it


solves a lot of the problems that you've


been hearing about that people complain about websites.


Because users love these.


People spend 3x more time on a progressive web


app than a regular site.


They have a 40% higher engagement rate,


70% higher conversion rate for people


when they download it compared to the regular mobile version


of the site.


And they take 3x less data than the mobile version


of the website.


They're lighter, because the service worker


does all the stuff for you and caches it for you.


So it's faster and lighter.


It's great.


Here's a problem.


Web apps in general, and any dynamic content on the web,


is a bit hard to index.


The reason is developers who build these things


are just using the JavaScript to get stuff


in a continuous way from the server.


So they don't actually have to have URLs


to load fresh content.


They get it from the server, and they don't have a URL.


That creates problems for Google, because Google understands


the world based on URLs.


So you have to do a little bit of extra work.


You have to have HTML screenshots.


You have to have a really great XML site map.


You have to use HTML5 push state,


so whenever someone requests something new from the server,


it updates the address bar without refreshing the page.


And you have to check everything in fetch and render as Google


to make sure that they're getting it and understanding


it, right?


So it's extra work.


And unfortunately, not all of the PWAs out there


have done this work.


For instance, Washington Post.


It's an awesome demo, but not an awesome demo


from an SEO perspective, because they only


have this one page index.


And I'll sneak preview, you guys.


I am sorry.


They took this down the day I was flying to Seattle.


And if you've been watching me on Twitter, you'll see,


we've been trying to bribe them to put it back up.


But I am sending out right now other links to PWAs


that you can try on your phone.


They're not quite as screaming fast as this one,


because this one, the Washington Post one, they use PWA


technology, and they coded it in AMP HTML and AMP JavaScript,


which FYI, you guys can do too.


AMP HTML and JavaScript are totally free to use whenever


you want, even if you're not news or not anything AMP-y.


You can use it, and it'll be much faster.


But there are other examples going out on Twitter


that you can check out that are super cool.


And you can do all different kinds of things in a PWA.


You can do games, run trackers, anything.


Most things you can do in an app, you can do in a PWA.


The limitations are some of the mobile browsers


have varying adoptions, but they've all


got it slated for the next round of mobile browser releases.


But in general, Chrome, Android, Safari,


all accept service workers and can handle that stuff.


Here's another example, and this is a PWA that was created


by a Google team as a demo.


This one also, not great for indexing.


A little bit better, they have more than one page indexed.


But sadly, they have lots of duplicate title tags,


lots of duplicate meta descriptions,


and really under-optimized URLs.


Now these things are not necessarily


part of being a PWA.


They're just part of being a developer who doesn't know SEO


and doesn't have an SEO initiative driving him


to optimize it.


But it's all possible to optimize.


So just remember, if you're going


to do any dynamic content, but especially a PWA,


make sure that you don't let the fancy development kill the SEO


effort.


Now here's just a quick list of resources,


including an app manifest wizard that


will allow you to write your app manifest in less than five


minutes, and a tutorial for doing the service


worker, which is also not super hard,


and some other stuff there.


OK?


Cool stuff.


Now that's web apps.


Let's talk about regular apps, the apps that you're used to,


the apps that we actually call apps, the ones that


come from the store.


Now I'm going to sneak preview and tell you


that the Oracle of Everything app is sitting in the audience.


And her name is Emily Grossman.


She's right back there.


She knows more than Google does about this stuff.


And I'm just kind of being her voice right now.


She is crazy well-versed on all of this stuff.


I'm pretty good.


She's the Oracle.


So she wants me to tell you that app indexing is all


about giving apps entry points.


Since they don't have URLs, you kind of


have to overlay entry and exit points onto the app.


Just like a JavaScript website, you


have to give Google something to latch onto.


And that's a URL.


You put URLs on top of the existing apps,


and they become indexable.


So there are good reasons for having native apps


and good reasons for having web apps.


Web apps we just talked about, but they have their problems.


Native apps solve a lot of those problems


because they're not as slow.


People really like engaging with them.


And they have kind of the razzle dazzle factor.


The problem is they have minimal reach.


As it turns out, the number of apps downloaded from the App


Store per person last month and for the previous basically two


years of months, average number of apps downloaded


from the store, how many?


Zero per person per month.


People aren't looking for new apps.


It's gone.


No one cares because they have the apps they want already.


So the reach of an app, even though you're


throwing tens of thousands of dollars at it,


the reach can be quite limited.


And so that's expensive.


That can create minimal or negative ROI


on an app development project because people just


aren't looking for your app for the most part.


As it turns out, apps represent 86% of the time


that people spend on their phone.


And every app developer you ever meet will tell you this.


They want you to believe it.


The problem is that 86% is represented by the top three


apps.


It's Facebook.


It's YouTube.


And it's Facebook Messenger is 86% of the time


that we're spending on our phones.


The remaining 20 or so percent is


fought out by a couple of apps.


But remember, what we're tracking here


is time spent in apps.


So who wants to throw out apps that take a lot of time,


like Netflix and Hulu and Google Maps and Gmail?


Those guys are taking probably the rest of the time,


leaving a very small portion available for you guys


to fight out to get eyes and time in your app.


Here's something else you probably didn't know.


66% of all digital purchases that happen on a mobile phone


still happen on the web.


So in terms of ROI in the app, your metrics


are going to be so skewed.


Because even if you have an app, no one's finding it.


No one's downloading it.


And definitely no one's spending money there.


People still spend money on the web


because they don't have to download it.


It's a much easier interaction.


The money happens on the mobile web.


OK.


So we solved this problem by making


the apps more discoverable, by getting the apps themselves


indexed, but also the content in the apps indexed.


To do this, we have to create lists and mapping documents.


And we have to host them on the web.


So what you do is you update your app


so that it follows HTTP or HTTPS app schemes.


What that means is app developers kind of


made up their own word for like URL.


An app scheme is basically a URL for content in the app.


And historically, app developers were off doing their own thing.


And they had custom app schemes, and this app scheme,


and that app scheme.


But now we're saying, hold on, guys.


Just do what we've already figured out.


This works on the web.


It'll work for you, too.


So if you create HTTP and HTTPS app schemes that match


perfectly what's happening on your website,


then you create a union, or you can create a union,


and a bunch of matching content where


there's app version and web version,


and Google can evaluate and rank it.


Now, it's not enough to update the app.


You have to put the mapping document on the website


as well.


In Apple, it's called an Apple App Site Association File.


It's basically, if you look at it,


it looks a lot like a robot's text file.


It says, this matches up with this,


and it should or should not be indexed.


Same thing exists on Android, but they


call it something else.


Just to be cheeky, it's called an Asset Links File.


The next thing you do, you host these files on your website.


There are two places that Google looks for them.


They look for them in the root directory,


and they look for them in a.well-known directory.


Who knows why?


But that's where they're looking for it.


So again, it's a lot like a robot's text file or an XML


sitemap, because Google is actively


looking for these there.


Now, once you get indexed, there are some benefits


above and beyond ranking for app indexing.


Once you're indexed, you can also auto-populate.


So if people start to search Google


for something that looks like they're searching for your app,


Google will show it to them automatically, especially


if you have it downloaded.


That, again, helps solve the reach problem.


People can now see your app.


Remember they've downloaded it.


Remember that it has the content that they're looking for.


But here's the problem.


The association in the mapping document


has to be to the canonical on the web.


If you do 301 redirects, you move a section of your site,


but you forget to update your mapping documents for your app.


You've broken all your deep links.


This is the number one problem we see.


So this is what those link files look like, right?


They really do have a lot of the same forward slash star kind


of robots text rules.


And they're not all that complicated.


But remember, remember, remember,


you always have to map to the canonical.


You can't 301 content on your website


and not deal with it in the app association files.


OK, so it sounds pretty easy.


Why is everyone not doing it?


It's not that hard.


Here's the deal.


The problem with the status quo is that it's a problem.


It's expensive.


It takes a lot of time to handle Android, Apple, and web, right?


And sometimes you have three different teams working on it,


and they're not talking to each other.


So you're spending triple the time, triple the money,


and triple the inconvenience of trying


to get these teams that don't normally


work together work together.


That's really tough.


And this is actually the biggest problem we solve.


It's not like redirects and stuff like that.


It's actually getting teams to communicate and introducing


teams to each other.


Because each of these teams tend to have their own group,


and they don't necessarily talk.


So the web team will make an update


and forget that the app teams exist


or that they've mapped anything to anything else,


and they break everything without even knowing.


Here's the other thing.


These teams all use different words


to describe mostly the same thing.


And so they're not communicating.


And even when you set them together,


they don't speak the same language.


So you have to have translators and interpreters to explain,


oh, well, in Android, this means that,


and in iOS, this means that.


The language, it's not a common language.


So it can be very hard for them to communicate,


and they give up.


So you have to have someone ushering those conversations.


So Google thinks they've solved this.


And if you were watching Google IO this year,


you probably heard a lot about Firebase.


Firebase is Google's new app platform,


and it's pretty cool.


The idea is Google thinks it's the answer.


It thinks it's going to bring everyone together,


make everyone able to communicate with each other,


or make those communications irrelevant, right?


Because it's going to do all the work for you.


Sounds great.


Problem is most SEOs don't get it.


Google hasn't done a good job of communicating about Firebase


to the SEO community.


But basically, it does the work of giving native apps and web


apps indexing points, entry and exit points.


And so it makes all of the crawling and indexing easier,


especially when you realize that part of Firebase


is this hosted solution where Google takes all of your app


content and says, let us host it for you.


And then they don't even necessarily so much


have to crawl and index it, because they've already got it.


It's there.


They get it.


They can access it at their leisure,


because it's in their cloud.


That's great for you, because it makes everything


that much faster on a Google Cloud-hosted solution.


And it means things happen uniformly


across all of the platforms.


So that's cool.


Google has a vested interest in this,


because it makes their services faster,


because they don't have to do all the processing of a query


as much when they host all of the content already.


It also gives us the ability to have these things that Google


calls dynamic links, where Google has all of your content


in Firebase, and it says this screen in the iOS app


equals this screen in the Android app


equals this URL on the website.


And they say, we don't want to index all that three times.


Why don't you let us give you a short link that


means those three things with just this one link?


And so they index all of those things together on one link.


That creates a lot of efficiency for them,


but also a lot of efficiency for your users,


because your users can share things in an app to a friend


on a different operating system and not worry that it won't


work, but also not worry that the app's not installed,


because it'll default back to web if they don't have it.


It's a really great solution.


So here's the fun part of the talk.


I'm going to tell you what I think this means for the future.


I love this part, because you can't really argue.


I'm not telling you this is fact.


This is just what I think is going to happen.


So we know that Google likes to entice us with ranking boost.


They gave us one for HTTPS for mobile friendly.


They gave us one for setting our apps up


for indexing in the first place.


And then when they launched the app indexing API,


they said, hey, we'll give you a boost for using the app


indexing API.


If you have universal links, then you


can be in the app indexing API.


That's a boost.


And then I think Google soon enough


is going to say, you get a boost for Firebase integration,


because Firebase makes Google's job that much easier.


It also makes it better for the users,


because if you think about a native app,


it's got a limited reach, right?


A native app for your iPhone only works on other iPhones.


A native app for your Android phone


only works on other Android phones.


When they encourage you to say, hey, also


you should make your web app a progressive web app,


that one will work anywhere, regardless of the platform.


And then if they say, hey, also, since you're already here,


you've got all that stuff going, just drop it into Firebase.


You'll get a rankings boost.


Then they have a way of making sure everyone


gets the best, fastest, coolest experience possible by giving


you the ranking boost.


Now, let's think about this with deep links in mind.


In the upper right-hand corner of the slide


is an example of a deep link.


If you've been in SEO and been paying attention,


it might look a little familiar, because it's


based on Google's old URL shortener, which,


when they launched it, they talked about using it


as a central place to disambiguate deep links,


essentially to make it the one link for all


of your related content.


So you're hosted in Google's database.


You have better app indexing for all of your apps,


whether it's native or progressive.


Enter Android Instant Apps.


Who's heard about these?


Google has started a beta where they're


indexing screen previews of native apps, Android only


right now, native apps that don't have corresponding web


content.


I think that they're using Firebase to do it,


because Firebase gives them the deep links they need,


but also the content they need.


And then you can just create a shell


and have an Android Instant App that works without a download


in the cloud.


That's cool.


And it's in their best interest, because it


keeps the game on their turf.


They know web.


And they want things to happen on the web.


And they don't want you to have to download things.


So they want it all to happen in the web.


So I think we're going to see iOS Instant Apps eventually,


when they figure it out.


It's not going to be easy, but I think it's possible.


What's interesting about that?


No need for app stores.


They can cut the app stores totally out of the equation.


So that means right now we already


know that app packs are ranking, and you can download apps


directly from a Google search result.


I think the status, 46% of apps are now


downloaded from an app pack, rather than going through the app


store and starting there.


This is a big, big deal.


So let's think about it another way.


Google encouraged HTTPS.


And that's important.


They gave a rankings boost.


Google launched AMP with Google Web Services


to do the caching, the Google hosting.


AMP uses Google hosting.


And now PWAs in Firebase also use that same Google hosting


for Firebase.


Next, if we talk about app indexing on dynamic links,


that's going to enable cross-device behavior,


not only between phones, but between other devices that


are trying to use the content in apps, but struggling.


So things like Android Auto can now interact with your,


in this view, can now interact with your iPhone


and your Android phone, because it's all happening in the cloud


on the internet, and it doesn't require your operating system


to latch in.


Beacons, Google Home, all of that stuff


will be able to work with Android and iOS,


because it's all happening in the cloud.


Then we get to the potential non-parity indexing,


which we know is already happening for Android,


but probably will happen for iOS as well.


And with App Packs, there's no need for the app stores


anymore.


But beyond that, it's much easier


to monetize your apps and all of your content


when it's in Firebase, because you have the cross-device


attribution, and there's tracking in there.


But beyond the tracking, there's actually


the ability to export it all to Google BigQuery, which


is their big data tool.


So you can create really, really sophisticated marketing


campaigns based on the data coming in an ongoing big data


kind of way, and that's cool.


And that means Google helps you monetize better,


and that helps them monetize better.


And they're really happy about that.


That's my conspiracy theory.


A little bit more on that, just to give you a heads up.


It seems like the Webmaster team hasn't started communicating


much about Firebase, but they do have a division of ground


that's interesting right now.


Gary seems to be talking about PWAs and web.


Maria seems to be talking about native app


indexing and Instant Apps.


And then John is talking about AMP and HTTPS,


but no one's talking about Firebase.


And that creates a problem, because Firebase


is still really unknown to the marketers,


and the marketers are going to be the ones who push it through.


Whoops.


So that's a problem.


There are other problems, though.


Firebase can be really scary, especially when you


start reading the documentation, or when


you think about the commitment that it takes.


So this is a quote from a developer,


and it says, Google's going to have some work ahead of it,


convincing developers to depend even more on its technologies.


In February, Facebook shut down its mobile backend service


called Parse, leaving many developers scrambling.


So developers are worried that if they do all this work


to get into Firebase, that Google may eventually


abandon it, and then they've wasted their time.


And that's a risk, but I don't think it's a big risk,


because Google's put a lot behind Firebase.


But some people are also just worried


about giving everything to Google.


What if Google turns it against you?


Also a valid concern.


What I think is troubling is that for Firebase,


and what a cool option it seems like it is,


Google has a really unclear value proposition.


They're not sure what they should be pushing.


Some of them are pushing the cloud-hosted database.


Some of them are pushing messaging and ads.


And some of them are pushing analytics.


And they're not really pushing app indexing that hard


as a value proposition.


So you read the documentation, and it depends on who wrote it.


What kind of a perspective you're going to get.


It's a bit odd.


But also it's difficult to set up.


Unless you have a team of developers for each platform,


you're going to struggle.


Because one SEO really can't set it up,


because you have to download the app development


software for each of the apps, and you


have to know the website.


And you have to do all these massive downloads just


to do five minutes worth of work,


but you have to learn how to do that work in the platforms.


It's not as simple as setting up Google Analytics or Webmaster


Tools slash Search Console.


We've done it, so I know the pain.


It's not fun, but it is possible.


But the worst is the documentation.


Google's documentation here is so myopic and horrible.


So what was supposed to be like this unifying proposition


to bring everyone together so that they say kumbaya


is actually written by web developers for web developers,


Android developers by Android developers,


and iOS developers for iOS developers.


And there aren't unifying documents that say,


hey, this equals this in those two platforms and this on web.


And here's the overall investment


that you're going to need, and here are the pros and cons.


That stuff doesn't exist.


It's all developer documentation and then fluff.


There's no in between that's like,


here's what your C levels need to know,


or here's what your planning team needs to know.


So it's a risk.


So should you use it?


Maybe.


What you have to, the key takeaway


is that you should be watching it.


You should be aware of app indexing,


especially for progressive web apps.


But also you should be working on native app indexing


because those things matter before you get into Firebase.


Firebase will help get that stuff indexed,


but it won't do all the work for you.


But it does make all of that indexing more valuable


because it gives you this centralized utility


to handle acquisition, engagement, and measurement.


Everything that we're trying to do as marketers,


it puts it under one place.


And it means that you don't have to rely so heavily


on developers to make changes because you


can make changes in Firebase without being a developer.


And those go live in the cloud and then down to the apps


immediately without you having to write the code.


So once you're set up, the idea is it's much,


much easier to handle.


You also get the benefit of the cross-platform analytics


where you can say, oh, this page does way better in Android


than iOS, or this page does way better on web than Android.


And you can say, huh, I wonder why.


And you can make good decisions based on that.


Right now, if you're trying to compare web traffic with app


traffic, you can be lost because it's


all in different platforms.


And you can't necessarily trust that those metrics really


work well together.


You hope that they do.


But when it's all coming from the same platform, it does.


It's helpful.


It's useful.


It's not just disparate sets of data.


This is how Google explains it again.


I think Google does a horrible job of explaining Firebase,


especially for SEOs.


But they do have a lot of delightfully colorful graphics


like that.


I prefer this one.


Fire gives us cooked meat.


And it gives us the ability to do cool things.


So if you think about Firebase and the cloud hosting,


the main thing is it becomes your CRM, your CMS,


and your CDN.


If you don't know those words, don't worry about it.


It becomes your cloud host.


And it does all the hard work for you.


And you have to pay fewer people and set up fewer things.


That's good.


The other thing is you get this cool thing called


Remote Config, which is to say that since Firebase has all


this data in its database about all of the different platforms


and about specific users who are logged in using the app,


they can actually send out different versions


of the content to different users,


kind of like a multivariate test,


but in a very knowing and intelligent planned way


so that you can basically have any number of versions


of your app out there in the wild that are remotely


configured based on one particular user's preferences


or one set of users' preferences.


And they can co-exist.


And you don't have to submit them to the App Store.


And you can get specific data on this version of the app that's


been created for soccer moms and that version that's


been created for another group, and so on and so forth.


And you can target and target and target


so you get very specific and having, at the same time,


multiple versions of the app.


You also get the cross-device attribution,


better ad management, push messaging


that you can measure across all platforms,


the real-time database, link sharing that's


easy for your users, all this stuff.


It's awesome.


And on top of that, I think there


will be some synthetic versions of data and things


that you can do that are spun out after that.


And that's great, too.


That's it.


MozCon 2015 - 17 - Dark Search and Social—Run Rabbit Run! with Marshall Simmonds

Hello, MozCon.


Hello.


About halfway through all this, aren't we?


I was just told backstage that people that were here this morning were complaining.


Those that were hungover were complaining because the speakers were pacing too much.


Seriously.


So, quick story.


April of last year, I get a phone call and some random day in the evening, it's Rand.


And he says, hey, Geraldine and I are going to South Africa with Sarah Bird and her family.


Do you want to go?


Sure.


Let's go to South Africa.


Because why not, right? Why not?


And when Rand and I get together, we get our families together every so often,


and when we do, we're really good at not talking about work.


We're good at keeping church and state.


But there was a time when we were in South Africa that, when we weren't goofing off,


that we were talking and we were talking about the industry and something came up.


And I happened to mention that at Define, we started to see something interesting with our publishers.


We started to see direct traffic increase, and we couldn't quite be sure why.


So we went back and did some data digging and we looked back into 2013 and we thought,


okay, where is this happening? Why is this happening?


We couldn't really figure it out.


But we started to see it grow, and we saw it extending into 2014 as well.


And he stopped me and he says, that's your topic for MozCon next year.


I'm like, whoa, whoa, whoa, man.


We're all trying to have a good time here, right?


We don't even bring MozCon into this.


I mean, you can feel the anxiety already, get all nervous.


I'm like, no, I'm not speaking at MozCon, no.


He's like, you're speaking at MozCon. That's a great topic.


And he's like, okay.


He's like, you've got nine months, you'll figure it out.


And so word to the wise, if Rand calls you to go on vacation somewhere, go.


Because you're going to go somewhere awesome, but be very aware of what you talk about.


Because nine months later, your ass could be on the stage talking at MozCon about this.


So what is dark traffic?


And dark traffic, quite simply, is a URL that you can't track.


It's a URL that doesn't pass a referrer string.


And so we've got this big bucket called direct traffic.


And as we started to dig into this and unpack it, we realized that big bucket started to segment itself out into dark search, dark mobile, and dark social.


They seem to be the major contributors.


These are URLs that don't pass referrer strings.


And our analytics software, whatever it is, whether it's Google Analytics or whether it's Omniture,


if they don't get a referrer string, they throw their hands up and throw it into the direct traffic bucket.


It's basically their way of saying, I don't know what it is, it's not telling me anything, we're putting it into direct.


You deal with it. You figure it out.


And it's become a problem.


So we start to segment this traffic out more, and we start to see some facets that are starting to tell us what is going on with this traffic.


It's direct traffic. It's apps. It's browsers. It's image search. It's secure search. It's misinformation.


That's a big part of this, too.


With mobile, it's apps. It's Twitter. It's referral traffic. It's the platforms themselves.


It's the operating systems that are accountable for this.


For social, it's email. It's peer-to-peer sharing. It's sharing apps.


It's Facebook, Snapchat, etc.


Anything in a secure environment, whether you're on HipChat, if you're on Slack, if you're sharing a URL that's in a protected environment,


that referral data isn't being passed.


And so we lose track of where it comes from, and maybe even lose track of our work.


So in 2012, Alex Madrigal, who was the editor-in-chief at The Atlantic, coined this phrase, dark social.


He said, we started to go through our analytics and we started to see we weren't getting traffic,


or we weren't getting attribution, proper credit for our Facebook traffic.


And he's since moved on to be the editor-in-chief of Fusion, and he's still talking about it.


So if you're interested in digging into the history of the data, that's your guy.


So we went back over a few years, and if we think about when this all started happening, it's very early on.


We don't have a lot of answers, unfortunately.


There's not a lot of solutions to it, but this is what we see based on the data.


And this is the culmination of the nine months since Rand pointed at me and said, you're doing this.


So the goal here is to create awareness, because you're losing traffic that you did the work for.


We know that to be true. We just don't know how much.


We've got some ideas. But most importantly, if you come out of this, you want to know how to talk to your clients about it.


You absolutely need to talk to upper management about it, and you've got to be able to talk to people that don't quite get it.


Because SEOs, digital marketers, we have to be the evangelists, right? We have to explain.


We're the evangelists, we're the explainers, we're the ones that have to tell them where this traffic is going to, and accounting for it.


So for the sake of this presentation, like Cyrus was talking about, Defined Media Group has access to a majority of the Blue Chip publishers.


We work with them, we have worked with them, we have access to the data, and we compiled it for this presentation.


It's 130 sites across 68 categories with billions of referrals.


So we've got a good cross-section, and we can point in the right direction and offer a couple solutions.


But again, we know that the buckets are at least this.


If you are participating in active campaigns around search, mobile, or social, you're leaving traffic on the table.


Just that simple.


So the first bucket is dark search.


We have to talk about misinformation.


When we talk about dark search, misinformation is the number one thing that we need to start with.


Because there's no bigger mis- there's no bigger misinformer than Google.


They round up numbers, they don't tell us how many links we have, they obscure our keyword data.


I'm not going to be late at this point. This is the world we live in, we know it.


Now, the search console, it's one brush, but it doesn't paint the whole picture.


We have to triangulate with getstat, with similarweb, with semrush, and we can kind of back into the keyword data.


But it's the most egregious.


But the second one that really chaps my hide is comScore.


And I railed on them last year, and I don't miss an opportunity to rail on them again, because they are responsible for a big part of our budgets.


Our management is looking at this because they set the ad rates.


And they continue to say that Google is responsible for 64% of the market share.


What the hell?


I mean, anybody who's looked at their data, they know, they know that number is not right.


And yet they won't be transparent and tell us where they're getting this data from.


It's third-party data, it's toolbar data. Has anybody here installed the comScore toolbar?


No.


This is where they're getting their data, and they say that 64% of that is coming from Google.


And it's flatlined, basically. It is tapered off year over year.


So if your marketing manager is looking at that and saying, hey, maybe this Google run is over, that's a problem.


So we go and look at this data, and we repeatedly find that number is way different.


Pete said the M-word this morning, right?


But not necessarily, that's not necessarily a number that maybe Google doesn't want you to see.


Maybe comScore doesn't want you to see that.


But 92% of the traffic that we look at across four, we'll say five billion publishers or visits with the publishing network that we have access to, 92% of that is Google.


And good old BuzzFeed loves to talk about this, but they love to say SEO is dead.


Now, BuzzFeed is fantastic at misinformation because they're incredible at Facebook, and they're really, really good at marketing their Facebook position.


And so they do this, and they say SEO is dead, SEO is dead.


In fact, Facebook has overtaken Google, and they say this often.


But if you go look, and I'm sorry I didn't source this, this is BuzzFeed, or excuse me, this is BuzzFeed traffic from similar web.


We see that they're actually benefiting from SEO.


They benefit from search traffic because we know, search marketers, as search marketers, we know that social begets keyword data and sharing,


begets search, begets sharing, begets social.


It's a symbiotic relationship.


You have to have social, and you have to have search working together.


So when BuzzFeed is saying this, when BuzzFeed is perpetrating that Facebook has overtaken Google and Google is dead, not true.


Because we look at the referral data, and I'm not taking anything away from Facebook.


They have had a meteoric rise that we will talk about in a second.


They are doing extremely well, growing faster than probably any other platform out there.


But Google is still alive and well, and Google traffic is still a good source for traffic, and we should be paying attention to it.


In fact, if you are in any of these categories, you're killing it.


These are the most prevalent categories in search, and since January 1st of 2013, all of them have grown.


Whether it's entertainment, diet, fashion, food, breaking news, etc.


Growing. And this is in search.


Google took the unprecedented step last August of saying something very interesting.


And that is, if you move your site, if you migrate your site to a secure environment,


you're going to see, we're going to use that as a ranking signal, you're going to see a ranking boost.


SEO's lost their shit.


They couldn't get their site secure fast enough.


And, we're going to go secure, and we're just going to let the traffic roll in.


And, interestingly, nothing happened.


So, we have to think of, when it comes to this misinformation, the information that we get from these major sources,


we have to consider what their MO is.


What is the opportunity for them?


Because when they tell you to go secure, they're doing it for the right reason.


They're just saying the wrong thing.


Because there is no search benefit. We took one of the largest publishers in the world,


we helped them migrate to the secure environment.


They were already going there. They weren't going there for SEO needs or SEO purposes.


But they were going there in February.


And traffic didn't do a thing, and it still hasn't done anything.


Sure, it may be a ranking signal, but again, it's not an SEO play.


Now, to Google's credit, they picked up 80 million URLs in three days.


So, if you're going to move to a secure environment, do it for the right reasons.


But understand what the consequences are.