🤖How to in-house playable production – with Michael Jessen, Senior User Acquisition Specialist at Socialpoint🎬

Our guest today is Michael Jessen, Senior User Acquisition Specialist at Socialpoint. I’m excited for this episode because Michael’s team does something in-house that very few teams do, which is make playables. This is something that they do at significant volumes – and have seen massive performance from – and I’m thrilled to dive into their experience today.

KEY HIGHLIGHTS

💡What inspired Michael and his team to look at in-housing playables.

📄What teams and resourcing are required to in-house playables.

💻How templates and variants are defined for each game.

🛠What the most important elements to test are.

🔌What the inputs – and the outputs of the playable tool are.

📊How Michael and his team measure performance of playables – and the key metrics they track.

📉How metrics can help identify drop off points in playable.

⚠️The challenges of making in-house playables for smaller companies

✅How videos, playables, end cards and in-game experiences can be a single unified experience.

📲What the impact of in-housing playables has been.

KEY QUOTES

The shift to making playables in-house

We decided that we have a team that is developing tools for the company in house, so technical tools for different kinds of teams, and they’re creating software within the team. We decided to take and do a test and get two people involved in an in-house project for making the playables in-house.

How to create different versions of the same game

Each game has a different kind of template, and every template has different kinds of mechanics that are based on the game. We have a word game that has some swiping elements. We have Dragon City and Monster Legends, which have more click interactions on the playables and different kinds of fight mechanics. So every game has its own templates.

Managing the creation pipeline effectively

We start testing these on several networks and DSPs. Then if we see there is a success or we have a good IPM ratio (etc.), we roll out more different iterations of that. This can be changing of characters, changing colors in the call to action, or different placements within the playable.

There is a one-time set up process for compatibility

The playable itself is programmed like any other game with code. In terms of the outputs, like every network, or every DSP that we’re working with – they all have different requirements in terms of their coding and the way that the HTML file is because that’s the output file that a playable needs to have. This is something that we manually had to build as custom exporters for every partner in order to comply with their requirements. This is something you set up once.

Metrics to track for playables

For example, let’s say one playable has five interaction points before it goes to the store. We see for example, that after three interactions, we see a massive drop. From that moment, people don’t click on the ad anymore, so we can see “Okay, what’s happening,” and what’s maybe different on that third specific screen part and interaction that we see people drop out the most like a bounce rate. This can be maybe the Call to Action button is placed in a weird corner, and we put it on another corner or instead of making the color green, we make it orange. Different kinds of things that we test, and then we see that these conversion rates from one to another are actually going up again, and then we know “Okay, this was therefore the reason why people were dropping out.” Then we go to the next, and that’s how we can optimize the playable experience.

The benefit of a contiguous user experience

What we saw there is, if I put a concept A video and I put a concept B playable, the whole experience and performance is not as good as if we would put a concept A video and a concept A playable. So, if we make the whole experience from video to interactive end card in the same kind of style with the same kind of characters… then the user going through a whole process, eventually going to the App Store, and downloading the game; then, in-game, getting the same experience as they saw on the playable, that’s working best for us.

FULL TRANSCRIPT BELOW

Shamanth: I’m very excited to welcome Michael Jessen to the Mobile User Acquisition Show. Michael, welcome to the show.

Michael: You’re welcome. Thanks for having me.

Shamanth: Yeah, I’m so glad to have you, Michael, because you definitely do come very highly recommended and also because you and your team are among the few people I know that have in-housed something that very few other teams have, which is playables. And this is something I’m excited to dive into in a lot more detail and depth today just because of the enormous impact that playables can have on any app’s performance. To get started, can you tell us about the genesis of the project to in-house playables? What were some of the challenges that inspired you and your team to pursue this project to in-house your playables?

Michael: Initially, we were working with a DSP Cross Install over the last couple of months, and in working with them, we saw some playables that they produced on their end. That was actually working pretty well on their DSP, so we wanted to know more about it. We started to, first of all, work with Cross Install and then with some other vendors as well to create external playables to use them also outside of the DSP that we were using them in. When we started, this was very costly, and it was slow in terms of development.

One vendor was faster than the others obviously, but the heavy price tag was something that always came back. With every vendor, the price tag is roughly between 3 and 5k for a playable, and then you don’t even know if it’s gonna work. So what do you do then?

We decided that we have a team that is developing tools for the company in house, so technical tools for different kinds of teams, and they’re creating software within the team. We decided to take and do a test and get two people involved in an in-house project for making the playables in-house.

So that’s actually how everything started. What we wanted to do is reduce the cost to see if we can make playabels in house first of all. Then secondly, how many playables can we produce? And is that worth the trade off of the investment that we would otherwise pay the vendor?

Shamanth: I know you said you started with two people on your team. What resourcing did you have to look for to get these two people and what engineering, design or analytic skill sets did you need to look for to start building this team out?

Michael: As I said before, it was people that were already working and creating tools, so they already had the developing and programming skills. They had the background already, so that was good. We didn’t have to hire anyone externally for this because we had the knowledge already in house. But then, of course, most of the partners don’t have any guidance or external communication, so we had to build everything from scratch and assign it for each different partner.

Shamanth: I imagine one of the things that makes this project so challenging and impressive is you’re essentially building the programming of a game, a mini game, and a mini version of the game itself. When you were starting off on the playable in-house project, what were some of the first steps you took to make sure you this tool that was built out to produce playables made those that were effective for this particular game?

Michael: Yeah, so we started with one game as a trial test, so for all of the games in general, we had to make different templates. At the moment, we’re at three games that we’re actively making labels for constantly.

Each game has a different kind of template, and every template has different kinds of mechanics that are based on the game. We have a word game that has some swiping elements. We have Dragon City and Monster Legends, which have more click interactions on the playables and different kinds of fight mechanics. So every game has its own templates.

Based on that, we created everything. We work together with the art team, and the art team provides different kinds of assets in terms of backgrounds, elements, movement, and they make the whole thing alive. From a static idea and concept, they put everything to the elements and the moving parts within the playable and the mechanics to make it come alive.

Shamanth: Do you find that for one game, you have one single single template? Or, for instance, for a word game, you could have a sliding template, but you could also have a template that involves picking alphabets or letters. So do you typically test different templates against the other? How does that work?

Michael: So every game has their own core gameplay or mechanics template. However, it’s true to say if you want to try something completely different, maybe a fake playable ad, like what you see very frequently on the video side as well. Maybe you want to, for a game like Dragon City, which is a very casual game, put a match 3 element in there, then you need to add those mechanics in there. So you create a separate second template just for that. It depends a little bit on what we want to do and depends a little on the concept. I would say we have three core templates, one for each game, and then depending on the concepts that we’re developing, we’re creating a sub template and this can be interchanged between the different games as well.

Shamanth: It sounds like to create a code template, you need engineering resources. Once it is created, what happens every time you need a new playable created? What do you need to do?

Michael: If we come up with a concept together with our team, we give them the assets and explain the concept to them – basically a briefing. The art team provides the static assets, and then they basically do the rest. Usually we create a main playable, and then we create one or two iterations where people go directly to the call to action or not. We always have a main version and then two iterations already in the beginning.

There’s a lot of things possible, but it comes down to a lot of testing as well.

Shamanth: What do you find in your testing are the most important variables or parameters that you see move the needle the most?

Michael: Yeah, so it’s the placement of the call to action. As the Install button, this is something that if we placed it in the middle, on the size of something, that can make a difference. If we put the Install button, what we saw in the beginning, with the first playables that we made, we did it only in the last part of the playable. Now, we add the Install button from the beginning, so it’s always on the top, and then in the end, it will be more centralized and more focused on. This is something that really helps as well.

People know that during the whole playable they can interact with it, and if they want to install the game after seeing the playable just for two, three seconds, they can. These kinds of insights are very useful, and this is stuff that we can optimize the playables with. As well as characters, we have a lot of data already from the game, so we know what characters people are usually playing with and what kind of elements in the game they like the most. These kinds of concepts we use in order to create concepts and to optimize them as well.

Shamanth: I know you said when you do want to build a new playable, you get assets from your team – it could be characters, colors, or whatnot. What is the input for the playable tool, and what is the output? What does it look like?

Michael:

The playable itself is programmed like any other game with code. In terms of the outputs, like every network, or every DSP that we’re working with. Think of Google, Facebook, networks like Vungle and AppLovin and these like Moloco or Crossinstall for example, they all have different requirements in terms of their coding and the way that the HTML file is because that’s the output file that a playable needs to have. This is something that we manually had to build as custom exporters for every partner in order to comply with their requirements. This is something you set up once.

I work with a number of partners that support playable ads, so if we know we’re spending a decent amount of money on one partner, we would like to create the playable or would like to run the playable for these partners as well. We can create customized exports in order to fulfill these requirements and to have these playables live on the partner.

Shamanth: Something else that I understand you guys do that makes all of this very impressive is you track metrics around playable performance. Can you speak to that? What are some of the metrics you track? How does that help you roll out performance? Can you speak to all of that?

Michael: Yeah, so the playable is basically always split into several parts, so every interaction that the user can make, whether it’s a swipe, click, or drag, everything has different frames. It’s similar to when you come onto a normal e-commerce website. An e-commerce website is split up in one page that you land on and then goes to different sub pages in order to get to your checkout. A playable, in a way, is similar to that. You start on a main part, and depending on the choices that you make in the playable — whether it’s good or bad or it’s a certain decision that you made that makes you pass or fail depending on what you do in the playable. All of these metrics have some kind of CTR, we can see the bounce rate sometimes, so we see that people click.

Shamanth: That makes sense. If you have to make a completely new playable concept for testing, how would you think about that? What would that process look like?

Michael: Yeah, so we have a lot as the playables are working well for us across the board, and there’s more and more effort being put into this. The team is now also extended to three people, so we have an extra person working on this now. We have several concepts being delivered week over week with quite a quick turnaround. Usually, the art team has some brainstorm sessions with the playable guys, so they pitch the concept that they want to do. This can be something that is related to an event or something inside of the game, or it can be an offline event like the other day you have Memorial Day or Fourth of July is coming up soon.

We can make playables around certain events, so this is something that the art team is usually brainstorming about with the team. They also involve the marketing teams like myself because we see what’s working in terms of videos as well as we try to use elements from the game, the video, and also what’s trending in the market if it’s related to a live ops event or an offline event.

Shamanth: Yeah, and playables often work in conjunction with videos. Can you tell us about what the interdependence is for our listeners who are not familiar with that? And, can you also speak to what are some of the things that you have learned about how playables and videos influence each other, and how you need to think about one with respect to the other?

Michael: Yeah, so there’s two different things. On some partners and some networks, we can run playables individually, which is great. There the concept can be completely free — we can do whatever we want. We can do something very similar to the game or something completely not relevant or a fake playable. However, we saw, for example, on AppLovin or Vungle or Facebook, you all work with video together with a playable end cards or interactive end cards as they say.

It maybe sounds obvious, but we tried it with several different tests, and that’s actually the case. As well as if there is live ops events, this is something that people directly see when they open the game. If these elements are all aligned, that’s gonna get the best performance.

Shamanth: In order for the game itself to reflect what’s in the playable or the ad itself, do you have to typically coordinate or work with your product teams? What is that process like usually?

Michael: No, product is normally not so much involved in this because we are free to do on the marketing side what we want in terms of playables. Of course, it’s preferred to have an experience on the marketing side, whether it’s video or playable to be as realistic to what’s in the game just to make sure that expectations are met from the user. However, whatever drives performance is good for the product team. If that’s a fake playable, or a fake video, they’re happy with that as well, so the product is not so much involved. It’s more of a collaboration between the playable guys, the art team and the marketing people in order to drive and come up with the ideas and the execution.

Shamanth: That makes a lot of sense, Michael. As I have myself seen and experienced, playables can be very powerful, but they can also be a bit of a bottleneck for a lot of teams just because, as you expressed, it can be so hard to pull off. It’s very impressive what you guys have done. Can you speak to what the outcome has been, and what quantity of playables your team is able to put out? And what the results have been for this project?

Michael: Yeah, the team now has been doing in-house playables since the end of the year more or less. I think for each game they’re putting out three playables a month. So, I think they can produce between five and eight playables a month for all three games that we’re advertising for at the moment. It’s quite a lot, actually, and this was something that was never possible before. If you think about the cost of getting 5 to 10 playables a month, and imagine paying 5k for each playable — that’s a lot of money on a monthly basis that we’re in a way saving. The good thing is we can iterate on this really fast, we can reskin them really fast. For example, if we have a playable that’s working really well, and say tomorrow’s Christmas or St. Patrick’s Day, you can put the characters or the mechanics with a Christmas feeling. So, you can even seasonalize them based on events that are happening in the offline world. It’s been a process that, for us, has been very successful.

Therefore, we also have a new person on, and the team is slowly expanding — it’s still not a super big team. The majority of marketing efforts are going to be video ads and statics, but playables are definitely something that’s gaining more and more month over month. We see that more and more DSPs and partners are implementing it. Also, there is more and more traffic coming for playables all the time — even Facebook and Google have more inventory every month, so it’s really good to see that it’s growing. But of course, for smaller companies, it’s a little bit of a risk because it’s quite expensive, and if you don’t have someone in-house that can make these things for you or you don’t have a designated team for it, it’s very hard to test that. As a smaller company, I would say as advice, use some outsourcing agencies perhaps first and ask for one or two playables to test that. If there is a potential, I would definitely say either outsource it or get it in house if you have the capability in the team.

Shamanth: Definitely, and what you’ve described also outlines the sheer potential of playables because not only are you producing 5 to 8 playables a month or more, but you’re also able to iterate much faster, and that unlocks a lot of performance, which in turn, can be a virtuous cycle. For all of this, Michael, I’m just so impressed by everything that you guys have done and everything you’ve described. This is perhaps a good place for us to wrap up. Can you tell our listeners how they can find out more about you?

Michael: Sure, if anyone wants to know more about what we did, performance, or what kind of specific things you need to get this all started, you can reach out to me on Twitter, and you can reach out to me on LinkedIn where I’m a bit more active. Reach out to me there if you want to follow up on this, and then I’m happy to jump in any kind of topics or conversations around playables or anything else related to marketing UA.

Shamanth: Excellent. We will link to your LinkedIn and Twitter in the show notes, and of course, we’ll have transcripts and detailed notes as well for folks who want to follow up later. For now, thank you so much, Michael, for being on the Mobile User Acquisition Show.

Michael: Perfect. Thanks a lot for the invite.

A REQUEST BEFORE YOU GO

I have a very important favor to ask, which as those of you who know me know I don’t do often. If you get any pleasure or inspiration from this episode, could you PLEASE leave a review on your favorite podcasting platform – be it iTunes, Overcast, Spotify or wherever you get your podcast fix. This podcast is very much a labor of love – and each episode takes many many hours to put together. When you write a review, it will not only be a great deal of encouragement to us, but it will also support getting the word out about the Mobile User Acquisition Show.

Constructive criticism and suggestions for improvement are welcome, whether on podcasting platforms – or by email to shamanth at rocketshiphq.com. We read all reviews & I want to make this podcast better.

Thank you – and I look forward to seeing you with the next episode!