type
status
date
slug
summary
tags
category
icon
password
在写之前文章的过程中，我对游戏行业的数据口径产生了一些疑问。因为Apple和Google并未对实时APP实际下载数据和收入公布，那这些三方平台给出的细节数据是统计口径等从何而来。另外，市场数据和行业的最重要的数据指标，还是有必要探究下它的来源，在日后引用到各大平台的数据也清楚其应用范围和局限性。本文先不聊有关投流和广告相关数据（包括各类平台出的广告，关键词竞价等），所以本文就主要研究以下内容：
一、对比当前市场主流APP数据分析平台
市面上提供APP下载和销量的数据分析平台非常多，其中七麦数据、点点数据和Sensor Tower（包括Data.ai）是其中较为知名的，它们各自提供了不同的功能和特色，以满足开发者、市场营销人员和产品经理的需求。以下是对这三家平台主要功能的对比：
七麦数据
点点数据（DataEye）
Sensor Tower/Data.ai
1. 主要功能对比
ㅤ | 七麦数据 | 点点数据 | Data.ai/Sensor Tower |
中国及全球APP排行 | 有 | 有 | 有 |
有 | 有 | 有 | |
有 | 有 | 有 | |
有 | 有 | 无 | |
有 | 有 | 无 | |
有 | 有 | 无 | |
有 | 有 | 有 | |
有 | 有 | 无 | |
有 | 有 | 有 | |
有 | 有 | 有 | |
有 | 有 | 有 | |
有 | 有 | 有 | |
有 | 有 | 有 | |
用户评价 | 有 | 有 | 有 |
ASA投放平台 | 有 | 有 | 有
|
ASA竞价应用监控 | 有 | 有 | 有 |
ASA搜索排行指数，关键词对比，关键词拓展助手，联想词智查 | 在APPSA | 有 | 无 |
TapTAP排行 | 无 | 有 | 无 |
Playstation排行 | 无 | 有 | 无 |
Switch排行 | 无 | 有 | 无 |
Steam排行 | 无 | 有 | 无 |
用户留存分析 | 无 | 无 | 有 |
用户情绪分析 | 无 | 无 | 有 |
用户活跃数据 | 无 | 无 | 有 |
盘点下三家各有优点和缺点：
- 三家基本打平的点：应用排名和排行榜的覆盖率、用户界面和体验、数据导出、竞品分析、竞品分析
- 七麦数据和DataEye优点：
- 数据实时性：在数据的更新频次上部分数据可以做到5-10分钟更新，而DataEye更新频次为一天2更
- 关键词分析：强大的关键词分析工具，帮助开发者优化应用的搜索排名
- 价格：对比Sensor Tower的订阅价格更低，更适合中小型开发者
- 数据深度：对中国市场的数据深度比Data.AI强
- DataEye优点：
- 覆盖更全面的榜单：包括Tap Tap、PS、Steam等数据
- Data.ai的优点：
- 用户侧的数据，包括留存数据、用户使用数据、用户活跃数据等
- 对比前两者，用户界面和体验更简单、直观，易于使用
总结来说，如果是中国游戏面对中国市场，毫无疑问七麦数据和点点数据是目前最适合的选择。而如果是中国游戏发海外市场，三者各有优略势。对于中小型公司来说，我还是建议使用这两家，因为无论是使用习惯还是数据的实时性，更适合这类团队。而对于中国大型游戏公司，一般都会有自己的数分帮建立更为精确和符合各公司使用习惯的数据仓库，Data.ai的市场似乎更适合偏海外发行的外国公司。
二、实时排行榜单的实现
实时运算和数据处理对于三方数据公司非常重要，因为他们需要提供最新和准确的市场情报。一般来说，会每分钟爬虫和API收集数据，数据通过Kafka进入流处理系统。然后使用Flink处理数据流，实时更新统计和分析结果。处理后的数据存储在Druid进行实时查询，同时关键数据存入Redis用于快速访问。实现这一目标通常涉及以下几个关键技术和方法：
2.1 数据收集和抓取：
IOS提供有按类型分的Top Free Game、Top paid Game和Top Grossing Game榜单，各榜单可拉取前2000名的数据。
前端APP有显示大致的游戏的评价数量，这个数据可以在ASA侧查到更详细的数据。
Google Play与IOS类似，也有提供下载量和评价量等数据
- 官方API：利用App Store和Google Play提供的官方API进行数据收集。这些API通常提供开发者自身应用的下载和使用数据，能提供高频率和实时的数据更新。
- 自动化爬虫（Web Scrapers）：使用分布式爬虫系统，持续不断地从应用商店网站抓取数据。为了保持实时性，这些爬虫需要具备高效的抓取和解析能力，同时要处理反爬机制，如IP封锁、验证码等。
- 以Python 爬虫为例：写爬虫脚本，定期抓取 App Store 畅销榜页面的数据。常用的库包括
requests和BeautifulSoup。
- 结合用户贡献数据：一些公司会鼓励开发者通过 SDK 或 API 上报他们的应用数据。这些数据通常包括用户行为、收入、下载量等，通过聚合和分析大量开发者提供的数据，能够获得较为全面的市场洞察。
2.2 数据处理和存储：
- 流式处理（Stream Processing）：使用流处理框架，如Apache Kafka、Apache Flink、Apache Storm等，实时处理和分析数据。这些框架可以处理大量数据流，并在数据到达时立即进行处理。
- 内存数据库：使用Redis、Memcached等内存数据库来存储和快速访问实时数据。这些数据库具有极低的延迟和高吞吐量，适合实时数据存储和检索。
2.3 数据分析和机器学习：
- 实时分析引擎：使用实时分析引擎，如Apache Druid、ClickHouse等，进行实时数据聚合和分析。这些引擎可以处理大规模数据并提供亚秒级查询性能。
- 机器学习模型：训练和部署实时更新的机器学习模型，利用新到的数据进行实时预测和估算。例如，可以使用TensorFlow Serving或Seldon等工具部署实时推理服务。
2.4 分布式计算：
- 分布式计算框架：使用Apache Hadoop、Apache Spark等分布式计算框架处理和分析大规模数据。这些框架可以并行处理数据，显著提高计算速度和效率。
- 容器化和编排：通过Docker和Kubernetes实现应用容器化和编排，确保数据处理和分析服务的高可用性和可扩展性。
2.5 缓存机制：
- 缓存层：在数据查询和分析过程中使用多层缓存机制，减少对后端数据库的直接访问，提升查询速度。Redis或Memcached常被用于实现这种缓存层。
2.6 实时数据管道：
- 数据管道（ETL/ELT）：构建高效的ETL（Extract, Transform, Load）或ELT（Extract, Load, Transform）数据管道，确保数据从收集、清洗、转换到存储和分析的整个过程快速高效。例如，使用工具如Apache NiFi、Airflow等。
具体实践上，每个公司基本流程会随公司实际情况不同而改变。以上流程通过不断的反馈验证和优化，最终形成自己的流程。
三、基本数据运算逻辑搭建
各渠道商都没有直接公布的官方数据，但我们其实可以根据开源数据对这些数据进行一个大概的预估，比如App Store除了排名外还有：
- 下载量：在每个应用的 App Store 页面上，通常会显示应用的下载量范围（例如，“100K+”表示超过100,000次下载）。
- 评论数：用户可以在 App Store 中对应用进行评价和评论，这些评论会显示在应用页面的“评价与评论”部分。
对于Google Play商店和Apple App Store的下载量和评论数据更新频率略有不同，总的来说，Google Play 商店中的下载量和评论数据更新更加实时，而 Apple App Store 中的下载量虽然也会每日更新，但用户评论的更新几乎是实时的。
3.1 估算下载量：
- 通过抓取排名数据和评分，可以建立下载量和排名之间的关系模型。例如，可以通过分析历史数据得出某个排名对应的平均下载量，然后应用到当前数据中进行估算。
- 一个简单的线性回归模型可能是：其中 a 和 b 是根据历史数据拟合得到的参数。
- 评论和评分数据分析：
- 用户评论和评分的数量也可以作为下载量的间接指标。通常，评论和评分的增加量与下载量有一定的比例关系。相对来说，评论数据更加精确。
- 公式可能是：其中 c 是根据历史数据计算出的每个评论或评分对应的平均下载量。
- 第三方数据源：
- 通过与广告网络、市场研究公司等第三方合作，获取他们的数据和估算模型。这些第三方可能会有更广泛的数据收集渠道和更复杂的分析模型。
综合使用这些方法，可以提高下载量预估的准确性。以下是一个最简单版综合公式示例：
其中，𝑤1w1、𝑤2w2、𝑤3w3 是权重，代表不同数据源的重要性，这些权重可以通过历史数据优化和调整。通过不断迭代和优化这些模型，并结合多种数据源和分析技术，Sensor Tower等公司能够提供较为准确的下载量估算。
3.2 估算收入：
自iOS11起,App Store和web都不再展示总榜和畅销榜。目前基本各网站展示的总榜和畅销榜数据是同步自iOS 10 App Store数据。这个数据的准确性相对来说以及比较稳定。
除了实时榜外，对于月收入等预估的主要来源可能是根据下载数据、企业财报、专家访谈等来持续优化的模型预估所得。
- 应用内购（In-App Purchase, IAP）和广告收入可以基于用户行为数据、平均收入值（ARPU, Average Revenue Per User）和下载量进行估算。
- 收入也需要除去给到平台的30%佣金以及增值税。
- 公式大概是：
- DownloadsDownloads 是估算的下载量
- Conversion RateConversion Rate 是转化率，即下载用户中进行内购的比例
- ARPUARPU 是每个用户的平均收入
3.3 用户活跃度和留存率：
- 这通常包括日活跃用户（DAU, Daily Active Users）、月活跃用户（MAU, Monthly Active Users）等指标。
- 留存率的基本公式是：
- 用户活跃度和留存率目前仅Data.ai有计算，据官方解释，这个数据是结合了安卓市场和IOS市场，不同类型APP的历史数据，根据该app所处类目的日活，七活，月活等数据来估算。另外，他们也通过监测用户行为数据来估算。
- 大部分的游戏日留存不足80%，七日留存不足20%。
3.4 排名变化和流量估算：
- 通过分析排名变化和历史流量数据，可以估算排名变化对应用下载量和使用量的影响。
- 简单的模型可能是：其中，Rank Change Factor 是基于历史数据和经验得出的一个系数，表示排名变化对流量的影响程度。
这些公式和模型只是帮助理解和估算的基础工具。在实际操作中，Sensor Tower等公司会使用更加复杂和精细的数据分析技术，包括机器学习算法、大数据分析和多源数据融合，以提供更精确和全面的市场情报和分析服务。
四、模型优化以达到更准确的预测
验证和优化数据模型，收入等相关指标可以通过各公司的财报来进行验证。记录预测数据和真实数据的差值，来不断优化拟合模型。
4.1 模型选择和训练
- 模型选择：选择适合特定任务的模型（如线性回归、决策树、随机森林、梯度提升树、神经网络等）。
- 超参数调优：使用网格搜索（Grid Search）、随机搜索（Random Search）或贝叶斯优化（Bayesian Optimization）等方法来优化模型的超参数。
- 交叉验证：使用k折交叉验证（k-fold cross-validation）评估模型的性能，确保模型的泛化能力。
4.2 模型评估和优化
- 评估指标：选择适当的评估指标，如均方误差（MSE）、均方根误差（RMSE）、平均绝对误差（MAE）、R²、准确率（Accuracy）、精确率（Precision）、召回率（Recall）、F1分数（F1 Score）等。
- 误差分析：分析模型预测误差的分布和原因，找出影响模型性能的关键因素。
- 集成方法：使用集成方法如Bagging（如随机森林）、Boosting（如XGBoost、LightGBM）、堆叠（Stacking）等，结合多个模型的预测结果，提高模型的整体性能。
4.3 模型调整和改进
- 正则化：使用L1或L2正则化来防止模型过拟合，提高模型的泛化能力。
- 特征选择：通过递归特征消除（Recursive Feature Elimination）、LASSO等方法选择最重要的特征，减少噪音和冗余特征的影响。
- 模型集成：结合多个不同类型的模型，形成一个集成模型，提高预测精度。
4.4 实践中的具体方法
- 误差分布分析：绘制预测误差的分布图（如残差图），识别系统性偏差或异常情况。
- 特征重要性分析：使用特征重要性评估方法（如基于树模型的特征重要性、SHAP值）识别和优化重要特征。
- 模型调优工具：使用如TensorFlow的TensorBoard、Scikit-learn的GridSearchCV等工具进行超参数调优和模型性能评估。
- 自动化机器学习（AutoML）：利用AutoML工具（如Auto-sklearn、Google AutoML、H2O.ai）自动化模型选择、特征工程和超参数调优过程。
- 实验管理：使用实验管理工具（如MLflow、Weights & Biases）记录和比较不同模型和参数设置的实验结果。
通过这些方法和技术，数据模型可以不断优化，使预测数据更接近真实数据，提高模型的准确性和稳定性。
五、搭建自家数据平台
除了选择三方数据平台，也可根据Apple和Google 提供的API，自己做一个集合个平台数据的内部分析工具。除了上述两家，还可以加入华为商城，小米商城，Vivo，oppo，魅族，应用宝，百度，360，豌豆荚等渠道下载情况。
5.1 Apple Store Connect API
对于开发者，我们可以在Apple Store Connect API获取其应用的下载量、销售数据等信息。需要注册一个Apple Developer账户
- Apple Store Connect API有多个端点，用于访问不同类型的数据。以下是一些常用的API端点：
- Sales and Trends Reports:
/v1/salesReports - 更新频率：每日更新。
- 数据延迟：通常会有一天的延迟。例如，今天查看到的数据是昨天的销售和下载情况。
- Finance Reports:
/v1/financeReports - 更新频率：月度更新。
- 数据延迟：每月初提供上一个月的财务报告，通常在几天内完成。例如，1月份的财务报告会在2月初生成并可用。
- App Analytics:
/v1/appAnalytics - 更新频率：每日更新。
- 数据延迟：通常会有一天的延迟。例如，今天查看到的分析数据是昨天的用户行为数据。
- Customer Reviews and Ratings:
/v1/customerReviews - 更新频率：实时更新。
- 数据延迟：一般在用户提交评论和评分后几分钟内可见，但有时可能会稍有延迟。
详细的API文档可以在这个链接看到。
Apple Search Ads 版本选择：Basic or Advanced
5.2 Google Play Console和其他
Google Play Console也提供了一些基本的APP表现数据
其他部分先暂时略过。
参考网站：
- 作者:Bennett Niu
- 链接:https://niulengxiao.asia/article/Gamedata
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章