如何建立市场部与技术专家之间的合作——G5 Games 亲述
作为市场营销人员和技术人员，如何找到共通语言？G5 Games的营销副总裁亚历山大·别佐布拉佐夫准备了几个案例，以使这种互动更加高效。
本文基于亚历山大在2019年白夜莫斯科大会上的报告撰写。
亚历山大·别佐布拉佐夫
在过去十年中，技术在市场营销中的重要性逐渐增加，无论是启动广告活动还是设置分析，现代市场营销人员都必须接触技术，并且不可避免地会接触到那些开发、实施和维护这些技术的人：技术人员。
这种互动有时让我想起角色生存游戏（Survival RPG），在这个残酷的世界中，你必须提升自己的技能以求生存；又或者像隐藏物品游戏（Hidden Object Game），你的细节关注程度直接影响游戏进度的成功与否。
我将与您分享7个原则，接受这些原则将有助于建立市场营销人员与技术人员之间的合作关系。不过，我想说明一下，本文绝不详尽，也不是解决所有问题的“银弹”。
***
首先，让我们承认市场营销人员和技术人员讲的语言不同，即使谈论同样的事情。这很正常。你不会因为听不懂法国人的语言而生气吧？
在共同的任务中，市场营销人员通常会提出“总体”请求。例如：“我们需要GDPR合规和教程完成事件。”而技术人员则需要实现细节，因此对他们而言，这样的任务是不够具体和深入的。自然，这一方会抱怨“你们不能清楚地告诉我们你们需要什么”，另一方则反唇相讥：“你们甚至连一点点思考都不愿意”。
现在，让我们谈谈原则和案例。
1. 与产品开发人员沟通
我有一个朋友，几年前他来到一家公司，决心了解产品团队，看看他们是如何与市场营销部门互动的。所有团队几乎都给出了相同的回答：“我们不知道市场营销在做什么。”可他们怎么能知道呢，如果没有人尝试将这些信息传达给他们？市场营销团队对此并不感兴趣。
即使市场营销团队在沟通中变得更加积极，仍然发生了可以归结为两句话的情况：“这个女孩在做什么？”和“哦，那是那个处理图标的女孩…”这样的形象源自于与产品团队的ASO专家的积极互动，该专家时常要求在成功的A/B测试后更换游戏中的图标。
也许对市场营销人员来说最残酷的事实是：接受技术人员在一开始总把你视为“那个处理图标的女孩”。即使他们在业务上的理解与您相似，比如在量子物理学方面，您仍需赢得他们的尊重。所以，第一个原则是：与产品开发人员沟通。
2. 核实接收到的数据
在免费游戏中，市场营销人员往往（如果不是总是）会跟踪应用内购买（IAP）和首次支付事件。在我接下来谈到的案例中，公司运营了几款游戏，而这些事件都已“实施”。在推出新游戏时，市场部仅要求新游戏的团队实现相同的事件：“我们需要购买和首次支付，”他们说。
问题在于，公司的新游戏团队是一个新团队，而对于他们而言，这是一个新建未解决过的任务。当然，他们可以询问其他游戏团队，但他们自己之前从未处理过这样的任务。
事件被实施后，游戏上线了，大家都很满意…可过了一段时间，营销测量合作伙伴（MMP）与商店控制台的收入报告却严重不一致。大额退款或转换率的波动无法归咎于商店。
经过调查，发现游戏团队在发送首次支付时将支付金额也发送了过去。这是一个正确且诚实的金额，但这一行为与其他游戏的“仅发送首次支付事实，而不包括金额”的做法不同。最终，所有游戏在首次支付时都会收到一个含有具体收入的收入事件，以及此时发送的“支付事实”；而在新游戏中，打过的收入事件和首次支付事件重复发送了相同的金额，自然首次支付的收入会“重复记录”。
这个案例很好地展示了，当一方没有明确说明他们具体需要什么而另一方又不愿意稍微思考时，会产生的情况。总体而言，两方都没有深入了解另一方为顺利工作所需的东西。甚至没有发生“市场营销人员vs.技术人员”的真正冲突。人们只是各说各的语言，以为对方明白了，却都没有去重新确认。
所以市场营销人员的第二个原则是：核实接收到的数据。技术人员可以检查他们发送的数据是否有到达，但是否发送了正确的数据则需要明确需求。
3. 记录你的实现过程
在之前的案例中，技术人员也存在问题。问题在于他们创建了一个“未记录的特性”来实现事件。另一个关于首次支付事件的案例将帮助我展示与文档工作不善相关的后果。
我朋友所工作的用户获取团队注意到，在某些国家，从自然流量转变为付费用户的转化率超出了预期。这看似不大，但对他们来说却是“悖论”，因为其一，是由于在投资回报率（ROI）方面严格的KPI，付费用户获取（Paid UA）受到了“超级针对性”的影响；其二，理应对自然流量的转化产生影响的特性，虽然带动了整体收入，却往往转化率低于普通自然流量。
在数据调查中为了寻找欺诈，发现那些有让人困惑的自然流量转化为付费用户的国家有一个“不可思议的指标”：首次支付事件次数超过了发送过至少一个IAP事件的独立安装次数。
此时甚至游戏团队也无法解释这为何发生：负责实施的员工已离职。但所有人都坚信事件在正确的时机以正确的指标发送 – 已经得到了验证。曾有人提出某种新的、未知的欺诈，或其他方面的问题。然而在这个案例中“那一方”就是MMP。
事实是什么呢？游戏在自己的数据上判断一个支付事件是否首次支付，并将事件发送给MMP。问题在于，在某些情况下，MMP和游戏自己的服务器对“唯一性”的定义存在分歧：对某些人来说这意味着新的安装和新用户，而对另一些人来说则是老用户重新安装了游戏。
如果在实施MMP时，不仅正确描述任务，还以市场营销人员能理解的术语清晰描述事件的实际实现，那么这种差异本可以避免。但游戏团队没有做这样的文档 – 他们只是按照理解实施了被要求的东西，并忘记了“与游戏无关的市场营销代码”。
这引出了我们的第三个原则：记录你为自己完成的实现过程。如果为你做了某件事，而你觉得一切正常 – 确保你有文档。如果没有文档？那就和开发者沟通，加以了解并自己记录。否则，半年后会发现没人知道这到底是如何工作的。
4. 记录达成的协议
当你只有一款游戏，且大家都在同一个城市时，互动要比处理多个项目和分散团队来得简单。尤其是当市场营销“脱离”产品时。
在这个案例中，市场营销团队负责对彼此独立资源的开发团队所开发应用进行应用商店优化（ASO）。ASO的关键是了解版本发布日期，至少需要提前规划自己的工作以准备App Store的元数据，因为在没有版本的情况下无法修改任何内容。此外，为了准备这些元数据，ASO专家需要与设计师共同准备创意，与本地化团队协商文本翻译。这些团队也有自己的计划和资源限制，他们和市场营销并不绑定于某一款游戏。
市场营销团队多次请求产品团队提前通知发布日期，不要悄悄修改这些日期，也不要在同一周进行多个发布。在这些只是口头协议的情况下，它们的效果时好时坏，整体上看更加像是偶然。这是一个重要的教训，可以用一句话概括：记录你达成的协议。
随着时间的推移，市场营销团队和产品团队达成了一项协议，即每个新发布的项目都加入了一个发布版本的独立任务，并包括各个平台的子任务。令人惊讶的是，之前并未有这样的任务。新的发布项目结束于测试阶段，发布版本通常由项目经理或版本工程师“没有独立任务”地完成。
在出现独立任务后，市场营销团队获得了变更信息。如果某些内容发生更改或在多个游戏之间“冲突” – 可以立即看到，而不是事后；游戏、市场营销、设计师和本地化团队之间的潜在“冲突”也能立刻显现。
5. 阅读可用的技术文档
今年夏天，我在白夜彼得堡大会上详细讲述了在“成人”项目中实施广告货币化的经验。
在众多内容中，谈及广告货币化指标时，我提到可以监测广告客户在游戏中展示的广告。这非常有用，原因有很多：可以看到哪些创意在您目标用户中效果好，还可以为自己的创意借用成功的概念；可以察觉到某些新强大的广告活动的出现，以及用户所看到的不相关广告的情况。
实现这一点的方法之一是通过专门的服务，其SDK已集成到应用中。如果信任该服务，实施应该很简单：只需要在应用中添加一行代码，之后一切都会自动跟踪。
似乎这有什么难的？您只需要创建一个账号，给开发者提供文档链接、SDK和账号密钥 + 访问权限 – 然后就大功告成。这是理想的情况。我朋友处理了类似的任务，但事情并不顺利。实施用了一个半月。添加一行代码竟然花了一个半月，您说这多不合理？
我不想用复杂的技术细节来让您感到厌烦。那句“只需添加一行代码”对市场营销人员和开发者都开了个玩笑。SDK的文档相当庞大，但在显示一行代码的那一页之外，没有人去阅读，市场营销人员和技术人员都没有。大家只是添加了带有必要密钥的一行代码，但仍然无法生效。
这也是市场营销人员的重要教训：阅读可用的技术文档。即使你无法完全理解，至少可以向同事表达担忧：一切并不像合作伙伴所承诺的那样简单。
6. 接受由技术引起的限制
我将通过下一个案例来展示这个原则：在实现广告货币化时，我朋友所在公司决定开发内部媒体。这个决定是由所有者做出的，目标之一是增加透明度并完全掌控广告收入的一个关键指标 – 展示次数（impressions）。
显然，市场营销部门作为实施广告货币化的发起者，非常希望充分利用自我开发所带来的灵活性。与游戏项目负责人一起起草了技术要求，描述了想要跟踪的内容，并与分析团队共同制定了数据存储方案。总之，他们对这个项目采取了非常负责任的态度，毫无疑问，避免了许多典型的市场营销与技术互动中的“疏漏”。
不幸的是，在项目期间，某游戏的项目负责人发生了更换，发布没有收集到完整的统计数据，而其他游戏的发布则没有出现统计数据收集问题。想象一下，朋友的困惑，因为第一款游戏让他了解到根本无法收集统计数据。
问题全部出在一个指标上 – 点击数。市场营销希望看到用户对游戏内广告的点击次数。应用中存在所谓的“执行流”。在一款应用中所有内容只有一个主流，而在另一款中，游戏流和广告流是分开的。正是由于这一实现特性的影响，游戏无法跟踪用户对广告的点击。是否可以修正？可以，但这将需要非常漫长而耗费资源的代码重构。因此，无论市场营销多么希望，也不得不放弃在自己的媒体上跟踪点击。
这导致了下一个原则：接受由技术引起的限制。
7. 接受团队中的变化
奇怪的是，人们并不总是与公司或某个产品密切相关。项目中的这种情况有时可能会带来冲击疗法，但这是事实。
我朋友曾推动一款游戏，在一年半的时间内换了5个项目经理和3个制作人，18个月内要与8位不同的“关键人物”建立关系，达成协议。显然，这种情况对产品和团队都有负面影响。
如果您也遇到了这种情况该怎么办？基本上，您需要超级提升危机管理技巧：您与一个人达成协议，与另一个人做事情，而最终将这种成果交给第三个人。每个人都对情况有自己的见解，各自有自己领导下的指示、各自的“安全感”意识和应对情况的风险倾向。
在这种情况下，遗憾的是，没有“银弹”。我可以建议市场营销人员向我的朋友学习：接受团队中的变化。
是的，人们来来去去。是的，某人的离职可能会使您在推进产品时的工作复杂化：与之前的人达成的所有协议，新的同事可能根本不想听。很遗憾，不过如果您认为自己是个专业人士，就应该去和新的人达成协议。
结论
当我回顾以上原则，特别以这番稍显夸张的方式阐述时，我在想：这更多是关于技术人员还是市场营销人员？我觉得这更多是关于你自己。你想成为“那个处理图标的女孩”，并不明白技术人员用什么语言与你沟通吗？你想要抱怨是他们不会沟通吗？或许，首先应该从自己做起：阅读文档，与人交流，总之，提升自身的技术技能，使与你的技术人员的互动更像是解谜角色游戏（Puzzle RPG），而非角色生存游戏（Survival RPG）。
