My Life In the Bush of Platforms

Session facilitator(s): Matt Dennewitz, Michael Donohoe, Luigi Ray-Montanez

Day & Time: Thursday, 3-4:15pm

Room: Thomas Swain

MATT: Hi, welcome to my life in the bush of platforms. My name is Matt. Michael, Luigi. We’re going to talk to you about our experience with the recent explosion of platforms in the last couple of years. First, a little bit about us, my name is Matt. I’m the engineering director at Condé Nast for Wired and pitchfork. If you want to talk later, I have some interests up there. Python, baseball, music and things like that.

MICHAEL: I’m currently working at herst newspapers, that covers San Francisco Chronicle, Houston Chronicle, 12 papers, San Antonio. Previously worked at the New Yorker, working on the paywall. And prior to that, Quartz and prior to that, the New York Times. Basically what we are trying to say is we’ve kind of seen a range of changes across time and hopefully you’ll be able to speak to that.

LUIGI: Hi, I’m Luigi, I work at Vox Media. I do not have my fancy title, unlike my colleagues here, I’m just an engineer. Previously I worked for Upworthy and the Sloan Foundation and I also have used some kind of Code for America on the side. So ask me about that. And that’s who we are. Our Twitter up there. If you want to follow us. So we want to talk about how organizations have adapted our platforms to modern content distribution problems. What that means is we used to have very simple setups, so we want to take a look at the history of it and look at how those rules are changing today. And then we’re going to split everybody into groups and we’ve got a couple of scenarios we want to run through. So in groups you’ll be looking at – you’ll be pretending you’re our interested organization and you’ll adopting a new platform, how do you integrate it and how do you. [inaudible] and we want to about new ideas about how to jump onto emerging platforms. If you’ve done this, in your groups please be very vocal about it, definitely help people think about these problems, but we also want you to know that everyone is thinking about this right now. So quick history lesson, how did we get into this mess? In the beginning, we had websites. Websites were very easy, you had a couple of app servers, maybe if you were lucky enough, you got a cache, people came to your websites and that was the sum of distribution. Maybe you also had a printed division. That was nice, that was easy. People come, CMSs, stored literally whatever was put in. If you pull that HTML back out, drop it on the page, you have the web page. Then came RSS readers. So we had these websites and people decided they didn’t want to read our websites anymore, great. We had a simple solution for that, you could aggregate websites, you could remix them, you had full access to them. People still visited our websites, people still took the feeds, people still read our content. We thought that was all we needed for distribution. RSS is really convenient, very easy to render and parse. It wasn’t a big rift on our servers. Anybody remember FeedBurner? Most of you are too young. It was fairly straightforward, if a little painful to monetize via inserting ads. This was the first step towards APIs. And then came the reader apps. How many folks in here worked for organizations that had reader apps? Wow, all right. Maybe they didn’t. The reader apps could take your RSS, and spit it back out for you, but a lot of times you had to put in a lot more information. When pitchfork for example introduced a reader app. You realized that it wouldn’t get you very far when you had things like reviews. RSS doesn’t fit that. We also found ourselves adding all sorts of like single-purpose feeds for distribution channels. New variants of RSS. You had RSS for let’s say. – let’s say Sirius radio wants to read the content but they didn’t want the show inside of their cars. Now you’ve got something that’s not quite XML, not quite RSS, that gets pretty nasty pretty quickly. You get a lot of debt out of that. So we tried to figure out how to serve data and keep it sane and well managed. They came APIs, we figured out here’s all the information we need, here’s how we can put it out, here’s how it make it accessible. But the upside here is that we’ve centralized all of our data access patterns, meaning that any partner that wants to come to us and take our data, or if people want do this internally is going to get the same information the same way, time after time. This is nice, because we can resenter everything that we need to the client. So we can still define the rules of engagement and consumption of our content. we don’t have awkward retrofitting of other feeds: And we began to rework our own platforms to read and write using these APIs. Just like your websites, your mobile apps, your search engines, your feeds, anything like that.

at Condé Nast, we had a program called Copilot.

I’m just wearing the t-shirt!

[laughter]

MATT: Everyone just consumes those APIs, it’s actually really nice. Again everyone knows what they’re going to get, everyone knows where to get it. Just don’t ask questions you don’t know the answer to. So now we’ve solved for distributing our content. We think we’re actually platform agnostic. But then, the real platforms came. This was the hard one. So you get things like AMP, Facebook Instant Articles, Snapchat, a lot of people telling you what to do with your content. Although we can feed out in a number of ways, we still had HTML. That’s a pretty big problem, because they all have subsets of HTML or some other like markup logic that they want you to use. When you’re pumping HTML out to them you have to start now decomposing just to publish on these platforms that are supposed to be more simple.

So our timeless solution is to quit storing HTML in the database. Debt finally caught up with us. Our solution is to quit storing HTML in the database. You have to structure the stuff. So at Condé Nast, we have markdowns, instead of HTML. Our writers, when you’re publishing with they’re just working with Markdown in the CMS. That’s what’s stored and on the way out, we can recompose that the way we need to. The upshot is that we separate the text from the layout. You can do anything you want with the text and reshape it for a different platform, because you simply know what needs to be remarked up elsewhere.

You get a token stream. I’ll show you what a token stream is in a couple of slides. This is what mark down looked like. This is what our editors would look like. Putting aside what our editors feel about mark down, whatever you feel like markdown, it’s actually fairly straightforward as far as marking up text. It’s pretty easy to render that in HTML.

MICHAEL: It’s beautiful.

MATT: Isn’t it? Yeah. So very simple to take that, turn it into this. Then if you need to render it for AMP. Do the same thing. All because you have a token stream like this, you can reiterate and render them the way you want to. We have these new distribution channels that we can cater to. We’ve solved the problem of distribution by reorienting our platform. And we also have decoupled our content from its presentation. So now I’ll pass it over to Luigi, who’s going to tell us how Vox has been handling this.

LUIGI: Thank you, Matt. So Matt kind of went on talks about how he went toward the present and I will talk a little bit more about the present and maybe into the near future. So at Vox Media, we are eight brands. We have all sorts of different audiences from sports to general news with box to lifestyle with Eater and Curbed. So with us we try to be on all the platforms that are out there. This is kind of a current snapshot of where we are with the bigger, larger platforms, I would say are Google AMP, Facebook Instant Articles. Those also require us to translate our content into their formats. Apple News and Google Newsstand are really focused on mobile. And the mobile experience. FlipBoard is sort of the mad earn RSS reader and we have a bunch of video platforms, Instagram, Snapchat and YouTube. It really is all about mobile. We are not really yet focused on some of the things that were maybe a big deal, like a year ago, because people thought they were kind of up and coming. With AI, with chatbots, I’m guilty of writing a chatbot last year. Smart speakers like Alexa, VR, or AR things that you need glasses to view. And definitely not worth watching. We’ll see about that. So it’s definitely about the mobile experience. It’s about people really liking to you content on the phones. So I’m going to talk a little bit about the – sort of we can call this the big three. AMP, Apple News and Facebook Instant Articles.

The first thing when we did when onboarding our eight brands onto these platforms is to mitigate risks and we really tried to start simple and one way we can do that for your organization currently is use something off the shelf. So if you want to get on AMP because Google search is important for your organization, then you could use something off the shelf, like the Mercury Converter which is from a tech firm called post light. If you are already on Facebook Instant Articles, Facebook has introduced an instant article to AMP converter that you could try out or if you just wanted to be on Apple News, it does accept RSS feeds. So if your feed is RSS, and I hope it is, then that might be good enough for your purpose. So you can start off simple and then you can start small. So by that, I mean pick a subset of your organize’s content. For Vox Media, we have eight brands so it kind of naturally fall in that we will pick a couple brands to start off with. Will we also picked just one of our content types, the standard article, instead of some of our other more rich content types that we have. We then chose some measurable goals, so if you’re going to go into the world of platforms, you need to know what you’re getting into and you need to know what you expect. So is it around revenue? Is it around growth? Is it around reach? And then obviously evaluate the performance and make sure you’re able to evaluate that performance, watch the data as it comes in and proceed in small steps. Don’t fully commit to a platform until you’re really sure that you should. So at Vox, we started this path about two years ago, and about a year and a half ago, this is a snapshot of where we were, so on AMP, we had three of our platforms – excuse me, three of our brands. Same thing with Apple News, and with Facebook Instant Articles, we had two brands on it.

And then we chose our goals: So for Vox Media, our company leadership makes things really easy for us. We really focused on just two of our top-line goals, which are traffic, so are we increasing traffic because of this platform that we joined? And revenue? Are we able to monetize this traffic through display ads is how we do it, and is it more successful than it would be otherwise.

So nows, after evaluating that, we have decided to expand.

So this is a snapshot of where we are today. And we have all eight of our brands on AMP. We have six of our eight on Apple News, and we will probably make that the full eight soon, but have capped Facebook Instant Articles at where we started with two. On AMP we support our standard articles, but also features, and our streams, which are collections of stories.

So the second thing we’ve gotten – kind of learned from this process, and I think Matt alluded to this a little bit with his section earlier, is that when you start to really support these platforms, you need to think about converting that poorly structured content into well structured data. So this is what your content looks like when your editors use it and put it into the CMS. It is probably messy HTML. And what we did, here’s our diagram, our architectural diagram, so we started with the full HTML from our CMS. We converted that to a Ruby data structure, because we use Rails for our primary CMS and based on that Ruby data structure, which was really just Ruby hash, which is close to JavaScript or Python, we put our output content into one of three formats. So there are some benefits to this. Because we started with the fully rendered HTML from the CMS, it was separated from the rest of our CMS, so it really kind of lived on its own as its own pipeline. So this let the main CMS team do its thing, not really worry about the platforms and we have a separate pipeline that kind of dealt with all the details about what it means to convert and then render to the separate platforms.

So with that rendering process that all started with that trusted starting point. So that Ruby data structure was the same exact Ruby data structure were the same for AMP, and etc. So there were some drawbacks. The first was: Complex content. If we had a review article where a brand like Vox.com might review movies, another brand like the Verge might review the new iPhone, those review score cards are pretty distinct. For Vox it’s a star system, one through five stars. For The Verge it’s a 1 through 10 point system and parsing that and making it uniform is complex. It takes a lot of effort and it also really duplicated effort, so because the CMS is rendering the whole thing first, we then parse that rendered CMS and then we rerender as an AMP page or as a Facebook instant article. It’s just a lot of duplicated work.

So what we’re kind of moving towards is really thinking about this well structured data and Matt talked about markdown. Here let’s say we start at the text editor in the CMS. So you have this one sentence. That looks like this on the HTML side. But you can also really think of it as a data structure of – here it’s in JSON of tags, children of those tags, types of content. You can really think of it as a very highly structured data.

And when you do this, you get the benefit of having sort of an easier way to output that data in any format you want. You can – if you store it as that formatted JSON, you can output it right back to the editor as your editorial site uses it, you can output it to your canonical pages and then to any other platforms if you want to. So that’s where we’re moving to. And briefly really the two takeaways we’ve had are mitigating risk by starting small, starting simple, measuring your goals, and then really think about what it will take to migrate your content from messy HTML to well structured data as quickly as possible, as early in the publishing pipeline as we can. So with that we’re going to hand off to Michael who is going to talk about a specific use case that eh went through with Google News stand.

MICHAEL: Has anybody heard of Google? Show of hands, maybe? One, two? OK. Yeah, so my two colleagues here have actually spoken on a very structure of the data, how it happens. My part of this is actually a little bit smaller. We’re going to focus on, well, Google Newsstand, very RSS-heavy so we’re going to use regular expressions to parse RSS. No. No we’re not going to talk about that. I’m going to talk about something else.

[laughter]

On the flip side of things, you know, we also are dealing with a lot of different platforms that have a lot of different incarnations that are moving quite quickly. Part of the problem and part of the solution of having to structure all of your data and go back and go back to HTML is you’ve got to keep up some sort of velocity and in terms of the pain points, not to turn this no a therapy session. Google newsstand went through a number of different incarnations. It’s Google Play Newsstand officially. It used to be Google currents and then producer and that likewise went through a lot of different name changes and you know, even if you look for it right now, it still doesn’t seem quite consistent. But it’s there and it actually has very high readership. As a platform it’s a pretty good one to be on but it gets complicated and you need to know that we have Facebook or others, like they make mistakes, and they think everything is very simple and sometimes it can be, but in publishing, we’ve kind of found out that that’s not the case.

So this is a little bit of a shorter talk. Wee want to move on to the practical exercise. But some kind of, you know, like pitfalls and things to be aware of. So I’m with Hearst right now and I’m not there long enough to do like one of these platform migrations so I want to focus on a couple of examples at the New Yorker that we faced when we were kind of embracing Google Newsstand. Part of the wind is it’s very heavy on RSS. We know that, we’ve been using it for a long time, but they really wanted to kind of go a little bit further than that, so there’s like a lot of media content. There was a lot of – is that the same slide?

There’s a lot of things that we didn’t actually realize until we got closer to launch. Like you’ll notice in the bottom right corner, Beyonce was in there. There was kind of a mild panic attack of why is that showing up? We didn’t tag the article this way. It’s not using the New Yorker taxonomy. Like, we have a library staff that tags and categorizes and slices and dices everything. So there’s things on the surface that some publications will care, some won’t. We also found out – actually, I just spoke ahead of my own slide.

We also discovered that the New Yorker has poetry, which Google did not actually understand. I don’t know if any of your publications deal with poetry?

And this is just a very slim example, but that spacing, that spacing is intentional, and there’s indentations on the left, on the right, there are words that are put off like five new lines, center the word, three more new lines, like left indent the next sentence and that is how the poet actually wrote it, submitted and how it was published and we have a hard enough time on the website representing that with a lot of fidelity. Well, I’m not there anymore, the New Yorker has a makeup department that literally make up the issue each week and one of the things that you see is they have that inline CSS so that they can on a poem by poem basis make actually tweaks, so when we got to Google Newsstand, they were unable to handle it. I mean they tried, and I think eventually they got it to work, but this was one of the things that no one was expecting this as a complication, and so I – I haven’t even spoken to how this works in Facebook and some articles in AMP. I mean these things don’t typically appear there or AMP might use it in Facebook. It is one of those issues. Again, a very simple example is slide shows or images with captions. The New Yorker also has images with captions but some of those are also cartoons. It’s one of the things that they’re kind of famous for.

[laughter]

And again, in the original New Yorker, use implementation, these things were not aligned, or they weren’t centered, and again, to a developer on a platform team for a large, kind of company, like Google, this is not something that they’re naturally thinking about when they’re building out a specification. So again, kind of custom work, research, design, custom category. Won’t go into that. In the early days if you wanted to monetize a video, unless you had a Google to YouTube account, you couldn’t do that. It’s expanded since then, I think. I’m sure you also would have issues with drop caps, chapter headings, we use block quotes, small tags, things that would have required a little bit of extra work out of the gate.

And so I guess what I’m trying to say to you is again, these things are hard. When editorial systems and publishing meet, you know, proprietary platforms, so you’re doing this for Google Newsstand, do you have to do this for Facebook Instant Articles? What do you do with say a Snapchat? It gets really complicated. Google has no way of marking satire separate from actual news content. I think we’re living in an era where that is especially important in the last year. Like Borowitz, he already gets confused with fake news and you could say, well, just take that out, well, the New Yorker does run satirical content from time to time, if they take it out of Google Newsstand, that’s fine, but then you can’t count subscriber into larger subscription issues. It gets into really weird issues like that. So again, these platforms, there’s well-meaning people but they don’t have the bigger picture that a lot of us have to deal with on a day-to-day basis. With that, I want to be very specific in calling out that the team that we worked with were very responsive with all of these and it took a lot of help in order to get through that. But the New Yorker is also a very large brand in this world and had the luxury of being able to have that direct relationship. There are teams, there are publications out there that would have similar issues and just may or may not be able to kind of get the same traction in getting those issues addressed and this is a problem we all faced in general as we go forward. We kind of rely on the larger players to call out features that don’t exist that then kind of trickle down to everyone else and that’s really hard sometimes. Especially when something is really meaningful, really impactful.

Why did I put the size big fish thing as the last slide?

MATT: We put it in yesterday.

MICHAEL: Did that seem obvious? Was that going to remind us of something? All right.

[laughter]

I guess that probably means I’m coming to a close here. Yes!

[laughter]

To sum up, you know, platforms like we’ve had to like go back into our archives, we’ve had to like reengineer and parse HTML to make it out to data structures, we’ve gotten that far, we’ve gone to great lengths with Copilot and chorus and other things. With that, I will hand over the mic. Luge awesome, so as a follow-up, because you know, this is a thing, we will be hosting a cry session tomorrow as an office hour at 3:30. I think it’s in the main room, where we can talk about very specific things. Specific to your organizations and specific to the platforms that are out there right now. But before we do that tomorrow, we do have a group exercise that we would like to lead you all through. Cool, so you can pull this up on your computers at our SRCCON etherpad. It’s bit.ly/SRCCON/platforms if you want to get to it quickly or it’s on the schedule on SRCCON.org and link to there. And from there, we have this worksheet. So for this exercise we’re going to simulate the decisionmaking process for getting onto one of these platforms, or actually there are two. I go there at the top of the screen. So the idea is you will break out, let’s just say, into your current groups, into your current tables. You will pick a persona of a media organization. So it can be something like a large newspaper in the writeup. I chose the Daily Planet, the fictional Superman newspaper. It’s a big metropolitan newspaper, probably well funded, has a lot of prestige and tries to be everywhere. It does a really good job at that. You can also take the persona of a startup of an online media startup, Slug Line, if you are familiar with a certain Netflix show, that is where I got that from. So highly innovative, VC-funded, has great reporters. Zoe Barnes who sends out an influential daily newsletter. I hope she’s around for a long time. Customized by a consulting firm, there’s some integration with AMP and Apple news, and then the third persona is a small local news outlet so you can be the Springfield channel 6 news with Kent Brockman, and there’s some of the constraints of being a local news outlet there. You have an off the shelf CMS, you have a small team. You have webmasters, and you have some RSS capabilities, but not too much beyond that. Maybe you have AMP support, but you use the company relay media to provide that. And then the exercise will be think through some new platforms, so these are fictional. I have no idea if these are actually real or in any stage of development, but the first platform is a Samsung app, it’s very similar to Apple News, so Samsung Galaxy phones are of a higher markets share than Apple iPhones, so maybe Samsung will want to make their own platform or their own news app, it’s called 24/7. So as you can create a channel for your article or video content, you can feature your content through a pitch process with Samsung editorial staff. This is similar to how things work right now with Apple News, you can also have video content, because these are phone-based apps. Vertical video is going to be favored. You can also send push notification, your editorial team can send push notifications to Samsung users if they subscribe to your channel, so very much potential for driving traffic there.

And technically, Samsung will ingest your content through RSS, and they also will have a web portal for pitching content and sending the push notifications. So your breakout group will answer these questions about the user base, about vertical video. Your organization has the capability to participate in the pitch process. Does your organization – or how does your organization mitigate risk? What more do you need to know about the platform? What else was not described in that very short summary? And then what is your final determination and maybe what will reach or will have to happen for your organization to reach the conclusion. So you’ll do that for the first example, Samsung 24/7.

And then the next example is a video-based one. Netflix newscast. So Netflix has this idea to launch a new quote-unquote show that features dynamic customized content from media organization, partner outlets like yours. So it’s dynamically generated. It’s called Newscast, it stitches together video clips based on the user’s subscriptions. Their stated preferences and past viewing behavior because it’s Netflix and they’re using algorithms for everything.

So Netflix is looking for timely, high-quality content, covering national and local niche topics and the clips are anywhere from 1 to 10 minutes. So Netflix will pay you for your content based on the viewership time. Much like Spotify pays – and audiencewise there are 52 million Netflix users in the US and 100 million worldwide. So technically this is going to be requiring a REST API to be able to post the video clips and metadata like titles and transcripts. Users can subscribe to it, you can find categories in channels and videos, like tags, users can subscribe to them through a preferences screen and after a Newscast shows a video clip, the next clip will be automatically queued just like if you use Netflix these days, your next – if you’re watching a show, the next show in the series will show next. What conditions must be present for your organization to support this platform? How well does the format align with your editorial strategy? And again, how do you mitigate risk? What more do you need to know? And a final determination about it. So, we’re going to break out. And you can just stay at the table and have a group discussion. The first thing your group needs to do is to figure out your persona for your organization. You can use one of these three. One of these three personas, or you can use a real company, maybe, at one of your – that is represented at one of your tables. It’s really up to you. Fill – read through this description again, fill out – have a transcriber fill out your answers to the questions, and then with about 15 minutes or so to go, we’ll stop and hear back about some of the responses that you all came up with. Any questions before we break?

Awesome. Cool. Go to it!

MATT: We’ll be walking around, so if you have any questions or ideas …

[group activity]

MATT: Alrighty. Start picking people that you want to send up to present. We’ll use the next 15 minutes to do that.

LUIGI: All right, we’re going to start doing the recaps. We’re going to start doing recaps soon. So start thinking about who will kind of present for your – or who will talk about – for each group, and the question just will be one: Which persona do you take? Which platform did you take, if you just chose one? And what were – what was your overall conclusion, and what were the sort of hard, sticky things that you have to contend with in your discussions? Who wants to go first?

MICHAEL: Bonus points if you’ve actually talked, saying this is an existing editorial workflow that we could repurpose or actually that we would have to do X, Y, and Z.

LUIGI: Yeah, will you have to hire in order to make this work or anything like that. Who wants to go first with a recap? I’m going to have to pick on someone!

AUDIENCE: Do I have to us use the mic or can I just talk really loud?

LUIGI: You can project.

AUDIENCE: OK, so we picked the Daily Planet. OK – I’m going to talk in the microphone. We chose the Daily Planet and the platform that we were talking through with the Samsung 24/7, AKA Apple News, some of the things that we talked about is while it’s not our target audience user base, it ultimately was a low risk, because we had some existing things that we could put into motion on it. Either a subset of our – and the tricky things we talked through and things that had the most questions was what do you need to know more about the platform? We talked about what measurements did they provide? How do they report back to us? What is the actual business model and do we make money off of them? And ultimately we said that although we would support it, if we were to go to the opposite way, we would see negative effects, i.e., loss of money.

LUIGI: Next time?

AUDIENCE: Yeah, we also chose the Daily Planet, AKA Washington Post, and we wondered how does this match up with our model who the stuff is written for. So the sharing thing again, we had a lot of questions about how will it make enough money? How will we know when it’s making enough money? What kind of analytics will we get back about who is reading our stuff? And also in terms of pitching, we wanted to know, can it just be keywords or does somebody every day have to write a pitch and does the person who writes a pitch have to be an editor or can it be other staff and how much time is it going to take for our staff. So those are questions that we had about that.

LUIGI: Alms.

AUDIENCE: So we picked Slug line and Netflix. And Slug Line live video channel. And primarily it’s not revenue focused but reach focus and the 100 million subscribers on Netflix was a draw. You know, one of the things – the other thing with Slug line is it is a WordPress site that is maintained by an outside firm, so one of the other challenges we saw is that we need to engage in a firm to build it, but then also project manage it internally, or kind of find like a – what do you call it? Oh, yeah, kind of pairing possible existing engineers with like an outside firm, kind of like a contractor on retainer. We jumped to kind of one of the things that stuck out for us is one of the questions we’d have on the platform, is what kind of metrics we would get back. So while there’s the revenue share of it, the – our, you know, biggest interest would be in how many people we’re reaching, so – and that kind of also then fem into like why we’d say no, is if there was little or no data.

LUIGI: Awesome. Next?

AUDIENCE: We accidentally all sat together. We all work at Condé Nast, so we used the persona of Condé Nast. We looked at both. For Samsung we sort of very quickly reached the conclusion that we can’t say yes to this without more information on monetization. Nothing was really given in the prompt and so we said, there’s no answer without that. That’s the most important question. For Netflix, we’re really interested in the audience for sure. We already have in-house video, where we’re meeting most of the sort of prerequisites, so there’s a question about sort of monetization and cost modeling. Mostly about the monetization side, because it’s kind of a one-time engineering effort to be able to push the data into the system. We were curious about rights assignment. That would be a fairly big deal. We do think acknowledges editorial strategy and it seems fairly low-risk to us to at least give it a shot. The one that we sort of identified is if we’re stringing together our video contents, especially short video content, with other teams’ video content, are we use that go reach to build any brand affinity? Are we driving any new relationship or engagement with the users? And that was a big question and the thing that we wanted to experiment with before we committed to it long-term.

LUIGI: Awesome. Any other teams? I think this side.

AUDIENCE: So we did the channel 6 news with Ken Brockman, which I’m kind of surprised everybody didn’t do that one, actually, and I’ll do the Samsung 24/7. We decided to go for it even we’re kind after small local newspaper, because we thought our skinny newspaper, Ken Brockman deal had more appeal. We only have the two webmasters and they don’t know how to edit video, but they sure do know how to pitch the stories. We had a lot of questions about the platform, like what data do we get back? How are we going to monetize this? Does the mayor have a Samsung phone? How are they selected? Is anybody going to see our content after we put it out there and what’s the revenue stream? So ultimately we do want do it but we want to make sure we can get some money out of this.

So Netflix, same thing, we want to reach all audiences, we’re not too discerning about that. The big thing with Netflix with us kind of to break it down, is again, this newspaper, Ken Brockman thing, is kind of perfect for their format. We don’t have an API. So ultimately we were a little too risk averse and decided not to go for it.

LUIGI: Any groups here? OK.

AUDIENCE: We were Slug Line. And we decided that we would go with Samsung 24/7. We did have questions about the platform. A couple that people mentioned, but one being how did this used for driving people back to our own site and they have modules for allowing us to sign up for newsletters and build up a relationship with that. We also had questions about analytics and monetization. Could we integrate with our analytics or was it a separate system? And that this processes were already engaged on Facebook and Twitter, so we had questions about was that something that our editors were like pushing stuff out to those platforms could do, without getting overloaded or was that going to require more work and how to make judgments about what to show and what not to show.

LUIGI: Excellent. Any more groups? Please do go to the etherpad, and if your group transcribes the answers into a Google doc, please put it at the bottom. Make that Google doc shareable and put the URL at the bottom of it. Any other groups that ever want to share?

AUDIENCE: Just an observation. I don’t think I heard anybody mention digital subscriptions in sort of the consumer side of monetization. Maybe not relevant for channel 6, but I’ve got to assume that the Daily Planet is – well it is, it says primarily subscription based. When do you worry about the driving subscriptions or cannibalizing subscriptions with alternative platforms? Any thoughts?

LUIGI: Any thoughts? Yeah.

AUDIENCE: That came up in our discussion a little bit and Eric, I’m sure you can guess why, because we know each other, but yeah, I mean that was our biggest, at least my biggest question with regards to like, what do you need to know more about. Like there’s nothing in there – and ads came up too, but like to me the most important thing is driving more subscriptions and if people who read our articles this way are hitting readers, then this is useless to us as the Daily Planet and as the Seattle Times where I actually work.

LUIGI: Awesome. Any other responses to that? Any more groups?

AUDIENCE: I think there are several variables. And also, what is the pay of your audience. If your audience is very willing to pay, the subscription rate can be very high, I think it is OK to set up a paywall and give fewer free articles, but if the subscription fee is low and CVM is okay, and then people are very reluctant to pay, you would consider to keep everything as it is.

LUIGI: Thank you. Any more groups to share?

All right, so, thank you all for engaging in that exercise. I hope it got you thinking, and made you feel things.

[laughter]

So we do have a – our cry session tomorrow at 3:30 in the main big room there with the beautiful high ceilings. And please do add your stuff to this etherpad if you haven’t yet. Any other parting thoughts, gentlemen?

MATT: Yeah, I’ll say thanks to you for putting together the activity. One last thing that I always like to ask for a volunteer – please get a last-minute volunteer, maybe from this table? Everyone give James a hand.

[applause]

MATT: Thanks for coming up, dude.

[laughter]