How to establish the work of the marketing department with technical specialists — the story of G5 Games
How do marketers and techies find a common language? Alexander Bezobrazov, Vice President of Marketing at G5 Games, has prepared several cases on how to make this interaction more productive.
The article is based on the report that Alexander delivered at White Nights Moscow 2019.
Alexander Bezobrazov
One of the main trends of the last dozen years can be called the increasing role of technology in marketing. Whether it’s an ordinary launch of an advertising campaign or setting up analytics, modern marketers are faced with technologies and, inevitably, with those who develop, implement and support these technologies: techies.
Such interaction sometimes reminds me of a Survival RPG, where you have to pump yourself a set of skills to survive in this cruel world, or a Hidden Object Game, where the successful completion of a level depends on your attention to detail.
I will tell you about 7 principles, the adoption of which will help to build a joint cooperation of marketers and techies. I will make a reservation, however, that the article is by no means an exhaustive list and not a “silver bullet” that solves all problems.
***
To begin with, let’s recognize that marketers and techies speak different languages, even when they talk about the same thing. It is ok. You’re not mad at a Frenchman for not understanding his language, are you?
In joint tasks, marketers, as a rule, issue a “common” request. For example: “We need GDPR adoption events and the completion of the tutorial.” Techies, on the other hand, need implementation details, and therefore for them such a task is not sufficiently specific and unprocessed. Naturally, on the one hand there is a claim “you can’t clearly say what you need“, and on the other – “you don’t even want to think a little.”
Now let’s talk about the principles and cases.
1. Communicate with the developers making the product
I have a friend who joined a new company a few years ago and decided to get to know the product teams, find out how they interact with marketing. All the teams gave an almost identical answer in essence: “We don’t know what marketing does.” And how could they know this if no one tried to convey this information to them? The marketing team was not interested in this.
Even when the marketing team became more interested in communication, situations regularly occurred that could be reduced to two phrases “What does this girl do?” and “Oh, it’s that icon girl…” Such an image appeared as a result of active interaction with the product teams of an ASO specialist who periodically asked to replace the icon in the game build after successful A/B testing.
Probably one of the most cruel theses for marketers: accept that for techies “at the start” you are always a bit of a “girl with icons”. Their respect will have to be won even if they understand business in about the same way as you do in quantum physics. You should try. Therefore, the first principle is: communicate with the developers who make the product.
2. Check the data coming to you
In free-to-play games, marketers very often, if not always, track the in-app purchase (IAP) event and the first payment event. In the case I will tell you about, the company had several games in operation in which these events were “implemented”. When a new game was released, marketing simply asked the team of this new game to implement the same events. “We need purchases and the first payment,” they said.
The nuance is that the team of a new game in that company is a new team. And for her, this is a new, previously unsolved task. Of course, she could ask the teams of other games, but she herself had not solved such a task before.
The events were implemented, the game was launched, everyone is happy … only after a while, for some reason, the readings of the Marketing Measurement Partner (MMP) and the store console on revenue begin to diverge greatly. You can’t write off a big difference on the conversion of courses or refands in the store.
They began to sort it out. It turned out that the game team sent its amount along with the first payment. The correct, honest amount, but it was a behavior different from other games that sent only the fact of the first payment, not its amount. As a result, for all games, at the first payment, a revenue event with a specific revenue and the fact of payment came, and for a new game, a revenue event with a specific revenue and a first payment event with the same revenue. Naturally, the revenue of the first payment was “duplicated”.
This case well demonstrates the situation when some did not say what they specifically needed, and others did not even want to think a little. In general, both sides did not delve into what the other side needed to do their job well. There wasn’t even a “marketers vs. techies” conflict as such. It’s just that people spoke each in their own language and thought that the other understood them, but they didn’t double–check.
Therefore, the second principle for a marketer is: check the data that comes to you. The technician can check whether the data he sent is coming, but whether he sent the data is the question for the task statement.
3. Document the implementation done for you
In the previous case, of course, the techies were also “good”. What was their mistake? That they created an “undocumented feature” of the event implementation. Another case with the same event of the first payment will help me demonstrate the consequences of poor work with documentation.
The User Acquisition team, with which my friend worked, noticed that the conversion to payers for organic traffic exceeds that for paid traffic in some countries. It was insignificant, but it seemed “counter-intuitive” to them: firstly, Paid UA was “super-targeted” due to hard payback KPIs; secondly, organic conversion had to be “pressed” by features, traffic from which, although it raises total revenue, but on average it is converted worse ordinary organic matter.
When studying the data in search of fraud, we found that in those countries where the conversion of organics into payers was confusing, there was an “impossible metric”: the number of “first payment” events exceeded the number of unique installations that sent at least one IAP event.
For some time, even the game team could not explain why this was happening: the employee involved in the implementation had quit. At the same time, everyone was sure that the event was sent at the right moment, with the correct metrics – it was checked. There were suggestions about some new, unknown fraud or that “this is a problem on the other side.” In this case, the “other side” was the MMP.
What really happened? The game “set”, whether it was the first payment or not, on its own data and sent the event to MMP. The problem is that in some cases, MMP and the game’s own server interpreted the “uniqueness” of the installation differently: for some it was a new installation and a new user, and for others it was an old user who reinstalled the game.
If not only the task, but also the actual implementation of the event had been correctly described at the time of the MMP implementation in terms understandable to the marketer, this discrepancy could have been avoided. But the game team did not make such documentation – they simply implemented what they were asked for, in the form they understood it, and forgot about the “marketing code that does not affect the game.”
This leads us to the third principle: document the implementation done for you. If something was done for you and it seemed to you that everything was working, make sure that you have documentation. No documentation? Then communicate with the developers, figure it out and write yourself. Otherwise, in six months it will turn out that no one knows how it works at all.
4. Fix the agreements you have reached
When you have one game and you are all locally located in the same city, it is easier to interact than with several projects and in a distributed team. Especially when marketing is “isolated” from the product.
In this case, the marketing team was engaged in App Store Optimization of applications that were developed by development teams that were independent of each other in terms of resources. For ASO, it is critically important to know the release dates of builds in stores, at least in order to plan your work in relation to the preparation of meta-data for the App Store, where you can’t change anything without a build. Moreover, to prepare these meta-data, the ASO specialist needed to prepare creatives with designers and translations of texts with the localization team. These teams also had their own plans and resource constraints, they, like marketing, were not tied to any one game.
Marketing has repeatedly asked product teams to warn in advance about release dates, not to move these dates “quietly” and not to make several releases in one week. So far, these were verbal agreements – they worked every other time and, it feels like, rather by accident. This is an important lesson that can be expressed with the phrase: fix the agreements you have reached.
Over time, the marketing and product teams have agreed that each new release project includes a separate task for publishing builds with subtasks by platform. Surprisingly, there were no such tasks before. The project of a new release was completed with a testing phase, and the publication of builds was done by a project manager or a release engineer “without a separate task”.
After the individual tasks appeared, information on the changes became available to marketing. If something changes or “overlaps” between several games, it is immediately visible, not post factum; potential “overlays” of games, marketing, designers and localizers are immediately visible.
5. Read the technical documentation available to you
This summer, I spoke in detail at White Nights in St. Petersburg about the experience of implementing advertising monetization in “adult” projects.
Among other things, talking about the metrics of advertising monetization, I mentioned that it is possible to monitor the ads that advertisers show in the game. This is very useful for a number of reasons: you can see which creatives work well for your audience, and you can take successful concepts for your own creatives; you can see the appearance of any new powerful advertising campaigns and situations when users are shown inappropriate advertising.
One of the ways to do this is by using a special service, the SDK of which is embedded in the application. If you believe the service, the implementation should be simple: just add one line of code to the application, then everything will track itself.
It would seem that what is difficult? You make an account, give developers links to documentation, SDK and account key + access to it – and let’s go. This is ideal. My friend was solving a similar problem, and something went wrong with him. The implementation took a month and a half. A month and a half to add one line. Agree, it will be a bit much somehow?
I won’t bore you with complicated technical details. The phrase about “add one line” played a cruel joke with both marketers and developers. The SDK documentation was quite large, but no one read it outside of the page with one line of code, neither marketers nor techies. Just added a line with the right key. But it didn’t start.
And this is also an important lesson for a marketer: read the technical documentation that is available to you. Even if you don’t understand 100%, then, at least, you will be able to express concern to colleagues that everything is not as simple as the partner promises.
6. Accept the limitations created by technology
I will demonstrate this principle in the following case: introducing advertising monetization, the company in which my friend worked decided to follow the path of developing in-house mediation. It was the decision of the owner, and one of the goals was transparency and full control over the number of impressions as one of the metrics that affect advertising revenue.
Obviously, the marketing department, which was the initiator of the introduction of advertising monetization, had a great desire to use the flexibility that its own development gives to the maximum. Together with the project managers of the games, they compiled the TOR, described what and how they want to track, and together with the analytics team developed a data storage scheme. In general, we approached this project as responsibly as possible and, we can safely say, without any typical “shoals” for interaction between marketing techies.
Unfortunately, the project manager changed at one of the games during the project period, and the release came out without a full set of statistics. Other games came out without any problems with collecting statistics. So imagine my friend’s bewilderment when the first game confronted him with the fact that it was impossible to collect statistics.
The whole problem was in one metric – in clicks. Marketing wanted to see how many times users click on in-game ads. There are so-called “execution threads” in applications. In one application, there was one main stream for everything, in the other, the streams of the game and advertising were separated. It is because of this implementation feature that the game could not track user clicks on ads. Was it possible to fix it? Yes, but it would require a very long and costly reworking of the game code. Therefore, no matter how much marketing wanted, the click track had to be abandoned. At least in his own mediation.
Hence the following rule: accept the limitations created by technology.
7. Accept the changes taking place in the team
Oddly enough, but people are not tied to a company or any product. Sometimes, within the framework of projects, it can even be shock therapy, but this is a fact.
A friend of mine promoted a game in which 5 project managers and 3 producers were replaced in a year and a half. 18 months, 8 different “key people” with whom it is necessary to build relationships, reach agreements. Naturally, this situation negatively affected both the product and the team.
What should you do if you find yourself in such a situation? In fact, you need a super-pumping of anti-crisis management skills: you negotiated with one person, did something with the second, and release it “into the world” with the third. And each of them has their own vision of the situation, their own introductions from their own supervisor, their own sense of their “security” and their own propensity to risk taking into account the situation.
Unfortunately, there will be no “silver bullet” here. I can recommend marketers in such a situation to do what my friend did: accept the changes taking place in the team.
Yes, people come and go. Yes, someone’s departure can significantly complicate your work when promoting a product: you have already agreed on everything with the previous person, and the new one does not want to hear about these agreements. It’s a shame, it’s a shame, but if you consider yourself a pro, then you need to go and negotiate with new people.
Instead of a conclusion
When I look at the principles above, especially formulated in such a slightly pretentious way, I wonder: is it more about techies or marketers? It seems to me that this is more about yourself. Do you want to be a “girl with icons” and not understand what language techies speak to you? Do you want to tell me that they don’t know how to communicate? Maybe you should start with yourself: read the documentation, talk to people, in general, pump up your technical skills so that interaction with technicians, if it resembles a role-playing game, is more like a Puzzle RPG than a Survival RPG.
